- Arch-projects - lists.archlinux.org

[arch-projects] [initscripts][RFC] deprecating TIMEZONE from rc.conf
by Tom Gundersen 17 May '11

17 May '11

Hi guys, I think the TIMEZONE variable in rc.conf is unnecessary and it causes some problems with other (especially GUI) tools. I'd like to hear what you think about deprecating it. We will still keep the support for it in initscripts, but we will suggest (in the standard rc.conf) to not set it. It will then be up to the maintainer of our installer(s) and documentation to adopt (or not) this suggestion. I cc'ed the GNOME/KDE/XFCE maintainers as I would be interested to hear if their timezone tools work well with rc.conf (I think not, but I might have missed something). I also cc'ed aif and archboot maintainers. Please forward if you know of anyone who maintains relevant packages that I left out. Cheers, Tom >From fd5fd34f8a593710483a204d7a7984f89385e3fa Mon Sep 17 00:00:00 2001 From: Tom Gundersen <teg(a)jklm.no> Date: Mon, 16 May 2011 13:17:48 +0200 Subject: [PATCH] timezone: deprecate the TIMEZONE variable Setting the TIMEZONE in rc.conf is a bad idea for several reasons: * it requires a reboot before taking effect, for people changing timezone's frequently (this is common if you travel a lot, especially annoying if you have several stop overs in different timezones and want your laptop's clock to be correct) * it is non-standard, so advice/guides that apply to other distro's will not apply to arch * it is non-standard, so gui tools like the ones found in KDE/GNOME will not be aware of the setting in rc.conf, and whatever change they do will be overwritten on next boot. * it is one of the few remaining blockers for ro /etc support in initscripts For these reasons (and possibly more), we deprecate TIMEZONE from rc.conf, and advice users and developers to clear it and set /etc/localtime directly. However, we do not remove the implementation from the scripts, so the timezone is still set during boot/shutdown if the variable is set. Signed-off-by: Tom Gundersen <teg(a)jklm.no> --- rc.conf | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/rc.conf b/rc.conf index 89ea27e..0fb6472 100644 --- a/rc.conf +++ b/rc.conf @@ -8,11 +8,13 @@ # # LOCALE: available languages can be listed with the 'locale -a' command # DAEMON_LOCALE: If set to 'yes', use $LOCALE as the locale during daemon # startup and during the boot process. If set to 'no', the C locale is used. # HARDWARECLOCK: set to "UTC" or "localtime", any other value will result # in the hardware clock being left untouched (useful for virtualization) # Note: Using "localtime" is discouraged. -# TIMEZONE: timezones are found in /usr/share/zoneinfo +# TIMEZONE: (DEPRECATED) copy timezone from /usr/share/zoneinfo to +# /etc/localtime instead # KEYMAP: keymaps are found in /usr/share/kbd/keymaps # CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US) # CONSOLEMAP: found in /usr/share/kbd/consoletrans @@ -22,7 +24,6 @@ LOCALE="en_US.UTF-8" DAEMON_LOCALE="no" HARDWARECLOCK="UTC" -TIMEZONE="Canada/Pacific" KEYMAP="us" CONSOLEFONT= CONSOLEMAP= -- 1.7.5.1

7 17

[arch-projects] [devtools] [PATCH] commitpkg: add -a option to upload only one arch
by Florian Pritz 16 May '11

16 May '11

-a i686 uploads only i686 packages and ignore everything else Signed-off-by: Florian Pritz <bluewind(a)server-speed.net> --- commitpkg | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/commitpkg b/commitpkg index 916bdfc..ea9468a 100755 --- a/commitpkg +++ b/commitpkg @@ -54,7 +54,7 @@ pkgbase=${pkgbase:-$pkgname} case "$cmd" in commitpkg) if [ $# -eq 0 ]; then - abort 'usage: commitpkg <reponame> [-l limit] [commit message]' + abort 'usage: commitpkg <reponame> [-l limit] [-a arch] [commit message]' fi repo="$1" shift @@ -63,7 +63,7 @@ case "$cmd" in repo="${cmd%pkg}" ;; *) - abort 'usage: commitpkg <reponame> [-l limit] [commit message]' + abort 'usage: commitpkg <reponame> [-l limit] [-a arch] [commit message]' ;; esac @@ -103,6 +103,11 @@ if [ "$1" = '-l' ]; then shift 2 fi +if [ "$1" = "-a" ]; then + commit_arch=$2 + shift 2 +fi + echo -n 'committing changes to trunk...' if [ -n "$1" ]; then svn commit -q -m "upgpkg: $pkgbase $pkgver-$pkgrel @@ -115,6 +120,11 @@ echo 'done' declare -a uploads for _arch in ${arch[@]}; do + if [ "${_arch}" != "$commit_arch" ]; then + echo "skipping ${_arch}" + continue + fi + for _pkgname in ${pkgname[@]}; do fullver=$(get_full_version ${epoch:-0} $pkgver $pkgrel) pkgfile=$(getpkgfile "$_pkgname-$fullver-${_arch}".pkg.tar.?z 2>/dev/null) -- 1.7.5.1

1 2

[arch-projects] [PATCH] Change pacman calls with -Sd flags to -Sdd
by Jakob Gruber 16 May '11

16 May '11

The old pacman -d flag is now -dd since commit 111e07d0be44b7. Signed-off-by: Jakob Gruber <jakob.gruber(a)gmail.com> --- checkpkg | 2 +- mkarchroot | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/checkpkg b/checkpkg index e669718..01c921e 100755 --- a/checkpkg +++ b/checkpkg @@ -47,7 +47,7 @@ for _pkgname in ${pkgname[@]}; do exit 1 fi - tmp=`pacman -Spd --noconfirm $_pkgname` + tmp=`pacman -Spdd --noconfirm $_pkgname` if [ $? -ne 0 ]; then echo "Couldn't download previous package for $_pkgname." diff --git a/mkarchroot b/mkarchroot index f385731..5b6be88 100755 --- a/mkarchroot +++ b/mkarchroot @@ -73,7 +73,7 @@ if [ -z "$cache_dir" ]; then fi if [ -f /etc/pacman.d/mirrorlist ]; then - host_mirror=$(pacman -Sdp extra/devtools 2>/dev/null | sed -E 's#(.*/)extra/os/.*#\1$repo/os/$arch#') + host_mirror=$(pacman -Sddp extra/devtools 2>/dev/null | sed -E 's#(.*/)extra/os/.*#\1$repo/os/$arch#') fi if [ -z "${host_mirror}" ]; then host_mirror='http://mirrors.kernel.org/archlinux/$repo/os/$arch' -- 1.7.5.1

3 3

[arch-projects] [PATCH] [mkinitcpio] Don't print success/failure result on same line
by Dan McGee 15 May '11

15 May '11

Doing the `echo -n` call causes the shell to line-buffer the output anyway, meaning one doesn't see the first part until 'SUCCESS' or 'FAILURE' is printed. This means the last message on the screen is 'Generating module dependencies' when in fact we are actually generating the image, which can take a lot of time when XZ, etc. are used. Print the status on two lines, ensuring buffering is not causing problems with out output. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- mkinitcpio | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mkinitcpio b/mkinitcpio index 31145d0..0ebf7c9 100755 --- a/mkinitcpio +++ b/mkinitcpio @@ -282,14 +282,14 @@ fi status=0 if [ -n "${GENIMG}" ]; then - echo -n ":: Generating image '${GENIMG}'..." + echo ":: Generating image '${GENIMG}'" shopt -s -o pipefail [ ${COMPRESSION} = "xz" ] && COMPRESSION_OPTIONS="${COMPRESSION_OPTIONS} --check=crc32" if ! /sbin/gen_init_cpio ${FILELIST} | ${COMPRESSION} ${COMPRESSION_OPTIONS} > "${GENIMG}"; then - echo "FAILED" + echo ":: Image generation FAILED" status=1 else - echo "SUCCESS" + echo ":: Image generation successful" status=0 fi -- 1.7.5.1

1 0

Re: [arch-projects] [udev][RFC][2/5] moving static nodes to udev-compat
by Tom Gundersen 15 May '11

15 May '11

On Sun, May 15, 2011 at 12:31 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > I was under the impression that some of these nodes are needed for > udev to start working. At least, back in the day, I know that console, > null, and zero needed to be created before udev started. If this is no > longer true, then I see no issues with making them go away. Unless > they're needed in early userspace before udev starts... but mkinitcpio > could always create those nodes. They used to be needed. However, with devtmpfs they are not. The essential ones (for early userspace) exist by default and the rest are created when udev is started. A quick test: delete /lib/udev/devices from your machine and notice that everything still works. A more thorough test: move /lib/udev/devices to /lib/udev/devcise.old (say) and reboot with init=/bin/bash (it would be best to do this with a self-compiled kernel that can boot without a initramfs to make sure nothing touches /dev at all). Now compare the contents of /dev with /lib/udev/devices.old. Cheers, Tom

2 2

[arch-projects] [udev][RFC][5/5] remove custom rules to workaround old bugs
by Tom Gundersen 14 May '11

14 May '11

In 81-arch.rules we have a section that loads modules that cannot be auto detected. I think this is the wrong thing to do. If the kernel cannot auto detect it, then we probably are not going to be any better at it. Also, some of these rules might cause unwanted problems on systems that do not need the modules. E.g., the snd-{seq,pcm}-oss modules are known to cause problems with PulseAudio (and as PA is getting more and more common and OSS is getting more and more uncommon, I think it is clear that we are doing the wrong thing here). In general, I think all the modules of this section are exactly what rc.conf's MODULES array is for, so I suggest removing it. It might make sense to keep a wikipage dedicated to modules that cannot be autoloaded (cpufreq also comes to mind) and then add a note in udev.install pointing there. The relevant rules are below. Thoughts? Cheers, Tom ##################################### ###### Hotplug rules - begin # Only additional modules, # which are not detectable, # are loaded here! ##################################### # check if the device has already been claimed by a driver ACTION!="add", GOTO="drivers_end" # SOUND addon modules SUBSYSTEM=="sound", RUN+="/lib/udev/load-modules.sh snd-pcm-oss" SUBSYSTEM=="sound", RUN+="/lib/udev/load-modules.sh snd-seq-oss" #PNP addon modules SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNP0800", RUN+="/lib/udev/load-modules.sh pcspkr" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="*PNP051[01]*", RUN+="/lib/udev/load-modules.sh irtty-sir" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f", RUN+="/lib/udev/load-modules.sh analog" # PARPORT addon modules SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNP040*", RUN+="/lib/udev/load-modules.sh lp" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNP040*", RUN+="/lib/udev/load-modules.sh ppdev" # fix ide cdrom detection on old proliant servers SUBSYSTEM=="pci", ENV{MODALIAS}=="pci:v00000E11d00000001sv00000000sd00000000bc06sc02i00", RUN+="/lib/udev/load-modules.sh ide-generic"

1 0

[arch-projects] [udev][RFC][4/5] removing module-load.sh
by Tom Gundersen 14 May '11

14 May '11

Hi guys, There has already been some discussion about this on the mailinglist, so I will just give a short summary here. At the moment, we have patches against initscripts that will create a blacklist file in /etc/modprobe.d/ (technically it is symlinked to a file on /run, but that is not important) at boot, based on the MODULES array in rc.conf. We still need to decide on exactly what to do with mkinitcpio that might want to have similar functionality. With this functionality added to initscripts it means that whatever modules were blacklisted in rc.conf at boot will not be autoloaded. This is the main functionality of modules-load.conf, and is as close to the intended upstream functionality we can get without breaking compatibility with rc.conf. Some functionality of load-modules.sh will be lost. However, I think it for the better (the closer we are to upstream the less weird bugs we will encounter). That said, if there are good reasons to implement any of these features I think it is doable. It should be noted that some of these things make a lot more sense in mkinitcpio than in initscripts, so if we drop these things from initscripts it does not mean we have to drop them from mkinitcpio. 1) You have to reboot between adding a module to rc.conf and it being blacklisted. If this is a problem for you, then use the method intended by upstream and add your blacklisted modules directly to /etc/modprobe.d/. I don't think we can avoid this problem. 2) MOD_AUTOLOAD will no longer work. This functionality is not upstream (correct me if I'm wrong!) and I find it hard to believe it is useful. As a boot parameter to fix a problem with the initrd it might be useful (though probably not in its current form, but that is another discussion), but I would like to remove it from rc.conf. If there is a use case for this, then we should follow whatever the other distros are doing and possibly help get this into udev.conf. 3) Can not blacklist modules on the kernel command line. Again, this is something that might be useful to get a working mkinitcpio so one can boot into a shell and fix one's system (if you know how to edit your grub command line then you should be able to set "init=/bin/bash"), but I don't think this is useful to blacklist modules from the real system. This _could_ easily be added, but I believe the correct place for this (if it is deemed useful) would be upstream. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][3/5] deprecate persistent-{net-cd}.rules
by Tom Gundersen 14 May '11

14 May '11

I'd like to remove the following deprecated functionality from initscripts/udev. The issue: If you have several networking devices or cd-rom's they might get their names swapped around on reboot. This is of course annoying. The old solution: udev ships with a rule file to automatically generate a persistent rule file in /etc every time it sees a new network device or cd-rom. The problems: /etc might not always be writable (in particular it is not during early boot when devices are typically probed), for this we have a workaround/hack in initscripts that will copy temporarily stored rule files to /etc when /etc becomes available. these days things like usb modems pretend to be cdroms so one might have potentially a lot of nonsense rules generated the functionality is basically deprecated upstream, i.e., they intend to rip it out as soon as someone has written a nice tool to replace it. For all intents and purposes it is dead. The correct solution: The user should not enable the auto generation rules, but rather create his/her own rules in the cases where they really want it. This is the same amount of manual intervention as enabling the rules, with none of the drawback. The correct procedure is excellently described here: <https://wiki.archlinux.org/index.php/Udev#Mixed_Up_Devices.2C_Sound.2FNetwo…> (the method referred to as the "udev-sanctioned" one). The situation in Arch: The auto generation rules are shipped, but patched to be disabled by default, the needed support is still in initscripts. My suggestion: We announce the deprecation and point users to the correct solution (maybe we fix up the relevant wiki pages a bit). After a not too long time we stop shipping the autogeneration rules, i.e., we pass --disable-rule_generator to configure in the udev package, and remove the support from initscripts. What this will mean for the end user: On an existing system where the rules are enabled and no new devices are added: nothing. On an existing system where the rules are enabled and a new device is added: the new devices will not get an auto generated persistent rule and an error will be logged. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][2/5] moving static nodes to udev-compat
by Tom Gundersen 14 May '11

14 May '11

In further simplifying our udev package I'd like to move all our static dev nodes (the contents of /lib/udev/devices) from udev to udev-compat. The reason for this is that it is not needed with a devtmpfs kernel, such as kernel26{,-lts}. In other words these static nodes are only useful for self-compiled kernels without devtmpfs support. The affected users are those who are using non-devtmpfs kernels without udev-compat, who should on the next upgrade install udev-compat. If we agree to do this I suggest an announcement to the news page in good time before the change and a note in udev.install. Thoughts? Cheers, Tom

1 0

[arch-projects] [udev][RFC][1/5] remove cdsymlinks.sh
by Tom Gundersen 14 May '11

14 May '11

The first thing I want to address is cdsymlinks.sh and the corresponding rules in 80-drivers.rules. As far as I understand the aim of this functionality is to create sensible symlinks to cdrom devices in /dev. Similar functionality is already provided by 60-cdrom_id.rules upstream, though it might differ slightly (from the git log, this rules file has had bugfixes that probably would apply to our rules too). I am inclined to simply remove our functionality and rely entirely on the upstream one. If there are use cases that we cover that upstream do not (I'm not aware of any), then I would be happy to take the lead on pushing the required patches upstream. This might cause some functional change to our users, but as far as I can tell a renamed cdrom symlink should not be the end of the world. Clearly, an announcement about this change must be made. >From what I have been told this was mostly relevant with the old standard fstab entries for cdroms. However, those have been removed a long time ago. Thoughts? Cheers, Tom

1 0