[Pkg-xen-devel] A bit of tagging

[Ralph Passgang]

just a small thing, could you only send mails to control at bugs.debian.org as 
bcc (when also mailing to the list), because I almost forgot to remove this 
adress when I just want to reply to the list for the second time now :)

I guess at the next time I will not notice this before it's to late ;-P

Am Freitag, 17. Februar 2006 14:55 schrieb Guido Trotter:
[,,,]
> > #321154: bzip2: Compressed file ends unexpectedly;
> >   -> never experienced something like that, for me unreproducible
>
> Neither did I... Anyway now we're not messing with kernels anymore, so
> we'll probably have to close it when uploading! (tagging)

right.

> > #330923: xend gives python warnings
> >   -> no problem with this since at least 2.0.7-0tha1, so this should be
> > solved
>
> Ok, great! (tagging) I hadn't before because I was mostly using xen on
> sarge and didn't try it in sid!

seems to that this was just a temporary issue in sid, because as I started 
using Adam's package and developing it further that was already working again 
on sid.

> > #326817: xend fails to start
> >   -> same as bug 330923? lookls like the exact same issue. then it's
> > solved
>
> Doesn't seem the same... it gives the same warning, but then the real error
> for which it doesn't start it:
> ERROR: Could not obtain handle on privileged command interface (2 = No such
> file or directory) (and then the traceback follows)

hard to say if it was the same issue or not without having more information. I 
think it would match in some aspect the other bug, so at least it could be 
the same issue (which is not a problem in new xen3 packages anyways).

Because you asked the bug reporter for "dmesg" output, please also ask 
for /var/log/xend.log the next time, because that's the place to find 
interessting differences to a working setup.

Another problem could also be, that hypervisor and xend doesn't matched, for 
example the user used an old xen 2 or even 1 hypervisor but 2.0.6 userspace 
tools or something like that. But hard to say, espacially because this is a 
quite old bug and the user most likely doesn't have xen 2.0.6 installed 
anymore.

> I don't know why he couldn't connect to the hypervisor... He didn't even
> reply my message asking if he was really trying from inside a dom0! So it's
> probably a bogus bug anyway!
>
> > #331297: building xen source package fails
> >   -> this is only a xen2 problem, this has never been a problem in xen3
> >        for xen2 I have a patch. anyways we can close that bug our 1st
> > upload
>
> Oh, good... As before I didn't say anything because I hadn't tried with
> that version of binutils... (tagging)
>
> > #325127: xen: missing man pages
> >   -> my packages installs the man pages that was missing in Adam's
> > releases, so can be closed on 1st upload
>
> No, the packages install the manpages, but there aren't man pages available
> for all the software installed in /bin, /usr/bin, /sbin, /usr/sbin, that
> is:
>
> /usr/bin/xenstore-exists
> /usr/bin/xenstore-list
> /usr/bin/xenstore-read
> /usr/bin/xenstore-rm
> /usr/bin/xenstore-write
> /usr/bin/xenstore-ls
> /usr/bin/xenperf
> /usr/bin/xc_shadow
> /usr/bin/xencons
> /usr/bin/cpuperf-xen
> /usr/bin/cpuperf-perfcntr
> /usr/bin/lomount
> /usr/bin/xentrace
> /usr/bin/tbctl
> /usr/bin/setsize
> /usr/bin/xentrace_format
> /usr/bin/pygrub
> /usr/sbin/xenstored
> /usr/sbin/netfix
> /usr/sbin/xm
> /usr/sbin/xen-bugtool
> /usr/sbin/xend
> /usr/sbin/xenperf
> /usr/sbin/xenconsoled
> /usr/sbin/xenbaked
> /usr/sbin/setmask
> /usr/sbin/xenmon.py
> /usr/sbin/xentop
>
> Between these only xm, xentop and xentrace have a manpage. Either we write
> them for all the others or we have, by policy, to leave the bug open!
>
> <Policy 12.1>
>
> Each program, utility, and function should have an associated manual page
> included in the same package. It is suggested that all configuration files
> also have a manual page included as well. Manual pages for protocols and
> other auxiliary things are optional.
>
> If no manual page is available, this is considered as a bug and should be
> reported to the Debian Bug Tracking System (the maintainer of the package
> is allowed to write this bug report themselves, if they so desire). Do not
> close the bug report until a proper man page is available.[71]
>
> You may forward a complaint about a missing man page to the upstream
> authors, and mark the bug as forwarded in the Debian bug tracking system.
> Even though the GNU Project do not in general consider the lack of a man
> page to be a bug, we do; if they tell you that they don't consider it a bug
> you should leave the bug in our bug tracking system open anyway.
>
> </Policy>

your right, I didn't knew that we would need to supply a manpage for every 
executable, even if the executable is not really meant to be a "user-tool".

but all manpages that upstream supplies are at least in the xen3 package, so 
better than nothing I guess :)

(I think we will have this bug open for ever, because it's hard to write 
manpages for tools that haven't got any kind of documentation in upstream).

> Guido

--Ralph