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

[arch-dev-public] Integrity Check i686: core, extra, community 18-06-2010
by repomaint＠archlinux.org 18 Jun '10

18 Jun '10

================================================ = Integrity Check i686 of core,extra,community = ================================================ Performing integrity checks... ==> parsing pkgbuilds ==> parsing db files ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking hierarchy ==> checking for circular dependencies ==> checking for differences between db files and pkgbuilds Missing Dependencies ---------------------- community/airsnort --> 'wlan-ng26-utils' community/sysprof-module --> 'kernel26<2.6.' core/tiacx --> 'kernel26>=2.6.34' extra/archboot --> 'vim>=7.2.385-1' extra/archboot --> 'xz-utils>=4.999.9beta-2' Missing Makedepends --------------------- community/xmobar --> 'haskell-parsec>=3.1.0' core/tiacx --> 'kernel26-headers>=2.6.34' extra/v86d --> 'kernel26<2.6.33' Repo Hierarchy for Dependencies --------------------------------- extra/pan depends on community/gmime22 (0 extra (make)deps to pull) Repo Hierarchy for Makedepends -------------------------------- core/ca-certificates depends on extra/python (25 extra (make)deps to pull) core/ca-certificates depends on extra/ruby (25 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (26 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/groff depends on extra/ghostscript (137 extra (make)deps to pull) core/groff depends on extra/netpbm (45 extra (make)deps to pull) core/groff depends on extra/psutils (138 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (26 extra (make)deps to pull) core/iputils depends on extra/libxslt (25 extra (make)deps to pull) core/iputils depends on extra/opensp (30 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gobject-introspection (39 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (25 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (39 extra (make)deps to pull) core/udev-compat depends on extra/gperf (0 extra (make)deps to pull) core/udev-compat depends on extra/libxslt (25 extra (make)deps to pull) extra/bigloo depends on community/jdk (1 extra (make)deps to pull : jre) extra/dbus-python depends on community/docutils (0 extra (make)deps to pull) extra/gnome-speech depends on community/espeak (2 extra (make)deps to pull : portaudio docutils) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/midori depends on community/docutils (0 extra (make)deps to pull) extra/opengtl depends on community/llvm (0 extra (make)deps to pull) extra/vigra depends on community/python-sphinx (3 extra (make)deps to pull : pygments docutils python-jinja) extra/xqf depends on community/chrpath (0 extra (make)deps to pull) Packages found in db, but not in tree --------------------------------------- community/ctpl extra/koffice-l10n-fr Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 8 Repo hierarchy problems: 26 Circular dependencies: 0 In db, but not in tree: 2 In tree, but not in db: 0

1 0

[arch-dev-public] kernel 2.6.34-1
by Tobias Powalowski 17 Jun '10

17 Jun '10

Hi guys, kernel 2.6.34 first test run ... Upstream changes: http://kernelnewbies.org/LinuxChanges Arch Linux bugfixes/feature requests: # added manpages and documents as separate package http://bugs.archlinux.org/task/17892 Arch Linux changes: - nouveau module moved into kernel tree, all nvidia binary packages include now a blacklist_nouveau.conf file, to avoid loading of nouveau module, instead of nvidia module. Broken binary modules: - fcpci,fcpcmcia,slmodem though no fix available yet. Enjoy have fun and give me feedback, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 6

[arch-dev-public] [signoff] pacman 3.4.0-1
by Dan McGee 17 Jun '10

17 Jun '10

Upstream release, please signoff. -Dan

3 2

[arch-dev-public] Out-of-date packages in [extra]/[community]
by Andrea Scarpino 16 Jun '10

16 Jun '10

Hi DEVs/TUs, these packages are out-of-date from time and needed by none. Can I move them on AUR? I will wait 2 days because I do not know many of them, maybe someone is useful. Please TUs, let me know if you want to maintain any of these packages in [community]. [extra] - biopython - gcin - glabels - linux_logo - nss_ldap - pam_ldap - prelink - pylint - python-cheetah - python-formencode - python-sqlobject (needed by pacbuild, but does pacbuild still work?!) - python-gdata (needed by pytube in [community]) - python-vpython [community] - live-f1 - sauerbraten -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux

2 1

Re: [arch-dev-public] [arch-general] Xorg-server 1.8 - when?
by Jan de Groot 16 Jun '10

16 Jun '10

On Wed, 2010-06-16 at 09:14 +0200, Lukáš Jirkovský wrote: > Hello, > I'd like to ask what are the plans for the xorg-server 1.8, especially > now when RC1 of xorg-server 1.9 is out. Please don't get me wrong, I'm > not demanding anything but I'm wondering what is holding back the move > to [extra]. > > I'm using new xorg-server on two different computers (notebook with > intel and desktop with nvidia's blob) for some time without any > problems. Though xorg-server 1.8 is not completely issue-free, I don't think 1.7 from extra isn't issue-free either. I've been running these packages for months now without much problems. Before we start moving xorg-server 1.8, I would like to know when we can move kernel26. The latest kernel has a lot of fixes for Intel and ATI/AMD DRM. Do we have really important open bugs for 2.6.34, or are we just waiting for the magic .1 release?

3 3

[arch-dev-public] [PATCH 1/4] Handle error case of parsepkgbuild correctly
by Dan McGee 16 Jun '10

16 Jun '10

We were never checking the return code of parsepkgbuild so would try to parse the error message it printed out as a package definition rather than erroring and returning None. Look at the return code, and as a bonus, use the more correct communicate() rather than stdout.read(). Signed-off-by: Dan McGee <dan(a)archlinux.org> --- pacman.py | 7 +++++-- parsepkgbuild | 6 +++--- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/pacman.py b/pacman.py index 1f78be2..f8edaab 100644 --- a/pacman.py +++ b/pacman.py @@ -105,8 +105,11 @@ def load(package, root=None): workingdir = None filename = os.path.basename(package) process = subprocess.Popen(['parsepkgbuild',filename], stdout=subprocess.PIPE, cwd=workingdir) - data = process.stdout.read() - ret = loaddb(None, data) + data = process.communicate() + # this means parsepkgbuild returned an error, so we are not valid + if process.returncode > 0: + return None + ret = loaddb(None, data[0]) # Add a nice little .pkgbuild surprise pkgbuild = open(package) diff --git a/parsepkgbuild b/parsepkgbuild index f9b5a91..d8bcc98 100755 --- a/parsepkgbuild +++ b/parsepkgbuild @@ -9,9 +9,9 @@ export PATH=/tmp/parsepkgbuild; exec /bin/bash --noprofile --norc -r << EOF source $1 -# ensure $pkgname and $pkgver variables were found -if [ -z "\$pkgname" -o -z "\$pkgver" ]; then - echo " error: invalid package file" +# ensure $pkgname, $pkgver, and $pkgrel variables were found +if [ -z "\$pkgname" -o -z "\$pkgver" -o -z "\$pkgrel" ]; then + echo "error: invalid package file" exit 1 fi -- 1.7.1

3 8

[arch-dev-public] dropping flashplugin x86_64
by Ionuț Bîru 15 Jun '10

15 Jun '10

Hi, the current x86_64 version of flashplugin has security problems and adobe dropped/temporally closed x86_64 releases. How do we manage this situation? Only dropping from repo? Should we submit an empty package? Suggest our users to remove their package if they consider security important? -- Ionuț

3 3

[arch-dev-public] [PATCH] Detect more usages of $startdir
by Allan McRae 15 Jun '10

15 Jun '10

The detection of $startdir usage ignored any potential brackets or quotes. Now the following are all detected: $startdir ${startdir} "$startdir" "${startdir}" Signed-off-by: Allan McRae <allan(a)archlinux.org> --- Namcap/invalidstartdir.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Namcap/invalidstartdir.py b/Namcap/invalidstartdir.py index f323b76..720e5cd 100644 --- a/Namcap/invalidstartdir.py +++ b/Namcap/invalidstartdir.py @@ -29,7 +29,7 @@ class package: def analyze(self, pkginfo, tar): ret = [[], [], []] for i in pkginfo.pkgbuild: - startdirs = re.split('\$startdir', i) + startdirs = re.split('\${?startdir}?"?', i) for j in startdirs[1:]: if j[:4] != '/pkg' and j[:4] != '/src': ret[0].append(("file-referred-in-startdir", ())) -- 1.7.1

2 1

[arch-dev-public] [signoff] pcmciautils-017-1
by Tobias Powalowski 15 Jun '10

15 Jun '10

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

2 2

[arch-dev-public] Namcap 2.6 in [testing]
by Dan McGee 15 Jun '10

15 Jun '10

Hopefully it works for everyone! Changes since 2.5 from the NEWS file: $ head NEWS namcap (2.6) - Add new 'anyelf' rule; should catch ELF files that end up in 'any' arch packages and cannot be arch-independent - Allow checking of all checksum types (FS#17168) - Code style and import cleanups - Handle optdepends descriptions correctly (FS#18259) - Make it an error to use $startdir in PKGBUILDs -Dan

2 1