Re: Bug reports, patches and other stuff
On Tue, 9 Sep 1997, Nikita Schmidt wrote:
> First, there are still bugs in some of the currently available binary
> packages, from segfaults in in.ftpd to just bad dependencies. Most of
> these bugs are specific for the Alpha port, so there is no point in
> reporting them to their primary maintainers. We have to handle them
> ourselves and then fill the official bug reports with patches included.
Agreed. As far as the bad dependencies, some of those have to do with
packages that haven't been converted to the new format yet. I know that I
have to go back into some of the ones I've built and redo them since
they're still using hard-coded dependencies. I didn't want to do this
yet, however, because of my reason for building half of the packages --
for testing purposes. I would rather have those of us that use some of
the packages to test them before I just toss them up to master. I would
really hate to compile a package that I have no use for, then find out
that it seg-faults on an end-user. Since "normal" package maintainers
only maintain packages that they use themselves, this isn't a problem on
the x86 platform, but we're kinda on the frontier :)
> This is the reason why I have set up a small bug tracking system,
> designed to aid in just remembering the bugs in the distribution and
> making them known to others. Anybody who wants to help with the port
> is welcome to take over any of the open bugs, to report new bugs, to add
> comments etc. via that system, which is accessible via the WWW at
> http://genie.ucd.ie/alpha/debian.html.
I'm already looking into some of these bugs and will update the tracking
site as I make progress. I'm thinking about putting up a web page myself
that lists the packages that are compiled already (hot-linked to the ftp
site), but don't know if it's needed yet...any feedback anyone?
> Second, I have built several packages, most of them having bugfixes.
> These packages are temporarily available at
> ftp://genie.ucd.ie/pub/ftp/alpha/debian, although I would like to get
> them to some more or less standard place, like Christopher's.
By all means, upload them to my site :) I have an incoming directory
already established that I check daily now. The packages you listed are
extremely useful (apache and samba were two that I considered
high-priority for "platform attractiveness" reasons). As far as the
more binary, if you could, post it to my site with a patch and/or source
and notify Pasi to replace the copy he included in base with yours.
Finally, regarding insmod, you say it's compiled under newer binutils? If
so, is it feasible to upgrade the binutils package so that I can repackage
module support? I would rather address the source of the problem rather
than just tossing in a working binary temporarily.
> I think that the Debian/Alpha effort is not quite well organised at the
> moment. The first thing I would like to see now is at least to get all
> the binary packages together. Master is not a good place for this (see
> Michael Alan Dorman's explanation why). What, I think, we need is some
> place to keep binary packages toghether with the patches (like, "second
> level" patches) which have been applied to their Debian source packages
> to make those binaries. These patches will eventually get merged with
> the main distribution.
> This centralisation will hopefully help people find packages more easily
> and will also eliminate duplicate efforts (with the help of the bug
> recording system).
I tend to agree on most of this. I'm not going to get into a debate (as
I've seen one develop already on this topic while I was gone), but I would
say that anything that we have confirmed is working and stable SHOULD be
uploaded to master ASAP. I have the disk space to keep the stuff, but for
new users, I would hate for them to get confused as to what's current,
etc. My site could serve as a repository for "untested" or not-so-clean
stuff until whomever is working on the package says that it's ready for
master (at which point, it would get uploaded). FYI, all I need to do now
is have my PGP key verified and I'll have access to master, so alot of my
packages will be there soon.
> Probably Christopher's machine can do this (at least it has write
> permissions on incoming), if he does not object. (Do you, Christopher?)
> Or we can go with genie.
I don't object at all. Since I seem to have an "established" site at this
point, it's probably easier to keep everything on my machine :)
> I propose to make the RTC driver mandatory and to use *only* the /dev/rtc
> interface to set system clock on bootup. That's where the epoch stuff
> comes in handy and will hopefully eliminate a Very Frequently Asked
> Question "my system says it's 2017 year, but the ARC console shows it OK!".
> The solution proposed is to autodetect the epoch (unfortunately, I have
> to do it in the kernel because of the RTC driver design, but that's only
> a few bytes).
This has been fixed now by Pasi and also myself (we both did it but didn't
know that each of us had done it separately :P). The new base disks will
reflect the change. The only thing that needed to be changed was the way
that "clock" was called. No kernel mods were needed (thank goodness).
Also, regarding the kernel, my personal feeling is that if we need to
patch the kernel, then we should submit the patches for modification of
the kernel sources by "the powers that be". I know I'm always leary of
patching the kernel through more than one revision of the sources, since
it shows that the problems we're patching aren't being addressed by the
current kernel folks. Have your patches and Jay's patches been accepted
for 2.0.31?
I have more to say on some other subjects, but I'll bring that up in a
separate mail since it's not really a follow-up...just an idea that your
message reminded me of.
Chris
--
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: