Re: mispackaged packages..
On 27 Aug 1999, Eberhard Burr wrote:
> xawtv: the v4l-conf utility as well as xawtv-remote are not in the
> binary package. They compiled from the source (the source
> package contains intel binaries, btw) and work well, so I
> think they have simply got lost in the packaging process.
Is this slink or potato? If it's potato, I can always recompile it, but
the compile finished flawlessly and appeared to have everything in there
when I compiled it circa last week. As far as slink goes...I can look
into it but am not sure how quickly I can get a replacement into the
archive.
> xemacs20 : is there any particular reason that there's no
> xemacs20-nomule binary package? I failed to compile myself
> because I don't have all the required library headers
> installed, but I guess, I'm not the only one using xemacs
> without mule. I'd appreciate pointers to pre-compiled binaries
> but also will try to get it compiled from source unless someone
> tells me that it has severe troubles...
Both emacs20 and xemacs20 are true headaches to compile on Alpha (I won't
even go into emacs19). EGCS always had problems compiling both and, to
make matters worse, xemacs has MANY source problems involved (emacs20 has
some newer code which xemacs doesn't...code that's needed for better
portability). Right now, neither package is compiling at all on Alpha in
potato, so again, this may be a problem that's not easily solved on our
level. I've been working on it here and there, but haven't had the time
to really figure out why it doesn't work properly.
> afbackup: is anyone running afbackup on alpha? I just tried it in
> favour of taper and all I could get was that afclient
> complained about the server refusing connections. Telnetting to
> the afbckup server on localhost gives an error about the
> machine having 8-byte longints or somesuch. (I've already
> erased the package from disk so I don't have the exact wording
> of that error at hand)
> have I overlooked something?
Wish I ran it so I can figure out what's wrong with this. It is probably
related to the size of some of our types versus the Intel. In other
words, this is probably a 32-bit->64-bit issue. I'll look at the afbackup
in potato and see if there's anything obviously troublesome in there.
I'll also dig up the slink source and look for problems in there.
> taper: on my intel box, taper 6.8 used to run nicely (daily backup of
> ~2G system and ~1G user data) while taper 6.9 segfaults. Now,
> I've tried taper 6.9 on alpha and it segfaults too. I really
> don't want to waste too much time with this since last time I
> checked, it was a heisenbug (wouldn't occur when running taper
> in the debugger), so the question is: is there still a taper6.8
> binary or source package anywhere?
I may have one, but will have to look. I keep all kinds of arcane stuff
:-)
> milo: any particular reason for not including a milo package into the
> main distribution?
MILO is currently not easily packaged. It won't compile on it's own with
glibc and 2.2 kernels. I suppose we could always make a binary package,
but since MILO needs to be installed on a DOS partition, floppy, or CD, it
would be kind of moot to install it into an ext2 partition like a normal
Debian package. Believe me, I went back and forth about this with another
developer for awhile, but neither of us came up with an easy way to handle
it or implement the installation.
> Don't get me wrong: I _am_ deeply impressed by the ease of
> installation (after having wrestled the stupid BIOS, that is) and the
> degree of stability of Debian. I am ready to look into some problems
> myself but I can use a guiding hand sometimes. If there is some quick
> guide to debugging source packages, I'd highly appreciate that.
Look for the obvious: pointer->int conversions (pointers are 8 bytes, ints
are 4 bytes), assumed type sizes (where the code obviously assumes longs
are 4 bytes like on Intel, for instance), and such. A good starting point
is to compile the package using the -Werror or -Wall switches to gcc and
log the compilation. -Werror will abort compilation if it generates a
warning (sometimes unavoidable...I would use -Wall, which should warn you
of all kinds of anomalies). Then go back and look into the warnings.
Good luck. If you need any further help, please don't hesitate to ask me
or the list...
C
Reply to: