- Aur-general - lists.archlinux.org

[aur-general] Delete request
by Stefan Husmann 07 Apr '13

07 Apr '13

Hello, please remove https://aur.archlinux.org/packages/conkeror-refactor-completions-git/ It pulls from a branch, but AFAIK pacman 4.1 cannot handle that. Best Regards Stefan

2 2

[aur-general] pacman 4.1 (makepkg 4.1) bazaar pkgver autobump problem
by Stefan Husmann 07 Apr '13

07 Apr '13

Hello, I have problems to find a good solution for a bazaar based PKGBUILD to do an autobump of pkgver. I use this PKGBUILD # Maintainer: Stefan Husmann <stefan-husmann(a)t-online.de> # based on a PKGBUILD of Mathias Nedrebø <mathias <at> nedrebo.org> pkgname=emacs-xwidget-bzr pkgver=101273 pkgrel=1 arch=('i686' 'x86_64') pkgdesc="Emacs, bazaar-version from the xwidget branch" url="http://www.gnu.org/software/emacs/emacs.html" license=('GPL3') depends=('alsa-lib' 'gpm' 'giflib' 'desktop-file-utils' 'hicolor-icon-theme' 'libwebkit3' 'm17n-lib' 'gobject-introspection' 'imagemagick' 'librsvg' 'gconf') makedepends=('bzr' 'texinfo' 'glproto') options=('docs' '!emptydirs') provides=('emacs') conflicts=('emacs') install=emacs.install backup=('usr/share/applications/emacs.desktop' 'usr/share/emacs/site-lisp/subdirs.el') source=(bzr+http://bzr.savannah.gnu.org/r/emacs/xwidget) md5sums=('SKIP') _bzrmod=xwidget pkgver() { bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}' } build() { cd $srcdir/${_bzrmod} export CFLAGS="`pkg-config --cflags webkitgtk-3.0 ` -DHAVE_WEBKIT_OSR -g" export LDFLAGS="`pkg-config --libs webkitgtk-3.0 ` `pkg-config --libs MagickWand `" ./autogen.sh && ./configure --prefix=/usr --with-xwidgets \ --with-x-toolkit=gtk3 --with-sound \ --libexecdir=/usr/lib --localstatedir=/var --with-rsvg \ --with-gconf make bootstrap make } package() { cd $srcdir/${_bzrmod} make DESTDIR=$pkgdir install chown -R root:root $pkgdir/usr for _i in 16x16 24x24 32x32 48x48 128x128 do mv $pkgdir/usr/share/icons/hicolor/${_i}/apps/emacs.png \ $pkgdir/usr/share/icons/hicolor/${_i}/apps/$pkgname.png done mv $pkgdir/usr/share/icons/hicolor/scalable/apps/emacs.svg \ $pkgdir/usr/share/icons/hicolor/scalable/apps/$pkgname.svg mv $pkgdir/usr/share/icons/hicolor/scalable/mimetypes/emacs-document.svg \ $pkgdir/usr/share/icons/hicolor/scalable/mimetypes/$pkgname-document.svg chmod 775 $pkgdir/var/games # adding the READMEs. install -Dm644 $srcdir/${_bzrmod}-build/README \ $pkgdir/usr/share/doc/$pkgname/README install -Dm644 $srcdir/${_bzrmod}-build/README.xwidget \ $pkgdir/usr/share/doc/$pkgname/README.xwidget # remove conflict with ctags package mv "$pkgdir"/usr/bin/{ctags,ctags.emacs} mv "$pkgdir"/usr/share/man/man1/{ctags.1.gz,ctags.emacs.1.gz} # remove conflict with the texinfo-package rm $pkgdir/usr/share/info/info.info.gz # fix perms on /var/games chgrp -R games "$pkgdir"/var/games chmod 775 "$pkgdir"/var/games chmod 775 "$pkgdir"/var/games/emacs chmod 664 "$pkgdir"/var/games/emacs/* } this gives : [haawda@frege 4.1]$ LANG=C makepkg ==> Making package: emacs-xwidget-bzr 101273-1 (Thu Apr 4 10:19:00 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/emacs/xwidget ... bzr: ERROR: No such file: u'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr': [Errno 20] Not a directory: '/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr' ==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/emacs/xwidget Aborting... Any clues?

11 22

[aur-general] merge request - chromium-stable-libpdf
by Jakub Klinkovský 07 Apr '13

07 Apr '13

Please merge chromium-stable-libpdf [1] into better named chromium-libpdf [2] (not chromium-libpdf-stable, [1] was related to chromium-stable package, which is now gone). The maintainer of [1] agreed to give up the package - see comments. [1]: https://aur.archlinux.org/packages/chromium-stable-libpdf/ [2]: https://aur.archlinux.org/packages/chromium-libpdf/

2 1

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 07 Apr '13

07 Apr '13

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 24 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 30 packages missing signoffs * 6 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (24 total) == * bbswitch-0.6-3 (i686) * cdfs-2.6.27-40 (i686) * ndiswrapper-1.58-5 (i686) * open-vm-tools-modules-1:9.2.2-9 (i686) * r8168-8.035.00-8 (i686) * r8168-lts-8.035.00-2 (i686) * rt3562sta-2.4.1.1-26 (i686) * tp_smapi-0.41-17 (i686) * tp_smapi-lts-0.41-10 (i686) * vhba-module-20120422-20 (i686) * virtualbox-modules-4.2.10-4 (i686) * virtualbox-modules-lts-4.2.10-3 (i686) * bbswitch-0.6-3 (x86_64) * cdfs-2.6.27-40 (x86_64) * ndiswrapper-1.58-5 (x86_64) * open-vm-tools-modules-1:9.2.2-9 (x86_64) * r8168-8.035.00-8 (x86_64) * r8168-lts-8.035.00-2 (x86_64) * rt3562sta-2.4.1.1-26 (x86_64) * tp_smapi-0.41-17 (x86_64) * tp_smapi-lts-0.41-10 (x86_64) * vhba-module-20120422-20 (x86_64) * virtualbox-modules-4.2.10-4 (x86_64) * virtualbox-modules-lts-4.2.10-3 (x86_64) == Incomplete signoffs for [community] (30 total) == * bbswitch-0.6-3 (i686) 0/2 signoffs * cdfs-2.6.27-40 (i686) 0/2 signoffs * fcron-3.1.2-1 (i686) 0/2 signoffs * ndiswrapper-1.58-5 (i686) 0/2 signoffs * open-vm-tools-modules-1:9.2.2-9 (i686) 0/2 signoffs * oss-4.2_2007-3 (i686) 0/2 signoffs * r8168-8.035.00-8 (i686) 0/2 signoffs * r8168-lts-8.035.00-2 (i686) 0/2 signoffs * rt3562sta-2.4.1.1-26 (i686) 0/2 signoffs * shapelib-1.3.0-1 (i686) 0/2 signoffs * tp_smapi-0.41-17 (i686) 0/2 signoffs * tp_smapi-lts-0.41-10 (i686) 0/2 signoffs * vhba-module-20120422-20 (i686) 0/2 signoffs * virtualbox-modules-4.2.10-4 (i686) 0/2 signoffs * virtualbox-modules-lts-4.2.10-3 (i686) 0/2 signoffs * bbswitch-0.6-3 (x86_64) 0/2 signoffs * cdfs-2.6.27-40 (x86_64) 0/2 signoffs * fcron-3.1.2-1 (x86_64) 0/2 signoffs * ndiswrapper-1.58-5 (x86_64) 0/2 signoffs * open-vm-tools-modules-1:9.2.2-9 (x86_64) 0/2 signoffs * oss-4.2_2007-3 (x86_64) 0/2 signoffs * r8168-8.035.00-8 (x86_64) 0/2 signoffs * r8168-lts-8.035.00-2 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-26 (x86_64) 0/2 signoffs * shapelib-1.3.0-1 (x86_64) 0/2 signoffs * tp_smapi-0.41-17 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-10 (x86_64) 0/2 signoffs * vhba-module-20120422-20 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.10-4 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.2.10-3 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (6 total) == * shapelib-1.3.0-1 (i686), since 2013-02-24 * shapelib-1.3.0-1 (x86_64), since 2013-02-24 * oss-4.2_2007-3 (i686), since 2013-03-14 * oss-4.2_2007-3 (x86_64), since 2013-03-14 * fcron-3.1.2-1 (i686), since 2013-03-19 * fcron-3.1.2-1 (x86_64), since 2013-03-19 == Top five in signoffs in last 24 hours == 1. eric - 5 signoffs 2. foutrelis - 3 signoffs 3. pierre - 3 signoffs 4. dan - 2 signoffs

1 0

[aur-general] Fwd: please add -depth 1 to makepkg git clone
by Tai-Lin Chu 07 Apr '13

07 Apr '13

A rage post with too many typos and not enough punctuation is hard to read. >This is dumb because using cp is not enough, you should be using git clone because it is git and straight from git, if you goal is to just use the newest you are doing it wrong go write you own pkgbuild. What is not enough? cp has option to reserve everything. >The only reason to use git packages is if you are deving upstream and want to actively test development of upstream packages... Or if up stream is dumb enough to never tag stable releases. Fortunately there are very few of the latter, so to support the majority of of users we clone the whole thing. Please read document for depth=1 and shallow clone. When we create a package, we only need the snapshot at that time; we rarely revert any commit. After we do shallow clone, we can still pull, and remake package. I really dont understand your reason for " to support the majority of of users we clone the whole thing" because shallow clone is sufficient. >I truly do not understand why this conversation exists. We discussed this months ago. The conclusion was that you really shouldn't be using these packages unless you are following upstream... yes, i agree with you. But as a person who commits patches and needs to test, I think using --depth 1 makes initial cloning faster and decreases the load of remote git server. Think about this 100 people clones vlc.git with shadow (around 600mb) vs without shadow (around 10000mb)... its not just about whether you care it or not; please preserve resources of other projects. On Fri, Apr 5, 2013 at 10:50 PM, Daniel Wallace <danielwallace(a)gtmanfred.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Tai-Lin Chu <tailinchu(a)gmail.com> wrote: > >>1. you can still pull, so it will not be a reason to go against it >> >>>This is also true. makepkg clones a bare repository to the SRCDEST >>>directory. If this is a shallow bare repo, then clones cannot be made >>of >>>it which is what makepkg does. >> >>2. ... i dont think why it needs to use git clone. using cp is good >>enough... >> >>On Fri, Apr 5, 2013 at 7:05 PM, William Giokas <1007380(a)gmail.com> >>wrote: >>> On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote: >>>> makepkg only needs the latest git snapshot >>>> there are only 2 cases that wont work: >>>> 1. revert git commit >>>> 2. count # of revisions >>>> >>>> > Won't work as you can't clone shallow repositories, which makepkg >>>> > needs to do to create the working copy for the build. >>> >>> This is also true. makepkg clones a bare repository to the SRCDEST >>> directory. If this is a shallow bare repo, then clones cannot be made >>of >>> it which is what makepkg does. >>> >>> Thanks, >>> -- >>> William Giokas | KaiSforza >>> GnuPG Key: 0x73CD09CF >>> Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF > > I truly do not understand why this conversation exists. We discussed this months ago. The conclusion was that you really shouldn't be using these packages unless you are following upstream... What if the current depth=1 is unstable and has a huge bug.... Then what... Oh those users aren't following upstream and have no idea because instead of the developers of the program monitoring and telling them this a stable (and hopefully bug free release... The use your depth=1 pkgbuild and never update until one of the depends does a soname bump and breaks everything... To save space... In my opinion we should actually remove git packages from the aur... It adds an air of instability to the distribution... People that use -git should really maintain there own pkgbuild... And yes I felt this was so important I interrupted my night out to send... > > > So, unlike you, I hope depth is never supported in package source=() > - -- > Sent from my Android Phone. > Daniel Wallace > Arch Linux Trusted User > GTManfred > -----BEGIN PGP SIGNATURE----- > Version: APG v1.0.8 > > iQFUBAEBCAA+BQJRX7eRNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu > aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUiGAgf/TywmVGiCUD7h > gwAa41u43M9v890Suf2Io9x37ptiVJ6vGcwx5iWKJVct8r6TSh0xvavZo3VRW3G3 > 9mVst9HVSa16tMBXelVMGC2h1dawH2MYi8Jy1/L453133hFTqkIAOKPRX+QF+c5o > /8xU3sXog/115n2UiYnn2PymsnYen+xHxdrW4x3nGDJYFFwUlDVq+YmRRFjZrz+/ > a2sP5RkK0isv4U3h57bnb2mwQrZscV/IYMUrBmhHhaWZpErBx2EnZlm/PYjrnYEE > D+CNmaYoVh7zdKbI+X+1/cY4E2OSSRgwK8IU8gM7mXkw447VjASDf2s/RnyxOPND > ENGX7R1V2A== > =PNi3 > -----END PGP SIGNATURE----- >

4 13

[aur-general] Deletion request
by Rafael Ferreira 06 Apr '13

06 Apr '13

lib32-libusb[1] should be deleted in favor of lib32-libusbx[1] as libusbx is in [core]. [1] https://aur.archlinux.org/packages/lib32-libusb/ [2] https://aur.archlinux.org/packages/lib32-libusbx/ Please delete lib32-libusb Thanks, Rafael Ferreira

2 2

[aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
by Cédric Girard 06 Apr '13

06 Apr '13

Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard

8 12

[aur-general] Orphaned Packages
by Stefan Tatschner 06 Apr '13

06 Apr '13

Hi, I orphaned several packages, because I do not use them anymore. If anybody wants to maintain them, here they are: https://aur.archlinux.org/packages/perl-business-ismn/ https://aur.archlinux.org/packages/perl-data-compare/ https://aur.archlinux.org/packages/perl-list-allutils/ https://aur.archlinux.org/packages/ruby-polyglot/ The perl ones are needed by the latex-biber package. Stefan

1 0

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 06 Apr '13

06 Apr '13

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 6 packages missing signoffs * 6 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (6 total) == * fcron-3.1.2-1 (i686) 0/2 signoffs * oss-4.2_2007-3 (i686) 0/2 signoffs * shapelib-1.3.0-1 (i686) 0/2 signoffs * fcron-3.1.2-1 (x86_64) 0/2 signoffs * oss-4.2_2007-3 (x86_64) 0/2 signoffs * shapelib-1.3.0-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (6 total) == * shapelib-1.3.0-1 (i686), since 2013-02-24 * shapelib-1.3.0-1 (x86_64), since 2013-02-24 * oss-4.2_2007-3 (i686), since 2013-03-14 * oss-4.2_2007-3 (x86_64), since 2013-03-14 * fcron-3.1.2-1 (i686), since 2013-03-19 * fcron-3.1.2-1 (x86_64), since 2013-03-19 == Top five in signoffs in last 24 hours == 1. allan - 3 signoffs 2. eric - 2 signoffs 3. bisson - 2 signoffs 4. bpiotrowski - 1 signoffs

1 0

[aur-general] please add -depth 1 to makepkg git clone
by Tai-Lin Chu 06 Apr '13

06 Apr '13

1. save bandwidth 2. less wait why not add --depth 1 :)

8 16