Re: s390-tools unblock
Hello, On Sun, Aug 29, 2010 at 11:11 AM, Julien Cristau jcris...@debian.org wrote: Hi, s390-tools is preventing linux-2.6 from moving to testing. Otavio, is it ok to unblock it? It is safe.. unblock it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimuoewv2tp73tj89mzsjtpjb2womwvuhppj-...@mail.gmail.com
Bug#594127: Fix for bug number 590028 is incomplete
On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] After thinking about this some more and actually trying to implement the hook scripts, I think I agree. These symlinks are horrible and by default we should not create them. As a stopgap, boot loader packages may create and then use the links, but I would much prefer that they construct a menu of all installed kernel versions, as GRUB and extlinux do. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: Digital signature
Bug#594127: Fix for bug number 590028 is incomplete
On Sun, 29 Aug 2010 16:20:20 -0400 (EDT), Ben Hutchings wrote: On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] After thinking about this some more and actually trying to implement the hook scripts, I think I agree. These symlinks are horrible and by default we should not create them. As a stopgap, boot loader packages may create and then use the links, but I would much prefer that they construct a menu of all installed kernel versions, as GRUB and extlinux do. Hmm. Well, I agree that the approach taken by grub-legacy and extlinux is more flexible. It allows more than two kernels to be bootable. But boot loaders such as lilo and zipl have historically used symlinks, and the symlink maintenance logic in my generic boot loader hook scripts, http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader and http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader, isn't really that complex. I'm curious as to why you consider symlinks to be horrible. For now, on my own systems, I have extracted the symlink maintenance logic from the above generic boot loader hook scripts and have created new hook scripts which I call zy-symlinks. It allows me to use the new boot loader packages with their kernel hook scripts which only invoke the boot loader installer without modifying them. I also have my own generic initramfs hook script which I use with zipl, http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader. (By the way, I like the way you were able to avoid a bashism, namely substring expansion, by using a case statement in lilo's initramfs hook. Very clever!) But Debian clearly needs to do *something* about this problem *somewhere*. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/631424779.459359.1283131904359.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
On Sun, 2010-08-29 at 21:31 -0400, Stephen Powell wrote: On Sun, 29 Aug 2010 16:20:20 -0400 (EDT), Ben Hutchings wrote: On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] After thinking about this some more and actually trying to implement the hook scripts, I think I agree. These symlinks are horrible and by default we should not create them. As a stopgap, boot loader packages may create and then use the links, but I would much prefer that they construct a menu of all installed kernel versions, as GRUB and extlinux do. Hmm. Well, I agree that the approach taken by grub-legacy and extlinux is more flexible. It allows more than two kernels to be bootable. But boot loaders such as lilo and zipl have historically used symlinks, and the symlink maintenance logic in my generic boot loader hook scripts, http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader and http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader, isn't really that complex. I'm curious as to why you consider symlinks to be horrible. Because of the limitation to two versions, arbitrarily designated 'current' and 'old'; the fact that they could be in /, /boot, or even configured to be elsewhere; and the problem of stale links. For now, on my own systems, I have extracted the symlink maintenance logic from the above generic boot loader hook scripts and have created new hook scripts which I call zy-symlinks. It allows me to use the new boot loader packages with their kernel hook scripts which only invoke the boot loader installer without modifying them. I also have my own generic initramfs hook script which I use with zipl, http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader. (By the way, I like the way you were able to avoid a bashism, namely substring expansion, by using a case statement in lilo's initramfs hook. Very clever!) But Debian clearly needs to do *something* about this problem *somewhere*. I met Colin Watson last night and he said that he (as GRUB maintainer) and Daniel Baumann (as syslinux maintainer) had discussed writing a common boot loader policy. Due to the interaction with kernel packages and initramfs builders, I think we could combine this with the extension of the kernel and initramfs hooks policy. I don't think this urgently needs to be fixed before squeeze, as it is only affects unofficial kernel packages. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
