Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, 18 Dec 2006 11:48:22 +0100, Bastian Blank [EMAIL PROTECTED] said: On Mon, Dec 18, 2006 at 09:31:22AM +0100, Goswin von Brederlow wrote: And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. That happens if the same problems happens over and over again: kpkg fails silent instead of producing errors. The following reasons was identified, some of them fixed. This errors are now catched by the abi check because the complete output is missing: - More than one entry in the Architecture line, the code just explicitely ignored anything after the first entry. What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? - Broken EXTRAVERSION. Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? - 2.6.19-rcX failed on the autobuilders and for Sven, not for me. So it failes if the environment is not as it wants. Has the bit about the environment that it wanted been identified? Is it not true that the failure was not in make-kpkg by itself, but only in linux-2.6, which leads one to conclude that the problem might have been in the so called infrastructure code? There are other problems like: * It is possible to interfere with the build from a user config. What do you mean, interfere? Can the same config build a kernel without using make-kpkg? The only issue I can see might be version numbers being changed with the ser config, and yes, changing version numbers like that is not supported. * Build time raises by about 30% at worst. - build target needs 30 minutes on ppc. - binary-arch target needs another 30 minutes. My own routine needs less than 10. I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? manoj -- We are what we are. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Wed, Dec 20, 2006 at 09:35:56AM -0600, Manoj Srivastava wrote: What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? ... Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? ... I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? Manoj, you see, this is part of the problem. Nearer integration of the kernel-package maintainer and kernel team, or you being part of the kernel team, doesn't necessarily mean communicating via bug reports. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Wed, Dec 20, 2006 at 09:35:56AM -0600, Manoj Srivastava wrote: What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? ... Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? ... I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? Manoj, you see, this is part of the problem. Nearer integration of the kernel-package maintainer and kernel team, or you being part of the kernel team, doesn't necessarily mean communicating via bug reports. What's wrong with filing bugreports? You seem to argue that keeping record of bugs is wrong is replaceable with coordination on a mailinglist, spiced up with IRC conversations. I disagree. Teaming up is great, but does not replace the core routines in Debian. It just glues them better together. IMHO. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFiXJgn7DbMsAkQLgRAukGAJ9WyRa3Y9KFuGsztQbyZieqGSyxXgCfVVRA MgDj3Vbrv8sp6Kg2RBXyjrM= =9wGi -END PGP SIGNATURE-
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Wed, Dec 20, 2006 at 06:26:57PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Wed, Dec 20, 2006 at 09:35:56AM -0600, Manoj Srivastava wrote: What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? ... Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? ... I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? Manoj, you see, this is part of the problem. Nearer integration of the kernel-package maintainer and kernel team, or you being part of the kernel team, doesn't necessarily mean communicating via bug reports. What's wrong with filing bugreports? You seem to argue that keeping record of bugs is wrong is replaceable with coordination on a mailinglist, spiced up with IRC conversations. Nope, i am saying that if the only communication channel between such important pieces of related debian infrastructure like the linux kernel package and the kernel-package package is plain wrong. I disagree. Teaming up is great, but does not replace the core routines in Debian. It just glues them better together. IMHO. Teaming up is all about communication. If some guys want to play it solo for such inter-related packages, that is a problem. I agree that this problem exists on both side in this case, but Bastian is at least part of the team. And bug reports are only so useful as the maintainers make them, as you well know, who left a pretty damaging RC bug open for months, rejected help in investigating it, and highly contributed to the near-desintegration of the kernel team in march by such behaviour (of which i also contributed i admit). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Wed, 20 Dec 2006 18:26:57 +0100, Jonas Smedegaard [EMAIL PROTECTED] said: Sven Luther wrote: On Wed, Dec 20, 2006 at 09:35:56AM -0600, Manoj Srivastava wrote: What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? ... Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? ... I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? Manoj, you see, this is part of the problem. Nearer integration of the kernel-package maintainer and kernel team, or you being part of the kernel team, doesn't necessarily mean communicating via bug reports. What's wrong with filing bugreports? Especially since there is no real communication of problem, just bad mouthing the package in question, suddenly, and out of the blue. Not very conducive to things being corrected either, lacking details, debug statements, or a means to reproduce the so called fatal flaws, manoj -- Women are wiser than men because they know less and understand more. Stephens Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
Sven Luther [EMAIL PROTECTED] writes: On Fri, Dec 15, 2006 at 04:40:16PM +0100, Goswin von Brederlow wrote: From personal experience I must say that bugs reported against kernel-package get manojs attention fast and get fixed fast. Bugs against the linux-2.6 source get ignored or you get comments like breaks cross building and any request of the error or a build log gets ignored. ... I think the blame is much more on the kernel team than manoj. He doesn't have a crystal ball to see linux-2.6 problems relevant to kernel-package. The team has to report them first. Only then can you have a discussion about the problems and find solutions. Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. Further one result of this dislike of kernel-package seems to be that you can't build proper custom kernels on mips, mipsel, s390 and ppc and no xen or vserver flavours anywhere. The debian patch is not make-kpkg compatible and again Bastian spoke against fixing the patch to work with kernel-package. So, basically, the problem is of two infrastructure people, both proud and head-strong, and both pulling the stuff in their own separate direction. I don't think pointing the fingers about responsability will help in any way here, but more cooperacion on both sides would be helpful. Let's all have a kernel-team meeting somewhere post-etch, and try to work together or something ? One can dream. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 09:31:22AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. Further one result of this dislike of kernel-package seems to be that you can't build proper custom kernels on mips, mipsel, s390 and ppc and no xen or vserver flavours anywhere. The debian patch is not make-kpkg compatible and again Bastian spoke against fixing the patch to work with kernel-package. I consider kernel-package one of the best things in Debian and it is a real pity that it is not being used to build the Debian kernel. Not being able to use Debian's kernel build tool to build a Debian kernel is depressing. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 10:47:56AM +0100, Marc Haber wrote: On Mon, Dec 18, 2006 at 09:31:22AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. Further one result of this dislike of kernel-package seems to be that you can't build proper custom kernels on mips, mipsel, s390 and ppc and no xen or vserver flavours anywhere. The debian patch is not make-kpkg compatible and again Bastian spoke against fixing the patch to work with kernel-package. I consider kernel-package one of the best things in Debian and it is a real pity that it is not being used to build the Debian kernel. Not It is used by the debian kernel team. The problem is as said one of communication and pride, with Bastian seeing it as a tool which breaks often in obscure ways, and hindering his work on the infrastructure build, while Manoj is still somewhat recentful of the kernel team, even though he won't admit such publicly, i remember perfectly his i was already packaging kernels in the early 90s and other such prideful issues last year. And jonas, who used this as a reason to explain to me in RL during half an hour why he should not even look at an RC bug. BTW, jonas, i notice also : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403203 And how you have been rather inactive on yaird over this past year. being able to use Debian's kernel build tool to build a Debian kernel is depressing. This is just plain FUD. Now, what is really needed, is that a few people like Jonas and Manoj, who are working on tools vital to the kernel team developments, actually join the kernel team, and so we can all work together in the same direction. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 09:31:22AM +0100, Goswin von Brederlow wrote: And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. That happens if the same problems happens over and over again: kpkg fails silent instead of producing errors. The following reasons was identified, some of them fixed. This errors are now catched by the abi check because the complete output is missing: - More than one entry in the Architecture line, the code just explicitely ignored anything after the first entry. - Broken EXTRAVERSION. - 2.6.19-rcX failed on the autobuilders and for Sven, not for me. So it failes if the environment is not as it wants. There are other problems like: * It is possible to interfere with the build from a user config. * Build time raises by about 30% at worst. - build target needs 30 minutes on ppc. - binary-arch target needs another 30 minutes. My own routine needs less than 10. Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: BTW, jonas, i notice also : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403203 Yes. I was slightly baffled about that bugreport fork, and is still wondering what to do about it: To me is seems like a report against the packager rather than the package itself... I want yaird to be a _generic_ tool for building initial ramdisks, without favoring the specific kernels maintained by the Debian kernel team. I believe that maintaining yaird separately from debian-kernel helps avoid interest conflicts. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhnbUn7DbMsAkQLgRAkNqAJ9qpjmAyF0pn9hcn5blVGzJmVXv1gCeM19k rpJizCk9Y6LJx7ZtLm0Sx/k= =4Q3L -END PGP SIGNATURE-
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 12:09:09PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: BTW, jonas, i notice also : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403203 Yes. I was slightly baffled about that bugreport fork, and is still wondering what to do about it: To me is seems like a report against the packager rather than the package itself... Yeah, right. I want yaird to be a _generic_ tool for building initial ramdisks, without favoring the specific kernels maintained by the Debian kernel team. The reality is that yaird has fallen aside during this whole year, because of little activity on your part (and i must say that i stopped pushing yaird after you explained to me why you should not take the 10 minutes to investigate the RC bug report in erkelenz). Have you heard of yaird's upstream since last year ? I remember you telling me that you didn't understand yaird enough to do stuff yourself, and there was no sign of upstream. Has this situation improved ? what are your plans regarding to this ? I believe that maintaining yaird separately from debian-kernel helps avoid interest conflicts. Well, this is where you are wrong, there is no conclict of interest. The kernel-team++ should take responsability from building the official kernels, but also from letting users build their own kernels, which integrate perfectly with the whole kernel stuff. It is you (and to a lesser degree Manoj), who, by not integrating the kernel team, are making this separation, and that is not a good thing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Mon, Dec 18, 2006 at 12:09:09PM +0100, Jonas Smedegaard wrote: I believe that maintaining yaird separately from debian-kernel helps avoid interest conflicts. Well, this is where you are wrong, there is no conclict of interest. [snip] It is you (and to a lesser degree Manoj), who, by not integrating the kernel team, are making this separation, and that is not a good thing. I told you about my belief in this matter, and my opinion on dealing with it in the future. Thank you for doing the same. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhoq0n7DbMsAkQLgRAlM2AJ9TgDjIPjB2XvXgyjS9topdYUen7gCdHoeZ bZWy0ivDdBnZCVpn/cVqs9Q= =GooY -END PGP SIGNATURE-
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought In my understanding kernel-package is intended as a _generic_ tool for Debian-packaging a Linux kernel, officially built or not. No use is favored, official or not. I don't think pointing the fingers about responsability will help in any way here, but more cooperacion on both sides would be helpful. I perfectly agree. So please don't ;-) Kind regards, - Jonas P.S. No privately cc'ed replies, please: I am subscribed to this list! - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhbuMn7DbMsAkQLgRAsxSAKCfi6uO54ut/2vH410Zi7HlOgqjhgCfSBkp xbKX+8EAsFaGxhUhAs2eeXM= =LDHW -END PGP SIGNATURE-
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sun, 17 Dec 2006 22:50:04 +0100, Jonas Smedegaard [EMAIL PROTECTED] said: Sven Luther wrote: Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought This is a egregious mischaracterization of my stance. In my understanding kernel-package is intended as a _generic_ tool for Debian-packaging a Linux kernel, officially built or not. No use is favored, official or not. This is indeed my stance. manoj -- When the going gets tough, the tough get empirical. Jon Carroll Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 12:30:28AM -0600, Manoj Srivastava wrote: On Sun, 17 Dec 2006 22:50:04 +0100, Jonas Smedegaard [EMAIL PROTECTED] said: Sven Luther wrote: Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought This is a egregious mischaracterization of my stance. Well, this may not be your stances, but you have in the past strongly communicated that way. Go look for the web archive of your post of this past year if you don't believe me. Now, all i was saying, is that everyone would benefit if you worked more closely with the kernel team, and in the same way, if Bastian was more open, and if ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
Sven Luther [EMAIL PROTECTED] writes: On Sat, Dec 02, 2006 at 12:43:06PM -0600, Manoj Srivastava wrote: On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank [EMAIL PROTECTED] said: I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. And none of which you report. If you can't put together a Notice that this is the same problem as the guy with 2.6.11 reported. coherent bug report, you can't expect issues to get resolved. Frankly, k-p works fine when used as expected -- linux-2.6 tries to mould it in a fashion which is not exactly supported, by overriding bits and pieces, and I am not surprised when things do not work as you try to force them to. The real problem is that you don't really integrate well with the kernel team, and have your own agenda. This is also true from the other side though. From personal experience I must say that bugs reported against kernel-package get manojs attention fast and get fixed fast. Bugs against the linux-2.6 source get ignored or you get comments like breaks cross building and any request of the error or a build log gets ignored. What we really need is a strategy where you work better with the kernel team, where we have more communication (also applies to Bastian), and where the stated goal of kernel-package is to build both older kernel and the kernel packages. This would be a good starting point to take Jonas idea again, and move the postinst scripts out of kernel-package and the linux-images, and into separate package ? Even then, I would respond to bug reports which show misbehavior by kernel-package -- which have not exactly been forthcoming, have they? manoj tired of people trying to bend k-p into doing things it is not supposed to do, and then complaining when they fail Well, to be honest, it goes both way. I think the blame is much more on the kernel team than manoj. He doesn't have a crystal ball to see linux-2.6 problems relevant to kernel-package. The team has to report them first. Only then can you have a discussion about the problems and find solutions. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Fri, Dec 15, 2006 at 04:40:16PM +0100, Goswin von Brederlow wrote: From personal experience I must say that bugs reported against kernel-package get manojs attention fast and get fixed fast. Bugs against the linux-2.6 source get ignored or you get comments like breaks cross building and any request of the error or a build log gets ignored. ... I think the blame is much more on the kernel team than manoj. He doesn't have a crystal ball to see linux-2.6 problems relevant to kernel-package. The team has to report them first. Only then can you have a discussion about the problems and find solutions. Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. So, basically, the problem is of two infrastructure people, both proud and head-strong, and both pulling the stuff in their own separate direction. I don't think pointing the fingers about responsability will help in any way here, but more cooperacion on both sides would be helpful. Let's all have a kernel-team meeting somewhere post-etch, and try to work together or something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
* Sven Luther ([EMAIL PROTECTED]) [061201 20:30]: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. If one of the release managers uses the force-hint, nothing from the first stage (RC-bugs, date, out-of-date, ...) will block the testing migration anymore. However, in the second stage, installability is checked. According to todays output, these packages are broken by the transition: trying: linux-2.6 skipped: linux-2.6 (15 - 32) got: 115+0: i-115 * i386: kernel-image-2.6-386, kernel-image-2.6-686, kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, redhat-cluster-modules-2.6.17-2-vserver-686, redhat-cluster-modules-2.6.17-2-vserver-k7, redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, unionfs-modules-2.6.17-2-k7 I could use a force-hint on linux-modules-extra-2.6 as well, but as long as it is out-of-date on so many architectures, that won't improve the picture. And also, why do e.g. linux-image-2.6-vserver-k7 get uninstallable (hm, that could be a bug in britney though). - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable ? Will we keep 2.6.19 in experimental for now ? I hope you can keep 2.6.19 in experimental for now - it doesn't take so long to release Etch anymore. Cheers, Andi -- http://home.arcor.de/andreas-barth/
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 10:37:01AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [061201 20:30]: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. If one of the release managers uses the force-hint, nothing from the first stage (RC-bugs, date, out-of-date, ...) will block the testing migration anymore. However, in the second stage, installability is checked. According to todays output, these packages are broken by the transition: trying: linux-2.6 skipped: linux-2.6 (15 - 32) got: 115+0: i-115 * i386: kernel-image-2.6-386, kernel-image-2.6-686, kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, redhat-cluster-modules-2.6.17-2-vserver-686, redhat-cluster-modules-2.6.17-2-vserver-k7, redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, unionfs-modules-2.6.17-2-k7 I could use a force-hint on linux-modules-extra-2.6 as well, but as long as it is out-of-date on so many architectures, that won't improve the picture. And also, why do e.g. linux-image-2.6-vserver-k7 get uninstallable (hm, that could be a bug in britney though). Ok, this is the linux-modules-extra-2.6 problem, which should be solved by removing the module which is broken. not sure which one it was. The -k7 issue, i don't know, can it be a flavour that was dropped or something ? - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. - latest info from Bastian was that the 2.6.19-rc6 experimental packages in experimental failed to build because of some kernel-package problem which caused silent bugs. Bastian, do you have any additional info to provide which may give a light to the problem ? Manoj, can you have a look at this, and maybe help us fix the issue ? I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. Bastian -- It is more rational to sacrifice one life than six. -- Spock, The Galileo Seven, stardate 2822.3 signature.asc Description: Digital signature
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
I think it is a good ideea to adopt 2.6.19 for etch if its possible. I looked over the changelogs in 2.6.18 and there is one issue that concerns me: commit a4fce7747b167aa5e9aa43c4f816744d8a97e021 Author: Patrick McHardy [EMAIL PROTECTED] Date: Wed Oct 11 01:53:26 2006 -0700 NETFILTER: NAT: fix NOTRACK checksum handling The whole idea with the NOTRACK netfilter target is that you can force the netfilter code to avoid connection tracking, and all costs assosciated with it, by making traffic match a NOTRACK rule. But this is totally broken by the fact that we do a checksum calculation over the packet before we do the NOTRACK bypass check, which is very expensive. People setup NOTRACK rules explicitly to avoid all of these kinds of costs. This patch from Patrick, already in Linus's tree, fixes the bug. Move the check for ip_conntrack_untracked before the call to skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19 NAT code breaks TSO by invalidating hardware checksums for every packet, even if explicitly excluded from NAT through NOTRACK. 2.6.19 includes a fix that makes NAT and TSO live in harmony, but the performance degradation caused by this deserves making at least the workaround work properly in -stable. On 12/2/06, Sven Luther [EMAIL PROTECTED] wrote: On Sat, Dec 02, 2006 at 10:37:01AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [061201 20:30]: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. If one of the release managers uses the force-hint, nothing from the first stage (RC-bugs, date, out-of-date, ...) will block the testing migration anymore. However, in the second stage, installability is checked. According to todays output, these packages are broken by the transition: trying: linux-2.6 skipped: linux-2.6 (15 - 32) got: 115+0: i-115 * i386: kernel-image-2.6-386, kernel-image-2.6-686, kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, redhat-cluster-modules-2.6.17-2-vserver-686, redhat-cluster-modules-2.6.17-2-vserver-k7, redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, squashfs-modules-2.6-vserver-k7,
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 11:36:30AM +0100, Bastian Blank wrote: On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. Ok, do we have a plan for this ? - latest info from Bastian was that the 2.6.19-rc6 experimental packages in experimental failed to build because of some kernel-package problem which caused silent bugs. Bastian, do you have any additional info to provide which may give a light to the problem ? Manoj, can you have a look at this, and maybe help us fix the issue ? I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. Well, we can : 1) Revert the infrastructure changes to the 2.6.18 one. 2) You could give as much information as you can about the problem, so that someone else (well, probably not me, because Manoj will not speak with me as far as i know), can follow up on this with him. In particular, one issue which remains open in the current situation, is that some could argue that it is not a k-p bug, but one in the infrastructure code, and as very few people apart from you have an oversight of what is really happeneing. I guess the more satisfying solution is 2), you provide a bit of info about what the problem is, and someone else goes to manoj and or to kernel-package, and resolve the problem. Thanks for your reply, Bastian, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 10:51:57AM +0100, Sven Luther wrote: The -k7 issue, i don't know, can it be a flavour that was dropped or something ? linux-latest-2.6 is not a candidate because not yet uploaded on sparc. That's the easy part; linux-modules-extra-2.6 is the harder part, currently failing to build on both arm and s390 (c.f. bug #400220). - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable ? Will we keep 2.6.19 in experimental for now ? I hope you can keep 2.6.19 in experimental for now - it doesn't take so long to release Etch anymore. Bah, we where told this for sarge, and it took over a year back then. I don't see us releaseing etch anytime soon, since we don't have had a single release candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to unstable (maybe with a linux-2.6.19 source package) should be nice enough. We did this already for 2.6.16, so, we know how to do this. Frankly, 2.6.16 was a total cock-up. Aside from all the extra work it made for the release team, I even found patches I had to reapply for alpha because they were dropped on the floor when 2.6.16 was merged to trunk. I am very much opposed to having two kernel versions in unstable at the same time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote: We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: Ok, do we have a plan for this ? Not yet. I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. Well, we can : 1) Revert the infrastructure changes to the 2.6.18 one. No. 2) You could give as much information as you can about the problem, so that someone else (well, probably not me, because Manoj will not speak with me as far as i know), can follow up on this with him. I don't know what the problem is. I only kown: it does not work on the autobuilders. Bastian -- Prepare for tomorrow -- get ready. -- Edith Keeler, The City On the Edge of Forever, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 02:41:08AM -0800, Steve Langasek wrote: On Sat, Dec 02, 2006 at 10:51:57AM +0100, Sven Luther wrote: The -k7 issue, i don't know, can it be a flavour that was dropped or something ? linux-latest-2.6 is not a candidate because not yet uploaded on sparc. That's the easy part; linux-modules-extra-2.6 is the harder part, currently failing to build on both arm and s390 (c.f. bug #400220). Can we not just scratch l-m-e-2.6 until those issues are fixed, and migrate linux-2.6 andl-l-2.6 into testing asap ? We need to get more testing done for it. - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable ? Will we keep 2.6.19 in experimental for now ? I hope you can keep 2.6.19 in experimental for now - it doesn't take so long to release Etch anymore. Bah, we where told this for sarge, and it took over a year back then. I don't see us releaseing etch anytime soon, since we don't have had a single release candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to unstable (maybe with a linux-2.6.19 source package) should be nice enough. We did this already for 2.6.16, so, we know how to do this. Frankly, 2.6.16 was a total cock-up. Aside from all the extra work it made for the release team, I even found patches I had to reapply for alpha because they were dropped on the floor when 2.6.16 was merged to trunk. I am very much opposed to having two kernel versions in unstable at the same time. Well, the idea is to continue working on 2.6.19 in a separate package, but keeping 2.6.18 linux-2.6 as the main package, with linux-2.6.19 being a separate package which will be worked on as separatedly for those peopel who want. But you are right, if we want to do more than one kernle, we need an automated better way to do synchronizations. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, 02 Dec 2006, Steve Langasek wrote: snipp Frankly, 2.6.16 was a total cock-up. Aside from all the extra work it made for the release team, I even found patches I had to reapply for alpha because they were dropped on the floor when 2.6.16 was merged to trunk. I am very much opposed to having two kernel versions in unstable at the same time. agreed, 2.6.19 is experimental material. guys 2.6.18 can still need stabilising, enough open bugs -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 12:10:00PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote: We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: Ok, do we have a plan for this ? Not yet. Can we upload that today or are other things waiting? Bastian -- Men of peace usually are [brave]. -- Spock, The Savage Curtain, stardate 5906.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 02:44:11PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 12:10:00PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote: We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: Ok, do we have a plan for this ? Not yet. Can we upload that today or are other things waiting? Bastian yes i want to add 2.6.18.5 to linux-2.6 sid, not sure if it breaks abi through.. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 11:36:30AM +0100, Bastian Blank wrote: On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. I'm sorry to say that, but my current position is to veto any future linux-2.6 upload, unless it also implements the changes to the orig.tar.gz in accordance with the release position statement [0] following the firmware GR. [0] http://lists.debian.org/debian-kernel/2006/10/msg00541.html Best regards, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank [EMAIL PROTECTED] said: On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. - latest info from Bastian was that the 2.6.19-rc6 experimental packages in experimental failed to build because of some kernel-package problem which caused silent bugs. Bastian, do you have any additional info to provide which may give a light to the problem ? Manoj, can you have a look at this, and maybe help us fix the issue ? I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. And none of which you report. If you can't put together a coherent bug report, you can't expect issues to get resolved. Frankly, k-p works fine when used as expected -- linux-2.6 tries to mould it in a fashion which is not exactly supported, by overriding bits and pieces, and I am not surprised when things do not work as you try to force them to. Even then, I would respond to bug reports which show misbehavior by kernel-package -- which have not exactly been forthcoming, have they? manoj tired of people trying to bend k-p into doing things it is not supposed to do, and then complaining when they fail -- You are the only person to ever get this message. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 12:43:06PM -0600, Manoj Srivastava wrote: On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank [EMAIL PROTECTED] said: On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. - latest info from Bastian was that the 2.6.19-rc6 experimental packages in experimental failed to build because of some kernel-package problem which caused silent bugs. Bastian, do you have any additional info to provide which may give a light to the problem ? Manoj, can you have a look at this, and maybe help us fix the issue ? I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. And none of which you report. If you can't put together a Notice that this is the same problem as the guy with 2.6.11 reported. coherent bug report, you can't expect issues to get resolved. Frankly, k-p works fine when used as expected -- linux-2.6 tries to mould it in a fashion which is not exactly supported, by overriding bits and pieces, and I am not surprised when things do not work as you try to force them to. The real problem is that you don't really integrate well with the kernel team, and have your own agenda. This is also true from the other side though. What we really need is a strategy where you work better with the kernel team, where we have more communication (also applies to Bastian), and where the stated goal of kernel-package is to build both older kernel and the kernel packages. This would be a good starting point to take Jonas idea again, and move the postinst scripts out of kernel-package and the linux-images, and into separate package ? Even then, I would respond to bug reports which show misbehavior by kernel-package -- which have not exactly been forthcoming, have they? manoj tired of people trying to bend k-p into doing things it is not supposed to do, and then complaining when they fail Well, to be honest, it goes both way. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
Teodor-Adrian MICU [EMAIL PROTECTED] writes: I think it is a good ideea to adopt 2.6.19 for etch if its possible. Please don't unless we can't avoid it. Each time we bring in a new kernel, those of us who maintain external kernel modules have to do a bunch of work to catch up with all the API changes. For full 2.6.19 support on all platforms I believe I'd need to pull patches from CVS for OpenAFS, whereas the current packages are stable and functioning on 2.6.18. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 03:41:24PM +0100, maximilian attems wrote: On Sat, Dec 02, 2006 at 02:44:11PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 12:10:00PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 11:48:07AM +0100, Sven Luther wrote: We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: Ok, do we have a plan for this ? Not yet. Can we upload that today or are other things waiting? yes i want to add 2.6.18.5 to linux-2.6 sid, not sure if it breaks abi through.. Sounds to me like something to look into *after* 2.6.18 has had a chance to reach testing? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 01:41:50PM -0800, Steve Langasek wrote: yes i want to add 2.6.18.5 to linux-2.6 sid, not sure if it breaks abi through.. Sounds to me like something to look into *after* 2.6.18 has had a chance to reach testing? You have to force them than. Bastian -- Killing is stupid; useless! -- McCoy, A Private Little War, stardate 4211.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
