Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 04:20:02PM -0800, Steve Langasek wrote: > This means you're not guaranteed to get /usr/sbin/sshd, which many admins > use exclusively for system administration where remote kvm is not an > affordable option. That's a pretty big problem. Maybe we need a sshd in /sbin then, since as i understand there is no real guarantee that /usr is mounted always in case of problems ? > The stated problem is that upgrades from sarge to etch require the user to > go to a bunch of extra work to change out their kernel before they can > dist-upgrade. I haven't heard you say "lvm will depend on the linux-image > package it needs", or anything equivalent, which means the preinst check for > running kernel version is the only protection against a completely broken > system. Yeah, all that is the same problem, and we need to find a way of fixing it before the sarge release. Maybe generalizing the --supported-version used by the ramdisk-generator tools would be an idea. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 04:52:50PM +0100, Marco d'Itri wrote: > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert > > > > or > > > > alternative mechanism to not overwrite their files. > > > As I explained, I do not believe that on-disk co-existence of two udev > > > packages is feasible. > > Mmm, even if for a short time as planed here ? > I can't see how this would change anything. > > Well, less than 6 months now, so now is the best time to handle this. We > > still > > need to tackle the out-of-tree module issues, and the non-free firmware too. > FWIW, I plan to propose a GR to allow temporary distribution of > binary-only firmwares on our official install media. Why temporary, out of curiosity? This doesn't seem like a temporary problem; I think this is an issue that will be just as applicable for etch+1 as it is for etch, and I think we should be honest about that. I also think it's within the realm of reason for us to decide that source for things like firmware, fonts, and documentation is less important than it is for programs. -- 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: BinNMUs for netcdf transition.
On Fri, Feb 10, 2006 at 04:19:05PM +0100, Daniel Kobras wrote: > On Wed, Feb 08, 2006 at 08:48:57PM -0800, Steve Langasek wrote: > > On Wed, Feb 08, 2006 at 05:10:28PM +0100, Daniel Kobras wrote: > > > Helen Faulkner <[EMAIL PROTECTED]> > > >labplot > Dep-Waits on current vtk on m68k. hppa build appears to be stuck. Stuck from a previous run. Given back. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 10:57:27PM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 01:30:51PM -0800, Steve Langasek wrote: > > > No, they need to reboot after installing udev/lvm, not before. > > Then you've once again left the user without any assurance that their system > > is bootable at the end of the udev/lvm install. > Which is the same than the other way around. (For example the device > mapper api version changed around 2.6.5 and older devmapper versions was > not longer able to work.) Does this mean that the sarge lvm2 package doesn't work with kernels from etch? If so, then bug #351679 *is* RC. > > We *must* avoid leaving the > > user in a state where rebooting the system could leave /usr and /var > > unmountable, the network inaccesible, and so on. > The old initrd is not changed at this time and can mount at least /. This means you're not guaranteed to get /usr/sbin/sshd, which many admins use exclusively for system administration where remote kvm is not an affordable option. That's a pretty big problem. > > > Which should be used. > > I don't see anywhere you've specified a mechanism for determining what > > kernel image this is, or ensuring that it is configured first. > Hu? The stated problem is that upgrades from sarge to etch require the user to go to a bunch of extra work to change out their kernel before they can dist-upgrade. I haven't heard you say "lvm will depend on the linux-image package it needs", or anything equivalent, which means the preinst check for running kernel version is the only protection against a completely broken system. -- 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: Preparation of the next stable Debian GNU/Linux update (I)
On Thu, Feb 09, 2006 at 10:37:38 +0100, Martin Schulze wrote: > Martin Zobel-Helas wrote: > > there was some discussion[1] wether the next stable update could have > > some timezone data updated in the glibc package. > > Show me the changes. > > Unless large chunks of the world are affected I don't consider timezone > details to warrant an update in our stable release. A note in the > release notes may be useful instead. A diff between the "timezone" dir in sarge's glibc sources and upstream CVS HEAD's lists changes for at least Australia, Azerbaijan, Canada, Cuba, Georgia, Haiti, Iran, Jordan, Kyrgyzstan, Libya, Nicaragua, Palestine, Tasmania, Tunisia, United States of America, Uruguay as well as the 2005 leap second. IMHO those are sufficient changes to warrant an update in stable. HTH, Ray -- LWN normally tries to avoid talking much about Microsoft - it is simply irrelevant to the free software world most of the time. http://www.lwn.net/2000/0406/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 10:45:23PM +0100, Sven Luther wrote: > On Fri, Feb 10, 2006 at 01:21:22PM -0800, Steve Langasek wrote: > > - Doesn't fuck the system if you lose power part-way through the > >dist-upgrade after udev has been unpacked and no newer kernel has been > >installed. > Hehe, never thougth about that. i guess that having udev depend on a kernel > image of at least version foo, you solve this problem. > Naturally, if you have i-t include klibc and udev, then you are faced with a > chicken-and-egg problem :) Yes, that's the circular dependency loop bug that's currently open on these packages. AIUI, maks has already agreed to try to break this loop by making i-t work with older udev. -- 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: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:30:51PM -0800, Steve Langasek wrote: > > No, they need to reboot after installing udev/lvm, not before. > Then you've once again left the user without any assurance that their system > is bootable at the end of the udev/lvm install. Which is the same than the other way around. (For example the device mapper api version changed around 2.6.5 and older devmapper versions was not longer able to work.) > We *must* avoid leaving the > user in a state where rebooting the system could leave /usr and /var > unmountable, the network inaccesible, and so on. The old initrd is not changed at this time and can mount at least /. > > Which should be used. > I don't see anywhere you've specified a mechanism for determining what > kernel image this is, or ensuring that it is configured first. Hu? Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:21:22PM -0800, Steve Langasek wrote: > - Doesn't fuck the system if you lose power part-way through the >dist-upgrade after udev has been unpacked and no newer kernel has been >installed. Hehe, never thougth about that. i guess that having udev depend on a kernel image of at least version foo, you solve this problem. Naturally, if you have i-t include klibc and udev, then you are faced with a chicken-and-egg problem :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 07:54:01PM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 03:45:28AM -0800, Steve Langasek wrote: > > Then what does this have to do with the problem people are trying to solve? > > The problem is that there is *no* kernel available in sarge that meets the > > needs of the etch udev and lvm packages, and as a result people have to > > install a new kernel, reboot, and then continue with the upgrade > No, they need to reboot after installing udev/lvm, not before. Then you've once again left the user without any assurance that their system is bootable at the end of the udev/lvm install. We *must* avoid leaving the user in a state where rebooting the system could leave /usr and /var unmountable, the network inaccesible, and so on. > > > Hu? The kernel image have to be configured already. > > *What* kernel image? > Which should be used. I don't see anywhere you've specified a mechanism for determining what kernel image this is, or ensuring that it is configured first. -- 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: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:41:55PM +0100, Sven Luther wrote: > On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote: > > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > We need something which upgrades seamlessly, and the above solution is not > > > acceptable for the etch release, as has been said already in the past. > > This would be nice, but so far nobody has been able to design anything > > better, myself included. > Yeah, but more heads together searching actively may find a solution where > people alone have not. > More to this later, as i am busy, just a few comments now. > > > Is it not possible to have a newer udev which is not removing the older > > > udev, > > > so you have both installed, and the older udev will work with older > > > kernels > > > and the newer udev will work with newer kernels ? > > I do not believe that this would be possible, at least for the general > > case, because the version of udev in stable is almost a different > > program with different interfaces with other system components. > Notice, the only case we really have to deal with is the case where the system > is already running with a 2.6.8 (or random self built) kernel, using the older > udev, and we are installing a newer kernel and udev. > The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot > anyway, so, we only need something that : > - don't mess up the currently running stuff, is it possible to have udev > installed to take effect after the next reboot, and keep the old udev live > until then ? > - installs without trouble. > - works fine when the newer kernel is booted into. - Doesn't fuck the system if you lose power part-way through the dist-upgrade after udev has been unpacked and no newer kernel has been installed. -- 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: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 04:52:50PM +0100, Marco d'Itri wrote: > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert > > > > or > > > > alternative mechanism to not overwrite their files. > > > As I explained, I do not believe that on-disk co-existence of two udev > > > packages is feasible. > > Mmm, even if for a short time as planed here ? > I can't see how this would change anything. Well, this could be part of a more generic roll-back of upgrades framework, which i believe would have interest beyond the kernel/udev issue, but this is vastly more work and time and effort than what we are speaking here. > > Well, less than 6 months now, so now is the best time to handle this. We > > still > > need to tackle the out-of-tree module issues, and the non-free firmware too. > FWIW, I plan to propose a GR to allow temporary distribution of > binary-only firmwares on our official install media. Well, given that we voted twice about this, and that it needs a 3:1 super-majority, i have some doubts of this passing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 03:45:28AM -0800, Steve Langasek wrote: > Then what does this have to do with the problem people are trying to solve? > The problem is that there is *no* kernel available in sarge that meets the > needs of the etch udev and lvm packages, and as a result people have to > install a new kernel, reboot, and then continue with the upgrade No, they need to reboot after installing udev/lvm, not before. > > Hu? The kernel image have to be configured already. > *What* kernel image? Which should be used. Bastian -- No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert or > > > alternative mechanism to not overwrite their files. > > As I explained, I do not believe that on-disk co-existence of two udev > > packages is feasible. > Mmm, even if for a short time as planed here ? I can't see how this would change anything. > Well, less than 6 months now, so now is the best time to handle this. We still > need to tackle the out-of-tree module issues, and the non-free firmware too. FWIW, I plan to propose a GR to allow temporary distribution of binary-only firmwares on our official install media. -- ciao, Marco signature.asc Description: Digital signature
Re: BinNMUs for netcdf transition.
On Wed, Feb 08, 2006 at 08:48:57PM -0800, Steve Langasek wrote:
> On Wed, Feb 08, 2006 at 05:10:28PM +0100, Daniel Kobras wrote:
>
> > Peter S Galbraith <[EMAIL PROTECTED]>
> >gri
>
> Only needed on i386, it seems.
Not (automatically) binNMUable because tarball ships read-only
debian/changelog. Bug filed (#352219).
> > Matthias Klose <[EMAIL PROTECTED]>
> >python-scientific
>
> This one is not binNMUable, it has an arch: all package with a Depends: =
> ${Source-Version} on an arch: any.
Oops, right. Bug filed.
> > Daniel Kobras <[EMAIL PROTECTED]>
> >dx
>
> Queued everywhere except for arm and hppa, where it seems to already be
> built against libnetcdf3.
Failed on m68k in the first run due to a misconfigured buildd, but now
appears to build fine.
> > Helen Faulkner <[EMAIL PROTECTED]>
> >labplot
Dep-Waits on current vtk on m68k. hppa build appears to be stuck.
> > Ionut Georgescu <[EMAIL PROTECTED]>
> >grace
Compiler error on m68k. Known problem (#338433).
> >grace6
Ok.
> > Debian QA Group <[EMAIL PROTECTED]>
> >nco
Bogus build-dep on netcdf3g in addition to netcdfg-dev. Will do
sourceful QA upload.
> > Torsten Landschoff <[EMAIL PROTECTED]>
> >gmt
FTBFS on hppa. Longstanding problem, but previously unreported. Bug
filed now.
> > Brian Mays <[EMAIL PROTECTED]>
> >netcdf-perl
Ok.
> > Sam Hocevar (Debian packages) <[EMAIL PROTECTED]>
> >genesis
Ok.
Thanks,
Daniel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:54:37PM +0100, Marco d'Itri wrote: > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot > > anyway, so, we only need something that : > > > > - don't mess up the currently running stuff, is it possible to have udev > > installed to take effect after the next reboot, and keep the old udev > > live > > until then ? > > > > - installs without trouble. > > > > - works fine when the newer kernel is booted into. > I think that this can be arranged easily (by not killing the old udevd) > with a few package tweaks and should not cause any problems as long as > the next reboot will happen "soon". > I'm just not sure if it can/should be automatic too. Well, we put a pre-inst debconf question here, where we ask the user if he wants to go ahead and reboot as soon after the install, or abort. If he wants to go ahead, we doit and put a postinst deconf note stressing he should reboot with the newer kernel ASAP (in the do-it-now style). > Even if for some reason the old daemon could not be kept running then > /dev will continue working until the next reboot. Cool. > > Naturally, the problem with this approach is that if the reboot with the > > newer > > kernel fails, then the user is hosed, but this can be worked with in some > > manner. > If the new kernel fails and users reboot again with the old kernel then > the system will boot using the static /dev. How much this will break is > system-dependent and impossible to predict. Ok, but there is a sane setup to fall back on. As i mentioned to Jonas, the best way to recover from this is probably to boot into the recovery mode of d-i anyway. > > 1) sarge-udev & etch-udev install concurently, maybe using the divert or > > alternative mechanism to not overwrite their files. > As I explained, I do not believe that on-disk co-existence of two udev > packages is feasible. Mmm, even if for a short time as planed here ? > > I got a guy complaining about powerpc/alsa being broken this past week for > Nobody reported this to me. Yeah, i asked him to file a bug report though, but you can't thrust those powerpc guys to do that :) > > Ah, it needs to be ready at etch freeze time, that is end of july. > This is a lot of time. Well, less than 6 months now, so now is the best time to handle this. We still need to tackle the out-of-tree module issues, and the non-free firmware too. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
[EMAIL PROTECTED] wrote: >In this case, does itmake any sense to treat the two versions of udev >similarly to how we treat library transitions? I.e., rename the new >udev to udev-$min-kernel-ver or something? (the name is ugly, but you It's not clear which problem this would solve, exactly. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot > anyway, so, we only need something that : > > - don't mess up the currently running stuff, is it possible to have udev > installed to take effect after the next reboot, and keep the old udev live > until then ? > > - installs without trouble. > > - works fine when the newer kernel is booted into. I think that this can be arranged easily (by not killing the old udevd) with a few package tweaks and should not cause any problems as long as the next reboot will happen "soon". I'm just not sure if it can/should be automatic too. Even if for some reason the old daemon could not be kept running then /dev will continue working until the next reboot. > Naturally, the problem with this approach is that if the reboot with the newer > kernel fails, then the user is hosed, but this can be worked with in some > manner. If the new kernel fails and users reboot again with the old kernel then the system will boot using the static /dev. How much this will break is system-dependent and impossible to predict. > 1) sarge-udev & etch-udev install concurently, maybe using the divert or > alternative mechanism to not overwrite their files. As I explained, I do not believe that on-disk co-existence of two udev packages is feasible. > I got a guy complaining about powerpc/alsa being broken this past week for Nobody reported this to me. > Ah, it needs to be ready at etch freeze time, that is end of july. This is a lot of time. -- ciao, Marco signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote: > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > We need something which upgrades seamlessly, and the above solution is not > > acceptable for the etch release, as has been said already in the past. > This would be nice, but so far nobody has been able to design anything > better, myself included. Yeah, but more heads together searching actively may find a solution where people alone have not. More to this later, as i am busy, just a few comments now. > > Is it not possible to have a newer udev which is not removing the older > > udev, > > so you have both installed, and the older udev will work with older kernels > > and the newer udev will work with newer kernels ? > I do not believe that this would be possible, at least for the general > case, because the version of udev in stable is almost a different > program with different interfaces with other system components. Notice, the only case we really have to deal with is the case where the system is already running with a 2.6.8 (or random self built) kernel, using the older udev, and we are installing a newer kernel and udev. The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot anyway, so, we only need something that : - don't mess up the currently running stuff, is it possible to have udev installed to take effect after the next reboot, and keep the old udev live until then ? - installs without trouble. - works fine when the newer kernel is booted into. This should be possible without too much pain, it mostly depends on the first item, which doesn't need a fully concurent udev, just that the currently running one is kept upto the reboot. Naturally, the problem with this approach is that if the reboot with the newer kernel fails, then the user is hosed, but this can be worked with in some manner. So let's imagine the following scenario : 1) sarge-udev & etch-udev install concurently, maybe using the divert or alternative mechanism to not overwrite their files. 2) when etch-udev is installed, it doesn't remove the older one, but also doesn't activate itself. 3) at boot time, before any of the udev thingy is called, a script is run, which checks the kernel version, and activate one of the two alternatives. Well, it may even work in the general case, upto a point, not sure, but it should be helpful at least in the sarge->etch upgrade scenario. > > Also, what about 2.4 kernels, they don't use udev right ? so the point is > > moot > > with them, and the only problem is the sarge 2.6.8 -> etch 2.6.15+ upgrade > > path. > Correct. > > > Also, could you comment more about the many breakage we have recently seen > > with udev, and if we can expect this to stabilize in the etch timeframe, or > > if > > it will continue to be problematic ? > Can you be more specific? I do not remember many breakages recently. I got a guy complaining about powerpc/alsa being broken this past week for example, but i vaguely remember other issues these past month too. > I am sure that I can manage to have a stable package ready in time for > the release, just like I did for sarge. Ah, it needs to be ready at etch freeze time, that is end of july. > As a plus, udev and the related kernel interfaces are much more mature > and much less a moving target than two years ago, so I do not expect > more troubles in the future. Which sounds cool, but doesn't help with sarge->etch upgrades sadly. Mmm, this became longer than i thought it would. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
This one time, at band camp, Marco d'Itri said: > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > We need something which upgrades seamlessly, and the above solution is not > > acceptable for the etch release, as has been said already in the past. > This would be nice, but so far nobody has been able to design anything > better, myself included. [...] > > Is it not possible to have a newer udev which is not removing the older > > udev, > > so you have both installed, and the older udev will work with older kernels > > and the newer udev will work with newer kernels ? > I do not believe that this would be possible, at least for the general > case, because the version of udev in stable is almost a different > program with different interfaces with other system components. In this case, does itmake any sense to treat the two versions of udev similarly to how we treat library transitions? I.e., rename the new udev to udev-$min-kernel-ver or something? (the name is ugly, but you get the idea). The upgrade path won't be perfect, but it will have the benefit of leaving the user with their current kernel + current udev at the end, at which point they will need to install the newer udev and newer kernel and reboot. Just a thought, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 12:07:11PM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 02:37:21AM -0800, Steve Langasek wrote: > > Anyway, I don't see that this is a very good solution. Disabling all of the > > available boot options for the system doesn't prevent incidental breakage, > > it just changes the *kind* of incidental breakage you get. > It makes it impossible to break by accident. It don't help against hand > made breakages. This is a social problem which can't be fixed by a > technical solution. Then what does this have to do with the problem people are trying to solve? The problem is that there is *no* kernel available in sarge that meets the needs of the etch udev and lvm packages, and as a result people have to install a new kernel, reboot, and then continue with the upgrade -- and failing to follow these directions means hours of pain trying to recover from an interrupted dist-upgrade (in particular for those users who have little or no dpkg knowledge/experience). > > Anything that introduces the possibility of the system breaking on > > reboot/power failure is *worse* than this. > Hu? The kernel image have to be configured already. *What* kernel image? -- 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: udeb migration now that 2.6.15 is in testing
On Thu, Feb 09, 2006 at 04:13:54PM +0100, Frans Pop wrote: > Now that 2.6.15 is in testing (Yay!) let's migrate the udebs that waited > on that to happen. > > unblock user-setup/2.12r-6 > unblock cdebconf/0.97 # 8 days old currently > > I'm not sure how the following package should be hinted as it used to have > a deb, but now only has a udeb: > network-console Let's see what happens with Steve's hint. > And here is the list of udeb-only packages for Jeroen: > apt-setup > base-installer # very young but last upload had only a minor > change for S/390; needs to go with the rest > FTBFS on m68k: known recurrent problem, needs > attention by Wouter > hw-detect # 7 days old currently > pkgsel > prebaseconfig > preseed All done. > # A lot of these are quite young as they were uploaded after 2.6.15-4 > linux-kernel-di-alpha-2.6 > linux-kernel-di-arm-2.6 > linux-kernel-di-hppa-2.6 > linux-kernel-di-i386-2.6 > linux-kernel-di-ia64-2.6 > linux-kernel-di-m68k-2.6 > linux-kernel-di-powerpc-2.6 > linux-kernel-di-sparc-2.6 done. > The following packages containing udebs were hinted earlier this week, but > the udebs are still shown as needing migration on our udeb status page: > - console-data > - util-linux done, just like: - pcmciautils - loop-aes-modules - installation-report --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: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 02:37:21AM -0800, Steve Langasek wrote: > Anyway, I don't see that this is a very good solution. Disabling all of the > available boot options for the system doesn't prevent incidental breakage, > it just changes the *kind* of incidental breakage you get. It makes it impossible to break by accident. It don't help against hand made breakages. This is a social problem which can't be fixed by a technical solution. > Anything that introduces the possibility of the system breaking on > reboot/power failure is *worse* than this. Hu? The kernel image have to be configured already. > > - Refuse to start on startup if no compatible version is found. > What does this mean, exactly? Should that be "upgrade" instead of > "startup"? And how does that help us improve users' experience when > upgrading? Okay, both. It have to fail without error on upgrades to not break the complete upgrade. Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1 signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 10:45:04AM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 07:57:25AM +0100, Sven Luther wrote: > > We need something which upgrades seamlessly, and the above solution is not > > acceptable for the etch release, as has been said already in the past. > Hmm. Are there problems with the following: > - Upgrade works but asks the not yet completed dkt to disable old images > which raises a big fat warning that it needs a reboot. Context from IRC: 01:55 < svenl> waldi: dkt ? 01:56 < waldi> svenl: the piece of software I just work on 01:56 < vorlon> which does what? 01:56 < waldi> https://lophos.multibuild.org/svn/dkt/trunk/doc/design 01:56 < waldi> it is mostly a generic replacement of update-grub Anyway, I don't see that this is a very good solution. Disabling all of the available boot options for the system doesn't prevent incidental breakage, it just changes the *kind* of incidental breakage you get. The *least* bad solution we have today is that some packages (lvm, udev) refuse in the preinst to continue being installed when upgrading from sarge (lvm for upgrades from either 2.4.27 or 2.6.8; udev from 2.6.8 only), and then the user is left to figure out how to get a viable 2.6.1x kernel package onto their system after a dist-upgrade has left God knows how many packages in an unconfigured or inconsistent state. Anything that introduces the possibility of the system breaking on reboot/power failure is *worse* than this. > - Refuse to start on startup if no compatible version is found. What does this mean, exactly? Should that be "upgrade" instead of "startup"? And how does that help us improve users' experience when upgrading? -- 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: making udev require 2.6.15 kernels
On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > We need something which upgrades seamlessly, and the above solution is not > acceptable for the etch release, as has been said already in the past. This would be nice, but so far nobody has been able to design anything better, myself included. > So, let's start to look for a real solution here, knowing that a kernel > upgrade will mean a reboot anyway, but there is really no need to impose two > reboots on the user. My only alternate proposal is: # disables the kernel version check touch /etc/udev/force-upgrade # this will also pull new initramfs, hal and $DEITY knows what else apt-get install udev linux-image-whatever # ASAP reboot But I am not sure about its merit. It probably needs a few more tweaks to the package because postinst will not be able to start udevd. > - older udev with newer kernel works mostly, but some events are lost. Not really. udev versions older than 072 do not support the new nested classes used by the input subsystem in kernels >= 2.6.15. The effect is that device nodes in /dev/input/ will not be created, and the respective drivers will not be loaded. Also, udev versions older than 059 have some bugs which break referencing sysfs attributes since kernel 2.6.12. The first problem is the important one. > - newer udev with older kernel breaks big time (no idea how it breaks > though). They will not even start, because they depend on recent kernel features like $MODALIAS variables and netlink uevents. > - when upgrading newer udev, the older one is removed, thus triggering the > newer udev with older kernel problem. Correct. > Is it not possible to have a newer udev which is not removing the older udev, > so you have both installed, and the older udev will work with older kernels > and the newer udev will work with newer kernels ? I do not believe that this would be possible, at least for the general case, because the version of udev in stable is almost a different program with different interfaces with other system components. > Also, what about 2.4 kernels, they don't use udev right ? so the point is moot > with them, and the only problem is the sarge 2.6.8 -> etch 2.6.15+ upgrade > path. Correct. > Also, could you comment more about the many breakage we have recently seen > with udev, and if we can expect this to stabilize in the etch timeframe, or if > it will continue to be problematic ? Can you be more specific? I do not remember many breakages recently. I am sure that I can manage to have a stable package ready in time for the release, just like I did for sarge. As a plus, udev and the related kernel interfaces are much more mature and much less a moving target than two years ago, so I do not expect more troubles in the future. -- ciao, Marco signature.asc Description: Digital signature
Re: udeb migration now that 2.6.15 is in testing
On Thu, Feb 09, 2006 at 01:30:19PM -0500, Joey Hess wrote: > Frans Pop wrote: > > I'm not sure how the following package should be hinted as it used to have > > a deb, but now only has a udeb: > > network-console > network-console-config needs to be removed from testing (should happen > semiautomatically), and then normal udeb sync. This will only happen if the package is hinted in via britney, AFAIK. Hint added. -- 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: binNMU for approx
On Thu, Feb 09, 2006 at 03:26:35PM +0100, Julien Cristau wrote: > approx still depends on ocaml-base-nox-3.09.0 on hppa, m68k, mips, > mipsel, s390. Could you trigger a binNMU on these architectures for the > transition to 3.09.1? Queued. Thanks, -- 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: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 07:57:25AM +0100, Sven Luther wrote: > We need something which upgrades seamlessly, and the above solution is not > acceptable for the etch release, as has been said already in the past. Hmm. Are there problems with the following: - Upgrade works but asks the not yet completed dkt to disable old images which raises a big fat warning that it needs a reboot. - Refuse to start on startup if no compatible version is found. It will also work with hand made kernels. Bastian -- Witch! Witch! They'll burn ya! -- Hag, "Tomorrow is Yesterday", stardate unknown signature.asc Description: Digital signature
Re: Preparation of the next stable Debian GNU/Linux update (I)
Steve Langasek wrote: > > * Accepted albatross > > * Accepted antiword > > * Investigation of cernlib > > * Investigation of clamav > > * Accepted crawl > > * Moved evms from further to accept > > * Accepted mantis > > * Accepted perl > > * Accepted sudo > > Are you aware of the complaints regarding the solution implemented in the > sudo DSA? Yes, we're discussing already how to handle this. In general we believe that the current fix is proper, but may release an update to document it better. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 12:32:21AM +0100, Marco d'Itri wrote: > Now that 2.6.15 kernels are in testing I'd like to raise the kernel > requirement for the udev package from 2.6.12 to 2.6.15 as soon as a new > version of udev will have entered testing. > This will let me remove a lot of cruft from the package. > Does anybody have a reason to wait some more time? Aside from it being a pain in my ass personally to have to constantly reboot to continue using a non-chrooted up-to-date unstable system for development, I suppose it doesn't make much difference whether 2.6.12 or 2.6.15 is the break point, no. :P -- 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
