[arch-dev-public] [signoff] initscripts-2011.04.1-1
Hi guys, A new initscripts package is in testing, please test and signoff. Some changes that might potentially cause problems: * We no longer call mdadm, as this is dealt with by udev * We no longer copy rule files from /dev/.udev on boot, as this is dealt with by udev * We no longer run depmod on boot, as this should be done by the respective packages, and is anyway done to late to make a difference on boot * We dropped several very old workarounds for bugs in other packages * We make hwclock drift adjustment into a daemon (defaults to enabled on fresh installs), as it causes more problems than it solves (especially if using dual-boot or ntp) * We have a new maintainer Other changes worth noting: * got a helperscript, rc, that allows to start/stop and list daemons * default to RTC being in UTC, strongly discourage localtime * support FakeRAID (dmraid) * support btrfs * support /run (and use it where relevant) * support forcefsck as a kernel parameter * allow the verbosity level to be configured in rc.conf * various cleanups all around Thanks to everyone who contributed to this release! Andrea Scarpino (1): Use dhcpcd -k instead of kill Dan McGee (1): Remove MOD_BLACKLIST from rc.conf Dave Reisner (5): PKGBUILD: remove unnecessary depends whitespace cleanup use bash's kill builtin instead of /bin/kill network: cleanup variable declarations rc.sysinit: condense calls to rm Eric Bélanger (1): Added missing else clause in set_consolefont function Kurt J. Bosch (2): Make hwclock --adjust as well as --systohc optional (FS#13684) Change hardware clock default to UTC Sebastien Luttringer (7): fix syntax error from 71a1b74eb778540d412705b09a24f1d2ba123a2b Move /var/run/daemons to /run/daemons mdadm: disable SoftRAID detection Fix console verbosity and add config via rc.conf Fix incomplete daemon detection in have_daemon Add an rc helper Fix and clean forcefsk detection Seblu (9): Allow forcefsck on kernel cmdline to have same effect as touching /forcefsck Improve encrypted filesystem detection Remove grep use where a simple env var check can be made Implement FakeRAID detection at startup Software RAID detection is now triggered via USEMDADM config var like fakeraid and lvm Add davfs to the list of network filesystems in netfs Add UDEV_TIMEOUT option Add BTRFS support in initscripts Allow loading of multiple keymaps when LOCALE is UTF-8 Tom Gundersen (13): udev: do not automatically save persistent net/cd udev rules to /etc on boot Merge branch 'hwclock-from-kurt' into arch-master status: synchronise the status message Revert "udevadm: retry failed udev events after filesystems have been mounted" hotplug: properly clear the path to hotplug/uevent_helper mtab: don't write to mtab if it is a symlink workaround: do not rmmod psmouse workaround: do not unset NIS on shutdown workaround: do not set property=STARTUP=1 when calling udevadm dev: create pts and shm directories depmod: no longer update module dependencies on boot /run: mount /run if it is not already mounted Add utmp group support
On Thu, Apr 21, 2011 at 12:10 PM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
A new initscripts package is in testing, please test and signoff.
Some changes that might potentially cause problems:
* We no longer call mdadm, as this is dealt with by udev * We no longer copy rule files from /dev/.udev on boot, as this is dealt with by udev
Do we know what versions we are dealing with here? E.g. udev >= ?, kernel version >= ?. It might be appropriate for a udev versioned dep to be used here since udev/initscripts/mkinitcpio/kernel/etc. packages are often held back on things like VPS installs. -Dan
On Thu, Apr 21, 2011 at 7:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Apr 21, 2011 at 12:10 PM, Tom Gundersen <teg@jklm.no> wrote:
* We no longer call mdadm, as this is dealt with by udev
The relevant rule file is shipped with mdadm and has been for a long time (2008). The rule file gained support for IMSM arrays in mdadm version 3.2, so it might be best to use a relatively up-to-date mdadm. Can we assume that people are not holding back mdadm and upgrading initscripts?
* We no longer copy rule files from /dev/.udev on boot, as this is dealt with by udev
Handling of persistent net/cd links has been in udev for a long time (the exact udev version escapes me at the moment). However, as a general rule I would be in favor of forcing an up-to-date udev. (In this particular case the problem was the opposite: the newest udev broke our persistent rule handling). The only package I have assumed might be anything but the most recent is the kernel. Would anyone object to making this the official policy for initscript, as I don't think we have the manpower to support other combination of packages? If no one objects, I'll put a note about this in the release notes. Cheers, Tom
On Thu, Apr 21, 2011 at 1:03 PM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Apr 21, 2011 at 7:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Apr 21, 2011 at 12:10 PM, Tom Gundersen <teg@jklm.no> wrote:
* We no longer call mdadm, as this is dealt with by udev
The relevant rule file is shipped with mdadm and has been for a long time (2008). The rule file gained support for IMSM arrays in mdadm version 3.2, so it might be best to use a relatively up-to-date mdadm. Can we assume that people are not holding back mdadm and upgrading initscripts? One would think so, and 2008 is in fact quite old so probably not something to fret about. (Note: our binaries require a kernel >= 2.6.27 anyway, which was released in late 2008).
* We no longer copy rule files from /dev/.udev on boot, as this is dealt with by udev
Handling of persistent net/cd links has been in udev for a long time (the exact udev version escapes me at the moment). However, as a general rule I would be in favor of forcing an up-to-date udev. (In this particular case the problem was the opposite: the newest udev broke our persistent rule handling).
The only package I have assumed might be anything but the most recent is the kernel. Would anyone object to making this the official policy for initscript, as I don't think we have the manpower to support other combination of packages? If no one objects, I'll put a note about this in the release notes.
+1 from me. Noting in the release notes that "this version of initscripts requires udev >= xxx" seems appropriate. However, enforcing policy via provided mechanisms (versioned depends) is a good thing as far as I can see. -Dan
On Thu, Apr 21, 2011 at 8:19 PM, Dan McGee <dpmcgee@gmail.com> wrote:
+1 from me. Noting in the release notes that "this version of initscripts requires udev >= xxx" seems appropriate. However, enforcing policy via provided mechanisms (versioned depends) is a good thing as far as I can see.
I'll make a new package depending on the newest udev. I'll wait a bit before pushing it out in case there are other comments. -t
On Thu, Apr 21, 2011 at 1:36 PM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Apr 21, 2011 at 8:19 PM, Dan McGee <dpmcgee@gmail.com> wrote:
+1 from me. Noting in the release notes that "this version of initscripts requires udev >= xxx" seems appropriate. However, enforcing policy via provided mechanisms (versioned depends) is a good thing as far as I can see.
I'll make a new package depending on the newest udev. I'll wait a bit before pushing it out in case there are other comments.
And you need to fix this too- not sure if someone gave you the right permissions to put files there yet. ==> SIZE initscripts-2011.04.1.tar.xz ... done. ==> PASV ... done. ==> RETR initscripts-2011.04.1.tar.xz ... No such file “initscripts-2011.04.1.tar.xz”. ==> ERROR: Failure while downloading initscripts-2011.04.1.tar.xz Aborting... -Dan
On 04/21/2011 09:49 PM, Dan McGee wrote:
On Thu, Apr 21, 2011 at 1:36 PM, Tom Gundersen<teg@jklm.no> wrote:
On Thu, Apr 21, 2011 at 8:19 PM, Dan McGee<dpmcgee@gmail.com> wrote:
+1 from me. Noting in the release notes that "this version of initscripts requires udev>= xxx" seems appropriate. However, enforcing policy via provided mechanisms (versioned depends) is a good thing as far as I can see.
I'll make a new package depending on the newest udev. I'll wait a bit before pushing it out in case there are other comments.
And you need to fix this too- not sure if someone gave you the right permissions to put files there yet.
==> SIZE initscripts-2011.04.1.tar.xz ... done. ==> PASV ... done. ==> RETR initscripts-2011.04.1.tar.xz ... No such file “initscripts-2011.04.1.tar.xz”.
==> ERROR: Failure while downloading initscripts-2011.04.1.tar.xz Aborting...
-Dan
he cannot even commit in svn or push packages to repos. I did that for him but i don't have permission to copy the tarball in the right directory since is owned by thomas. I did pinged you couples of minutes ago to ask you to do it. -- Ionuț
On 22/04/11 04:03, Tom Gundersen wrote:
The only package I have assumed might be anything but the most recent is the kernel. Would anyone object to making this the official policy for initscript, as I don't think we have the manpower to support other combination of packages? If no one objects, I'll put a note about this in the release notes.
That seems fine to me. We are supposed to be bleeding edge. As far as kernels go, glibc only supports up to 2.6.27, so long as the lts kernel is still supported you should be fine. Allan
participants (4)
-
Allan McRae
-
Dan McGee
-
Ionut Biru
-
Tom Gundersen