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

[arch-dev-public] [signoff] kernel 2.6.32.8-1
by Tobias Powalowski 09 Feb '10

09 Feb '10

Hi guys, bump to latest bugfix version. Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] wpa_supplicant 0.6.10
by Thomas Bächler 09 Feb '10

09 Feb '10

Upstream update.

4 4

[arch-dev-public] [signoff] openvpn 2.1.1-1
by Thomas Bächler 09 Feb '10

09 Feb '10

Upstream update.

1 1

[arch-dev-public] [signoff] rfkill 0.4-1
by Thomas Bächler 09 Feb '10

09 Feb '10

Upstream update, please sign off.

2 2

Re: [arch-dev-public] root over NFS support
by Thomas Bächler 09 Feb '10

09 Feb '10

Am 08.02.2010 20:09, schrieb Simon Boulay: > Hi, (Note: I am CC'ing this to arch-dev-public. I will not resend the patches sent to me in the previous mail, you will see them when I apply them to the git. This is what happened so far: Simon stepped up and said he could implement NFS root for mkinitcpio. I pointed him to some patch on the bugtracker that someone made in the past and now he sent me patches that will make NFS support possible again) > Here is a patch which adds the support for mounting the root > filesystem over NFS. > ipconfig and nfsmount sources are attached. > I don't how to deal with them: > - make a package (like mkinitcpio-netutils) which download > official klibc and add patches to build against glibc > - make a sort of fork for those programs only and two packages > (mkinitcpi-ipconfig + mkinitcpio-nfsmount) > - ? I would put both programs in a small "mkinitcpio-nfs-utils" package or so. I guess it will be better to maintain them in a git repository instead of downloading klibc and applying patches all the time. > ipconfig and nfsmount have to be installed in /lib/initcpio. > I added a net hook based on the patch you pointed to me and modify > install/net and init accordingly. I don't have time to integrate them right now, because it is late and I can't proof-read them now. After applying your patch I will definitely change something about the logic: I was planning to provide a concept of "mount helpers" that allow you to override the default mounting procedure from inside a hook. This concept could be used for NFS root and for archiso. > Regards, > Simon. Thank you for the work, now I need to merge it and find testers. And then we can move to the release candidate stage and finally get rid of klibc once and for all.

1 0

[arch-dev-public] [PATCH 2/2] Fixed typo in man page
by Eric Bélanger 08 Feb '10

08 Feb '10

Signed-off-by: Eric Bélanger <snowmaniscool(a)gmail.com> --- mkinitcpio.5.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mkinitcpio.5.txt b/mkinitcpio.5.txt index 56e5eae..5a1c889 100644 --- a/mkinitcpio.5.txt +++ b/mkinitcpio.5.txt @@ -66,7 +66,7 @@ set up the udev device filesystem, load IDE modules, etc. About Presets ------------- -A preset is a pre-defined definition on how to create an initial ramdisk. Instead of specifying the configuration file and which output file, every time you generate a new intial ramdisk, you define a preset and use the -p switch to generate an initial ramdisk according to your preset. Presets are located in /etc/mkinitcpio.d +A preset is a pre-defined definition on how to create an initial ramdisk. Instead of specifying the configuration file and which output file, every time you generate a new initial ramdisk, you define a preset and use the -p switch to generate an initial ramdisk according to your preset. Presets are located in /etc/mkinitcpio.d Files ----- -- 1.6.6.1

2 2

[arch-dev-public] [PATCH] Fixed typo in comment
by Eric Bélanger 08 Feb '10

08 Feb '10

Signed-off-by: Eric Bélanger <snowmaniscool(a)gmail.com> --- mkinitcpio | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mkinitcpio b/mkinitcpio index 91dac25..999901d 100755 --- a/mkinitcpio +++ b/mkinitcpio @@ -8,7 +8,7 @@ # variables should be quoted and bracketed "${SOMEVAR}" # inline execution should be done with $() instead of backticks # use -z "${var}" to test for nulls/empty strings -# incase of embedded spaces, quote all path names and string comarpisons +# in case of embedded spaces, quote all path names and string comparisons # -- 1.6.6.1

1 0

[arch-dev-public] Fwd: Perl packaging guidelines.
by Aaron Griffin 07 Feb '10

07 Feb '10

Message below is trimmed, but the summary is: pacpan (CPAN wrapper for pacman packages) has been updated with gusto. There is a request to include using pacpan as part of the official guidelines for packaging perl apps for Arch. I think this is a good idea, but it leaves me wondering what we should do with the tool itself - should we be hosting it in the git repos? What do you guys think? ---------- Forwarded message ---------- From: Xyne <xyne(a)archlinux.ca> Date: Fri, Feb 5, 2010 at 6:18 AM Subject: Perl packaging guidelines. To: aaron(a)archlinux.org Hi Aaron, You're probably at least vaguely aware of a tool that I wrote a while ago named pacpan, which can autogenerate PKGBUILDs for CPAN packages. In the past worked well enough in most cases but there was room for improvement and I finally found the time to rewrite it recently. It is now a very useful tool for packaging CPAN distributions. I don't want to bore you with the details but it now does the following: *) correctly maps all modules to their distributions *) maps distributions to unique pacman pkgnames which follow the guidelines *) detects depends, makedepends, optdepends, and provides *) can detect missing provides for installed packages *) can update the local database provides while waiting for the packager to update it The provides are actually really important because many official packages do not list the packages that they provide and/or deviate from the standard naming conventions and this causes problems when trying to install other CPAN packages. Patching the local database works but it's an ugly hack. I've posted a thread on the forum to discuss changing the perl packaging guidelines to officially recommend using pacpan as a starting point for all CPAN packages. In most cases the PKGBUILD it generates should work out of the box. In those when it doesn't, it will still provide a comprehensive provides array and contain the correct name. This will improve the CPAN packaging situation by enabling full dependency resolution and by preventing conflicts from people effectively packaging the same packaging under different names and omitting the provides of those packages. ...snip... If I get some sort of official approval for this proposal, I will update the Perl packaging guidelines page in the wiki and begin to open tickets on the bug tracker to update/fix current CPAN packages which are incorrectly named and/or lack complete provides arrays.

4 5

[arch-dev-public] netcfg & away 8/2 to 15/2
by James Rayner 07 Feb '10

07 Feb '10

Hi all, Just letting you know I'm away for the next week. I'll move netcfg testing->core when I return so that I am about to offer support/explanation/docs. Thanks to those who have closed some of my bugs/updated my packages. I'm sorry that I can't spend more time around helping and keeping track of things. Life is busier than it was when I started working on Arch and the free time I used to spend on the computer has reduced and been taken by studies/work/other interests. So a big thanks to everyone :) See you in a week. James

1 0

[arch-dev-public] replacing syslog-ng with rsyslog
by Paul Mattal 06 Feb '10

06 Feb '10

All, There's been some compelling arguments made in the below bug request to switch from syslog-ng to rsyslog: http://bugs.archlinux.org/task/12314 I'm planning to start the process of migrating to rsyslog in March, if a rough show of hands here confirms it's the right thing to do. Can people give a quick +1 or -1 to this idea? - P

4 3