- Aur-general - lists.archlinux.org

[aur-general] PKGBUILD URL has changed
by Justin Davis 27 Feb '11

27 Feb '11

I just wanted to let AUR helper authors (or other AUR enthusiasts) know that the PKGBUILD URL has changed on the AUR. All AUR helpers should update your code. I knew the AUR was updated recently but I did not realize that the URLs were changed for PKGBUILDs until I looked carefully at the AUR and the new patches. I found out earlier today and wanted to help others who might wonder why their AUR software slowly starts to break. The old scheme was: /packages/<name>/<name>/PKGBUILD The new scheme is: /packages/<name>/PKGBUILD Fun facts: Packages that were uploaded before the change still have an extracted package directory (/packages/<name>/<name>). The old packages also have a copy of their PKGBUILD in the new location.This means they have a PKGBUILD in both locations. Once a package is uploaded the old package directory is deleted so only one PKGBUILD remains (/packages/<name>/PKBUILD). So all packages uploaded after the change use the new PKGBUILD URLs. -juster

4 3

Re: [aur-general] [arch-dev-public] [signoff] ncurses-5.8-1
by Allan McRae 27 Feb '11

27 Feb '11

On 27/02/11 10:40, Allan McRae wrote: > Major upstream update. > > Test well. There is no soname bump, but experience tells me that some > rebuilds will probably be required to fix minor issues. > I have rebuilt community/stfl to fix a crash (used by newsbeuter). I will start a TODO list to keep track of packages that require moved with ncurses. If you do any rebuilds, please add the package to the list. Allan

2 1

Re: [aur-general] [arch-general] [arch-dev-public] [signoff] ncurses-5.8-1
by Allan McRae 27 Feb '11

27 Feb '11

On 27/02/11 18:38, Emmanuel Benisty wrote: > On Sun, Feb 27, 2011 at 8:55 AM, Allan McRae<allan(a)archlinux.org> wrote: >> On 27/02/11 10:40, Allan McRae wrote: >>> >>> Major upstream update. >>> >>> Test well. There is no soname bump, but experience tells me that some >>> rebuilds will probably be required to fix minor issues. > > just FTR, it breaks rtorrent. > > eb64@drama:~$rtorrent > Caught Segmentation fault, dumping stack: > 0 rtorrent() [0x439274] > 1 rtorrent() [0x43d737] > 2 /lib/libc.so.6(+0x326d0) [0x7f60f5e6e6d0] > 3 rtorrent() [0x482f9e] > 4 rtorrent() [0x439988] > 5 /lib/libc.so.6(__libc_start_main+0xfd) [0x7f60f5e5adcd] > 6 rtorrent() [0x40d959] > Aborted > > simple rebuild doesn't seem to help, downgrading does. > Seems this is x86_64 only. I tried building a few things in its dependency chain too but that did not help. Added to the TODO list for the maintainer to look into. Allan

1 0

[aur-general] please remove xdotool-svn
by Andreas Wagner 27 Feb '11

27 Feb '11

Hello, xdotool has moved from svn to git. The package xdotool-svn no longer works. Can someone remove it? http://aur.archlinux.org/packages.php?ID=45057 Thanks, Andreas Wagner

2 1

[aur-general] delete request
by speps 26 Feb '11

26 Feb '11

Hi TUs, mutt-ncurses > http://aur.archlinux.org/packages.php?ID=20061 is no needed any more since mutt in extra is built against ncurses. cheers - speps -

2 1

[aur-general] Please delete minecraft-data
by Cédric Girard 26 Feb '11

26 Feb '11

The package minecraft-data [1] is supposed to provide game data for Minecraft. This package is outdated, orphaned and does not comply with the game license [2] (hosting of original game content). Please delete it. Thanks. [1] http://aur.archlinux.org/packages.php?ID=40928 [2] http://www.minecraft.net/copyright.jsp -- Cédric Girard

4 5

[aur-general] Delete request
by kevku 26 Feb '11

26 Feb '11

https://aur.archlinux.org/packages.php?ID=30938 lib32-libpps, replaced by libpps https://aur.archlinux.org/packages.php?ID=16385 bin32-gmlive-svn, replaced by gmlive-svn

2 1

[aur-general] Adding AUR packages to [community] packages' provides
by Lukas Fleischer 26 Feb '11

26 Feb '11

Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well. Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages. Seriously, we should be consistent here. [1] http://mailman.archlinux.org/pipermail/aur-general/2011-February/013811.html [2] https://bugs.archlinux.org/task/16495

7 7

[aur-general] Blacklisted - postgresql-client
by Phillip Smith 26 Feb '11

26 Feb '11

Well this is new.... "postgresql-client is on the package blacklist, please check if it's available in the official repos." postgresql-client is not in the repos, but it is 'provides' in postgresql, as per FS#16495: https://bugs.archlinux.org/task/16495 How should I handle this?

4 6

[aur-general] [new community packages] eeze-svn and elementary-svn
by Ronald van Haren 25 Feb '11

25 Feb '11

FYI, I've added eeze-svn and elementary-svn libs to the e17 package group in [community]. These two packages were missing from the core EFL libs in community. Ronald

1 0