November 2007 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] NFS 4 support request, opinions?
by Tobias Powalowski 09 Feb '08

09 Feb '08

Hi http://bugs.archlinux.org/task/8486 http://wiki.archlinux.org/index.php/NFSv4 required packages for core: http://aur.archlinux.org/packages.php?do_Details=1&ID=13630 http://aur.archlinux.org/packages.php?do_Details=1&ID=13625 http://aur.archlinux.org/packages.php?do_Details=1&ID=13629 nfs4-utils is not really needed it will be included in nfs-utils i think it would be a good idea to provide the users nfs4 support out of the box, i haven't used it but it seems reasonable to me. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 5

[arch-dev-public] [signoff] libdownload 1.3
by Aaron Griffin 03 Jan '08

03 Jan '08

Simple upgrade, with a few minor backend features, and removed the DEBUG flag from the build. If you upgrade and pacman can still download things, we're in business.

5 8

[arch-dev-public] ArchCon 2009, Take 2: Let's make a date
by Tom K 15 Dec '07

15 Dec '07

And we're back. :) Here's how I see this working: 1. We agree a date 2. We agree a location 3 and upwards. We organise some stuff This mail is about step 1. ArchCon's date is the single most important element to be confirmed, and probably the hardest as well. I suggested 2009 in the original proposal because it's likely that some people already have plans for 2008. Obviously, there are also people who already have plans for 2009, but probably not as many. If we're going to do this, we should regard ArchCon as a pre-existing commitment that is given priority over other activities, and not something that we try to squeeze into existing schedules. To kick this off, I'm making some provisional decisions here: * ArchCon will take place over a weekend * ArchCon will last no more than four days * ArchCon will take place in warm weather (Yes, I know, that's a date/location mix, but necessary for the next step) (James - see below) And now here are five randomly-chosen corresponding weekend periods in 2009: 29 May - 01 June 26 - 29 June 24 - 27 July 21 - 24 August 18 - 21 September I would ask everyone to indicate which of these periods would suit them. Please select as many as possible, to increase our chances of finding a good one, and set aside any other concerns, such as funding, travel arrangements, size of mugs, etc. If we don't come up with a date, none of that will matter anyway. If anyone has a particularly strong case for a different weekend that meets the same criteria, please post the details. I realise that individual weekends may be too specific at this stage, but I'm going for a shortcut here - it would be worthwhile if we didn't have to drill down from month to week to weekend. So fire up cal/remind/Google/Oprius/whatever, pencil in some weekends for ArchCon, and post them here. I'd appreciate a majority of responses before the next Status Report, which is due in just over a week. If we can get the date confirmed before Christmas, that would be great. James - I am also aware that my warm weather requirement, combined with my chosen dates, indicates a preference for the Northern Hemisphere, but our geographical distribution suggests that anyway, right? Regards Tom.

10 14

[arch-dev-public] [signoff] shadow 4.0.18.2-2
by Tom K 13 Dec '07

13 Dec '07

Fix for md5sum problem caused by $Id: line in login.defs. As before, I would be grateful if someone could do a x86_64 build. T.

5 6

[arch-dev-public] [patch] remove netcfg from initscripts
by James Rayner 13 Dec '07

13 Dec '07

http://src.iphitus.org/netcfg-release/initscripts-netcfg2.diff Removes netcfg2 from the current initscripts. And... there's one slight problem in moving netcfg2 in. Unless we make initscripts depend on netcfg2, people will upgrade their initscripts and have no netcfg2 at all. Any better way of dealing with this? Let me know when you put initscripts with the above patch into the repo, and I'll update netcfg2 accordingly. If the patch is OK'ed, I can do it. James

4 11

[arch-dev-public] [PATCH] Add boot probing hooks
by Simo Leone 12 Dec '07

12 Dec '07

Initscripts now export their state to an arbitrary boot logging/probing program. This opens up the possibility for advanced boot profiling, among other interesting uses. --- functions | 17 +++++++++++++++++ rc.conf | 1 - rc.multi | 6 ++++++ rc.shutdown | 2 ++ rc.sysinit | 10 ++++++++++ 5 files changed, 35 insertions(+), 1 deletions(-) diff --git a/functions b/functions index 8b5ecf1..ebde3ca 100644 --- a/functions +++ b/functions @@ -3,6 +3,19 @@ # functions # +# source boot monitoring functions and settings +if [ -x "${BOOT_PROBE}" ]; then + source /etc/`basename ${BOOT_PROBE}`.conf &>/dev/null + source /etc/rc.d/`basename ${BOOT_PROBE}`-functions + emit_state() { + ${BOOT_PROBE} $@ + } +else + emit_state() { + : + } +fi + # width: STAT_COL=$(stty size) @@ -81,6 +94,7 @@ stat_bkgd() { echo -ne "$C_OTHER$PREFIX_REG $C_MAIN$1$C_CLEAR " deltext echo -ne " $C_OTHER[${C_BKGD}BKGD$C_OTHER]$C_CLEAR " + emit_state bkgd } stat_busy() { @@ -88,6 +102,7 @@ stat_busy() { echo -ne "${SAVE_POSITION}" deltext echo -ne " $C_OTHER[${C_BUSY}BUSY$C_OTHER]$C_CLEAR " + emit_state busy } stat_append() { @@ -99,11 +114,13 @@ stat_append() { stat_done() { deltext echo -e " $C_OTHER[${C_DONE}DONE$C_OTHER]$C_CLEAR " + emit_state done } stat_fail() { deltext echo -e " $C_OTHER[${C_FAIL}FAIL$C_OTHER]$C_CLEAR " + emit_state fail } stat_die() { diff --git a/rc.conf b/rc.conf index 43a597e..167b65f 100644 --- a/rc.conf +++ b/rc.conf @@ -89,5 +89,4 @@ ROUTES=(!gateway) # DAEMONS=(syslog-ng network netfs crond) - # End of file diff --git a/rc.multi b/rc.multi index 8050e98..5c4a3b3 100755 --- a/rc.multi +++ b/rc.multi @@ -6,6 +6,8 @@ . /etc/rc.conf . /etc/rc.d/functions +emit_state multi_startup + # Load sysctl variables if sysctl.conf is present [ -r /etc/sysctl.conf ] && /sbin/sysctl -q -p &>/dev/null @@ -14,9 +16,11 @@ for daemon in "${DAEMONS[@]}"; do if [ "$daemon" = "${daemon#!}" ]; then if [ "$daemon" = "${daemon#@}" ]; then /etc/rc.d/$daemon start + emit_state multi_progress else stat_bkgd "Starting ${daemon:1}" (/etc/rc.d/${daemon:1} start) &>/dev/null & + emit_state multi_progress_bkgd fi fi done @@ -25,4 +29,6 @@ if [ -x /etc/rc.local ]; then /etc/rc.local fi +emit_state exit + # vim: set ts=2 noet: diff --git a/rc.shutdown b/rc.shutdown index 19cb00f..a1771a8 100755 --- a/rc.shutdown +++ b/rc.shutdown @@ -6,6 +6,8 @@ . /etc/rc.conf . /etc/rc.d/functions +emit_state shutdown + # avoid staircase effect /bin/stty onlcr diff --git a/rc.sysinit b/rc.sysinit index f4729bf..6559f3f 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -6,6 +6,8 @@ . /etc/rc.conf . /etc/rc.d/functions +emit_state boot + echo " " printhl "Arch Linux $C_OTHER(${C_H2}Core Dump$C_OTHER)\n" printhl "${C_H2}http://www.archlinux.org" @@ -88,6 +90,9 @@ if [ -d /sys/class/net/lo ]; then fi fi +# tell probing programs to get ready +emit_state init + # If using an encrypted root fs, we should find the root dev in the initrd # FIXME: obsoleted by initramfs and udev if [ -e /initrd/dev/mapper/root ]; then @@ -232,6 +237,8 @@ if [ -x /sbin/fsck ]; then fsckret=$? if [ ${fsckret} -gt 1 ]; then stat_fail + # oh crap. tell probers not to hide anything. + emit_state verbose if [ $((${fsckret}&2)) -eq 2 ]; then echo echo "********************** REBOOT REQUIRED *********************" @@ -399,5 +406,8 @@ fi # Screen blanks after 15 minutes idle time /usr/bin/setterm -blank 15 +# set things up for probing in rc.multi +emit_state multi + # End of file # vim: set ts=2 noet: -- 1.5.3.4

6 11

[arch-dev-public] [signoff] madwifi/madwifi-utils svn version 2978
by Tobias Powalowski 05 Dec '07

05 Dec '07

Hi http://bbs.archlinux.org/viewtopic.php?id=40261 according to this thread the normal madwifi tarball has some issues. which is fixed with svn version, please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 3

[arch-dev-public] [signoff] shadow 4.0.18.2-1
by Tom K 03 Dec '07

03 Dec '07

New upstream shadow release, plus fixes for FS#8050/8051/8724/8742, and general PKGBUILD tidy-up. I would be grateful if someone could build and upload this for x86_64. Please note that this signoff request supercedes Dan's, posted a couple of days ago: http://archlinux.org/pipermail/arch-dev-public/2007-November/003430.html Regards T.

5 7

[arch-dev-public] license for sqlite3
by Andreas Radke 03 Dec '07

03 Dec '07

http://www.sqlite.org/copyright.html so far we used "custom" and installed the included license file. now this file has been removed from the source. what should i do now(no file/use old file/create a txt file with a link to the license url)? -Andy

8 11

[arch-dev-public] Questionable apps in core/support
by Aaron Griffin 03 Dec '07

03 Dec '07

I just came across a couple of things in core/support that seemed odd to me, and wanted to ask you guys what you thought: support was intended to be apps which "help out" or "support" the rest of core - like when installing and things like that. a) screen While this is an important app, sure, does it belong in core? b) hdparm and sdparm I don't see how these work in "support" - as the very least I'd put them at the same mental level as acpi and pm-utils c) openswan/openvpn/vpnc I'm on the fence here. I mean, I could see VPN connections being needed at some point during an install or something of the sort, but at the same time, why do we have 3 VPN apps there? Anyone want to clarify or give me your opinions here?

6 8