Bug#349354: initramfs-tools - kernel -udev dependency loop
Any more bright ideas? -- ciao, Marco signature.asc Description: Digital signature
Re: removing 2.2 from the archive?
dann frazier wrote: On Fri, May 26, 2006 at 03:29:49PM +0200, Andreas Barth wrote: * dann frazier ([EMAIL PROTECTED]) [060526 15:14]: On Mon, May 22, 2006 at 01:24:52PM +0200, Sven Luther wrote: On Sun, May 21, 2006 at 11:20:38PM +0200, Christian T. Steigies wrote: need some further discussion among the m68k folks... does this also mean that an etch installation will require a 2.6 kernel to run on the machine? Some of the m68k buildds (most macs) are still running 2.2.25, the two Atari Falcons run 2.4. The long term aim is indeed to release etch with only 2.6 kernels, which means no 2.4 but also no 2.2 kernel. Now, the removal of the 2.2 kernel should follow the same roadmap as what was discussed for the 2.4 kernels, and i suppose that for m68k purpose, you can substitute '2.4' with '2.2 or 2.4' in all those emails. There has been no DSA for a 2.2 kernel to date in the lifetime of woody/sarge (counting on my recollection here, I'm currently offline), so I can't see how we can continue shipping it unless someone steps up to handle this. Of course, you could always request insecure status from the release team (with proper release notes, etc). As far as I know, 2.2 isn't even supported by glibc any more. I've cc'd the glibc list for confirmation. glibc in etch needs at least a 2.4.1 kernel, except for m68k, for which the minimum version is 2.2.0. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.2 from the archive?
On Fri, May 26, 2006 at 03:29:49PM +0200, Andreas Barth wrote: > * dann frazier ([EMAIL PROTECTED]) [060526 15:14]: > > On Mon, May 22, 2006 at 01:24:52PM +0200, Sven Luther wrote: > > > On Sun, May 21, 2006 at 11:20:38PM +0200, Christian T. Steigies wrote: > > > > need some further discussion among the m68k folks... does this also mean > > > > that an etch installation will require a 2.6 kernel to run on the > > > > machine? > > > > Some of the m68k buildds (most macs) are still running 2.2.25, the two > > > > Atari > > > > Falcons run 2.4. > > > > > > The long term aim is indeed to release etch with only 2.6 kernels, which > > > means > > > no 2.4 but also no 2.2 kernel. > > > > > > Now, the removal of the 2.2 kernel should follow the same roadmap as what > > > was > > > discussed for the 2.4 kernels, and i suppose that for m68k purpose, you > > > can > > > substitute '2.4' with '2.2 or 2.4' in all those emails. > > > > There has been no DSA for a 2.2 kernel to date in the lifetime of > > woody/sarge (counting on my recollection here, I'm currently offline), > > so I can't see how we can continue shipping it unless someone steps up > > to handle this. Of course, you could always request insecure status > > from the release team (with proper release notes, etc). > > As far as I know, 2.2 isn't even supported by glibc any more. I've cc'd the glibc list for confirmation. > If that is > the case, we definitly shouldn't ship with 2.2. Also, anyone is free to > open a kernel-2-2.debian.net repository kernel.debian.net has a repository that could be used for stuff like this. -- 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 Fri, May 26, 2006 at 11:39:30AM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060526 10:20]: > > Well, it was my understanding that both those packages where living in a > > differnt section, namely etch and etch-, which would take care of > > the problem. Failing that, it is easy enough to handle the problem in the > > same > > way as we want to handle the sid/etch kernel dichotomy, in case we froze on > > a > > 2.6.16 kernel. > > Both packages will have to live in etch. Ok, so we need to find a scheme which appends some tag or something to the module names. Ideally, this would be the full kernel version (2.6.16-2-), which i believe would be enough for our purpose. kernel-package already does this for binary package, we only need to transpose this to the source package too, and everyone is happy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(Some) received packets are not reaching a listening application (UDP?)
Hello everybody, I have an issue with an application not receiving all traffic that it should be getting. The current system is a non-Debian GNU/Linux, but since I had a similar issue using Debian and I am not following any other Linux-related list, I hope not to be off topic. I have taken the liberty to CC debian-kernel because I feel that the kernel is getting the packets but not forwarding them. The first experience--using the Debian system--was some months ago, so accuracy is not guaranteed. At that time I had decided to try configuring network autodetection (on a laptop using a 10/100 Broadcom Ethernet chipset, and a 2.6.x packaged kernel) using one of Debian's packages, laptop-net, I think. Under ordinary circumstances I did not manage to make it work. However, when capturing traffic with Ethereal, I found that the IP was correctly configured from the previous arbitrary state. The situation was weired, I wasn't really moving around much and time was scarce, so I let the issue drop. Now I have seen a similar situation with syslog running under a RedHat system with a 2.6.9 kernel. This time, capturing traffic on the wire shows no packet loss, and a tcpdump capture on the interface shows all messages arriving, but syslog does not log all of them. However, when running "nc -l -u -p 514 > /dev/null", without stopping the syslog daemon, all messages are written down. As a matter of fact, it seems that "nc -l -u -p 514 > /dev/null &" is just as good, but since the process is stopped automatically not even I quite believe my eyes. I hope that somebody can offer some insight as to what might be happening or how to look deeper into the problem. I might not be able to readily work on the affected system, but it would anyway be good to get some tips as to how to further look into the problem. Hints about the reason and, why not, how to mend the situation would also work wonders. Thanks. -- Gonzalo HIGUERA DÍAZ <[EMAIL PROTECTED]>
Re: removing 2.2 from the archive?
* dann frazier ([EMAIL PROTECTED]) [060526 15:14]: > On Mon, May 22, 2006 at 01:24:52PM +0200, Sven Luther wrote: > > On Sun, May 21, 2006 at 11:20:38PM +0200, Christian T. Steigies wrote: > > > need some further discussion among the m68k folks... does this also mean > > > that an etch installation will require a 2.6 kernel to run on the machine? > > > Some of the m68k buildds (most macs) are still running 2.2.25, the two > > > Atari > > > Falcons run 2.4. > > > > The long term aim is indeed to release etch with only 2.6 kernels, which > > means > > no 2.4 but also no 2.2 kernel. > > > > Now, the removal of the 2.2 kernel should follow the same roadmap as what > > was > > discussed for the 2.4 kernels, and i suppose that for m68k purpose, you can > > substitute '2.4' with '2.2 or 2.4' in all those emails. > > There has been no DSA for a 2.2 kernel to date in the lifetime of > woody/sarge (counting on my recollection here, I'm currently offline), > so I can't see how we can continue shipping it unless someone steps up > to handle this. Of course, you could always request insecure status > from the release team (with proper release notes, etc). As far as I know, 2.2 isn't even supported by glibc any more. If that is the case, we definitly shouldn't ship with 2.2. Also, anyone is free to open a kernel-2-2.debian.net repository - and I would be willing to mention that in the release notes. I however doubt we should deliver 2.2 kernels inside of etch. Heck, we even consider to drop 2.4. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- 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 Thu, May 25, 2006 at 05:10:57PM -0700, Steve Langasek wrote: > On Tue, May 23, 2006 at 07:08:41PM +0200, Sven Luther wrote: > > 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. > > Er, the problem is that you're talking about keeping *two* sets of packages > around. That implies two source packages; at least some members of the ftp Well, it was my understanding that both those packages where living in a differnt section, namely etch and etch-, which would take care of the problem. Failing that, it is easy enough to handle the problem in the same way as we want to handle the sid/etch kernel dichotomy, in case we froze on a 2.6.16 kernel. > team don't like having source packages building binaries that aren't > mentioned in debian/control of the source package, and keeping one source I fail to see the problem here. > package for two kernel versions, one of them added at a later date and for > an undetermined version, pretty definitely means that one set of these > binaries aren't mentioned in debian/control of the current source package. No, see above. > The ftp team might be ok with making an exception here, I'm just saying > that's a conversation to have *before* release instead of when it comes time > to do etch 1/2 and people suddenly realize there's no infrastructure to > fully support both kernels. Ah, yes, i fully agree with you about that. Like most of the discussions we are having now should have been handled last fall :) > > > 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. > > Changing the list of packages in debian/control in the standard debian/rules > targets is almost always something we treat as an RC bug; so binNMUs are > definitely out. Indeed. But why be so inflexible ? Why not see that there are some limited cases where this is useful, and this is one of them. What is so definitively wrong in this case ? Also, the problem is not as you think, the idea is only to modify the debian/control in an automated way in the source upload, so no, it would not be binNMUs, but some kind of automated sourceNMUs. We have the same problem in the ocaml case, and see what happened, despite our care, some of the m68k packages where rebuilt with the older ocaml, the same problem can happen here if we are not carefull and will cause a mess. > Which means sourceful uploads, which means the binaries for the old kernel > no longer correspond to the current source package, which means rene tags > them as candidates for removal... We can simply append some random tag to the new source-upload, or upload them to a separate archive, and the problem goes away by itself. There are always solution if there is the will to implement them :) Friendly, Sven Luther -- To UNS
Re: removing 2.2 from the archive?
On Mon, May 22, 2006 at 01:24:52PM +0200, Sven Luther wrote: > On Sun, May 21, 2006 at 11:20:38PM +0200, Christian T. Steigies wrote: > > need some further discussion among the m68k folks... does this also mean > > that an etch installation will require a 2.6 kernel to run on the machine? > > Some of the m68k buildds (most macs) are still running 2.2.25, the two Atari > > Falcons run 2.4. > > The long term aim is indeed to release etch with only 2.6 kernels, which means > no 2.4 but also no 2.2 kernel. > > Now, the removal of the 2.2 kernel should follow the same roadmap as what was > discussed for the 2.4 kernels, and i suppose that for m68k purpose, you can > substitute '2.4' with '2.2 or 2.4' in all those emails. There has been no DSA for a 2.2 kernel to date in the lifetime of woody/sarge (counting on my recollection here, I'm currently offline), so I can't see how we can continue shipping it unless someone steps up to handle this. Of course, you could always request insecure status from the release team (with proper release notes, etc). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368937: linux-headers-2.6.17-rc3-686: fails to install
Package: linux-headers-2.6.17-rc3-686 Severity: grave Justification: renders package unusable Installation fails with: The following packages have unmet dependencies: linux-headers-2.6.17-rc3-686: Depends: linux-kbuild-2.6.17 but it is not installable E: Broken packages -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060526 10:20]: > Well, it was my understanding that both those packages where living in a > differnt section, namely etch and etch-, which would take care of > the problem. Failing that, it is easy enough to handle the problem in the same > way as we want to handle the sid/etch kernel dichotomy, in case we froze on a > 2.6.16 kernel. Both packages will have to live in etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- 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 07:08:41PM +0200, Sven Luther wrote: > 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. Er, the problem is that you're talking about keeping *two* sets of packages around. That implies two source packages; at least some members of the ftp team don't like having source packages building binaries that aren't mentioned in debian/control of the source package, and keeping one source package for two kernel versions, one of them added at a later date and for an undetermined version, pretty definitely means that one set of these binaries aren't mentioned in debian/control of the current source package. The ftp team might be ok with making an exception here, I'm just saying that's a conversation to have *before* release instead of when it comes time to do etch 1/2 and people suddenly realize there's no infrastructure to fully support both kernels. > > 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. Changing the list of packages in debian/control in the standard debian/rules targets is almost always something we treat as an RC bug; so binNMUs are definitely out. Which means sourceful uploads, which means the binaries for the old kernel no longer correspond to the current source package, which means rene tags them as candidates for removal... -- 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
