Re: mispackaged packages..
On 27 Aug 1999, Eberhard Burr wrote:
> 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 ;-))
Pick up a 2.2 kernel (try 2.2.11...works nice on an SX -- I just booted
2.2.12 today and it seems to be nice as well). There were some funky time
problems with earlier kernels on the SX.
> 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...
It's being extricated by the Debian maintainer, though :-) He's got
access to a build Alpha to play with and is working on the problem as
well, so hopefully, once he returns from holiday, he'll be able to get us
a working package.
> 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.
In either case, let me know what you find if you decide to play with it a
bit. I'd be happy to spin a new upload if it needs it and can get a
working patch. Without the hardware to test it here, I'm hesitant to even
look at it.
> 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 :-)
Hehehehe...yeah, it's kind of ugly getting these things up. To make it
worse, there's SOOOOO many different types of Alphas that no one
HOWTO seems to cover it. I currently know two methods (ARC and
AlphaBIOS), but SRM is foreign to me (and I've been on Alpha for years
now). Regarding the booting off of the hard drive, it can be a pain with
the SX's. They seem to not be able to recognise any drives that are
hooked up to my Tekram SCSI board, so I had to add a small IDE drive to
run MILO from.
> 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.
We plan on working on docs a bit more. Unfortunately, most of us are
better programmers (and workaholics) than we are at documenting things
<g>. I'll note the suggestions, though, and see if we can improve things
for the people who are totally new to Alpha. To be fair, the main Debian
install doc is REALLY lacking as far as good installation instructions.
The README that Loic generated with the boot disks is far better and
probably should be more prominant on the CDs.
> 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.
Oh, sorry :-) Best way is to unpack it with dpkg-source, edit
debian/rules and remove any reference to strip. That will keep all of the
symbols in there. From there, it's just a matter of figuring out how to
add -g to the CFLAGS/CXXFLAGS (usually can be done easily if they use a
configure script). After you figure out that (I can give more detail
depending on the method of configuration and/or compilation
involved...there's too many to generalise or elaborate on here), install
the debs and have a go with gdb.
C
Reply to: