Re: Something wrong with eglibc 2.13-3 ?
2011/5/12 Charles Plessy ple...@debian.org: dpkg (subprocess): unable to execute rm command for cleanup (rm): No such file or directory dpkg: error while cleaning up: subprocess rm cleanup returned error exit status 2 Could not exec dpkg! E: Sub-process /usr/bin/dpkg returned an error code (100) E: Failed to execute /bin/rm: No such file or directory E: apt-get dist-upgrade failed This would explain why my desktop system (with unstable up-to-date via unattended-upgrades) was broken this morning and I couldn't execute any application. The error message was the same (APPNAME: No such file or directory). After reboot I get a kernel panic, the last lines are: Begin: Running /scripts/init-bottom ..done. run-init: /sbin/init: No such file or directory [ 3.85] Kernel panic - not syncing: Attempted to kill init! [ 3.85] Pid: 1, comm: run-init Not tained 2.6.38-2-amd64 #1 [ 3.85] Call trace: [ 3.85] [ff...] ? panic+0x92/0x1a1 [ 3.85] [ff...] ? sched_move_task+0xa7/0xb2 [ 3.85] [ff...] ? do_exit+0x73/0x736 [ 3.85] [ff...] ? vfs_write+0xc9/0xff [ 3.85] [ff...] ? complete_and_exit+0x0/0x16 [ 3.85] [ff...] ? system_call_fastpath+0x16/0x1b Thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinYcX=rxog80fpb+qndwg6kdqt...@mail.gmail.com
Re: A concrete proposal for rolling implementation
2011/5/5 Raphael Hertzog hert...@debian.org: On Thu, 05 May 2011, Stefano Zacchiroli wrote: Also, having the unstable-next suite you've mention would tight more the deployment of rolling to other project mechanisms, while the rest of the proposal enjoyed much more decoupling. There's no reason why this unstable-next would be a requirement to start rolling. It's just a suggestion of how to handle package updates during the freeze. I've been disappointed at first to read that so many approve this rolling implementation that in fact is just c-u-t, constantly usable testing [1]! Outside of the freeze period it doesn't really matter and one can say rolling==cut. However, some key points added later with 'unstable-next' really completes the missing piece to call it rolling! During the freeze unstable is in a de facto freeze, but packages not suited for the next stable release in preparation could be uploaded to 'unstable-next'. The 'unstable-next' suite could be used for several purposes: 1) some packages could be picked from it for 'unstable' - testing 2) all packages from unstable-next are a candidate for rolling 3) after the final stable release all packages could be moved directly from 'unstable-next' to 'unstable'. Although #3 might not be practical without other infrastructure changes, but was the core of this discussion in debian-devel. rolling has only derived from not freezing unstable, but the initial proposal was to be able to never freeze unstable. It is my believe that by using the freeze time to upload packages as usual will help to prepare the next release by extending the pre-freeze development from 1.5 years to 2 years. To conclude, unstable-next suite (or some other name [2]) is a requirement for rolling [3]. Thanks [1] although the CUT team might have a different view for 'cut', I don't know what's the current direction [2] but not experimental [3] I agree with Raphael that is not a requirement to *start* rolling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin3czqjafzsk1bsk6akd_w22yc...@mail.gmail.com
Re: [RFC] disabled root account / distinct group for users with administrative privileges
On Fri, Oct 22, 2010 at 1:44 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Carsten Hey writes (Re: [RFC] disabled root account / distinct group for users with administrative privileges): A group named sudo or sudoroot is somehow linked to sudo as tool used to gain administrative privileges. No one knows if in future an other tool will be the de facto standard to gain privileges, as sudo is now, and having a group sudoroot whose members are allowed to gain to become root using an imaginary suto command sounds wrong. Speaking as the author of a program (really) which would also want to use the same group, I have no problem at all with a group name which mentions sudo specifically. This is probably the best way to ensure that the name is meaningful and not used elsewhere for something else. sudoroot is better than sudo, as there already is a sudo group and therefore people may already be using it for something else. I'm proposing to use 'sysadmins' (plural as 'users') since its kinda short and commonly accepted for this purpose on job announcements. Thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin7qzt_gdxgpkrv0oawo9gqdprjboy1n3mdk...@mail.gmail.com
Re: Default value of net.ipv6.bindv6only should revert to 0
Hi, On Wed, Apr 7, 2010 at 10:14 AM, Bernhard R. Link brl...@debian.org wrote: I personally would prefer ipv6 to still be a module so it can be blacklisted or some other way to disable it, but having this option on by default at least avoids many annoiances in ipv4 world. I've always disabled IPv6 on all hosts (blacklist or alias to /bin/true on Debian = 5.0) and on squeeze/6.0 it works from the boot loader: | r...@host:~# grep ipv6 /etc/default/grub | GRUB_CMDLINE_LINUX_DEFAULT=ipv6.disable=1 panic=20 vga=791 Of course that after this setup you'll see the failure to set bindv6only=1 at every boot as this key doesn't exist. Having IPv6 enabled might be a good thing for those who have this capability from their ISP, but I'm disabling it for several reasons the first reason being the ISP not supporting IPv6. Cheers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x2k796aed871004071244k8ec2e599l871db94670251...@mail.gmail.com
