Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 11:39:01PM -0500, Joey Hess wrote: > Thiemo Seufer wrote: > > It will AFAICS break all remaining d-i with 2.4 because those try to > > install a 2.4 kernel from testing by default. > > > > Frans, Joey, what is your opinion about this? > > I suppose it's a good reason to do a d-i release w/o 2.4 before dropping > the kernel. (The GPL is another good reason..) > > I hadn't planned to do it that way, and I'd still like to see a decision > that the kernel really is about to be dropped before removing it from > d-i. Who should in your opinion take that decision ? I mean, it has been some time now since the kernel team announced the 2.4 obsolescence, and that it would be removed soonishly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367570: unknown symbols in sound modules
* Frederik Schueler wrote: > On Tue, May 16, 2006 at 04:47:43PM -0500, martin f krafft wrote: > > After the upgrade to 2.6.16 (from 2.6.15), I started seeing the > > following errors during boot: > > rerunning alsaconf fixes this. No, it doesn't, I'm still seeing these errors during boot after rerunning alsaconf. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Thiemo Seufer wrote: > It will AFAICS break all remaining d-i with 2.4 because those try to > install a 2.4 kernel from testing by default. > > Frans, Joey, what is your opinion about this? I suppose it's a good reason to do a d-i release w/o 2.4 before dropping the kernel. (The GPL is another good reason..) I hadn't planned to do it that way, and I'd still like to see a decision that the kernel really is about to be dropped before removing it from d-i. -- see shy jo signature.asc Description: Digital signature
Bug#100421: pat hysler
Hi, pat hysler Rifill for pat hysler is ready. Please re-confirm your Data. http://geocities.com/AugustaLindsay254 The Buyer as per our records: pat hysler your info if wrong order please help us to correct it Just visit our site above to make sure. Sincerely, Penny -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 12:26:40AM +0200, Frans Pop wrote: > On Wednesday 17 May 2006 20:53, Sven Luther wrote: > > We have metapackages in place, which i believe will take charge of > > upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any > > kernel upgrade, will need a reboot, which is not without risk, but > > which we should hopefully have ironed out all the major problems by the > > time of the etch release, so it should be made to be painless (or > > documented in the release notes). > > Upgrading from 2.4 to 2.6 is absolutely not trivial in a lot of cases. See > the Sarge release notes for some potential issues users may face. Well, ok, so we already have a somehwat complete list of issues that the user can face. Contrary to woody->sarge migration though, where 2.6 kernels where not the default, we are facing another issue here, and we should take the time to clearly investigate all those migration problems, and offer a more detailed set of instructions, or even better, some automated way to do it. Naturally, udev is a mess, even in the case of 2.6->2.6 upgrades, and we don't need to handle the case of self built kernels, as the user will probably know how to handle the upgrade and o it by hand. We should do a massive upgrade testing from between the freeze and the release, and provide the best possible way for this. The : You are therefore strongly advised not to upgrade to a 2.6 kernel as part of the upgrade from woody to sarge. Instead, you should first make sure your system works correctly with either the old kernel or with a 2.4 kernel from sarge and do the upgrade to a 2.6 kernel later as a separate project. part of the release note, is not something we can consider now, so this makes a seamless upgrade all the more important. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Frans Pop wrote: [snip] > IMO the question whether 2.4 should be removed now and if so for which > architectures is something to be decided between the kernel team and > porters. > If a porter needs more time to switch to 2.6 for the installer, he should > probably come up with a migration plan and timeline. > > Purely from a d-i release management point of view, it would be nice if > the removal of 2.4 could be delayed until just after the next beta > release. The release date for that depends on the progress of AMD64 > archive migration (it is not yet installable from testing). Switching d-i reqires stable kernels for all subarchitectures, those are now mostly done for mips/mipsel. I hope we complete the move to 2.6 in 3-6 weeks. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 12:24:57AM +0200, Frans Pop wrote: > I could also understand if m68k would keep a 2.4 kernel for a while > longer. As it is not a release arch, it might be acceptable for release > managers to keep a m68k 2.4 kernel in testing/unstable. > 2.2 should probably be dropped completely. > Whether we will be able to keep 2.4 support in d-i if all other > architectures have dropped it is uncertain though [1]. The m68k porters just had a discussion about this and we're fine with whatever ya'll decide to do. We can always keep some unofficial kernels and installers around if necessary. In other words, don't worry about holding on to any kernels just for us. I hope to keep some 2.4 and 2.2 support in d-i until we get everything moved, but I'll try to keep it out of the way or in a branch. -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#365077: linux-2.6: The problem got solved with one of the recent versions
Package: linux-2.6 Followup-For: Bug #365077 The problem vanished with one of the recent versions of the kernel-image packages, I cannot reproduce it with 2.6.16-12. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wednesday 17 May 2006 20:53, Sven Luther wrote: > We have metapackages in place, which i believe will take charge of > upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any > kernel upgrade, will need a reboot, which is not without risk, but > which we should hopefully have ironed out all the major problems by the > time of the etch release, so it should be made to be painless (or > documented in the release notes). Upgrading from 2.4 to 2.6 is absolutely not trivial in a lot of cases. See the Sarge release notes for some potential issues users may face. pgpJ4fZ8UWcbc.pgp Description: PGP signature
Re: removing 2.4 from etch/sid
On Wednesday 17 May 2006 22:12, Thiemo Seufer wrote: > It will AFAICS break all remaining d-i with 2.4 because those try to > install a 2.4 kernel from testing by default. Yes, installs will break to some degree. If no 2.4 kernel is available, d-i will display a list of other available kernels (probably 2.6). However, crossinstalling kernel versions (i.e. installing running 2.4 setting up target with 2.6) is not really supported. It will probably lead to errors and at least some packages incorrectly installed or missing. Full CD installs are of course not affected. IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Full CD installations using that release could then still install 2.4 and we could set completing switches to 2.6 as the main goal for d-i Etch RC1. I could also understand if m68k would keep a 2.4 kernel for a while longer. As it is not a release arch, it might be acceptable for release managers to keep a m68k 2.4 kernel in testing/unstable. 2.2 should probably be dropped completely. Whether we will be able to keep 2.4 support in d-i if all other architectures have dropped it is uncertain though [1]. Cheers, FJP [1] This depends mainly on changes needed to support persistent device naming in d-i which is very much needed for Etch. pgpizERxY1ONi.pgp Description: PGP signature
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
> d-i is currently paying (at least some) attention to amiga, atari, > q40, *vme*, and mac. > > Of those, only amiga seems to be ready for a full switch to 2.6. mac > works on some hardware. That's been my impression. Christian has been working on 2.6 for Atari lately though. > To my knowledge *vme* and atari don't have large followings. Although > we do have buildds running for those subarchs, I believe they are Buildds are running _on_ Atari. not for Atari :-) > running with custom kernels anyway. Atari requires patches not in the > kernel packages as I recall. IIRC 2.4.30 worked pretty much out of the box except for the serial driver (which is crucial for networking ATM). On _my_ CT60 I had to hack a bit more, but I guess I'm the only one with the CT60 installed on top of a 030 clock booster :-) 2.4 for stock Atari and even CT60 on stock Falcon should work out of the box. > So, as long as we're not dropping full support for 2.4 in other > subsystems, I don't see a problem. Right. What subsystems might be affected? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 07:18:11AM -0500, Bill Allombert wrote: > On Tue, May 16, 2006 at 05:04:00PM -0500, dann frazier wrote: > > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > > object to a filing of bugs to remove these packages from etch? > > > > Developers at DebConf have pointed out to me that removing these > > packages would help avoid confusion/unnecessary bug reports. > > > > The rough consensus was also to continue to support systems for which > > users have compiled their own 2.4 - if we proceed with this removal, > > we might ask the release team to explicitly note this in a d-d-a > > e-mail so that package maintainers do not break 2.4 support if possible. > > How do you plan to handle upgrade from sarge for users that are running > 2.4 kernel ? What should the release note say about that? We have metapackages in place, which i believe will take charge of upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any kernel upgrade, will need a reboot, which is not without risk, but which we should hopefully have ironed out all the major problems by the time of the etch release, so it should be made to be painless (or documented in the release notes). If the user had installed a 2.4 kernel without using the metapackages, then his kernel will not be upgraded, as was his express wish, and all is fine for everybody. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
On Wed, May 17, 2006 at 01:03:13PM +0200, Christian T. Steigies wrote: > Does any m68k subarch still need a 2.4 kernel? d-i is currently paying (at least some) attention to amiga, atari, q40, *vme*, and mac. Of those, only amiga seems to be ready for a full switch to 2.6. mac works on some hardware. We've never really supported q40, so that's not a loss. mac doesn't work with 2.4, anyway. To my knowledge *vme* and atari don't have large followings. Although we do have buildds running for those subarchs, I believe they are running with custom kernels anyway. Atari requires patches not in the kernel packages as I recall. So, as long as we're not dropping full support for 2.4 in other subsystems, I don't see a problem. Any one else? Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
* Sven Luther <[EMAIL PROTECTED]> [2006-05-17 15:53]: > > In general, imho 2.4 should be removed from d-i first for each arch, > > and then after the next beta the 2.4 kernel images can be removed. We > > can start with the removal of 2.4 from those architectures which no > > longer use 2.4 at all (e.g. powerpc). > > Notice that we are not asking removal from d-i, but from the archive > completely. I know, but that'll probably break d-i. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: > * dann frazier <[EMAIL PROTECTED]> [2006-05-16 17:04]: > > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > > object to a filing of bugs to remove these packages from etch? > > For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. > It's getting close though, but in the meantime I'd like to keep 2.4. > > For arm, I've recently removed the last bits of 2.4 from d-i and I was > going to request the removal after the next d-i beta. > > In general, imho 2.4 should be removed from d-i first for each arch, > and then after the next beta the 2.4 kernel images can be removed. We > can start with the removal of 2.4 from those architectures which no > longer use 2.4 at all (e.g. powerpc). Notice that we are not asking removal from d-i, but from the archive completely. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367570: unknown symbols in sound modules
also sprach Frederik Schueler <[EMAIL PROTECTED]> [2006.05.17.0633 -0500]: > > After the upgrade to 2.6.16 (from 2.6.15), I started seeing the > > following errors during boot: > > rerunning alsaconf fixes this. Fair enough, I am willing to try this, but I've never run alsaconf before; things have just worked out of the box. How am I supposed to know to run alsaconf? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP)
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
On Wed, May 17, 2006 at 07:51:32PM +0200, Michael Schmitz wrote: > > running with custom kernels anyway. Atari requires patches not in the > > kernel packages as I recall. > > IIRC 2.4.30 worked pretty much out of the box except for the serial driver > (which is crucial for networking ATM). On _my_ CT60 I had to hack a bit > more, but I guess I'm the only one with the CT60 installed on top of a 030 > clock booster :-) 2.4 for stock Atari and even CT60 on stock Falcon should > work out of the box. Isn't that stock 2.4.31 or something? I'm not sure that is what is in the 2.4.27 debian packages. (I could easily be wrong though. ;) > > So, as long as we're not dropping full support for 2.4 in other > > subsystems, I don't see a problem. > > Right. What subsystems might be affected? I think I've heard glibc wants to drop some cruft. I'm sure there are others. -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Processed: tagging 352434
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.19 > tags 352434 pending Bug#352434: tmpfs for /dev is ram/2 There were no tags set. Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel bug 2.4.27 (inode.c)?
Hi developers, please to meet you and congratats you for your great work. Let's go in my question. I have one box Intel(R) Xeon(TM) 1 CPU 3.06GHz (HT), 2gb ram and one SCSI storage controller QLogic Corp. QLA2200 64-bit Fibre Channel Adapter running debian stable (2.4.27 SMP) more Debian HBA Patch actuating like one Network Area Storage (NAS). This server shares theerteen volumes for more of the ninety clients via nfs with the XFS like filesystem. Well in the last days I needed to reboot this box because nfs server is stoping to work and I got the follow messages in '/var/log/messages'. --- May 10 04:30:29 linpro367nas kernel: printing eip: May 10 04:30:29 linpro367nas kernel: c023bd2a May 10 04:30:29 linpro367nas kernel: Oops: May 10 04:30:29 linpro367nas kernel: CPU:0 May 10 04:30:29 linpro367nas kernel: EIP:0010:[linvfs_dentry_to_fh+42/160] Not tainted May 10 04:30:29 linpro367nas kernel: EFLAGS: 00010202 May 10 04:30:29 linpro367nas kernel: eax: ebx: 000d ecx: dc315ba0 edx: dc315 b80 May 10 04:30:29 linpro367nas kernel: esi: f6221d30 edi: f6221cf0 ebp: f6221cb8 esp: f6221 cb8 May 10 04:30:29 linpro367nas kernel: ds: 0018 es: 0018 ss: 0018 May 10 04:30:29 linpro367nas kernel: Process nfsd (pid: 389, stackpage=f6221000) May 10 04:30:29 linpro367nas kernel: Stack: c9042da0 f6221cf0 c0148a21 f6221d20 ea0727 60 f6221d30 c03b9f00 May 10 04:30:29 linpro367nas kernel:c01a70cc ea072760 f6221d30 f6221cf0 0001 dc315b a0 000d f5ee0b40 May 10 04:30:29 linpro367nas kernel:ea072760 f616c204 f34b7232 c01b1bd5 f6221d20 f5e278 00 ea072760 f616c204 May 10 04:30:29 linpro367nas kernel: Call Trace:[lookup_hash+65/224] [fh_compose+380/848] [ encode_entry+341/608] [nfs3svc_encode_entry_plus+37/48] [linvfs_readdir+373/528] May 10 04:30:29 linpro367nas kernel: [vfs_readdir+147/224] [nfs3svc_encode_entry_plus+0/48] [ nfsd_readdir+184/400] [nfs3svc_encode_entry_plus+0/48] [nfsd3_proc_readdirplus+184/320] [nfs3sv c_encode_entry_plus+0/48] May 10 04:30:29 linpro367nas kernel: [nfsd_dispatch+169/432] [svc_process+872/1441] [nfsd+510 /880] [arch_kernel_thread+35/48] [nfsd+0/880] May 10 04:30:29 linpro367nas kernel: May 10 04:30:29 linpro367nas kernel: Code: 8b 40 08 55 8b 4a 14 51 ff 50 50 8b 44 24 10 83 fb 0 3 89 06 May 17 09:17:11 linpro367nas kernel: kernel BUG at inode.c:1238! May 17 09:17:11 linpro367nas kernel: invalid operand: May 17 09:17:11 linpro367nas kernel: CPU:1 May 17 09:17:11 linpro367nas kernel: EIP:0010:[iput+258/784]Not tainted May 17 09:17:11 linpro367nas kernel: EFLAGS: 00010202 May 17 09:17:11 linpro367nas kernel: eax: cf006700 ebx: cf006660 ecx: 0001 edx: 0 003 May 17 09:17:11 linpro367nas kernel: esi: edi: c03b9f00 ebp: f5ede000 esp: f5edf ef8 May 17 09:17:11 linpro367nas kernel: ds: 0018 es: 0018 ss: 0018 May 17 09:17:11 linpro367nas kernel: Process nfsd (pid: 366, stackpage=f5edf000) May 17 09:17:11 linpro367nas kernel: Stack: e4f971e0 e4f97270 c0149ec9 cf006660 e4f971 e0 dfe57260 f6187c04 May 17 09:17:11 linpro367nas kernel:edb6dd40 c01a9f3e e4f971e0 edb6dd40 e4f971e0 f61b00 00 000a f6187c94 May 17 09:17:11 linpro367nas kernel:f6187c04 c01aeae7 f6187e00 f6187c04 c000 e2cce0 a8 000a f6187e00 May 17 09:17:11 linpro367nas kernel: Call Trace:[vfs_unlink+329/560] [nfsd_unlink+254/496] [nfsd3_proc_remove+103/208] [nfsd_dispatch+169/432] [svc_process+872/1441] May 17 09:17:11 linpro367nas kernel: [nfsd+510/880] [arch_kernel_thread+35/48] [nfsd+0/880] May 17 09:17:11 linpro367nas kernel: May 17 09:17:11 linpro367nas kernel: Code: 0f 0b d6 04 d8 08 36 c0 89 5c 24 10 5b 5e 5f e9 0a e 6 ff ff --- What can I do to fix this problem? Tks. -- Renan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 03:59:40PM +0200, Martin Michlmayr wrote: > * Sven Luther <[EMAIL PROTECTED]> [2006-05-17 15:53]: > > > In general, imho 2.4 should be removed from d-i first for each arch, > > > and then after the next beta the 2.4 kernel images can be removed. We > > > can start with the removal of 2.4 from those architectures which no > > > longer use 2.4 at all (e.g. powerpc). > > > > Notice that we are not asking removal from d-i, but from the archive > > completely. > > I know, but that'll probably break d-i. Probably yes, altough a two step removal (first from sid, then from etch), would maybe make this less severe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
On Wed, May 17, 2006 at 09:47:27AM -0500, Stephen R Marenka wrote: > To my knowledge *vme* and atari don't have large followings. True. [...] > Although we do have buildds running for those subarchs, I believe they > are running with custom kernels anyway. Err, no, ska is running a stock Debian kernel. I've stopped compiling custom kernels a while back. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Sven Luther wrote: > On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: > > * dann frazier <[EMAIL PROTECTED]> [2006-05-16 17:04]: > > > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > > > object to a filing of bugs to remove these packages from etch? > > > > For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. > > It's getting close though, but in the meantime I'd like to keep 2.4. > > > > For arm, I've recently removed the last bits of 2.4 from d-i and I was > > going to request the removal after the next d-i beta. > > > > > In general, imho 2.4 should be removed from d-i first for each arch, > > and then after the next beta the 2.4 kernel images can be removed. We > > can start with the removal of 2.4 from those architectures which no > > longer use 2.4 at all (e.g. powerpc). > > Notice that we are not asking removal from d-i, but from the archive > completely. It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Frans, Joey, what is your opinion about this? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Tue, May 16, 2006 at 05:04:00PM -0500, dann frazier wrote: > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > object to a filing of bugs to remove these packages from etch? > > Developers at DebConf have pointed out to me that removing these > packages would help avoid confusion/unnecessary bug reports. > > The rough consensus was also to continue to support systems for which > users have compiled their own 2.4 - if we proceed with this removal, > we might ask the release team to explicitly note this in a d-d-a > e-mail so that package maintainers do not break 2.4 support if possible. How do you plan to handle upgrade from sarge for users that are running 2.4 kernel ? What should the release note say about that? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367570: unknown symbols in sound modules
Hello, On Tue, May 16, 2006 at 04:47:43PM -0500, martin f krafft wrote: > After the upgrade to 2.6.16 (from 2.6.15), I started seeing the > following errors during boot: rerunning alsaconf fixes this. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Processed: ethernet does not work
Processing commands for [EMAIL PROTECTED]: > found 358744 2.6.16-12 Bug#358744: linux-image-2.6.16-1-686: ethernet does not work Bug marked as found in version 2.6.16-12. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
dann frazier wrote: > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > object to a filing of bugs to remove these packages from etch? Mips/mipsel d-i hasn't fully switched to 2.6 yet. Is there a urgent need to remove 2.4 from etch? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
* dann frazier <[EMAIL PROTECTED]> [2006-05-16 17:04]: > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Tue, 16 May 2006, dann frazier wrote: > I believe there's a rough consensus to not ship 2.4 in etch. Anyone > object to a filing of bugs to remove these packages from etch? full ack. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Tue, 16 May 2006, dann frazier wrote: > However, to meet the etch release schedule, we need to begin freezing > the kernel relatively soon. I am not sure what those dates are > though; hopefully this will become more clear after the etch release > discussion at debconf on Thursday (iirc). indeed the release schedule impose that. but releasing with an old frozen kernel has not the same advantage as the old glibc which still supports the 2.4 kernel line. so if in the freeze time we get something much better it makes sense to push that release. > The bit I find interesting about 2.6.16 is that Adrian Bunk has > proposed maintaining a 2.6.16 branch where new *features* are > permitted, and it sounds more inline with how 2.4 was maintained once > 2.5 had forked. If this happens, it *should* provide a more > controlled tree than Linus' from which we can pull in updated features > like atapi, acpi, etc, and continue to sync them into our testing > kernel until the freeze. If we could have trivially cherry-picked > features from 2.6.10 and backported to 2.6.8 before sarge, I think we > would have; but the number of changesets between the two was so > immense that we only really considered moving completely to 2.6.10. 2.6.16 has seen major distro stabilisation as seen of the hight nr. of stable kernel releases. i thus think that it is a good canditate per se. although i would keep a window open for 2.6.18 if we get it ready during the freeze and it works better. 2.6.17 is said to be used by no major distro [1]. for sarge we could have pusshed 2.6.10 if we had worked earlier on that release. although it was not so easy to rebase on those times. i've not seen any bit of that tree yet and there is already a lot of new features to backport. until that "stable" tree appears talks are pretty much speculations. regards -- maks [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=114780190710723&w=2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
[EMAIL PROTECTED] wrote: >I believe there's a rough consensus to not ship 2.4 in etch. Anyone >object to a filing of bugs to remove these packages from etch? Please do. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: wrong bug closed
Processing commands for [EMAIL PROTECTED]: > reopen 367567 Bug#367567: please remove the md/raid hooks and scripts and let mdadm provide them 'reopen' is deprecated when a bug has been closed with a version; use 'found' or 'submitter' as appropriate instead. Bug reopened, originator not changed. > close 367576 1.1.17 Bug#367576: libpaper1: Fix parsing of $LC_PAPER 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 1.1.17, send any further explanations to Denis Barbier <[EMAIL PROTECTED]> > quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367567: marked as done (please remove the md/raid hooks and scripts and let mdadm provide them)
Your message dated Tue, 16 May 2006 23:02:05 -0700 with message-id <[EMAIL PROTECTED]> and subject line Bug#367567: fixed in libpaper 1.1.17 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: initramfs-tools Version: 0.60 Severity: wishlist I would like to provide /usr/share/initramfs-tools/hooks/md and /usr/share/initramfs-tools/scripts/md in mdadm to be able to make changes without harassing you. Could you thus please orchestrate with me a release that conflicts with previous versions of mdadm? -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.1.2-1 Tiny utilities for small and embed ii cpio 2.6-11 GNU cpio -- a program to manage ar ii klibc-utils 1.3.19-2 small statically-linked utilities ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii udev 0.091-2/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP) --- End Message --- --- Begin Message --- Source: libpaper Source-Version: 1.1.17 We believe that the bug you reported is fixed in the latest version of libpaper, which is due to be installed in the Debian FTP archive: libpaper-dev_1.1.17_powerpc.deb to pool/main/libp/libpaper/libpaper-dev_1.1.17_powerpc.deb libpaper-utils_1.1.17_powerpc.deb to pool/main/libp/libpaper/libpaper-utils_1.1.17_powerpc.deb libpaper1_1.1.17_powerpc.deb to pool/main/libp/libpaper/libpaper1_1.1.17_powerpc.deb libpaper_1.1.17.dsc to pool/main/libp/libpaper/libpaper_1.1.17.dsc libpaper_1.1.17.tar.gz to pool/main/libp/libpaper/libpaper_1.1.17.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Giuseppe Sacco <[EMAIL PROTECTED]> (supplier of updated libpaper package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 17 May 2006 07:41:49 +0200 Source: libpaper Binary: libpaper-dev libpaper1 libpaper-utils Architecture: source powerpc Version: 1.1.17 Distribution: unstable Urgency: low Maintainer: Giuseppe Sacco <[EMAIL PROTECTED]> Changed-By: Giuseppe Sacco <[EMAIL PROTECTED]> Description: libpaper-dev - Library for handling paper characteristics (development files) libpaper-utils - Library for handling paper characteristics (utilities) libpaper1 - Library for handling paper characteristics Closes: 367529 367567 367589 Changes: libpaper (1.1.17) unstable; urgency=low . * now postrm deletes conffiles during purge (Closes: #367529) * simplified the way to get informations from current locale (Closes: #367567) * use CURDIR instead of PWD in debian/rules to make it work on autobuilders with sudo (Closes: #367589) Files: f942d2ef74027618f6e5ca87ece24738 568 libs optional libpaper_1.1.17.dsc de14702ff39b0c57336605913718daa2 327104 libs optional libpaper_1.1.17.tar.gz 0a6f11f6070d546d2bf32bec585ae6f5 21410 libs optional libpaper1_1.1.17_powerpc.deb 3dc3c1fe096b2edb7d77241f2237adb9 18868 utils optional libpaper-utils_1.1.17_powerpc.deb d62825c91b60e0e6c395a0675d0f2d33 17112 libdevel optional libpaper-dev_1.1.17_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEark4IgfFlOyXCJ0RAnmSAKCV43pzdmEafyuA5SMi1PXLPaujIwCfVU5e uhx7rtgwAqtlGJOaFBs7a6U= =81aa -END PGP SIGNATURE- --- End Message ---
Re: [D-I] Preparing for update in stable
This is a follow-up to [1] which proposed a plan for the update of D-I using the latest kernel update for stable in preparation for Sarge r3. Follow-ups please in principle _only_ to d-release and d-boot and maybe to one of the CCed lists if relevant for them. On Friday 21 April 2006 02:01, Frans Pop wrote: > In more detail: > 1) Upload new i386 kernel udebs for both 2.4 and 2.6 to s-p-u (I've >already prepared a set) > 2) Get these acked by SRM so they actually show up in s-p-u; s-p-u > already has debian-installer sections, I'm not sure if the acceptance > queue and approval stuff supports udebs though (aj?) > 3) Try a local build of d-i using a sources.list that has both stable > and s-p-u in it [1]. After a bit of a wait, stage 2 was completed and I have completed the test in stage 3. Building the installer using s-p-u to get kernel udebs worked as expected and the mini.iso booted with the correct kernel and ran successfully for the first installation steps. Attached are the patches that are needed in the installer to make use of the new kernels. One patch for d-i itself and one for base-installer (for alpha). Patches for kernel udeb packages not included as they are trivial. Some comments on the patch for debian-installer: - AMD64 currently has _no_ kernel updates in their s-p-u Packages file; I understand that Joerg Jaspert needs to work on this for AMD64 to be included in the r3 point release. It will probably also need work by him to get the udebs into the debian-installer section in s-p-u. - The following architectures have no ABI version in the packages names and thus do not need a change in their config files: arm, m68k, mips, mipsel - Powerpc did not have any ABI version in the kernel-image package names, but with this release they have been added for 2.6.8 (not for 2.4.27!). As there also seem to be (new?) meta-packages, base-installer should continue to work. - The other arches all has an ABI change from 2 to 3. Request to d-i porters: please check if the changes for your architecture are complete. So, the next steps are: > 4) If this works, poke^Wask porters to upload updated kernels udebs for >their arches. We are going to delay step 4 until the kernel security updates that are currently being prepared are available in s-p-u. These do not include an ABI change. > 5) Upload new base-installer. > 6) Get those uploads acked by SRM. > 7) Upload d-i and let the buildds do their stuff. The steps after that are: 8) Prepare necessary updates for debian-cd (if any). 9) Release r3 with very clear communication (debian-announce) that old installer images may break and that preferably new images should be used. Also communicate that availability of CD images may take up to a week. 10) Generate new package lists for debian-cd with new kernel versions. 11) Build and test images for all arches (with porter help). Cheers, FJP [1] http://lists.debian.org/debian-release/2006/04/msg00122.html Index: debian/postinst === --- debian/postinst (revision 36545) +++ debian/postinst (working copy) @@ -513,7 +513,7 @@ trykernel=kernel-image-$version-$flavor ;; alpha) - version=2.4.27-2 + version=2.4.27-3 if dmesg | grep -q ^Processors:; then CPUS=`dmesg | grep ^Processors: | cut -d: -f2` else Index: config/powerpc/power3.cfg === --- config/powerpc/power3.cfg (revision 37370) +++ config/powerpc/power3.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot # The version of the kernel to use. -KERNELVERSION = 2.6.8-power3 +KERNELVERSION = 2.6.8-3-power3 KERNEL_FLAVOUR = di KERNELNAME = vmlinux KERNELIMAGEVERSION = $(KERNELVERSION) Index: config/powerpc/powerpc.cfg === --- config/powerpc/powerpc.cfg (revision 37370) +++ config/powerpc/powerpc.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot floppy floppy-2.4 hd-media cdrom-minimal netboot-minimal # monolithic # The version of the kernel to use. -KERNELVERSION = 2.6.8-powerpc +KERNELVERSION = 2.6.8-3-powerpc # Targets for 2.4 kernel images will use this version instead. KERNELVERSION_2.4 = 2.4.27-powerpc KERNEL_FLAVOUR = di Index: config/powerpc/power4.cfg === --- config/powerpc/power4.cfg (revision 37370) +++ config/powerpc/power4.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot # The version of the kernel to use. -KERNELVERSION = 2.6.8-power4 +KERNELVERSION = 2.6.8-3-power4 KERNEL_FLAVOUR = di KERNELNAME = vmlinux KERNELIMAGEVERSION = $(KERNELVERSION) Index: config/alpha.cfg === --- config/alpha.cfg (revision 37370) +++ config/alpha.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot miniiso #
