Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
Horms wrote: > On Wed, Sep 14, 2005 at 07:35:48AM +0200, Sven Luther wrote: > > On Wed, Sep 14, 2005 at 11:18:14AM +0900, Horms wrote: > > > On Tue, Sep 13, 2005 at 11:34:13AM +0200, Sven Luther wrote: > > > > On Tue, Sep 13, 2005 at 05:51:18PM +0900, Horms wrote: > > > > > > http://packages.vergenet.net/testing/linux-2.6/ > > > > > > > > > > I have done a second build, with the following changes, as > > > > > 2.6.12-5.99.sarge2 > > > > > Only the first change is relevant, URL as immediately above :) > > > > > > > > > >* Change kernel-source build dependancy to > > > > > kernel-package (>= 8.135) [!powerpc] | kernel-package (>= > > > > > 8.135.sarge1) [powerpc] > > > > > so that this package can be build on an unmodified sarge install > > > > > on non-powerpc > > > > >* Add myself and Sven Luther as uploaders > > > > > > > > Maybe we should move that stuff to the SVN, under dists/sarge/backports > > > > or > > > > something such ? > > > > > > Yes, i think that would be an excellent idea. > > > perhaps just put it in dists/sarge, or if you want > > > to make a distinction, dists/sarge-backports > > > > Debian-sarge is fine, what about uploading those to sarge-proposed-updates ? > > Not sure if that one is auto-built, or even easily accessible from the user > > stand-point. > > > > Maybe this is one of the things we need to discuss in oldenbourg with Joey ? > > Good idea, though at this stage it seems unlikely that I will make it > there. Bad idea, actually, because sarge-p-u is supposed to hold potential sarge updates and a backport doesn't meet the criteria for that. (Herbert did the same in woody-p-u with 2.4 backports, they had to be removed before sarge at the price of some user confusion who had t-p-u in their sources.list.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Wed, Sep 14, 2005 at 04:54:04AM +0200, Jeroen van Wolffelaar wrote: > On Tue, Sep 13, 2005 at 08:01:11PM +0200, Sven Luther wrote: > > Hi, > > > > I write this email to ask, now that linux-2.6 2.6.12-6 is in testing, there > > isn't any reason to keep those 2.6.10 and 2.6.11 kernels around, A quick > > glance listed those : > > (...) > > > Also, if there are 2.6.8 kernels in sid/etch still, these can be removed as > > well. > > Please see #317079, #322697 and and #323183. This report is a duplicate from > what's already in those three reports, so please followup to them where > appropriate. I already see a duplicate discussion on whether 2.6.8 can be > removed, so please coordinate in the -kernel team about this, I mailed -kernel > about it before, and there's a bug on the kernel package (#323183) about it. First up I'd like to applogise for the confusion and multiple bug reports surrounding this. The simple truth is that the legacy of the Sarge-era kernel packaging has left us with a mess, that we are trying to sift through and slowly clean up. Its turning out to be quite complicated, and thats not something that you should have been asked to worry about. I suggest that we just track this as 323183, rather than mucking around with opening and merging existing bugs. Please let me know if you would prefer a different approach. I've just spent a bit of time looking through this and here is a summary of where I beleive we are, others, please comment if this is inaccurate or incomplete. If there are ammendments I'll try and correlate them into an updated list. Already removed: kernel-image-2.6.11-s390(done in Bug #317079) kernel-image-2.6.11-sparc (done in Bug #317079) kernel-patch-powerpc-2.6.11 (done in Bug #317079) kernel-source-2.6.11(done in Bug #317079) kernel-image-2.6.10-alpha (done in Bug #322697) kernel-image-2.6.10-hppa(done in Bug #322697) kernel-image-2.6.10-sparc (done in Bug #322697) kernel-source-2.6.10(done in Bug #322697) Ready for removal by ftpmasters kernel-source-2.4.24 kernel-source-2.4.25 kernel-source-2.4.26 kernel-image-2.6.11-alpha kernel-image-2.6.11-amd64 kernel-image-2.6.11-i386 kernel-image-2.6.11-ia64 kernel-patch-2.6.10-hppa kernel-latest-2.6-amd64 fai-kernels (request from Holger Levsen) mol-modules-2.6.11 Will be ready for removal once d-i moves from 2.6.8 to 2.6.12 kernel-image-2.6.8-alpha kernel-image-2.6.8-amd64 kernel-image-2.6.8-hppa kernel-image-2.6.8-i386 kernel-image-2.6.8-ia64 kernel-image-2.6.8-m68k kernel-image-2.6.8-s390 kernel-image-2.6.8-sparc kernel-patch-2.6.8-hppa kernel-patch-2.6.8-m68k kernel-patch-powerpc-2.6.8 kernel-source-2.6.8 kernel-latest-2.6-i386 kernel-latest-2.6-s390 kernel-latest-2.6-sparc kernel-latest-2.6-hppa Not ready for removal kernel-latest-powerpc (needed for 2.4 and in turn d-i) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 09:25:06AM +0200, Thiemo Seufer wrote: > Horms wrote: > > On Wed, Sep 14, 2005 at 07:35:48AM +0200, Sven Luther wrote: > > > On Wed, Sep 14, 2005 at 11:18:14AM +0900, Horms wrote: > > > > On Tue, Sep 13, 2005 at 11:34:13AM +0200, Sven Luther wrote: > > > > > On Tue, Sep 13, 2005 at 05:51:18PM +0900, Horms wrote: > > > > > > > http://packages.vergenet.net/testing/linux-2.6/ > > > > > > > > > > > > I have done a second build, with the following changes, as > > > > > > 2.6.12-5.99.sarge2 > > > > > > Only the first change is relevant, URL as immediately above :) > > > > > > > > > > > >* Change kernel-source build dependancy to > > > > > > kernel-package (>= 8.135) [!powerpc] | kernel-package (>= > > > > > > 8.135.sarge1) [powerpc] > > > > > > so that this package can be build on an unmodified sarge > > > > > > install > > > > > > on non-powerpc > > > > > >* Add myself and Sven Luther as uploaders > > > > > > > > > > Maybe we should move that stuff to the SVN, under > > > > > dists/sarge/backports or > > > > > something such ? > > > > > > > > Yes, i think that would be an excellent idea. > > > > perhaps just put it in dists/sarge, or if you want > > > > to make a distinction, dists/sarge-backports > > > > > > Debian-sarge is fine, what about uploading those to > > > sarge-proposed-updates ? > > > Not sure if that one is auto-built, or even easily accessible from the > > > user > > > stand-point. > > > > > > Maybe this is one of the things we need to discuss in oldenbourg with > > > Joey ? > > > > Good idea, though at this stage it seems unlikely that I will make it > > there. > > Bad idea, actually, because sarge-p-u is supposed to hold potential > sarge updates and a backport doesn't meet the criteria for that. > (Herbert did the same in woody-p-u with 2.4 backports, they had to be > removed before sarge at the price of some user confusion who had t-p-u > in their sources.list.) Ok, bad idea. (Though to clarify, when I said Good idea, i was refering to discussion with Joey at Oldenbourg) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 09:25:06AM +0200, Thiemo Seufer wrote: > Bad idea, actually, because sarge-p-u is supposed to hold potential > sarge updates and a backport doesn't meet the criteria for that. Well, this is something that could be open for discussion, don't you think, but in any case, we need an official and preferably auto-built repository for this kind of things. > (Herbert did the same in woody-p-u with 2.4 backports, they had to be > removed before sarge at the price of some user confusion who had t-p-u > in their sources.list.) Well. The packages have smaller version than the sid ones, so there should be no such confusion. BTW, how are the mips/mipsel integration going ? Any chance to get those in for 2.6.12-7 ? Do you need any help or something ? Will you be in Oldenbourg this year ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
Sven Luther wrote: [snip] > > (Herbert did the same in woody-p-u with 2.4 backports, they had to be > > removed before sarge at the price of some user confusion who had t-p-u > > in their sources.list.) > > Well. The packages have smaller version than the sid ones, so there should be > no such confusion. The problem is a different one. Such a package will have a higher version number than the next stable security update. It will also block legitimate sarge updates because of its version unless it is removed, which is an unattractive option because the users who need exactly this version can't reinstall it any more, and the package still blocks security updates on every machine it was installed. > BTW, how are the mips/mipsel integration going ? Experimental has now a linux-patch-2.6-mips package. > Any chance to get those in > for 2.6.12-7 ? Do you need any help or something ? Will you be in Oldenbourg > this year ? Yes, I'll see you there. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 10:31:06AM +0200, Thiemo Seufer wrote: > Sven Luther wrote: > [snip] > > > (Herbert did the same in woody-p-u with 2.4 backports, they had to be > > > removed before sarge at the price of some user confusion who had t-p-u > > > in their sources.list.) > > > > Well. The packages have smaller version than the sid ones, so there should > > be > > no such confusion. > > The problem is a different one. Such a package will have a higher version > number than the next stable security update. It will also block legitimate He, they will even have a different package name, so ... But maybe you mean the meta-packages, we could chose not to include them, but then if the kernel team and the security team work more closely together, we could even provide security for those kernels. > sarge updates because of its version unless it is removed, which is an > unattractive option because the users who need exactly this version can't > reinstall it any more, and the package still blocks security updates on > every machine it was installed. Only the metapackages, and sure, we can remove them from the backports. All the other cases have the kernel version embedded in their package name, so there could be no such issue. > > BTW, how are the mips/mipsel integration going ? > > Experimental has now a linux-patch-2.6-mips package. What is still blocking at this time to get mips integrated into linux-2.6 ? The last time this came over, i think most of the issues you mentioned as blocking where solved in the current batch of packages, but maybe there are soem remaining, could you do a new list, so we can look them over and fix them if needed ? > > Any chance to get those in > > for 2.6.12-7 ? Do you need any help or something ? Will you be in Oldenbourg > > this year ? > > Yes, I'll see you there. Cool, i will bring my asus WL-HDD2.5 box, which supposedly has a mips chip on it (broadcom one), and we can try getting linux and a debian derivative working on it. Hey, i would even sponsor such a box to someone interested in gettint a real debian on it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328143: was a hfsplus but missing nls_utf8 bug.
severity 328143 normal thanks We traced this problem to hfsplus needing nls_utf8 as module, which d-i did not include, so downgrading the severity. waldi said he would provide a patch for a more graceful handling on this, so i leave htis bug open until then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: was a hfsplus but missing nls_utf8 bug.
Processing commands for [EMAIL PROTECTED]: > severity 328143 normal Bug#328143: [powerpc] d-i dies on apple hardware with a HFS+ kernel OOPS, freezing base-installer Severity set to `normal'. > 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: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 10:59:02AM +0200, Sven Luther wrote: > On Wed, Sep 14, 2005 at 10:31:06AM +0200, Thiemo Seufer wrote: > > Sven Luther wrote: > > [snip] > > > > (Herbert did the same in woody-p-u with 2.4 backports, they had to be > > > > removed before sarge at the price of some user confusion who had t-p-u > > > > in their sources.list.) > > > > > > Well. The packages have smaller version than the sid ones, so there > > > should be > > > no such confusion. > > > > The problem is a different one. Such a package will have a higher version > > number than the next stable security update. It will also block legitimate > > He, they will even have a different package name, so ... > > But maybe you mean the meta-packages, we could chose not to include them, but > then if the kernel team and the security team work more closely together, we > could even provide security for those kernels. > > > sarge updates because of its version unless it is removed, which is an > > unattractive option because the users who need exactly this version can't > > reinstall it any more, and the package still blocks security updates on > > every machine it was installed. > > Only the metapackages, and sure, we can remove them from the backports. All > the other cases have the kernel version embedded in their package name, so > there could be no such issue. > > > > BTW, how are the mips/mipsel integration going ? > > > > Experimental has now a linux-patch-2.6-mips package. > > What is still blocking at this time to get mips integrated into linux-2.6 ? > The last time this came over, i think most of the issues you mentioned as > blocking where solved in the current batch of packages, but maybe there are > soem remaining, could you do a new list, so we can look them over and fix them > if needed ? > > > > Any chance to get those in > > > for 2.6.12-7 ? Do you need any help or something ? Will you be in > > > Oldenbourg > > > this year ? I was under the impression that 2.6.13-1 is well under way and that there is unlikely to be a 2.6.12-7. Has this situation changed? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 06:05:38PM +0900, Horms wrote: > On Wed, Sep 14, 2005 at 10:59:02AM +0200, Sven Luther wrote: > > > > Any chance to get those in > > > > for 2.6.12-7 ? Do you need any help or something ? Will you be in > > > > Oldenbourg > > > > this year ? > > I was under the impression that 2.6.13-1 is well under way and > that there is unlikely to be a 2.6.12-7. Has this situation changed? Not really, altough we have a week at least, and i think it would be good to have both, but more important Thiemo mentioned that mips patches where not yet 2.6.13 ready, and he prefered to get them integrated with 2.6.12 first. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote: > On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote: > > Not a good idea. Why clutter the namespace of versions in order to adapt to > > non-debian needs. ? What is it you intent to do anyway ? Thanks to Bastian Blank, code was added to make your life easier, /proc/version now shows the debian version after the kernel version as : (Debian 2.6.13-1) For example, not yet in released packages, and will not account for self compiled kernels from the debian sources, but it should be usefull to you. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328167: initrd-tools: completely broken with regard to LVM devices on EVMS
On Wed, Sep 14, 2005 at 01:12:15PM +0900, Horms wrote: > first up you should know that we are currently trying really > hard to kill mkinitrd in sid/etch. But initrd-tools is > in Sarge, so I guess that means fixes are still important. I guess a fix for this would be out of scope for sarge. > If /etc/mkinitrd/scripts/evms doesn't exist, should > something else be run instead? Or is just removing > the exit 1, as you suggest, sufficient? EVMS has its own probe.d script. OTOH, now that everything is up and working (I was trying to transition from LVM to EVMS) mkinitrd actually doesn't complain anymore; possibly since the probe.d script already sets ok=1 for the root volume, or something? I still believe the code is wrong, but perhaps the right fix is just to remove the check for /etc/mkinitrd/scripts/evms altogether... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 11:15:33AM +0200, Sven Luther wrote: > On Wed, Sep 14, 2005 at 06:05:38PM +0900, Horms wrote: > > On Wed, Sep 14, 2005 at 10:59:02AM +0200, Sven Luther wrote: > > > > > Any chance to get those in > > > > > for 2.6.12-7 ? Do you need any help or something ? Will you be in > > > > > Oldenbourg > > > > > this year ? > > > > I was under the impression that 2.6.13-1 is well under way and > > that there is unlikely to be a 2.6.12-7. Has this situation changed? > > Not really, altough we have a week at least, and i think it would be good to > have both, but more important Thiemo mentioned that mips patches where not yet > 2.6.13 ready, and he prefered to get them integrated with 2.6.12 first. I'm pretty keen on the idea of maintaining fewer branches rather than more. However, the reason that I asked is that there are some 2.6.13.1 changes that should go into 2.6.12-7 if it is to be released. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 06:30:50PM +0900, Horms wrote: > On Wed, Sep 14, 2005 at 11:15:33AM +0200, Sven Luther wrote: > > On Wed, Sep 14, 2005 at 06:05:38PM +0900, Horms wrote: > > > On Wed, Sep 14, 2005 at 10:59:02AM +0200, Sven Luther wrote: > > > > > > Any chance to get those in > > > > > > for 2.6.12-7 ? Do you need any help or something ? Will you be in > > > > > > Oldenbourg > > > > > > this year ? > > > > > > I was under the impression that 2.6.13-1 is well under way and > > > that there is unlikely to be a 2.6.12-7. Has this situation changed? > > > > Not really, altough we have a week at least, and i think it would be good to > > have both, but more important Thiemo mentioned that mips patches where not > > yet > > 2.6.13 ready, and he prefered to get them integrated with 2.6.12 first. > > I'm pretty keen on the idea of maintaining fewer branches rather than > more. However, the reason that I asked is that there are some 2.6.13.1 > changes that should go into 2.6.12-7 if it is to be released. Andres mentioned we should get 2.6.12-7 out ASAP, so i am not entirely sure about this. I would vote for this too, and maybe wait for 2.6.13 until we get the init* issue sorted out. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Wed, Sep 14, 2005 at 04:27:32PM +0900, Horms wrote: > On Wed, Sep 14, 2005 at 04:54:04AM +0200, Jeroen van Wolffelaar wrote: > > On Tue, Sep 13, 2005 at 08:01:11PM +0200, Sven Luther wrote: > > > Hi, > > > > > > I write this email to ask, now that linux-2.6 2.6.12-6 is in testing, > > > there > > > isn't any reason to keep those 2.6.10 and 2.6.11 kernels around, A quick > > > glance listed those : > > > > (...) > > > > > Also, if there are 2.6.8 kernels in sid/etch still, these can be removed > > > as > > > well. > > > > Please see #317079, #322697 and and #323183. This report is a duplicate from > > what's already in those three reports, so please followup to them where > > appropriate. I already see a duplicate discussion on whether 2.6.8 can be > > removed, so please coordinate in the -kernel team about this, I mailed > > -kernel > > about it before, and there's a bug on the kernel package (#323183) about it. > > First up I'd like to applogise for the confusion and multiple bug > reports surrounding this. The simple truth is that the legacy > of the Sarge-era kernel packaging has left us with a mess, that > we are trying to sift through and slowly clean up. Its turning > out to be quite complicated, and thats not something that > you should have been asked to worry about. > > I suggest that we just track this as 323183, rather than mucking around > with opening and merging existing bugs. Please let me know if you would > prefer a different approach. > > I've just spent a bit of time looking through this and here > is a summary of where I beleive we are, others, please comment > if this is inaccurate or incomplete. If there are ammendments > I'll try and correlate them into an updated list. > > Already removed: > kernel-image-2.6.11-s390(done in Bug #317079) > kernel-image-2.6.11-sparc (done in Bug #317079) > kernel-patch-powerpc-2.6.11 (done in Bug #317079) > kernel-source-2.6.11(done in Bug #317079) > > kernel-image-2.6.10-alpha (done in Bug #322697) > kernel-image-2.6.10-hppa(done in Bug #322697) > kernel-image-2.6.10-sparc (done in Bug #322697) > kernel-source-2.6.10(done in Bug #322697) > > Ready for removal by ftpmasters > kernel-source-2.4.24 > kernel-source-2.4.25 > kernel-source-2.4.26 > > kernel-image-2.6.11-alpha > kernel-image-2.6.11-amd64 > kernel-image-2.6.11-i386 > kernel-image-2.6.11-ia64 > > kernel-patch-2.6.10-hppa > > kernel-latest-2.6-amd64 > > fai-kernels (request from Holger Levsen) > > mol-modules-2.6.11 I just uploaded mol-modules-2.6.12, so once they pass NEW, mol-modules-2.6.12 can go indeed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen.
Package: linux-image-2.6.12-1-powerpc64 Version: 2.6.12-6 Severity: critical Justification: breaks the whole system Both on 7,2 and 7,3 powermacs, these kernels just hang past the first page. I have not copied the msgs by hand, but can do so if necessary. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-power4-smp Locale: LANG=en_US.ISO8859-1, LC_CTYPE=en_US.ISO8859-1 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Versions of packages linux-image-2.6.12-1-powerpc64 depends on: ii coreutils [fileutils] 5.2.1-2.1 The GNU core utilities ii initrd-tools 0.1.82 tools to create initrd image for p ii module-init-tools 3.2-pre8-1 tools for managing Linux kernel mo linux-image-2.6.12-1-powerpc64 recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen.
On Wed, Sep 14, 2005 at 12:54:49PM +0200, Michal wrote: > Package: linux-image-2.6.12-1-powerpc64 > Version: 2.6.12-6 > Severity: critical > Justification: breaks the whole system > > Both on 7,2 and 7,3 powermacs, these kernels just hang past the first page. I > have not copied the msgs by hand, but can do so if necessary. We would like the /proc/cpuinfo of both these machines, and the boot message if possible. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328255: kernel-image-2.6.8-2-k7: VIA VT82C586 isn't recognized on boot
Package: kernel-image-2.6.8-2-k7 Version: 2.6.8-16 Severity: important I have a machine running Sarge, with 2.4 kernel. Motherboard (A8V Deluxe) includes an IDE controller, an IDE RAID, a SATA, a SATA RAID. I also have an adaptec SCSI controller. The system setup uses MD and LVM. Some group include IDE and SCSI disks. No SATA disks are present, no RAID controller is used. I just installed the 2.6 kernel and I cannot see anymore my IDE disk. I checked that the via82cxxx module was loaded and it was. I also added its name in /etc/mkinitrd/modules, creating a new initrd image. Please find attached a log of boot process (got via a serial console) and an output of lspci. I also made the same test with kernel-image-2.6.8-11-amd64-k8 kernel since this is an Athlon64 system, but I got the same result. Thanks, Giuseppe -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages kernel-image-2.6.8-2-k7 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information Bootdata ok (command line is BOOT_IMAGE=Linux64 ro root=fe00 hdc=scsi console=ttyS0,38400 console=tty0) Linux version 2.6.8-11-amd64-k8 ([EMAIL PROTECTED]) (gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)) #1 Mon May 30 22:15:15 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ffb (usable) BIOS-e820: 3ffb - 3ffc (ACPI data) BIOS-e820: 3ffc - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: ff78 - 0001 (reserved) No mptable found. ACPI: RSDP (v002 ACPIAM) @ 0x000fa810 ACPI: XSDT (v001 A M I OEMXSDT 0x01000526 MSFT 0x0097) @ 0x3ffb0100 ACPI: FADT (v003 A M I OEMFACP 0x01000526 MSFT 0x0097) @ 0x3ffb0290 ACPI: MADT (v001 A M I OEMAPIC 0x01000526 MSFT 0x0097) @ 0x3ffb0390 ACPI: OEMB (v001 A M I OEMBIOS 0x01000526 MSFT 0x0097) @ 0x3ffc0040 ACPI: DSDT (v001 A0036 A0036001 0x0001 MSFT 0x010d) @ 0x ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:15 APIC version 16 ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: Assigned apic_id 1 IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ ec00 size 64 MB Built 1 zonelists Kernel command line: BOOT_IMAGE=Linux64 ro root=fe00 hdc=scsi console=ttyS0,38400 console=tty0 Initializing CPU#0 PID hash table entries: 16 (order 4: 256 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 1802.356 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1022708k/1048256k available (1586k kernel code, 24752k reserved, 901k data, 124k init) Calibrating delay loop... 3530.75 BogoMIPS Security Scaffold v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 00 Using local APIC NMI watchdog using perfctr0 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. Detected 12.516 MHz APIC timer. checking if image is initramfs...it isn't (ungzip failed); looks like an initrd NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040326 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 14 15) *0, disabled. usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI interrupt
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 09:18:55AM -0400, Lennart Sorensen wrote: > On Wed, Sep 14, 2005 at 08:19:16AM +0200, Sven Luther wrote: > > The next point would be for base-installer/kernel. I have thought about it > > some, but me talking about that on irc faced only a huge wall of silence, > > so i > > make the proposal here again. > > > > The gist of it is that : > > > > 1) modifying b-i/kernel will break sarge installs with the etch/sid d-i's. > > It is possible to allow both kernel-image and linux-image at the same > time. At least I tried to do so when I modified the sarge installer > to handle linux-image-2.6.12 for amd64 a couple of months ago, although > I didn't keep any kernel-image on the cd so I didn't actually test it. not sure i fully understand what you mean here. I guess you are saying you can kind of fix the b-i/kernel rules to install either linux-image or kernel-image, but that would be counter productive, now that we have some nice unified packages, we can have a simple set of rules for all arches, and make the code much more maitenable. Also, keep in mind that some of the flavours changed between the new packages and the old stuff. > > The last point is that i would much prefer a 1 module per .udeb solution > > over > > the existing mess (where modules are assigned to .udebs in a rather > > arbitrary > > fashion, which often break on non-mainstream arches/subarches). I hear this > > has too much of a packaging overhead (but is this really the case ? Anyone > > claiming this can argument this case with real info ?), so another solution > > for the kernels could be found, where modules are not-packaged ? > > Well how much overhead does a package have? 500 bytes? 100? 2000? > How big is the average kernel module? Looking at 2.6.12 on i386 it > appears to be about 27k/module on average. What is the block size of > initramfs (if it has such a concept). We don't care about initramfs, because the modules which go into the initramfs are already unpacked, and there is thus no overhead, the overhead can only be concerning : 1) the archive space used up on the mirrors. 2) the space used up on the cd medias. 3) the actual download size of the .udebs. 4) maybe the time it takes to process the Packages file on slower arches, and the effect .udeb multiplication has on this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 08:19:16AM +0200, Sven Luther wrote: > Is this not the moment to modify the way our kernel .udeb packages are built, > and either use a single package building all .udebs or at least some common > infrastructure for building them all if there is still problems in the > archive, i feel that anything else would be unreasonable now that all arches > are built from the same source packages (except mips/mipsel, but they will be > folded in soon, i hope). > > Also, i propose that we rename the kernel .udebs to use the linux- prefix, as > the .debs have done, to pave the way of futur non-linux support (hurd, *bsd or > others like opensolaris maybe). This sounds a good time to do so. > > The next point would be for base-installer/kernel. I have thought about it > some, but me talking about that on irc faced only a huge wall of silence, so i > make the proposal here again. > > The gist of it is that : > > 1) modifying b-i/kernel will break sarge installs with the etch/sid d-i's. It is possible to allow both kernel-image and linux-image at the same time. At least I tried to do so when I modified the sarge installer to handle linux-image-2.6.12 for amd64 a couple of months ago, although I didn't keep any kernel-image on the cd so I didn't actually test it. > 2) the kernel .debs are now built from a common package, and it doesn't > really make sense to have 12+ different code snipplet, all being subtly the > same but with individual differences in b-i/kernel. > > So, the secon proposal is to : > > 1) keep the sarge code as is, and use it only when installing sarge. > > 2) propose a new unified b-i/kernel code aiming at etch/sid kernels, and > using the linux-image- thingy. > > This new code could probably just use some per-arch rules to detect flavours, > and it would even be possible in the long run to migrate that code to the main > linux kernel packages, in order keep it at one place only, also porters know > best what flavours match what subarches and so on, but we will see. > > The last point is that i would much prefer a 1 module per .udeb solution over > the existing mess (where modules are assigned to .udebs in a rather arbitrary > fashion, which often break on non-mainstream arches/subarches). I hear this > has too much of a packaging overhead (but is this really the case ? Anyone > claiming this can argument this case with real info ?), so another solution > for the kernels could be found, where modules are not-packaged ? Well how much overhead does a package have? 500 bytes? 100? 2000? How big is the average kernel module? Looking at 2.6.12 on i386 it appears to be about 27k/module on average. What is the block size of initramfs (if it has such a concept). > Anyway, i had a look at the "packaging overhead". Each module .udeb contains a > (rather short) control file (498 bytes for the hfs powerpc modules), a file > hierarchy, and the modules. The overhead over just the modules. The overhead > seems to be 4k per directory node, and a half k for the control file. So is > this really an overhead we are worried about. > > The only real problem would be the number of packages issue, but if we go this > way, we could build the .udebs automatically from the kernel packages, and > then have the whole kernel build problem take only a couple of days for all > autobuilders to build the packages, and there would be no delay due to the > kernel for d-i. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Re: [Alsa-devel] Problems with Hercules DJ Console and the usb-audio driver
Hi CONFIG_USB_BANDWIDTH is enabled by default in the debian kernel. Could this be changed? According to the alsa developer who helped me debug the problem with my usb soundcard CONFIG_USB_BANDWIDTH should be disabled. The original email is forwarded here: - Forwarded message from Clemens Ladisch <[EMAIL PROTECTED]> - From: Clemens Ladisch <[EMAIL PROTECTED]> To: Daniel Svensson <[EMAIL PROTECTED]> Subject: Re: [Alsa-devel] Problems with Hercules DJ Console and the usb-audio driver Daniel Svensson wrote: > Here is the output of "amixer scontents": > ... > Which doesn't match alsamixer controls very well (in count and names). What is the output of "amixer contents"? > Ok, so some progress. The device accepts S16, 6 channels, 48kHz. > Still no output, fails with kernel message: > > ALSA /hom.../usbaudio.c:807: cannot submit datapipe for urb 5, err = -28 28 = ENOSPC. Please disable bandwidth checking in the kernel configuration. (This is a bug of your distribution unless you compiled the kernel yourself.) HTH Clemens --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel - End forwarded message - -- Daniel Svensson <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 09:46:32AM -0400, Lennart Sorensen wrote: > On Wed, Sep 14, 2005 at 03:28:30PM +0200, Sven Luther wrote: > > not sure i fully understand what you mean here. I guess you are saying you > > can > > kind of fix the b-i/kernel rules to install either linux-image or > > kernel-image, but that would be counter productive, now that we have some > > nice > > unified packages, we can have a simple set of rules for all arches, and make > > the code much more maitenable. > > Well is 2.4 kernel images being dropped from etch? Are the archs that > still use 2.4 going to update their images to be linux-image-2.4.x? Well, the goal is indeed to drop 2.4 kernels for most arches in etch, and failing that to have a unified kernel for the remaining arches/subarches that have these 2.4 kernels still left. In the meantime we need indeed to keep something akin to the old code for 2.4 kernels, maybe doing something like : if sarge | 2.4 kernel then use the old code else use the unified code. > Unified rules sure sound nice. > > > Also, keep in mind that some of the flavours changed between the new > > packages > > and the old stuff. > > Well some like -586 seem to have disappeared if I remember correctly. powerp4, power4-smp, power3, power3-smp have been changed to powerpc64. all hppa flavours renamed to include hppa. some other renames like the hppa one i don't remember. > > We don't care about initramfs, because the modules which go into the > > initramfs > > are already unpacked, and there is thus no overhead, the overhead can only > > be > > concerning : > > Ah, good point. > > > 1) the archive space used up on the mirrors. > So the overhead of 1000+ potential modules (although wouldn't some of > them like sound be worth stripping out as irrelevant to the installer?) We would only package those needed for the installer, we can list those in the .udebs actually, there should be around a 100 or so. multiplied by around 50 flavours (maybe less) this brings us around 5000 packages. > > 2) the space used up on the cd medias. > At 2k blocks, 1000 modules would probably add an extra 1M of wasted > block space (assuming each wastes 1/2 of 2K each). Probably not a big > deal really. Well plus any overhead from the package header and > potential loss of compression due to a smaller amount of data to work on > in each package. Well, we may have multiple flavours per arch, but there will definitively not be in the 1000 modules involved here. > > 3) the actual download size of the .udebs. > On the other hand, what if you didn't have to download as many? Would > the installer be able to save ram by not having to load unnecesary > modules? Indeed, i was not going to list pro arguments though :) > > 4) maybe the time it takes to process the Packages file on slower arches, > > and the effect .udeb multiplication has on this. > That could be annoying. Could be, on the other side, slower arches probably have less modules, and this should be less of a problem. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 03:28:30PM +0200, Sven Luther wrote: > not sure i fully understand what you mean here. I guess you are saying you can > kind of fix the b-i/kernel rules to install either linux-image or > kernel-image, but that would be counter productive, now that we have some nice > unified packages, we can have a simple set of rules for all arches, and make > the code much more maitenable. Well is 2.4 kernel images being dropped from etch? Are the archs that still use 2.4 going to update their images to be linux-image-2.4.x? Unified rules sure sound nice. > Also, keep in mind that some of the flavours changed between the new packages > and the old stuff. Well some like -586 seem to have disappeared if I remember correctly. > We don't care about initramfs, because the modules which go into the initramfs > are already unpacked, and there is thus no overhead, the overhead can only be > concerning : Ah, good point. > 1) the archive space used up on the mirrors. So the overhead of 1000+ potential modules (although wouldn't some of them like sound be worth stripping out as irrelevant to the installer?) > 2) the space used up on the cd medias. At 2k blocks, 1000 modules would probably add an extra 1M of wasted block space (assuming each wastes 1/2 of 2K each). Probably not a big deal really. Well plus any overhead from the package header and potential loss of compression due to a smaller amount of data to work on in each package. > 3) the actual download size of the .udebs. On the other hand, what if you didn't have to download as many? Would the installer be able to save ram by not having to load unnecesary modules? > 4) maybe the time it takes to process the Packages file on slower arches, > and the effect .udeb multiplication has on this. That could be annoying. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 10:26:55AM -0400, Lennart Sorensen wrote: > On Wed, Sep 14, 2005 at 03:56:07PM +0200, Sven Luther wrote: > > We would only package those needed for the installer, we can list those in > > the > > .udebs actually, there should be around a 100 or so. multiplied by around 50 > > flavours (maybe less) this brings us around 5000 packages. > > > > Well, we may have multiple flavours per arch, but there will definitively > > not > > be in the 1000 modules involved here. > > Well doing a list of the modules in the current linux-image-2.6.12 on > i386, and then deleting from the list sound, and netfilter and anything > else obviously not needed and probably a few things that would be > needed, I got down to just under 400 modules. Probably most > architectures would have less. how one would automate doing such a > filter I am not sure. Ok. > > Could be, on the other side, slower arches probably have less modules, and > > this should be less of a problem. > > Well unless you have a 386/486 which is still pretty slow. :) But they could benefit from some sort of dpkg-accelerator in general though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 03:56:07PM +0200, Sven Luther wrote: > We would only package those needed for the installer, we can list those in the > .udebs actually, there should be around a 100 or so. multiplied by around 50 > flavours (maybe less) this brings us around 5000 packages. > > Well, we may have multiple flavours per arch, but there will definitively not > be in the 1000 modules involved here. Well doing a list of the modules in the current linux-image-2.6.12 on i386, and then deleting from the list sound, and netfilter and anything else obviously not needed and probably a few things that would be needed, I got down to just under 400 modules. Probably most architectures would have less. how one would automate doing such a filter I am not sure. > Could be, on the other side, slower arches probably have less modules, and > this should be less of a problem. Well unless you have a 386/486 which is still pretty slow. :) Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
Sven Luther wrote: > Is this not the moment to modify the way our kernel .udeb packages are built, It's not a prerequisite for getting a working release of d-i for etch. I think our users are more interested in being able to install using the new kernel. > Also, i propose that we rename the kernel .udebs to use the linux- prefix, as > the .debs have done, to pave the way of futur non-linux support (hurd, *bsd or > others like opensolaris maybe). This sounds a good time to do so. I assume you mean the kernel-image udebs and not all the modules that lack any prefix. I really doubt some other OS will conflict with eg, kernel-image-2.4.27-2-386-di, and IIRC some parts of d-i have the "kernel-image" part of the name hardcoded in them, but a comprehensive patch would not be ignored. > 1) keep the sarge code as is, and use it only when installing sarge. Great, send a patch.. > 2) propose a new unified b-i/kernel code aiming at etch/sid kernels, and > using the linux-image- thingy. > > This new code could probably just use some per-arch rules to detect flavours, > and it would even be possible in the long run to migrate that code to the main > linux kernel packages, in order keep it at one place only, also porters know > best what flavours match what subarches and so on, but we will see. If the kernel team would really like to handle issues like detecting whether an i386 machine running a UP kernel is SMP, I'd be very happy for the code for that to move there. However, I don't think the 1:1 subarch mapping you describe actually exists; it's rife with special cases. Colin already designed the code to factor out common information. > Anyway, i had a look at the "packaging overhead". Each module .udeb contains a > (rather short) control file (498 bytes for the hfs powerpc modules), a file > hierarchy, and the modules. The overhead over just the modules. The overhead > seems to be 4k per directory node, and a half k for the control file. So is > this really an overhead we are worried about. At times in addition to the ramdisk space, up to three programs (main-menu, anna, udpkg) can be running concurrently that all have to hold udeb state in memory. Care to calculate how much memory that would waste? (Make sure to take into account the memory that would have to be used to represent all the inter-module dependencies.) > The only real problem would be the number of packages issue, but if we go this > way, we could build the .udebs automatically from the kernel packages, and > then have the whole kernel build problem take only a couple of days for all > autobuilders to build the packages, and there would be no delay due to the > kernel for d-i. Alternatively, kernel team members who maintain an architecture could already take resposibility for rebuilding (and testing, which your proposal does not take into account, and without which any given kernel upload would be statistically likely to break d-i on some arch) the udebs as part of the release process for a new kernel. There's no reason for the udeb builds to lag the kernel builds by more than a day or two, and they don't for architectures that have an active maintainer already doing this (for 2.6, this is already happening pretty well for i386, sparc, powerpc, and ia64). -- see shy jo signature.asc Description: Digital signature
Re: 2.6.12 is in testing
Lennart Sorensen wrote: > Well doing a list of the modules in the current linux-image-2.6.12 on > i386, and then deleting from the list sound, and netfilter and anything > else obviously not needed and probably a few things that would be > needed, I got down to just under 400 modules. Probably most > architectures would have less. how one would automate doing such a > filter I am not sure. [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.6.12*; do dpkg --contents $d; done |grep \.ko |wc -l 340 [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.4.27*; do dpkg --contents $d; done |grep \.o\$ |wc -l 635 The latter includes the speakup flavour. -- see shy jo signature.asc Description: Digital signature
Re: how to detect a debian kernel from `uname -r`
On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote: > On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote: > > On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote: > > > Not a good idea. Why clutter the namespace of versions in order to adapt > > > to > > > non-debian needs. ? What is it you intent to do anyway ? > > Thanks to Bastian Blank, code was added to make your life easier, > /proc/version now shows the debian version after the kernel version as : > > (Debian 2.6.13-1) > > For example, not yet in released packages, and will not account for self > compiled kernels from the debian sources, but it should be usefull to you. Yes, that's nice thanks! Could you show me a full /proc/version? It's unfortunate my current client isn't logging /proc/version yet, so I should update the client soon. Logging /proc/version is a good idea anyway to know the compiler used. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Wed, Sep 14, 2005 at 04:46:04PM +0200, Andrea Arcangeli wrote: > On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote: > > On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote: > > > On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote: > > > > Not a good idea. Why clutter the namespace of versions in order to > > > > adapt to > > > > non-debian needs. ? What is it you intent to do anyway ? > > > > Thanks to Bastian Blank, code was added to make your life easier, > > /proc/version now shows the debian version after the kernel version as : > > > > (Debian 2.6.13-1) > > > > For example, not yet in released packages, and will not account for self > > compiled kernels from the debian sources, but it should be usefull to you. > > Yes, that's nice thanks! > > Could you show me a full /proc/version? 10:49 < waldi> Linux version 2.6.13-1-powerpc64 (Debian 2.6.13-1) ([EMAIL PROTECTED]) (gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)) #1 SMP Wed Sep 14 09:28:56 UTC 2005 > It's unfortunate my current client isn't logging /proc/version yet, so I > should update the client soon. Logging /proc/version is a good idea > anyway to know the compiler used. Indeed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 11:04:27AM -0400, Joey Hess wrote: > Lennart Sorensen wrote: > > Well doing a list of the modules in the current linux-image-2.6.12 on > > i386, and then deleting from the list sound, and netfilter and anything > > else obviously not needed and probably a few things that would be > > needed, I got down to just under 400 modules. Probably most > > architectures would have less. how one would automate doing such a > > filter I am not sure. > > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.6.12*; do dpkg --contents > $d; done |grep \.ko |wc -l > 340 > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.4.27*; do dpkg --contents > $d; done |grep \.o\$ |wc -l > 635 > > The latter includes the speakup flavour. What exactly did you count above ? the 2.4.27 and 2.6.12 x86 kernel module .udebs ? for all flavours in sid ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 10:53:30AM -0400, Joey Hess wrote: > Sven Luther wrote: > > Is this not the moment to modify the way our kernel .udeb packages are > > built, > > It's not a prerequisite for getting a working release of d-i for etch. I > think our users are more interested in being able to install using the > new kernel. Yeah, well, if the maintainability of the code improves, ... > > Also, i propose that we rename the kernel .udebs to use the linux- prefix, > > as > > the .debs have done, to pave the way of futur non-linux support (hurd, *bsd > > or > > others like opensolaris maybe). This sounds a good time to do so. > > I assume you mean the kernel-image udebs and not all the modules that > lack any prefix. I really doubt some other OS will conflict with eg, > kernel-image-2.4.27-2-386-di, and IIRC some parts of d-i have the > "kernel-image" part of the name hardcoded in them, but a comprehensive > patch would not be ignored. Ok, was just for tydying up anyway. > > 1) keep the sarge code as is, and use it only when installing sarge. > > Great, send a patch.. Well, was planing to work on that in oldenbourg, does that sound great ? > > 2) propose a new unified b-i/kernel code aiming at etch/sid kernels, and > > using the linux-image- thingy. > > > > This new code could probably just use some per-arch rules to detect > > flavours, > > and it would even be possible in the long run to migrate that code to the > > main > > linux kernel packages, in order keep it at one place only, also porters know > > best what flavours match what subarches and so on, but we will see. > > If the kernel team would really like to handle issues like detecting > whether an i386 machine running a UP kernel is SMP, I'd be very happy > for the code for that to move there. However, I don't think the 1:1 > subarch mapping you describe actually exists; it's rife with special > cases. Colin already designed the code to factor out common information. Yep, upto a point, but imagine that code could also be reused for normal upgrades or something. > > Anyway, i had a look at the "packaging overhead". Each module .udeb > > contains a > > (rather short) control file (498 bytes for the hfs powerpc modules), a file > > hierarchy, and the modules. The overhead over just the modules. The overhead > > seems to be 4k per directory node, and a half k for the control file. So is > > this really an overhead we are worried about. > > At times in addition to the ramdisk space, up to three programs > (main-menu, anna, udpkg) can be running concurrently that all have to > hold udeb state in memory. Care to calculate how much memory that would > waste? (Make sure to take into account the memory that would have to be > used to represent all the inter-module dependencies.) Mmm, why is this tripple need of holding udeb state necessary ? Would not solving this go a great way for diminishing general memory usage anyway ? > > The only real problem would be the number of packages issue, but if we go > > this > > way, we could build the .udebs automatically from the kernel packages, and > > then have the whole kernel build problem take only a couple of days for all > > autobuilders to build the packages, and there would be no delay due to the > > kernel for d-i. > > Alternatively, kernel team members who maintain an architecture could > already take resposibility for rebuilding (and testing, which your > proposal does not take into account, and without which any given kernel > upload would be statistically likely to break d-i on some arch) the > udebs as part of the release process for a new kernel. There's no reason Nope, with the common kernel package we did take great care to *NOT* need individual maintainers to do the upload, and to not need each porter to make uploads, and thus we heavily dislike you putting the burden on us like that again (well, i dislike, but i think the rest of the kernel team will echo this). And no, why would d-i break more than the kernels would ? And i believe you should maybe rething the etch/sid separation to handle this, with sid d-i builds being sometimes broken, but etch being ok. That's what we have unstable for :) > for the udeb builds to lag the kernel builds by more than a day or two, > and they don't for architectures that have an active maintainer already > doing this (for 2.6, this is already happening pretty well for i386, > sparc, powerpc, and ia64). Exactly that is the problem, they lag because there is a human factor involved for something which is pretty automated. that said you told me in HEL that you could easily enough setup a automated or semi-automated rebuild and upload infrastucture, so ... I still think my proposal makes more sense in the long run, but let's discuss this more in oldenbourg. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen.
severity 328242 important merge 328242 319986 thanks On Wed, Sep 14, 2005 at 12:54:49PM +0200, Michal wrote: > Both on 7,2 and 7,3 powermacs, these kernels just hang past the first page. I > have not copied the msgs by hand, but can do so if necessary. Read the old bugreports. This is a known problem without solution. Bastian -- Star Trek Lives! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen.
Processing commands for [EMAIL PROTECTED]: > severity 328242 important Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen. Severity set to `important'. > merge 328242 319986 Bug#319986: linux-image-2.6.12-1-powerpc64 fails on dual G5 PowerMac7,3 Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen. Mismatch - only Bugs in same state can be merged: Values for `package' don't match: #319986 has `linux-2.6'; #328242 has `linux-image-2.6.12-1-powerpc64' > 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: 2.6.12 is in testing
Sven Luther wrote: > On Wed, Sep 14, 2005 at 11:04:27AM -0400, Joey Hess wrote: > > Lennart Sorensen wrote: > > > Well doing a list of the modules in the current linux-image-2.6.12 on > > > i386, and then deleting from the list sound, and netfilter and anything > > > else obviously not needed and probably a few things that would be > > > needed, I got down to just under 400 modules. Probably most > > > architectures would have less. how one would automate doing such a > > > filter I am not sure. > > > > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.6.12*; do dpkg > > --contents $d; done |grep \.ko |wc -l > > 340 > > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.4.27*; do dpkg > > --contents $d; done |grep \.o\$ |wc -l > > 635 > > > > The latter includes the speakup flavour. > > What exactly did you count above ? the 2.4.27 and 2.6.12 x86 kernel module > .udebs ? for all flavours in sid ? The number of modules used by d-i in the i386 2.6 and 2.4 kernel udebs. -- see shy jo signature.asc Description: Digital signature
Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen.
On Wed, Sep 14, 2005 at 05:28:10PM +0200, Bastian Blank wrote: > severity 328242 important > merge 328242 319986 > thanks > > On Wed, Sep 14, 2005 at 12:54:49PM +0200, Michal wrote: > > Both on 7,2 and 7,3 powermacs, these kernels just hang past the first page. > > I have not copied the msgs by hand, but can do so if necessary. > > Read the old bugreports. This is a known problem without solution. Well, would be nice if we did indeed found a solution to it though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 11:45:12AM -0400, Joey Hess wrote: > Sven Luther wrote: > > On Wed, Sep 14, 2005 at 11:04:27AM -0400, Joey Hess wrote: > > > Lennart Sorensen wrote: > > > > Well doing a list of the modules in the current linux-image-2.6.12 on > > > > i386, and then deleting from the list sound, and netfilter and anything > > > > else obviously not needed and probably a few things that would be > > > > needed, I got down to just under 400 modules. Probably most > > > > architectures would have less. how one would automate doing such a > > > > filter I am not sure. > > > > > > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.6.12*; do dpkg > > > --contents $d; done |grep \.ko |wc -l > > > 340 > > > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.4.27*; do dpkg > > > --contents $d; done |grep \.o\$ |wc -l > > > 635 > > > > > > The latter includes the speakup flavour. > > > > What exactly did you count above ? the 2.4.27 and 2.6.12 x86 kernel module > > .udebs ? for all flavours in sid ? > > The number of modules used by d-i in the i386 2.6 and 2.4 kernel udebs. So, we have 340 modules i386 2.6 kernels for all flavours, this is not so bad. Powerpc has 441 for powerpc and powerpc64. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 328242 to linux-2.6, merging 328242 319986
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.7 > reassign 328242 linux-2.6 Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen. Bug reassigned from package `linux-image-2.6.12-1-powerpc64' to `linux-2.6'. > merge 328242 319986 Bug#319986: linux-image-2.6.12-1-powerpc64 fails on dual G5 PowerMac7,3 Bug#328242: linux-image-2.6.12-1-powerpc64: This kernel does not boot on Mac G5s (7, 2 and 7, 3). It does not get past the first screen. Merged 319986 328242. > 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]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 11:04:27AM -0400, Joey Hess wrote: > [EMAIL PROTECTED]:~/lib/debian/unstable>for d in *2.6.12*; do dpkg --contents > $d; done |grep \.ko |wc -l > 340 Does that include the missing modules like sata-uli, ahci, etc? Well at least they were missing from the udeb building package a couple of months ago when I grabbed it. I really have to update to the latest one and have a good look at it. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
Sven Luther wrote: > Mmm, why is this tripple need of holding udeb state necessary ? Well, look at the code to main-menu, anna, and udpkg.. > Would not solving this go a great way for diminishing general memory > usage anyway ? No, this is not the current high water mark for memory usage in d-i. That point is currently reached after anna has loaded all the udebs and partman is running, just before swap space is set up. Decreasing the memory used at other points is fairly useless, unless they mushroom all out of control as splitting the module udebs might do. OTOH, splitting the module udebs does indeed have the potential to decrease memory usage at that high water mark. If someone did some work and some tests and got some real numbers that would be fine. I'm a bit tired of the constant empty proposals to do it though. > Nope, with the common kernel package we did take great care to *NOT* need > individual maintainers to do the upload, and to not need each porter to make > uploads, and thus we heavily dislike you putting the burden on us like that > again Someone has to do the work for d-i to support architectures if it will continue to support them. This work is currently largely not being done, and as a result it seems very likely that d-i won't be able to release with support for quite a lot of architectures. I observe that the many of the people who _are_ doing the work to keep d-i working for an architecture are also involved in keeping the kernel working for that architecture, which is IMHO nowhere near as trivial as you make it out to be. > Exactly that is the problem, they lag because there is a human factor involved > for something which is pretty automated. It's either trivial or reasonably hard, depending on what changes have happened in the kernel. > I still think my proposal makes more sense in the long run, but let's discuss > this more in oldenbourg. I don't know what the point is in discussing it over and over if noone is doing the work. -- see shy jo signature.asc Description: Digital signature
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 12:09:31PM -0400, Joey Hess wrote: > Sven Luther wrote: > > Mmm, why is this tripple need of holding udeb state necessary ? > > Well, look at the code to main-menu, anna, and udpkg.. Hehe, will do in Oldenbourg. > > Would not solving this go a great way for diminishing general memory > > usage anyway ? > > No, this is not the current high water mark for memory usage in d-i. > That point is currently reached after anna has loaded all the udebs and > partman is running, just before swap space is set up. Decreasing the > memory used at other points is fairly useless, unless they mushroom all > out of control as splitting the module udebs might do. Ok. > OTOH, splitting the module udebs does indeed have the potential to > decrease memory usage at that high water mark. If someone did some work > and some tests and got some real numbers that would be fine. I'm a bit > tired of the constant empty proposals to do it though. Bah, we will see in two weeks, but see below. BTW, the other proposal was to not packages kernels or .udebs as modules, but i don't know upto what point the d-i infrastructure is upto it. We already have the dependency information thanks to depmod, and could use this, and have all the modules unpacked on the server somewhere. Need to see how we handle the versioning issues though. > > Nope, with the common kernel package we did take great care to *NOT* need > > individual maintainers to do the upload, and to not need each porter to make > > uploads, and thus we heavily dislike you putting the burden on us like that > > again > > Someone has to do the work for d-i to support architectures if it will > continue to support them. This work is currently largely not being done, > and as a result it seems very likely that d-i won't be able to release > with support for quite a lot of architectures. This is indeed the case, but i think it is sign of a generic disafection of d-i coding post sarge release. > I observe that the many of the people who _are_ doing the work to keep > d-i working for an architecture are also involved in keeping the kernel > working for that architecture, which is IMHO nowhere near as trivial as > you make it out to be. Nope, but i don't think there is a real problem in making d-i kernel .udebs working for d-i, if said kernels already worked outside of d-i. And of all the powerpc issues i had with current d-i, i think none where kernel related, but generic code stale because i was the only powerpc guy left to work on d-i. I think powerpc is now in pretty good shape, apart from oldworld, which will be fixed in oldenbourg i hope, and apus/nubus. > > Exactly that is the problem, they lag because there is a human factor > > involved > > for something which is pretty automated. > > It's either trivial or reasonably hard, depending on what changes have > happened in the kernel. It is trivial if there was no api change, and failry automatable in the other case too, The only reason you had problems with it is because you lacked the infrastructure to do it nicely, and the fact that the artificial grouping of kernel modules in package may make floppy media outgrow their size. > > I still think my proposal makes more sense in the long run, but let's > > discuss > > this more in oldenbourg. > > I don't know what the point is in discussing it over and over if noone > is doing the work. Did i not say i intent to work on this in oldenbourg ? Come on it is in two weeks, and i have other things to do right now, what else do you want ? Also, notice that if we get a "no, it is not a good idea" from you, there is really no interest in coding anything, especially on my part and the "you delayed singlehandedly the sarge release by a whole week" trashing i got from you last time i did some modifications of this ilk. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
Sven Luther wrote: > Nope, but i don't think there is a real problem in making d-i kernel > .udebs working for d-i, if said kernels already worked outside of d-i. It's odd that you say this when you have just finished tracking down #327891, which is a perfect example of the kind of issue that can be introduced for an architecture in d-i when upgrading its kernel, and which needs a maintainer to deal with. > It is trivial if there was no api change, and failry automatable in > the other case too No, abi changes are trivial except for coordinating the changes in the other parts of d-i. The only hard part is tracking new modules that need to be added and dealing with changes in intermodule dependencies. > The only reason you had problems with it is because you lacked the > infrastructure to do it nicely, and the fact that the artificial > grouping of kernel modules in package may make floppy media outgrow > their size. Incorrect. Anyway, given the rest of your mail, this conversation is useless. Thread-kill here. -- see shy jo signature.asc Description: Digital signature
Bug#325070: Fix in svn
tags 325070 + pending thanks Peter's patch does the trick, so I've included it in svn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Fix in svn
Processing commands for [EMAIL PROTECTED]: > tags 325070 + pending Bug#325070: XFS - invalid module format There were no tags set. Tags added: pending > 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: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 12:56:38PM -0400, Joey Hess wrote: > Sven Luther wrote: > > Nope, but i don't think there is a real problem in making d-i kernel > > .udebs working for d-i, if said kernels already worked outside of d-i. > > It's odd that you say this when you have just finished tracking down > #327891, which is a perfect example of the kind of issue that can be > introduced for an architecture in d-i when upgrading its kernel, and > which needs a maintainer to deal with. Which was a missing .udeb indeed, and quite bothersome. Not sure if it was introduced by a change in the hfsplus module, or by a change in d-i. That said, this is orthogonal to the issues discussed here. Also notice that if we had one-module-per-udeb and automated dependency handling, this would not have happened at all, so the argument cuts both way. > > It is trivial if there was no api change, and failry automatable in > > the other case too > > No, abi changes are trivial except for coordinating the changes in the > other parts of d-i. The only hard part is tracking new modules that need > to be added and dealing with changes in intermodule dependencies. Notice though that the kernel team already deals with new module introduction when we are faced with new .config entries enabling them or not, and it would not be major work to extend that decision to build it or not, to also think about including them for d-i or not. > > The only reason you had problems with it is because you lacked the > > infrastructure to do it nicely, and the fact that the artificial > > grouping of kernel modules in package may make floppy media outgrow > > their size. > > Incorrect. Ok, then i missed the other argument you where giving me in hel, but i think to remember it was either that or the problem we mentioned above. > Anyway, given the rest of your mail, this conversation is useless. > Thread-kill here. Bah, this is ridiculous, then you complain that people don't participate enough, and you scare them away by refusing to discuss stuff ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302523: kernel-image-2.6.11-9-amd64-k8: module dm_mod locks my IDE disks
Hi, since kernel 2.6.13 has not appeared in Debian yet (hint, hint !), I had a chance to reboot my system, so here is the requested info: # dmsetup ls hda1(253, 0) hdb1(253, 1) # dmsetup info hda1 Name: hda1 State: ACTIVE Tables present:LIVE Open count:0 Event number: 0 Major, minor: 253, 0 Number of targets: 1 # dmsetup info hdb1 Name: hdb1 State: ACTIVE Tables present:LIVE Open count:0 Event number: 0 Major, minor: 253, 1 Number of targets: 1 # dmsetup deps hda1 1 dependencies : (3, 0) # dmsetup deps hdb1 1 dependencies : (3, 64) # dmsetup status hda1 0 234436482 linear # dmsetup status hdb1 0 234436482 linear # dmsetup table hda1 0 234436482 linear 3:0 63 # dmsetup table hdb1 0 234436482 linear 3:64 63 # dmsetup table hda1 0 234436482 linear 3:0 63 # dmsetup table hdb1 0 234436482 linear 3:64 63 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 02:39:56PM -0400, Lennart Sorensen wrote: > On Wed, Sep 14, 2005 at 07:45:25PM +0200, Sven Luther wrote: > > Which was a missing .udeb indeed, and quite bothersome. Not sure if it was > > introduced by a change in the hfsplus module, or by a change in d-i. That > > said, this is orthogonal to the issues discussed here. Also notice that if > > we > > had one-module-per-udeb and automated dependency handling, this would not > > have > > happened at all, so the argument cuts both way. > > Any idea how one would handle loading a module x that depends on module > y being loaded first? How is that currently handled? Are the required > modules always included in the same udeb as the modules that depend on > it? Have a look at : /lib/modules/2.6.12-1-powerpc/modules.dep (or the equivalent for your arch), there we have a dependency list, each module lists his dependency there, and this could be used as is for a non-udeb single module distribution scheme, or used to build the dependencies tree. Currently the modules are grouped per hand in .udebs, partly artificially, partly because they belong to some wide group, and the dependencies are handled by hand. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 07:45:25PM +0200, Sven Luther wrote: > Which was a missing .udeb indeed, and quite bothersome. Not sure if it was > introduced by a change in the hfsplus module, or by a change in d-i. That > said, this is orthogonal to the issues discussed here. Also notice that if we > had one-module-per-udeb and automated dependency handling, this would not have > happened at all, so the argument cuts both way. Any idea how one would handle loading a module x that depends on module y being loaded first? How is that currently handled? Are the required modules always included in the same udeb as the modules that depend on it? Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
Package: linux-image-2.6.12-1-powerpc64 Version: 2.6.12-6 Severity: wishlist Upon reading "Announcing powerpc backport 2.6.12-6 kernel package for sarge", http://lists.debian.org/debian-powerpc/2005/09/msg00135.html , I figured I would give that a try on an Xserve G5. I notice that /usr/share/doc/linux-image-2.6.12-1-powerpc64/changelog.Debian.gz says: * New upstream release: ... - readdition of tg3 driver, as firmware license has been fixed Sounds good. BUT! /boot/config-2.6.12-1-powerpc64: # CONFIG_TIGON3 is not set :( - since this Xserve G5 needs that to network. My main motivation was to get the fans to quiet down (they run full speed in 2.6.8-power4-smp since therm_pm72 doesn't handle them right in that version). I look forward to someday soon having a linux-image-2.6.12-1-powerpc64 that supports Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03) and perhaps lets the fans run slower when possible. Until then it'll run kernel-image-2.6.8-power4-smp. Thanks, -Maitland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RM: please remove ia64 2.4 kernel packages from unstable
Package: ftp.debian.org Support for 2.4 kernels on ia64 will be dropped for etch. I've already removed ia64/2.4 support from d-i: ok, I see it I think we can remove the 2.4 udebs for ia64 joeyh: great - i'll file the f.d.o. bugs then So, please remove the following packages from sid: - kernel-image-2.4.27-ia64 - kernel-patch-2.4.27-ia64 - linux-kernel-di-ia64 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
On Wed, Sep 14, 2005 at 03:56:39PM -0400, A. Maitland Bottoms wrote: > Package: linux-image-2.6.12-1-powerpc64 > Version: 2.6.12-6 > Severity: wishlist > > Upon reading "Announcing powerpc backport 2.6.12-6 kernel package for sarge", > http://lists.debian.org/debian-powerpc/2005/09/msg00135.html , > I figured I would give that a try on an Xserve G5. > > > I notice that > /usr/share/doc/linux-image-2.6.12-1-powerpc64/changelog.Debian.gz says: > > * New upstream release: > ... > - readdition of tg3 driver, as firmware license has been fixed > > Sounds good. > > BUT! > /boot/config-2.6.12-1-powerpc64: > # CONFIG_TIGON3 is not set > > :( - since this Xserve G5 needs that to network. Waht can i say ? Don't use hardware which needs non-free drivers. Now, if they are not freed, we have some non-free modules, including tg3 i think, which needs to be built, this will come soon. > My main motivation was to get the fans to quiet down (they > run full speed in 2.6.8-power4-smp since therm_pm72 doesn't > handle them right in that version). This should be fixed. > I look forward to someday soon having a linux-image-2.6.12-1-powerpc64 > that supports > Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet > (rev 03) > and perhaps lets the fans run slower when possible. So, ask broadcom to not include non-free firmware code in their drivers. You can even get the non-free-modules package out of the kernel svn, and build it yourself, if you feel like it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
Sven Luther wrote: > Currently the modules are grouped per hand in .udebs, partly artificially, > partly because they belong to some wide group, and the dependencies are > handled by hand. THe above statement is incorrect. Read /usr/share/kernel-wedge/commands/copy-modules or even the documentation for kernel-wedge. -- see shy jo signature.asc Description: Digital signature
Re: 2.6.12 is in testing
Sven Luther wrote: > Which was a missing .udeb indeed No it wasn't: | Added nls_utf8 to fs-common-modules (Closes: #327891). > introduced by a change in the hfsplus module, or by a change in d-i. That > said, this is orthogonal to the issues discussed here. Also notice that if we > had one-module-per-udeb and automated dependency handling, this would not have > happened at all, so the argument cuts both way. [EMAIL PROTECTED]:~>zgrep dependency /usr/share/doc/kernel-wedge/README.gz happen for a particular dependency, follow it by a "!" The dependency information from modules.dep is compared with the output of the "kernel-wedge gen-deps" command, which extracts dependency information -- see shy jo signature.asc Description: Digital signature
Bug#328324: please build powerpc64 kernel with tg3 support
Sven Luther writes: > > # CONFIG_TIGON3 is not set > > > > :( - since this Xserve G5 needs that to network. > > Waht can i say ? Don't use hardware which needs non-free drivers. > > Now, if they are not freed, we have some non-free modules, including tg3 i > think, which needs to be built, this will come soon. > Well I did know that Debian had purged tg3, but then I noticed that they are in linux-2.6 (2.6.12-6) source, with the "readdition" note in the changelog in the (2.6.12-1) version section. > > My main motivation was to get the fans to quiet down (they > > This should be fixed. Yes, it is. > > > I look forward to someday soon having a linux-image-2.6.12-1-powerpc64 > > that supports > > Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit > > Ethernet (rev 03) > > and perhaps lets the fans run slower when possible. > > So, ask broadcom to not include non-free firmware code in their drivers. > > You can even get the non-free-modules package out of the kernel svn, and > build > it yourself, if you feel like it. > > Friendly, > > Sven Luther I think I'll just try building out of the linux-2.6 Debian source package. Where is the svn for Debian's linux-2.6 kernel tree? I'd like to run svn blame to see where the changelog line came from: - readdition of tg3 driver, as firmware license has been fixed. Maybe that wasn't quite right. I think that your interpretation of the fix in firmware license is that it improves the situation from undistributable to non-free distributable. So, perhaps this bug needs to be reassigned to linux-26, and retitled to "non-free content in kernel source packages in main should be removed (again)". Thanks, -Maitland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 05:45:54PM -0400, Joey Hess wrote: > Sven Luther wrote: > > Currently the modules are grouped per hand in .udebs, partly artificially, > > partly because they belong to some wide group, and the dependencies are > > handled by hand. > > THe above statement is incorrect. Read > /usr/share/kernel-wedge/commands/copy-modules or even the documentation > for kernel-wedge. Oh, sorry then, i misunderstood the current setup, i didn't really look beyond the individual listing of all modules. Those are assembled by hand though ? Or at least i always modified those by hand, was there a more subtle way to do it ? Mmm, i believe your comment was about the dependencies, sorry, that was indeed a typo on my part. I wanted to say that the dependencies are between the groups of packages, not that they are added by hand, got distracted at that moment. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
On Wed, Sep 14, 2005 at 05:50:19PM -0400, A. Maitland Bottoms wrote: > Sven Luther writes: >- readdition of tg3 driver, as firmware license has been fixed. > > Maybe that wasn't quite right. I think that your interpretation of the > fix in firmware license is that it improves the situation from undistributable > to non-free distributable. Current status is that the firmware is no more non-distributable but still non-free, last notice was that it was indeed in the non-free module package. Andres maybe you can confirm this ? > So, perhaps this bug needs to be reassigned to linux-26, and retitled to > "non-free content in kernel source packages in main should be removed > (again)". Its all the same thing, i think the changelog is maybe confusing. but this and linux-2.6 are the same package now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
A. Maitland Bottoms wrote: [snip] > I think I'll just try building out of the linux-2.6 Debian source package. > > Where is the svn for Debian's linux-2.6 kernel tree? http://svn.debian.org/ , Project "kernel". > I'd like to run > svn blame to see where the changelog line came from: > >- readdition of tg3 driver, as firmware license has been fixed. > > Maybe that wasn't quite right. Tg3 is built for most other architectures. > I think that your interpretation of the > fix in firmware license is that it improves the situation from undistributable > to non-free distributable. > > So, perhaps this bug needs to be reassigned to linux-26, and retitled to > "non-free content in kernel source packages in main should be removed > (again)". Or probably "re-enable tg3 for powerpc and arm". Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, 2005-09-14 at 12:41 +0200, Sven Luther wrote: > Andres mentioned we should get 2.6.12-7 out ASAP, so i am not entirely sure > about this. I would vote for this too, and maybe wait for 2.6.13 until we get > the init* issue sorted out. I just committed a fix to .12 & .13 that repairs a problem that made both uniprocessor ia64 flavors useless, so I'd like to see something sooner than later to avoid causing more unbootable systems. I assume a 2.6.12-7 would be the fastest route, so I vote for that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, 2005-09-14 at 11:18 +0900, Horms wrote: > On Tue, Sep 13, 2005 at 11:34:13AM +0200, Sven Luther wrote: > > On Tue, Sep 13, 2005 at 05:51:18PM +0900, Horms wrote: > > > > http://packages.vergenet.net/testing/linux-2.6/ > > > > > > I have done a second build, with the following changes, as > > > 2.6.12-5.99.sarge2 > > > Only the first change is relevant, URL as immediately above :) > > > > > >* Change kernel-source build dependancy to > > > kernel-package (>= 8.135) [!powerpc] | kernel-package (>= > > > 8.135.sarge1) [powerpc] > > > so that this package can be build on an unmodified sarge install > > > on non-powerpc > > >* Add myself and Sven Luther as uploaders > > > > Maybe we should move that stuff to the SVN, under dists/sarge/backports or > > something such ? Having backports in the name (sarge/backports or sarge-backports) sounds better to me. When etch ships we'll have linux-2.6 under dists/etch (under current conventions) - if we wanna add a backport of a newer version, we'll have a namespace conflict. (Ok, that's a ways in the future, but...) They are also pretty descriptive names which should help avoid confusion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: In preparation for 2.6.13 - initrd issues
In linux.debian.kernel Frans Pop <[EMAIL PROTECTED]> wrote: >there already is support for udev in d-i; what's currently missing is a >udeb for hotplug. Thinking again about this: an hotplug udeb is not be strictly needed, because current versions of udev already provide the hotplug multiplexer. The hotplug package currently provides: - a firmware loader hotplug agent - support for hotplug of network devices - coldplug (hardware detection and loading the drivers) I think that d-i actually needs only the first item, and since it's not critical for many devices I will deal with it later. So the next udev-udeb package will not depend anymore on hotplug-udeb. (I do not follow closely d-i developement, so if something is needed from my packages please send mail or look for me on IRC ASAP.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Wed, Sep 14, 2005 at 04:27:32PM +0900, Horms wrote: > On Wed, Sep 14, 2005 at 04:54:04AM +0200, Jeroen van Wolffelaar wrote: > > On Tue, Sep 13, 2005 at 08:01:11PM +0200, Sven Luther wrote: > > > Hi, > > > > > > I write this email to ask, now that linux-2.6 2.6.12-6 is in testing, > > > there > > > isn't any reason to keep those 2.6.10 and 2.6.11 kernels around, A quick > > > glance listed those : > > > > (...) > > > > > Also, if there are 2.6.8 kernels in sid/etch still, these can be removed > > > as > > > well. > > > > Please see #317079, #322697 and and #323183. This report is a duplicate from > > what's already in those three reports, so please followup to them where > > appropriate. I already see a duplicate discussion on whether 2.6.8 can be > > removed, so please coordinate in the -kernel team about this, I mailed > > -kernel > > about it before, and there's a bug on the kernel package (#323183) about it. > > First up I'd like to applogise for the confusion and multiple bug > reports surrounding this. The simple truth is that the legacy > of the Sarge-era kernel packaging has left us with a mess, that > we are trying to sift through and slowly clean up. Its turning > out to be quite complicated, and thats not something that > you should have been asked to worry about. I understand, > I suggest that we just track this as 323183, rather than mucking around > with opening and merging existing bugs. Please let me know if you would > prefer a different approach. No, that is fine. Having just one report makes things easiest -- though the most important thing is a clear overview of which sourcepackages are really ready to be removed and which are not yet -- an overview which you've succeeded quite well to produce. > I've just spent a bit of time looking through this and here > is a summary of where I beleive we are, others, please comment > if this is inaccurate or incomplete. If there are ammendments > I'll try and correlate them into an updated list. > > Already removed: > kernel-image-2.6.11-s390(done in Bug #317079) > kernel-image-2.6.11-sparc (done in Bug #317079) > kernel-patch-powerpc-2.6.11 (done in Bug #317079) > kernel-source-2.6.11(done in Bug #317079) > > kernel-image-2.6.10-alpha (done in Bug #322697) > kernel-image-2.6.10-hppa(done in Bug #322697) > kernel-image-2.6.10-sparc (done in Bug #322697) > kernel-source-2.6.10(done in Bug #322697) Indeed, I removed both source packages and all of the kernel-* stuff that was broken by that removal. I did leave some 3rd-party packages around that seemed like they 'just' needed to be upgraded to 2.6.12. > Ready for removal by ftpmasters > kernel-source-2.4.24 > kernel-source-2.4.25 > kernel-source-2.4.26 Reverse-dependencies: ** pcmcia-modules-2.4.26-i386 has an unsatisfied build-dependency: kernel-tree-2.4.26-2 ** user-mode-linux has an unsatisfied build-dependency: kernel-source-2.4.26 I guess pcmcia-modules-2.4.26-i386 should be dropped too, and user-mode-linux left broken for the moment? > kernel-image-2.6.11-alpha > kernel-image-2.6.11-amd64 > kernel-image-2.6.11-i386 > kernel-image-2.6.11-ia64 All gone already ttbomk. > kernel-patch-2.6.10-hppa Still around, ok. > kernel-latest-2.6-amd64 Ditto -- shouldn't this one be simply superseded by packages generated by a next upload of linux-2.6? > fai-kernels (request from Holger Levsen) > > mol-modules-2.6.11 Ok. After you clarified my two minor questions, could you please reassign this bug back to ftp.debian.org? I'll then remove all packages mentioned from "Ready for removal by ftpmasters" up until here. You can then open a new bug for the packages mentioned below when the time is there. > Will be ready for removal once d-i moves from 2.6.8 to 2.6.12 > (...) > Not ready for removal > (...) Thanks a lot, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, 2005-09-14 at 11:18 +0900, Horms wrote: > On Tue, Sep 13, 2005 at 11:34:13AM +0200, Sven Luther wrote: > > On Tue, Sep 13, 2005 at 05:51:18PM +0900, Horms wrote: > > > > http://packages.vergenet.net/testing/linux-2.6/ > > > > > > I have done a second build, with the following changes, as > > > 2.6.12-5.99.sarge2 > > > Only the first change is relevant, URL as immediately above :) > > > > > >* Change kernel-source build dependancy to > > > kernel-package (>= 8.135) [!powerpc] | kernel-package (>= > > > 8.135.sarge1) [powerpc] > > > so that this package can be build on an unmodified sarge install > > > on non-powerpc > > >* Add myself and Sven Luther as uploaders > > > > Maybe we should move that stuff to the SVN, under dists/sarge/backports or > > something such ? > > Yes, i think that would be an excellent idea. > perhaps just put it in dists/sarge, or if you want > to make a distinction, dists/sarge-backports (cc list trimmed) I started work on the latter by svn_load_dirs'ing sarge1 into place. I can do the same w/ sarge2 once I can get at the source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: In preparation for 2.6.13 - initrd issues
Marco d'Itri wrote: > Thinking again about this: an hotplug udeb is not be strictly needed, > because current versions of udev already provide the hotplug multiplexer. > > The hotplug package currently provides: > - a firmware loader hotplug agent > - support for hotplug of network devices > - coldplug (hardware detection and loading the drivers) > > I think that d-i actually needs only the first item, and since it's not > critical for many devices I will deal with it later. > So the next udev-udeb package will not depend anymore on hotplug-udeb. The idea is to possibly switch d-i to using hotplug for all (or at least most) hardware detection, so that the installer and installed systems do not detect hardware in different ways that cause incompatabilities. For that to work we'd need at least coldplug support and proper hotplug wouldn't hurt. For example, this is a code fragment from d-i's existing hw-detect which has been patched with the hotplug support from ubuntu for a while: if [ "$HOTPLUG_TYPE" = real ]; then /lib/debian-installer/coldplug fi (Not sure why it's in /lib/debian-installer in this example) -- see shy jo signature.asc Description: Digital signature
Re: Announcing powerpc backport 2.6.12-6 kernel package for sarge
On Wed, Sep 14, 2005 at 04:48:46PM -0600, dann frazier wrote: > On Wed, 2005-09-14 at 12:41 +0200, Sven Luther wrote: > > Andres mentioned we should get 2.6.12-7 out ASAP, so i am not entirely sure > > about this. I would vote for this too, and maybe wait for 2.6.13 until we > > get > > the init* issue sorted out. > > I just committed a fix to .12 & .13 that repairs a problem that made > both uniprocessor ia64 flavors useless, so I'd like to see something > sooner than later to avoid causing more unbootable systems. I assume a > 2.6.12-7 would be the fastest route, so I vote for that. Ok, it sounds increasingly likely that 2.6.12-7 is going to happen. I'll go ahead and deal with the 2.6.13.1 patches that are appropriate. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Thu, Sep 15, 2005 at 01:35:47AM +0200, Jeroen van Wolffelaar wrote: [snip] > > I suggest that we just track this as 323183, rather than mucking around > > with opening and merging existing bugs. Please let me know if you would > > prefer a different approach. > > No, that is fine. Having just one report makes things easiest -- though the > most important thing is a clear overview of which sourcepackages are really > ready to be removed and which are not yet -- an overview which you've > succeeded quite well to produce. Thanks, hopefully we can get to the bottom of this sooner rather than later [snip] Matt Zimmerman, the maintainer, has indicated that he is not interested in updating uml to 2.6, which in his oppinion is the only way forward. I guess the package should be orphaned or removed from the archive. But in any case it seems that it shouldn't block the removal of kernel-source-2.4.26. I have CCed Matt so he can clarify this. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323183;msg=25 With regards to pcmcia-modules-2.4.26-i386. I notice that pcmcia-modules-2.4.27-i386 exists and presumably works. I've CCed the maintainer, Per Olofsson for comment. > > kernel-image-2.6.11-alpha > > kernel-image-2.6.11-amd64 > > kernel-image-2.6.11-i386 > > kernel-image-2.6.11-ia64 > > All gone already ttbomk. > > > kernel-patch-2.6.10-hppa > > Still around, ok. > > > kernel-latest-2.6-amd64 > > Ditto -- shouldn't this one be simply superseded by packages generated by a > next upload of linux-2.6? amd64 still doesn't seem to exist for linux-2.6, I'm not sure why, perhaps I am just blind or looking in the wrong place http://ftp2.jp.debian.org/debian/pool/main/l/linux-2.6/ However, once it is uploaded, it will have binary packages with the same names as those previously produced by the kernel-latest-2.6-amd64 source package. Does this mean that kernel-latest-2.6-amd64 will automatically be removed, or automatically flagged for removal? > > fai-kernels (request from Holger Levsen) > > > > mol-modules-2.6.11 > > Ok. > > After you clarified my two minor questions, could you please reassign this bug > back to ftp.debian.org? I'll then remove all packages mentioned from "Ready > for removal by ftpmasters" up until here. You can then open a new bug for the > packages mentioned below when the time is there. [snip] I'll wait for some feedback from Matt and Per and do just that. Could you clarify the sistuation with regards to kernel-latest-2.6-amd64 being removed once linux-2.6 for amd64 is uploaded. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328389: CAN-2005-2800: memory leak in scsi procfs leads to local DoS
Package: kernel-source-2.6.8 Version: 2.6.8-16 Severity: important In http://www.securityfocus.com/bid/14790 a memory leak is reported in the linux kernel. They reference http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=729d70f5dfd663b44bca68a4479c96bde7e535d6 which has a patch for drivers/scsi/sg.c I've browsed around on http://svn.debian.org/wsvn/kernel/, but not found any references to this problem. So hopefully I've not duplicated any work! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322237: ipt_recent patch
Just FYI, this has been assigned CAN-2005-2802. -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Thu, Sep 15, 2005 at 11:19:37AM +0900, Horms wrote: > On Thu, Sep 15, 2005 at 01:35:47AM +0200, Jeroen van Wolffelaar wrote: > > (...) > Thanks, hopefully we can get to the bottom of this sooner rather > than later I hope so too :) > With regards to pcmcia-modules-2.4.26-i386. > I notice that pcmcia-modules-2.4.27-i386 exists and presumably works. > I've CCed the maintainer, Per Olofsson for comment. Ok, either way, since 2.4.27 exists, I won't let pcmcia-modules-2.4.26 block removal. > > > kernel-latest-2.6-amd64 > > > > Ditto -- shouldn't this one be simply superseded by packages generated by a > > next upload of linux-2.6? > > amd64 still doesn't seem to exist for linux-2.6, I'm not sure why, > perhaps I am just blind or looking in the wrong place > > http://ftp2.jp.debian.org/debian/pool/main/l/linux-2.6/ > > However, once it is uploaded, it will have binary packages with > the same names as those previously produced by the > kernel-latest-2.6-amd64 source package. Does this mean that > kernel-latest-2.6-amd64 will automatically be removed, or automatically > flagged for removal? Yes, if all binary packages of a give source package are 'hijacked' by another package, the source package will be automatically flagged for removal, and packages automatically flagged for removal will be removed by an ftp-team member every few days. So, no action needed, and not removing will ensure a smooth transition. > Thanks Thanks you, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Alsa-devel] Problems with Hercules DJ Console and the usb-audio driver
On Wed, Sep 14, 2005 at 03:29:13PM +0200, Daniel Svensson wrote: > Hi > > CONFIG_USB_BANDWIDTH is enabled by default in the debian kernel. Could > this be changed? According to the alsa developer who helped me debug the > problem with my usb soundcard CONFIG_USB_BANDWIDTH should be disabled. > The original email is forwarded here: That sounds fair enough to me, as long there are no objections from the rest of the kernel-team. Clemens, could you provide a little more information on the problems that CONFIG_USB_BANDWIDTH causes? Thanks -- Horms > - Forwarded message from Clemens Ladisch <[EMAIL PROTECTED]> - > > From: Clemens Ladisch <[EMAIL PROTECTED]> > To: Daniel Svensson <[EMAIL PROTECTED]> > Subject: Re: [Alsa-devel] Problems with Hercules DJ Console and the usb-audio > driver > > Daniel Svensson wrote: > > Here is the output of "amixer scontents": > > ... > > Which doesn't match alsamixer controls very well (in count and names). > > What is the output of "amixer contents"? > > > Ok, so some progress. The device accepts S16, 6 channels, 48kHz. > > Still no output, fails with kernel message: > > > > ALSA /hom.../usbaudio.c:807: cannot submit datapipe for urb 5, err = -28 > > 28 = ENOSPC. Please disable bandwidth checking in the kernel > configuration. (This is a bug of your distribution unless you > compiled the kernel yourself.) > > > HTH > Clemens > > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > Alsa-devel mailing list > Alsa-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-devel > > > - End forwarded message - > > -- > Daniel Svensson <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322237: ipt_recent patch
Geoff Crompton wrote: > Just FYI, this has been assigned CAN-2005-2802. > Oops. Just noticed that this has actually been assigned CAN-2005-2872, which is the one that is actually referenced in all the debian kernel svn logs. Sorry! http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2802 -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328394: 2.6.12 kills speedstep on Thinkpad T20
Package: kernel Version: 2.6.12-6 I upgraded from 2.6.10 kernel to 2.6.12 and my Thinkpad T20 (a) fails to load speedstep. I downgraded to 2.6.10 kernel and it works fine again. My T23 had NO similar problem. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328395: CAN-2005-2801: ext2 ext3 xattr access control bypass
Package: linux-2.6 Severity: important Ref http://www.securityfocus.com/bid/14793 The kernel team is aware of this issue, and fixes are in the kernel teams svn at svn.debian.org. I created this report so as I couldn't find this issue mentioned in the BTS. Please tag it with security and sarge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
split-config
Hi, I noticed two potential problems while trying to manipulate the kernel configs to consistently turn USB_BANDWIDTH on or off. 1) split-config does not seem to work with architecures such as amd64 and powerpc where the architecture name the kernel uses differes from the name that debian uses. Is the best way to resolve this by adding a simple mapping in split-config? 2) Running splitconfig for 386, seems to need to be run multiple times to stablilise the config, even if no options are changed. The attached patch reflects the config changes effected by the following sequence of events run on the current dists/trunk/linux-2.6 and 2.6.13 from kernel.org Note that the patch disables CONFIG_FB_VESA for amd64 as a side effect of the opperations below. I tried to rectify this using split-config and arrived at problem 1 above. # ~/blah/scripts/split-config debian/arch/ 386 make[2]: warning: -jN forced in submake: disabling jobserver mode. scripts/kconfig/mconf arch/i386/Kconfig # # using defaults found in .config # .config:56: trying to assign nonexistent symbol GAMEPORT_VORTEX .config:93: trying to assign nonexistent symbol DEVFS_DEBUG .config:138: trying to assign nonexistent symbol DEVFS_FS .config:214: trying to assign nonexistent symbol SND_VXP440 .config:233: trying to assign nonexistent symbol SCSI_PCI2220I .config:251: trying to assign nonexistent symbol DVB_DIBCOM_DEBUG .config:328: trying to assign nonexistent symbol DVB_DIBUSB .config:383: trying to assign nonexistent symbol MTD_ELAN_104NC .config:467: trying to assign nonexistent symbol SERIAL_8250_MULTIPORT .config:895: trying to assign nonexistent symbol DVB_DIBUSB_MISDESIGNED_DEVICES .config:1028: trying to assign nonexistent symbol DEVFS_MOUNT .config:1069: trying to assign nonexistent symbol JFFS2_FS_NAND .config:1169: trying to assign nonexistent symbol SCSI_PCI2000 .config:1217: trying to assign nonexistent symbol DVB_B2C2_SKYSTAR .config:1413: trying to assign nonexistent symbol GAMEPORT_CS461X .config:2136: trying to assign nonexistent symbol JFFS2_FS_NOR_ECC [ nothing modified in menuconfig ] *** End of Linux kernel configuration. *** Execute 'make' to build the kernel or try 'make help'. CONFIG_HZ_250=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_HZ_100=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_FLATMEM_MANUAL=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_PHYSICAL_START=0x10 has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_MTD_PCMCIA_ANONYMOUS=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_SERIAL_8250_MCA=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_SELECT_MEMORY_MODEL=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_SPARSEMEM_MANUAL=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_KEXEC=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_FLAT_NODE_MEM_MAP=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_FLATMEM=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_ACPI_HOTKEY=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_SCSI_QLA2XXX=m has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_DISCONTIGMEM_MANUAL=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_ACPI_SLEEP_PROC_SLEEP=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_JFFS2_FS_WRITEBUFFER=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_EXT2_FS_XIP=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_HZ_1000=n has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_HZ=250 has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_I2O_CONFIG_OLD_IOCTL=y has been added. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G CONFIG_FUSION has been changed from 'm' to 'y'. Do you want to make this change [G]lobal, per-[A]rch, or per-[F]lavour? [GAF] G # ~/blah/scripts/split-config debian/arch/ 386 make[2]: warning: -jN forced in submake: disabling jobserver mode. scripts/kconfig/mconf arch/i386/Kconfig # # using defaults found in .config # .config:56: trying to assign n
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Thu, Sep 15, 2005 at 04:50:26AM +0200, Jeroen van Wolffelaar wrote: > On Thu, Sep 15, 2005 at 11:19:37AM +0900, Horms wrote: > > On Thu, Sep 15, 2005 at 01:35:47AM +0200, Jeroen van Wolffelaar wrote: > > > (...) > > Thanks, hopefully we can get to the bottom of this sooner rather > > than later > > I hope so too :) > > > With regards to pcmcia-modules-2.4.26-i386. > > I notice that pcmcia-modules-2.4.27-i386 exists and presumably works. > > I've CCed the maintainer, Per Olofsson for comment. > > Ok, either way, since 2.4.27 exists, I won't let pcmcia-modules-2.4.26 block > removal. > > > > > kernel-latest-2.6-amd64 > > > > > > Ditto -- shouldn't this one be simply superseded by packages generated by > > > a > > > next upload of linux-2.6? > > > > amd64 still doesn't seem to exist for linux-2.6, I'm not sure why, > > perhaps I am just blind or looking in the wrong place > > > > http://ftp2.jp.debian.org/debian/pool/main/l/linux-2.6/ > > > > However, once it is uploaded, it will have binary packages with > > the same names as those previously produced by the > > kernel-latest-2.6-amd64 source package. Does this mean that > > kernel-latest-2.6-amd64 will automatically be removed, or automatically > > flagged for removal? > > Yes, if all binary packages of a give source package are 'hijacked' by another > package, the source package will be automatically flagged for removal, and > packages automatically flagged for removal will be removed by an ftp-team > member every few days. > > So, no action needed, and not removing will ensure a smooth transition. Thanks, I'll prepare a fresh list for you ASAP. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
reassign 323183 ftp.debian.org thanks As requested, here is an updated list of kernel and related packages to be removed at this time. This does not include 2.6.8 and related packages. Its probably best to handle them in a separate bug once d-i no longer needs them. kernel-source-2.4.24 kernel-source-2.4.25 kernel-source-2.4.26 kernel-patch-2.6.10-hppa fai-kernels (request from Holger Levsen) mol-modules-2.6.11 (mol-modules-2.6.12 is in new) This is also separate from #328325, requesting the removal of the following packages: kernel-image-2.4.27-ia64 kernel-patch-2.4.27-ia64 linux-kernel-di-ia64 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
On Thu, Sep 15, 2005 at 12:29:29AM +0200, Thiemo Seufer wrote: > A. Maitland Bottoms wrote: > [snip] > > I think I'll just try building out of the linux-2.6 Debian source package. > > > > Where is the svn for Debian's linux-2.6 kernel tree? > > http://svn.debian.org/ , Project "kernel". > > > I'd like to run > > svn blame to see where the changelog line came from: > > > >- readdition of tg3 driver, as firmware license has been fixed. > > > > Maybe that wasn't quite right. > > Tg3 is built for most other architectures. > > > I think that your interpretation of the > > fix in firmware license is that it improves the situation from > > undistributable > > to non-free distributable. > > > > So, perhaps this bug needs to be reassigned to linux-26, and retitled to > > "non-free content in kernel source packages in main should be removed > > (again)". > > Or probably "re-enable tg3 for powerpc and arm". Unless there are technical problems, for instance, tg3 oopses all the time on arm (i made that up), it should either be on or off uniformly for all achitecturs. The licencing battle should be done at the source level - if its in our tree then its fair game to be turned on. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328324: please build powerpc64 kernel with tg3 support
On Thu, Sep 15, 2005 at 12:29:29AM +0200, Thiemo Seufer wrote: > A. Maitland Bottoms wrote: > [snip] > > I think I'll just try building out of the linux-2.6 Debian source package. > > > > Where is the svn for Debian's linux-2.6 kernel tree? > > http://svn.debian.org/ , Project "kernel". > > > I'd like to run > > svn blame to see where the changelog line came from: > > > >- readdition of tg3 driver, as firmware license has been fixed. > > > > Maybe that wasn't quite right. > > Tg3 is built for most other architectures. Well, Andres mentioned the contrary to me, and i don't have a checked out three on this box, so you may be right. We need to comonize the tg3 option too. > > I think that your interpretation of the > > fix in firmware license is that it improves the situation from > > undistributable > > to non-free distributable. > > > > So, perhaps this bug needs to be reassigned to linux-26, and retitled to > > "non-free content in kernel source packages in main should be removed > > (again)". > > Or probably "re-enable tg3 for powerpc and arm". Well, that would be fine and all, but : The licence change made the tg3 firmware distributable again, but it is still no free software by any stretch of the imagination. So, if we add it again, then we indeed are going counter to our previous position, and counter to what happened during that vote. I am not sure it is a good idea to do that silently. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328389: CAN-2005-2800: memory leak in scsi procfs leads to local DoS
On Thu, Sep 15, 2005 at 12:25:57PM +1000, Geoff Crompton wrote: > Package: kernel-source-2.6.8 > Version: 2.6.8-16 > Severity: important > > In http://www.securityfocus.com/bid/14790 a memory leak is reported in > the linux kernel. > > They reference > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=729d70f5dfd663b44bca68a4479c96bde7e535d6 > which has a patch for drivers/scsi/sg.c > > I've browsed around on http://svn.debian.org/wsvn/kernel/, but not found > any references to this problem. So hopefully I've not duplicated any > work! Thanks, I will look into this. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328395: CAN-2005-2801: ext2 ext3 xattr access control bypass
On Thu, Sep 15, 2005 at 01:05:41PM +1000, Geoff Crompton wrote: > Package: linux-2.6 > Severity: important > > Ref http://www.securityfocus.com/bid/14793 > > The kernel team is aware of this issue, and fixes are in the kernel > teams svn at svn.debian.org. > > I created this report so as I couldn't find this issue mentioned in the > BTS. Please tag it with security and sarge. Reporting bugs for problems that are already resolved in SVN just creates work, and believe me we have enough of that already. Security bugs are already being tracked by the testing-security team, I think thats a much more workable framework for handling this. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328395: CAN-2005-2801: ext2 ext3 xattr access control bypass
On Thu, Sep 15, 2005 at 01:38:51PM +0900, Horms wrote: > On Thu, Sep 15, 2005 at 01:05:41PM +1000, Geoff Crompton wrote: > > Package: linux-2.6 > > Severity: important > > > > Ref http://www.securityfocus.com/bid/14793 > > > > The kernel team is aware of this issue, and fixes are in the kernel > > teams svn at svn.debian.org. > > > > I created this report so as I couldn't find this issue mentioned in the > > BTS. Please tag it with security and sarge. > > Reporting bugs for problems that are already resolved in SVN > just creates work, and believe me we have enough of that already. > > Security bugs are already being tracked by the testing-security > team, I think thats a much more workable framework for handling this. I understand this, and I certainly appreciate your help. Probably the best way to fix this problem is to set up automation between the SVN changelogs, what the testing-security guys are doing, and the BTS (for kernel packages). -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
