Bug#368544: linux-headers-2.6.17-rc3-amd64-k8: depends on non-existant package linux-kbuild-2.6.17
Package: linux-headers-2.6.17-rc3-amd64-k8 Severity: grave Justification: renders package unusable This actually effects all the linux-header files for 2.6.17 except the base one linux-headers-2.6.17-rc3 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-k8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-2.6_2.6.16-14_m68k.changes
linux-2.6_2.6.16-14_m68k.changes uploaded successfully to localhost along with the files: linux-headers-2.6.16-2-all_2.6.16-14_m68k.deb linux-headers-2.6.16-2-all-m68k_2.6.16-14_m68k.deb linux-headers-2.6.16-2_2.6.16-14_m68k.deb linux-image-2.6.16-2-amiga_2.6.16-14_m68k.deb linux-headers-2.6.16-2-amiga_2.6.16-14_m68k.deb linux-image-amiga_2.6.16-14_m68k.deb linux-image-2.6-amiga_2.6.16-14_m68k.deb linux-headers-2.6-amiga_2.6.16-14_m68k.deb linux-image-2.6.16-2-atari_2.6.16-14_m68k.deb linux-headers-2.6.16-2-atari_2.6.16-14_m68k.deb linux-image-atari_2.6.16-14_m68k.deb linux-image-2.6-atari_2.6.16-14_m68k.deb linux-headers-2.6-atari_2.6.16-14_m68k.deb linux-image-2.6.16-2-bvme6000_2.6.16-14_m68k.deb linux-headers-2.6.16-2-bvme6000_2.6.16-14_m68k.deb linux-image-bvme6000_2.6.16-14_m68k.deb linux-image-2.6-bvme6000_2.6.16-14_m68k.deb linux-headers-2.6-bvme6000_2.6.16-14_m68k.deb linux-image-2.6.16-2-hp_2.6.16-14_m68k.deb linux-headers-2.6.16-2-hp_2.6.16-14_m68k.deb linux-image-hp_2.6.16-14_m68k.deb linux-image-2.6-hp_2.6.16-14_m68k.deb linux-headers-2.6-hp_2.6.16-14_m68k.deb linux-image-2.6.16-2-mac_2.6.16-14_m68k.deb linux-headers-2.6.16-2-mac_2.6.16-14_m68k.deb linux-image-mac_2.6.16-14_m68k.deb linux-image-2.6-mac_2.6.16-14_m68k.deb linux-headers-2.6-mac_2.6.16-14_m68k.deb linux-image-2.6.16-2-mvme147_2.6.16-14_m68k.deb linux-headers-2.6.16-2-mvme147_2.6.16-14_m68k.deb linux-image-mvme147_2.6.16-14_m68k.deb linux-image-2.6-mvme147_2.6.16-14_m68k.deb linux-headers-2.6-mvme147_2.6.16-14_m68k.deb linux-image-2.6.16-2-mvme16x_2.6.16-14_m68k.deb linux-headers-2.6.16-2-mvme16x_2.6.16-14_m68k.deb linux-image-mvme16x_2.6.16-14_m68k.deb linux-image-2.6-mvme16x_2.6.16-14_m68k.deb linux-headers-2.6-mvme16x_2.6.16-14_m68k.deb linux-image-2.6.16-2-q40_2.6.16-14_m68k.deb linux-headers-2.6.16-2-q40_2.6.16-14_m68k.deb linux-image-q40_2.6.16-14_m68k.deb linux-image-2.6-q40_2.6.16-14_m68k.deb linux-headers-2.6-q40_2.6.16-14_m68k.deb linux-image-2.6.16-2-sun3_2.6.16-14_m68k.deb linux-headers-2.6.16-2-sun3_2.6.16-14_m68k.deb linux-image-sun3_2.6.16-14_m68k.deb linux-image-2.6-sun3_2.6.16-14_m68k.deb linux-headers-2.6-sun3_2.6.16-14_m68k.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-2.6_2.6.16-14_m68k.changes is NEW
linux-headers-2.6-amiga_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-amiga_2.6.16-14_m68k.deb (new) linux-headers-2.6-atari_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6 on Atari machines This package depends on the architecture-specific header files for the latest Linux kernel 2.6 on Atari machines. linux-headers-2.6-bvme6000_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-bvme6000_2.6.16-14_m68k.deb linux-headers-2.6-hp_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-hp_2.6.16-14_m68k.deb linux-headers-2.6-mac_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-mac_2.6.16-14_m68k.deb linux-headers-2.6-mvme147_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-mvme147_2.6.16-14_m68k.deb linux-headers-2.6-mvme16x_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-mvme16x_2.6.16-14_m68k.deb linux-headers-2.6-q40_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-q40_2.6.16-14_m68k.deb linux-headers-2.6-sun3_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-sun3_2.6.16-14_m68k.deb (new) linux-headers-2.6.16-2-all-m68k_2.6.16-14_m68k.deb optional devel All header files for Linux kernel 2.6.16 This package depends against all architecture-specific kernel header files for Linux kernel version 2.6.16, generally used for building out-of-tree kernel modules. linux-headers-2.6.16-2-all_2.6.16-14_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.16-2-all_2.6.16-14_m68k.deb (new) linux-headers-2.6.16-2-amiga_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6.16 on Amiga machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on Amiga machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-amiga, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-amiga package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-atari_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6.16 on Atari machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on Atari machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-atari, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-atari package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-bvme6000_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6.16 on BVM BVME4000 and BVME6000 machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on BVM BVME4000 and BVME6000 machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-bvme6000, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-bvme6000 package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-hp_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6.16 on HP machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on HP machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-hp, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-hp package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-mac_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6.16 on Macintosh machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on Macintosh machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.16-2-mac, and can be used for building modules that load into the kernel provided by the linux-image-2.6.16-2-mac package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.16-2-mvme147_2.6.16-14_m68k.deb optional devel Header files for Linux kernel 2.6.16 on Motorola MVME147 machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.16 on Motorola MVME147 machines, generally used for building out-of-tree kernel modules. These files are going to be installed into
Re: kernel/d-i/security/release meeting at DebConf6
[ keeping the cross-post and please keep it cross-posted ] On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: hey, Frans Pop assembled an informal BoF at DebConf to discuss cross-team issues related to the kernel[1]. We discussed the following topics: snip/ * Non-free modules + firmware * External module packages Non-free modules + firmware --- It was noted that Bastian Blank is working on splitting non-free modules out of main into their own source package. frans It should happen pretty soon; we need the modules in non-free before we do the d-i work; d-i will probably ask for an exception so that d-i can install them as though they were in main because frans thinks we won't have time for that (modules really won't be in main) This means that non-free modules will be on installer cds. The needed exception would be to allow etch to be used as a transition period. manoj this isn't a release management decision, we don't want another GR aba a GR would be time consuming manoj what about a free and a non-free installer image, where the non-free installer is in the non-free section What work is done to get the Linux kernel completely libre? Who is talking with hardware manufactures to GPL their code? aba 2-3 different options * images like today w/ non-free udebs * only put the modules on non-free, make users pick them up * dropping support for devices that require non-free fw completely manoj only option (for permitting non-free modules on the etch installer) is a gr to once again modify our social contract suggestion was made to have users click-through to opt-in to use non-free firmware. manoj believes this is still a violation of the social contract and will require a GR (because the non-free modules would still be on the media) manoj you can ask for an official interpretation of the social contract from the project secretary. manoj suggests two different installers, but joeyh is concerned over additional maintenance/support The deliver modules/users opt-in approach would give us enough time, but requires a GR. joeyh maybe keep it as a separate image that can be combined by the user, problem is that the solution varies with each installation method floppy install needs another floppy; netboot needs another layered initramfs joeyh multi-sessions could be used for cd installs In conclusion, we believe the following options exist: a) debian doesn't support this hardware b) GR to allow combining c) make users combine External module packages Its believed that if we solve the non-free external module package issue, we will also have solved this one. Beside non-free will the external module package help hardware manufactures to get their libre driver in Debian - divergence between official kernel packaging and kernel-package (k-p) The /lib/modules/$(uname -r)/build symlink issue was introduced by Manoj. The attendees agreed to move this to a discussion thread on debian-kernel, in probably a week's time. Please post the outcome also to debian-boot Cheers Geert Stappers [1] http://lists.debconf.org/lurker/message/20060517.065113.4f39d60e.en.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Tue, May 23, 2006 at 09:10:54AM +0200, Geert Stappers wrote: [ keeping the cross-post and please keep it cross-posted ] On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: hey, Frans Pop assembled an informal BoF at DebConf to discuss cross-team issues related to the kernel[1]. We discussed the following topics: snip/ * Non-free modules + firmware * External module packages Non-free modules + firmware --- It was noted that Bastian Blank is working on splitting non-free modules out of main into their own source package. frans It should happen pretty soon; we need the modules in non-free before we do the d-i work; d-i will probably ask for an exception so that d-i can install them as though they were in main because frans thinks we won't have time for that (modules really won't be in main) This means that non-free modules will be on installer cds. The needed exception would be to allow etch to be used as a transition period. manoj this isn't a release management decision, we don't want another GR aba a GR would be time consuming manoj what about a free and a non-free installer image, where the non-free installer is in the non-free section What work is done to get the Linux kernel completely libre? Who is talking with hardware manufactures to GPL their code? We did some work to make the drivers with non-free firmware at least be distributable (many of them originally came with GPLed binary-only blobs), and the manufacturers where rather open about this. That said, asking them to free their actual firmware is something rather doubtful to work, especially given the current situation of upstream linux deciding to ignore the issue. By moving those drivers to non-free, we raise the user awareness of the issue, and we should even document it during the install (a dialog saying this driver is non-free because of blah-blah-blah maybe), and this should in the mid-to-long term help out convince the manufacturers to go the free route. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367518: FTBFS in unstable: UTS Release version does not match the current version
On Tue, May 16, 2006 at 11:52:53AM -0500, Norbert Tretkowski wrote: * Martin Michlmayr wrote: kernel-image-2.4.27-alpha fails to build in unstable. Yes, I know. I have an update ready, but I didn't upload it yet because it's seems to be that we're removing 2.4 from etch. Well, as the alpha kernel maintainer you're free to request removal of the 2.4 kernel packages any time you think it's ready. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: kernel/d-i/security/release meeting at DebConf6
On Tue, May 23, 2006 at 09:47:08AM -0700, Steve Langasek wrote: On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote: On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? If ever the new out-of-tree module and d-i kernel reunification is in place, it will be easy enough to rebuild all packages which depend on the abi-changed kernel. rebuilding them doesn't address the question of making them available for both old and new kernels. Since the assumption seems to be that etch 1/2 Well, they will obviously have the abi number embedded in their package name, and a virtual package / provides who will handle the transition, so this should be no real problem. It is a technology that is well proven and mastered since years in debian. See the ocaml example. uses a different upstream kernel version than etch, to be able to continue providing security support for the etch versions it seems that you need a separate source package (or a whole new suite in dak complete with w-b support!) for any packages being rebuilt against the etch 1/2 kernel. You need a source package, which will be able to generate its debian/control semi-automatically, to adjust to the kernel abi change, yes. This is also something we have done in the ocaml case recently. Needs some coordination and policy for the out of tree modules, and maybe binNMUs who are able to regenerate the debian/control in this way, but nothing otherwordly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364584: Potential workaround
Title: Potential workaround I did not receive all of the errors in the original report, but did receive some of them. This one (and related ones) were most prominent: /bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory Anyway, it seemed to be fixed by forcing an upgrade of initrd-tools from 0.1.81.1 to 0.1.84.1 and modutils 2.4.26-1.2 to 2.4.27-0.5. It could be only one of them; I forced both upgrades at once. --t
Re: kernel/d-i/security/release meeting at DebConf6
On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote: On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? If ever the new out-of-tree module and d-i kernel reunification is in place, it will be easy enough to rebuild all packages which depend on the abi-changed kernel. rebuilding them doesn't address the question of making them available for both old and new kernels. Since the assumption seems to be that etch 1/2 uses a different upstream kernel version than etch, to be able to continue providing security support for the etch versions it seems that you need a separate source package (or a whole new suite in dak complete with w-b support!) for any packages being rebuilt against the etch 1/2 kernel. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: kernel/d-i/security/release meeting at DebConf6
On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote: On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: Kernel udeb creation process (possibly using k-p?) - If we build all of the *existing* udebs from a single source, we outgrow the limit of the Binary: field in the control file. Huh ? This problem is known since over 2 years now, and i thought it was one of the things that where fixed earlier this year or late last year ? Immediately after I sent out the notes from this meeting, aba said he'd followed up with an ftp master (neuro, iirc). From what he was told, it sounds like the information we had during this meeting was stale/inaccurate. Hopefully someone will update this thread with the accurate information so that we can revisit this discussion. Many of the attendees are still travelling (in fact, I'm replying to this without a net connection, so it may be moot once it actually goes out). It'll probably be a few days before everyone makes it home, but then we can continue with a more well-informed discussion. buildd issue - it'd be nice if we could be from an unpacked kernel, but you can't build-dep on that so its a FTBFS. Which is why it makes the most sense to build them from linux-2.6, but i won't argue this point here. I think that the decision of whether or not to build them from linux-2.6 is a separate issue. If doing so is the right thing, let's do it, if its not, let's fix the build issue. dannf suggested that maybe k-p can be configured to allow simple unapcking of debs vs. all the postinst configuratin to allow autobuilders to deal with udebs better; manoj thinks that this will be possible but further out in the current k-p transition that allows for users to do more overriding of postinstallations by default. Mmm. But i don't see how this will play nice with the auto-builders. There is no way we can get this behaviour into the current set of deps/build-deps. Should we add another new kind (Source-dep: ?) ? Well, the only problem (aiui) is that kernel installs want to do bad things like run bootloaders, etc. If we had a chroot parameter we could tweak to turn this off, then wouldn't that solve this problem? manoj new kernel package will have some new features the kernel team might like - versioning is messed up, manoj is integrating abi number, etc, into k-p dannf what if we split up centralized udeb source packages to manage a certain set of archs The consensus was that the current udeb approach is suboptimal, but solving it cleanly won't be possible until etch+1. None of the attendees considered this issue to be critical for etch, so the current plan is to status quo and wait till etch so that we can come up with a good solution. I strongly disagree with this. The non-solution of this issue means that we have a limited power to handle abi-breaking security and bug-fix patches, and impose unreasonable earliness on the kernel freeze for etch, as well as endangers security support during etch's lifetime after that. This was and is a problem with sarge, and we should not repeat that. We should have tackled this issue last fall though. I sympathize with your concerns but, speaking as a person that does security work and udeb maintenance for one architecture, I don't think this is *that* big of a problem. ABI changes are more painful, but d-i work can be ignored when releasing a security update (in fact, we did so last time) - its just point release that suffer, and those schedules are more flexible (as far as our users are concerned). Where this would help solve time critical issues is *before* the release of etch, where a late change could cause us to miss a release deadline. However, the d-i team seemed to believe this was low-risk. I do believe that our consensus was correct based on what we knew at the time - however, it now sounds like this information may have been incorrect so we should re-discuss. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Tue, May 23, 2006 at 10:16:37PM -0500, dann frazier wrote: On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote: On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: Kernel udeb creation process (possibly using k-p?) - If we build all of the *existing* udebs from a single source, we outgrow the limit of the Binary: field in the control file. Huh ? This problem is known since over 2 years now, and i thought it was one of the things that where fixed earlier this year or late last year ? Immediately after I sent out the notes from this meeting, aba said he'd followed up with an ftp master (neuro, iirc). From what he was told, it sounds like the information we had during this meeting was stale/inaccurate. Hopefully someone will update this thread with the accurate information so that we can revisit this discussion. Many of the attendees are still travelling (in fact, I'm replying to this without a net connection, so it may be moot once it actually goes out). It'll probably be a few days before everyone makes it home, but then we can continue with a more well-informed discussion. Notice that this issue was mentioned in a thread on debian-boot at least some weeks ago, i am not sure, but it may even have been Joeyh who mentioned it. I also mentioned it earlier, altough i was not 100% sure. dannf suggested that maybe k-p can be configured to allow simple unapcking of debs vs. all the postinst configuratin to allow autobuilders to deal with udebs better; manoj thinks that this will be possible but further out in the current k-p transition that allows for users to do more overriding of postinstallations by default. Mmm. But i don't see how this will play nice with the auto-builders. There is no way we can get this behaviour into the current set of deps/build-deps. Should we add another new kind (Source-dep: ?) ? Well, the only problem (aiui) is that kernel installs want to do bad things like run bootloaders, etc. If we had a chroot parameter we could tweak to turn this off, then wouldn't that solve this problem? Ah, that would indeed be a solution, we could easily implement something such, together with Manoj, since i believe it involves kernel-package, and how the /etc/kernel/*.d/ scripts are run. Not sure if this is enough, as we would also obviously need support from the buildd software. The consensus was that the current udeb approach is suboptimal, but solving it cleanly won't be possible until etch+1. None of the attendees considered this issue to be critical for etch, so the current plan is to status quo and wait till etch so that we can come up with a good solution. I strongly disagree with this. The non-solution of this issue means that we have a limited power to handle abi-breaking security and bug-fix patches, and impose unreasonable earliness on the kernel freeze for etch, as well as endangers security support during etch's lifetime after that. This was and is a problem with sarge, and we should not repeat that. We should have tackled this issue last fall though. I sympathize with your concerns but, speaking as a person that does security work and udeb maintenance for one architecture, I don't think this is *that* big of a problem. ABI changes are more painful, but d-i work can be ignored when releasing a security update (in fact, we did so last time) - its just point release that suffer, and those schedules are more flexible (as far as our users are concerned). Well, as a proof of my claims, the sarge d-i released with a known remote security hole, and there has been no (or maybe 1 by now ?) d-i update since then. Where this would help solve time critical issues is *before* the release of etch, where a late change could cause us to miss a release deadline. However, the d-i team seemed to believe this was low-risk. Yeah, well, i disagree on this. Taking the last time as example, all development on the kernel was frozen by the d-i team, and we released with a known remote exploit in d-i. And again this time, d-i freeze is scheduled first week of august, and this means we need to have the kernels frozen a week or so before that. This is something like 5 month before the actual release date of etch. So, given these, i am dubious of any claim on the subject made by the d-i team. I do believe that our consensus was correct based on what we knew at the time - however, it now sounds like this information may have been incorrect so we should re-discuss. I have some trouble with this too, i believe that at least some in the meeting must have known about this new information, and either forgot about it, or chose to ignore it, or whatever. Friendly, Sven Luther -- dann frazier --- Wanadoo vous informe que cet
Bug#368683: linux-source-2.6.16: menuconfig should say what the raw default is
Package: linux-source-2.6.16 Version: 2.6.16-13 Severity: normal menuconfig provides defaults, and it also sometimes gives hints like if you're all like 'WTF?' then you can safely say Y here. that's nice, but was that default there because of my old .config? or is it a real default? menuconfig should say: o the default if you leave it alone o the raw default (as if you had no previous .config) these are different things. i leave severity at normal because i think this much usability affects a lot of users who struggle with menuconfig. please feel free to change it. i report here instead of kernel.org because i think reportbug should allow that, and many maintainers do forward upstream. thanks for maintaining the debian kernels. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11--from-2.6.9-proc-config-and-menuconfig Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-source-2.6.16 depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii bzip2 1.0.2-7high-quality block-sorting file co Versions of packages linux-source-2.6.16 recommends: ii gcc 4:3.3.5-3 The GNU C compiler ii libc6-dev [libc-dev] 2.3.6-7GNU C Library: Development Librari ii make 3.80-9 The GNU version of the make util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
