Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 12:50:43AM +0200, Josselin Mouette wrote: Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? I'm not sure that this is true. OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an asoundingly bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120809231631.gc25...@codelibre.net
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 01:30:54PM +0200, Andrew Shadura wrote: On Wed, 08 Aug 2012 19:26:27 +0800 Thomas Goirand z...@debian.org wrote: This kind of remark make be say that probably, it'd be nice to have ifconfig display a warning as this one: ifconfig is deprecated, please use ip instead It'd be terrible. Please don't even think of it, okay? Let people decide themselves what to use. As a distribution we have to decide on a default, and that is ip. We took the effort to remove all use of ifconfig from ifupdown and other related tools for wheezy precisely to make it removable and optional, so that it can eventually be removed. While it's fine for an end user to continue to use ifconfig, we should continue to remove its use by ourselves and in programs in Debian. Warning the user that they are using an obsolete tool is IMO entirely justified, particularly when there is a much better and more capable replacement. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120808114042.gy25...@codelibre.net
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 03:20:11PM +0200, Ulrich Dangel wrote: Not just ifconfig, there is also route, iwconfig, blkid etc. And moving them to other directories and add symlinks from sbin/$PROG to bin/$PROG is error prone. Normal users do not need to know or care about these tools. Only admins use them, or tools that set things up on behalf of the user. Having them in the default path serves no purpose other than a minor convenience to a minority of users. The number of times I've wished e.g. blkid was in my path is... zero. Having these immediately accessible to all users isn't strictly bad, but may cause confusion and just pollutes the namespace for tab completion etc. If you want them in your path, it's trivial to add /sbin to it yourself. I can't see any compelling reason to make them the default. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120808133843.gz25...@codelibre.net
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 09:28:03AM -0700, Russ Allbery wrote: Yes, we could file bugs and go to the work of moving things and leaving symlinks behind to not break other things, but that's a lot of work. And it's ongoing work to keep things sorted into the right place. Whereas if we moved everything and left a symlink behind, that's way more work in the short run but then we would be done and no one would have to think about the distinction again. If we did want to do a blanket move of everything in /sbin to /bin (and for /usr/sbin to /usr/bin), we could do this in a single operation in e.g. base-files. It wouldn't require any path changes in individual packages, but we would need to fix any name clashes first, and also to bail out if any were found during the upgrade. It should be possible to do entirely atomically as well if we hardlink the binaries, and then replace the dir with a symlink. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120808164835.ga25...@codelibre.net
Re: tasksel: Default desktop: Gnome→Xfce
On Sat, Aug 04, 2012 at 12:18:45PM +0200, Cyril Brulebois wrote: Josselin Mouette j...@debian.org (04/08/2012): This is for example why we still don’t have tmpfs by default. Your example is wrong. On a freshly-installed system: tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=161324k) This is only until sysvinit migrates to testing though. We did (regrettably, IMO) change back the default. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120804111008.gs25...@codelibre.net
Re: Bug#683486: ITP: barman -- Backup and Recovery Manager for PostgreSQL
On Wed, Aug 01, 2012 at 09:56:56AM +0200, Marco Nenciarini wrote: * Package name: barman postgresql-barman would make it a bit easier for people to find. Most of the other postgreql packages use the postgresql- namespace. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120801091825.go25...@codelibre.net
RFH: NFS support and networking
Hi folks, For several years, there have been a number of NFS issues in initscripts. Some of those are now resolved, but there are still a number of NFS issues present in wheezy which I'm unable to resolve myself, either because I can't reproduce them or because I'm insufficiently familiar with the issues involved. Some of these may be consequences of the new ifupdown and associated changes, but not all. We still have the ASYNCMOUNTNFS option in mountnfs.sh, which is a horrible hack in its own right. We should have a single way to mount NFS filesystems that works in all cases, rather than a poorly documented option that makes a broken script work in some situations. Current issues are: #540291 initscripts: fails to mount NFS shares at boot #674039 /etc/network/if-up.d/mountnfs: boot stalls by 3 minutes because network is not configured yet (using network-manager) But we also have: #430760 No NFS mounts after waking up server during client boot #434570 if-up.d/mountnfs doesn't work on nfs-root systems #434775 nfs-common: fails to mount nfs volumes when booted with ip= command line #496007 initscripts: if-up.d/mountnfs should not try to wait for all auto interfaces #521357 initscripts: /etc/network/if-up.d/mountnfs fails with slow interfaces (Token Ring) #530583 add ASYNCMOUNTNFS to default rcS #540291 initscripts: fails to mount NFS shares at boot #551555 mountnfs.sh: start should declare dependency on name resolver #578254 nfs mounts are not working at boot #602212 initscripts: NFS shares not mounted properly when using WLAN and NetworkManager #608862 network-manager: automounted nfs volumes no longer mount when connecting with wireless #612519 initscripts: mountnfs ignore ASYNCMOUNTNFS=no for hotplug interfaces #616330 /etc/network/if-up.d/mountnfs: mountnfs script stalls for 2minutes on boot Even discounting the network-manager related bugs, there are a lot of issues with NFS, and there have been for many years. If we want decent NFS support in wheezy, the mountnfs.sh and /etc/network/if-up.d/mountnfs scripts need some attention from an NFS expert. I would be very grateful for anyone who could contribute their time for getting some of the above issues resolved for wheezy. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120728100355.gx25...@codelibre.net
Re: solving the network-manager-in-gnome problem
On Tue, Jul 24, 2012 at 11:31:26AM +0200, Vincent Lefevre wrote: On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote: I don't think it follows at all that because there are init systems which conflict with sysvinit, Debian does not support multiple init systems. But in such a case, sysvinit shouldn't be an essential package (and packages that need it should thus have an explicit dependency on it), since it isn't really needed in a working Debian system. sysvinit will drop the essential status in wheezy+1. Just lack of time and testing the consequences prevented this being done already. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120724105617.gq25...@codelibre.net
Re: solving the network-manager-in-gnome problem
On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote: On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote: On Mon, 23 Jul 2012, Vincent Lefevre wrote: so that if you want to make things more consistent, you should get rid of /etc/default entirely. /etc/default is used for a lot more than just enabling/disabling services, and it will not go away. But with /etc/default, you can override options. For instance, for sshd, the port can be provided either in /etc/ssh/sshd_config or in /etc/default/ssh. One one and only purpose of a file in /etc/default is to modify the behaviour of the init script, as an alternative to editing the script directly (since this causes dpkg conffile prompts and is quite annoying). The fact that sshd lets you add additional arbitrary options there does not make that the intended use or good practice. It is neither. Now, if you just mean removing enable/disable switches for initscripts from /etc/default/*, that should be doable with some effort. And that's what this subthread is about. No, I just mean that configuration of some service should be in a limited number of places. But if you agree that it's fine for /etc/default to override config setup somewhere else, then there should not be any problem with ENABLE/DISABLE. It's not compatible with init systems which do not use the init scripts directly, e.g. systemd. A common interface for enabling/ disabling is required, which can then do the system-specific thing for enabling/disabling. That should probably be update-rc.d (though the name is sysvinit-specific). Since we're going to be changing the update-rc.d interface in wheezy+1, maybe we could simply replace it with e.g. update-service and provide a compatibility wrapper. And we should ensure that all init systems provide add/remove/enable/disable actions. The stop|start actions are going to simply defer to the defaults action, and will ultimately go. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120723165920.gm25...@codelibre.net
Accepted schroot 1.6.3-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 21 Jul 2012 10:42:53 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.6.3-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Changes: schroot (1.6.3-1) unstable; urgency=low . * New upstream stable release. * Revert pam_env change in 1.6.2-1. This is due to running the PAM module on the host, it would inappropriately set LANG, LANGUAGE and potentially other environment variables which would be incorrect inside the chroot. Checksums-Sha1: 597b5d9b711d89c80802ae3c3980e5aa267071f1 2424 schroot_1.6.3-1.dsc 14c102c13f2bd50f1d0bdc315f6f45f488b631fb 730756 schroot_1.6.3.orig.tar.xz cddb38e302f75e7664d7d04c12bc3a77b10ee270 29365 schroot_1.6.3-1.debian.tar.gz 2fcc3554ea4d74ca7ad75acff83eacf2831f6fb7 264360 schroot-common_1.6.3-1_all.deb aa85aa19bf81183d7b6a764ea249d0b068f45a25 2297312 libsbuild-dev_1.6.3-1_amd64.deb 9aa90a9eeed4ccc25a67434431b88d8f6ad5829b 29218270 schroot-dbg_1.6.3-1_amd64.deb 2f240447a3e5df8c4e14badd76d68e4a5a6df0cc 8274348 libsbuild-doc_1.6.3-1_all.deb d28b84750e4d0e0a849d07b63cf45b25df702730 970494 schroot_1.6.3-1_amd64.deb 688e92032b017058167d160d853f882099d16c9d 374782 dchroot_1.6.3-1_amd64.deb f08a4e6490e44f38ccfcf4a601dfbaf0d8ec6f83 374266 dchroot-dsa_1.6.3-1_amd64.deb Checksums-Sha256: 83ec9920967c49c945f292d1c8fbef1b6cbcb220a7e85a297384cf18245738d8 2424 schroot_1.6.3-1.dsc 0b914a0ae1eef0288e5bf016c14031d3433d1b3f18820bebc5480647594ebc82 730756 schroot_1.6.3.orig.tar.xz 6711fedef3041acc2661b2ac5a37b421e0d45825a0cbbb511149f189068449e3 29365 schroot_1.6.3-1.debian.tar.gz 99e545b804e28b76be8b8d8ccdd5ad355d90c9893f3dc4d0404487ec762661cb 264360 schroot-common_1.6.3-1_all.deb 9882eb67a4b0bbeeadb6870308415748ef46d295bbc0e09bae9e8dd10d3f 2297312 libsbuild-dev_1.6.3-1_amd64.deb ae8eacb95004a55663710cf38a40176ddd790cdcbf96137573dc7069b9ad5684 29218270 schroot-dbg_1.6.3-1_amd64.deb 13e9e8ed3e714185f7aa2d65cb3bdedffa2e9a8ed12b63d95735b03c432e3b47 8274348 libsbuild-doc_1.6.3-1_all.deb 81f7b6f8ff59298b6edcfa641d07ce5537cbfd059dabe9f1a8315b8ec6320144 970494 schroot_1.6.3-1_amd64.deb 9f6ed8a7d25ea38eb2d8c19081f90044732363544e2b2a3f9eed7bd0775f2391 374782 dchroot_1.6.3-1_amd64.deb 0aee41271a7a11e77e95f8bbd5b969ab915b3f7c2ff9d301f30ae9bd193bb971 374266 dchroot-dsa_1.6.3-1_amd64.deb Files: dfd5313665ade26e6d9c58811ca28ac8 2424 admin optional schroot_1.6.3-1.dsc f6b1badef213ce8e9ef37bb3fc213390 730756 admin optional schroot_1.6.3.orig.tar.xz 5915ef9ab224c37eea28b7dc2c7b8535 29365 admin optional schroot_1.6.3-1.debian.tar.gz 517bb7b26cbb50208930d6385fc92fc4 264360 admin optional schroot-common_1.6.3-1_all.deb 50cba804dad0c365b7164c29e69688de 2297312 libdevel optional libsbuild-dev_1.6.3-1_amd64.deb 5bd91179435e58b470097c347c6d514d 29218270 debug extra schroot-dbg_1.6.3-1_amd64.deb 8795563cbd6fb814842bcbfbb4ced8c5 8274348 doc optional libsbuild-doc_1.6.3-1_all.deb d7ca8913f961c8974f268306feec5c4b 970494 admin optional schroot_1.6.3-1_amd64.deb ac8c26eea993a6757bbae70b6b41c0bf 374782 admin optional dchroot_1.6.3-1_amd64.deb f7de48b8f5bcaa679dd57a6bc8200a66 374266 admin optional dchroot-dsa_1.6.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQDc3AAAoJEOJSSsUKn1xZYgMQAJQizhYJDWtUys2tUkCMUrqf 3A46wG/HufI+g7GA0gAhIbQkmE3E2ypCpsc+ULEqxubciWeFFEiPSPlSDaYD0dml GJTTRFdbKz1O7XuiyTnhaoVOvMW5jsUHVfHO8CrxAyatlgb7BOf9r7sDDtx5ZyT9 0FkQ0B9yLL78BcZ8wgwTESL5kuz5QQqirFylPPFANvOdIhAf5X/mh7iG+sVCsRLV ddHqg75t4W70J0V6O5lR29JTpl1xAtNF8p4CViDBVswJBxoVRxL8JutWoD/acbX2 /QUULGHey81s64dxAawfajICHu19Bx8mF0KspoAuhG977FdaN9DbsgAh4EcNgezX 6yPY3L7ju1Gk0JmaQ5IcaoV6VMht7fprrIi9+Q6f/H2ouh3HtPw4H8CUxq1VosqD LgXjEFHOqmbztEhyhrRXVT82RgHBjs41ykdM1bh169bzWrlesOP90ZLEV87bsk3l zAwHtcotTcpi3d6xISU0nZh4GPAztcErpVkOFfcWYvbbxbdU4b+1CVu4zBKRFamM Tu4lCAyPIn9xGwIVYkl8lMoZ20Zyj10XmXrYr7sUiu8UMERjYsoEWiFvDgSjqNQB OeJZQn6aW2Y+HHWYnVtZ73hFTJjTKSIG76fVQ8Q2n3VJttMZch8ZoPtYKr8Ie2mr /JQ60Hq4NNYvr50+DWU5 =/ZIC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1strpz-0004nh...@franck.debian.org
Re: solving the network-manager-in-gnome problem
On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote: On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote: ENABLE/DISABLE switches are *ugly*, I disagree. ENABLE/DISABLE switches have some advantages: they are more readable than a set of symlinks, allow all the settings of some service to be grouped in a single place, and can be managed more easily by VCS software. While this is true, it's not the way that sysvinit works. Other systems such as systemd may provide such facilities natively, but initscripts do not. If you're going to use sysvinit, then you should just use update-rc.d foo disable to disable it. as their effect is not limited to boottime changes. Especially in case of packages who ship with such a variable set to disable by default, this is very annoying. The user may not want a service he didn't request or he hasn't configured yet to be enabled by default. For instance, some packages may be installed automatically (due to dependencies), or one may want the client, but not the server. Such services should be disabled by default. This is not the general consensus--by default daemons are started if the package is installed. This has been already debated extensively many times over. Irrespective of whether your personal opinion is that this is a good or bad thing, that's just the way it is at present. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120722131141.gh25...@codelibre.net
Accepted sysvinit 2.88dsf-29 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Jun 2012 23:21:06 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-29 Distribution: unstable Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 677097 679523 679612 679972 681639 Changes: sysvinit (2.88dsf-29) unstable; urgency=low . [ Steve Langasek ] * initscripts: - Improve /dev/shm to /run/shm upgrade handling in the postinst (improvement for #674178). . [ Roger Leigh ] * initscripts: - Remove /lib/init/rw if possible. Closes: #679612. - If /run is a symlink to /var/run, correct this on both upgrade and on boot. On upgrade, the proper /run migration will occur on reboot. On boot, the system will require rebooting to fully migrate /run to a working configuration (but this will only occur on systems which are already broken, it's not an upgrade path). This correct problems with udev breakage due to /run being mounted twice when /run is a symlink. Closes: #677097, #679523. - Start urandom on initial install, so that a random seed exists on first boot. Closes: #679972. - Restore creation of /var/log/dmesg (Closes: #681639). * sysv-rc: Remove unused debconf logic in postinst. Checksums-Sha1: 54d5bbb8ab1c82ad86f240e18b019fceec06387e 2342 sysvinit_2.88dsf-29.dsc 02ee45710510fc0a2fc7bf4533d1246440a1b414 205973 sysvinit_2.88dsf-29.debian.tar.gz e11df634ff29a85e4f6d310b9b0d51e74622495f 131768 sysvinit_2.88dsf-29_amd64.deb 4b2e3619a979374539fc448305ed3ae85b1ffac2 98028 sysvinit-utils_2.88dsf-29_amd64.deb 771a2a0baae48c768a99140b9305b29f2817c4b3 79666 sysv-rc_2.88dsf-29_all.deb 5d166bbdad4811bea7e07526a845d615c04ae237 90282 initscripts_2.88dsf-29_amd64.deb 3bdf3eb55feabe022bd712e876482de36c571052 53812 bootlogd_2.88dsf-29_amd64.deb Checksums-Sha256: a46a3e69578f22219558a058a80ff978d8edbd6101e3d9bd2025c58ed8d6fe88 2342 sysvinit_2.88dsf-29.dsc 013cd30c1f5cb418091ce869ca80af658623fe6030f69255f444d730e770e3ca 205973 sysvinit_2.88dsf-29.debian.tar.gz 8b86f4020fb71b39381d53f53e0d2df8e1c3ea4106a72c9f75e85d07785cdc8a 131768 sysvinit_2.88dsf-29_amd64.deb 661bfd146ef1deb230f539dbe99d3bd9591c7fd80d00c0d3ab5615a9bc39b93c 98028 sysvinit-utils_2.88dsf-29_amd64.deb 289e228b8b9730ae3c9dfa9b4ebf785687087ed9f5a2a91658e3f9c5ba7f994e 79666 sysv-rc_2.88dsf-29_all.deb 1c1cd10415e47aa4435db812461771a9cdb093eaeb35666bbc20453f3f97ff13 90282 initscripts_2.88dsf-29_amd64.deb df585179d5844ed2c0a9e8f88de2e12dbf66f9e51295ac8d8454778ca10ab346 53812 bootlogd_2.88dsf-29_amd64.deb Files: 7662fa846ecff04529e4e14141cf0bc6 2342 admin required sysvinit_2.88dsf-29.dsc 9178c37aaa97e3907f6c65bc31fd2f1a 205973 admin required sysvinit_2.88dsf-29.debian.tar.gz d32fc681163059703f38e74731bb673b 131768 admin required sysvinit_2.88dsf-29_amd64.deb c030cac65c5b93accf6d59ea7a76bf38 98028 admin required sysvinit-utils_2.88dsf-29_amd64.deb 89986589edf9824590e38342731dc38e 79666 admin required sysv-rc_2.88dsf-29_all.deb b0a71f92e4fea2fe75fa194976a48523 90282 admin required initscripts_2.88dsf-29_amd64.deb da483c3c54903929473fda1976431813 53812 admin optional bootlogd_2.88dsf-29_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQC8oQAAoJEOJSSsUKn1xZzzgQALXFV2o1ot0REJrodyHSSweF U69O3GxPv5rePOM7uPcWfp623VmU2GqtwN+hYcSShNwsX2V1j0zl5YXwdGU14UD/ qJ0j+xxIffXhCPvy/IREw3tYNg4lE7KNJA+Df9Y0uQAwkCabz7qRHFElerTm5vm/ oGQJF8dXtcMX0Zc0T0vHOYF7zaHKXuEgne10x3JRZ/JhQFlV4QDgH2UWsJfc6ov2 a85x9UlT4LzOtAFN/ZunybFXQMlVpiew7MWQljJNynjn/ToX0aE+W362TBVdERdN EkQDyk9vVuc0jDL9opcNUUl1SgxZII4D2vTEDENOCVyl0u8Y6upA6Xx8vb4WlubK EPaC98A9Tyxj+mFCEcBwb/4aqjtNKxLdexkualL48nY9xMogGigJZfQZtfnOm+8E yQhBrl5DUWSCXH18bj3izVAeMdwO09vKV9LvLkqWLh1hmyQqS3oGD32FPXQC/tHc 8xlo7cYHT0Gauu+bUdGRTkLHJIeFXmkk9ptyNrtMSdBMwjozeNTtpnqOQxinqlhK tpoGqp1qRD+Qpb7TgJrcNwOrISl0Ej+p2L3nMKYjJ2bGBb6w4mwUpDMoZ4Ni+R/S obXOFaTrgNG3c0NiPD2CikRHS90ZI34ngMBA68DsyIE+vLosp9XwtsDUXaKqXQiO qkg1/l1cnIVb6KC207p5 =FfQ2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sssmu-jk...@franck.debian.org
Accepted schroot 1.6.2-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Jul 2012 23:10:24 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.6.2-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Changes: schroot (1.6.2-1) unstable; urgency=low . * New upstream stable release. * schroot: - PAM pam_env is used to set up additional environment from /etc/security/pam_env.conf and /etc/default/locale. - /usr/bin/X11 and /usr/games have been removed from the default PATH. Checksums-Sha1: 9f039ecc48f70ee588801f01eed1dc583c843329 2424 schroot_1.6.2-1.dsc 76ecaf7a4462a48287efc0b8ea0050fdbaf86b82 730696 schroot_1.6.2.orig.tar.xz aa3963dc20c056d797a8131eec6a8c1828de92d1 29342 schroot_1.6.2-1.debian.tar.gz 45960efac4ce73f58ed83997d1b7095c8c4c01b4 264046 schroot-common_1.6.2-1_all.deb 76c0e7ec1d375a2af3a9a2a1d8e43d23afc4f293 2296988 libsbuild-dev_1.6.2-1_amd64.deb 29e8aa5d284a223d5c8a6fe5522b660b5580d16e 29219438 schroot-dbg_1.6.2-1_amd64.deb 676b60fe3c571d288d7294e42142baaf482431c7 8273492 libsbuild-doc_1.6.2-1_all.deb 7c5b9890d08bda966f79372bd597769479314187 970190 schroot_1.6.2-1_amd64.deb 646b33b09c2afb1fee3ccd57a355d4cf65ffeb66 374764 dchroot_1.6.2-1_amd64.deb 3863b46c129f4bac7f8c3306a3cd79c16505f709 374254 dchroot-dsa_1.6.2-1_amd64.deb Checksums-Sha256: 2d958999b886ea773b77abe42a6dffb29d8dc83c82d234483b134b832431139b 2424 schroot_1.6.2-1.dsc 411539518e0c47f81655f5f88e94de8477b259780cbd91d2ac3aebb134aa500e 730696 schroot_1.6.2.orig.tar.xz 9d5c621e8b1121ad160336e1dd63e29c39a9f4f8b4041e81f840dac97d239b26 29342 schroot_1.6.2-1.debian.tar.gz 9f5f957df2a344b833b903316e1eb82365644d10bbefbe43280bd133bc19cde6 264046 schroot-common_1.6.2-1_all.deb a872a6c65dccdd781409449e738fce1555f5f570324f16f3862810bb37ee2475 2296988 libsbuild-dev_1.6.2-1_amd64.deb 8f2173d920ae3b3163f8ab6938e8b5b99419c5b511dcbb8372b929b5e86c96b8 29219438 schroot-dbg_1.6.2-1_amd64.deb 62323d6936dda69fc5b7032666c93de3edf95e10946bf002f1dcb2845c7269fe 8273492 libsbuild-doc_1.6.2-1_all.deb 97ab78a686005f13b0d2c7ed64ca03eda27f8bc0e9e24c3457dc2a3f98dd4492 970190 schroot_1.6.2-1_amd64.deb 26e8f6ff0a9d5bbfc94632aa005ab7eaf9771c6757340f60f865494dcab8938e 374764 dchroot_1.6.2-1_amd64.deb cffb97f42b40515a193812412a803e58003c21ecc758701f55e9717688f293ae 374254 dchroot-dsa_1.6.2-1_amd64.deb Files: 8117ee1a11c2d23cfa7295524010bba7 2424 admin optional schroot_1.6.2-1.dsc 5bd38f5977f942ff3b8f9094abcd07b5 730696 admin optional schroot_1.6.2.orig.tar.xz 3b145edde758f0f772fc7e9856bde383 29342 admin optional schroot_1.6.2-1.debian.tar.gz 9dce2e11f11ca9a0443c3000452a627d 264046 admin optional schroot-common_1.6.2-1_all.deb 6da152a80686542311dc6738b84d3cd8 2296988 libdevel optional libsbuild-dev_1.6.2-1_amd64.deb a053f728961cf5551d74f4f1168d3c1f 29219438 debug extra schroot-dbg_1.6.2-1_amd64.deb 22aec08e7e46be85afb4d73b2510ae21 8273492 doc optional libsbuild-doc_1.6.2-1_all.deb f8159e47a44485f5df16d403d704d8c3 970190 admin optional schroot_1.6.2-1_amd64.deb 0f145c606d35404d73d3682113bd58e6 374764 admin optional dchroot_1.6.2-1_amd64.deb f3d6b7dff5b7421c3e8483c2d1a1238a 374254 admin optional dchroot-dsa_1.6.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQCnaeAAoJEOJSSsUKn1xZ47EP/3jw/FMdXCg60Ss+tkiMvhpW Db7VWLNerBzug3TCWHtfLTRa6Py6q3UUh4ZwRA1P4rcp2wWhRz6qSjorPCdXIn6w JpC0OdhsSnis24aRrhiYRVy7H208hRFYfKZI1laDgD78yjsy1VbNp6rwkyXNQg3x aM634uJOGqDa2QBmXY2UGksk524mPgl6xWHvUCuj9ap8ulanCnfF1EljdHXEP/EF VMfhMPr0+Hnkyfd0wHcNAgJ/2znhSgFuk3kwBV6c9PoUp3Byq5AQR7r4mPwiU9HG RR9cRCeboufbLM5rtJH2nK6Uj6YKOeWkym9LBZlw28556dxQdruGBqUTAl39HMXv LGbD92AfsmKpTQYuFQfwX468XosSpA8uhFNirOSv+AU2i2iDW2TucTlCa1A92Xxk tIT5QcHWdyrG7cqdJrg/b550wpwVYrxDQRhDo7LI2U33oRC0/dwRK1GlJ/OqAzqu AwGi82OKK6mPKSG6i1A6FjmiLe7xO4QK3IxwBydinzcZZ+YExmxlOp8g8DiJnSa4 ikWZISL9GyoaRJWKWa5zd8k7st0c2PwBzF0xOES+yfhGPgnu42/QIuA1aeHq30c+ Ixv79bD2ezWrZE9YcpTagKRT1ENZ0PkyPZ1Liou7LCkd05qsVd9++HCHeHJesS3r TFo+9oR1wYl13kNA1Yrf =FGfD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sswhg-00011v...@franck.debian.org
Accepted schroot 1.6.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Jul 2012 20:04:41 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.6.1-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Closes: 677811 680882 681876 681931 Changes: schroot (1.6.1-1) unstable; urgency=low . * New upstream stable release. * schroot: - Remove invalid and obsolete symlinks which were being created on install and upgrade, and no longer create them (Closes: #681931). - Fix 15binfmt setup script to bind mount binfmt binary correctly (Closes: #677811). Thanks to Vagrant Cascadian and Julian Andres Klode. - Building from git has been documented, as has the upstream release process (Closes: #680882). * dchroot: - Migrate dchroot.conf to schroot.conf format on upgrade (Closes: #681876). Also documented caveats in NEWS.Debian. * dchroot-dsa: - Migrate dchroot.conf to schroot.conf format on upgrade. Also documented caveats in NEWS.Debian. Checksums-Sha1: b2c6616c3e47c4fda883f11a2b17e407860a070f 2424 schroot_1.6.1-1.dsc bf9b2becd9ee07c18b3cd51493a0234512ec2247 730472 schroot_1.6.1.orig.tar.xz 7ecd5307d5afad69795d929353984207bacde0d3 29225 schroot_1.6.1-1.debian.tar.gz cb4ac906a8785567fb93f1cdbe8f09a8de396ad5 263694 schroot-common_1.6.1-1_all.deb f666d821fbae17fb048dc0c505928d83a353a10e 2296548 libsbuild-dev_1.6.1-1_amd64.deb 604650eb7a6fcf3c5833a4cbdcfadfaf3db1f1d9 29217038 schroot-dbg_1.6.1-1_amd64.deb 34859fa99bf40d85687e46fed8b1e5153ffad16c 8273220 libsbuild-doc_1.6.1-1_all.deb fb0a638d154ce0a8c000ebc610bb003ad5a5f9d5 969738 schroot_1.6.1-1_amd64.deb 17125ae4b23696e64686ca585ee0b79514e72186 374772 dchroot_1.6.1-1_amd64.deb 890007f10b771fe2df7f68a4f086be7b1b0822e2 374288 dchroot-dsa_1.6.1-1_amd64.deb Checksums-Sha256: cb6be6071ee8977f2be6c311b361dec1a4dad915b22278a79b2150bb60a16345 2424 schroot_1.6.1-1.dsc 0e48478833a004d06d3e6a1eb91196c0377eacbc74289dc354ee36e0c3d64902 730472 schroot_1.6.1.orig.tar.xz 9b6df3f63fc0fdbf01d66b202876fdda2ab8afcd57990b164c070be754ea6fd1 29225 schroot_1.6.1-1.debian.tar.gz 587cf960e25bcd2c45449403de1088018766795c3654c994e21892510d1d8048 263694 schroot-common_1.6.1-1_all.deb 55fac2d6b52884b3324f26e593f4911d893ae1b6644ef6ed9dacc1f8b9960fc1 2296548 libsbuild-dev_1.6.1-1_amd64.deb 1d1f64881dc747d9ad2343aef24a2031e6ff4f395e1ca0e69cdc4a0c52b59d27 29217038 schroot-dbg_1.6.1-1_amd64.deb db5e1962db72fa119df7e6a76b9594671e7992f4491a022e0829593c0f31a1c1 8273220 libsbuild-doc_1.6.1-1_all.deb a917942165f19aa18ed08248055d0c0ecc2d56c8a85dca6dc224d6378863202b 969738 schroot_1.6.1-1_amd64.deb 196b5ba9f14e75bfe80a3ffbaa4c03acf0469147077bc9cf7bcf63a951e78d61 374772 dchroot_1.6.1-1_amd64.deb 36057b4c3be7d0210ed6bafc109fdd9ee6336b1620976aee562d390a9f74983f 374288 dchroot-dsa_1.6.1-1_amd64.deb Files: 0cbb795221dd5e8be5174283c2ce43f7 2424 admin optional schroot_1.6.1-1.dsc 059daf59f3d9b564d0c0ed0cf5a7a625 730472 admin optional schroot_1.6.1.orig.tar.xz 1a237eb9bcb7d8a32cd7aa6ebf2f2b8d 29225 admin optional schroot_1.6.1-1.debian.tar.gz cd0bb0dc8812fe9e4a94ce771742e4e3 263694 admin optional schroot-common_1.6.1-1_all.deb be8b507ec6da5cfe1d0187d32c971cf1 2296548 libdevel optional libsbuild-dev_1.6.1-1_amd64.deb 5e0cc618fe5812356471ccaaef8564a1 29217038 debug extra schroot-dbg_1.6.1-1_amd64.deb 418b1be892ac223677551920bc4c4518 8273220 doc optional libsbuild-doc_1.6.1-1_all.deb 0ef686e26be9d9e68202d76c6ff7a5a8 969738 admin optional schroot_1.6.1-1_amd64.deb b44340ad56992a7cf92e1c939c68db51 374772 admin optional dchroot_1.6.1-1_amd64.deb d00f862de19c3f698b8979a9c0d28a19 374288 admin optional dchroot-dsa_1.6.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQBzFKAAoJEOJSSsUKn1xZbPgP+wRENfZ5OxMR+nM8SzpDjUJC o+sde/iDtz9iTKEtCVV7FwTEBBVrlAMvidxBOeE+m93HLyNmjlXe6L+0qRQt8VAS y3/Pq37b47I+kkmfHp/VdaJTTAeipUM8DJ+YKJA0L66n8qVTDrCAQIZLbEmO74Tp eib6unl3IeRldUB8kYK6jcXGYGh/H9kEB9KIHfIyeqoFEO97FrU/m7B9vbhZ9Zth cGANqIM5UBwc5J4I52k4R4q+BlW/dhZ4PYYQyL8ZmrIrFIF3O0ymojxbKSbN9Q7Z h9Q7HwXVlzcaO1V7+EYDShyKla4W4EpLtWQaZkzjGpTWlfPrLPjAOjDoWY7WDFLd r0Clg0vnRv8oLrHei5e1RXqfo/Zl4kpPOUtHxDRmAArLSduks9QEs0bi4okaO+7G /yHSRvCega4Sd04OmsVK0VibZ3RW1N2yLfQoTKTpfS8aG4uP7ArGx+D56W0SxY3P jWCLVPs8sYGVZqk9HxEyCG6LD3nIXeMz3r5xVWu/8pHMLPTY
Accepted gutenprint 5.2.9-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 09 Jul 2012 23:16:31 +0100 Source: gutenprint Binary: gimp-gutenprint cups-driver-gutenprint printer-driver-gutenprint libgutenprint-dev libgutenprint-doc libgutenprint2 libgutenprintui2-dev libgutenprintui2-1 gutenprint-locales escputil ijsgutenprint foomatic-db-gutenprint gutenprint-doc Architecture: source amd64 all Version: 5.2.9-1 Distribution: unstable Urgency: low Maintainer: Debian Printing Group debian-print...@lists.debian.org Changed-By: Roger Leigh rle...@debian.org Description: cups-driver-gutenprint - transitional dummy package for gutenprint printer driver escputil - maintenance utility for Epson Stylus printers foomatic-db-gutenprint - OpenPrinting printer support - database for Gutenprint printer dr gimp-gutenprint - print plugin for the GIMP gutenprint-doc - users' guide for Gutenprint and CUPS gutenprint-locales - locale data files for Gutenprint ijsgutenprint - inkjet server - Ghostscript driver for Gutenprint libgutenprint-dev - development files for the Gutenprint printer driver library libgutenprint-doc - documentation for the Gutenprint printer driver library libgutenprint2 - runtime for the Gutenprint printer driver library libgutenprintui2-1 - runtime for the Gutenprint printer driver user interface library libgutenprintui2-dev - development files for the Gutenprint printer driver user interfac printer-driver-gutenprint - printer drivers for CUPS Changes: gutenprint (5.2.9-1) unstable; urgency=low . * New upstream stable release. * Drop patches against 5.2.8-1 to correct library versioning and linking, which have been incorporated upstream. Checksums-Sha1: 1b0870c4d24d814bae646ab1d1f9ecbc422dd140 2734 gutenprint_5.2.9-1.dsc ecfd3757c5f8ddc994e4e60f713f5b9561b8cf28 5720450 gutenprint_5.2.9.orig.tar.bz2 b09b27bdd21d2acb27ece1b3611b66259a6cf836 21481 gutenprint_5.2.9-1.debian.tar.gz 8c29eb8cae97156b8af7aa8b2e8d3dd1def3ff17 111720 gimp-gutenprint_5.2.9-1_amd64.deb ac2cb67877e7502be385f6dc44820033e0369c06 1288 cups-driver-gutenprint_5.2.9-1_all.deb a8a9294c524467d3187710f30abc2bfbb4dd45ce 421642 printer-driver-gutenprint_5.2.9-1_amd64.deb 53183b637e38813cb0e449e5f7bd30e472f08a4f 88106 libgutenprint-dev_5.2.9-1_amd64.deb 6244bf1c6f36a95957a7adb4bb5c111596590c41 430444 libgutenprint-doc_5.2.9-1_all.deb 976a95a80fb9998d7b004ee302377c32c734c596 1286548 libgutenprint2_5.2.9-1_amd64.deb 6adf6d0ee60a1ba9b1536b298c225d1ce615c871 42478 libgutenprintui2-dev_5.2.9-1_amd64.deb 2c1346d14ff298e6865616ad99fcb91a3f7655f2 141650 libgutenprintui2-1_5.2.9-1_amd64.deb 8de18a80eb95e4e2031431090ae52bfd3e6dea26 2237910 gutenprint-locales_5.2.9-1_all.deb 9bba83d3d3da0bb68712446f642c2c481195ae99 114408 escputil_5.2.9-1_amd64.deb 14566d90288c14505a585693f9dea148ec6f4dc2 58518 ijsgutenprint_5.2.9-1_amd64.deb 6baa78c33aed3b7f79a77ed0a6e3161d6e6a605c 6965060 foomatic-db-gutenprint_5.2.9-1_all.deb d49dfa81c9c8ac5b5443b8b105f74106533646d4 681410 gutenprint-doc_5.2.9-1_all.deb Checksums-Sha256: 28b9757be033492fcb60fb6b696c6738b7cb888f443a908ad86023650cd46843 2734 gutenprint_5.2.9-1.dsc 4b27e4f06f32d30271df89ecb6089bb11bcf2caec5f60b0909e083095354bca0 5720450 gutenprint_5.2.9.orig.tar.bz2 b20b04a93499454ac3ba7a38ec7f66d7b482305d6ba1549276a8b862def2d4d9 21481 gutenprint_5.2.9-1.debian.tar.gz 6ff1dfccf52b018d2e7f20106f442e05b5afe19d342cf92c5fd8ab09501d1337 111720 gimp-gutenprint_5.2.9-1_amd64.deb 208d9f24e5009edf0889fe201e0bc33ee7c64c588bcd0216297043c33ec0896a 1288 cups-driver-gutenprint_5.2.9-1_all.deb 5f3762121749c19db31a96db904db107d767bb4b04de93131a3fea3d9a6cdba0 421642 printer-driver-gutenprint_5.2.9-1_amd64.deb fbe7d65f9ba9c03291ca894205cbdbc06ada047a12ef0061f36cd043c2e4ca8c 88106 libgutenprint-dev_5.2.9-1_amd64.deb 0fd59864e61b189e327b1dcacb186c9d6adb8a4c3371a0b0baee73da7c7c69aa 430444 libgutenprint-doc_5.2.9-1_all.deb 2455cfa0a6f006058ff64c655fee5502f7da472c2e0348df0f4d09aba1dcdd67 1286548 libgutenprint2_5.2.9-1_amd64.deb 833fc5c4e4ccdee5b48a99de50ca64b7132e0182c39babf8b7c80d21140e3f08 42478 libgutenprintui2-dev_5.2.9-1_amd64.deb 9526a2f3321776a43ddf64f1a3db42be173b338a9d096dfbe73c94eeb870fb8e 141650 libgutenprintui2-1_5.2.9-1_amd64.deb b75085701cba25a5a91536c8b76c419659bf96e9c3456bd999e801cce22da35f 2237910 gutenprint-locales_5.2.9-1_all.deb 6010f0db03700a50dd1311523df9ff197413cdbddf2e1843dbc7358e114fe76d 114408 escputil_5.2.9-1_amd64.deb 11619bb5e5e623c4ca7065e3c4c1314fa00f069882165587bd1460712774a5f0 58518 ijsgutenprint_5.2.9-1_amd64.deb d2f790ee5de1fea40ad2290b05f8d2d5b451b3897661cd8064ccb8bce8bb6a25 6965060 foomatic-db-gutenprint_5.2.9-1_all.deb 5a229910c4999be7a4bf043be4ab80acb1d02359536cb8cc579e878ca6921e4a 681410 gutenprint-doc_5.2.9-1_all.deb Files: a6f23d6477a4c325c365df6f1b2fb718 2734 graphics optional gutenprint_5.2.9-1.dsc aefbec27b96dd404d9ac9811e17d58ce 5720450 graphics optional gutenprint_5.2.9.orig.tar.bz2
Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 10:58:09PM +0200, Michael Biebl wrote: On 27.06.2012 11:13, Roger Leigh wrote: I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used error out in dh_install or update-rc.d? dh_install initially, since it only breaks builds rather than upgrades. Maybe even for wheezy+1. I'll see about adding a lintian check before that point though. update-rc.d could just warn for wheezy+1, but won't actually use the options for anything (start and stop can just be synonymous with defaults), which will allow old scripts to continue working. And additionally, to add lintian warnings for use of these options, including when using dh_installinit. All in all, sounds reasonable. Please go ahead with this. It is seriously annoying making up random sequence numbers just to please dh_install/update-rc.d. I've added insserv support to file-rc this weekend, which was the only thing still using the sequence numbers. I'd like to get this in wheezy, even though it's after the freeze, since it means there will be zero users of the numbers in the wheezy-wheezy+1 upgrade, which will allow us to disable them immediately after the release of wheezy. (#539591) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120701232244.gy9...@codelibre.net
Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 06:39:57PM +0200, Stephan Seitz wrote: On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Well, I’m using file-rc on all my systems for many years. - „vi /etc/runlevel.conf” is easier than working with strange symlinks; - if I don’t want a service to start, I can replace „2,3,4,5” with „-”; - third-party software without Debian package doesn’t use update-rc.d; getting it to start is easier if I only have to edit one file (runlevel.conf); No one messes with symlinks. We have update-rc.d for that for both sysv-rc and file-rc. For sysv-rc, insserv manages them for you, and in theory we could even get rid of them entirely and have the dependencies computed at runtime. We'd just need a mechanism for recording which scripts were disabled. When you edit runlevel.conf, you have to maintain the script ordering, by hand, using the sequence number field. This is (or is becoming) utterly broken, and is why we have dependency based booting nowadays. The numbers are computed automatically by insserv; this is far less error prone and much more flexible. I have never used dependency based booting. - old systems had to many old init scripts without LSB headers, so the upgrade failed; - some software needs a database, but the database server may not be the same server, so the software can’t have a dependency on the database server; so I have to overwrite the dependency configuration in some way; - third-party software doesn’t have any LSB headers; IIRC the upgrade to dependency based booting doesn’t fail anymore if you have initscripts without LSB headers (they are now running at the end of the boot process), but for now I still don’t see any reason to change. Given that it's been the default for quite a few years now, you really should try it. The sequence numbers are going away, so if there are problems with it that you need fixing, then they need indentifying and reporting. Editing the LSB headers in the scripts to do stuff like not depend on a local server is not exactly rocket science. And we have Should-Start rather than Required-Start for exactly this situation--if you found a buggy LSB dependency, for goodness sake report it and get it fixed, rather than perpetuating the awful static sequence numbers. Dependency based boot works, and works well. There is no reason to continue to use file-rc. [I spent the weekend adding insserv support to file-rc. But the consequence of computing the sequence numbers automatically is that it no longer makes sense to edit runlevel.conf by hand--adding or removing an init script could recompute the sequence numbers of many scripts. runlevel.conf is essentially just marking scripts as enabled if present, disabled if absent.] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120701233720.gz9...@codelibre.net
Re: locking system users on package removal
On Sat, Jun 30, 2012 at 02:12:45PM +0100, Simon McVittie wrote: On 30/06/12 13:24, Stephan Springl wrote (on Bug #679642): quake-server does neither install nor purge properly on systems without shadow password because usermod gives an error for its e option in this case. I took this use of usermod from the discussion on debian-devel regarding Policy bug #621833 (where it was originally suggested by Roger Leigh), so this potentially affects quite a few packages. Stephan's proposed patch (below) makes me think we really need a script (or dpkg-maintscript-helper subcommand) that locks and unlocks system users, in which we can make changes like this once and have them affect every relevant package, rather than individually patching every maintainer script. Roger: does the change below look appropriate? [in the preinst] -usermod -U -e '' quake-server +if [ -f /etc/shadow ]; then + usermod -U -e '' quake-server +else + usermod -U quake-server +fi [in the postrm] # Lock account on purge -usermod -L -e 1 quake-server +if [ -f /etc/shadow ]; then +usermod -L -e 1 quake-server +else +usermod -L quake-server +fi It looks sane to me. Having a dh_ command or some other dpkg maintscript helper shell function to do this automatically would IMO be a very nice improvement. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120630133647.gl9...@codelibre.net
Re: Improving our response to duplicate packages in Debian
On Fri, Jun 29, 2012 at 12:55:15AM -0600, Holger Levsen wrote: On Donnerstag, 28. Juni 2012, Ben Finney wrote: It's part of the job of a (prospective) package maintainer to advocate for the package. what??? I don't see anything unreasonable about being able to articulate the reasons why a package should be part of Debian. I don't mean having to suffer a drawn out argument, but just being able to give the reasons why it's important for the software to be in Debian, what it does, and why it's sufficiently different from what we already have. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120629084930.gb9...@codelibre.net
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
tags 539591 + patch thanks On Thu, Jun 28, 2012 at 02:40:18PM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 08:02:33AM +0200, Alexander Wirt wrote: On Wed, 27 Jun 2012, Roger Leigh wrote: On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. Nope, there is an experimental patch for insserv to print out sequence numbers, to get this working I first have to build my own insserv. And the whole file-rc part is - beside of some ideas in my mind - missing. So the insserv patch is already present, it just needs enabling. So 10 mins tops to download and rebuild. I never saw a followup in the bug above--does the output format suit your needs? If it does, please say so. It could potentially be enabled and uploaded today or tomorrow. The patch works just fine. I retested it this evening. Short example: % insserv -s | egrep '(postgresql|cron|procps|sudo)$' K:02:0 1 6:postgresql K:01:0 1 6:anacron S:02:2 3 4 5:postgresql S:02:2 3 4 5:anacron S:02:2 3 4 5:cron S:01:2 3 4 5:sudo S:13:S:procps One you have the dependency info, can't you just query that in your update-rc.d implementation to override the defaults provided to update-rd.d? Does it require anything more complex than that? The following patch implements this behaviour. While the insserv parsing logic has been tested, it's not been tested for upgrades or whether the whole script works correctly. - it needs a Depends on insserv (= $version_with_-s) == this needs your feedback so it can be uploaded. - the preinst could be simplified to just use update-rc.d $script -f defaults if this is sufficient to update the sequence numbers in the configuration. This probably needs running in the postinst TBH. - this just replaces the defaults and user-provided start and stop arguments with those provided by insserv. Other than that, there are no changes to anything else. - You might need to retain support for the old-style logic so that if other scripts call update-rc.d in the gap between unpacking and running the postinst, it won't fail. Just back out the deletions and run those blocks only if insserv didn't run or didn't find any matches, which are a trivial addition to the script. While this patch is just a proof a concept, this should be pretty much all you need. It just needs checking and testing by someone with file-rc expertise. If this could be done in the very near future, then that would be great. Please do provide some feedback on whether insserv -s is sufficient for your needs. Thanks, Roger diff -urN file-rc-0.8.12.original/debian/changelog file-rc-0.8.13/debian/changelog --- file-rc-0.8.12.original/debian/changelog2010-04-07 20:30:54.0 +0100 +++ file-rc-0.8.13/debian/changelog 2012-06-29 20:00:01.917474582 +0100 @@ -1,3 +1,10 @@ +file-rc (0.8.13) UNRELEASED; urgency=low + + * Use insserv for runlevel defaults rather than the arguments +provided to update-rc.d. + + -- Roger Leigh rle...@debian.org Fri, 29 Jun 2012 19:59:06 +0100 + file-rc (0.8.12) unstable; urgency=low * New maintainer (Closes: #539609) diff -urN file-rc-0.8.12.original/debian/preinst file-rc-0.8.13/debian/preinst --- file-rc-0.8.12.original/debian/preinst 2010-04-07 20:30:54.0 +0100 +++ file-rc-0.8.13/debian/preinst 2012-06-29 20:06:18.739474331 +0100 @@ -14,6 +14,8 @@ # for details, see http://www.debian.org/doc/debian-policy/ or # the debian-policy package +# Make sure insserv is in path +PATH=/sbin:$PATH case $1 in install) @@ -64,6 +66,19 @@ dpkg-divert --package file-rc --remove \ --divert /etc/init.d/rcS.links /etc/init.d/rcS fi + + if [ $2 != ] dpkg --compare-versions $2 lt 0.8.13 + then + for script in /etc/init.d/* + do + if [ -x $script ] + then + script=$(basename $script
Re: Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. You say the numbers are going to bitrot, which I totaly agree. But that could be prevented. The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120628095223.gs9...@codelibre.net
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 08:02:33AM +0200, Alexander Wirt wrote: On Wed, 27 Jun 2012, Roger Leigh wrote: On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. Nope, there is an experimental patch for insserv to print out sequence numbers, to get this working I first have to build my own insserv. And the whole file-rc part is - beside of some ideas in my mind - missing. So the insserv patch is already present, it just needs enabling. So 10 mins tops to download and rebuild. I never saw a followup in the bug above--does the output format suit your needs? If it does, please say so. It could potentially be enabled and uploaded today or tomorrow. One you have the dependency info, can't you just query that in your update-rc.d implementation to override the defaults provided to update-rd.d? Does it require anything more complex than that? Example: If you are invoked with update-rc.d cron start 89 2 3 4 5 . then you run insserv -s | grep ':cron$' == K:01:0 1 6:cron S:04:2 3 4 5:cron So you just treat that as equivalent to update-rc.d cron start 04 2 3 4 5 . stop 01 0 1 6 . and AFAICS you're done. i.e. you're just getting the runlevel info from insserv, rather than from the command-line options. Should be quite straightforward. So its unlikely to get this working unless insserv (for the patch) and file-rc get a freeze exception. I'm sure we can ask for one. If it's not done for wheezy, that will cause problems in removing sequence numbers in wheezy+1, since upgrades will then cause breakage for file-rc users (either because they are bitrotted, or because they are no longer present). I would prefer that this not drag out over *three* stable releases--since this has been really needed since before squeeze, and no action has been taken to date in file-rc. It's really not in our users' interest to have file-rc using increasingly buggy sequence numbers. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120628134018.gw9...@codelibre.net
Re: Dependency-based boot ordering and sysvinit in unstable
severity 678231 serious severity 676473 serious forgemerge 676463 678231 676473 tags 676463 + pending thanks On Thu, Jun 07, 2012 at 09:31:47PM +0100, Roger Leigh wrote: Hi, If you're using unstable and you're using static boot ordering with sysv-rc, you might have run into #676463/#676520. We've been using dynamic dependency-based boot ordering by default for quite some time now. However, if you had a lenny (or earlier) system, prior to sysv-rc 2.88dsf-23, users had a choice between opting to remain using the old static legacy boot ordering, or to enable dynamic dependency-based boot ordering. In 2.88dsf-23, the question is removed, and dynamic boot ordering will be enabled on all systems. For the majority of users, this won't cause any problems at all. However, if you have any lingering scripts without any LSB headers, you'll need to fix them up or remove them to allow dynamic boot ordering to be enabled. This is obviously not too desirable, since it requires fixing things up by hand. But it doesn't break anything either (other than requiring you to fix things to continue--the boot ordering will be unaffected until the migration can proceed). Ideally, we would be able to skip the sanity checks and just enable it anyway, with the non-LSB scripts getting ordered after all the LSB scripts. This should satisfy the (absent) dependencies in all but the most insane of cases. But this does require testing carefully, which is why it's not done at the present time. The packages at http://people.debian.org/~rleigh/sysvinit/ remove all the old sanity checks and permit insserv to run when scripts without LSB headers are present. The scripts get ordered at the end of $all. i.e. they are run after all scripts with LSB headers, but before rc.local and other scripts that require $all to be run before them. This should be safe to do in all cases, with the exception being any custom scripts which are ordered in a specific place in the runlevel. These will now most likely get run later than previously. However, running after all system-provided services are started will usually be the correct thing to do. This will only cause problems if the script must start strictly before a particular service starts. In this situation, you'll need to add an LSB header describing the specific dependencies. I'd be grateful for any testing and feedback of the above prerelease packages before they get uploaded to unstable. Unless there are any major objections to this change, I'd like to upload this later in the week. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627073852.gh9...@codelibre.net
Future of update-rc.d in wheezy+1
Hi folks, I'd just like to briefly discuss potential plans for update-rc.d in wheezy+1, and how this might impact on file-rc and sysv-rc. sysv-rc has defaulted to using LSB header dependencies and insserv for a few years now. The last few releases require you to enable insserv to upgrade, and the pending upload just does this automatically. The result is that all wheezy users of sysv-rc will be using dependency-based boot. This means that the runlevels and sequence numbers passed as arguments to update-rc.d will never be used; they will just get silently discarded. The main problem as I see it is that these numbers are going to bitrot badly--they aren't being tested, while the dependency information in the header is being used by everyone. I'd like to suggest that we do the following in sysv-rc update-rc.d: - wheezy: silently drop start|stop sequence numbers and runlevels (this is already the case when using insserv, and we can remove the non-insserv codepaths) - wheezy+1: warn if these options are used - wheezy+2: remove support for the options and error out if used And additionally, to add lintian warnings for use of these options, including when using dh_installinit. The main problem that I can see is file-rc is currently still dependent upon the sequence numbers and runlevel information. Would it be possible for file-rc to also add support for dependencies? Given that the static boot ordering is quite dead at this point, it would be very helpful to know what's possible here. Could it use insserv to do the dependency graph and then just consume the makefile-style dependency list? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627091329.gj9...@codelibre.net
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: On 06/27/2012 03:46 PM, Alexander Wirt wrote: On Wed, 27 Jun 2012, Paul Wise wrote: On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: Yes. See URL: http://bugs.debian.org/539591 , URL: http://bugs.debian.org/573004 and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. Hmm, no upload in those two years either. Is file-rc still maintained at all? It is. But more or less in no-new-features mode. Implementing the insserv stuff is wishlist for me. Even when I now get forced into it. I don't think there's any question of forcing, but encouraging file-rc to retain compatibility with the init scripts being used by the distribution. It looks like the patches are there, they just need testing. If file-rc could have this in place for wheezy, that would be highly desirable, so that we can work on deprecating runlevel sequence numbers in wheezy+1. So might be this could avoided if we switch to something more modern like openrc as discussed some weeks ago here - I think the main reason file-rc edxists is because its much more easy to maintain than all the other crap^Winit systems (including insserv) floating around. The openrc runscript format is certainly a bit nicer than the LSB header, but at the same time has some disadvantages. With the LSB header/insserv setup, we can read all the headers and have a dependency graph for all the scripts. But when you run a script by hand, or with invoke-rc.d, it can't satisfy dependencies at that point--it's only at the level of /etc/init.d/rc for runlevel changes. OpenRC OTOH has no global view but can resolve dependencies iteratively when running a script directly. Having both would be nice, which is what systemd/upstart give us. I'm still following OpenRC stuff, though I've not had time to get involved directly yet. The main point preventing us adopting it is lack of support for LSB dependencies, which would make upgrades rather painful. We could possibly address this by autogeneration of runscript wrappers for LSB scripts. Ideally, I'd like for OpenRC to gain a high level dependency graph view of the system, but it doesn't look like this is a design that would be particularly popular with OpenRC upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627215404.gn9...@codelibre.net
Accepted gutenprint 5.2.8-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 21 Jun 2012 23:31:35 +0100 Source: gutenprint Binary: gimp-gutenprint cups-driver-gutenprint printer-driver-gutenprint libgutenprint-dev libgutenprint-doc libgutenprint2 libgutenprintui2-dev libgutenprintui2-1 gutenprint-locales escputil ijsgutenprint foomatic-db-gutenprint gutenprint-doc Architecture: source amd64 all Version: 5.2.8-1 Distribution: unstable Urgency: low Maintainer: Debian Printing Group debian-print...@lists.debian.org Changed-By: Roger Leigh rle...@debian.org Description: cups-driver-gutenprint - transitional dummy package for gutenprint printer driver escputil - maintenance utility for Epson Stylus printers foomatic-db-gutenprint - OpenPrinting printer support - database for Gutenprint printer dr gimp-gutenprint - print plugin for the GIMP gutenprint-doc - users' guide for Gutenprint and CUPS gutenprint-locales - locale data files for Gutenprint ijsgutenprint - inkjet server - Ghostscript driver for Gutenprint libgutenprint-dev - development files for the Gutenprint printer driver library libgutenprint-doc - documentation for the Gutenprint printer driver library libgutenprint2 - runtime for the Gutenprint printer driver library libgutenprintui2-1 - runtime for the Gutenprint printer driver user interface library libgutenprintui2-dev - development files for the Gutenprint printer driver user interfac printer-driver-gutenprint - printer drivers for CUPS Changes: gutenprint (5.2.8-1) unstable; urgency=low . * New upstream stable release. * debian/README.building: Document git workflow. * debian/control: - Upgrade Standards-Version to 3.9.3 - Require debhelper = 9. * debian/rules: - Re-enable NLS with --enable-nls. * printer-driver-gutenprint no longer installs profile.jpg. * Re-enable NLS with --enable-nls. Checksums-Sha1: 25ac1198ae853d081dc4b8d83f17890a3b233ee9 2734 gutenprint_5.2.8-1.dsc 5948919a0077d411b89669cd45a280a7f6f90186 5691472 gutenprint_5.2.8.orig.tar.bz2 983cb608598f100d91da448e94961978054624e1 91355 gutenprint_5.2.8-1.debian.tar.gz 3a3a9b41c56f996e14b59c508b2b7249d9a8a000 111404 gimp-gutenprint_5.2.8-1_amd64.deb 3f922af184ec83c20849c787c0239c50108a64a5 1294 cups-driver-gutenprint_5.2.8-1_all.deb a152c809f4f7a158314eec31fa79f3b148a7f1c4 421370 printer-driver-gutenprint_5.2.8-1_amd64.deb 373111496349e36dd52377f0519a6f9faafb7a50 87812 libgutenprint-dev_5.2.8-1_amd64.deb 68892b7f166d426912fa503c3138fcecb967b92c 430268 libgutenprint-doc_5.2.8-1_all.deb 1b326b79dc252ba85a1b204b78c71d189f72614c 1286304 libgutenprint2_5.2.8-1_amd64.deb fb086d0005c20dc1651e17545ab96bdcd34fac38 42204 libgutenprintui2-dev_5.2.8-1_amd64.deb 783d84cf6e242d42ee547f6adfa9981b06927911 141372 libgutenprintui2-1_5.2.8-1_amd64.deb 807f805764b16e6f7ee0ba65168c1c05d580d30d 2214296 gutenprint-locales_5.2.8-1_all.deb 756b0db8608a886ec34bd810a1546fc515db1546 114086 escputil_5.2.8-1_amd64.deb c529d182701c852213071e9ea52de71cb7d6407c 58218 ijsgutenprint_5.2.8-1_amd64.deb 11090c74c3b8523ca47721638db7d2fc35f44bb2 6964776 foomatic-db-gutenprint_5.2.8-1_all.deb 26a0344f91d46ad9e460cdebe9a636ffc673c6bc 681128 gutenprint-doc_5.2.8-1_all.deb Checksums-Sha256: c8e1ccf5c332bb0bdfa53eb8b3fab0dee6ccf1918f9fce8e726c652aa92586f0 2734 gutenprint_5.2.8-1.dsc 8cb9d2b4dda2d33b221f21c8e1453aead5e37966a194c5a473735d12cdc1c8e0 5691472 gutenprint_5.2.8.orig.tar.bz2 fb7f857ba4a7a214fe3f38a8aae1054e49b96e49c3d4fceca92bfb05b94aaab2 91355 gutenprint_5.2.8-1.debian.tar.gz 47acc79267beb064476da993fa8a0011a02cce527f80cba10e5ae7f35ba28f70 111404 gimp-gutenprint_5.2.8-1_amd64.deb 6af898d4f71ba0b16001ca788a49c18700b82e1527c4149b7cf232de2e6b2f22 1294 cups-driver-gutenprint_5.2.8-1_all.deb 64c4e26e83a63789e40660aacea161d195e2e85bffee4577c07f97c635715217 421370 printer-driver-gutenprint_5.2.8-1_amd64.deb e0a0110f3d5081c45ac4a289386703306ac0d33658597d1de0325600c8edf30e 87812 libgutenprint-dev_5.2.8-1_amd64.deb 64f7b72b5eb98558fd6f9231620207153d324abdda2424f9a3f79909df96d3ae 430268 libgutenprint-doc_5.2.8-1_all.deb 4a8e353dce4da21317a7465e625bc7a7d22b66f51fac138bb00333bd943cd5a1 1286304 libgutenprint2_5.2.8-1_amd64.deb 0bb948dc66023a5923578f4021d7d9f0c1599b88f63a060b06ee401449930252 42204 libgutenprintui2-dev_5.2.8-1_amd64.deb 4817dcf68761ae41dc6d05a3df93bf57496bc3a085fb2e5fd99fa5016086c2f5 141372 libgutenprintui2-1_5.2.8-1_amd64.deb 428ae7ae5eddf4e5726d6d6de5225f8b917ccab3e5a69669da0c66a293cc92a7 2214296 gutenprint-locales_5.2.8-1_all.deb 988ce1e1de0c3752779a0c29a297dc1a276b25e3d6314510939dac8548f89218 114086 escputil_5.2.8-1_amd64.deb e381a7f15358b722ec4cbaa03b3d5d844277ece3d21394543323507dc6e9cd69 58218 ijsgutenprint_5.2.8-1_amd64.deb 6a5c7c68370d1a9dfb4d4fdf00ed8102aacaec4cb390618b6c5c1782035c9e96 6964776 foomatic-db-gutenprint_5.2.8-1_all.deb 32082a8f1532d8363d8a11a9b4ae8c3b34ab61b728b08f274f0c7b494f8aae4f 681128 gutenprint-doc_5.2.8-1_all.deb Files
Accepted sysvinit 2.88dsf-28 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 27 Jun 2012 23:00:45 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-28 Distribution: unstable Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 625463 637390 668650 669162 671124 674178 676463 676473 676721 676725 676773 676791 676814 676893 676910 677011 677333 677590 677753 677904 678231 678627 678680 678878 Changes: sysvinit (2.88dsf-28) unstable; urgency=low . [ Steve Langasek ] * debian/patches/upstart_support.patch: add missing startpar-upstart-inject manpage. . [ Roger Leigh ] * Updated debconf translations: - ca. Thanks to Innocent De Marchi. Closes: #677904. - cs. Thanks to Miroslav Kure. Closes: #678680. - da. Thanks to Joe Hansen. Closes: #676893. - de. Thanks to Chris Leick. Closes: #677753. - fr. Thanks to Steve Petruzzello. Closes: #677590. - gl. Thanks to Jorge Barreiro. Closes: #678627. - nl. Thanks to Jeroen Schot. Closes: #677333. - pl. Thanks to Michał Kułach. Closes: #676773. - pt. Thanks to Miguel Figueiredo. Closes: #676814. - ru. Thanks to Yuri Kozlov. Closes: #677011. - sk. Thanks to Slavko. Closes: #676721. - sv. Thanks to Martin Bagge. Closes: #676791. - zh_CN. Thanks to YunQiang Su. Closes: #676725. * Add missing hardening CPPFLAGS. Thanks to Simon Ruderich. Closes: #678878. * Update clean run to cope with nonexistent startpar. * initscripts: - Only run update-rc.d in maintainer scripts when the init script exists and is executable. Closes: #671124. - Break initramfs-tools ( 0.104), needed to prevent initrd generation failure since older initramfs-tools can't cope with /etc/mtab being a symlink. Closes: #668650. - Don't mount with -o nodev on kFreeBSD. Closes: #669162. - Set up /run correctly in a chroot when running debootstrap. Thanks to Serge Hallyn. initscripts.postinst: if /dev is not a separate partition and we're in a chroot, then create /run/shm and make /dev/shm a symbolic link to it, as we would expect to find in a upgraded and rebooted running system. LP: #974584. Closes: #674178. * sysvinit: - rc and startpar distinguish between LSB not installed and not configured failure conditions. Thanks to Nate Coraor. Closes: #625463. * sysv-rc: - Dependency-based booting is activated unconditionally. Scripts without LSB headers will generally be ordered after all other scripts, but before scripts requiring $all to be started, such as rc.local, but this is not guaranteed. Add an LSB header if you need to guarantee the ordering of scripts. Closes: #676463, #678231, #676473. - update-rc.d uses absolute path to insserv, to give better error messages to non-root users where /sbin is not in the PATH. Thanks to Regid Ichira. Closes: #637390. . [ Paul Menzel ] * Fix usage message in /etc/init.d/motd. Closes: #676910. Checksums-Sha1: b90ffc046fdd512c62ae19bb13850dcb1b2305c6 2342 sysvinit_2.88dsf-28.dsc 397f16184177bb8ca2db88e3de87b04e987022a0 205903 sysvinit_2.88dsf-28.debian.tar.gz 27b81490b1fbd8f899c9818f5f44c5d81e29283d 131442 sysvinit_2.88dsf-28_amd64.deb 9a74176af84fa97f07f0957132683788ab7b3a66 97814 sysvinit-utils_2.88dsf-28_amd64.deb 49061a2b93a355f79428ec212c7f497312de353c 80418 sysv-rc_2.88dsf-28_all.deb 77265b02e98516839889cb74ca150c7e6471e6f5 89312 initscripts_2.88dsf-28_amd64.deb f460fafd46c02dd5d6ad0a6e520c569c82aaf729 53304 bootlogd_2.88dsf-28_amd64.deb Checksums-Sha256: f57f4a48810ddd6936d5f5a0103e31cd7da0bcb0a8b5389081989c8756794f34 2342 sysvinit_2.88dsf-28.dsc 65a153d8c34f8269e15daf5939b88f9c6981b24732483079a0e5de9b853a0e20 205903 sysvinit_2.88dsf-28.debian.tar.gz ad874ca195ab8393cf4493da449f924e50db4d23d6d60406a2748183debd24e2 131442 sysvinit_2.88dsf-28_amd64.deb a9ba29f675f1f58c6cc38afd14d44aa3321aa00c59a16b874fe42cb9e405fcad 97814 sysvinit-utils_2.88dsf-28_amd64.deb 38b392763e768c3473754588cda6de9619af11a7336efe4c80b306f4e82c90a9 80418 sysv-rc_2.88dsf-28_all.deb 2255a388dcdc27200db8a695073373fab542001c9572f995d65699e993b14f92 89312 initscripts_2.88dsf-28_amd64.deb bdf6b587696f5228ea72d1689ed118780cc0066f3cafff899e2bd51e37cef200 53304 bootlogd_2.88dsf-28_amd64.deb Files: f257dbabfb89713531294153c3ffbf6c 2342 admin required sysvinit_2.88dsf-28.dsc 7b276df5a09c2ada369281d1979299dd 205903 admin required sysvinit_2.88dsf-28
Re: File naming of scripts in /etc/init.d
On Mon, Jun 25, 2012 at 01:51:36PM +0200, Steve R. Petruzzello wrote: I noticed that some scripts in /etc/init.d/ are suffixed by .sh and some are not. [...] All except console-screen.sh, hwclock.sh and keymap.sh are from the initscripts package. So 1) nowhere is .sh suffixing mentioned and 2) some scripts are not named by their package's name (hwclock.sh is part of the util-linux package). Is there a reason for this? Nowadays, it's essentially the case that - scripts with a .sh suffix are run from rcS - they are not intended to be run by hand and/or after boot, or else they can screw up the system state Would it be purely aesthetics to clean out these script names? Yes, though the above distinction about them being run from rcS would be lost. And given the history, and the fact that other scripts depend on them (the names are used in the inter-script dependencies), renaming them is do-able, but not something we should be doing this close to the freeze. PS: Is there a way to list all packages putting a file in /etc/init.d/? dpkg -S $(ls -1 /etc/init.d/*) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120625134758.gp9...@codelibre.net
Re: File naming of scripts in /etc/init.d
On Mon, Jun 25, 2012 at 03:59:30PM +0200, Steve R. Petruzzello wrote: Le 25-06-2012, à 14:47:58 +0100, Roger Leigh (rle...@codelibre.net) a écrit : On Mon, Jun 25, 2012 at 01:51:36PM +0200, Steve R. Petruzzello wrote: I noticed that some scripts in /etc/init.d/ are suffixed by .sh and some are not. [...] All except console-screen.sh, hwclock.sh and keymap.sh are from the initscripts package. So 1) nowhere is .sh suffixing mentioned and 2) some scripts are not named by their package's name (hwclock.sh is part of the util-linux package). Is there a reason for this? Nowadays, it's essentially the case that - scripts with a .sh suffix are run from rcS But not all scripts in /etc/rcS.d/ have a .sh suffix (for instance S09mdadm-raid). No, it's not a strict rule, just historic practice. If we were to do it over today, it's unlikely we would use the suffixed names. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120625142102.gq9...@codelibre.net
Accepted schroot 1.6.0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 24 Jun 2012 20:18:30 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.6.0-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Closes: 675398 675408 676380 676413 676416 676813 677501 Changes: schroot (1.6.0-1) unstable; urgency=low . * New upstream stable release. * schroot: - Ensure that the schroot init script is migrated from using rcS to using standard runlevels (Closes: #677501). - script-config sets FSTAB, COPYFILES and NSSDATABASES, plus the new names prefixed with SETUP_ (Closes: #675408). The old script-config and new profile keys are mutually exclusive. If both are set, script-config will be used. If the script-config file is not present, create default settings for FSTAB, COPYFILES and NSSDATABASES for backward compatibility, needed since the standard config files are removed on upgrade. Note that in 1.5.x releases, profile was set in all cases, which set setup.fstab etc. but this is now no longer the case, to permit script-config files to continue to function if present. script-config will be removed in 1.7.x/1.8.x, so it is advisable to replace usage of script-config with profile. * Updated translations: - da (Closes: #675398). Thanks to Joe Hansen. - de (Closes: #676380). Thanks to Holger Wansing. - fr (Closes: #676413, #676416). Thanks to Thomas Blein. - pt (Closes: #676813). Thanks to Pedro Ribeiro. Checksums-Sha1: 325596d158920ca197b0cc10016a7227331bb403 2424 schroot_1.6.0-1.dsc c2b0b67a61be552e448cc58c48c06f097492600d 728860 schroot_1.6.0.orig.tar.xz ff74809b0b01c121d92f6378f9179c14e9a6af93 28310 schroot_1.6.0-1.debian.tar.gz ca8908aa738eae6988124e7c168ba38dff817931 262880 schroot-common_1.6.0-1_all.deb dfec32803162793329d43e113440ab65a62e62ce 2295660 libsbuild-dev_1.6.0-1_amd64.deb a6d6c466ebaa20efcdc44904a28fac63fc5e69c8 29218038 schroot-dbg_1.6.0-1_amd64.deb ba59234e14aebeb3d53d1b8028f3a76915cbdccf 8261498 libsbuild-doc_1.6.0-1_all.deb c667554f0285f32723cc5b297a94f5c2fdcb267f 969086 schroot_1.6.0-1_amd64.deb 443b986fa745c97bfc8fde6c0537a849b74f22f6 374614 dchroot_1.6.0-1_amd64.deb 4611b3721638b4dea555206392976ce4aadec3fe 374120 dchroot-dsa_1.6.0-1_amd64.deb Checksums-Sha256: f5d439910532f1761090d5a1926dc8934b949a9fdc5a48d5343394b811e9336a 2424 schroot_1.6.0-1.dsc afc1cff95bf296631756a91bd0092d984b0dbb0386fcb71d8a852aef244a 728860 schroot_1.6.0.orig.tar.xz e5fc84b35940d06a7a1d4bcecd7d2f884a1faa9a87d335edae4646aae7428001 28310 schroot_1.6.0-1.debian.tar.gz 2d7cb2bf04dcd86253f9eb18b248b1a99325dee3ad27872f47e3c0a564e1da46 262880 schroot-common_1.6.0-1_all.deb 63503b8848e9f90ac2234faf10fa0fa97de501eda6fd46c44d6d5430d887e843 2295660 libsbuild-dev_1.6.0-1_amd64.deb 301f2cbedcb206da177feb929e5d1b0eae81aa0501ee1f2a3d310449e7bda56a 29218038 schroot-dbg_1.6.0-1_amd64.deb 721d9af1e656c04b6f8182ed9a5a63a673a02411559a13c1dfb7eeb3e6dbc182 8261498 libsbuild-doc_1.6.0-1_all.deb ccd02b6198b5ede70c5b46fb85f34fc991c246c50d140db3d699bbbd45f98e5c 969086 schroot_1.6.0-1_amd64.deb 1d01677ad7a4b112d71b22e15471c5ddf5c13cf73ec07c1e2be4abf181d65000 374614 dchroot_1.6.0-1_amd64.deb aec3cc27e509ea85376613ff92c8ee25bfa0de27c3874d6fa2fedf86ba92e6b2 374120 dchroot-dsa_1.6.0-1_amd64.deb Files: 6568872c347e970de938777eba62098c 2424 admin optional schroot_1.6.0-1.dsc 9b0a12077dbb0e3e384b4c9af0dc3195 728860 admin optional schroot_1.6.0.orig.tar.xz 60c7e5b2d66ed91095aef027b4276605 28310 admin optional schroot_1.6.0-1.debian.tar.gz 7896d9fe6490fa7375f80b77430b 262880 admin optional schroot-common_1.6.0-1_all.deb a3531f907a231a23149b4ea87e765906 2295660 libdevel optional libsbuild-dev_1.6.0-1_amd64.deb d5ce2d99c3cf8370fc634eb293dc5462 29218038 debug extra schroot-dbg_1.6.0-1_amd64.deb 276a63955c2bea193fbea102bdeb751a 8261498 doc optional libsbuild-doc_1.6.0-1_all.deb 6518155e1cf9c804f9fd7dcbf07c4830 969086 admin optional schroot_1.6.0-1_amd64.deb 919de4ace432ab90be69e1deddaee7fe 374614 admin optional dchroot_1.6.0-1_amd64.deb 116784c2deda58984c6a6b621f5d38de 374120 admin optional dchroot-dsa_1.6.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJP6PQRAAoJEOJSSsUKn1xZkJkP
Re: The future (or non-future) of ia32-libs
On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote: On 06/22/2012 05:34 PM, Goswin von Brederlow wrote: Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back Step 2: dpkg --add-architecture i386 apt-get update Step 3: dist-upgrade (ia32-libs, wine, ... is now installable) May I suggest that upon upgrade, we have a debconf message telling about it? We could add this in base-files or any essential package, probably one with some debconf messages already in would be a better pick. Instructions would show, IF ia32-libs old version is currently installed AND the --add-architecture i386 hasn't bee done. I know we have release notes, but some don't know about them or would simply not read them. A debconf message seem really appropriate IMO. Could we not introduce the concept of an upgrade script into apt-get which could be downloaded when you run apt-get update and then run during a dist-upgrade? This could handle automation of any housekeeping during the upgrade which would otherwise require manual work detailed in the release notes. For example, if the ia32-libs package is installed, this could automatically update dpkg and apt-get, then automatically add the architecture and update prior to continuing with the upgrade. It could also handle any additional work which needs doing before and after the upgrade of the whole distribution, or any particular package. i.e. handling any work which the package maintainer scripts can't safely or sensibly handle. Doesn't the Ubuntu updater tool do something like this already when it does a full upgrade between releases? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120622143137.gf9...@codelibre.net
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On Sun, Jun 17, 2012 at 01:39:05PM +0200, Goswin von Brederlow wrote: I think that the sources-subvars target must function without any Build-Depends-(Indep) installed because otherwise: Just as an aside, we now have Build-Depends-Arch in addition to Build-Depends-Indep. This means that Build-Depends can be restricted to the common subset needed for packing sources but not those needed for arch-all or arch-any building. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120618121014.ge30...@codelibre.net
Accepted sysvinit 2.88dsf-27 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 08 Jun 2012 22:29:04 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-27 Distribution: unstable Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 676669 Changes: sysvinit (2.88dsf-27) unstable; urgency=low . [ Salvatore Bonaccorso ] * Remove reference to /usr/share/initscripts/default.rcS. With commit d0388ba464e69b1b7915a3d9071cfcba21d0102c /etc/default/rcS was made a regular conffile. Remove reference to original location with default values. . [ Roger Leigh ] * initscripts: - Don't fail in the absence of /proc/meminfo. The ram_size and swap_size functions in /lib/init/tmpfs.sh always return true. Closes: #676669. Checksums-Sha1: b73ba52d8e070ae0d4686430846139d0f073ab85 2342 sysvinit_2.88dsf-27.dsc 1276b69dd0ccb5a7fa4b7aa0f262c30c71a4fa34 202330 sysvinit_2.88dsf-27.debian.tar.gz 8d84399bbb81201348d6e22a666eb02b8a61a78b 130200 sysvinit_2.88dsf-27_amd64.deb caa05dda4cc76c47b67dea3125aa0eba6538feae 96222 sysvinit-utils_2.88dsf-27_amd64.deb 06e46e7813f76c3b9d9425198f0ab020705b864d 75186 sysv-rc_2.88dsf-27_all.deb 669559606b71862594f54f2adb8a1d5fb0b2c6d7 87900 initscripts_2.88dsf-27_amd64.deb c6cee9a8084b5d2a93e9979e3d75802e46421dfa 52326 bootlogd_2.88dsf-27_amd64.deb Checksums-Sha256: e03b0e8bed455ebf28c85c348b6bf49bbd2f5768d8d5540ed008620c94e7 2342 sysvinit_2.88dsf-27.dsc 71b602380805d2fe638df0c890a1d0ec589ec6d6fba6272b714e281c1259d813 202330 sysvinit_2.88dsf-27.debian.tar.gz 5869e07f589b6b46af72ac4ed13110cbf01b3f4dab6aa3ed0842f24e1d33fdba 130200 sysvinit_2.88dsf-27_amd64.deb a39bfa5141243a9b62b359f960aad23926e4c7b87c7f9e1405ae73c17d93f73f 96222 sysvinit-utils_2.88dsf-27_amd64.deb f2822d6a2344986fa8da5efa74f56434ef4913012f6c684323839afecff56adf 75186 sysv-rc_2.88dsf-27_all.deb b3d25ab906ec5e3587be6bdbbf4ab095b0b7d4ae4db711a6bd153175df963da9 87900 initscripts_2.88dsf-27_amd64.deb 73e1af24c19bba45e7df79cc704084e91eb1bf162da723455e6a6b08ebee66d3 52326 bootlogd_2.88dsf-27_amd64.deb Files: 1e38c1ee98c2a88ba2569252d7a7e485 2342 admin required sysvinit_2.88dsf-27.dsc 7541cb18b33f11fcadd971e8e83c9066 202330 admin required sysvinit_2.88dsf-27.debian.tar.gz 935a68e66a385bf724f3a78010294a65 130200 admin required sysvinit_2.88dsf-27_amd64.deb b47e57bb9866afa5c5b3eb962ba05f91 96222 admin required sysvinit-utils_2.88dsf-27_amd64.deb b9348cb09c2da780b3546c2a1d215cbf 75186 admin required sysv-rc_2.88dsf-27_all.deb 27d22e1e5c6b55417b12ee93e0321f6d 87900 admin required initscripts_2.88dsf-27_amd64.deb f2cd739c0fac5271ab4848c297bb2c54 52326 admin optional bootlogd_2.88dsf-27_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJP0nS0AAoJEOJSSsUKn1xZbAUP/1HuIrnrg6eRc67Me5HH0250 ODBBxrHQ6Hsh+YuL7lALWWp6G0zGk4NRdqr2/gsklAAZzPM+D66Z5PVYOe47huZJ ero2VheQ5En5XZlTRw13V7DdSlQIVpos5O7HCGzMW2Ld3PoaZg4a7PlqWCJGokXp pluAXKYDHWEpouQNEn1mMv0Ee9gsysbOmNPM5fsebj9Xb74BbxL+jvFodpeQovpn 8R7fDwNq7bkr5CGI4/Pf4V+/72jwYvhvEd1rT+lMaqOFUOaQNvFZfSRExZnZTIWp yqEhVUCGyqpAcqlveq/mmFxOph4rmUsHj9PBus3Bjl8b9hQ4w1dZCM+8i52BunZt vOev0HY1gAiBuehEpCRtzFlP2KgOsKIyvUJr663Ub7gAl7Az3MeH+ReMP565xZFL SL8loTVnvaeIgZpbOK7V1/8lii9X6TAIq4bMIXI0gQ8dOgAlXGFYOj5hnzzdNfvB vXZQ4jb81+030LAnnY77HrRuv+mX1+spIbHuH9em2+2v5jU1WeXiR4CZf7A5OyzF YoYDpKe+h2temM28ahEP6s7EQWu1HM8CNmxFoLSgXf5gyJ6j/Xn+jOC1EPNgRMly zMa/CHx3h9h6Pdbx/Yhb69/lo8o+ufma6hNImlvBKmuQo4O/qFKIm9JM+CdVmBMm xNDcqFI9zvu6l7wGJBjj =Us96 -END PGP SIGNATURE- Accepted: bootlogd_2.88dsf-27_amd64.deb to main/s/sysvinit/bootlogd_2.88dsf-27_amd64.deb initscripts_2.88dsf-27_amd64.deb to main/s/sysvinit/initscripts_2.88dsf-27_amd64.deb sysv-rc_2.88dsf-27_all.deb to main/s/sysvinit/sysv-rc_2.88dsf-27_all.deb sysvinit-utils_2.88dsf-27_amd64.deb to main/s/sysvinit/sysvinit-utils_2.88dsf-27_amd64.deb sysvinit_2.88dsf-27.debian.tar.gz to main/s/sysvinit/sysvinit_2.88dsf-27.debian.tar.gz sysvinit_2.88dsf-27.dsc to main/s/sysvinit/sysvinit_2.88dsf-27.dsc sysvinit_2.88dsf-27_amd64.deb to main/s/sysvinit/sysvinit_2.88dsf-27_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sd7nq-0007aj...@franck.debian.org
Incorrect use of /run
Apologies for using -announce, but it's become apparent that there are some packages mis-using /run, and this will break squeeze to wheezy upgrades, and it's clear that some maintainers are not aware of this. mysql-5.5 is the package I'm aware of, but there may be others, and this needs fixing or else you'll break things. If you want to use /run, you must read http://wiki.debian.org/ReleaseGoals/RunDirectory first. If you're using /var/run, please continue to use /var/run. This path is not going away, and it's the correct path to use. You only *need* to use /run if you start before /var is mounted. Otherwise, ignore the fact that they are the same location, it's just an implementation detail. /run does not exist in squeeze. It's created by initscripts on upgrade. This means *it does not exist until initscripts is configured*. You can not use /run *at all* until initscripts is configured. Therefore if you do use it, you need a versioned Depends on initscripts in your package. This is all detailed in the reference above. If your package is using /run and lacks a versioned dependency, you'll need to either 1) Switch back to using /var/run (preferred) 2) Add a versioned initscripts dependency You'll also potentially need to sort of the breakage, if possible or safe. In all cases, your package must not provide or create the /run directory, or any files or directories under /run. All of these will cause breakage. This requirement will be relaxed in wheezy+1, where /run will exist at all times. But until then, you need to follow the instructions in the reference above. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Dependency-based boot ordering and sysvinit in unstable
Hi, If you're using unstable and you're using static boot ordering with sysv-rc, you might have run into #676463/#676520. We've been using dynamic dependency-based boot ordering by default for quite some time now. However, if you had a lenny (or earlier) system, prior to sysv-rc 2.88dsf-23, users had a choice between opting to remain using the old static legacy boot ordering, or to enable dynamic dependency-based boot ordering. In 2.88dsf-23, the question is removed, and dynamic boot ordering will be enabled on all systems. For the majority of users, this won't cause any problems at all. However, if you have any lingering scripts without any LSB headers, you'll need to fix them up or remove them to allow dynamic boot ordering to be enabled. This is obviously not too desirable, since it requires fixing things up by hand. But it doesn't break anything either (other than requiring you to fix things to continue--the boot ordering will be unaffected until the migration can proceed). Ideally, we would be able to skip the sanity checks and just enable it anyway, with the non-LSB scripts getting ordered after all the LSB scripts. This should satisfy the (absent) dependencies in all but the most insane of cases. But this does require testing carefully, which is why it's not done at the present time [it wasn't supposed to leave experimental until this was done, but the competing demands of fixing /tmp and other things such as upstart integration meant that it did, so apologies for that]. I'm away for the next 10 days, but I will be looking into this as soon as I get back. In the meantime, if anyone would like to test the safety of removing the sanity check, that would be very useful. The reason for making this change is that packages provide both LSB dependency information, and they also have to separately provide static ordering information when running update-rc.d. However, now the vast majority of systems use dynamic ordering, the static ordering is bitrotting. It's not tested properly, and it will only get worse. Rather than let the quality of the static ordering decline until it results in inevitable breakage, requiring all systems to use dynamic ordering means that all systems will be using the same, sane LSB dependencies, making booting rather more robust, and removing the requirement for maintainers to invent some fictional static order, which isn't being tested by them to ensure it's correct in any case. All the other init systems use dependency-based ordering, and this additionally makes migration to other init systems easier given their use of LSB dependencies for compatibility. The only exception is perhaps file-rc, and this should probably be using insserv to order the scripts even if it doesn't use startpar to run them in parallel, so that it can use LSB dependency ordering as well. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120607203147.gn15...@codelibre.net
Accepted sysvinit 2.88dsf-26 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 28 May 2012 17:58:38 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-26 Distribution: unstable Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 386368 630615 665635 98 674208 674460 674517 Changes: sysvinit (2.88dsf-26) unstable; urgency=low . [ Roger Leigh ] * initscripts: - /run/shm is mounted noexec. Closes: #386368. - The RAMSHM and RAMTMP settings in /etc/default/rcS are used if present, though the replacement settings in /etc/default/tmpfs will override these, if enabled. - Revert RAMTMP setting to be disabled by default. Closes: #630615, #665635, #98, #674517. - Don't prompt the user on upgrade if rcS was not modified by the admin. Closes: #674460. * sysvinit-utils: - Fix typo in fstab-decode(8). Thanks to Bjarni Ingi Gislason. Closes: #674208. Checksums-Sha1: 3c82521046fe0bc28aa23f0d4a34271bad6f9a53 2342 sysvinit_2.88dsf-26.dsc 2652be7e905b67b5a6e8da86a794b98a1a1f0738 201474 sysvinit_2.88dsf-26.debian.tar.gz d29edc85b963aaefc4a6171cbfb084ee7ab34723 130062 sysvinit_2.88dsf-26_amd64.deb 61670601d0b467d078578a4b944077767e6f3c18 96020 sysvinit-utils_2.88dsf-26_amd64.deb 81de4371959b1339c1aead437d34d3bcea182567 74976 sysv-rc_2.88dsf-26_all.deb 3932b1b997387d7c28a283125ea19c2cca629b31 87720 initscripts_2.88dsf-26_amd64.deb be47b5a4e7b12b52e34fb1df9fbc62e2f6822e39 52116 bootlogd_2.88dsf-26_amd64.deb Checksums-Sha256: ee6385d301943c4aeb35b037a46ab8c9792707deadcdd32c4274e80389409d87 2342 sysvinit_2.88dsf-26.dsc 86cc67267ad0d76143aabd10084e93d95c6d4ee4de5fc3d49f073695ca0b9d87 201474 sysvinit_2.88dsf-26.debian.tar.gz 13863704c20c519c768e74501d7410122b4bdd8197822710a381a4f8caebd0e6 130062 sysvinit_2.88dsf-26_amd64.deb 1ca84a97924e87200cbe4a99dc5a655ea14ff732a1722b516f47bb5873833b0b 96020 sysvinit-utils_2.88dsf-26_amd64.deb 7034a86747cc2eefa0a4ea6879371f5f5219a58584489bbc555f6907bae362a6 74976 sysv-rc_2.88dsf-26_all.deb ea9ca8dab36bd61a1d61049c291e87ad9696d2426e60d03afeab209abde4ce5a 87720 initscripts_2.88dsf-26_amd64.deb 2300e379d3ee055625a78ddd5e574ae713b86a577689addf0181dccf0bf4a71f 52116 bootlogd_2.88dsf-26_amd64.deb Files: 60ec6cbc959ca118e00cffbaef5861e3 2342 admin required sysvinit_2.88dsf-26.dsc 1cf2ebc37120e3d4e7d50fb80588355d 201474 admin required sysvinit_2.88dsf-26.debian.tar.gz bea6e21164dc526215269394552362ae 130062 admin required sysvinit_2.88dsf-26_amd64.deb 3312dc77c0cadff02c69c1ce5c3c41fa 96020 admin required sysvinit-utils_2.88dsf-26_amd64.deb b4108cfe9f64c5021171bd56d1122db2 74976 admin required sysv-rc_2.88dsf-26_all.deb e284939ba57576e674d64c61507ac030 87720 admin required initscripts_2.88dsf-26_amd64.deb e4a725feb457c9d603df328007f1a56e 52116 admin optional bootlogd_2.88dsf-26_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPz9lVAAoJEOJSSsUKn1xZcTkQAItYpP6zhOhgHP9EERqjG2M0 uJ2wOJGyGz23tPaYah4jOt1On9ih30EXyoz/1Vk5e56UrBe1V14guw4Qg4nimf1u SfknjG4xzGf41kus4EpR8OzZXY9GQMtTGBDJsG75UaLZUXEw14bszaRlIZ/Acf6y x2Q2Sszg0HW5B5Hr32kywo2zlC494XD77y356IWG9VWAxccUY7F+kgKOcQT8wOwL 62TP6ItzH+2d1CpjlFW1RXNXBGyo2U5t8f/rdoSuWVgT0ANHKGoFhyDJ2w/vK656 vNW/JM9HWC+f6lr6HsY4th1B7ZMpImB13WVGIzFsrB+TcFADJ48ikTgOA2jnBlRo 91AYH3sxuBw+iqJMzZsHuZ3cL2Ua4Dwd+/o8o8JYHWpLuY0X5elXIeyZR88KseZx MYoyixJy1AgiWvre4gut4U5pHq+MUkV/9z3RywDL8S6IfvSnWhhNibeAqcv1ThDB Ey3YxyY5X3a75hhNtufW4avFWyr4Q+7EGQVQgD08QI0cYIDQN2gZwTUvH9RhXq6T 03h+PT008cwu9GY+2BIxpPWhKgz2jD3h0ke+bP9zXa8BRYDdWNfMHlk30PoUkpoX X+QNPl4gNbEINrniSL8WkE5Z4pL3qs+UKVn3oIx6FEC9LKi/ut932fgQtZXzfL+M kk9A39T0ujTHw2mUoXD/ =gNVP -END PGP SIGNATURE- Accepted: bootlogd_2.88dsf-26_amd64.deb to main/s/sysvinit/bootlogd_2.88dsf-26_amd64.deb initscripts_2.88dsf-26_amd64.deb to main/s/sysvinit/initscripts_2.88dsf-26_amd64.deb sysv-rc_2.88dsf-26_all.deb to main/s/sysvinit/sysv-rc_2.88dsf-26_all.deb sysvinit-utils_2.88dsf-26_amd64.deb to main/s/sysvinit/sysvinit-utils_2.88dsf-26_amd64.deb sysvinit_2.88dsf-26.debian.tar.gz to main/s/sysvinit/sysvinit_2.88dsf-26.debian.tar.gz sysvinit_2.88dsf-26.dsc to main/s/sysvinit/sysvinit_2.88dsf-26.dsc sysvinit_2.88dsf-26_amd64.deb to main/s/sysvinit/sysvinit_2.88dsf-26_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1scp1i-0008ei...@franck.debian.org
Re: Moving /tmp to tmpfs makes it useless
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote: On 05/28/2012 05:32 AM, Roger Leigh wrote: On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote: On 05/25/2012 07:44 PM, Roger Leigh wrote: However, the majority of software which finds the tmpfs too small has unreasonable expectations of what can be expected to be available (by default). We welcome you to rewrite / patch these software then! Good luck, the list is huge, and growing every day this thread is alive. (As an aside, could you possibly reduce the number of mails you're sending. You've sent at least 12 today, and most of them all said essentially the same thing.) I'll do that when people will stop ignoring arguments posted on the very first message of the thread, like the fact so many popular applications are writing big files to /tmp, and that it's simply unrealistic to believe we can fix them all before Wheezy. You seem to forget it once more in this post as well. Nothing in this thread has been ignored. Please don't make unwarranted assumptions. Stating the same thing in 20 different replies doesn't make it any more useful than stating it in one. I'm well aware of the issues involved and haven't forgotten anything. The primary cause of problems is simply that the tmpfs /tmp isn't big enough. Applications are creating files which use up all the space. I'd like us to consider the problem in terms of what guarantees are offered by the system in terms of minimum and maximum available space on /tmp. Consider the default: /tmp is on the rootfs, and there is a single filesystem (which might be very large or quite small, and may have lots of free space or very little). In this case, we offer no guarantees about the available space. Now in the typical case, we might well have tens, or even hundreds, of GiB available, which can be used by files under /tmp. But this is not guaranteed. There might be next to no free space. Now consider tmpfs mounted on /tmp: the size specifies the total available space. This is guaranteed to be available; it's both the minimum and maximum, so while it /might/ place a lower upper limit on size than a regular filesystem would, it also guarantees that this space will be available Unless I didn't understand how tmpfs work, you have no guarantee as well. Once your memory is eaten by apps, and your swap gets full, you are in the exact same situation as having your /tmp holding partition full, at the exception that your system becomes totally unusable and unstable. The defaults have been carefully (perhaps even too conservatively) chosen to prevent any problems with the system becoming unusable. And you are not correct here. The tmpfs defaults to guaranteeing a certain fixed size being available, as I stated above. If the memory was used up by applications and data, then the system will swap, drop cached data, flush unwritten data to disc etc. in order to make room for it. You are *guaranteed* to be able to use that space, and it does not cause problems (modulo the size limit being too small). The important point is that the space is absolutely guranteed to be available, which is something a regular filesystem does not, unless you dedicate a separate filesystem to /tmp. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120601123246.gn...@codelibre.net
Re: Moving /tmp to tmpfs makes it useless
On Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh wrote: On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote: I've read across different debates about whether using tmpfs is good or bad but I could not find the most important reason, so here it is... I haven't got anything particularly new to add to the discussion here. [This was also posted to LWN in part.] As mentioned in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674517 it was originally intended that this feature only be enabled for new installs, not on upgrade. As mentioned in this bug, some of that has been rectified already in git. We will also correct the configuration for users who got tmpfs enabled during upgrade, but this needs careful testing. The main issue for it being enabled on upgrades is that insufficient swap may be available to have a reasonable amount of space. This is also an issue for new installs--we do need some support in the installer for this as well. I'm certainly not averse to switching the default back, if this is the best solution at the present time for the majority of our users. As was seen in both this an earlier discussions, there is not a clear-cut consensus here--there are from what I can tell approximately equal numbers in the for and against camps. It's clear we can't satisfy everyone no matter which is picked as the default. As mentioned, the use of tmpfs really boils down to peoples expectations of what /tmp is /for/. The size of what may be stored isn't specified in any standard, so it's not fair to say that it's only usable for small files. But using a tmpfs does place a restriction of the size of the files which may be used. That said, allowing certain applications to store multi-GiB files on /tmp causes its own indirect problems in addition to the immediate: these programs are often broken on smaller systems due to not being able to cope with running out of space, and impose a requirement for vast amounts of temporary space. These programs are broken on systems with a smaller rootfs, irrespective of the tmpfs issue. Maybe we need to distinguish not on size, but on speed of access, and have /tmp for fast access and a separate location for slower disc-backed storage, which would be more suited to the storage of streaming media, ISO images etc. which are going to have a longer lifetime, and also tend to be larger. None of these uses benefit from being on a tmpfs in the general case. (I've used /scratch for this in the past, though currently it's a 1 TiB btrfs RAID1 under /srv/scratch.) Obviously out of scope for wheezy. The important part of what we've achieved for wheezy is having tmpfs filesystems mounted on /run (and optionally /run/lock and /run/shm). The tmpfs on /tmp uses the same infrastructure in our init scripts, and we mount tmpfs on /tmp in two special cases: if the rootfs is read-only and no /tmp mount exists in fstab, and if /tmp contains less than a certain amount of free space. This is one part of making it possible to run with a read-only rootfs out of the box, and also to aid recovery if booting when the rootfs is full, respectively. The default of whether we mount tmpfs on /tmp by default or not is really only a minor part of the other improvements we have in wheezy--it really doesn't matter which is the default, so long as it works. While I'm in favour of this being tmpfs, if there are too many programs which break which can't be fixed, then we'll have to switch back to using a regular filesystem. Maybe we'll then be able to reconsider it for wheezy+1. [As an ironic aside, when testing RAMTMP=no in rcS for backward compatibility for #674517, I ran out of space on /tmp and broke gcc/ld. On my system, there's only a few hundreds of MiB free on the rootfs; tmpfs is absolutely needed here!] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120601124026.go...@codelibre.net
Re: Moving /tmp to tmpfs makes it useless
20.10 21.24 20.45
12 19.92 21.09 20.45
13 19.89 21.00 20.47
14 20.04 21.11 20.55
15 20.36 21.42 20.43
16 20.27 21.09 20.53
17 20.28 20.98 20.69
18 20.02 21.05 20.52
19 20.21 21.08 20.67
20 20.12 21.02 20.54
sapply(sb, mean)
tmpfsext4 btrfs
20.0805 21.0810 20.5155
sapply(sb, semean)
tmpfs ext4 btrfs
0.03099639 0.02973479 0.02623251
3) Unpacking of a large zip file
#!/bin/sh
set -e
for pass in $(seq 1 5); do
sh -c rm -rf lsm; unzip lsm.zip
done
for pass in $(seq 1 20); do
/usr/bin/time -f '%e' -a -o $1 \
sh -c rm -rf lsm; unzip lsm.zip
done
unzip
tmpfs ext4 btrfs
1 12.44 16.67 12.68
2 12.44 18.57 12.56
3 12.50 18.13 12.82
4 12.45 17.14 12.82
5 12.43 19.72 12.79
6 12.50 19.43 12.55
7 12.35 17.74 12.76
8 12.46 21.73 12.85
9 12.43 21.01 12.86
10 12.43 19.80 12.78
11 12.59 17.18 12.96
12 12.45 21.86 12.77
13 12.46 21.88 12.84
14 12.39 21.27 12.84
15 12.35 17.61 12.76
16 12.45 22.21 13.21
17 12.50 26.03 12.72
18 12.43 18.60 12.77
19 12.49 19.45 12.84
20 12.47 17.71 12.58
sapply(unzip, mean)
tmpfsext4 btrfs
12.4505 19.6870 12.7880
sapply(unzip, semean)
tmpfs ext4 btrfs
0.01199726 0.52173249 0.03233541
tmpfs 12.45 ± 0.01
ext4 19.69 ± 0.52
btrfs 12.79 ± 0.32
4) Unpacking of large uncompressed tarfile
#!/bin/sh
set -e
for pass in $(seq 1 5); do
sh -c rm -rf lsm; tar xf lsm.tar
done
for pass in $(seq 1 20); do
/usr/bin/time -f '%e' -a -o $1 \
sh -c rm -rf lsm; tar xf lsm.tar
done
tar
tmpfs ext4 btrfs
1 1.16 18.61 4.81
2 1.16 17.87 5.73
3 1.17 17.36 5.05
4 1.15 17.97 5.51
5 1.16 16.97 5.16
6 1.16 18.50 6.83
7 1.15 19.72 4.21
8 1.15 16.31 5.39
9 1.15 19.51 5.23
10 1.15 19.16 4.71
11 1.16 18.04 6.80
12 1.16 17.25 3.42
13 1.15 18.72 4.43
14 1.16 14.17 4.26
15 1.16 16.85 5.30
16 1.15 19.47 4.81
17 1.15 19.39 4.90
18 1.16 16.27 6.77
19 1.15 12.56 4.06
20 1.15 17.56 5.03
sapply(tar, mean)
tmpfsext4 btrfs
1.1555 17.6130 5.1205
sapply(tar, semean)
tmpfsext4 btrfs
0.001352386 0.405560755 0.202557951
semean
function(x) {
sd(x) / sqrt(length(x))
}
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
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/20120601215118.gq...@codelibre.net
Accepted sbuild 0.63.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 31 May 2012 21:59:16 +0100 Source: sbuild Binary: libsbuild-perl sbuild buildd Architecture: source all Version: 0.63.1-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: buildd - Daemon for automatically building Debian binary packages from Deb libsbuild-perl - Tool for building Debian binary packages from Debian sources sbuild - Tool for building Debian binary packages from Debian sources Closes: 675332 675349 675354 Changes: sbuild (0.63.1-1) unstable; urgency=low . [ Roger Leigh ] * New release * Don't require xapt. Remove duplicate and incorrect check. Thanks to Andres Mejia and Jakub Wilk (Closes: #675332, #675354). * Remove /etc/schroot/setup.d/99builddsourceslist which was provided with earlier versions of sbuild, but no longer works with current schroot versions (Closes: #675349). Checksums-Sha1: 7ec7cb32b7f1dab819c7911b699c1fcbb50e602b 2114 sbuild_0.63.1-1.dsc a4981253573b54677de7045c33c4aab7a5442d7f 540630 sbuild_0.63.1.orig.tar.gz a0fddd5458378c1bf3c10dd2f5c060d1347741ed 20 sbuild_0.63.1-1.diff.gz 0c9fee2aeffde3a40f29fdadce71215953281d2b 287222 libsbuild-perl_0.63.1-1_all.deb 222b562ffe15192a1c41a45737afd7411a167c10 302112 sbuild_0.63.1-1_all.deb 43fae93b39d2a9d8105858b2b74103a013311502 286226 buildd_0.63.1-1_all.deb Checksums-Sha256: e1f8b6fe1fa126f6d1c4df3dbc4aac8e125d82d16198f72de4daf8aaa29f3869 2114 sbuild_0.63.1-1.dsc 8f3380c2605abeb869a349dd9f711f66f5962197c2542629677ea5cdee21d7c1 540630 sbuild_0.63.1.orig.tar.gz f61f27bd17de546264aa58f40f3aafaac7021e0ef69c17f6b1b4cd7664a037ec 20 sbuild_0.63.1-1.diff.gz 3dfa4dd8bc484049ae60cb8b21e8cd187ad79f79ed41df1114dc969249bf211a 287222 libsbuild-perl_0.63.1-1_all.deb 6f05be1d68556a2cfb2128e0ca593079018dadd56e81c973db54782e05219af4 302112 sbuild_0.63.1-1_all.deb 7e7b3b848a73fb571f7b51f89068177cf9f7bcdca289162953ff7ec8d70ab679 286226 buildd_0.63.1-1_all.deb Files: 5169692959f134233682ff72f4786c2a 2114 devel extra sbuild_0.63.1-1.dsc 29a9e25b49f01aa638f444c9d63b54a2 540630 devel extra sbuild_0.63.1.orig.tar.gz 4a4dd3598707603b3f76a2378a4504aa 20 devel extra sbuild_0.63.1-1.diff.gz 68f84cb62956c03c1bfb3ebd0ac85318 287222 perl extra libsbuild-perl_0.63.1-1_all.deb ea9c5e7a144f646a5adad110f66ee9b1 302112 devel extra sbuild_0.63.1-1_all.deb a9af2b9b198984d58a5ddf934cfeb10f 286226 devel extra buildd_0.63.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPx+knAAoJEOJSSsUKn1xZtOgP/RqE2Ep8vgAXW6s1xtLQL0Pn 1L3zWwgQNuZra3eIgeLrT2Fq9a4n5xCKqdWOKx/IZMVb2E0L+7cWr0r0Tuymk6Fk XQCddv8upvFMIOqk9/DLWjeE32Pv99vcbxFJZw1ExuZsVxvFbX0+OdtkSM6Ph14k gCwnIqcSncfv900/ZvVqGlTa/72gsXWXkEYOdxTcLD8aKrsMFOGkw4QRsLDRVPe6 VEEYnJwCABaG/UkP66ZHweinO0VKa1LeyzvSDc1RsCm7O/UGIcsXGyanB53qNJ3t x9MDi/r/cXyif3MfeLoxqm1zzdf4p1vt9aTccj3MWjoZhwByAuR4HZ94ZWFUceb1 3qNGejA7gaFxcoCNuqCuInhd/sSTcwKzYY+tz/OEijAheVc/Lo+G26Tx7PZ1Wy8Q y8ERhldqYqDsOwdXjBBN6eZLoUG3GFjgsX4pMD3gOvVJfeDoBk2wmlV3jSosfvqf 7JgtueO/IAbKZ2kP8nUG05/5SaU90rc/h6cBdPFmSrqQv3HAUgjT0qAeVnXgTP0s b1fBOALbNpTX8rrD+S118LT7ayFXaJNl0seH6WnoVGIi0py+czRaveTyrEvRUW/U kji1hcH+wNMDFhaiNFCr97mFSIU4mWT2OqsFLo8a3uThTdxnENQzEVphNL6YjKEW hq0fr1d68fyNY/8It4oi =83Zk -END PGP SIGNATURE- Accepted: buildd_0.63.1-1_all.deb to main/s/sbuild/buildd_0.63.1-1_all.deb libsbuild-perl_0.63.1-1_all.deb to main/s/sbuild/libsbuild-perl_0.63.1-1_all.deb sbuild_0.63.1-1.diff.gz to main/s/sbuild/sbuild_0.63.1-1.diff.gz sbuild_0.63.1-1.dsc to main/s/sbuild/sbuild_0.63.1-1.dsc sbuild_0.63.1-1_all.deb to main/s/sbuild/sbuild_0.63.1-1_all.deb sbuild_0.63.1.orig.tar.gz to main/s/sbuild/sbuild_0.63.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sadt3-00019y...@franck.debian.org
Accepted schroot 1.5.4-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 29 May 2012 22:53:23 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.5.4-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Closes: 675189 Changes: schroot (1.5.4-1) unstable; urgency=low . * New upstream development release. * schroot: Correctly initialise the profile property (Closes: #675189). Checksums-Sha1: 6f3b56b442d9f8357bda3bf9c981ad87e61bfc74 2424 schroot_1.5.4-1.dsc cabc6542c6bbc27ae6eb9407f8c36a91d219b237 721520 schroot_1.5.4.orig.tar.xz d67002cd671241d1eb9a3b14c0cb6212132f1141 27989 schroot_1.5.4-1.debian.tar.gz b1915660d7813b3c204dd73c1ff68d5cfcfe01d3 255670 schroot-common_1.5.4-1_all.deb 105dc7b808d69ddaf083c7d8c25c7d8bbc1d5170 2293868 libsbuild-dev_1.5.4-1_amd64.deb d338a7ccbe8731f7f869fb098e4c97b699003bcb 29722390 schroot-dbg_1.5.4-1_amd64.deb a3e823eda7d8360dfce9f3d3bd9b57842de37f3a 8262558 libsbuild-doc_1.5.4-1_all.deb 3e29246a8f4862d9c3280f3bc540155480a0120e 958586 schroot_1.5.4-1_amd64.deb ac55e9141d6674961f7fe68fb90f32d9f5e3a675 372818 dchroot_1.5.4-1_amd64.deb 17a649857f58d755329306a8495b593d1b3d5f24 372274 dchroot-dsa_1.5.4-1_amd64.deb Checksums-Sha256: ba2a1e1c2b2a8f88fb18ad300a598132846d54e82ff494f71e6d5fcb6af7fe79 2424 schroot_1.5.4-1.dsc ac4e0ee9f08ae4eae35ee42c1e60a5b66191283809bb872150a4ef2a780f5b55 721520 schroot_1.5.4.orig.tar.xz 77c153b2288dfd93313185cb2bafc11f38cacedbc4e8da0d9ed677c1cd1bbd75 27989 schroot_1.5.4-1.debian.tar.gz 55595535e7d0a4e6261c6fd2e044803239381bed9625093f6689e8f12eb3530c 255670 schroot-common_1.5.4-1_all.deb 15cefee96a5965a4c81cf6d24d29a738646dfbdbd39a9302131e9f6422c3615d 2293868 libsbuild-dev_1.5.4-1_amd64.deb f3dd6bf7e104c36c448ffdc3282275ea04006583ece9d7173a43593521103a82 29722390 schroot-dbg_1.5.4-1_amd64.deb e8b70fa0480d9c9b371a7cb9779425bc3de3ab30cd7e241260d7ad6a1cbd9214 8262558 libsbuild-doc_1.5.4-1_all.deb 5ee4f03afb8d040b17d9c0e07693771e8c5377e119f58ed868fe854248a01551 958586 schroot_1.5.4-1_amd64.deb 0e9bf747cf004ad37294ca77a9eb23035f8aa18f96e56381923a1f973a6c6eba 372818 dchroot_1.5.4-1_amd64.deb b70154a04247ba3d9bc731353b6f3de9971f67b5a991243d92e605e596ee1c05 372274 dchroot-dsa_1.5.4-1_amd64.deb Files: e883191ca351b8f03326115ec5337b98 2424 admin optional schroot_1.5.4-1.dsc 8e3e01d68e6a67b5663fc6850d7172c1 721520 admin optional schroot_1.5.4.orig.tar.xz ac586bdedc8d627488ea6c21b7256446 27989 admin optional schroot_1.5.4-1.debian.tar.gz ed1c22c52532b90f61625990bf597b2c 255670 admin optional schroot-common_1.5.4-1_all.deb 8416967487a3c48bb550838309bec3ac 2293868 libdevel optional libsbuild-dev_1.5.4-1_amd64.deb db5a9eae84f1a026b92ab705877d4108 29722390 debug extra schroot-dbg_1.5.4-1_amd64.deb bbed8528005df4662bc3c7128a281836 8262558 doc optional libsbuild-doc_1.5.4-1_all.deb 85f96f83495f13e51bfc5c9f171bc14e 958586 admin optional schroot_1.5.4-1_amd64.deb c613f85c53ce95ce2d41a67e4431fdec 372818 admin optional dchroot_1.5.4-1_amd64.deb 6323efb30910c94ef159af7cc61c3a09 372274 admin optional dchroot-dsa_1.5.4-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPxo3iAAoJEOJSSsUKn1xZqsIQAIWxO2BpYP4WIpDfg8Cspze3 u1HHTE8IbNVhNAO92Vvdi7TAUKNUYuf09VGMw04QX2cBI5qYp7gu1uZZ6AwGLUUk iaT+vDedIzr/F4d5Lpz3fOexCBkfjWpyjHKKGolgI3Smt0mWbHtIbmw/yqN3F6Id j+QZObDoRdc2aRA1inTqsA0P/ML2XWcifI5Ep1MvDPeXWL1cWFczaLuofE8Vx6O/ PzTbbVbPPVG/tzXIooHudZq/tREqaisurL3hu16gmDGecvsgfE/yPVXgZIU6RVLW 8pNd/ZHeBWt5PzdSKYvyjqJe3/JBxyKis6Ep0dqyNNtlFUmx402736c6mMNbr399 hvJH3aCje4TPfVzNIxd1SFrLoZJCw1De+x0KtC825X3AMetNpal1rj8GkcuLRkRs fxSvfH70cW0Ww/irPjeTDL63uZFHWF2atGmc2UUtkzulliPaiILJ5TBAZ3K/UZO6 TYgfITnPoJ21hI/KK73Dz1alJzDrSTCIyAVopEn5jqDa1KqgRDwd8+a6N+UDwa3C cLAiYaR7VfM7DRspfJH96Ul4lScxPKYcNHyvUp5cp7JFhPiArrATuCr4objdQVni 9xLs1P3kUfLQbmfHrap6Ub9OIn6TYWLCo6ZLW4Vk0Q6drv9LnYScdJ1DpkdjDYfo ltTKMraEOjf2bGjhzcgd =HlNR -END PGP SIGNATURE- Accepted: dchroot-dsa_1.5.4-1_amd64.deb to main/s/schroot/dchroot-dsa_1.5.4-1_amd64.deb dchroot_1.5.4-1_amd64.deb to main/s/schroot/dchroot_1.5.4-1_amd64.deb libsbuild-dev_1.5.4-1_amd64.deb to main/s/schroot/libsbuild-dev_1.5.4-1_amd64.deb libsbuild-doc_1.5.4-1_all.deb to main/s/schroot/libsbuild-doc_1.5.4-1_all.deb schroot-common_1.5.4-1_all.deb to main/s/schroot/schroot-common_1.5.4-1_all.deb schroot-dbg_1.5.4-1_amd64
Accepted sbuild 0.63.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 30 May 2012 22:49:18 +0100 Source: sbuild Binary: libsbuild-perl sbuild buildd Architecture: source all Version: 0.63.0-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: buildd - Daemon for automatically building Debian binary packages from Deb libsbuild-perl - Tool for building Debian binary packages from Debian sources sbuild - Tool for building Debian binary packages from Debian sources Closes: 610689 622788 Changes: sbuild (0.63.0-1) unstable; urgency=low . [ Wookey ] * Support for cross-compiling has been added. This includes the addition of $host and $build configuration variables, with corresponding --host and --build command-line options. This includes the addition of a new 'xapt' dependency resolver. - Merge cross-build support (thanks to Hector Oron, Closes: #610689). - Add multiarch cross-build support. . [ Roger Leigh ] * The deprecated 'internal' dependency resolver has been removed, along with the configuration variables $apt_policy, $check_depends_algorithm and $resolve_virtual, and the command-line option --check-depends-algorithm. The 'apt' resolver is the default replacement for 'internal'. (Closes: #622788) * Support for watches has been removed. The configuration variables $check_watches, $ignore_watches_no_build_deps and $watches (and obsolete variables @ignore_watches_no_build_deps and %watches) have also been removed. * sbuild-stats and support for build time and space statistics recording has been removed. These statistics are recorded in both the build log and are available as build metadata internally. The statistics recorded in the database were not particularly informative; storing the statistics in a proper relational database is recommended. The configuration variables $avg_time_db and $avg_space_db have been removed. * Drop 25nssdatabases schroot setup script used on compatibility mode (on buildds). This has been replaced by the schroot 20nssdatabases for many years. Checksums-Sha1: d841b2b8f4fe5b0305ec37a036c719b6cd199e1c 2114 sbuild_0.63.0-1.dsc c3c8e8acb53a83218160cf45de60e21fc3d3624f 540501 sbuild_0.63.0.orig.tar.gz a0fddd5458378c1bf3c10dd2f5c060d1347741ed 20 sbuild_0.63.0-1.diff.gz 2bfe154d79ab0b77ed7903faa0dce68af12f9c44 286956 libsbuild-perl_0.63.0-1_all.deb e015b6fcd914a9f12a0dff760ba26e232460c3ec 301792 sbuild_0.63.0-1_all.deb 5447f18872b8880348b9179441141ee614f0f964 285918 buildd_0.63.0-1_all.deb Checksums-Sha256: d7c780814310c3f5528969a8967aa77dad9e2a7c5ba47df45aca496ec2340408 2114 sbuild_0.63.0-1.dsc b2c6fe02368a4f422a825a7200eab3ae2e4500708c7aa4264cbcf308a72e3282 540501 sbuild_0.63.0.orig.tar.gz f61f27bd17de546264aa58f40f3aafaac7021e0ef69c17f6b1b4cd7664a037ec 20 sbuild_0.63.0-1.diff.gz 29f463dabed9d307849fea1b04f2c44d10ab3d54919fbed2041f430f0680fc05 286956 libsbuild-perl_0.63.0-1_all.deb 648fbe7aef6bad751f775d6df83a96c10905b39610fee15f476502b979dad466 301792 sbuild_0.63.0-1_all.deb d87fdee85abb8d7800905a12323a2566689bef174e736a51aa914a618ea844ff 285918 buildd_0.63.0-1_all.deb Files: 80fb0f73cded3fc680b3639598efe5d7 2114 devel extra sbuild_0.63.0-1.dsc 6964c9922807747f54f55e0f0c29e406 540501 devel extra sbuild_0.63.0.orig.tar.gz 4a4dd3598707603b3f76a2378a4504aa 20 devel extra sbuild_0.63.0-1.diff.gz 7f7ea3d0735812bbecaff93ebc993bea 286956 perl extra libsbuild-perl_0.63.0-1_all.deb 22db0f293ef830cf851503a1f70d7abf 301792 devel extra sbuild_0.63.0-1_all.deb 0b7c42da0688fde86fd062fc32ebb9f4 285918 devel extra buildd_0.63.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPxqP3AAoJEOJSSsUKn1xZl6AQAMJWH5tBstMOSXngQuC1JSIP yvjpvv4FHu5/R2UH9ZMh5g8vnyLITsLRab8KIC0Q6cKjM/VRSDEPi/qzmXxieyCP nwQgFmfrcsfYM4QubqM23oYJB9FZabPC8X944vdx99vgk8UH3ijyB9s06MDs8DHX mooxXvGBVL4YJg5g9jUWtjNUGmY4biGdghxh9DhSIMMLermkaopPDQf11MdQW2D0 QtrB+qVzIx+gcIm9zMF0BeNRqTBzjHpmcHlBwiDzmkA0i+fY+TCtLoV4+MGwHIc3 YjAzaEQq/vn3huVV/syvFYtuI52nBhzDQVO+K5c+WV7VDnhKbm9FiIjerJxmplSI Ybur6YfAxs34hDbzAmLJhfVd9JN8RO40MjCOrg9gYcrgqNhlXUNaAWmc/lJ6sl6l LAzuaIQex8BqDmF4K01xF4g76psp7Qroc51/5RwU55jha6eYRN4XuSdrPx8E/pW8 IUixi0qEYv6LsAT3HpC/5BPZd4WqfLNpfLsaxRHF2rVxRAf56eVlELI2wRE7588p hvIF50bUCu5eOEcukbRps62PeysCaq7RSHuants/d94MH3OrPCqWDT+GbkHOayJi 1GmSxGezdaRV8SvG/8YIowsvwySCOpi+B52PjPNwcWcG3ZiXZh+oWNwjZCThy+k0 a1WfIMNzuAnuieqct/Ta =3/Dn -END PGP SIGNATURE- Accepted: buildd_0.63.0-1_all.deb to main/s/sbuild/buildd_0.63.0-1_all.deb libsbuild-perl_0.63.0-1_all.deb to main/s/sbuild/libsbuild-perl_0.63.0-1_all.deb sbuild_0.63.0-1.diff.gz to main/s/sbuild/sbuild_0.63.0-1.diff.gz sbuild_0.63.0-1.dsc to main/s/sbuild/sbuild_0.63.0-1.dsc sbuild_0.63.0-1_all.deb to main/s/sbuild
Accepted schroot 1.5.3-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 29 May 2012 21:26:47 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.5.3-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Closes: 604268 674040 674041 Changes: schroot (1.5.3-1) unstable; urgency=low . * New upstream development release. * dchroot: - Always use /bin/sh -c to run the specified command, rather than the user's shell, in order to ensure consistent behaviour. * schroot: - Add shell fallbacks (Closes: #674040). When running a login shell, try $SHELL (if preserving the environment), or else passwd pw_shell, then /bin/bash and finally /bin/sh. This may be overidden using the shell configuration key, which may in turn be overidden by the --shell option. - Don't warn the user about groups which do not exist (Closes: #674041). This is now debug log info only. - Add support for running programs in non-native architecture chroots using binfmt support for qemu user binaries (Closes: #604268). Thanks to Loïc Minier, Julian Andres Klode and Colin Watson. Checksums-Sha1: cf1d0e442d4a4c6fb3184a99a3178e10d3a8eb46 2424 schroot_1.5.3-1.dsc 1037078bfb3dc9563a37f51f573112c2c706aebf 721204 schroot_1.5.3.orig.tar.xz 0070ea91f10320a7bd48d58eedcc6629f2d627d7 27885 schroot_1.5.3-1.debian.tar.gz 6e0cbc2ff3d6d09be19ac735fabf651b6e30b013 255274 schroot-common_1.5.3-1_all.deb 3c93492dfffb03bd95c2368880b06ab4065a6bf8 2293348 libsbuild-dev_1.5.3-1_amd64.deb 8cf95553d18e527bfaf15562390a6068fcc8dd31 29722960 schroot-dbg_1.5.3-1_amd64.deb 63a05d8ca4710ce4119e70baaaf6710ab85a5b42 8257012 libsbuild-doc_1.5.3-1_all.deb 9e0bead60e12cdfa7ce1be597ca9c572bcb7fe25 958126 schroot_1.5.3-1_amd64.deb a4c1acce81ae091cf400f4f19308a6e19efe77cd 372800 dchroot_1.5.3-1_amd64.deb 1b84a9ec0b0c8f819d0e8d9e7a0f1e4ea3a41135 372236 dchroot-dsa_1.5.3-1_amd64.deb Checksums-Sha256: 4f2b9fd9ef53e22e2564165cdc47e844cd05cea8d78a16b5b93239a6dab79fdc 2424 schroot_1.5.3-1.dsc bdbc66c357d2a3ac14a1a2bfad1176b1ccfb3628c2b4607354ae3e26c03aafb1 721204 schroot_1.5.3.orig.tar.xz 84d41377e26efb468be74591619bed329d3cd0b6e0fb25ca383124e432158c99 27885 schroot_1.5.3-1.debian.tar.gz d6d4af344e790d9c6d5001a7413ad9f605130965a22b08a4a02317c3cb1efd6b 255274 schroot-common_1.5.3-1_all.deb 732035fdac3632fd246b2454be4731c14e7f720084edaddb4b0f6c6bbfa992d9 2293348 libsbuild-dev_1.5.3-1_amd64.deb df828605b618886a1b068f31112e58439bb3c8e7d39824b6d188044f711e0063 29722960 schroot-dbg_1.5.3-1_amd64.deb 48ea7339481244ff29633aa65a9febf548204b459cbdbb5acc811087df0fd370 8257012 libsbuild-doc_1.5.3-1_all.deb 8811200220414b765b1ed304037cc49dad101d30884509efef6f5a152ede4f25 958126 schroot_1.5.3-1_amd64.deb d5dae2107cf3d46fa5eff696ae409ad26a19d9ded33c1f478422d5fc4198adee 372800 dchroot_1.5.3-1_amd64.deb 0d677523baa5ede32d8bcfa65dfa6d9d5bb21fbbc5ff1d2f8a8cc1cb30da8a98 372236 dchroot-dsa_1.5.3-1_amd64.deb Files: 750d0afa6d08608146283a9739c07e2a 2424 admin optional schroot_1.5.3-1.dsc ef9ffb7c4fe25c074c9f3544ec14085a 721204 admin optional schroot_1.5.3.orig.tar.xz 7ce62eb64d478f04e8ddecea9c60b18c 27885 admin optional schroot_1.5.3-1.debian.tar.gz d479a9ec4db4e3230c4e99624b775f87 255274 admin optional schroot-common_1.5.3-1_all.deb 66ea444ae35d7ad5491f094f0db80174 2293348 libdevel optional libsbuild-dev_1.5.3-1_amd64.deb 23c813cf19fa552ad10c3755ac4b2f39 29722960 debug extra schroot-dbg_1.5.3-1_amd64.deb c12b4731ab392d460ece1e179ecbafc1 8257012 doc optional libsbuild-doc_1.5.3-1_all.deb ea12bd508948c58e4db32c6799b33254 958126 admin optional schroot_1.5.3-1_amd64.deb 8815d13362a861dd8259721368177e1d 372800 admin optional dchroot_1.5.3-1_amd64.deb 961271b58a3998ac832c4d09396d53f2 372236 admin optional dchroot-dsa_1.5.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPxUNxAAoJEOJSSsUKn1xZ5PUQAKyQo3gSbu2iW2eLC+8zjuoe IyeUFfzm+P2hKD6Od+6kCTi2fCgNIjOeeSbo0wiIQFTGVLq7l/JMjQlZky0KhnB4 84cGoHRflvLKsZrwR6LdFVmv87aO0LzHjwxOj4PVT8jNlNFkoPgahWIzca1MQIRg 0G3dVnG5sUW6yVkmptYi23SKtUaPPlaonpDHijWJAxpwhd3y/ijA7uxNKMvbNOod V6p571eL0Z+A9rEVdYH9I7dNtphyg4AJonIkqQDU9hzzOHGEOMGMJz+gUCxXBd7x D5vhxmpJwZ16bjLj48r7i0H84geyC9kN1C4zAIoZGA9ioUZpJRmxYbzbX2lx8z9X QWDV0NhskvvjydBlIrNy+h9yi4xFVzvR+zGUenKLLDwXLxGE
Re: Moving /tmp to tmpfs makes it useless
On Sat, May 26, 2012 at 04:39:34PM -0400, Joey Hess wrote: Roger Leigh wrote: I did want to have this for wheezy (#633299). But I lacked the time and familiarity with the d-i code, and the d-i developers also have higher priorities. Personally, this d-i developer has as one priority that the system d-i installs be broadly useful. d-i has at times needed to frob files in /etc to achieve this goal, and I have not ruled out the possibility that it might need to do so again... Note that the initscripts respect all the settings in /etc/fstab, and this includes noauto. While it would be possible to set the default size and enable/disable by editing /etc/default/tmpfs, it's also possible to configure the size by writing an fstab entry with the size limit, with or without noauto. Given the issues with the default size, and that we now use %VM, it would be nice if the installer could perhaps accommodate the use of tmpfs by automatically adding a certain size to the swap size calculation, and if needed adding this to the fstab entry. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120527200805.gt22...@codelibre.net
Re: Moving /tmp to tmpfs makes it useless
On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote: On 05/25/2012 07:44 PM, Roger Leigh wrote: However, the majority of software which finds the tmpfs too small has unreasonable expectations of what can be expected to be available (by default). We welcome you to rewrite / patch these software then! Good luck, the list is huge, and growing every day this thread is alive. (As an aside, could you possibly reduce the number of mails you're sending. You've sent at least 12 today, and most of them all said essentially the same thing.) Regarding space usage on /tmp, I think I mentioned this before, but I'm not sure it was on-list, so I'll reiterate it here. The primary cause of problems is simply that the tmpfs /tmp isn't big enough. Applications are creating files which use up all the space. I'd like us to consider the problem in terms of what guarantees are offered by the system in terms of minimum and maximum available space on /tmp. Consider the default: /tmp is on the rootfs, and there is a single filesystem (which might be very large or quite small, and may have lots of free space or very little). In this case, we offer no guarantees about the available space. Now in the typical case, we might well have tens, or even hundreds, of GiB available, which can be used by files under /tmp. But this is not guaranteed. There might be next to no free space. Now consider tmpfs mounted on /tmp: the size specifies the total available space. This is guaranteed to be available; it's both the minimum and maximum, so while it /might/ place a lower upper limit on size than a regular filesystem would, it also guarantees that this space will be available, which is a guarantee a regular filesystem does not offer (unless you have a dedicated filesystem for /tmp, which is getting outside the scope of this discussion). If the default size of the tmpfs is too small, we should decide what is a reasonable size, and ensure that the installer makes sure sufficient swap is available by default, or disables tmpfs on /tmp if this is not possible. My other comment is regarding software having reasonable expectations about the space they can use and, just as importantly, how they cope when those expectations are not met. In the example of streaming video using all the space on /tmp, the space used is approxiately proportional to the length of the video stream being downloaded. Looked at another way, the file is of completely arbitrary size, and the application should be able to deal with running out of space--resources are not finite, and failure should be expected given the indeterminism implicit in the downloading. Is /tmp even appropriate for this use? Another example was not having enough space when processing images. As mentioned by Neil Williams, it's important to tailor the software and hardware to requirements, and others mentioned issues with what happens when the tmpfs starts swapping. You obviously don't want to swap unless you absolutely have to. I process multi-GiB images using 8GiB RAM, 16GiB swap and a 6GiB tmpfs on /tmp. They get copied to /tmp, have multiple operations performed on the temporary copy, and get written back out. The performance is great--it's always working on in-memory data, with a single copy to/from a regular filesystem. But this was not a default configuration--it was deliberately configured for the job. This will always be needed to get optimal performance, whether you use a tmpfs or not. The system was tailored to meet the expectations of the image processing software. The best size for /tmp is of course the size which lets you store all your data without it getting full. However, when its size is essentially unlimited, there's a danger here. Software can assume that it can fill it without restriction, and not need to deal with space restrictions. While this isn't a problem on a desktop with vast amounts of disc space, it does mean the software is essentially imposing this requirement on *all* systems, including resource- constrained systems, or else it's basically broken. This is not a new problem--it's been an issue with mc as long as I remember. But that does not make it desirable. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120527213208.gu22...@codelibre.net
Re: Moving /tmp to tmpfs makes it useless
On Sun, May 27, 2012 at 10:01:22PM +0200, Tollef Fog Heen wrote: ]] Thomas Goirand Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much, then later applications can slowly use it if they want. Worst case: not a lot of app uses it, and the /run/tmp tmpfs isn't used much, which isn't a problem. Best case: everyone that needs a fast space has it and switches to it, and everyone is happy. How is this significantly different from /run/user/$user ? If it's not, we should just use that instead. /run/user is AFAICT not for user data, it's for session metadata for user services such as pidfiles, sockets and state. i.e. the user equivalent of /var/run. Its size should be only a few KiB at most. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120527213511.gv22...@codelibre.net
Re: Moving /tmp to tmpfs makes it useless
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote: I've read across different debates about whether using tmpfs is good or bad but I could not find the most important reason, so here it is... I haven't got anything particularly new to add to the discussion here. But I would like to refer you to the previous discussion on the topic. I am well aware that the default does not satisfy all use cases, but that's simply not possible for this problem. The best we can do is have a good default. That could be by improving the tmpfs default sizes and behaviour (my preferred solution). It could be by defaulting to not using a tmpfs. However, the majority of software which finds the tmpfs too small has unreasonable expectations of what can be expected to be available (by default). http://lists.debian.org/debian-devel/2011/04/msg00554.html http://lists.debian.org/debian-devel/2011/11/msg00281.html http://lists.debian.org/debian-devel/2012/02/msg00473.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630615 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630615#50 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630615#89 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665406 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674517 http://fedoraproject.org/w/index.php?title=Features/tmp-on-tmpfs Also see sysvinit in experimental. And the most important thing: file managers, browsers, image editors, cd burners — these are not some rare scientific stuff, but a common programs, that most people use every day. Putting them on a small tmpfs will break them. Is this because the tmpfs is too small, or because those applications are broken? Please see the discussion above first. Do not mount /tmp as tmpfs by default. Instead... Debian already allows custom partitioning during the system install. For example it's possible to mount /tmp on a separate partition. The suggestion is to extend partitioner with a new option Configure tmpfs partitions. That option should allow to mount anything as tmpfs (not just /tmp, but also /var/run, /media, /opt or whatever the user might want). It would be nice to have the `size` option there as well. I did want to have this for wheezy (#633299). But I lacked the time and familiarity with the d-i code, and the d-i developers also have higher priorities. I'm sure support for tmpfs in the partitioner would be welcome if you want to add this functionality. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120525114403.gm22...@codelibre.net
Accepted sysvinit 2.88dsf-25 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 22 May 2012 23:46:14 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-25 Distribution: experimental Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 674039 Changes: sysvinit (2.88dsf-25) experimental; urgency=low . [ Roger Leigh ] * Build with hardening flags enabled; CFLAGS and LDFLAGS are passed to all build commands. * initscripts: - /etc/default/rcS is no longer managed by ucf, and is a regular conffile. Drop the UTC setting, which has been migrated to /etc/adjtime by util-linux. Break util-linux 2.20.1-5 in order to ensure correct migration of the UTC setting before the file is upgraded. - Use ifquery in /etc/network/if-up.d/mountnfs to replace complex parsing. Also only run if inet or inet6 interfaces have been configured, to avoid freezing when the interface hasn't yet been configured (Closes: #674039). - %VM tmpfs size calculation works when swap is disabled. Checksums-Sha1: c8cb4c71a5b1a38cc1f2af360666d338b4ad2ef2 2342 sysvinit_2.88dsf-25.dsc 99f0edf43811c55a701da2f172ddc890f5a8db1b 199727 sysvinit_2.88dsf-25.debian.tar.gz 39568414df2f1a55cc8689ec7e54ba1a5dc3d38c 130694 sysvinit_2.88dsf-25_amd64.deb 880dd2093cab4ba4ffa67b27db245daeb1608e68 96246 sysvinit-utils_2.88dsf-25_amd64.deb 046a9df142fd4973611d350d194ed8ab605b49d7 74942 sysv-rc_2.88dsf-25_all.deb 645b5ea000ede4d99fee059ac55241f7dfb4eb51 85378 initscripts_2.88dsf-25_amd64.deb 9d9ed52018b7a2b0635a365a343fdf495390b8d7 51954 bootlogd_2.88dsf-25_amd64.deb Checksums-Sha256: 7287748bb81b14448725ed28a02265f1f95c29afc55a05cf9f5c77f941d87a01 2342 sysvinit_2.88dsf-25.dsc 71e03bcd8a9b989faf088d2e478f8672dc436ec4e09849a8f2bccaed5987ee0f 199727 sysvinit_2.88dsf-25.debian.tar.gz 3bd80348822c072f9323884ff3ac7c8253b477906a2775d5d02cad03df0065d7 130694 sysvinit_2.88dsf-25_amd64.deb db3c94ee83bb52c99388274de50bce7d557c220be40c20231938a53e6c3442e9 96246 sysvinit-utils_2.88dsf-25_amd64.deb 97199c28f40e703d42d4a122e71b265dcf3ab9460a841a691ea5f1358a4926b8 74942 sysv-rc_2.88dsf-25_all.deb d61432d1b083abc94d6d944bd355880c2edca93e4ce9baa49b196a9e4584 85378 initscripts_2.88dsf-25_amd64.deb e977ca46d22ec7a7c2b28d9a1bd4142588d6af78df732068fec78695e40ad2e8 51954 bootlogd_2.88dsf-25_amd64.deb Files: e3f1f83f2d28f2ec8d6a19ee8080d4d8 2342 admin required sysvinit_2.88dsf-25.dsc d4b12fd9d03fcb60b0630036f43d2a29 199727 admin required sysvinit_2.88dsf-25.debian.tar.gz 91bdda4fb03d8d81a4921fd326c793e4 130694 admin required sysvinit_2.88dsf-25_amd64.deb 7f48d74c515207944f3e286ecddf1c8b 96246 admin required sysvinit-utils_2.88dsf-25_amd64.deb c1725643fa2edeafffa83307de911fa7 74942 admin required sysv-rc_2.88dsf-25_all.deb e05dd763b000ca8773ec72dd07bdb71f 85378 admin required initscripts_2.88dsf-25_amd64.deb 067739cf9373621c0dec1b5053543876 51954 admin optional bootlogd_2.88dsf-25_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPvBtKAAoJEOJSSsUKn1xZ3KwQAICFimzrQ7hNmpSf4zPMTlEx 81QXVOMQ8DDkVKrepN9sCvDgNDD5ESCZcZoyTKwtbSVdTAP6YglBQ+Rth7VriJqb b/AKClycvExSRwDis3nqxbONrSI6LVUK0BF9pOaVcHy05SVhvGt5vLodLxo0ZiD+ Y42p4bjMXHLv1mYs5IZ1AymrNvPR5GJVPAph7nX0i9cIMCzDwg3MOrg/oCBg1Uem KUhQJ4xJ++TcbyeYb6Y0sws0hImBDOSVkFIqQ2u1HGBPWd3V4Ns6EmhAzVqBNl5R pSRdhV7qVg8C6EPXDNEFdcqIibN2wyPkRqH2no6JSUnvBS9or6QWYD4cOrAWjICl WM64n63aXAHwVvt80MCmvAyIg9pnuyTgBFMFvso1G80b/QMCVClL13kqs7aF/TMc YyeKuc7zNm7Tk1Y9EFUyoEGQvRuVojoo7wt4w5PGkrlJ3rkt9VeeGpAdhm0e+5aI rFeyi33bdBlR14v84YzFwFIERsnrf2xXK5r2T//TSTUC6J9mVfmelWpN6+4IHtTU 6dsuuDW/MFbQWdU3BEJ9YoqGuzVkBhBAdDoy7XdPooiZ3d+pfg2ZXygMEhXpX/C1 ru5Hyw+B6YMc+fyAYUruqm3QLZsZQF4XdvJPsCHZq8rwFLT+8PrmXUjw4S5ZOCKy ahB67Q5y3yncja2LDets =xX0W -END PGP SIGNATURE- Accepted: bootlogd_2.88dsf-25_amd64.deb to main/s/sysvinit/bootlogd_2.88dsf-25_amd64.deb initscripts_2.88dsf-25_amd64.deb to main/s/sysvinit/initscripts_2.88dsf-25_amd64.deb sysv-rc_2.88dsf-25_all.deb to main/s/sysvinit/sysv-rc_2.88dsf-25_all.deb sysvinit-utils_2.88dsf-25_amd64.deb to main/s/sysvinit/sysvinit-utils_2.88dsf-25_amd64.deb sysvinit_2.88dsf-25.debian.tar.gz to main/s/sysvinit/sysvinit_2.88dsf-25.debian.tar.gz sysvinit_2.88dsf-25.dsc to main/s/sysvinit/sysvinit_2.88dsf-25.dsc sysvinit_2.88dsf-25_amd64.deb to main/s/sysvinit/sysvinit_2.88dsf-25_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Fri, May 18, 2012 at 01:27:50PM +0200, Adam Borowski wrote: On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. We know what a primary concrete objection is. We discussed it at length at DebConf two years ago, and then on debian-devel afterwards. Uploading a Git archive requires reviewing the entire contents of the archive, not just the current code, for licensing issues, which is pretty painful from the ftp-master perspective. How come? If the .git directory shipped in the package is pruned, there is no hidden data. All you have to review are commits that are present there, which is exactly the same as with quilt: you need to review the tarball and every single patch. I think this is a key point. The aim of the git format should not be provide the entire history, any more than the other formats do (not). What should be provided needs to be - sufficient to build the package - sufficient to determine the changes made between the Upstream release and the Debian upload - sufficient to allow further uploads, including NMUs - (allow restoration of the full history) There was never really a satisfactory resolution to that discussion. We can upload very shallow clones, but they end up looking a lot like the existing quilt format with single-debian-patch, There's a whole world between shallow clones and complete ones. While existing git porcelain provides no convenient tools to selectively shallowify a repository, this is because no one had that need before. If we allow non-linear Debian changes (ie, merged not rebased, etc), there is indeed a complex question: where to cut[2]. But even then, a given commit is either present or not. If too much old history is there, that's no different from the upstream shipping an old tarball and a pile of patches upon it (like ancient apache or qmail). If the git repo contain two tags, maybe signed, one which uniquely referenced the upstream version, and one which referenced the debian version, then all commits not part of the graph between these two commits could be dropped. This would preserve all history of branching and merging between these two points. Tools used for importing upstream tarballs could automatically create such tags; native git projects can do this themselves. These tags could be put in the .dsc, so that projects can use their own naming rules, or dpkg-source could use a specific method. [As an upstream who uses signed tags for all releases, the flexibility to use the project- specific tags would be useful.] dak could check that the upstream tag referenced the same commit between uploads, as well as maybe also verifying the tag signature. This would ensure that the upstream source couldn't be altered in an upload, the same as is enforced for orig.tar right now. dak could also check the debian tag if required; though the .dsc signature would presumably be sufficient, signed tag verification would be useful for a potential git-only workflow in the future. Providing that the packaged repo contains links to the public git repo, and we can get this from debian/control (in case the developer is using a private or git+ssh repo), the end user should be able to do a simple git fetch origin to restore the full history. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120518124912.gi22...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: With the above approach, the only hard question is how to set the ownership during the package build. fakeroot handles this just fine, but it does require the user/group to be present on the build system, which will not always be the case. Is there an alternative means to set/override the ownership during packing of a tarfile? Shouldn't be to hard to make fakeroot also create fake users and groups specified in debian/passwd and debian/group (or similar). fakeroot is the wrong level to do this. Think about how you are dependent upon the NSS databases and you need a valid db for the chown/chmod commands to work. Coupled with the fact that fakeroot is not required for building, I don't think this is a good plan. A wrapper around or replacement for chown/chmod is a possibility; this could store the changes in a file, rather than change the on-disc perms, ready for dpkg-deb to use. That just leaves the question of wether dpkg uses uid/gid or symbolic names when unpacking debs. I think this one is clear: it must be symbolic since the uids/gids aren't static. Unless you want to provide a package-specific mapping in the control data, and I can't see that gains much, since it makes unpacking unnecessarily complex. If it's symbolic, you simply just extract it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120516130809.gb22...@codelibre.net
Accepted schroot 1.5.2-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 14 May 2012 23:29:22 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.5.2-1 Distribution: experimental Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols Closes: 477937 588962 625202 625205 648450 653732 658544 659524 659967 660040 661514 666274 666497 670881 672113 Changes: schroot (1.5.2-1) experimental; urgency=low . * New upstream development release. * Build with current Boost libraries (1.49). * debian/control: - Fix typo (debuggging, Closes: #653732). Thanks to Vincent Blut. - Build-Depend on debhelper 9, and po4a 0.40. - Upgrade to Standards-Version 3.9.3. * schroot preinst: Remove default (script-config) conffiles on upgrade. These are deprecated and support will be dropped in the future. * /etc/default/schroot supports ending sessions on stop (Closes: #625202). The existing SESSIONS_RECOVER option has been renamed to START_ACTION, and an additional STOP_ACTION option has been added. Both of these may be set to end to cause all sessions to be ended when run with a start or stop argument, respectively. * Support translation of the documentation with po4a (Closes: #588962). A French translation of the manual pages has been added, and translated manual pages are built, but is not yet installed. Thanks to David Prévot. * Support for overlayfs has been added in addition to aufs and unionfs (Closes: #648450). Thanks to Evan Broder. * Arbitrary options may now be set in a chroot definition in schroot.conf. These options are also set in the environment when running setup scripts, making this a simple means by which setup scripts may be customised without writing code. As part of this change, the error message for invalid keys has been reworded to make it more helpful (Closes: #666274). * The gshadow database is now copied into the chroot using the nssdatabases setup script, rather than copyfiles. * Services may be started and stopped inside the chroot on session creation and session ending (Closes: #625205). These are specified using the new setup.services key, and are started and stopped using invoke-rc.d. See schroot.conf(5) for further details. * 15killprocs kills processes under CHROOT_PATH rather than CHROOT_MOUNT_LOCATION (Closes: #672113). Thanks to Julien Viard de Galbert. * The above options may be set (where permitted) on the schroot command-line by using the new --option command-line option to set the option to a user-defined value, which will permit users to customise the behaviour of setup scripts. Note that only keys specified in the new user-modifiable-keys or root-modifiable-keys settings are permitted to be set, for security reasons. * A new custom chroot type has been added (Closes: #477937). This permits the testing and development of new specialised chroot types without the need to write any C++ chroot modules. It just requires a custom setup script, which can use arbitrary options set in your schroot.conf for configuration. Options are provided to set up the session cloning and purging behaviour for the custom chroot. See schroot.conf(5) for further details. * Exceptions thrown for command-line options validation errors no longer use the Boost validation_error exception, which formatted the exception reason text badly (Closes: #666497). * schroot(1): Update overview text, including explaining the restriction of the plain chroot type not running setup scripts (Closes: #670881). * PATH is now set when running setup scripts. * Updated translations: - da (Closes: #658544). Thanks to Joe Hansen. - de (Closes: #659524). Thanks to Holger Wansing. - fr (Closes: #661514). Thanks to Thomas Blein. - pt (Closes: #660040). Thanks to Pedro Ribeiro. - zh_CN (Closes: #659967). Thanks to Ji ZhengYu. Checksums-Sha1: 46d95ae57ef81ae04d2bb942011a034791913c4e 2424 schroot_1.5.2-1.dsc 40377167864c508901882951a1c18ad65cbf744a 718344 schroot_1.5.2.orig.tar.xz 9eaf97eac6c0635ea18a37224b3e86255107b5c5 26764 schroot_1.5.2-1.debian.tar.gz ea69f4484ca60bf980e71fc4fb4fc5c59f9610a6 252632 schroot-common_1.5.2-1_all.deb
Re: on the use of chmod/chown in maintainer scripts
On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
A lot of daemon packages in Debian nowadays create their own user and groups
during installation. Usually this also implies that a couple of files and
directories are created, and then chmodded and chowned to some appropriate
value for the service in question.
Any ideas what we should do?
Like for other parts of the packaging and maintainer scripts, I think
this is something which should be entirely declarative, and handled
at the dpkg or debhelper level.
In the case of adding users and groups, it would be helpful to have
e.g. a dh_user and/or dh_group script which look at
debian/${package}.(user|group) and put the appropriate
adduser/useradd commands into the package preinst or postinst, and
depends/pre-depends on the needed tools as appropriate.
This can also add the appropriate commands for removal in the postrm
(or not, as the consensus currently appears to be). But the policy
for that can be set by debhelper.
Why the preinst? If all static or dynamic users and groups are made
available before unpacking the data.tar, we can just unpack the tar
and the users/groups in the files and directories could be
automatically used. No manual chmod/chown would be required, since
this would all be handled transparently by dpkg.
With the above approach, the only hard question is how to set the
ownership during the package build. fakeroot handles this just fine,
but it does require the user/group to be present on the build
system, which will not always be the case. Is there an alternative
means to set/override the ownership during packing of a tarfile?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
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/20120512112827.gq23...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Sat, May 12, 2012 at 05:25:57PM +0800, Thomas Goirand wrote: On 05/11/2012 05:07 PM, Gergely Nagy wrote: I'll turn this around: how do you handle cases where the defaults of packages like apt, exim or syslogd change? Where the defaults are embedded in the executable. The thing is, if you put the default in a file, it's because you expect these to change, at least more often than things that are compiled-in. Otherwise, what's the point in having stuff stored in a file that can be edited? Why not just do a .h with the values you need? P.S: I'm continuing to ask, even though you guys are slowly succeeding in convincing me... :) Not fully though... which is why I'm continuing this (I believe interesting) discussion. At this point, I think all the pros and cons of all the various different strategies have been discussed ad nauseam--there's not much of value in continuing this further on this list. It's not adding anything new or useful. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120512113200.gr23...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote: On Sat, 2012-05-12 at 12:28:27 +0100, Roger Leigh wrote: On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote: With the above approach, the only hard question is how to set the ownership during the package build. fakeroot handles this just fine, but it does require the user/group to be present on the build system, which will not always be the case. Is there an alternative means to set/override the ownership during packing of a tarfile? One option would be to make dpkg-deb use an internal tar implementation, and add a file describing the attributes of the to be packaged files. That might make needing root privs (either through fakeroot or sudo) unneeded in most of the cases too. I found that this functionality is already present in BSD tar, according to the manpage. You can provide a file containing all the files to pack, plus their ownership and perms etc., rather than just specifying the files on the command-line. bsdtar(1) An input file in mtree(5) format can be used to create an output archive with arbitrary ownership, permissions, or names that differ from existing data on disk: $ cat input.mtree #mtree usr/bin uid=0 gid=0 mode=0755 type=dir usr/bin/ls uid=0 gid=0 mode=0755 type=file content=myls $ tar -cvf output.tar @input.mtree - I can't see an equivalent in GNU tar. But BSD tar is available in Debian. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120512214722.gl23...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote: On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote: On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote: One option would be to make dpkg-deb use an internal tar implementation, and add a file describing the attributes of the to be packaged files. That might make needing root privs (either through fakeroot or sudo) unneeded in most of the cases too. I found that this functionality is already present in BSD tar, according to the manpage. You can provide a file containing all the files to pack, plus their ownership and perms etc., rather than just specifying the files on the command-line. bsdtar(1) An input file in mtree(5) format can be used to create an output archive with arbitrary ownership, permissions, or names that differ from existing data on disk: [...] - Yeah, mtree is actually one of the things I've been having in mind when considering ways to store file metadata in the dpkg suite. I can't see an equivalent in GNU tar. But BSD tar is available in Debian. This would imply BSD tar needs to be promoted to the Essential set alongside GNU tar, at which point I might as well just use an internal tar implementation. Won't this only be needed for /packing/ the archive though? Can't any tar implementation still be used for unpacking? Or would dpkg-deb be constrained to a single tar for both operations? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120513001735.gp23...@codelibre.net
Accepted schroot 1.4.26-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 12 May 2012 15:57:33 +0100 Source: schroot Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa Architecture: source all amd64 Version: 1.4.26-1 Distribution: unstable Urgency: low Maintainer: Debian buildd-tools Developers buildd-tools-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: dchroot- Execute commands in a chroot environment dchroot-dsa - Execute commands in a chroot environment libsbuild-dev - development files for the Debian source builder libsbuild-doc - development documentation for the Debian source builder schroot- Execute commands in a chroot environment schroot-common - common files for schroot schroot-dbg - schroot, dchroot and dchroot-dsa debuggging symbols Closes: 658517 659523 659875 660040 661512 Changes: schroot (1.4.26-1) unstable; urgency=low . * Upgrade to Standards Version 3.9.3. * Updated translations: - da (Closes: #658517). Thanks to Joe Hansen. - de (Closes: #659523). Thanks to Holger Wansing. - fr (Closes: #661512). Thanks to Thomas Blein. - pt (Closes: #660040). Thanks to Pedro Ribeiro. - zh_CN (Closes: #659875). Thanks to Ji ZhengYu. * Added --exclude-aliases option. This removes aliases from the chroot selection. Checksums-Sha1: 9608e61c56f9fd182615e939066cfe38b8de22c6 2415 schroot_1.4.26-1.dsc 27fecbb05646d3f88f625c4e9cffbc0d2b6841a3 659816 schroot_1.4.26.orig.tar.xz 67fba2885d9baeab4786685cb6ef1c5173c952a1 23967 schroot_1.4.26-1.debian.tar.gz 8f8b1481989359d54de847c61624c4e7880859d2 257574 schroot-common_1.4.26-1_all.deb 2987c74d93b5ae5823501688d6440a30ac69ee1d 2025556 libsbuild-dev_1.4.26-1_amd64.deb cd4ddc31b92c02e19b717033fe11e747471449d0 26355140 schroot-dbg_1.4.26-1_amd64.deb 9e88c7923657e60c3040d98913d3985c57fc1328 6945994 libsbuild-doc_1.4.26-1_all.deb a86b80f395a7c0617c97e2c5a0b0524ec3edba02 899534 schroot_1.4.26-1_amd64.deb 6027f6fb117e2a6a6bfa5f823674a4ab086a187a 344228 dchroot_1.4.26-1_amd64.deb 22735253940987cba834de4f4890ebba87f9f1e7 343204 dchroot-dsa_1.4.26-1_amd64.deb Checksums-Sha256: f1403a916803a3813a9536537ca87405fe6b937d687085c166eaaff65aefb9a9 2415 schroot_1.4.26-1.dsc 7caa8dc8d5db95972e8459ef603afc6e0f146a139130fca7555f31217d2d469f 659816 schroot_1.4.26.orig.tar.xz 24ad4d22a0d6daf913476d23236c1c2ef706851faaf4bf55125f34f2546a7475 23967 schroot_1.4.26-1.debian.tar.gz a0b24c4afa75cac0b78a4854d8932b6934b383b9e131aa0d9099e39fe855e51f 257574 schroot-common_1.4.26-1_all.deb bf193ffd017896642602a04f2c42a4c548d10d31aecf6c8163e0342c54fde035 2025556 libsbuild-dev_1.4.26-1_amd64.deb b7051ba479f2013ae0996ec965145758c96f49027a0cdb21089204632c4e1290 26355140 schroot-dbg_1.4.26-1_amd64.deb 0ab3e7a684d53a09a69547f8f50456c053e484d81c3bac4d2e3ee58e242715fb 6945994 libsbuild-doc_1.4.26-1_all.deb 1d5cbe03ef7e9fd7a724e7f709fa58f27a407658716b6dfd87f2e24104bc20a8 899534 schroot_1.4.26-1_amd64.deb 38a4a02a2cbb0868f9b44dcdcd43a6e575343ca3931b2d42bbe70cc3266798b6 344228 dchroot_1.4.26-1_amd64.deb 78abeea2ccf553189e7f979bd4ae5fe2dc9619dc36177c77222af129273420b8 343204 dchroot-dsa_1.4.26-1_amd64.deb Files: cece62913a3acf894597f604c3474b47 2415 admin optional schroot_1.4.26-1.dsc 57e6f65e73dfa016afb6d44dac8f1e77 659816 admin optional schroot_1.4.26.orig.tar.xz d97bf02012a95e17bea3d0131a708aa9 23967 admin optional schroot_1.4.26-1.debian.tar.gz 59b59334a7abcab8e5e4c4b5c6a5ec9d 257574 admin optional schroot-common_1.4.26-1_all.deb b5861efe9141ada016c487071185ac9e 2025556 libdevel optional libsbuild-dev_1.4.26-1_amd64.deb 069cba23c4f57fe9f611e00284310945 26355140 debug extra schroot-dbg_1.4.26-1_amd64.deb 1f79757ab835268823769a1cce050ca2 6945994 doc optional libsbuild-doc_1.4.26-1_all.deb 33688262ab74fca7eae38d2a1292d4e7 899534 admin optional schroot_1.4.26-1_amd64.deb 2cec7e1c8d3ec4f4315ef5dbd4bc8ddb 344228 admin optional dchroot_1.4.26-1_amd64.deb 8f501fb2338db1b149a7872cb1837c0a 343204 admin optional dchroot-dsa_1.4.26-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPrpeDAAoJEOJSSsUKn1xZwBMP/2/J3L+0SIzUbIrX6euVDxNo zzHaGPFhK49rnL06pGg3cBSPAZ7j0adOfe69fiPEqlR5dp34Qn2V3tESMQEiZfj9 NsX1GzBsBZhIqbfxOiiGuwH3H5X8IdTjMQuFZMtZ+0ORQ1UXM3fh3ssfcOjWzB+w Fd3Fc9/LXvwi80CpVrfjRaegzh1bHfPJP1hxBBZM0zg7Q6V3koIK9hbE42M+ZSCZ 2tKtGR6I1Sur7f4SoLJpPlkLvUUoLhV+acf/Djll+ANaIkRHyox+7oweg7HySMMa wz3MreQSFUrA2c3eKb/l2N5WDrb1qJqYmM/ZhuMvtGiRJw0zfVVfg6zfCgTNiL1X vpyU24DSuiwWnDcspc3C/Loix9ea7jGbXkRGsQnm9epeHtrZLQvyXQdaVznhhG+m ReEJBO1dToRLLyr7bXNY/qPWtMq2ObnYxcd63ykrtSWyGcXWYoVeSLOdvk7xLwV2 Af2uP+fPS+f2CQ5xfby6KeCR3kUQP+r2n5ocnd2ysLoalf6cETmhndVjf1ljDLqL Pl05cvpH4ofR+fSSo8qc8I+PxyvSifS7AovmwM67K1EZshppVeKFI+0nPgBf2aYj kAFxfqlle58DfYN4NxVJrDjYYAGGHByQEVHzeQt0xI37tp91aAFQ2mONyMpAv01+ K1xqYxEO137efLOlEM7i =ZOyg -END PGP SIGNATURE- Accepted: dchroot-dsa_1.4.26-1_amd64.deb to main/s/schroot
Configuration file handling (was: RFC: OpenRC as Init System for Debian)
On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles I'm unconvinced that this would be workable. How many programs and configuration files reference absolute paths under /etc? Which wouldn't be overridable using the proposed mechanism. Is this going to concern itself only with init.d scripts or all conffiles? Bind mounting the prinstine copy over the broken copy is probably the safest way--it keeps all the paths consistent, though you'd lose /all/ configuration if you bind over the whole /etc rather than just parts of it. A unionfs overlay might also be an option, then the /etc-only files can show through; but all these are still far too fragile for my liking. I would much rather we had a more general mechanism of storing the real configuration files (as opposed to just md5s) by dpkg itself, which would enable proper merging of admin changes between old and new conffiles, and perhaps also allow dpkg to implement ucf-like conffile handling (or remove the need for ucf entirely). These could be stored under /var/lib/dpkg/conffiles (for example). For the pristine initscripts use case, it would be possible to mirror a subset under /lib or /etc. But how often does anyone make their system unbootable even with the most extreme init script hacking? We already have rescue boot CDs etc. to cater for this eventuality in any case--why introduce a pile of complexity into the system when it's already redundant? On a related note... While we might criticise rpm for its bad conffile handling, dpkg is itself fairly woeful, and if we change one thing for wheezy+1, it should be sane conffile handling. dpkg should never forget about conffiles; the fact that maintainer scripts have to take care of purging such files is a glaring defect, and possibly the source of the greatest fragility in our maintainer scripts--it's impossible for maintainer scripts to get this right all the time given all the corner cases like downgrades and being taken over by other packages. If this was implemented robustly, the maintainer script should never need to concern itself with such cleanup, or indeed any manual work with conffiles at all, except maybe for deletion ahead of purge where this is needed. And given the frequency this is needed, a defined mechanism to do this would be useful. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120511124132.gn23...@codelibre.net
Re: Directory /boot/console-setup
On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: [Please preserve the CC to 672...@bugs.debian.org because I am not subscribed to debian-devel.] First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. We created /run for exactly this purpose. Create /run/console-setup and put what you need inside there. You'll need to follow the advice in http://wiki.debian.org/ReleaseGoals/RunDirectory . You basically just need to have a Depends on initscripts (= 2.88dsf-13.3) and you're good to go. Don't store megabytes of data in here though, since it's stored in virtual memory on most systems. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120510174518.gk23...@codelibre.net
Work on init systems (was: Making -devel discussions more viable)
On Wed, May 09, 2012 at 12:29:21PM +0300, Arto Jantunen wrote: Thomas Goirand z...@debian.org writes: But that's not the problem. The issue is that there's no outcome, and that it's demotivating. If I read others that what we want to work on isn't a good idea, I will simply not work on that, and external contributors will run away. I agree with this. The init system discussion has gone on long after it was useful, and instead of discussing the matter we should be working on implementing what we want to implement. As an example, if you want to see OpenRC in Debian, make it work and upload it. If someone else wants to see systemd in Debian they can make it work and upload it (as has been done). This is exactly what is happening. I'm still involved with talking about this with the OpenRC upstream folks on their IRC channel, and while I've not yet had a chance to begin packaging it, there's a repo on collab-maint in preparation for that. In order to make OpenRC usable in Debian, we need it to be able to work with LSB scripts, but it's not yet clear on how to do that. An upstream developer was initially keen to look into doing this, but it looks like they are now short on time, so we might need to do that part ourselves in collaboration with them. I'm short on time myself, so if anyone wanted to join in with doing this, I'm sure we could set up a proper mailing list and start moving things a bit faster. I think the only technical decision that needs to be made at this point is removing the Essential mark from sysvinit. The consensus for that should be somewhat more reachable, even if the technical implementation may have some open questions. This is already in the works. It can be removed right now. The only thing stopping it is just investigating the impact on removing the Essential flag on the installer etc. If there are no deleterious consequences of this change, it can be made in the next upload. Any advice on doing this would be appreciated, e.g. in case this would make it more liable to cause breakage if apt could remove sysvinit and result in a broken system. In addition to that it would be nice if everyone could agree to not work against a certain init implementation (for example by refusing to include the startup file for that init when someone else has written one and submited it as a wishlist bug). We should however not demand that people work on writing startup files for init systems they don't care about. AFAIK this is exactly what's happening. While I've been working on sysvinit I've made numerous changes to better accommodate systemd and upstart, and with the latest experimental uploads it includes some changes to better work with upstart. There's no blocking involved-- I've been happy to make changes that improve things for alternative init systems, and make migration easier, while also making things better for everyone. So long as it doesn't have a negative impact on existing sysvinit users, no changes have so far been refused. While I have personal reservations about making systemd or upstart the default at this time or in the near future, I am nevertheless keen to make their support in Debian top-notch, and I will continue to work on reorganising sysvinit to make this even better. WRT supporting multiple init systems, I certainly don't think it's a wise move for packages to support multiple init systems. If we change the default, we should e.g. provide a means for sysvinit to run systemd service units to allow for a smooth migration, and amend policy so that all packages provide files in the same format-- we don't really want to have fragmented support for different systems within Debian, though supporting different init systems as the present is needed and desirable. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120509110759.ge23...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Wed, May 09, 2012 at 03:37:50PM +0200, Tollef Fog Heen wrote: ]] Philipp Kern You will not, however, get a conffile update prompt when the system file changes (e.g. to update your own local copy to incorporate the fix). This is something I'm pondering if we should handle in either a systemd trigger or a tool that packages shipping systemd files can call to tell the user about any changes. (Basically a wrapper around ucf, probably.) Can't we just do things the Debian way, and just provide them directly as conffiles in /etc? It's nice that systemd provides its mechanism to symlink/include the units provided elsewhere, but is this either necessary or desirable on a Debian system? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120509142404.gf23...@codelibre.net
Accepted sysvinit 2.88dsf-24 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 29 Apr 2012 23:52:14 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-24 Distribution: experimental Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 353229 437176 624391 660824 668307 669949 670085 Changes: sysvinit (2.88dsf-24) experimental; urgency=low . [ Roger Leigh ] * initscripts: - Don't generate or touch /etc/motd. Instead, the dynamic part of /etc/motd is created as /run/motd.dynamic, leaving /etc/motd entirely under the control of the system administrator. If /etc/motd is a symlink to /run/motd, /etc/motd.tail is moved back to /etc/motd. Closes: #353229, #624391, #668307. /etc/motd is not removed if initscripts is purged, since it's not owned by initscripts. - By default, /run/motd is just the output of uname, preserving the existing behaviour. However, should the administrator wish to include dynamic information in the motd, they may write scripts to update /run/motd.dynamic as they please. Closes: #437176. - motd generation is split from bootlogs into a separate motd init script. - bootlogs init script has been removed; current logging daemons handle this themselves, making this script redundant. - tmpfs mounts are never cleaned by bootclean.sh. Cleaning /run can lead to nonfunctional input when Xorg starts. Closes: #669949. * sysvinit-utils: - Suggest rather than Recommend bootlogd; Recommends would effectively . [ Kel Modderman ] * sysv-rc: - Run check_divert in postinst to make sure /usr/sbin/update-rc.d not symlinked to /usr/sbin/update-rc.d-insserv. Closes: #670085. . [ Steve Langasek ] * Install the startpar bridge now that dh_installinit in Debian handles this. Closes: #660824. * Give startpar a listening backlog on its socket for upstart connections, since there's no protocol-level queuing for unix sockets and these connections tend to come in fast and furious at boot. Checksums-Sha1: e01a5b8072f791cc5d66936329847c5d51d825ab 2342 sysvinit_2.88dsf-24.dsc a054d9eb9019cd1fb6b1ab24d40ab26aec4094ce 198897 sysvinit_2.88dsf-24.debian.tar.gz 4df675fc72df9346acdb22cb558d4fc670205eff 130470 sysvinit_2.88dsf-24_amd64.deb 7d84a863630f5a27ce4b86ba13cdb2c38c21354c 96086 sysvinit-utils_2.88dsf-24_amd64.deb a99e96ad8604dc5ca8557d296e627c36bf272595 74648 sysv-rc_2.88dsf-24_all.deb 4539b113f5fc25c223af2fdccb77bb45622e0945 86030 initscripts_2.88dsf-24_amd64.deb 8b0dc812470ccc8e22487bac445ca920cc4311c8 51688 bootlogd_2.88dsf-24_amd64.deb Checksums-Sha256: d89af707a8d7ec8af027b4a140c432c61688abc0a15a9cfa865d0d4a70c64a3b 2342 sysvinit_2.88dsf-24.dsc 4909c59767dfad57adfe7a7a7e81285ad19d62c33d2b582d94f8fc9e3c7df4ea 198897 sysvinit_2.88dsf-24.debian.tar.gz 2d1ee660060c84fa15fa988d15b86485bb7bde2f2304952521eb5e5ee7da4f1b 130470 sysvinit_2.88dsf-24_amd64.deb 9b0779230de35778b6073918f1bbd14591d9bc6ada60454aa1153ac3f8cb69e7 96086 sysvinit-utils_2.88dsf-24_amd64.deb 59d1d31136301a23c2e5d8db71f87221c34ac04e8d4bf1a381316f1953df603b 74648 sysv-rc_2.88dsf-24_all.deb ae5ee9452bbce06a1f5dc43f54f815d310d1f1f5d70b7f3e16da8960a9c571e8 86030 initscripts_2.88dsf-24_amd64.deb ef50a2ded21580a60847b0a53fd3e978a2e074adbd301ec845f7b705adde6215 51688 bootlogd_2.88dsf-24_amd64.deb Files: 457458d34dd44212495e37e149415a24 2342 admin required sysvinit_2.88dsf-24.dsc 3cc8109a4d3686c9d8bd7c65f7c13381 198897 admin required sysvinit_2.88dsf-24.debian.tar.gz 7776c56f9cb448975c2de1266d60290d 130470 admin required sysvinit_2.88dsf-24_amd64.deb 4fe7e75552689d57dab101eb041b3aa2 96086 admin required sysvinit-utils_2.88dsf-24_amd64.deb bd8f2c760f0427a9bfc0f1204a448cdb 74648 admin required sysv-rc_2.88dsf-24_all.deb 801629c05aad9f87d74f6e56cc9ccd7d 86030 admin required initscripts_2.88dsf-24_amd64.deb 44f5c2f88f9dbf0cecbf00390a9508e9 51688 admin optional bootlogd_2.88dsf-24_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPqZXmAAoJEOJSSsUKn1xZnLYP/0Z7ZGLvbYotXGTzkYfNCm4g L9ETRt9DFMG3l2A2YJRK95bG82ozBBR9C5vHvLQ/57qVvVUt+HeciCOcLpNuxYTF IFJs6Tt/FzRZcJ7EE7kBULrCb8R188XgBLI1AkP1eclz4oQvbchRIf5xGP3k0ix7 4NviO6ju/FFZklWIuaITW3PWR3c2Ezw6TOdvfoZK9Ab8H0bVM3Y6S7936P0gq+ZB ghhVbbxsqJt3gCXAjCr24x8Ghyvg5HsJuq1xM63N3mUJGV7mor2rsuk2fs2O5Veg nBGs8LY97mN0BBU1BiG4RGNPTdZt5Um3ziXF6ssdoSEPnfGy1gq6vcxeqrWD9RKJ W2lHcJnSUkBBYGvYitB/y/cE6v3Xl/7+IVgDmOvEaoT1klE4tney18Lsv8rahEtK
Re: RFC: OpenRC as Init System for Debian
On Mon, May 07, 2012 at 09:30:42PM +0800, Patrick Lauer wrote: On 04/26/12 00:42, Roger Leigh wrote: On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote: I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. While as others have mentioned that ideally a more dynamic init system such as systemd or upstart is where I think the general consensus is Define dynamic please, and don't use lines of code changed per month as metric ;) As long as we don't even agree what that (and event driven) mean it'll be needlessly confusing for all involved to discuss without a shared vocabulary. From the dependency side, it looks like OpenRC has most of that functionality covered; it can start other services as required in order to bring up dependencies needed by a service before starting it. What systemd has that (AFAICS) OpenRC and sysvinit/startpar/insserv do not, is a global view of the entire running system. That is, when you run an OpenRC script, it can trigger dependencies recursively, but it doesn't have itself a dependency graph of the entire set of available services. systemd, in comparision, can read all the unit files and has a complete picture of the entire system. So in a sense, it has a higher-level view of the system--mountpoints and other stuff can go into the dependency graph, which solves som of the issues with mounting of network filesystems and bringing up interfaces, and starting the necessary services etc. The dynamic part is AFAICT a few pieces: 1) socket-based service activation 2) dbus-based service activation [and I guess others, e.g. udev, initctl, etc.] All of these are effectively the same conceptually; an external trigger causes systemd to execute actions. The socket-based activation is essentially the same as inetd, but because it's integrated into systemd it can fit this into the dependency graph, as well as starting all the listeners in a single step, and then allowing the actual services to be started on demand. The dbus activation is similar (I'm less familiar with it), but working over dbus instead. I guess this is needed for integration with desktop environments (e.g. bluetooth), in response to user actions. The other really nice thing that systemd has is a unified means of configuring the process environment for all services, e.g. resource limits, umask, etc. which are all set up before starting the service. That's not to say that OpenRC couldn't be made to do any of these things, it being a superset of the functionality currently provided. But it would probably require replacement of sysvinit as init with a daemon like systemd which could keep track of all the dependencies and other stuff, and respond to signals of various types to trigger events. It could convievably query each init script for its dependencies to build up the complete picture of the system; this could cater for reading from multiple sources like systemd does: OpenRC scripts, LSB scripts, systemd units, /etc/fstab, and /etc/inittab etc. The above type of central control is one source of confusion in our initial discussions regarding LSB script support; I initially assumed that this was how OpenRC deps were implemented, which would have made LSB script support simpler. However, it would be possible to extend the OpenRC functions to trigger the central coordinating service rather than doing things themselves, as well as to configure the per-service process environment. (I was planning on bringing this sort of possibility up, but wanted to learn more about the design of OpenRC and get it working first on Debian with LSB scripts so I had a clear understanding of what would or would not be possible or appropriate.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120507155858.ga22...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Mon, Apr 30, 2012 at 02:00:15PM -0300, Fernando Lemos wrote: On Mon, Apr 30, 2012 at 12:50 PM, Roger Leigh rle...@codelibre.net wrote: On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote: On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand z...@debian.org wrote: On 04/30/2012 04:56 AM, Fernando Lemos wrote: I agree that OpenRC would be an improvement over the status quo, but migrating *away* from OpenRC later on would be a major pain as we would have to support both LSB/sysvinit scripts and OpenRC service descriptions for the foreseeable future. Ah? Is this any different with other alternatives like upstart or systemd? Yes. The kernel isn't getting any less event-based, so OpenRC would be an interim solution. Unless OpenRC itself could become more event-based. How realistic is that? I'm not sure yet. That's one of the things I'd like to find out. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120501102134.go28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote: On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand z...@debian.org wrote: On 04/30/2012 04:56 AM, Fernando Lemos wrote: I agree that OpenRC would be an improvement over the status quo, but migrating *away* from OpenRC later on would be a major pain as we would have to support both LSB/sysvinit scripts and OpenRC service descriptions for the foreseeable future. Ah? Is this any different with other alternatives like upstart or systemd? Yes. The kernel isn't getting any less event-based, so OpenRC would be an interim solution. Unless OpenRC itself could become more event-based. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120430155009.gl28...@codelibre.net
Re: switching from exim to postfix
On Sun, Apr 29, 2012 at 07:03:11PM +0200, Julien Cristau wrote: The 500 packages that would have to change their Depends from exim4 | mta to something else. The brokenness of having to have a default package hardcoded in every virtual dependency rather than having a virtual defaults package and/or central list is an insanity I wish we could have fixed years ago. We should not have global policy WRT virtual package defaults embedded (inconsistently!) into every single dependency! Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120429170701.ge28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Fri, Apr 27, 2012 at 08:49:24AM +0200, Adrian Knoth wrote: On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote: I believe Debian still supports running locally compiled kernels which do not depend on udev, and that some setups do not require udev either (not everyone use fibre channel). And then, there is this statement about the core distro: There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this “core distro” can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the “universal” distros. I hope I'm not alone in feeling quite uneasy about the implications of the above. One of the definining characteristics of the Linux ecosystem, including Debian, has been that the system has been made up of a set of loosely- coupled compoments with well-defined interfaces. This is in stark contrast to, e.g. Windows, MacOS and other proprietary systems, which have extremely tight coupling between their components, and where being able to swap out one component for another is almost unheard of. Given that this loose coupling has enabled experimentation with a wide variety of different solutions to problems, and allowed the evolution of a diverse range of different packages to solve a very wide variety of needs, it could be considered one of the defining factors in the success of Linux. Quite why we would want to replace this with a one-size-fits-all solution beggars belief. Given the ongoing debate regarding the different init systems we might want to adopt long-term, I think this is perhaps one of the less discussed factors, but perhaps one of the more important ones. Both systemd and upstart are technically superior to all the alternatives, systemd perhaps more so. But while the technical advantages are nice, these come at the cost of reducing the amount of diversity in the system, and our ability to replace pieces which don't fit our needs due to the tight coupling. While sysvinit is clearly inferior, it gives us (Debian) something the others do not: control over our own destiny, and the ability to modify every aspect of it and the init scripts to fit our needs. Both systemd and upstart are largely influenced by third parties. As a trivial example: systemd creates user session information in /run/user/$user . I brought up with lennart the fact that this would only permit one session per user. He rejected out of hand the fact that more than one session would ever be needed, because Gnome only allowed one session per user. So the limitations of Gnome in this respect have led to a fundamental limitation in systemd's session management. We could patch and work around this type of brokenness easily enough. But given the rapid speed at which systemd is growing and swallowing up more and more functionality previously served by different tools, would we have the ability and will to continue to patch every bit that didn't fit our needs, and keep that working over time? If we can't, we'll potentialy end up with a technically superior system... which meets the needs of Gnome/Fedora and other distributions, rather than our own. And when the primary maintainers have shown themselves to be less than willing to accommodate even this simplest of requests (as above; a single tempnam call would have been sufficient), would we be committing ourselves to a less than desirable fate? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120429174548.gf28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Thu, Apr 26, 2012 at 01:42:48PM +0100, Roger Leigh wrote: I'm going to investigate it in more detail on a running Gentoo system and learn a bit more about it before doing anything. If anyone fancies doing the packaging, I'll be happy to join in. I'll probably be able to provide a better overview once I know a bit more. Just to provide a bit more context for this discussion. After learning a bit more about how OpenRC works, thanks to their assistance on IRC: - OpenRC is a relacement for sysv-rc/insserv/startpar - It still depends on sysvinit, though only for the initial inittab runlevel actions. - It uses its own dependency system rather than LSB. In some ways, it's nicer (starting a script manually will also start the required deps, something LSB scripts can not do), and most of the LSB deps will map to OpenRC deps (not sure about all the (X- variants yet) - It looks like it will be possible to get OpenRC to run LSB scripts and cope with LSB dependencies, which would let us evaluate it in Debian. So from the POV of the wider systemd/upstart debate, it's not going to particularly affect that. I think this could be viewed as a potentially good upgrade from insserv/startpar. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120429175717.gg28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Sun, Apr 29, 2012 at 08:19:44PM +0200, Marco d'Itri wrote: On Apr 29, Roger Leigh rle...@codelibre.net wrote: While sysvinit is clearly inferior, it gives us (Debian) something the others do not: control over our own destiny, and the ability to modify every aspect of it and the init scripts to fit our needs. Both systemd and upstart are largely influenced by third parties. As a I do not consider settling for obsolete software to be a useful direction for Debian, nor is NIH a great argument in software design. Just to be clear, I am by no means suggesting that we should stick with sysvinit. I am merely pointing out that there are important factors to consider /in addition to/ the technical merits of the init system. With systemd we get a technically excellent system, but we are also buying into a whole lot more than that, some good, some bad. Keeping our options open, and evaluating what are options are available and usable is important, and this is the principal reason why I am interested in looking at OpenRC. It doesn't hurt to try it out and see if it meets our needs. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120429201451.gh28...@codelibre.net
Re: Node.js and it's future in debian
On Fri, Apr 27, 2012 at 07:14:04PM -0700, Russ Allbery wrote: Carl Fürstenberg azat...@gmail.com writes: As I'm not a hamradio user, I'm off course biased towards letting nodejs having the node binary and let it pass to testing. But we must find a solution to this, as nodejs is getting more and more used, and developers are forced to install nodejs from source to be able to use it instead of install it via the package manager. This increasingly feels like the same situation as Git: yes, another utility was first, but the usage of one is a tiny fraction of the usage of the other, and people expecting to use a common package expect it to be available under that name and think poorly of Debian when it doesn't just work. From a purely pragmatic POV, how many people are using both packages? If the answer is zero, and this seems relatively likely, can't we just add a Conflicts/Breaks and be done with it. Not a great solution, but it doesn't seem like there's a better one if both camps are unwilling to change. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120428094136.gh28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Fri, Apr 27, 2012 at 05:18:35AM +0200, Michael Biebl wrote: This is getting OT and a better question for debian-user, so this will be my last post regarding this issue. On 27.04.2012 04:34, Chris Knadle wrote: AFAICT I really want the 'quiet' linux command line parameter, and to reconfigure the console output of systemd somehow. man 1 systemd : Try adding systemd.show_status=true systemd.sysv_console=true to your kernel command line. This is basically having the same effect for systemd as removing the quiet kernel command line option. Is this the default? Or do we need an additional silent option so that systemd can behave similarly to the existing stuff when passed the quiet option? Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120427075451.ge28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Thu, Apr 26, 2012 at 09:49:18AM +0200, Bernd Zeimetz wrote: On 04/25/2012 06:42 PM, Roger Leigh wrote: On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote: I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. While as others have mentioned that ideally a more dynamic init system such as systemd or upstart is where I think the general consensus is (we all know that sysvinit/insserv is flawed in many ways, even if we can't agree on what should replace it), there is always the possibility of having OpenRC as a sysvinit alternative in the interim, or potentially as a systemd/upstart alternative longer term. Initially, we'd want to package it and make sure that it works ^ Does that mean you are working on it already? ;) So far I think using OpenRC is the first sane idea in this longish discussion, and while I won;t have the time to maintain it I would be happy to help with the initial packaging and testing. Not yet, I hadn't looked at it at all until mentioned on this thread. But I am exploring it in a bit more detail and discussing it with the OpenRC developers. It's definitely worth considering. It has some significant advantages over startpar/insserv. In the longer term, if systemd/upstart are an inevitability, whether it's worth doing is perhaps moot. - startpar computes the inter-script dependencies from the LSB info when update-rc.d is run. openrc does it dynamically, without there being a static .depend file. It's probably more robust in consequence; it can't get out of date or break if there are manual changes - the scripts are much cleaner. All the common stuff found in our scripts is removed. So you just provide functions for start and stop actions etc. No need for all the boilerplate. The dependency info is also provided this way as well, so no need to parse comments. - knows whether services are running or not - supports cgroups like systemd - supports kFreeBSD (unlike systemd, the cgroups and other) - (could potentially support Hurd) OpenRC doesn't currently parse LSB headers; it would definitely need to be able to do this before we could adopt it. systemd (I think) currently understands LSB headers; it would also need to be able to process OpenRC dependencies as well, AFAIK. I'm going to investigate it in more detail on a running Gentoo system and learn a bit more about it before doing anything. If anyone fancies doing the packaging, I'll be happy to join in. I'll probably be able to provide a better overview once I know a bit more. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120426124248.ga28...@codelibre.net
Re: Plans to (re-)include cgroups in wheezy?
On Thu, Apr 26, 2012 at 03:00:55PM +0200, Michael Hanke wrote: I'm trying to get Condor [0] included into wheezy. I just now realized that the cgroups package [1] which condor currently depends on is in a rather bad shape (numerous bugs, only little maintainer response, last upload a year ago, one upstream release behind). Looking at HOWTOs like [2] it seems that the overall setup of cgroups in Debian is suboptimal -- but I'm not really in the position to judge, as I have no personal experience with cgroups. Setup should (?) probably be handled by initscripts. See #601757. However, we should also copy the set of mounts used by systemd (?). Is the proposed patch in this bug sufficient? I've not yet looked to see--I'm not familiar with cgroups, and I don't know if it's sufficiently compatible with the systemd mounts. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120426140158.gb28...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
On Thu, Apr 26, 2012 at 11:50:51PM +0800, Thomas Goirand wrote:
On 04/26/2012 08:42 PM, Roger Leigh wrote:
If anyone fancies
doing the packaging, I'll be happy to join in. I'll probably be able
to provide a better overview once I know a bit more.
I don't know much about OpenRC apart from what Patrick told me,
but I'd be happy to discover it. Maybe I can start packaging with
Patrick together, and with you as well.
That sounds great. I'm equally in the dark regarding OpenRC, though
I've checked the git repo out and had a chat on IRC with some of the
developers. My initial impressions are that it adds some very nice
features which are lacking in our current default sysvinit setup,
while not going quite as far as systemd/upstart. Certainly a very
nice upgrade to what we currently have, while not being as radical a
change as the other alternatives. Other than replacing the /etc/rc?.d
symlink farms with /etc/runlevels/name (and most of us really don't
care about runlevels directly), it's pretty much identical from the
user's POV.
I've taken the liberty of creating a repo on collab-maint for Debian
packaging. git://git.debian.org/git/collab-maint/openrc.git
It's currently just branched from the current upstream repo with
no changes.
I've read others writing that they don't like the LSB headers. I'd like
to know why. What's wrong with it? I find ok-ish. Sure perfectible,
sure the syntax is a bit stupid and verbose for no reasons, but that's
not *that* bad. So, could you tell why you think it's bad? (this of
course isn't aimed at Roger specifically, but to everyone)
Two issues that come to mind
- it's not permitted for a package to declare that it provides a
virtual service, e.g. $cron. This is actually in the LSB spec.
OpenRC does allow this. There are several bugs about this.
- it's just a block of text inside a shell script comment. Not the
nicest thing to parse. In comparison systemd is entirely
declarative. OpenRC is sort-of declarative inside a shell function,
but is actually part of a script so you can define them
programatically as well from what I can tell, which would mean it
might be possible to conditionally depend on things.
depend()
{
need localmount
keyword -jail -openvz -prefix -vserver -lxc
}
depend()
{
need localmount
after bootmisc
provide net
keyword -jail -vserver
}
Next: if the LSB headers are bad, what are our options to move
away from them? Should we do some kind of tools to convert them
to a better, simpler format? How does it work with systemd for
example? I've just read about .depend files, how are they handled?
The .depend files are an internal implementation detail of startpar
and insserv. insserv generates them from the LSB headers, while
startpar uses them to parallelise startup. If you take a look, you'll
see that it's basically Makefile-style dependencies.
systemd unit files are purely declarative descriptions of services.
It uses socket-based activation to defer starting services, similar
in concept to inetd I guess, but encompassing much much more. So
a service will get started when something tries to connect to it,
which will block until it's available. It's a really nice concept.
I've not figured out exactly how the OpenRC dependencies work, or if
it's possible to dump them by running the script. I've had a small
look, but not had enough time to familiarise myself with it all yet.
I agree that best would be if OpenRC was a simple drop-in replacement
for insserv, and if it supported what we currently have *PLUS* some
new features (which have already been discussed during huge threads,
I don't feel like enumerating them again...). If it doesn't, then maybe
I can beat-up^Wmotivate Patric to work toward that goal of
supporting our already existing infrastructure.
I'm not sure where all this will lead me/Debian, but I think this is
worth a try. I'll try to catch-up with Patrick and talk with him about
how we can start doing this. Maybe we can also have a round table
about this during Debconf12...
I think it's definitely worth exploring. From our chatting on IRC, I
think the following came out of it:
- We need LSB dependency support in OpenRC in order to support all the
init scripts in Debian which utilise them. Definitely required in
order to make it possible to evaluate OpenRC without converting the
entire distribution immediately.
- Converting all our core initscripts probably isn't a massive task.
It can probably be done inside a weekend. There's undoubtedly a
large amount of overlap with the OpenRC scripts, which would need
removing/replacing where appropriate.
- Given that runlevels have names rather than numbers, we would need
to look into how update-rc.d interacts with OpenRC. Conversion of
/etc/rc?.d to /etc/runlevels (and in reverse) also needs
investigation. For update-rc.d we could probably map the standard
0/1/2/6 numbers
Re: RFC: OpenRC as Init System for Debian
On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote: I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. While as others have mentioned that ideally a more dynamic init system such as systemd or upstart is where I think the general consensus is (we all know that sysvinit/insserv is flawed in many ways, even if we can't agree on what should replace it), there is always the possibility of having OpenRC as a sysvinit alternative in the interim, or potentially as a systemd/upstart alternative longer term. Initially, we'd want to package it and make sure that it works with our existing init scripts, before it could be considered as the default. (Obviously we can't make any promises about that; we already have a number of alternative inits, and OpenRC would be one of several.) I think the key requirement is that it can function as a drop-in replacement for sysvinit/insserv. Are there any important differences? Does it treat LSB dependencies the same as insserv? How about old scripts lacking dependency info? Are the dependencies computed dynamically or generated? (insserv hooks into update-rc.d) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120425164212.gw28...@codelibre.net
Re: Bug#669647: ITP: hurd-cvsfs -- CVS virtual filesystem for the GNU Hurd
On Mon, Apr 23, 2012 at 09:18:30AM +0200, Josselin Mouette wrote: Le vendredi 20 avril 2012 à 20:23 +0200, Samuel Thibault a écrit : * Package name: hurd-cvsfs Aren’t you late by 19 days? (This isn't intended as a criticism of this specific ITP.) While it's great that Hurd can support all of these esoteric translators, in terms of making Hurd a viable *Debian* port, we really only need a few specific ones: - tmpfs - procfs - sysfs - ext?fs Speaking from the perspective of initscripts, we are carrying around a large amount of Hurd-specific code, which as far as I understand is probably actually unused. Example: All other platforms have /etc/mtab as a symlink. Yet we are carrying around large amounts of code and extra initscripts to generate mtab for the only system which does not support /proc/mounts (Hurd). A procfs translator (even an incomplete one) would allow all this (barely tested) cruft to be dropped. It would be really great if the efforts of the Hurd developers could be directed to getting the translators which are of direct benefit to the distribution as a whole functional, rather than features such as this--who uses CVS nowadays anyway, let along through a translator? It's neat, but not really useful (from the POV of the distribution as a whole). Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120423084432.gq28...@codelibre.net
Re: Bug#669647: ITP: hurd-cvsfs -- CVS virtual filesystem for the GNU Hurd
On Mon, Apr 23, 2012 at 11:20:00AM +0200, Samuel Thibault wrote: Roger Leigh, le Mon 23 Apr 2012 09:44:32 +0100, a écrit : While it's great that Hurd can support all of these esoteric translators, in terms of making Hurd a viable *Debian* port, we really only need a few specific ones: - tmpfs - procfs - ext?fs They are already there. OK. I was informed otherwise when I was working on all the tmpfs-related code. If this is the case, I will remove all the Hurd-specific disabling, and it will be enabled shortly. You'll get a tmpfs /run etc. like everyone else. Does Hurd support ext3/4 yet? - sysfs Err, I don't think it's a good idea to let people think it is ok to use extremely-linuxish things there. kFreeBSD supports both linprocfs and linsysfs. If you're going to integrate well with the rest of the Debian system, the reality is that this stuff is needed. We shouldn't need Hurd to be gratuitously different for such basic stuff, it again causes a large maintenance burden, and means Hurd support will be lacking. Yet we are carrying around large amounts of code and extra initscripts to generate mtab for the only system which does not support /proc/mounts (Hurd). A procfs translator (even an incomplete one) would allow all this (barely tested) cruft to be dropped. We have an incomplete procfs already. It doesn't have /proc/mounts, because it's not a trivial thing to implement: since mounts are distributed, there is no central place where filesystems are to be recorded. There are plans to somehowe build one. In the meanwhile things are working already. I don't think spending time on a feature just to remove some existing code is the best way to spend our time, either. It's not just a case of working already. I spent several days writing and testing all that code. From scratch. Just for Hurd. And this is just one example. We need a dynamic mtab; a static one is plain broken, and this does have a maintenance burden which Hurd forces me to undertake. There's special code in every initscript which mounts something, plus a whole library of shell functions... which should be deleted at the earliest opportunity. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120423094300.gr28...@codelibre.net
Re: Bug#669647: ITP: hurd-cvsfs -- CVS virtual filesystem for the GNU Hurd
On Mon, Apr 23, 2012 at 03:47:18PM +0100, Ben Hutchings wrote: around large amounts of code and extra initscripts to generate mtab for the only system which does not support /proc/mounts (Hurd). A procfs translator (even an incomplete one) would allow all this (barely tested) cruft to be dropped. We have an incomplete procfs already. It doesn't have /proc/mounts, because it's not a trivial thing to implement: since mounts are distributed, there is no central place where filesystems are to be recorded. There are plans to somehowe build one. In the meanwhile things are working already. I don't think spending time on a feature just to remove some existing code is the best way to spend our time, either. [...] I would say something *like* /proc/mounts is important for a modern Unix-like system. I'm sure it's not trivial, but it's implementing a standard format (mtab) and not a moving target of 'be like Linux'. For mtab, it's probably not even strictly necessary for this to be in /proc/mounts. It could be a translator on /etc/mtab directly? (If a translator can be a single file?) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120423145529.gs28...@codelibre.net
Accepted sysvinit 2.88dsf-23 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 21 Apr 2012 12:11:45 +0100 Source: sysvinit Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd Architecture: source amd64 all Version: 2.88dsf-23 Distribution: experimental Urgency: low Maintainer: Debian sysvinit maintainers pkg-sysvinit-de...@lists.alioth.debian.org Changed-By: Roger Leigh rle...@debian.org Description: bootlogd - daemon to log boot messages initscripts - scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities sysvinit-utils - System-V-like utilities Closes: 55707 232569 385172 403863 438895 518249 539261 540448 543793 545401 545438 550425 558000 562500 567539 585540 587923 596284 596479 596480 596481 596482 596483 614895 623051 634146 636054 652625 659480 659490 660824 664816 665995 666871 667745 668312 Changes: sysvinit (2.88dsf-23) experimental; urgency=low . [ Roger Leigh ] * Acknowledge NMU for translation updates. Thanks to Christian Perrier. * debian/control: - Upgrade to Standards-Version 3.9.3. - Build-Depend on debhelper v9. - Correct Vcs-Git URL. * debian/rules: - Use DEB_HOST_ARCH_OS = hurd rather than DEB_HOST_ARCH = hurd-i386. Thanks to Pino Toscano. * debian/patches: - 11_lfs_cflags.patch: Add patch for enabling large file support, needed on GNU/Hurd, but useful for all platforms. - 73_lfs_cflags.patch: Add patch for enabling large file support in startpar. * initscripts: - Moved RAM* settings from /etc/default/rcS to /etc/default/tmpfs. This ensures that the settings are equivalent for upgrades and new installations, but will require manual configuration of the settings for upgrades (no migration from /etc/default/rcS to /etc/default/tmpfs will take place, due to tmpfs being a conffile). tmpf(5) manual page added to document all aspects of tmpfs configuration, including the existing documentation in rcS(5). - Drop the use of .ramfs dotfiles in /run and /run/lock. These were a legacy of /lib/init/rw and were not actually used by anything. Closes: #403863. - Drop /etc/init.d/mountoverflowtmp. This has been merged into the general tmpfs on /tmp handling functions. This means the generic RAMTMP configuration is used for the overflowtmp. Closes: #567539. - It is now possible to configure a tmpfs mount size limit as a percentage of the total VM size (%VM) as well as a percentage of the RAM size (%). This is computed by tmpfs.sh and the tmpfs mounts are remounted with the updated size limit after swap becomes available. - An fstab entry for /tmp overrides RAMTMP. Document tmpfs override and tmpfs defaults in tmpfs(5), also undeprecating the tmpfs settings. Closes: #585540, #665995. - An fstab entry for /run/lock or /run/shm overrides RAMLOCK and RAMSHM. - bootclean cleans /tmp, /run and /run/lock before any filesystems are mounted as well as after local and network mounts. This permits cleaning of directories which would otherwise be hidden by mountpoints later in the boot process. Closes: #55707, #558000, #666871. Additionally clean up /lib/init/rw in case any files were hidden by the (now removed) tmpfs mount at this location. Closes: #652625. - Removed last trace of the long-removed EDITMOTD from the postinst. Closes: #438895. - Removed documentation of #346342 in rcS(5). This is no longer an issue now tzdata keeps a copy of the data on the rootfs. Closes: #385172. - Correct description of TMPTIME in rcS(5). Thanks to Alan J. Greenberger. Closes: #562500. - urandom: Applied a series of patches from John Denker to improve the integrity of random number generation. Many thanks. Closes: #596479, #596480, #596481, #596482, #596483. * sysv-rc: - Remove old upgrade logic from maintainer scripts not required for wheezy. - Migrate users of obsolete static boot ordering to dynamic boot ordering. - Remove use of /etc/init.d/.legacy-bootordering. Closes: #668312. - Improve help text of debconf message when it is not possible to automatically enable dynamic boot ordering. Provide explicit instructions for how to purge obsolete init scripts. Closes: #550425. - etc/init.d/rc: Ensure linprocfs is mounted on kFreeBSD. Thanks to Robert Millan. Closes: #659480. - Drop undocumented CONCURRENCY setting from /etc/init.d/rc. Closes: #518249, #540448, #539261. Note that this still contains internal fallbacks to support non-insserv booting, which may be removed at a later date. - invoke-rc.d: + Minor manual page corrections. Thanks to Anthony
Re: The future of non-dependency-based boot
On Thu, Apr 19, 2012 at 09:01:55AM +0200, Petter Reinholdtsen wrote: [Roger Leigh] I can't see why not at first glance--it's done its job, so should no longer be needed. It is still needed in two use cases. 1) Machine upgraded from Lenny where the migration was not done. Either because it could not be done, or because the user choose not to do it. 2) Machines switching to/from file-rc. Sure, I can appreciate that we still need the upgrade logic. But, do we need the debconf question? Surely we can just migrate unconditionally (or attempt to, at least). (I don't know if you saw my mail regarding having done this provisionally in git; I mentioned it on the pkg-sysvinit-devel list and in #545976. I was wanting to additionally ask you how safe it would be to remove the is_unsafe_to_activate check and just run insserv anyway, and rely on insserv to fail if problems are found.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120419085407.ge28...@codelibre.net
Re: The future of non-dependency-based boot
On Thu, Apr 19, 2012 at 12:52:23PM +0200, Tollef Fog Heen wrote: ]] Roger Leigh (I don't know if you saw my mail regarding having done this provisionally in git; I mentioned it on the pkg-sysvinit-devel list and in #545976. I was wanting to additionally ask you how safe it would be to remove the is_unsafe_to_activate check and just run insserv anyway, and rely on insserv to fail if problems are found.) Not having sysv-rc complain when it can't wrap its head around the init scripts on the system would be very much appreciated. I'm kinda tired of it trying to convert my system on each upgrade and then failing. (And this machine has never even used sysvinit.) Could you provide examples please? If there are init scripts which it can't handle, that's a bug. Either in insserv or (more likely) the scripts. This has been partly discussed in #594917, but you haven't followed up there in response to the last comment. Based on this bug, I think it's perfectly reasonable for sysv-rc to manage the links; whether sysvinit is or is not running is not part of the question here, IMO. Given that systemd users are for the most part going to be users migrating from a sysvinit/sysv-rc/ insserv configuration, it's not unexpected that insserv will be managing the links. systemd should be able to cope with insserv managing the links shouldn't it? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120419132641.gf28...@codelibre.net
Re: The future of non-dependency-based boot
On Wed, Apr 18, 2012 at 07:15:48PM +0200, Philipp Kern wrote: On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote: Petter Reinholdtsen p...@hungry.com writes: [Sven Joachim] I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) Or seed the debconf value and override file for legacy bootordering before (c)debootstrap: [...] echo $F Name: sysv-rc/convert-legacy echo $F Template: sysv-rc/convert-legacy echo $F Value: false echo $F Owners: sysv-rc Given that skipping a release isn't supported and as this has been in squeeze, can it be dropped from sysv-rc, please? I can't see why not at first glance--it's done its job, so should no longer be needed. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120418173005.gc28...@codelibre.net
Bug#669108: general: assorted segfault
On Tue, Apr 17, 2012 at 01:06:10PM +0200, ygmarchi wrote: Package: general Severity: normal Hi there, I'm using debian testing. Lately I've been experiences frequent segfaults with eventual complete freeze. I attach evidence found in kern.log. Is there anybody out there who could guide me to collect further information to investigate the problem? Try memtest86 to see if it's memory corruption due to bad RAM. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120417120026.gn13...@codelibre.net
Re: Bug#668841: ITP: svipc -- System V InterProcess Communication for Python/Yorick
On Sat, Apr 14, 2012 at 10:16:53PM +0200, Thibaut Paumard wrote: Package: wnpp Severity: wishlist Owner: Thibaut Paumard paum...@users.sourceforge.net * Package name: svipc * URL : https://github.com/frigaut/yorick-svipc/ Given the rather generic package name, and the fact that upstream is already using yorick-svipc, wouldn't it be better to continue using yorick-svipc as the package name? The 3 packages expose SysV IPC functionalities to the corresponding interpreter: - shared memory; - semaphores; - message queues. Are the POSIX equivalents not supported already in Yorick and Python? While yorick-svipc is undoubtedly useful, it's also quite dated; the standard POSIX equivalents to the old SysV should really be preferred. FWIW, http://pypi.python.org/pypi/posix_ipc/0.8.1 Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120414203044.gf...@codelibre.net
Re: The future of non-dependency-based boot
On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. So do your boot scripts declare the correct dependency information in the LSB header? With dependency based boot, the numbers are meaningless other than for ordering. The fact that they change is to be expected. Are you running insserv to update the ordering? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120411102751.ga...@codelibre.net
Re: The future of non-dependency-based boot
On Wed, Apr 11, 2012 at 12:31:11AM +0200, Michael Biebl wrote: On 10.04.2012 22:44, Tollef Fog Heen wrote: ]] Adam Borowski Could sysv-rc show this output upon a failure to migrate? Knowing you need to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and /etc/init.d/stop-bootlogd would provide the user with straightforward info of what needs to be done. I think this should just be fixed in initscript instead. There's no good reason for it to not clean up after itself. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653050 Yep. Started looking at this over the weekend, it's a PITA though. Hopefully should be fixed in the next upload if I have time to thoroughly test it this week (but I need to write the helper function first given that this has apparently not been needed until now). Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120410223745.gz30...@codelibre.net
The future of non-dependency-based boot
Hi, When dependency-based booting was introduced, it was initially entirely optional. We later made it the default, and encouraged users to switch to dependency-based boot on upgrade. So today, pretty much everyone will be using dependency-based boot with there being a minority continuing to use the static boot ordering of yore. Probably mostly users who upgraded from etch. The reason for this mail is mainly to ask if there is any continuing need for the old static ordering to be kept, and if not, how best to migrate the remaining users. With all other init systems worth their salt requiring dependencies, should sysvinit not do the same? Now that all (?) init scripts provide LSB headers, the existing static ordering will increasingly bitrot. It was never that great to begin with, but with dependency ordering being used by the vast majority, it's going to be increasingly untested. Do we want to continue to maintain something that will be increasingly unsupportable, or complete the migration cleanly before that point? WRT actually doing this, the main issues I can see are - blocking by obsolete-but-unpurged init scripts without LSB header. We could mv them out of the way to .dpkg-old and continue, or abort and require manual intervention. - breakage of any non-LSB scripts remain after this. We could abort in the preinst and prevent upgrade until it's manually resolved, unless there's a cleaner way to handle it. Obviously, we don't want to make any systems unbootable, but doing it without any manual intervention where possible would be desirable. This can, of course, be left until wheezy+1. It's just something which needs considering before it becomes a bigger problem. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120409212638.gt30...@codelibre.net
Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?
On Thu, Mar 29, 2012 at 09:58:41PM +0200, Julien Cristau wrote: On Thu, Mar 29, 2012 at 19:10:05 +0100, Wookey wrote: Should a package depending on this behaviour build-dep on a particular dpkg version? As it already works in build-essential in stable do the same rules apply as essential packages in stable (i.e no explicit dependency required)? That would be consistent. Maybe it's been doing it since forever? A package may not depend on this behaviour. The interface to build a package is still debian/rules, not dpkg-buildpackage. While this might be the formal policy, isn't dpkg-buildpackage the /de-facto/ interface? AFAIK we don't actually test that building via debian/rules alone works, while we do test that building via dpkg-buildpackage works since this is what most packages build for upload, and all packages built on the autobuilders, use. Would there not be some advantage to making dpkg-buildpackge the interface for building? (Not dropping the debian/rules interface, of course.) This would permit the automatic setting of all the host- and build-related variables without requiring every package to also set them by hand. It would of course still be possible to build using debian/rules directly, but it wouldn't be required to set the flags. Without commenting on whether or not this is a good idea, isn't this basically the status quo already, given that most packages don't test direct usage of debian/rules, and manual setting of the various arch- and build-related variables is inconsistent? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120330130833.gj30...@codelibre.net
Re: On init in Debian
On Wed, Mar 21, 2012 at 10:49:09AM +0100, Martin Wuertele wrote: * Marco d'Itri m...@linux.it [2012-03-21 09:34]: On Mar 21, Svante Signell svante.sign...@telia.com wrote: And how do you expect non-experts be able to solve problems when they pop up. Buying consultant services from the experts? Non-experts are not able to solve any problem, so this is not an issue. But they can provide debugging info and some level of analyses that helps to triage the problems (and if it's a simple set -x in init scripts). This has been asserted quite a few times in the thread, and I think it's an oversimplification of the matter. We have: startpar initsystemd -- (lots of)(lots of) shell scripts unit files There's an important distinction between debugging a buggy service (be it a shell script or unit file) and a buggy init implementation (be it sysvinit/startpar or systemd or upstart). Debugging the core sysvinit or systemd code does require programming expertise, but it only needs doing once. Once it's tested and known to work well, the chance of a user running into problems with it is very small. We initially had problems when startpar was introduced: it was buggy in certain cases, and some init scripts had incorrect dependency information, resulting in boot problems. It's now well tested and works well. I'm sure the same will apply to systemd, but it will work very well once the initial teething problems are fixed. It's not common for users to run into major problems with an individual init script, but when they do, I don't agreee that it's easy to debug. init scripts are, by their very nature, full of horribly complex shell script, and understanding what everything does for a single service often requires initimate knowledge of how the service works. While it's possible to manually fix up a script to work by editing it, the reality is that only a few people have the expertise to do that. And the most important point, is that with unit files, you never need to do that: they are so simple, they should be obviously correct. The chance of there being a problem in the first place is vastly reduced. While it's true that if something goes wrong with systemd, diagnosing it and fixing it might be difficult, this is mainly due to our (collective) lack of experience with it rather than there being anything intrinsically more difficult about it. If anything, it promises to be vastly simpler and more robust than the spaghetti mess of shell we currently have to deal with. If there are corner cases where the boot hangs, that's simply something which needs finding and fixing. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120323104431.gc24...@codelibre.net
Re: upstart: please update to latest upstream version
On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote: Roger Leigh wrote: On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote: [note: it's somewhat desirable for them to be optional on Linux too, to prevent feature lock-in and future compatibility problems]. Unix kernel development outside Linux is pretty limited, especially development for features other than server use. I think avoid requiring Linux-specific features would turn into avoid technology developed after the 90s. This is missing the point. I'm not saying don't use Linux-specific features, I'm saying that use of Linux-specific features should be /optional/, even on Linux. Only use them if present. Let's take cgroups as an example. They are an optional feature even on Linux. As are several fundamental POSIX features. POSIX features, optional or not, are standard and will not change incompatibly. If not present, one would expect an ENOSYS error return and the code should cope with that eventuality. cgroups is both non-standard, changing rapidly, and does not have a guaranteed future. It's somewhat controversial even amongst kernel hackers. Relying on it is, to put it mildly, short-sighted. Portability to other systems is really just a special case of portability to future versions of the Linux kernel. Things can and will change, and systemd needs to make sure it doesn't break horribly when it happens. What's your problem scenario here? That kernel upstream suddenly decides it's OK to completely break systemd? I don't think it's that much more likely than them deciding to break POSIX functionality. If they want to tweak the APIs, then that can be coordinated with systemd without causing any catastrophic breakage. Even without Debian, the install base for systemd is already large enough to ensure that the kernel can't just ignore backwards compatibility. Excuse me, but what you're implying here is that systemd can dictate the development of kernel interfaces. Sorry, but that's too far. Can't you see the massive problem here? You are now preventing cgroups being removed from the kernel, and this has big implications for kernel development going forward. It's not exactly loved even now, and you're lumbering us with it indefinitely... Not a sensible attitude. We've already seen the effects of the close relationship between the kernel and udev. It has caused upgrade issues in the past, but at least at the moment has been manageable. Tight-coupling between components is almost always a bad idea. This has the potential to cause horrible issues during upgrades, when compatibility issues between systemd and kernel versions make upgrades either impossible, or cause massive breakage. One situation we never want to see is a system rendered unbootable as a result of a kernel/systemd incompatibility. By only using cgroups *if available at runtime*, you avoid the issue entirely by having a fallback *if not present*. Again, cgroups is just a single example, and the above applies equally to all Linux-specific non-standard interfaces. Enabling systemd to run on non-Linux architectures has the massive benefit of ensuring that it will also run on all Linux kernels as well. Using advanced features is fine, and appreciated. Mandating their use or failing to work in their absence is not. We do not want to require the kernel and systemd to be upgraded in lockstep. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120228165118.gq24...@codelibre.net
Re: upstart: please update to latest upstream version
On Fri, Feb 24, 2012 at 10:45:41AM +, Lars Wirzenius wrote: On Fri, Feb 24, 2012 at 10:51:23AM +0100, Svante Signell wrote: Then you are excluding all non-linux systems. Is that part of Debian policy? While at the time supporting non-linux systems (like kFreeBSD and Hurd, and others to come) It is an interesting question, that we should perhaps re-visit at this time: to what extent should the desire to support non-Linux kernels be allowed to hold back improvements in the GNU/Linux flavor of Debian? … Should we allow kFreeBSD and Hurd (and, possibly, other kernels in the future), which do not support the features required by systemd and upstart, allow us to get away from sysvinit and start using an event based init system? … The ideal solution would be for Hurd and kFreeBSD to add support for systemd and upstart, but I guess that's not so easy. It would, however, mean that the work would be done by the people who most benefit from it, rather than putting it on the people who probably never even use the other kernels. I certainly don't think it's fair for fairly niche platforms to hold back Linux indefinitely. There is a high cost on maintainers to support these platforms, and it would be an ideal situation if systemd or upstart were sufficiently portable to run on them, even if they didn't support all the Linux-specific features they offer [note: it's somewhat desirable for them to be optional on Linux too, to prevent feature lock-in and future compatibility problems]. There's nothing intrinsically non-portable about the systemd socket-based activation scheme. It's just all the cgroups and other stuff on top of that that's the problem. And the attitude of the upstream maintainer towards portability. Has anyone investigated exactly how hard it would be to port? If it's reasonably simple, we could just carry those patches in Debian. Another alternative is to let sysvinit run systemd units and/or upstart jobs. Given their declarative syntax, would it be possible for these to be translated into init script form so that they can be run by init? This would provide a migration path and permit packages to migrate away from providing init scripts in favour of systemd units (or upstart jobs), while permitting sysvinit use to continue. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120224114135.gi24...@codelibre.net
Re: upstart: please update to latest upstream version
On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote: Roger Leigh wrote: I certainly don't think it's fair for fairly niche platforms to hold back Linux indefinitely. There is a high cost on maintainers to support these platforms, and it would be an ideal situation if systemd or upstart were sufficiently portable to run on them, even if they didn't support all the Linux-specific features they offer Portability is not necessarily a positive attribute. When you're talking about standard functionality available on all platforms, it's cleaner to write it using standard interfaces that work everywhere. But if the platforms do not support the same things, then portability often requires platform-specific hacks, special cases and limitations. A systemd that tried to work on BSD kernel would be less reliable, less maintainable and harder to debug. I wouldn't want my Linux system to run an init process hacked for BSD portability. All our software has some element of portability hacks in it. Here's a trivial one from schroot: #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) (this-get_device()).is_character() #else (this-get_device()).is_block() #endif Disc devices are character on FreeBSD, rather than block. So we work around that fact. Big deal. Once that's done, it works perfectly on both platforms. Taking the stance that there must never, ever, be any platform- specific hacks is both extreme and counter-productive. If you want your software to be usable outside your own world, you have to make some compromises. [note: it's somewhat desirable for them to be optional on Linux too, to prevent feature lock-in and future compatibility problems]. Unix kernel development outside Linux is pretty limited, especially development for features other than server use. I think avoid requiring Linux-specific features would turn into avoid technology developed after the 90s. This is missing the point. I'm not saying don't use Linux-specific features, I'm saying that use of Linux-specific features should be /optional/, even on Linux. Only use them if present. Let's take cgroups as an example. They are an optional feature even on Linux. By mandating them systemd may be painting itself into a corner given that they might be removed or replaced with something better in the future. If they are present, by all means use the facility. But don't create the seed of a future maintenance nightmare. This doesn't just affect systemd, it affects the kernel indefinitely since we can't break working systems by removing the feature. This applies to all use of Linux-specific APIs: don't be too clever--it will come back to bite somewhere down the line. Asking this sort of question about systemd isn't stupid--there are long-term issues which could arise from short-sighted decisions by the systemd developers in the short-term. It would greatly ease its adoption if they would be given due consideration. And this includes portability to other systems just as much as it does to future versions of Linux. I would love Debian to adopt systemd (or an equivalent). But I really can't see that happening without a change in attitude by upstream. Portability to other systems is really just a special case of portability to future versions of the Linux kernel. Things can and will change, and systemd needs to make sure it doesn't break horribly when it happens. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120224212719.gj24...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Wed, Feb 22, 2012 at 10:14:49AM +0100, Tollef Fog Heen wrote: ]] Roger Leigh Just FYI, please see #659451. I've split the UTC variable into /etc/default/hwclock, which means /etc/default/rcS can become a regular dpkg conffile (in current git only for now). This needs support in d-i clock-setup (done) and util-linux (pending) before upload. I really wish we could just use /etc/adjtime instead, from hwclock(8): The format of the adjtime file is, in ASCII: [...] Line 3: UTC or LOCAL. Tells whether the Hardware Clock is set to Coordinated Universal Time or local time. You can always override this value with options on the hwclock command line. If you saw my mail of a couple of days ago, I have made patches for util-linux and clock-setup to enable this. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120222140103.gd24...@codelibre.net
Re: upstart: please update to latest upstream version
On Wed, Feb 22, 2012 at 02:58:50PM -0800, Russ Allbery wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: But I don't see the problem, Debian has the choice. We're not going to drop system V init anytime soon. Providing both systemd, upstart as well as classical system V init leaves the up to the user and allows to support non-Linux kernels. There's a serious drawback to supporting multiple init systems if one of the goals is to stop writing init scripts. The only common denominator is init scripts; upstart and systemd configuration files look entirely different, and would have to be maintained separately if we support both without using the init script compatibility support. Yes, there is absolutely a big cost to pay in supporting multiple init systems. Choice is good when there's a benefit, but we should not ignore the cost we pay. It would be good if we could generate init scripts from upstart and/or systemd service files, to permit migration to newer systems while still permitting the old system to be supported for the interim. It would IMO be more productive to port systemd and/or upstart to kFreeBSD/Hurd to make it possible to use the modern systems on all arches. The attitude of the systemd upstream is not encouraging here, however. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120223004715.gf24...@codelibre.net
Improving hwclock support in Debian (testing wanted)
Hi, The attached patch against current util-linux cleans up hwclock handling with the following changes: • There are currently two init scripts, hwclockfirst.sh and hwclock.sh. The reasons for these two originally existing (/etc/localtime not being present until after /usr was mounted AFAICT) no longer exist. I've removed hwclockfirst and adjusted the hwclock init script to run before checkroot. • Currently the setting for if the hardware clock is in UTC or local time is set with the UTC setting in /etc/default/rcS. However, this needlessly duplicates the /existing/ setting in hwclock's own configuration file (/etc/adjtime). This means hwclock's behaviour is overridden and its configuration overwritten *every shutdown*. This patch migrates the existing UTC= setting to UTC/LOCAL in /etc/adjtime. • The hwclock init scripts use the --utc and --localtime options (based on the UTC setting). This patch changes hwclock to use the value in /etc/adjtime. • The udev hwclock-set script now runs unconditionally in all cases using --tzset. (It's a no-op for UTC.) • If the user runs hwclock --systohc (--utc|--localtime) this is now handled correctly. The clock state is recorded in /etc/adjtime and correctly handled on restart. This means the UTC setting in /etc/default/rcS doesn't screw things up by requiring two separate changes to do the same thing. • systemd uses /etc/adjtime as for hwclock to store the hardware clock UTC/LOCAL configuration. This change means there's a single place to store the hardware clock configuration for all init systems. I've tested the patch on a powerpc system for a PST timezone using UTC and LOCAL options both with and without udev support (commented out the udev conditionals to test non-udev code). It would be great to have some testing on different hardware and setups with UTC or local time to make sure this covers all possible configurations without any regressions. There's an additional patch for d-i clock-setup to make this work for new installs as well (#660093). I'll file a bug with this patch against util-linux once this is properly tested. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 util-linux-hwclock-decruft.patch.bz2 Description: Binary data
Re: Improving hwclock support in Debian (testing wanted)
On Sat, Feb 18, 2012 at 03:59:23PM +, Roger Leigh wrote: Hi, The attached patch against current util-linux cleans up hwclock handling with the following changes: • Also adds /etc/default/hwclock and hwclock(5) which permit configuration without editing the initscript, and also documents all the undocumented knobs used by the scripts. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120218163428.gg26...@codelibre.net
Re: leaks in our only-signed-software fortress
On Sat, Feb 18, 2012 at 04:31:19PM +0100, Ansgar Burchardt wrote: Jakub Wilk jw...@debian.org writes: * Ansgar Burchardt ans...@debian.org, 2012-02-18, 14:14: Could you point us to those which were ignored or denied? At least pbuilder still disables secure APT by default, see #579028. The bug is closed. Am I missing something? pbuilder was changed to pass the --keyring argument to debootstrap by default and there now is an option to enable secure apt, but it is still disabled by default. This should be safe to enable now. We had problems enabling it in sbuild (in 2005) when tools first started supporting it for backward- compatibility reasons, but it's been the default for some time now (since July 2008) since everything we would want to build on supports it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120218174609.gi26...@codelibre.net
Re: Improving hwclock support in Debian (testing wanted)
On Sat, Feb 18, 2012 at 08:00:28PM +0100, Marco d'Itri wrote: On Feb 18, Roger Leigh rle...@codelibre.net wrote: • There are currently two init scripts, hwclockfirst.sh and hwclock.sh. The reasons for these two originally existing Why do you still bother with init scripts? With very good approximation, nowadays all systems which need hwclock (i.e. are not containers, chroots, etc) use udev: This updates both the init script and the udev hwclock script. Also, the init script is still needed to sync the clock on shutdown; AFAIK udev only triggers the hwclock on startup when the rtc device is registered. In addition to that, this ensures that it works uniformly on non-Linux- and non-udev-using systems. The (previously undocumented) configuration variables for both the init script and the udev script are now set in /etc/default/hwclock. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120218194040.gj26...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Tue, Jan 31, 2012 at 10:07:22PM +, Roger Leigh wrote: On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: Interesting timing. initscripts started depending on ucf just a few days ago, which makes ucf quasi-essential. Unless you are going to argue to add it to the essential set, I can't see why that matters. It's still wrong to use non-essential packages in postrm unconditionally. One could even argue that an essential package should not use ucf unconditionally and have a sane fall back when it's not available. Well, I would argue that packages in the essential set shouldn't be adding new dependencies without some discussion and review on debian-devel first. Hopefully we can remove the ucf dependency; please see #648433. Currently /etc/default/rcS is intentionally only installed once during a fresh install, and never updated afterward. However, this precludes ever updating it. Ideally we could make it a conffile and handle it entirely with dpkg; this would probably require splitting out the variables which should never be touched into a separate file under /etc/defaults. Just FYI, please see #659451. I've split the UTC variable into /etc/default/hwclock, which means /etc/default/rcS can become a regular dpkg conffile (in current git only for now). This needs support in d-i clock-setup (done) and util-linux (pending) before upload. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120213234531.ge8...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Thu, Feb 09, 2012 at 11:18:08PM +0100, Andreas Beckmann wrote: Roger Leigh wrote: On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: Interesting timing. initscripts started depending on ucf just a few days ago, which makes ucf quasi-essential. [...] Well, I would argue that packages in the essential set shouldn't be adding new dependencies without some discussion and review on debian-devel first. Hopefully we can remove the ucf dependency; please see #648433. Currently /etc/default/rcS is intentionally only installed once sysvinit is currently at 9/10 days and about to migrate to testing. If these two controversial changes (initscripts adding dependency on ucf (which becomes transitively-essential), updating rcS on upgrade) should not find their way into testing (in the current form), action should be taken now. I won't have time to do anything about it personally until the weekend. Not that this is IMO a massively urgent problem--we can remove the use of ucf any time. What I would like to know in order to fix the problem properly, is which variables in /etc/default/rcS can't ever be in a conffile, and which ones can. Because right now it's a mixture, and I'd like to separate them. If it's just UTC that's the problem, I think splitting it into e.g. /etc/default/hwclock would be the appropriate solution, then /etc/default/rcS could become a regular conffile and ucf can be dropped Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120210090804.gn8...@codelibre.net
Re: Use of the first person in messages from the computer
On Thu, Feb 09, 2012 at 01:40:42PM +0100, Niels Thykier wrote: On 2012-02-09 13:20, Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: [...] I suspect devref 6.5.2.5 is a (possible) source of this impression. As I recall, there are also some Lintian checks about using first person. The computer is not a person. IMO, the use of first-person personal pronouns such as I grate badly in the context of being used by the computer. By all means refer to the user this way (e.g. you), but I don't think Ian's opinion on the use of I is by any means universal. It's by no means wrong, but I think such uses could be phrased better. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120209132908.gm8...@codelibre.net
