Re: Bug reports, patches and other stuff
On Fri, 12 Sep 1997, Nikita Schmidt wrote:
> I was thinking about it myself (it's not handy to have to visit several
> FTP sites just to decide whether I can use a binary or have to build it
> from the source). However, Bdale convinced me that we should get all
> our packages to master as soon as possible, and this would eliminate the
> inconveniences caused by the absence of such a page.
Very true. I thought about doing a simple perl script or something to
autogenerate the pages, though, so updating wouldn't be a hassle (which
would make it kinda easy and nearly worthwhile regardless).
> There is absolutely no patch required to build a working more out of
> util-linux-2.7.1. I've filed a bug report against util-linux (upgrade
> request), so if the original maintainer releases util-linux-2.7.1 as a
> Debian package, we'll be able to accommodate more on a more permanent
> basis. I just feel it absolutely pointless to fix bugs in old versions
> when newer versions that have already got the bugs fixed are available.
I may go ahead and debianise that version for us at least. I'm sure the
maintainer won't be far behind anyway and we can move over to his
afterwards. I'll look into this probably this weekend, time allowing.
> I just did not try to recompile the modules/modutils/whatever package
> myself to say whether it works or not... I am not 100% sure that the
> problem with the current insmod is the binutils version, just 99%.
> Current Debian binutils (2.8.1) should be OK, I've built my insmod under
> much older binutils. I think building new modules support packages is
> hopefully nothing more than just plain "debian/rules binary".
Well, I'm running binutils 2.8.1 with no such luck with modules. Maybe my
ksyms are to blame, but I get all kinds of strangeness. Then again, I've
never attempted modules before with the Alpha, so maybe I'm missing out on
something that everyone else seems to know (not unlikely). I'll see what
goes. If you try with 2.8.1 binutils and it works for you, let me know
what you did and I'll see if it works for me and maybe write something on
it for others who may be in the dark :)
> Even maybe if it is not that working and stable...
Good point...after all, we're still "unstable" really.
> Great. Wonderful. For I doubt that my own registration as a Debian
> maintainer is going to give any results.
Did you submit your e-mail to new-maintainer? I know that the new
maintainer person is REALLY backed up right now. The only reason I was
expedited was because of the sheer volume of work that I have waiting to
upload.
> Did you just add an option to specify -A if the system is going to be
> booted from ARC? Certainly it's a solution, although, in my opinion,
> not quite perfect. Because:
You bring up good points regarding this...especially the SMP part (I
expect to see more SMP Alphas out soon), but since SMP really isn't
technically supported under Alpha yet, that alone wasn't a terribly vital
problem.
The other points were great, though, and I agree. If you can build it all
package-wise, I'm sure Pasi and the rest of us would switch over.
> The problem with /dev/rtc is that this driver is broken under normal
> 2.0.x kernels. A simple fix is included with the standard
> alpha-patches, though.
Do we have a time-table for the next stable kernel yet (2.2.x)?? I
haven't seen the kernel list since I've gotten back, so I don't know how
far they are from completion.
> There is no common opinion in the Alpha world on what the epoch should
> be. Windows NT uses 1980, Digital UNIX - 1952, Linux (following the
> DOS/PC tradition) - 1900 (or sometimes 2000).
Hehehehe...unfortunately, that will probably persist. I doubt that
Digital will change to MS's ideas and vice versa. As far as Linux goes,
at least we can adopt to one or the other. Because of the install base of
NT on the Alpha, though, I would tend to go with that side. That's just
my ugly opinion, though :P
> The question now is, where to put this code. It seems natural to put it
Hmmm....good question :)
> the epoch dependency should go into the kernel. Putting a little bit
> (quite little, beleive me) of epoch support code into the kernel does
> not break anything. Changing the well-established /dev/rtc interface,
> unfortunately, would be a disaster.
Yeah, that would be bad. This is probably best brought up in debian-devel
or even the kernel list since they may be able to offer better suggestions
than I could. I never really had to deal with alot of that stuff, but
probably could get more into it if need be.
> I strongly agree, and I'm sure that is not only your personal feeling.
> Of course, we are not going to introduce proprietary kernel patches
> unless it is strictly necessary. All the proposed modification must be
> submitted to the "upstream maintainers".
Yeah, I agree.
> No, they haven't. And I doubt they ever will. The axp-patches, which
> have evolved into alpha-patches, have been around since 1.3.x. They
> never managed to get their way into the official kernel sources,
> probably because the main development is going on with 2.1.x; nobody is
> interested in patching 2.0. However, alpha-patches are a quite official
> patchset for 2.0.x/alpha, so I'll better submit my patches to Jay.
Great. There is some development still going with pre-2.0.31, though, and
if it's just minor stuff that's Alpha-related and fits with the 2.0.x
kernel series, they should accept the patches. If it can wait, though,
maybe waiting for the 2.1.x series to go to 2.2.0 is the better idea with
patching 2.0.x kernels for now. If we're over two months away from those
new kernels, though, I would try posting the patches for the 2.0.31
project.
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: