Hi,
Finally, 2.4.18. No changes between it and -rc4.
final:
- No changes have been made between -final
and -rc4.
rc4:
- Load code did not set personality for
binaries without an interpreter: This was
breaking static apps on several archs (Tom Gall)
rc3:
- Fix reiserfs endianess problems (Chris Mason)
- Fix PowerMac compilation problem (Pmac team)
- Fix some eepro100 ID's which had problems
in -ac merge (Jeff Garzik)
- Rename some internal pcnet32 definitions to
not clash with ethtool.h - the clash caused
the driver not work correctly (William Lee Irwin)
- Add missing netif_carrier_{on,off} to
eepro100 (Andrew Morton)
- Fix netfilter race (Rusty Russell)
- Correct error handling on tcp_recvmsg (Alexey Kuznetsov)
- Revert tulip changes which were apparently
causing slowdowns (Jeff Garzik)
- Fix ptrace behaviour (Linus Benedict Torvalds)
rc2:
- Make get_user_pages handle VM_IO areas
gracefully (Manfred Spraul)
- Fix SMP race on PID allocation (Erik A. Hendriks)
- Fix SMP race on dnotify scheme (Alexander Viro)
- Add missing checks to shmem_file_write (Alan Cox)
rc1:
- PPC MPC8260 update (Tom Rini)
- eepro100 fixes (Jeff Garzik)
- Make natsemi hardware workaround a config
option (Jeff Garzik)
- Add serial board PCI ID (Jeff Garzik)
- Add support for another tulip clone (Jeff Garzik)
- Fix typo in winbond driver (Jeff Garzik)
- Move initialization of tridentfb before
the generic drivers (Geert Uytterhoeven)
- Reiserfs bugfixes (Oleg Drokin)
- More __devexit_p assorted fixes (Andrew Morton)
- Merge some -ac bugfixes (Alan Cox)
pre9:
- Cris update (Bjorn Wesen)
- SPARC update (David S. Miller)
- Remove duplicate CONFIG_SUNLANCE entry in
Config.in (David S. Miller)
- Change Netfilter maintainer (David S. Miller)
- More SunGEM bugfixes (David S. Miller)
- Update md5sums in ISDN's md5sums.asc (Kai Germaschewski)
- 3ware driver update (Adam Radford)
- Fix cosa compile problem (Adrian Bunk)
- Change VIA "disabling write queue" message (Oliver Feiler)
- Remove buggy Elan-specific handling code (Robert Schwebel)
- Reiserfs bugfixes (Oleg Drokin)
- Fix ppp memory leak (Andrew Morton)
- Really add devfs fix for removable devices:
its on pre8 changelog but not on pre8 patch (me)
- Add framebuffer support for trident graphics
card (James Simmons)
- SCSI tape driver bugfixes (Kai Makisara)
- Add support to Ovislink card on 8139too
driver (Jeff Garzik)
- Add SIOCxMIIxxxx ioctls for better binary
compatibility on au1000_eth driver (Jeff Garzik)
- Fix initialization of phy on epic100 driver (Jeff Garzik)
- Add MODULE_* info to mii.c (Jeff Garzik)
- Add new PCI ID to sundance driver (Jeff Garzik)
- Merge some -ac3 patches (Alan Cox)
- Unify simple_strtol symbol export (Russell King)
- Add amount of cached memory to sysreq-m
output (Martin Knoblauch)
- Do not use SCSI device type to change
IO clustering (Jens Axboe)
- IRC conntrack update (Harald Welte)
- sonypi driver update (Stelian Pop)
- Fix one of the PPP deadlocks (Manfred Spraul)
pre8:
- Add missing netfilter files in pre7 (David S. Miller)
- SunGEM driver update (David S. Miller)
- Kill get_fast_time (David S. Miller)
- Update APIC LVTERR fix to work correctly on
old 486/586 APICs (Mikael Pettersson)
- Check the return code of copy_{from,to}_user
on serial code (Rasmus Andersen)
- Mark 2.5 extended attributes system calls as
reserved to avoid potential conflicts (Nathan Scott)
- Change Christoph Hellwig's email address (Christoph Hellwig)
- Make BLKGETSIZE64 return size in bytes not
sectors (Eric Sandeen)
- Coda dentry revalidation fix (Jan Harkes)
- hisax_fcpcipnp driver update (Kai Germaschewski)
- i810 sound driver update (Doug Ledford)
- Early personality setting in binfmt_elf (Christoph Hellwig)
- Fix rename bug in reiserfs (Oleg Drokin)
- SCSI documentation update (Douglas Gilbert)
- Fix silly typo in megaraid driver (Arjan Van de Ven)
- PPC update (Benjamin Herrenschmidt)
- USB bug fixes (Greg KH)
- Fix devfs problems with removable devices (Richard Gooch)
- Merge -ac1 fixes (Alan Cox)
- VXFS update (Christoph Hellwig)
- Add Compaq FC array to the LUN whitelist (Arjan Van de Ven)
pre7:
- Make ext2/minix/sysvfs actually operate
synchronously on directories when using
the sync mount option (Andrew Morton)
- AFFS update (Roman Zippel)
- Fix 3dfx fb crash with high pixelclock (Jurriaan on Alpha)
- PATH_MAX POSIX compliance (Rusty Russell)
- Really apply AMD Elan patch (me)
- Don't drop IP packets with less than 8 bytes
of payload (David S. Miller)
- Netfilter update (Netfilter team)
- Backport 2.5 sb_bread() changes (Alexander Viro)
- Fix AF_UNIX fd leak (David S. Miller)
- Add Audigy Gameport PCI ID (Daniel Bertrand)
- Sync with ia64 arch independant parts (Keith Owens)
- APM fixes (Stephen Rothwell)
- fs/super.c cleanups (Alexander Viro)
pre6:
- Removed patch in icmp code: its
not needed and causes problems (me)
pre5:
- Include missing radeonfb defines (Erik Andersen)
- Fix fs/buffer.c thinko introduced in pre4 (Andrew Morton)
- USB bugfixes (Greg KH)
- Make fat work correctly with gcc-3.0.x (Tom Rini)
- Avoid overusage of the vmalloc area by
NTFS (Anton Altaparmakov)
- atyfb: Decrease clock rate for 3d RAGE XL (David S. Miller)
- Sungem driver bugfixes (David S. Miller)
- More networking updates (David S. Miller)
- More SPARC updates (David S. Miller)
- devfs update (Richard Gooch)
- Reiserfs expanding truncate fix (Chris Mason)
- ext3 update (Andrew Morton/Stephen Tweedie)
- Add support to WDIOC_SETTIMEOUT on several
watchdog drivers (Joel Becker)
- dl2k driver update (Jeff Garzik)
- Orinoco driver update (David Gibson)
- Radeonfb driver update (Ani Joshi)
- Avoid free_swap_and_cache() from leaving
freeable pages on the cache (Hugh Dickins)
- Add workarounds for AMD Elan processors (Robert Schwebel)
- Random pmac driver bugfixing (Benjamin Herrenschmidt)
- emu10k1 driver update (Rui Sousa)
pre4:
- Networking updates (David S. Miller)
- clgenfb update (Jeff Garzik)
- 8139cp: make it faster (Jeff Garzik)
- 8139too: fix bugs, add experimental RX reset (Jeff Garzik)
- Add MII ethtool interface and change
several drivers to support that (Jeff Garzik)
- Fix ramdisk corruption problems (Andrea Arcangeli)
- Correct in-kernel MS_ASYNC behaviour
on msync/fsync() (Andrew Morton)
- Fix PLIP problems (Niels Jensen)
- Fix problems triggered by the "fsx test"
on smbfs (Urban Widmark)
- Turn on OOSTORE for IDT winchip (from -ac tree)
- Fix iphase crash (from -ac tree)
- Fix crash with two mxser cards (from -ac tree)
- Fix tty write block bug (from -ac tree)
- Add mono/stereo detect to gemtek pci radio (from -ac tree)
- Fix sf16fmi crash on load (from -ac tree)
- add CP1250 (windows eastern european)
translation table (from -ac tree)
- cs46xx driver update (from -ac tree)
- Fix rare data loss case with RAID-1 (Ingo Molnar)
- Add 2.5.x compatibility for the kdev_t
changes (me)
- SPARC updates (David S. Miller)
pre3:
- Cris arch merge (Bjorn Wesen)
- Finish PPC merge (Benjamin Herrenschmidt)
- Add Dell PowerEdge 2400 to
"use BIOS to reboot" blacklist (Arjan van de Ven)
- Avoid potential oops at module unload with
cyclades driver (Andrew Morton)
- Gracefully handle SCSI initialization
failures (Pete Zaitcev)
- USB update (Greg KH)
- Fix potential oops while ejecting ide cds (Zwane Mwaikambo)
- Unify page freeing codepaths (Benjamin LaHaise)
- Miata dma corruption workaround (Richard Henderson)
- Fix vmalloc corruption problem on machines
with virtual dcaches (Ralf Baechle)
- Reiserfs fixes (Oleg Drokin)
- DiskOnChip driver update (David Woodhouse)
- Do not inherit page locking rules across
fork/exec (Dave Anderson)
- Add DRM 4.0 for XFree 4.0 users convenience (Christoph Hellwig)
- Replace .text.lock with .subsection (Keith Owens)
- IrDA bugfixes (Jean Tourrilhes)
pre2:
- APIC LVTERR fixes (Mikael Pettersson)
- Fix ppdev ioctl oops and deadlock (Tim Waugh)
- parport fixes (Tim Waugh)
- orinoco wireless driver update (David Gibson)
- Fix oopsable race in binfmt_elf.c (Alexander Viro)
- Small sx16 driver bugfix (Heinz-Ado Arnolds)
- sbp2 deadlock fix (Andrew Morton)
- Fix JFFS2 write error handling (David Woodhouse)
- Intermezzo update (Peter J. Braam)
- Proper AGP support for Intel 830MP chipsets (Nicolas Aspert)
- Alpha fixes (Jay Estabrook)
- 53c700 SCSI driver update (James Bottomley)
- Fix coredump mmap_sem deadlock on IA64 (David Mosberger)
- 3ware driver update (Adam Radford)
- Fix elevator insertion point on failed
request merge (Jens Axboe)
- Remove bogus rpciod_tcp_dispatcher definition (David Woodhouse)
- Reiserfs fixes (Oleg Drokin)
- de4x5 endianess fixes (Kip Walker)
- ISDN CAPI cleanup (Kai Germaschewski)
- Make refill_inactive() correctly account
progress (me)
pre1:
- S390 merge (IBM)
- SuperH merge (SuperH team)
- PPC merge (Benjamin Herrenschmidt)
- PCI DMA update (David S. Miller)
- radeonfb update (Ani Joshi)
- aty128fb update (Ani Joshi)
- Add nVidia GeForce3 support to rivafb (Ani Joshi)
- Add PM support to opl3sa2 (Zwane Mwaikambo)
- Basic ethtool support for 3com, starfire
and pcmcia net drivers (Jeff Garzik)
- Add MII ethtool interface (Jeff Garzik)
- starfire,sundance,dl2k,sis900,8139{too,cp},
natsemi driver updates (Jeff Garzik)
- ufs/minix: mark inodes as bad in case of read
failure (Christoph Hellwig)
- ReiserFS fixes (Oleg Drokin)
- sonypi update (Stelian Pop)
- n_hdlc update (Paul Fulghum)
- Fix compile error on aty_base.c (Tobias Ringstrom)
- Document cpu_to_xxxx() on kernel-hacking doc (Rusty Russell)
- USB update (Greg KH)
- Fix sysctl console loglevel bug on
IA64 (and possibly other archs) (Jesper Juhl)
- Update Athlon/VIA PCI quirks (Calin A. Culianu)
- blkmtd update (Simon Evans)
- boot protocol update (makes the highest
possible initrd address available to the
bootloader) (H. Peter Anvin)
- NFS fixes (Trond Myklebust)
Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
2.4.19-pre1 will contain it.
On Mon, 25 Feb 2002, Marcelo Tosatti wrote:
>
> Hi,
>
> Finally, 2.4.18. No changes between it and -rc4.
>
>
> final:
>
> - No changes have been made between -final
> and -rc4.
>
> rc4:
>
> - Load code did not set personality for
> binaries without an interpreter: This was
> breaking static apps on several archs (Tom Gall)
On Mon, 25 Feb 2002, Marcelo Tosatti wrote:
>
> Finally, 2.4.18. No changes between it and -rc4.
>
> final:
>
> - No changes have been made between -final
> and -rc4.
>
> rc4:
>
> - Load code did not set personality for
> binaries without an interpreter: This was
> breaking static apps on several archs (Tom Gall)
Am I imagining it, or has this -rc4 fix gone missing in final?
Hugh
On Mon, 25 Feb 2002, Hugh Dickins wrote:
> On Mon, 25 Feb 2002, Marcelo Tosatti wrote:
> >
> > Finally, 2.4.18. No changes between it and -rc4.
> >
> > final:
> >
> > - No changes have been made between -final
> > and -rc4.
> >
> > rc4:
> >
> > - Load code did not set personality for
> > binaries without an interpreter: This was
> > breaking static apps on several archs (Tom Gall)
>
> Am I imagining it, or has this -rc4 fix gone missing in final?
Indeed you are right: The fix is missing.
> Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
>
> 2.4.19-pre1 will contain it.
Should 2.4.18 final get a -dontuse tag or something? Some people may get
confused grabbing 2.4.18 and not getting the fixes that went into rc-4?
Just a thought...
Thanks
Bruce H.
On Mon, 25 Feb 2002, Holzrichter, Bruce wrote:
>
>
> > Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
> >
> > 2.4.19-pre1 will contain it.
>
> Should 2.4.18 final get a -dontuse tag or something?
No. A "-dontuse" tag should be only used when the kernel can cause damage
in some way.
The patch which I missed only breaks static apps on _some_ architectures
(not including x86).
> Some people may get confused grabbing 2.4.18 and not getting the fixes
> that went into rc-4? Just a thought...
I already changed ftp.kernel.org's changelog adding:
"Update: The SET_PERSONALITY fix in rc4 has _not_
been included in the final 2.4.18 by mistake."
I guess thats enough.
In article <[email protected]> you wrote:
> Should 2.4.18 final get a -dontuse tag or something? Some people may get
> confused grabbing 2.4.18 and not getting the fixes that went into rc-4?
> Just a thought...
90 percent or more of the Linux users couldn't care less for the missing
hunk (as it doesn't affect i386).
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Monday 25 February 2002 20:18, Marcelo Tosatti wrote:
> On Mon, 25 Feb 2002, Holzrichter, Bruce wrote:
> > > Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
> > >
> > > 2.4.19-pre1 will contain it.
> >
> > Should 2.4.18 final get a -dontuse tag or something?
>
> No. A "-dontuse" tag should be only used when the kernel can cause damage
> in some way.
>
> The patch which I missed only breaks static apps on _some_ architectures
> (not including x86).
>
> > Some people may get confused grabbing 2.4.18 and not getting the fixes
> > that went into rc-4? Just a thought...
>
> I already changed ftp.kernel.org's changelog adding:
>
> "Update: The SET_PERSONALITY fix in rc4 has _not_
> been included in the final 2.4.18 by mistake."
>
> I guess thats enough.
Wouldn't it be easier just to make a new 2.4.18 with the patch applied?
Just to make all our lives a bit easier...
DK
On Mon, 25 Feb 2002, DevilKin wrote:
> On Monday 25 February 2002 20:18, Marcelo Tosatti wrote:
> > On Mon, 25 Feb 2002, Holzrichter, Bruce wrote:
> > > > Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
> > > >
> > > > 2.4.19-pre1 will contain it.
> > >
> > > Should 2.4.18 final get a -dontuse tag or something?
> >
> > No. A "-dontuse" tag should be only used when the kernel can cause damage
> > in some way.
> >
> > The patch which I missed only breaks static apps on _some_ architectures
> > (not including x86).
> >
> > > Some people may get confused grabbing 2.4.18 and not getting the fixes
> > > that went into rc-4? Just a thought...
> >
> > I already changed ftp.kernel.org's changelog adding:
> >
> > "Update: The SET_PERSONALITY fix in rc4 has _not_
> > been included in the final 2.4.18 by mistake."
> >
> > I guess thats enough.
>
> Wouldn't it be easier just to make a new 2.4.18 with the patch applied?
>
> Just to make all our lives a bit easier...
Having two 2.4.18's is a bit of a mess for the ftp.kernel.org mirroring
system.
Marcelo Tosatti <[email protected]> writes:
> Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
>
> 2.4.19-pre1 will contain it.
Why not just immediately release 2.4.19 with only the -rc4 patch?
There's no harm done in an extra release.
Dan
> Wouldn't it be easier just to make a new 2.4.18 with the patch applied?
>
> Just to make all our lives a bit easier...
Nope. It would not.
~~~
Yust remove the three lines yourself.
--tg
On 25 Feb 2002, Daniel Quinlan wrote:
> Marcelo Tosatti <[email protected]> writes:
>
> > Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
> >
> > 2.4.19-pre1 will contain it.
>
> Why not just immediately release 2.4.19 with only the -rc4 patch?
> There's no harm done in an extra release.
Its not critical enough I think.
Looks like its fixed.
[root@war root]# cd /usr/src/linux-2.4.18
[root@war linux-2.4.18]# patch -p1 < ../linux-2.4.18
linux-2.4.18 linux-2.4.18.tar.bz2
[root@war linux-2.4.18]# patch -p1 < ../patch-2.4.18-rc4
patching file CREDITS
Reversed (or previously applied) patch detected! Assume -R? [n]
On Mon, Feb 25, 2002 at 04:13:21PM -0500, Justin Piszcz wrote:
> Looks like its fixed.
>
> [root@war root]# cd /usr/src/linux-2.4.18
> [root@war linux-2.4.18]# patch -p1 < ../linux-2.4.18
> linux-2.4.18 linux-2.4.18.tar.bz2
> [root@war linux-2.4.18]# patch -p1 < ../patch-2.4.18-rc4
> patching file CREDITS
> Reversed (or previously applied) patch detected! Assume -R? [n]
Only 1 chunk got dropped, not all of rc4.
Check the rc4-final diff in testing/incr/ and apply with -R
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
DevilKin> Wouldn't it be easier just to make a new 2.4.18 with the
DevilKin> patch applied?
Or just release 2.4.19 right away with the patch applied and start all
over again on 2.4.20-pre1 instead?
John
Dave- Thanks, I included that on my page.
http://installkernel.com/kernel/index.html
I hope I got the story right, and I hope this clears things up on 2.4.18.
Marcelo Tosatti <[email protected]> writes:
> - Fix netfilter race (Rusty Russell)
> - Correct error handling on tcp_recvmsg (Alexey Kuznetsov)
> - Revert tulip changes which were apparently
> causing slowdowns (Jeff Garzik)
> - Fix ptrace behaviour (Linus Benedict Torvalds)
Are any of these relevant, security-wise?
(The shmem_file_write() fix by Alan Cox is indeed.)
--
Florian Weimer [email protected]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
On Mon, Feb 25, 2002 at 04:29:38PM -0500, John Stoffel wrote:
>
> DevilKin> Wouldn't it be easier just to make a new 2.4.18 with the
> DevilKin> patch applied?
>
> Or just release 2.4.19 right away with the patch applied and start all
> over again on 2.4.20-pre1 instead?
>
You have got to be kidding me.
The only binaries that are affected are ones compiles without shared
libraries on some non-x86 arches, and anyone doing that should know what
they are doing and which kernels to use.
Does anyone know how long this bug has been in the kernel?
Mike
Justin Piszcz wrote:
> http://installkernel.com/kernel/index.html
> I hope I got the story right, and I hope this clears things up on 2.4.18.
That might be the most serious bug in this release: people and media reporting a "release problem".
How many people really need that small fix and are not able to take -rc4 instead final? Compared to 2.4.17, there are more than
100 fixes in this release, that could have been more dangerous than this missing function. And there might be still people out
there using 2.4.17 ;-)
--
[email protected]
Mike> You have got to be kidding me.
Not at all.
Mike> The only binaries that are affected are ones compiles without
Mike> shared libraries on some non-x86 arches, and anyone doing that
Mike> should know what they are doing and which kernels to use.
Mike> Does anyone know how long this bug has been in the kernel?
So what? What's the big deal of releasing a new version with just one
quick change? Marcello made a mistake, this seems to be the quickest
way to solve it in an unambiguous manner.
Who cares how fast the kernel version number moves up, or for what
reason?
I can see your point of view as well, but I still think your arguement
that "they should know what they are doing" is bogus.
But hey, whatever Marcello thinks is fine by me.
John
From: Mike Fedyk <[email protected]>
Date: Mon, 25 Feb 2002 13:54:52 -0800
Does anyone know how long this bug has been in the kernel?
For a very short period of time.
We can avoid this kind of mess in the future if the "-rc*" releases
really are "release candidates" instead of "just another diff".
Ie. they are done as patches _and_ tarballs, then the final can just
be done with a "cp" command.
That will make errors like this one more likely to be
caught.
On Mon, 2002-02-25 at 14:08, David S. Miller wrote:
>
> We can avoid this kind of mess in the future if the "-rc*" releases
> really are "release candidates" instead of "just another diff".
> Ie. they are done as patches _and_ tarballs, then the final can just
> be done with a "cp" command.
the problem with that is the top level Makefile still needs to be
changed. the last thing I want is to be running a 2.4.18-rc3 kernel and
have uname tell me it is 2.4.18.
-tduffy
From: Thomas Duffy <[email protected]>
Date: 25 Feb 2002 14:14:30 -0800
the problem with that is the top level Makefile still needs to be
changed. the last thing I want is to be running a 2.4.18-rc3 kernel and
have uname tell me it is 2.4.18.
I think the benefits of not screwing up the real release
are larger than this inconvenience.
As a side note I also think it's silly that we can't just "fix up"
when a slight error is made like this. In the worst possible case one
could make a real quick "2.4.18a" release that had things fixed.
Personally I'd just put fixed files up and say "sorry the original one
didn't have the holy penguin pee on it, this one does" and tell
people to simply cope.
David S. Miller wrote:
> We can avoid this kind of mess in the future if the "-rc*" releases
> really are "release candidates" instead of "just another diff".
And how should EXTRAVERSION be accommodated?
--
[email protected]
From: Rainer Ellinger <[email protected]>
Date: Mon, 25 Feb 2002 23:20:03 +0100
David S. Miller wrote:
> We can avoid this kind of mess in the future if the "-rc*" releases
> really are "release candidates" instead of "just another diff".
And how should EXTRAVERSION be accommodated?
It's empty, if it isn't empty then it really isn't a
"release candidate" since changes will be made now is
it? :-)
On 2002-02-25T14:16:50,
"David S. Miller" <[email protected]> said:
> I think the benefits of not screwing up the real release
> are larger than this inconvenience.
Well, I would suggest to have a second look at the final releases to check for
these minor issues; a second pair of eyes couldn't hurt.
> As a side note I also think it's silly that we can't just "fix up"
> when a slight error is made like this. In the worst possible case one
> could make a real quick "2.4.18a" release that had things fixed.
Yes.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
Followup to: <[email protected]>
By author: Marcelo Tosatti <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > Wouldn't it be easier just to make a new 2.4.18 with the patch applied?
> >
> > Just to make all our lives a bit easier...
>
> Having two 2.4.18's is a bit of a mess for the ftp.kernel.org mirroring
> system.
>
Not really. You can substitute a file and the mirror system should
handle it fine, *AS LONG AS THE FILE DATE IS CHANGED*.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
> Not really. You can substitute a file and the mirror system should
> handle it fine, *AS LONG AS THE FILE DATE IS CHANGED*.
It does. I've switched a few corrupt patches around from upload errors
before now. Just nobody noticed 8)
In article <[email protected]> you wrote:
> "Update: The SET_PERSONALITY fix in rc4 has _not_
> been included in the final 2.4.18 by mistake."
> I guess thats enough.
I dont understand why it is a problem to release 2.4.19 instead.
Greetings
Bernd
In article <[email protected]> you wrote:
> The only binaries that are affected are ones compiles without shared
> libraries on some non-x86 arches, and anyone doing that should know what
> they are doing and which kernels to use.
Sorry, I dont see a reason to treat any architecture different. And static
apps are quite common on install and rescue systems.
> Does anyone know how long this bug has been in the kernel?
What is so bad about releasing a final kernel which matches the RC? I mean we
could have the chance to do it with 2.4.19
Greetings
Bernd
On Mon, 25 Feb 2002, Rainer Ellinger wrote:
> David S. Miller wrote:
>
> >We can avoid this kind of mess in the future if the "-rc*" releases
> >really are "release candidates" instead of "just another diff".
>
> And how should EXTRAVERSION be accommodated?
sed/perl/awk -- a short five-liner "bless-rc-to-final" script should do.
A fixed procedure to just fix the Makefile, removing the -rc tag, and
copy over the stuff, can prevent that. If it's considered important
enough by the maintainer, of course.
From: Matthias Andree <[email protected]>
Date: Tue, 26 Feb 2002 00:01:56 +0100
> And how should EXTRAVERSION be accommodated?
sed/perl/awk -- a short five-liner "bless-rc-to-final" script should do.
Ummm... no.
This whole conversation exists because "Deleting the EXTRAVERSION
setting from linux/Makefile" then making new diffs/tars was screwed
up. Doing it with a script isn't going to help this kind of problem.
I repeat: it isn't a "release candidate" if it will not match preciely
what the final tarball/patches contains. Anything else opens up the
possibility for errors to be made.
On Mon, Feb 25, 2002 at 03:08:13PM -0800, David S. Miller wrote:
> I repeat: it isn't a "release candidate" if it will not match preciely
> what the final tarball/patches contains. Anything else opens up the
> possibility for errors to be made.
If the release candidates had identical version numbers, Marcelo could
still copy rc3 to final instead of rc4. So this doesn't solve anything,
it only adds some potential for confusion.
Release candidates only help if people use them and report errors. And
people who run rc kernels want to be able to use uname to find out which
kernel version is running.
So please keep EXTRAVERSION.
Jan
On Mon, 25 Feb 2002, David S. Miller wrote:
> From: Matthias Andree <[email protected]>
> Date: Tue, 26 Feb 2002 00:01:56 +0100
>
> > And how should EXTRAVERSION be accommodated?
>
> sed/perl/awk -- a short five-liner "bless-rc-to-final" script should do.
>
> Ummm... no.
>
> This whole conversation exists because "Deleting the EXTRAVERSION
> setting from linux/Makefile" then making new diffs/tars was screwed
> up. Doing it with a script isn't going to help this kind of problem.
>
> I repeat: it isn't a "release candidate" if it will not match preciely
> what the final tarball/patches contains. Anything else opens up the
> possibility for errors to be made.
I'd think that running a script to "upgrade" 2.4.N-rcM to 2.4.N by just
unpacking that latest rc tarball, editing the Makefile and tarring
things up again, should be safe enough, and if it doesn't allow for
operator interference, especially so.
I'd rather violate the "it's not a release candidate if it changes to
the final release" than have differing versions with the same tag
around, which would be a support nightmare. "Does the person who
reported this bug run the release candidate or the final version?" That
question is hard to answer if you cannot ask for uname -r, but end up
asking for the MD5sum of that tarball, and that still does not account
for patches, patches missed and patches applied -- Would you want that?
I would not.
I think that the coupling between tag and corresponding code should be
tighter than that of the release candidate to the release, but I don't
decide on this issue, Marcelo does.
--
Matthias Andree
GPG encrypted mail welcome, unless it's unsolicited commercial email.
Followup to: <[email protected]>
By author: "David S. Miller" <[email protected]>
In newsgroup: linux.dev.kernel
>
> From: Matthias Andree <[email protected]>
> Date: Tue, 26 Feb 2002 00:01:56 +0100
>
> > And how should EXTRAVERSION be accommodated?
>
> sed/perl/awk -- a short five-liner "bless-rc-to-final" script should do.
>
> Ummm... no.
>
> This whole conversation exists because "Deleting the EXTRAVERSION
> setting from linux/Makefile" then making new diffs/tars was screwed
> up. Doing it with a script isn't going to help this kind of problem.
>
Sure it would. It would make the likelihood for errors much lower.
You need to make tarballs anyway.
> I repeat: it isn't a "release candidate" if it will not match preciely
> what the final tarball/patches contains. Anything else opens up the
> possibility for errors to be made.
I think this is much too absolutist of an approach. There is *always*
a possibility for errors to happen, but automation can reduce the risk
a lot.
If Marcelo wants, I can write him a "bless" script that he can run
directly on master.kernel.org, which would make it trivial to avoid
error.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
From: "H. Peter Anvin" <[email protected]>
Date: 25 Feb 2002 15:34:14 -0800
> This whole conversation exists because "Deleting the EXTRAVERSION
> setting from linux/Makefile" then making new diffs/tars was screwed
> up. Doing it with a script isn't going to help this kind of problem.
>
Sure it would. It would make the likelihood for errors much lower.
You need to make tarballs anyway.
Part of my suggestion involved putting up tarballs in the RC
releases, perhaps you missed that bit :-)
John Stoffel <[email protected]> writes:
> DevilKin> Wouldn't it be easier just to make a new 2.4.18 with the
> DevilKin> patch applied?
>
> Or just release 2.4.19 right away with the patch applied and start all
> over again on 2.4.20-pre1 instead?
That would be the right thing to do.
--
Hilsen Harald.
Bernd Eckenfels <[email protected]> writes:
> I dont understand why it is a problem to release 2.4.19 instead.
Neither do I.
--
Hilsen Harald.
> Bernd Eckenfels <[email protected]> writes:
> > I dont understand why it is a problem to release 2.4.19 instead.
>
> Neither do I.
> --
> Hilsen Harald.
If, hypothetically speaking of course, one were to start downloading a
file that was a couple dozen megabytes in size and leave it going
overnight on their dial-up connection only to awake and find that they
had an outdated file, I could imagine them being quite pissed ;-)
At 05:20 PM 2/25/02, you wrote:
>David S. Miller wrote:
>
>>We can avoid this kind of mess in the future if the "-rc*" releases
>>really are "release candidates" instead of "just another diff".
>
>And how should EXTRAVERSION be accommodated?
An idea :-)
The actual release could be automated by a script that copies the release
candidate directory to a final directory, uses sed to correct EXTRAVERSION,
then creates the tarball. Using a script would ensure that EXTRAVERSION is
correctly handled and would create all necessary tarballs and signature files.
The "Kernel_Release" script would look something like:
mkdir /usr/src/linux-$1
( cd /usr/src/linux-$1-rc$2 ; tar cf - ) | ( cd /usr/src/linux-$1
; tar xf - )
sed s/EXTRAVERSION=.*/EXTRAVERSION/ <
/usr/src/linux-$1-rc$2/Makefile > /usr/src/linux-$1/Makefile
tar zcf linux-$1.tar.gz linux-$1
tar jcf linux-$1.tar.bz2 linux-$1
cp linux-$1.tar.gz linux-$1 jcf linux-$1.tar.bz2 linux-$1
ftp/pub/linux/kernel/v2.4
... whatever other magic is neded ...
On February 25, 2002 08:18 pm, Marcelo Tosatti wrote:
> On Mon, 25 Feb 2002, Holzrichter, Bruce wrote:
> > > Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
> > >
> > > 2.4.19-pre1 will contain it.
> >
> > Should 2.4.18 final get a -dontuse tag or something?
>
> No. A "-dontuse" tag should be only used when the kernel can cause damage
> in some way.
That reminds me, why did 2.4.15 never get a -dontuse? Did the iput bugfix
get quietly added, or is it still an accident waiting to happen?
I think there'a a limit to how strict one should be about the 'don't change
it after posting rule'.
--
Daniel
On February 25, 2002 08:31 pm, Marcelo Tosatti wrote:
> On Mon, 25 Feb 2002, DevilKin wrote:
> > On Monday 25 February 2002 20:18, Marcelo Tosatti wrote:
> > > On Mon, 25 Feb 2002, Holzrichter, Bruce wrote:
> > > > > Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that.
> > > > >
> > > > > 2.4.19-pre1 will contain it.
> > > >
> > > > Should 2.4.18 final get a -dontuse tag or something?
> > >
> > > No. A "-dontuse" tag should be only used when the kernel can cause damage
> > > in some way.
> > >
> > > The patch which I missed only breaks static apps on _some_ architectures
> > > (not including x86).
> > >
> > > > Some people may get confused grabbing 2.4.18 and not getting the fixes
> > > > that went into rc-4? Just a thought...
> > >
> > > I already changed ftp.kernel.org's changelog adding:
> > >
> > > "Update: The SET_PERSONALITY fix in rc4 has _not_
> > > been included in the final 2.4.18 by mistake."
> > >
> > > I guess thats enough.
> >
> > Wouldn't it be easier just to make a new 2.4.18 with the patch applied?
> >
> > Just to make all our lives a bit easier...
>
> Having two 2.4.18's is a bit of a mess for the ftp.kernel.org mirroring
> system.
That suggests the mirroring system is flawed. It should be possible to
do a quick cancel on an upload, much as with a usenet post. Not that it
should become a habit of course, but it seems something's missing. We've
had a number of events this year where a cancel would have saved a lot of
confusion and handwringing.
--
Daniel
On February 24, 2002 06:20 am, Daniel Phillips wrote:
> On February 25, 2002 08:31 pm, Marcelo Tosatti wrote:
> > Having two 2.4.18's is a bit of a mess for the ftp.kernel.org mirroring
> > system.
>
> That suggests the mirroring system is flawed. It should be possible to
> do a quick cancel on an upload, much as with a usenet post. Not that it
> should become a habit of course, but it seems something's missing. We've
> had a number of events this year where a cancel would have saved a lot of
> confusion and handwringing.
Reading ahead, I see this is already handled by manipulating the file date,
cancel the cancel suggestion please ;)
--
Daniel
On Feb 25, 2002 19:28 -0500, Eric Krout wrote:
> > Bernd Eckenfels <[email protected]> writes:
> > > I dont understand why it is a problem to release 2.4.19 instead.
>
> If, hypothetically speaking of course, one were to start downloading a
> file that was a couple dozen megabytes in size and leave it going
> overnight on their dial-up connection only to awake and find that they
> had an outdated file, I could imagine them being quite pissed ;-)
Well, that's what incremental patches are for.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Tue, 26 Feb 2002, Matthias Andree wrote:
> I'd think that running a script to "upgrade" 2.4.N-rcM to 2.4.N by just
> unpacking that latest rc tarball, editing the Makefile and tarring
> things up again, should be safe enough, and if it doesn't allow for
> operator interference, especially so.
Seems to me:
- clean EXTRAVERSION
- make new diff
- make tar (one please)
- make tar.gz from tar
- compress tar to tar.bz2
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Followup to: <[email protected]>
By author: Bill Davidsen <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Tue, 26 Feb 2002, Matthias Andree wrote:
>
> > I'd think that running a script to "upgrade" 2.4.N-rcM to 2.4.N by just
> > unpacking that latest rc tarball, editing the Makefile and tarring
> > things up again, should be safe enough, and if it doesn't allow for
> > operator interference, especially so.
>
> Seems to me:
> - clean EXTRAVERSION
> - make new diff
> - make tar (one please)
> - make tar.gz from tar
> - compress tar to tar.bz2
>
For what it's worth, I have written such a script and made it
available on master.kernel.org. The kernel maintainers have been sent
directions; it's of course up to them if they want to use it.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Tue, 26 Feb 2002, Bill Davidsen wrote:
> On Tue, 26 Feb 2002, Matthias Andree wrote:
>
> > I'd think that running a script to "upgrade" 2.4.N-rcM to 2.4.N by just
> > unpacking that latest rc tarball, editing the Makefile and tarring
> > things up again, should be safe enough, and if it doesn't allow for
> > operator interference, especially so.
>
> Seems to me:
> - clean EXTRAVERSION
> - make new diff
Correct, I forgot about this item -- but it's a longer distance, from
2.4.N-1 to 2.4.N. Thank you.
> - make tar (one please)
> - make tar.gz from tar
> - compress tar to tar.bz2
>>>>> "david" == David S Miller <[email protected]> writes:
Hi
david> We can avoid this kind of mess in the future if the "-rc*" releases
david> really are "release candidates" instead of "just another diff".
david> Ie. they are done as patches _and_ tarballs, then the final can just
david> be done with a "cp" command.
No, think of EXTRAVERSION.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
On Mon, 25 Feb 2002 16:18:46 -0300 (BRT)
Marcelo Tosatti <[email protected]> wrote:
> [...]
> The patch which I missed only breaks static apps on _some_ architectures
> (not including x86).
This statement is not very nice. You obviously classify these architectures as minor important. At least not important enough to give them a release version as bugfree as possible at the given time. You shouldn't do that, don't focus on what you classify the "mainstream" too much.
As stated before, there is no problem with making mistakes. You only have to handle the situation in an intelligent manner _and_ aware of the power given to you.
In my eyes, the clean choice would have been 2.4.19 release.
> > Some people may get confused grabbing 2.4.18 and not getting the fixes
> > that went into rc-4? Just a thought...
>
> I already changed ftp.kernel.org's changelog adding:
>
> "Update: The SET_PERSONALITY fix in rc4 has _not_
> been included in the final 2.4.18 by mistake."
>
> I guess thats enough.
Technically correct, but intentionally questionable.
Regards,
Stephan
On Tue, 26 Feb 2002, Stephan von Krawczynski wrote:
> In my eyes, the clean choice would have been 2.4.19 release.
Then make one.
It's just too easy for people to critisise marcelo without
realising how much work he's putting into 2.4.
Rik
--
Will hack the VM for food.
http://www.surriel.com/ http://distro.conectiva.com/
On Tue, 26 Feb 2002 14:13:05 -0300 (BRT)
Rik van Riel <[email protected]> wrote:
> On Tue, 26 Feb 2002, Stephan von Krawczynski wrote:
>
> > In my eyes, the clean choice would have been 2.4.19 release.
>
> Then make one.
>
> It's just too easy for people to critisise marcelo without
> realising how much work he's putting into 2.4.
This comment was suboptimal, Rik.
There is a group of people that can _make_ one, but there is only one that can _release_ it.
No need to discuss if I am a member of the group, but for sure neither me nor you are _the one_.
So we both can do no more than state our personal opinions on the matter.
Some more thoughts while I am at it:
It is the nature of critics to focus on small bits of the picture. That does not mean the whole picture is teared down just from criticising _some part_ of it.
It is the nature of critics that you can always learn something from it. If it is not about the underlying matter it is at least about the person speaking up.
And: please keep in mind that there are (at least) two major groups in this list: one consisting of people getting paid from distro-(and other-)companies to do something useful about linux - and one consisting of people _not_ getting paid for it. It is very obvious that the lines-of-code-for-patches from single heads inside the second group may be a bit less than from the first. This is not necessarily related to the respective persons' knowledge about linux and related issues.
Regards,
Stephan
> Rik
> --
> Will hack the VM for food.
I see, you know what I am talking about.
Am Dienstag, 26. Februar 2002 17:46:17 schrieb Stephan von Krawczynski:
> On Mon, 25 Feb 2002 16:18:46 -0300 (BRT)
>
> Marcelo Tosatti <[email protected]> wrote:
> > [...]
> > The patch which I missed only breaks static apps on _some_ architectures
> > (not including x86).
>
> This statement is not very nice. You obviously classify these architectures
> as minor important. At least not important enough to give them a release
> version as bugfree as possible at the given time. You shouldn't do that,
> don't focus on what you classify the "mainstream" too much. As stated
> before, there is no problem with making mistakes. You only have to handle
> the situation in an intelligent manner _and_ aware of the power given to
> you. In my eyes, the clean choice would have been 2.4.19 release.
> [...]
> Regards,
> Stephan
Mhm, I'm not a kernel developer but I think that people how need the newest
kernel can also use a patch. In this case 2.4.19 pre1 which doesn't need much
time.
So I see no Problem.
I think Marcelo does his work well.
If anyone needs a new kernel, your dist will have well tested working kernels
for your arch.
If a person has a special arch, he must know how to patch a kernel.
So there is no need to make special things for __any__ architecture.
The final release is fine and very usefull, but if you have problems with it,
you should be able to use the pre versions from the next release.
I only write this, because I don't like it that people say: The 2.4.x is too
buggy, you miss some of the other archs, I need a wallpaper in the background
of my xconfig.
I am a user, I make mistakes with the configuration of the kernel.
I use new kernel, but if something goes wrong I know that it's my fault,
because I don't want to wait.
Mhm, should be enough ;)
thanks for all people who work on Open Source products
have fun
Felix Seeger
On Tue, 26 Feb 2002, Felix Seeger wrote:
> If anyone needs a new kernel, your dist will have well tested working kernels
> for your arch.
That's not possible, honestly. Any application of the adjectives "new" and
"well tested" to the same noun is an oxymoron.
If someone needs a new kernel they have to go to the bleeding edge,
otherwise what they need is an "upgrade," and it's not the same thing. By
the time a responsible vendor releases a kernel it is in no way new, nor
should it be.
Is you need stability and timelyness, go to vendors of -ac, -aa, -jam,
etc. Or similar, I'm not deliberately leaving anyone out, just that those
are kernels I have run on non-critical but production servers, because I
NEED the performance kick or the lockup fix.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.