Re: Only m68k and i386 in hamm?
Martin Schulze [EMAIL PROTECTED] writes: Speaking for binary-powerpc there will not be 2.0. I hope we'll be ready for 2.1. I wonder if it would be useful to remove binary-powerpc from hamm completely and only work on slink. Speaking of the powerpc distribution, how's it doing? Is there any chance I could use it to install Debian on some Power Macs using the monolihic kernel (which supposedly runs OK on the relevant machines). I have a group of people here who want to start learning Linux, and I'd rather set them up with Debian than RedHat. I'm happy to deal with some ugly hacking to boostrap things if needed. Thanks -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
At 00:31 +0100 1998-04-30, James Troup wrote: Michael Alan Dorman [EMAIL PROTECTED] writes: [ ... ] ld.so doesn't apply [ ... ] Upgrade your quinn-diff :-) From 0.31's ChangeLog.main :- | Sun Apr 12 21:33:14 1998 James Troup [EMAIL PROTECTED] | | * Packages-arch-specific (ldso): exclude alpha. (Maybe it should also be excluded for the other glibc only architectures too? I always welcome input on Packages-arch-specific as I'm only qualified to speak for m68k (and then only barely)) powerpc is the only other glibc-only architecture in Debian, AFAIK. You'll need to add powerpc to ldso's exclude list too. -- Joel Espy Kleckermailto:[EMAIL PROTECTED]http://web.espy.org/ Debian GNU/Linux Developer...http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
Michael Alan Dorman [EMAIL PROTECTED] writes: [ ... ] ld.so doesn't apply [ ... ] Upgrade your quinn-diff :-) From 0.31's ChangeLog.main :- | Sun Apr 12 21:33:14 1998 James Troup [EMAIL PROTECTED] | | * Packages-arch-specific (ldso): exclude alpha. (Maybe it should also be excluded for the other glibc only architectures too? I always welcome input on Packages-arch-specific as I'm only qualified to speak for m68k (and then only barely)) -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
James Troup [EMAIL PROTECTED] writes: Michael Alan Dorman [EMAIL PROTECTED] writes: [ ... ] ld.so doesn't apply [ ... ] Upgrade your quinn-diff :-) From 0.31's ChangeLog.main :- Yeah, but I've been meaning to feed back my changes in one block rather than in dribs and drabs, no time, etc. (Maybe it should also be excluded for the other glibc only architectures too? I always welcome input on Packages-arch-specific as I'm only qualified to speak for m68k (and then only barely)) Probably? Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
Is there any reason we couldn't do a delayed debian-hamm-alpha release? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
On the subject of bootdisk readiness: I spent a couple days about 2 months ago trying to get Debian onto my alpha pc164lx. Basically, none of the problems I encountered resulted from features in MILO or the bootdisks themselves. They were all due to misinterpretation of the instructions on my part :) Of course, due to the bewildering array of alpha chipsets, I have no idea how things might go for a cabriolet or a miata but, as far as the pc164's are concerned, I had no more trouble installing the debian base system than I had on any of the intel machine's I've worked on over the last few years. Sothe bootdisks look good to me. Jesse Goldman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
Raul Miller writes: Is there any reason we couldn't do a delayed debian-hamm-alpha release? I was also thinking about that. As i386 seems to be the leading arch (sorry for others, no offense intended), we could IMHO release it first (maybe together with m68k ?), and then release hamm/alpha or hamm/whatever later on, maybe even if slink/i386 is near release. -- Yann Dirson [EMAIL PROTECTED] | Stop making M$-Bill richer richer, alt-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
Martin Schulze [EMAIL PROTECTED] writes: Sounds good. I know it sounds good. I just want to be sure that's it's the right thing to do. :) So my understanding is that only i386 and m68k are to be official 2.0 releases. alpha (and other) will wait for 2.1. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
On Tue, Apr 28, 1998 at 10:02:56AM -0400, Christopher C. Chimelis wrote: I agree with this and it's been very frustrating to try to get things ported over (fyi, for the x86 folks). Also, often, new upstream sources Is there an alpha machine with accounts available so that we i386 maintainers could try doing alpha compiles ourselves? Can you give, or give reference to, some information about why alpha appears to be more trouble than m68k? thanks, Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
Hamish Moffatt [EMAIL PROTECTED] writes: Is there an alpha machine with accounts available so that we i386 maintainers could try doing alpha compiles ourselves? No. The machines that most alpha developers have available are either not well connected, in environments that require more security, or simply aren't sufficiently powerful to make it reasonable. In the past I proposed to Bruce that Debian could use some of its funds to purchase a fast Alpha motherboard and memory to which I could add plenty of disk space, network connectivity and administrative services, but got no response. Can you give, or give reference to, some information about why alpha appears to be more trouble than m68k? There's more divergence from the i386 environment wise---in all the packages I've compiled in the last several days, there were at least a handful of failures because of attempts to make oldlibs packages that are totally inappropriate for the Alpha since we've been glibc from the beginning. Those packages *are* needed cor m68k, which has been around since libc5 days. Compiler support is less mature---we just now got a version of egcs that can compile emacs20 reliably. I, personally, have used gcc on the m68k for nearly a decade, all the way back to 1.X days. Also, the Alpha is a 64-bit platform, which means we also tend to turn up issues with source code that makes 32-bit assumptions. And even Linux/Alpha has undergone one major transition during its availablity (ECOFF to Elf), that means even emacs-20.2 (only release a few months ago) needs to be hacked to work correctly, since it's still worrying about ECOFF. In addition, remember that glibc patches for many packages (especially net based ones) originated in the Alpha port. We've been using glibc exclusively for a year, and had to put in a lot of hard work at the very beginning to deal with a lot of glibc issues that other hamm developers were free to not deal with. Finally, realize that packages-wise, we probably rival RedHat's Alpha port---something on the order of 800+ packages are available on the Alpha. However, that's *half* of the number available in Debian/i386. Many of the ones that haven't been ported are the more obscure ones that probably don't support Alpha at all. But we try to make it work anyway. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
In article [EMAIL PROTECTED] you wrote: : Finally, realize that packages-wise, we probably rival RedHat's Alpha : port---something on the order of 800+ packages are available on the : Alpha. However, that's *half* of the number available in Debian/i386. That raises an interesting question, that I've thought about quite a bit... What constitutes a port that is complete enough for distribution? I personally think that if all of the packages marked as 'standard' or higher are there and working, it's good enough for me to think we should release it. That is obviously a far cry from everything, but my guess is we'll never have 100% occupancy of all packages on all platforms, even if for such reasons as MILO only being used on Alpha, LILO on i386, and SILO on Sparc. So, where is it ok to draw the line? One of the questions we ask ourselves at my place of daytime employment goes something like: At what point is our drive for perfection no longer helping our customers, but in fact hurting them by causing the stuff we've done that does work to not be available to the folks who could use it and don't care about details at the margin? I think we should ask ourselves that here. In fact, it's a good question for the 2.0 release process overall. I'd like to propose that if a non-i386 architecture has a reasonable installation process and base archive, plus .deb's for all packages marked as 'standard' or higher in the i386 tree (modulo obvious exceptions like lilo), that it be considered ready for inclusion in a release. Thoughts? Given the current state of the Alpha port, this objective may or may not be attainable for a 2.0 release. I don't currently have (much) time to help, though I have put a fair amount of time into the Alpha port personally in the past. But on the debian-alpha list, I see some flailing since we don't have a solid definition of what needs to be present for a release to be considered ready, and without such a goal, it's hard to focus and concentrate effort on what needs to be done. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
Bdale Garbee [EMAIL PROTECTED] writes: I'd like to propose that if a non-i386 architecture has a reasonable installation process and base archive, plus .deb's for all packages marked as 'standard' or higher in the i386 tree (modulo obvious exceptions like lilo), that it be considered ready for inclusion in a release. Thoughts? As one of maybe two alpha-porters who have never taken their alpha through the Debian installation process (my alpha has been running some form of Debian/Alpha for more than a year, and thus predates the install disks), I am wretchedly unqualified to speak to the first part of your suggestion. However, I think we could just about achieve everything marked standard or higher. Heck, we may already and not realize it. Quick quinn-diff run And, in fact, I find that we basically have. The following would need to be dealt with: net/lpr_5.9-26.1.dsc [standard:libc6] editors/emacs19_19.34-16.dsc [standard:libc6:X] base/gzip_1.2.4-27.dsc [required:libc6] base/ld.so_1.9.7-1.dsc [required:n/a] devel/cvs_1.9.26-3.dsc [standard:libc6] base/kbd_0.95-12.dsc [required:libc6] base/shadow_970616-1.1.dsc [required:libc6] x11/xfree86_3.3.2-3.dsc [standard:libc6:X] admin/cron_3.0pl1-44.dsc [important:libc6] base/e2fsprogs_1.10-14.dsc [required:libc6] utils/sharutils_4.2-5.dsc [standard:libc6] shells/tcsh_6.07.02-7.dsc [standard:libc6] admin/at_3.1.8-2.1.dsc [important:libc6] libs/glibc_2.0.7pre1-4.dsc [required:libc6] base/procps_1.2.7-1.dsc [required:libc6:X] devel/egcs_1.0.2-0.7.dsc [standard:libc6] devel/gdb_4.16.98-1.dsc [standard:libc6] editors/emacs_19.34-13.dsc [standard:libc6:X] I just did emacs19 today, ld.so doesn't apply, we're actually using a more up-to-date egcs, gdb4.17 has actually been released so 2.0 shouldn't go out the door with a snapshot, and except for glibc---which I've been having some problems with---the rest are easily doable. (Parenthetically, I think we should swap lprng for lpr, I'm not sure why cvs is standard, and emacs_19.34 should be removed from the archive) But on the debian-alpha list, I see some flailing since we don't have a solid definition of what needs to be present for a release to be considered ready, and without such a goal, it's hard to focus and concentrate effort on what needs to be done. A very good point. It's hard to know when you've achieved something if you haven't picked out a measuring stick beforehand. So what do people think of the status of the boot disks? Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
I've just done an initial install on a Alpha machine that was originally setup with RH 4.2. I upgraded the machine to RH 5.0. I then reworked and did the initial install of Debian hamm on another partition and am now duel-booting. I have consideral experience with Debian-i386, but do not consider myself an expert by any means. Perhaps an above-average user. I'd say you have a way to go. The base disks are way out of date. It took considerable hacking to finally get the system current. Not all packages in the hamm/binary-alpha will install. There are several packages which depend on ldso which is not available to install. I guess it depends on how close you really are to the i386 release. I think for someone knowledgable, and a bit of work, an alpha release could be possible. I am running the Debian/hamm now on my system. My biggest problem is getting the required passwork server running which was built on libc5 (which is not available under hamm). Bdale Garbee [EMAIL PROTECTED] writes: I'd like to propose that if a non-i386 architecture has a reasonable installation process and base archive, plus .deb's for all packages marked as 'standard' or higher in the i386 tree (modulo obvious exceptions like lilo), that it be considered ready for inclusion in a release. Thoughts? As one of maybe two alpha-porters who have never taken their alpha through the Debian installation process (my alpha has been running some form of Debian/Alpha for more than a year, and thus predates the install disks), I am wretchedly unqualified to speak to the first part of your suggestion. However, I think we could just about achieve everything marked standard or higher. Heck, we may already and not realize it. Quick quinn-diff run And, in fact, I find that we basically have. The following would need to be dealt with: net/lpr_5.9-26.1.dsc [standard:libc6] editors/emacs19_19.34-16.dsc [standard:libc6:X] base/gzip_1.2.4-27.dsc [required:libc6] base/ld.so_1.9.7-1.dsc [required:n/a] devel/cvs_1.9.26-3.dsc [standard:libc6] base/kbd_0.95-12.dsc [required:libc6] base/shadow_970616-1.1.dsc [required:libc6] x11/xfree86_3.3.2-3.dsc [standard:libc6:X] admin/cron_3.0pl1-44.dsc [important:libc6] base/e2fsprogs_1.10-14.dsc [required:libc6] utils/sharutils_4.2-5.dsc [standard:libc6] shells/tcsh_6.07.02-7.dsc [standard:libc6] admin/at_3.1.8-2.1.dsc [important:libc6] libs/glibc_2.0.7pre1-4.dsc [required:libc6] base/procps_1.2.7-1.dsc [required:libc6:X] devel/egcs_1.0.2-0.7.dsc [standard:libc6] devel/gdb_4.16.98-1.dsc [standard:libc6] editors/emacs_19.34-13.dsc [standard:libc6:X] I just did emacs19 today, ld.so doesn't apply, we're actually using a more up-to-date egcs, gdb4.17 has actually been released so 2.0 shouldn't go out the door with a snapshot, and except for glibc---which I've been having some problems with---the rest are easily doable. (Parenthetically, I think we should swap lprng for lpr, I'm not sure why cvs is standard, and emacs_19.34 should be removed from the archive) But on the debian-alpha list, I see some flailing since we don't have a solid definition of what needs to be present for a release to be considered ready, and without such a goal, it's hard to focus and concentrate effort on what needs to be done. A very good point. It's hard to know when you've achieved something if you haven't picked out a measuring stick beforehand. So what do people think of the status of the boot disks? Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- /--\ |James D. Freels, P.E._i, Ph.D. |Phone: (423)576-8645 | | L | A | |Oak Ridge National Laboratory |FAX:(423)574-9172 | H | I | L | |Research Reactors Division |work e-m: [EMAIL PROTECTED]| F | N | P | |P. O. Box 2008 |home e-m: [EMAIL PROTECTED] | I | U | H | |Oak Ridge, Tennessee 37831-6392|world's best neutrons | R | X | A | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
Martin Schulze [EMAIL PROTECTED] writes: As far as I can see we only have disadvantages supporting hamm-powerpc. (no regular uploads, extra handling of security fixes to non-supported versions, frozen of _really unstable_ binary set etc.) I would make dinstall just throw all uploads for it to slink and ignore hamm. That way porters don't have to worry that the package says frozen unstable. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
On Tue, Apr 28, 1998 at 02:23:12AM -0700, Guy Maor wrote: Martin Schulze [EMAIL PROTECTED] writes: As far as I can see we only have disadvantages supporting hamm-powerpc. (no regular uploads, extra handling of security fixes to non-supported versions, frozen of _really unstable_ binary set etc.) I would make dinstall just throw all uploads for it to slink and ignore hamm. That way porters don't have to worry that the package says frozen unstable. Sounds good. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / The good thing about standards is / / that there are so many to choose from. -- Andrew S. Tanenbaum / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
[crossposted to debian-alpha] On Tue 28 Apr 1998, Guy Maor wrote: [I had to read the original message via the archive, as the mailhost here was screwed up yet again and discarded all messages arriving this weekend :-( ] About Alpha: There's been a lot of porting going on for Alpha, however, I can't really say that the number of packages that need to be ported to Alpha has been decreasing since the freeze; every time 20 packages are uploaded for Alpha, there are 22 new packages for i386 :-( That aside, I'm pretty happy with the way my Alpha works with hamm; I'd be satisfied if I was a Joe User trying out debian on my Alpha for the first time. The only part that still needs to be worked on is the boot disks situation; the boot disks themselves need work and the accompanying docs are also pretty useless, to put it bluntly (sorry to those who have been working on them, but unfortunately it's true; I myself am also to blame, I could have written up some docs myself in the meantime). So, I'm still undecided as to whether 2.0 should go out for Alpha. Anyone else have opinions? Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands Support Randal Schwartz! See http://www.lightlink.com/fors/ or send empty email to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
Paul Slootman wrote: There's been a lot of porting going on for Alpha, however, I can't really say that the number of packages that need to be ported to Alpha has been decreasing since the freeze; every time 20 packages are uploaded for Alpha, there are 22 new packages for i386 :-( I agree with this and it's been very frustrating to try to get things ported over (fyi, for the x86 folks). Also, often, new upstream sources have been breaking some compilations that would have ordinarily been clean (thus requiring more hand-patching and therefore, more time). I had hoped the freeze would've slowed down the upload of packages to master, but it seems to have increased it, unfortunately. That aside, I'm pretty happy with the way my Alpha works with hamm; I'd be satisfied if I was a Joe User trying out debian on my Alpha for the first time. The only part that still needs to be worked on is the boot disks situation; the boot disks themselves need work and the accompanying docs are also pretty useless, to put it bluntly (sorry to those who have been working on them, but unfortunately it's true; I myself am also to blame, I could have written up some docs myself in the meantime). The docs are definitely lacking. I am also partially to blame for this, but RL has gotten in the way again. As far as the boot disks go, I don't even know who's working on them anymore. Until we can resolve that issue at least, I would agree that the Alpha may not be Hamm-release-date-ready. So, I'm still undecided as to whether 2.0 should go out for Alpha. Anyone else have opinions? I am getting another Alpha at the end of the week (this will be my third now), so I should be able to at least get a clean install on a system and see what problems come about so I can start fixing them. Because of personal problems, however, I'm not sure how long all of that is going to take :-( Luckily, Michael Dorman has been uploading packages like crazy, so that's a HUGE help, but the standard and required packages are starting to slip by the wayside (dpkg notably). IMO, I think if we can at least get some boot disks together, all of the required packages up to date and functional, and compile current versions of all packages with security fixes, then we should have a release-quality base system for the Alpha. If we can do that by the release date, then yes, I think the Alpha port can be included in the Hamm release. If not, though, I would recommend against it for obvious reasons Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
Paul Slootman [EMAIL PROTECTED] writes: So, I'm still undecided as to whether 2.0 should go out for Alpha. Anyone else have opinions? I think we should leave it out of 2.0, with the caveat that we should nevertheless start referring to it as a full-fledged port---and once we get further along in the process of fixing packages that don't compile well on the alpha (and from the couple-hundred packages I tried to compile this weekend, many failures stemmed from poor packaging, not any inherent software limitations I can see), it will be less trouble to keep up. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
There's been a lot of porting going on for Alpha, however, I can't really say that the number of packages that need to be ported to Alpha has been decreasing since the freeze; every time 20 packages are uploaded for Alpha, there are 22 new packages for i386 :-( Thats the reason for needing more time as two weeks after the deadline!! Minumum are four weeks! Bye, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
