- Aur-general - lists.archlinux.org

[aur-general] Integrity Check community i686 27-03-2009
by repomaint＠archlinux.org 27 Mar '09

27 Mar '09

===================================== = Integrity Check i686 of community = ===================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Missing PKGBUILDs ------------------- /srv/abs/rsync/i686//community/CVS /srv/abs/rsync/i686//community/daemons/CVS /srv/abs/rsync/i686//community/devel/CVS /srv/abs/rsync/i686//community/editors/CVS /srv/abs/rsync/i686//community/emulators/CVS /srv/abs/rsync/i686//community/games/CVS /srv/abs/rsync/i686//community/gnome/CVS /srv/abs/rsync/i686//community/i18n/CVS /srv/abs/rsync/i686//community/kde/CVS /srv/abs/rsync/i686//community/lib/CVS /srv/abs/rsync/i686//community/modules/CVS /srv/abs/rsync/i686//community/multimedia/CVS /srv/abs/rsync/i686//community/multimedia/libflashsupport-oss/CVS /srv/abs/rsync/i686//community/network/CVS /srv/abs/rsync/i686//community/office/CVS /srv/abs/rsync/i686//community/science/CVS /srv/abs/rsync/i686//community/system/CVS /srv/abs/rsync/i686//community/x11/CVS /srv/abs/rsync/i686//community/xfce/CVS Missing Dependencies ---------------------- flumotion --> 'twisted-web' open-vm-tools-modules --> 'kernel26<2.6.28' eclipse-ve --> 'eclipse<3.3' cdfs --> 'kernel26<2.6.28' virtualbox-ose-additions-modules --> 'kernel26<2.6.28' Missing Makedepends --------------------- splix --> 'jbigkit' Summary --------- Missing PKGBUILDs: 19 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 6 Repo hierarchy problems: 0 Circular dependencies: 0

2 1

[aur-general] Arch's Vim Failings & Solution Suggestions
by Andrei Thorp 27 Mar '09

27 Mar '09

Hello, fellow Archers. Recently, I had a question about Vim, so I went to the #vim channel in IRC. I was doing something that should be working, but it wasn't. Surprisingly, the question came up, "Are you on Arch?" Turns out that several of the peolpe I most respect in the #vim IRC channel are very unhappy with the quality of Arch's Vim package. One even (jokingly?) asked if they could officially not support Arch in the channel, which I found somewhat alarming. I suggested that we should instead help improve the Arch package. I hate to pick on people, but according to the generally kind folks on IRC, the Vim package for Arch has quite a few issues, and the maintainer hasn't addressed some outstanding bugs in quite a long while. As some of you may know, James Vega (jamessan) is an outstanding Vim user and the Debian package maintainer for Vim. I asked him to send me what he saw as the problems with the Arch package, and he was kind enough to send along some suggestions. They are attached in this forward. Thank you, -Andrei Thorp ---------- Forwarded message ---------- From: James Vega <jamessan(a)debian.org> Date: Thu, Mar 19, 2009 at 2:29 AM Subject: Arch's Vim failings To: garoth(a)gmail.com Andrei, Thanks for being receptive to trying to address the issues in Arch's Vim packaging. Below are the major points that stand out. 1) gvim package: Shipping an /etc/gvimrc which, due to the order that Vim loads rc files, overrides any settings in the user's ~/.vimrc. Considering that some users make the conscious decision to keep all their settings in their ~/.vimrc instead of using both ~/.vimrc and ~/.gvimrc, this is at the very least annoying. More in depth discussion is contained in the nearly year old, unfixed bug[0] about this issue. 2) vi package: The package is built such that the resulting vi binary reads its config from the completely non-standard ~/.virc. Presumably this is to allow different configurations for the different feature-sets avaiable in vi vs. vim packages. Fortunately, Vim has methods to deal with this already such as being able to check what name was used to invoke Vim[1] and explicitly checking for feature support[2]. 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME == $VIM by specifying "--with-global-runtime=/usr/share/vim" to configure. This doesn't need to be specified to configure as it will be set to the correct directory on its own. If they insist on specifying it, the directory should be /usr/share/vim/vimXY (where XY is Vim's version number -- 72 for current Vim). This manifests various problems, the most noticeable being that the 'runtimepath' option in Vim has /usr/share/vim listed twice, thus causing runtime files to be sourced twice and causing duplicate information when using common scripting methods for discovering files in the runtimepath[3]. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan(a)debian.org> [0] - http://bugs.archlinux.org/task/10303 [1] - if v:progname == 'vi' [2] - if has('cscope') [3] - globpath(&rtp, 'colors/*') -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX =HJf3 -----END PGP SIGNATURE-----

6 14

[aur-general] Integrity Check community x86_64 27-03-2009
by repomaint＠archlinux.org 27 Mar '09

27 Mar '09

======================================= = Integrity Check x86_64 of community = ======================================= Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Missing PKGBUILDs ------------------- /srv/abs/rsync/x86_64//community/CVS /srv/abs/rsync/x86_64//community/daemons/CVS /srv/abs/rsync/x86_64//community/devel/CVS /srv/abs/rsync/x86_64//community/editors/CVS /srv/abs/rsync/x86_64//community/emulators/CVS /srv/abs/rsync/x86_64//community/games/CVS /srv/abs/rsync/x86_64//community/gnome/CVS /srv/abs/rsync/x86_64//community/i18n/CVS /srv/abs/rsync/x86_64//community/kde/CVS /srv/abs/rsync/x86_64//community/lib/CVS /srv/abs/rsync/x86_64//community/lib32/CVS /srv/abs/rsync/x86_64//community/modules/CVS /srv/abs/rsync/x86_64//community/multimedia/CVS /srv/abs/rsync/x86_64//community/network/CVS /srv/abs/rsync/x86_64//community/office/CVS /srv/abs/rsync/x86_64//community/science/CVS /srv/abs/rsync/x86_64//community/system/CVS /srv/abs/rsync/x86_64//community/x11/CVS /srv/abs/rsync/x86_64//community/xfce/CVS Missing Dependencies ---------------------- eclipse-ve --> 'eclipse<3.3' flumotion --> 'twisted-web' gg2 --> 'arts' perl-ldap --> 'perl-xml-sax-writer' thunderbird-spell-pl --> 'thunderbird=2.0.0.19' cdfs --> 'kernel26<2.6.28' Missing Makedepends --------------------- splix --> 'jbigkit' Summary --------- Missing PKGBUILDs: 19 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 7 Repo hierarchy problems: 0 Circular dependencies: 0

1 0

[aur-general] Quick Access Plasmoid appears more than once in AUR
by Bram Schoenmakers 27 Mar '09

27 Mar '09

Hello, The Quick Access Plasmoid appears more than once in AUR. [1] is orphaned but has more votes. [2] still has a maintainer. So I would suggest to remove [1] from AUR. Kind regards, [1] http://aur.archlinux.org/packages.php?ID=18854 [2] http://aur.archlinux.org/packages.php?ID=18893 -- Bram Schoenmakers What is mind? No matter. What is matter? Never mind. (Punch, 1855)

2 1

[aur-general] package removal/orphaning request: rubberband
by hollunder＠gmx.at 26 Mar '09

26 Mar '09

Please orphan or remove this package, I'd be willing to take over but the author of the PKGBUILD can have it back if he wants to. http://aur.archlinux.org/packages.php?ID=15349 For the following reasons: -Wrong homepage link -some minor things inside the PKGBUILD -out of date since a few weeks and most importantly: -source isn't downloaded from the authors website and the downloaded tarball is significantly larger than the original one: rubberband-1.2.tar.bz 298627 rubberband-1.2-arch.tar.bz2 2739510 I won't attempt to see what the difference is, either way it's just wrong to download a modified tarball from a third party website, especially with an active project. Best regards Philipp

2 3

[aur-general] Package deletion
by Arkham 26 Mar '09

26 Mar '09

Could someone please delete http://aur.archlinux.org/packages.php?ID=24988 ? I uploaded it by mistake ;)

2 1

[aur-general] Please delete a package
by José Valecillos 25 Mar '09

25 Mar '09

I commited a mistake uploading one of my packages, then the xammp-linux package is a error. Can you delete please -- José Valecillos

3 3

[aur-general] Package disown request (omniorbpy)
by tsa＠gmx.eu 25 Mar '09

25 Mar '09

Hi! The package omniorbpy (ID 7457) is quite old and there seems to be no maintenance since some time... Is it possible to "disown" the package? I would like to submit omniorbpy-3.3... Greetings, Tobias

2 2

[aur-general] Bad PKBUILD and out of date package
by José Valecillos 25 Mar '09

25 Mar '09

Greetings! The joyutils package in the aur seems to be out of date and not updated for a long while. On the other hand, that PKGBUILD have a binary file, this isn't even allowed. Can you orphand it? -- José Valecillos

2 1

[aur-general] Redirection of package
by Cilyan Olowen 24 Mar '09

24 Mar '09

I was wondering if it is possible to redirect one package to another, and if it was possible in unsupported. For example, python bindings for poppler are currently, but probably will stay like this, a bazaar repository. The fact is, as it is the official way of obtaining the software, the package should be python-poppler. But, as it is a bzr, it should be python-poppler-bzr too and so will beneficiate the makepkg functionality to update to the last repository version. Another package needs the bindings, but as it is the functionnality that are needed and not a particular way of obtention, I think it is better to request python-poppler. So, for the requirement to be installed automatically, it is better for the package to be named python-poppler. Finally, it could be great if the package python-poppler was redirected to python-poppler-bzr. And if a stable packaged version of the software arise, the two packages could be dissociated transparently. Is it possible ? Cilyan

4 5