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
Bug#529624: netbase: networking should not be stopped on reboot or halt
On Thu, May 21, 2009 at 7:11 PM, Marco d'Itri m...@linux.it wrote: Not going to happen: releasing DHCP leases is more important. This could be done by calling dhclient3 with -r parameter somehow, but it isn't even required by the protocol. Is this an acceptable workarround for the desktop computers? Thanks The client normally doesn’t release the current lease as it is not required by the DHCP protocol. Some cable ISPs require their clients to notify the server if they wish to release an assigned IP address. The -r flag explicitly releases the current lease, and once the lease has been released, the client exits. If the client is killed by a signal (for example at shutdown or reboot) it won’t execute the dhclient-script (8) at exit. However if you shut the client down gracefully with -r or -x it will execute dhclient- script (8) at shutdown with the specific reason for calling the script set. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Is the FHS dead ?
On Mon, Feb 16, 2009 at 5:14 PM, Josselin Mouette j...@debian.org wrote: Le lundi 16 février 2009 à 14:20 +, Matthew Johnson a écrit : the FHS should certainly continue to exist and be coordinated between distros though. I agree that if it needs taking over we should do so in cooperation with the other big distros. Certainly. It's just that someone needs to start the work. There is no need to create another standard, FHS is being continued in the LSB project at linuxfoundation.org / freestandards.org. FHS was the starting point for LSB. Even if the LSB project has been criticized by the Debian project, this seems to become the the facto file hierarchy standard for Linux. It is not perfect, but is being adopted by the majority of Linux distros. Thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Tue, Oct 28, 2008 at 2:59 AM, Brian May [EMAIL PROTECTED] wrote: Steffen Möller wrote: Teodor happened to have nicely explained my objections to rename plink. Except what he said is wrong, puttygen hasn't been renamed. Yes, puttygen hasn't been renamed. It was a wrong assumption from me .. Dear Colin, if you don't mind too much, or if you could be bribed with a few beers, please be so kind to rename the plink binary package. If we rename plink in putty (I think that is what you are asking?), that it going to make our version of putty inconsistent with every other putty package out there. This program is often used by scripts, they will break too. I still believe it is best to rename 'plink' to 'puttylink' in putty-tools binary package. Anyway, this should be fixed for squeeze since in lenny there is no conflict (plink is not included in lenny). Thanks
Re: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools
On Tue, Oct 28, 2008 at 12:54 PM, Steffen Möller [EMAIL PROTECTED] wrote: Charles Plessy schrieb: Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit : I still believe it is best to rename 'plink' to 'puttylink' in putty-tools binary package. Anyway, this should be fixed for squeeze since in lenny there is no conflict (plink is not included in lenny). That was based on the assumption that the project name is well established (plink). I had no idea and I couldn't find on the project site what 'p' stands for. A more appropriate and suggestive name for the project is this one given by upstream: snplink. I have a feeling that upstream will change the project name from plink to something more appropriate (like snplink) to avoid the confusion. Upstream documented the renaming on his website, so I think that that is the (happy) end of the story :) Yes, it is. :) To summarise things up: the renaming of the executable of plink to snplink renders the plink package inferior to a manual installation of plink under the proper name. What I'll do now unless I hear some objections that I am mentally prepared to follow: I'll prepare the new version, add the conflict to debian/control to close 503367 (won't fix) and herewith truly apologize for all these emails. That would be serious bug against 'plink' according to Debian policy. Read the whole thread starting at [1] or this specific message [2]. Thanks [1] http://lists.debian.org/debian-devel/2008/10/msg00633.html [2] http://lists.debian.org/debian-devel/2008/10/msg00644.html
Re: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Sat, Oct 25, 2008 at 12:24 PM, Charles Plessy [EMAIL PROTECTED] wrote: Since Plink is younger than Putty, I think that the burden of the renaming is for us (the Debian Med packaging team). I plan to rename /usr/bin/plink to /usr/bin/Plink, that would be a symbolic link to /usr/lib/plink/plink so that with an appropriate PATH, users can rescue their scripts. This *upercase first letter* thinghy is no annoying and ugly .. But before doing so, I would like to ask the readers of debian-devel: - if it is not a bad idea to have to programs whose name only differs by case (do we support file systems à la Macintosh?), - if they have a better idea in general. IMO a simple Conflicts: putty-tools is enough. If they provide the same functionality than an alternative is better than conflicting with each other. Cheers
Re: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Sat, Oct 25, 2008 at 6:21 PM, Charles Plessy [EMAIL PROTECTED] wrote: Le Sat, Oct 25, 2008 at 06:07:11PM +0300, Teodor a écrit : IMO a simple Conflicts: putty-tools is enough. If they provide the same functionality than an alternative is better than conflicting with each other. Hello Tedor, thanks for the feedback, but this would be against our Policy, because the two files competing for the same name do not provide the same functionality: Yes, it seems to be the case. I'm a newcomer to Debian but IMO this restriction about Conflicts in s10.1 seems a little unpractical. The Conflicts section of the policy [1] does not specify anything about the restriction of packages that should conflict on each other *only* if they provide the same functionality. The *alternative* mechanism is the most natural way to handle the conflicts between packages that provide the same functionality. Otherwise, the Conflicts directive could help for packages that doesn't provide the same functionality. Thanks [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
Re: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Sat, Oct 25, 2008 at 7:40 PM, Frank Küster [EMAIL PROTECTED] wrote: No, if the functionality is different, it should be possible to install and use both at the same time. Yes, this seems to be the rationale for this restriction in the policy. Thanks
Re: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Sat, Oct 25, 2008 at 12:24 PM, Charles Plessy [EMAIL PROTECTED] wrote: Both programs are intended for command line, and could be used in scripts. We may even find users who want to install both at the same time. Very annoying… Since Plink is younger than Putty, I think that the burden of the renaming is for us (the Debian Med packaging team). I plan to rename /usr/bin/plink to /usr/bin/Plink, that would be a symbolic link to /usr/lib/plink/plink so that with an appropriate PATH, users can rescue their scripts. Since renaming seems to be the only solution, than IMO it is more appropriate to rename 'plink' in putty-tools than in the plink packages since this is exactly the source/binary package name. This has been done already in putty-tools for the 'puttygen' binary. Thanks piti:~# dpkg -L putty-tools [snip] /usr/bin/pscp /usr/bin/psftp /usr/bin/plink /usr/bin/puttygen
Re: Xen status in lenny?
On Thu, Sep 18, 2008 at 6:43 PM, Bastian Blank [EMAIL PROTECTED] wrote: This kernel have a critical problem: | Bad pte = 11764060, process = vsftpd, vm_flags = 100071, vaddr = b7f85000 | Pid: 8129, comm: vsftpd Not tainted 2.6.26-1-xen-686 #1 | [c015edcd] handle_mm_fault+0x61b/0xe78 | [c0162b8f] mprotect_fixup+0x6d3/0x735 | [c010ee3e] do_page_fault+0x684/0xbd6 | [c0162d6b] sys_mprotect+0x17a/0x1df | [c0162dbd] sys_mprotect+0x1cc/0x1df | [c010e7ba] do_page_fault+0x0/0xbd6 | [c02ccbe5] error_code+0x35/0x3c | === | VM: killing process vsftpd The pte have bit 6 set: PAGE_DIRTY aka PAGE_FILE. But the vm flags lacks the marker for a nonlinear (file based) mapping. Here it is another one: | Bad pte = 5e164060, process = BORGChat.exe, vm_flags = 100075, vaddr = 34 | Pid: 8575, comm: BORGChat.exe Not tainted 2.6.26-1-xen-686 #1 | [c015edcdhandle_mm_fault+0x61b/0xe78 | [c017040ado_sync_read+0xbf/0xfe | [c012f06cautoremove_wake_function+0x0/0x2d | [c010ee3edo_page_fault+0x684/0xbd6 | [c01470d1audit_syscall_exit+0x2a1/0x2bd | [c010974edo_syscall_trace+0x62/0x165 | [c010e7bado_page_fault+0x0/0xbd6 | [c02ccbe5error_code+0x35/0x3c | === | VM: killing process BORGChat.exe Cheers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please help me make athcool compatible with dependency-based init systems
On Wed, Jul 23, 2008 at 10:52 PM, Nicolas Boullis [EMAIL PROTECTED] wrote: Sorry for asking a potentially stupid question, but how does the Default-Start keyword affect the bahvior of the system? Refer to http://wiki.debian.org/LSBInitScripts for details. Maybe this page should be updated for LSB 3.2? Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Xen status in lenny?
On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen [EMAIL PROTECTED] wrote: See: http://wiki.xensource.com/xenwiki/XenParavirtOps I think x86-64 xen patches are going in for 2.6.27.. Lenny will not support 64bit, no dom0.. so basicly lenny can only be used as a 32bit domU .. unless people build/get some other dom0 kernel. What about the patches for x86-64 support in domU? If these are going to be included in 2.6.27 does it mean they qualify [1] to be included in the kernel for lenny? Thanks [1] http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
