Re: mispackaged packages..
Christopher C Chimelis <chris@classnet.med.miami.edu> writes:
> > 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.
It's slink. The source package compiles without problem after the
intel binaries have been removed. Also, the make process complained
about some bogus time-stamps which may well be due to the hwclock
problem on SX164 that hit me during installation (hey, great system,
checks itself for Y2K conformance prior to installation ;-))
> 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.
So I think, I'll stay with the binary that I have and eventually get
the sources for 21.X from xemacs.org. There was a discussion about the
alpha issue on comp.emacs.xemacs a few weeks(months?) ago, and it
seems the authors are aware of the problem. For the moment, I cannot
afford spending major amounts of time on this because I have to get my
thesis out (the main reason I bought a faster machine in the first
place).
I was just curious because the Mule stuff adds even more complexity in
that one cannot be sure whether a buffer has one or more bytes per
character. I never understood why mule was integrated to tightly into
emacs but that's a different story...
[afbackup]
> 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.
I was just curious. I've found that the source packages are really easy
to install and so I thought maybe this package has just been compiled
and uploaded since the compilation went well... It seems the packaging
system adds a surprising amount of ad-hoc portability but of course it
cannot fix broken source code. After all, a client-server solution is
maybe a bit of overkill for a single user machine, so I'll try to dig
up the old taper sources.
>
> 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.
given the fact that I had zero experience with alphas last week, I'm
doing quite well now. One of the nastier things during installation,
however, was the fact that I couldn't get this machine to boot from
hard disk. Once the system was up, I felt rather nervous about
rebooting without a few spare floppies with milo and a kernel image on
them. Also, the complete documentation somewhere in /usr/doc would
have been helpful because after disassembling my machine and plugging
the alpha in, my room was a complete mess and thus having to search
the floor for the HOWTOs that i had printed led to some inexact
language :-)
Maybe the milo binaries are not necessary to have (or even nonsensical
at the point where the system runs) but the docs should be there. When
the system runs for the first time, one can still have a hard time
figuring out how to make it start next time. It would be even better
if there was a readme.exe on the installation CD, that could be
started from the BIOS.
> 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.
Hm, I was more looking for something like "unpack the source with
dpkg-source, then do/don't edit the files in place..." or maybe give some
special switches to one of the dpkg tools to get a binary with debug
information in it and the like. Well, I'll look into the dpkg
documentation as time permits.
kind Regards,
--
Eberhard Burr check http://www.uni-karlsruhe.de/~Eberhard.Burr/publickey.asc
for PGP Key -- #include <stddisc.h> -- electric cookie follows
DIDI ... is that a MARTIAN name, or, are we in ISRAEL?
Reply to: