[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: broken packages



On 21 Aug 1997, Ian Willmott wrote:

> If I find problems with packages in
> ftp://ftp.debian.org/debian/unstable/binary-alpha/ , should I ask about
> them on this mailing list or contact the maintainer directly? Is there a
> different maintainer for the Alpha versions? How do I find out who
> assembled the Alpha packages?

Best thing to do, for now, is to post any Alpha-related package problems
here.  Since most of us who are working on this port are doing nothing
more than patching for Alpha happiness and packaging, we can usually
determine easily whether the problem lies in what we did or the
(relatively) upstream version.  From there, whomever packaged the software
on the Alpha can contact the original maintainer via the bug tracking
system if need be.

At least this is my opinion on things since I've recompiled and packaged a
ton of things on the Alpha now.  Since I've had to patch a number of the
packages, I've become more familiar with the source code of many of them
and could probably not only figure out where the problem lies but also
could submit a patch or ideas to the original maintainer.

This leads to an interesting question:  Should we consider having a
"maintainer pool" of sorts for the different distributions?  I'm just
curious since alot of the current package maintainers don't have access to
other architecture hardware (Sparc, Alpha, etc).

Each package can have a maintainer for each architecture and all could
keep in contact somehow (along with getting bug reports simultaneously).
That may actually help a bit since it would allow for a bigger knowledge
base that's familiar with the source immediately available in case of bugs
or problems.  The downside is that such communication may provide for some
convolution and duplication of effort unless a "main maintainer" moderates
things somehow.

Any thoughts???

> some problems (details will follow when I find out the appropriate forum):
> - more (from fileutils). Either dumps core or puts the terminal into some
>   weird mode.

I'm working on this slowly but surely.  I just got a working gdb about two
weeks ago and that's on my list of things that are important.  More seems
to have a few problems that are architecture-related at first glance.  I
*HIGHLY* suggest using less instead and making a symlink from more until
the real more is fixed.

> - man-db. Install error while checking languages. I patched this, but now
>   "man" complains that "eqn" needs some option like "-Tlatin1" and does not
>   seem to save formatted pages.

I noticed this also and am going to look into it also.  In fact, I was
*JUST* thinking about this five minutes before reading this.  FYI,
compiling apropos entries isn't working correctly either.  On first
thought, I suspect this is glibc related, but I'll have to look into it
more deeply.  If you have some time, please forward the patches you have
to me and I'll see what I can find out from there...I also noticed the
install problem and was curious on how you fixed it.

> - ppp. Install error having to do with some "update-rc.d" perl script.

This one goes to Mike Dorman, I believe.  His e-mail is available on
www.debian.org under package maintainers.  He's been wrestling with pppd
for awhile now and trying to figure out why performance sucks on the
Alpha.  I've tossed a few suggestions at him since I'm more familiar with
TCP/IP as a protocol, but until I look at it, I don't know the progress of
that whole thing.

> - fvwm2. Some install error, can't remember exactly what.

Hmmm...I haven't installed that one and wouldn't know where to begin.
I'll check it out.  It's probably just script related and probably fixed
easily.  Given that X is non-essential, though, this is way down on my
list since we have some base-level stuff to check into first (PAM, for
one).

> Also, do I understand correctly that gcc_2.7.2.1-10 fixed the earlier
> gcc problems and that I can now turn optimisation on without fear that
> it will either coredump or emit buggy code? I looked at some .s output
> without optimisation and it was terribly inefficient.

Any gcc/glibc bugs or errors should be forwarded to Richard Henderson.
I'm sure he'd welcome ANY suggestions regarding optimisation that you
might be able to offer.  If you're really familiar with assembly language,
I may need to pick your brain a bit also to fix the unaligned trap
warnings we're getting.  I have isolated why they come about, but don't
know enough about compiler construction to offer a fix.

That having been said, I just wanted to let you know that I'm currently
waiting for access to master to upload the boatload of packages that I've
compiled.  Until I am granted access, you can find them ftp at:
	beezer.med.miami.edu:/pub/chris

Take/test anything you'd like and let me know if things posted there die
or croak in any way.  I've only compiled most and haven't done testing (I
have a slow UDB, so testing things is kinda wasted on my hardware).

Good luck :)

Chris
------------------------------------------------------------------
 Christopher C. Chimelis          chris@classnet.med.miami.edu
 Systems Supervisor
 Division of Biomedical Communications
 University of Miami School of Medicine
 --> finger chris@classnet.med.miami.edu for PGP public key <--



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: