uploaded libc (5.4.23-6 (i386 source) to master
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Thu, 22 May 1997 21:38:26 +0200 Source: libc Binary: libc5 libc5-pic localebin libc5-dbg libc5-dev Architecture: source i386 Version: 5.4.23-6 Distribution: frozen Urgency: high Maintainer: Helmut Geyer <[EMAIL PROTECTED]> Description: libc5 - The Linux C library version 5 (run-time libraries). libc5-dbg - The Linux C library version 5 (debug files). libc5-dev - The Linux C library version 5 (development files). libc5-pic - Kit for building specialized versions of the shared C library. localebin - The locale binaries of the Linux C library version 5. Changes: libc (5.4.23-6) frozen; urgency=high . * fix packaging mess up for frozen: add libc5-pic and localebin packages again. Remove libc5-altdev package. Files: 4e3bb6927a826b08e70a1ea6903189d9 689 libs required libc_5.4.23-6.dsc f85c6b2eef81306c0c7b0e4123f15064 652069 libs required libc_5.4.23-6.diff.gz a7f87b0bb19369a721f9870d96be1bea 259152 base required libc5_5.4.23-6_i386.deb 22fd42916bc6508365137a44b6c68f96 857602 devel standard libc5-dev_5.4.23-6_i386.deb b36f10ac2a6f743bc9f019f52f1e76fe 1188992 devel optional libc5-dbg_5.4.23-6_i386.deb 426e496049024d7a2f64291fc70b1d6f 849486 devel optional libc5-pic_5.4.23-6_i386.deb e64fe94e794fbf7993d0c4ffe9459bdb 44820 devel optional localebin_5.4.23-6_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBM4TTNtr+2q4pQAYJAQEWpQP/ZwAkjVllfPVzi84agag8Fn2aJIxXvGsc XaTDcmI5xGWc1C4aMqAFAYnLwqJ74sVC7REjKMM6HQea65TRpq1tD8kByE27G97m 8wpHmVBZHT7LGwlD5gOs9XwDybS8IDjGPw29C8gdA2hcl0kdS+T2kM9o/33nSteW 2BjDwJ55aTA= =xcx1 -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Conflict between Packages file and actual files
Dale Scheetz <[EMAIL PROTECTED]> writes: > > On Thu, 22 May 1997, Bob Nielsen wrote: > > > On Thu, 22 May 1997, Dale Scheetz wrote: > > > > > On Thu, 22 May 1997, Bob Nielsen wrote: > > > > > > > In /frozen, the packages file shows: > > > > > > > > procmail_3.10.4-1.deb > > > > modconf-0.2.9.deb > > > > > > > > The actual files are: > > > > > > > > procmail-3.10.4-2.deb > > > > modconf-0.2.10.deb > > > > > > > This is a mirror sync problem. The packages file on master is correct. > > > Give the mirror you are using some time to catch up and try again, or, you > > > can crate your own, correct, Packages file using dpkg-scanpackages. > > > > I thought that might be the case, so I checked ftp.debian.org and got the > > same answer. I ended up ftp'ing the two files and installing with dpkg > > rather than worry about dselect not accepting the packages file. > > > This is a continuous problem. I don't know why ftp.debian.org takes so > long to get in sync with master, but the problem simply propogates from > there to all the additional mirrors. Debian is the only distribution I > know that depends so heavily on the accuracy of one file. This sounds like a locking problem to me. If the archive on master changes while the mirror to ftp.debian.org is running, then the packages file will obviously differ from the contents of the archive. This can continue down the chain of mirrors. Assuming no locking takes place, then differences become increasingly likely as the time taken to update the mirror increases. Another source of this is if the packages file on master is not updated immediately after a package is added. These problems will presumably settle if the archive is unchanged for a couple of days. I strongly agree however that dselect ought to cope a lot better than it does at present. I've had it fall over when it calls dpkg -iGROEB and a package I'm not interested in has a broken symlink on the archive. I've made a suggestion to the deity team that this should be one thing to tackle. Chris -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
'Raul Miller wrote:' > >> '=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= wrote:' >> > So I say: PS1="[\\u] \\h:\\w\\$ " =D >On May 21, Chris Fearnley wrote >> No, PS1='[EMAIL PROTECTED]:\w\$ ' ! >> >I'd prefer PS1='\$ ' > >However, if you want all that fanciness, a compromise is: >PS1='[EMAIL PROTECTED] \W\$ ' How about: PS1='\[\033[40;31m\]pwd: \[\033[40;33m\]\w \[\033[40;[EMAIL PROTECTED] ' I'll repeat my conclusion: leave it as PS1="\\$ " and provide a customization app for sysadmins to edit /etc/profile and another for users to edit ~/.bash_profile (and other dotfiles too, of course) and keep the installation's paws away from customizations that EVERYBODY has a different opinion about. -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | "Dare to be Naive" -- Bucky Fuller -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Donald Becker's ethernet drivers
Any chance of getting the ethernet drivers listed as "supported" in the ethernet howto, but stored at cesdis.gsfc.nasa.gov instead of in the main linux kernel, included in the base debian kernel distribution? -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Missing xemacs
Since I didn't get an answer on -private, I'll do this the public way. Xemacs seems to be missing from bo. It's in rex and hamm. I con- sider a missing major package a bug unless there was a reason it was pulled. Brian? Anyone? Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps "It's almost impossible to overestimate the unimportance of most things." -- John Logue ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Missing xemacs
[EMAIL PROTECTED] (Tim Sailer) writes: > Since I didn't get an answer on -private, I'll do this the public > way. Xemacs seems to be missing from bo. It's in rex and hamm. I con- > sider a missing major package a bug unless there was a reason it > was pulled. Brian? Anyone? See bug 8857. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Missing xemacs
Guy, I think you made the wrong decision here. James LewisMoss never responded to the 8857 bug list to your request for pulling xemacs. In fact, I couldn't find anyone other than yourself who supported the decision to pull xemacs completely. The discussion was whether xemacs-19.14 or 19.15 was the best choice for bo. Could you please state your reasons for removing xemacs? xemacs-19.14 doesn't have any fatal flaws. Bug 8857 suggested that 19.15 be the official bo xemacs; it did not suggest that xemacs-19.14 be removed from bo distribution entirely. xemacs-19.14 and emacs conflict, but that is generally not considered a reason for removing a package. xemacs-19.14 is usable and better than nothing. Perhaps I misunderstood our policy, but I thought that a package should only be removed from stable if it has a critical bug. I didn't see any discussion on any mailing claiming that xemacs has a critical bug. In any case, the removal of xemacs requires further discussion. Please reconsider the decision to pull xemacs from bo. Guy Maor <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Tim Sailer) writes: > > > Since I didn't get an answer on -private, I'll do this the public > > way. Xemacs seems to be missing from bo. It's in rex and hamm. I con- > > sider a missing major package a bug unless there was a reason it > > was pulled. Brian? Anyone? > > See bug 8857. -- Kevin Dalley [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dselect/diety audit trail
> "Darren" == Darren/Torin/Who Ever <[EMAIL PROTECTED]> writes: Darren> -BEGIN PGP SIGNED MESSAGE- Amos Shapira, in an Darren> immanent manifestation of deity, wrote: >> Or an audit-trail of invocations of dpkg (e.g. "adduser 3.1-2 >> installed and configured successfully on Wed May 29 1997 >> 00:00:23, replaced adduser-3.1-0") Darren> I asked for this a while back and was told that not very Darren> many people wanted it. I still think it would be a useful Darren> feature... So do I. It would make it a lot easier to do bug reports when things fail at installation or upgrade time. -- Karl M. Hegbloom <[EMAIL PROTECTED]> http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect/diety audit trail
> From: Karl M. Hegbloom <[EMAIL PROTECTED]> > > So do I. It would make it a lot easier to do bug reports when things > fail at installation or upgrade time. > > -- I agree. As a member of the deity team, I can tell you that there will be an audit trail. This will be especially important in phase 2 and 3 of deity as the intention is to provide distributed management of nodes on a network. Having said that it would be next to impossible to manage these nodes if there isn't an audit trail. Peter -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Donald Becker's ethernet drivers
> Any chance of getting the ethernet drivers listed as "supported" > in the ethernet howto, but stored at cesdis.gsfc.nasa.gov instead > of in the main linux kernel, included in the base debian kernel > distribution? > The Boomerang driver (updated Vortex driver) has already been included in the latest kernel-source (2.0.20-6) and the kernel images of the boot disks. Are there other drivers that need to be included? Cheers, Thomas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Removing packages with critical bugs
I've just read a few messages complaining about the removal of xemacs
from bo. Why don't we simply move those packages with critical bugs to
contrib?
--
Debian GNU/Linux 1.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://greathan.apana.org.au/~herbert/
PGP Key: http://greathan.apana.org.au/~herbert/pubkey.txt
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Conflict between Packages file and actual files
> Dale Scheetz <[EMAIL PROTECTED]> writes: > > > This is a continuous problem. I don't know why ftp.debian.org takes so > > long to get in sync with master, but the problem simply propogates from > > there to all the additional mirrors. Debian is the only distribution I > > know that depends so heavily on the accuracy of one file. > > This sounds like a locking problem to me. > > If the archive on master changes while the mirror to ftp.debian.org is > running, then the packages file will obviously differ from the > contents of the archive. This can continue down the chain of > mirrors. > > Assuming no locking takes place, then differences become increasingly > likely as the time taken to update the mirror increases. Another > source of this is if the packages file on master is not updated > immediately after a package is added. These problems will presumably > settle if the archive is unchanged for a couple of days. I think its a combination of these two. I think that the archive on master being updated asynchronously with the package file is a problem (it leads to an inconsistant archive, for one thing), and I think that ftp.debian.org mirroring without locking is a problem. Is there any reason why the following can't be done, and why it can't be automated: 1) New packages are placed in the archive, without deleting the old versions. This way, the existing Packages file and the archive remain consistant -- if the Package file says it's there, it's there. 2) A new Packages file is generated by a script that only adds the newest version of duplicate packages. It would be nice if this also generated a list of older versions of duplicated packages for the next step, but that list could also be generated as part of step one. Since the only files listed in this new Package file are in the archive, consistancy is maintained. 3) Delete old version of updated packages. Since these are no longer listed in the Packages file, they can be deleted without ruining the consistancy of the Packages file. If this could be automated and run at a set time, then "locking" could be achieved by scheduling it at a time when ftp.debian.org -won't- be mirroring it. That way, ftp.debian.org is maintained as consistant. Similarly, if the mirroring could be achieved in the same order (new files, Packages, delete old files), then even during mirrors, ftp.debian.org would be consistant. -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect/diety audit trail
In article <[EMAIL PROTECTED]>, "Karl M. Hegbloom" <[EMAIL PROTECTED]> writes: > So do I. It would make it a lot easier to do bug reports when things > fail at installation or upgrade time. I agree, but I'm puzzled by what you chose for the subject line. This sort of functionality belongs in dpkg, not dselect (I'm not sure whether the current plan is for deity to replace just dselect or both, but the consensus I got from the last time it came up was that there would be a libdpkg and everything would be based on that, so presumably the audit trail would be implemented at that level)
Re: Donald Becker's ethernet drivers
On May 22, Raul Miller wrote > Any chance of getting the ethernet drivers listed as "supported" > in the ethernet howto, but stored at cesdis.gsfc.nasa.gov instead > of in the main linux kernel, included in the base debian kernel > distribution? Do they compile as modules? Maybe someone could package them up as kernel modules in a separate desdis-drivers package, or something like that. Christian pgpP1ekmonaO7.pgp Description: PGP signature
Re: Donald Becker's ethernet drivers
On May 23, Christian Hudon wrote > Do they compile as modules? Maybe someone could package them up as kernel > modules in a separate desdis-drivers package, or something like that. The eepro100.c file had a line in it (grep gcc eepro100.c) which said how to compile it (given /usr/include/linux for a kernel of proper version) without touching anything else. Note that I needed this to install the important and standard debian packages. Some kind of optional driver set wouldn't have been very useful to me. What I would have needed would have been an updated drivers disk. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Missing xemacs
Kevin Dalley <[EMAIL PROTECTED]> writes: > The discussion was whether xemacs-19.14 or 19.15 was the best choice > for bo. Could you please state your reasons for removing xemacs? Moving 19.15 to bo was out of the question because of the time and the seriousness of bugs still being filed against it. I never considered this a viable option. > xemacs-19.14 is usable and better than nothing. > Perhaps I misunderstood our policy, but I thought that > a package should only be removed from stable if it has a critical > bug. No, packages are removed from stable for the far more common reason that they're simply not ready for release. Releasing software that we know is full of bugs while at the same time advising people to install the package out of unstable is silly. We're not trying to compete with other distributions on sheer number of packages. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
I know nothing about runlevel standards, just my opinions: > "AK" == Alexander Koch <[EMAIL PROTECTED]> writes: AK: level 1 is without net, 2 is with it all (imo including nfs AK: and the like) and 3 is xdm, 6 was shutdown or halt or AK: whatsoever. at least that i remember from some german AK: distribution. I'm no big sysadmin but I think we can use all 1 to 4 levels. One free runlevel could be enough (in actually, if *I* need some modifications, I make them by modifying existing runlevels not creating new ones). AK: default runlevel is 2 so why should nfs start with 3? I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) 5: empty for making special local runlevel? So if I want to do something without being too used from outer world, I can switch to level 2 (and I can still telnet or ftp somewhere). AK: if 3 gets xdm, perhaps gpm should be disabled and the like? Remark: gpm should be disabled only when it doesn't work as a repeater. BTW, I don't like RedHat concept of empty level *4*. When I upgraded HW on some RedHat machine, I lowered default level from 5 to 4 in expection it will disable just xdm. Then I spent an hour looking for explanation, why many services don't start after changing HW. After I explored runlevel 4 was empty, I was far from being polite... Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
trn and inews
-BEGIN PGP SIGNED MESSAGE- When installing trn, the dependency screen pops up and suggests (ie. puts an asterisk beside) both cnews and inews. Shouldn't this only select one of the two? I don't know what package to report a bug against, so I thought I would ask here first. Cheers, Colin. - -- Colin R. Telmer, Institute of Intergovernmental Relations School of Policy Studies, Queen's University Kingston, Ontario, Canada, K7L-3N6 (613)545-6000x4219 [EMAIL PROTECTED] PGP Fingerprint = 09 E9 DA 66 9C EE 33 DC B8 3B 97 0E 01 BC EC 0B PGP Public Key at http://terrapin.econ.queensu.ca> -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBM4XhgRhhzOJJktw1AQEnSgP/cDTrr757i89oaCyI7JNvugRv/GAM+Big F2ge/g0wqm87Q+Li99rZHdIPpP1cFb4+zXy4Q2oYMvxiUsgRJ2GIPEP8d1UaXPLT qlYuA9dzngwH/StXlao4NYR+OnIsEBqwSXeaOM2Onjzs13RHlegCJetBatC3MZgu BJ3qunY12cc= =xwXW -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Mon, 19 May 1997, Brian C. White wrote:
> Hamm
>
I think its been agreed that this will be called "Debian 2.0", so why not
add this here.
> * All packages are in the new package format.
Possibly a new source package format may be created, so we should resolve
this before putting too much effort into converting twice.
> * All base packages are compiled with libc6.
Should be all pkgs in the main distrib really.
> * Fix packages currently depending on 'libc5-dev'.
> * Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
> * No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs,
> ...).
> * No a.out executables anymore.
> * Much improved dpkg/dselect.
> - Move config information from install scripts to "cfgtool" (???)
I'm having a look at ways of doing this. It would be really cool to
integrate this into deity.
> - Some sort of package-grouping mechanism for dselect
> - New run-level layout (???) [12]
> - No bug reports older than 9 months at release time
And another one:-
* Official Debian logo to be chosen
Footnotes 1, 4, 5, and 7 can be removed AFAIK.
--
Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10060: libc6-dev: time.h and linux/time.h conflict
You're absolutely right. I should have thought before I posted. In fact I already patched ibcs to work regardless which gcc/C library is used, since ibcs (as a kernel module) should include the kernel headers, but not the differing application headers. I'm sorry for reporting a non existant bug. Michael P.S.: It was one of those days ... -- Dr. Michael Meskes, Projekt-Manager| topystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Use Debian GNU/Linux! | Tel: (+49) 2405/4670-44 >-- >Von: Helmut Geyer[SMTP:[EMAIL PROTECTED] >Gesendet: Freitag, 23. Mai 1997 19:48 >An:[EMAIL PROTECTED]; [EMAIL PROTECTED] >Cc:[EMAIL PROTECTED] >Betreff: Re: Bug#10060: libc6-dev: time.h and linux/time.h conflict > >> Package: libc6-dev >> Version: 2.0.3-4 >> >> Just try to compile ibcs. I won't work because one source file includes >> and (or others), which includes . >> This gives an error condition since both files have a different definition >>of >> structure timespec. In fact it's not that much of a difference (long vs. >> long int) but enough for gcc to see an error. There are other double >>defined >> structures in other files (e.g. timeval, timezone, itimerval). >> >That is right, but this is _not_ a bug in libc 6 but comes from the fact that >many Linux applications use the kernel haeders themselves, which generally is >a bad idea anyway. >The change in the C library (i.e. to provide headers for all the stuff that >is >not really kernel-dependant) is coordinated with Linus and the kernel >developers. >These problems are bugs (or lets say portability problems) in the packages.. >IBCS should be fixed, not libc6. > > Helmut > >-- >Helmut Geyer >[EMAIL PROTECTED] >public PGP key available : finger >[EMAIL PROTECTED] > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
SIOCSIFFLAGS
[Aside: I think I sent a message about ethernet configuration with a subject line from an X configuration problem. My prior message on the subject was a bug report about a non-bug. Third strike and I'm out, but by jove I think I've got it.] Turns out I've got a buslogic 946C and a 32 bit lance card trying to share IRQ 11. I think this is a kernel problem. Anyone know the workaround? -- Raul FYI... Date: Fri, 23 May 1997 15:35:53 -0500 From: Eric Dittman <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: RE: Shared Interrupts >Did you ever get a solution to this problem? I'm running >into something similar (where I'm getting SIOCSIFFLAGS: Try again) and >don't know what to do about it. It turned out that Linux has two incompatible methods of sharing interrupts. The SCSI drivers tend to use one method and the Ethernet drivers tend to use the other method. Because of this (and I don't think it has changed) the SCSI card and Ethernet card can't share interrupts. -- Eric Dittman Texas Instruments - Component Test Facility [EMAIL PROTECTED](214) 462-4292 Disclaimer: Not even my opinions. I found them by the side of the road. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Kernel 2.0.30 a bad choice for 1.3
Christoph <[EMAIL PROTECTED]> writes: > On 21 May 1997, John Goerzen wrote: > > > Since we know of a number of things that have been broken in 2.0.30 > > (such as IP masquerading being totally hosed), why are we distributing > > that version with 1.3? 2.0.30 has SYN_COOKIES. This is a critical feature. > > It seems like a rather bad idea because it > > could very well break the setups of a number of people. I think that neither 2.0.29 nor 2.0.30 have a sufficient quality for the Debian release. > 2.0.29 is the proper kernel unless Herbert can assure us that he has fixed > all known bugs especially in relationship to networking. I doubt that Herbert has any methods for assuring anything over a 30 Megabytes source tree. The kernel developers didn't manage to fix all known bugs in 2.0.30, and I expect them to have significiantly better skills in this area than Herbert. Herbert does a good job with kernel-image, but we must not request him to fix arbitrary kernel bugs. Sven -- Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: --> Debian Bug #10000
Vincent Renardias <[EMAIL PROTECTED]> writes: > In case you're interessed, I just got the acknowledgement of bug report > #1 Lucky for us, the bug scripts are bug-1 compliant... ;-) -- Mike Coleman http://ctr.cstp.umkc.edu/~coleman I'm not an actor, but I play one on TV. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
