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

[arch-dev-public] [PATCH 1/4] Moved ALLOWED_LICENSES declaration to config file
by Eric B�langer 14 Oct '09

14 Oct '09

Signed-off-by: Eric B�langer <snowmaniscool(a)gmail.com> --- config | 3 +++ misc-scripts/make-sourceball | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/config b/config index 86a5eca..24ec37a 100644 --- a/config +++ b/config @@ -13,3 +13,6 @@ BUILDSCRIPT="PKGBUILD" DBEXT=".db.tar.gz" PKGEXT=".pkg.tar.gz" SRCEXT=".src.tar.gz" + +# Allowed licenses: get sourceballs only for licenses in this array +ALLOWED_LICENSES=('GPL' 'GPL1' 'GPL2' 'LGPL' 'LGPL1' 'LGPL2') diff --git a/misc-scripts/make-sourceball b/misc-scripts/make-sourceball index 865e0e7..462549f 100755 --- a/misc-scripts/make-sourceball +++ b/misc-scripts/make-sourceball @@ -1,8 +1,5 @@ #!/bin/bash -# Allowed licenses: build only for licenses in this array -ALLOWED_LICENSES=('GPL' 'GPL1' 'GPL2' 'LGPL' 'LGPL1' 'LGPL2') - if [ $# -ne 3 -a $# -ne 4 ]; then echo "usage: $(basename $0) [-f] <packagename> <repo> <arch>" echo " -f Force building. Skip license checks" -- 1.6.5

3 5

[arch-dev-public] [signoff] kernel26-lts 2.6.27.37-1
by Andreas Radke 14 Oct '09

14 Oct '09

new upstream release. removed depricated CONFIG_USB_DEVICE_CLASS by suggestion from udev upstream maintainers, #16561. please signoff. -Andy

2 1

[arch-dev-public] [patch] devtools/makechrootpkg: move determination of unique install files inside loop
by Ronald van Haren 14 Oct '09

14 Oct '09

Hey guys, Can we move the determination of unique .install files inside the loop (see patch below). A few weeks ago I had troubles building koffice, now I had the time to look into it. It appears that due the vast number of splitted packages the install_files variable grew so large it was still not finished adding variables after 12 hours. Determining the uniqueness of the .install files inside the loop this doesn't happen anymore and it now finishes in a couple of seconds. I imagine this is also a problem with other splitted packages (most notably some kde ones?) Ronald path below is against current git version. --- /usr/sbin/makechrootpkg.old 2009-10-13 10:08:02.297306265 +0200 +++ /usr/sbin/makechrootpkg 2009-10-13 10:08:32.237724312 +0200 @@ -182,10 +182,9 @@ for pkg in ${pkgname[@]}; do install_files+=' ' install_files+=$(echo $install_files |sed "s/\$pkgname/$pkg/"|sed "s/\${pkgname}/$pkg/") + install_files=$(eval echo $install_files |tr '[:blank:]' '\n'|sort |uniq) done -install_files=$(eval echo $install_files |tr '[:blank:]' '\n'|sort |uniq) - for f in $install_files;do install="${f#"install="}" if [ "$install" != "" -a -f "$install" ]; then

2 1

[arch-dev-public] commits ML for community repo
by Eric Bélanger 14 Oct '09

14 Oct '09

Hi, Could one of the admins setup a ML for the commits of the community andcommunity-testing repos? Several people including myself would find it useful as we already have one for core/extra/testing. Thanks, Eric

8 20

[arch-dev-public] [signoff] kernel26 2.6.31.4-1
by Thomas Bächler 13 Oct '09

13 Oct '09

Just a few random upstream fixes, please sign off. x86_64 is tested and available in testing i686 is still building, it will be there in about an hour, I won't write a separate message about it.

4 3

[arch-dev-public] [signoff] iptables 1.4.5
by Ronald van Haren 13 Oct '09

13 Oct '09

new upstream release, please signoff for both architectures. Ronald

3 3

[arch-dev-public] [signoff] dhcpcd 5.1.1-1
by Ronald van Haren 13 Oct '09

13 Oct '09

In testing for both architectures, please signoff. Changes: - new upstream release Ronald

3 3

Re: [arch-dev-public] [PATCH 0/7] Namcap performance improvements
by Dan McGee 13 Oct '09

13 Oct '09

On Sun, Sep 27, 2009 at 11:16 PM, Dan McGee <dan(a)archlinux.org> wrote: > In the spirit of Eli making a bunch of patches for the AUR, I finally decided > to sit down tonight and figure out why the heck namcap was sucking it up, and > did a little code cleanup along the way. namcap.py is now a bit cleaner and > separated into functions, and the real treat is namcap is a hell of a lot > faster now that I found the bottleneck, which was the depends hook. The first 6 > patches in this series lead up to the 7th, which is where the speed increase is > found. > > Let me know what you see, otherwise it would be cool to get this in and a new > namcap release made, as it has rather dramatic effects with regards to speed. > > If you don't like patches, you can get all this from my git tree as well: > http://code.toofishes.net/cgit/dan/namcap.git/log/?h=working > > -Dan > > Dan McGee (7): > Rename 'tags' to 'namcap-tags' > Only process tags if necessary > Move extracted variable to the correct scope > Only do active_modules check once > Move PKGBUILD processing to a function > Move real package processing to a function > Make the depends module not suck > > Namcap/depends.py | 104 +++++++++++++++++++------------- > README | 10 ++-- > namcap-tags | 65 ++++++++++++++++++++ > namcap.py | 173 +++++++++++++++++++++++++++-------------------------- > setup.py | 2 +- > tags | 65 -------------------- > tests/tags-check | 4 +- > 7 files changed, 224 insertions(+), 199 deletions(-) > create mode 100644 namcap-tags > delete mode 100644 tags Pinging the namcap maintainer? -Dan

4 3

[arch-dev-public] progsreiserfs cause warnings when running aclocal
by Roman Kyrylych 12 Oct '09

12 Oct '09

I get this: $ aclocal --dry-run /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Not sure if this is important enough to warrant opening a bug for it - seems to be upstream issue anyway, and does not affect the result of aclocal when using it in a PKGBUILD (didn't try building anything related to progsreiserfs though). This just makes makepkg output for some packages (namely kbd & klibc-kbd) not that pretty, :-P -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] About the vim packages (Opinions needed)
by Tobias Kieslich 12 Oct '09

12 Oct '09

Hi @all, as most of you know, the (g)vi* packages are a constant subject to suggestions and proposed changes be they stupid or valid. I just like to have some input on two major issues and if we shall pursue them or not: Only vim and gvim are concerne since vi is an entirely different beast now. Here is how the packages are split up: vim: - perl scripting support, since it's small and produces minor overhead - provides runtime files - is mainly intended for command line use where vi is not sufficient gvim: - python (and later again ruby) scripting support for addon scripts - provides X support, vim server support, gtk frontend if invoked with gvim symlink - intended for serious development, I think it's a reasonable assumption that people who do that do not wanna have 80x24 consoles but will have X installed and with X there is a huge likely hood that gtk2 is installed Now, I think that gives a nice and very clear distinction between vim (mainly for console user) and gvim (for developers, but also people who run the vim command in the terminal). Note that after installing the gvim package, the vim command invokes a more powerful, python and X enabled binary. I am getting feature requests, to put it nicely, about enabling python in vim. I'm opposed to that for two reasons: - upon the return of ruby people will pester me about ruby support becuase python is in there and why not ruby .. whine .. blah - I think there is a clear distinction between vim for the console and vim for serious development, and the current layout shows that nicely The arguments about including python are mainly like that: But when I am on this server, or on this very small box, too small to run X and I wanna develop in python etc. I don't think these are valid arguments because they are rare cases. And if it's really true, you can always build a custom python enable smaller vim. Which brings me directly to the second point, the building system. Vim follows a patch based approach which makes the PKGBUILD a fair bit complex. All thes seemed to be fine for the last year but now people seriously pester me that it would be better to build it from cvs/svn and the patch based approach is not good enough anymore because the rebuilds take too long becuase the download takes soooo long. The cvs approach however has a few gotchas IMHO: - first of all I think that's a non issue, becuase Arch is binary based and rebuilding is not really necessary - cvs/svn is behind the patches in vim world - if you rebuild, you rebuild more often, which is supported by the central srccache - I clean up my PKGBUILD directories before rebuilding, I never clean my SRCCACHE so overall I don't benefit from the cvs at all So what I wanna know is, 1. Do we wann have python enabled in vim package (don't forget: as soon as you install the gvim package, you have python in vim and don't use the vim-package binary anymore) 2. Do we wanna have a cvs enabled buildsystem just because upon an initial rebuild the download is faster (It would annoy the hell out of me because as package maintainer I would have to dowload everything everytime) So, I like (g)vim the way it is but I don't wanna be the benevolent I would be okay with 1) if everyone agrees, I know quite few developer use vim. I'm strongly opposed to 2) because it just causes more work and we do have a perfectly usable build system in place. -T

4 7