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

[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

[arch-dev-public] [signoff] openssh 5.3p1-1
by Thomas Bächler 12 Oct '09

12 Oct '09

New upstream release, please sign off.

5 5

[arch-dev-public] [signoff] popt 1.15-1
by Andrea Scarpino 12 Oct '09

12 Oct '09

Upstream release released 12-Apr-2009. Please signoff both arch -- Andrea `bash` Scarpino Arch Linux Developer

2 1

[arch-dev-public] texlive-bin binary doesn't match PKGBUILD
by Jan de Groot 12 Oct '09

12 Oct '09

Somehow the texlive-bin PKGBUILD doesn't provide the same binary package that is in the repository. I just committed a gnome-unstable directory with 3 patches that fixes build against poppler 0.12, but building it with makechrootpkg results in a lot of missing binaries. Also, I couldn't build texlive-bin without adding some force commands to ln and rm.

3 6

[arch-dev-public] gnome-unstable merged with core/extra (GNOME 2.28 released!)
by Jan de Groot 12 Oct '09

12 Oct '09

The merge of gnome-unstable with core/extra has been finished. Packages should be available on your mirror soon, which is the moment to remove the gnome-unstable repository from pacman.conf. The gnome-unstable repository will get removed tomorrow. Note that this release comes with a new version of policykit, which installs side by side with the old version. Any policy set in the previous version will not apply to the new version, and any GUI tools available for the old version will not apply policies to the new version. The use of ConsoleKit is advised to get full access to all features in this release.

1 0