- Aur-general - lists.archlinux.org

[aur-general] lib32-libvdpau moved in multilib
by Ionuț Bîru 09 Feb '11

09 Feb '11

Hi, now that adobe released as stable the flash version that supports vdpau, i needed your build to bring the support to multilib. Thanks for the build. -- Ionuț

2 1

[aur-general] Deletion request
by Krzysztof Raczkowski 08 Feb '11

08 Feb '11

Hi, The following packages: - openxencenter (http://aur.archlinux.org/packages.php?ID=34398) - openxencenter-svn (http://aur.archlinux.org/packages.php?ID=36074) are replaced by openxenmanager-svn (http://aur.archlinux.org/packages.php?ID=45800) as upstream switched name from openxencenter to openxenmanager. Why not clear AUR from obsolete ones? Cheers, -- Krzysztof Raczkowski raczkow(a)gmail.com

2 1

Re: [aur-general] Moving packages to Community
by Martti Kühne 08 Feb '11

08 Feb '11

> Not that I wouldn't mind the credit but it was Lukas Fleischer who > implemented the official repo checking code and not me. He is also > hosting the git repository for his branch of the AUR. Oops, yeah, I saw this too at some point. > Your idea sort of sounds like "retiring" a package to me. That seems > like an interesting idea but I am not sure the benefits are worth the > work involved. The benefits that I can see are: Well, a "retired" AUR package isn't much retiring in my notion, but more active than ever before, due to the fact that it is officially part of Archlinux at that point. The thing is that the intention behind this is to basically insert a cheery error page that would iron out the complaints from AUR maintainers that seem to come up frequently. It would improve the communication with TUs when there's a mailto address to the guy displayed, which does the package now. > + keeping a backup of the source package (for whom? are they that valuable?) > + keeping a backup of the comments, which hardly anyone can see (the > original author? TUs?) <displace-by-topic-coverage> > - what sort of design on the web could be used to show old retired > package comments? you can't hide a package and show its comments. who > is the end-user for old musty comments anyways? The backup of the source package is unnecessary, as well as the comments to the point, that maybe said maintainer wants to look at it for a last time. So that could be, like some static you-might-be-looking-for-this-data-but-probably-not kind of way. Nice to have, no must-have, anyways. Just for the sake that I did read ppl complaining about that as well... > Just to be specific, a TU clicks the "Retire" button on a package to > retire it. A retired package is hidden from the general user. Only the > original author can see it. I suppose TU or devs could see it as well, > in a special swanky section of the site. Problems I brainstormed: > - what happens if the original author disowns his invisible retired > package? does he lose it never to found again? would anyone care? There should no more be a way to disown that package. The intention is really just a bite more than the "database entry not found" surprise people now have. The only thing that can be done by that former owner and only that former owner is to approve, and when approved, it's going to be deleted. > Anyways there you go. If I were the one expected to spend time > programming this (for free) I would say that it's not worth the > effort. That's more nicely said than unsubscribing this list, but you would remember by the fifth time this flame awakes as a zombie... :-D Let's see... cheers! mar77i

1 0

Re: [aur-general] TU Resignation
by Seblu 08 Feb '11

08 Feb '11

On Mon, Feb 7, 2011 at 8:25 PM, Andrea Scarpino <andrea(a)archlinux.org> wrote: > Hi TUs, > it's my time to leave the [community] repo. > > I orphaned more packages in the last year and now I orphan the rest: > - choqok > - quoauth > - oxygen-gtk > - rekonq > - wtf > > Has been an honour to work with all you guys. > Thank you all. As a simple user, thanks you for your advices and your work in community. -- Sébastien Luttringer www.seblu.net

1 0

Re: [aur-general] AUR & Copyright
by Nicky726 08 Feb '11

08 Feb '11

Angel Velasquez wrote: > Why you didn't reply on the thread ? :S now this thread is splitted > without reason Sorry, Re: somehow slipped out from Subject line. :-( Nicky -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)

4 8

[aur-general] new aur mirror
by keenerd 08 Feb '11

08 Feb '11

Hi all. I am now mirroring the AUR continuously, and am starting to open it up to public access. It is not a perfect byte-for-byte clone, as I felt like adding a few features :-) For now, there is an enhanced RPC database. It's got everything from the original RPC calls, plus some extra fields that people always seem to want. Access it through http://aur.kmkeen.com/rpc/name_of_package Yes, it is 100% static. This was the only way my little VPS could keep up with the beastly Sigurd machine. I've also got all the tarballs mirrored, but forgot to add the links to the RPC info (mirror/pkgname/pkgname.tar.gz). Will fix that shortly. There are also search indexes prepared for description, depends and required-by but the regex search is not open to the world yet. Maybe after I get some sleep. Much thanks goes to Falconindy for ideas, encouragement and patience. I am currently taking feature requests. Go wild. -Kyle http://kmkeen.com

5 8

[aur-general] AUR PKGBUILD Deletion Request
by Slash 08 Feb '11

08 Feb '11

Greetings, The following packages need to be deleted: 1) ezquake-skins: http://aur.archlinux.org/packages.php?ID=7069 2) ezquake-textures: http://aur.archlinux.org/packages.php?ID=7068 These packages have a bunch of random, out of date, some no longer relevant assets, which should never have been bundled together in the first place. In addition, they are not directly related, nor depend on ezquake, so they should not have been named as such. I have created a new proper package to take the place of these two, with the work from the Quake Retexturing Project (QRP), quake-qrp-textures ( http://aur.archlinux.org/packages.php?ID=45791 ). I posted a comment on the two aforementioned packages to warn users ahead of time. Thank you in advance, Slash

2 1

[aur-general] Delete Request
by Sara Fauzia 08 Feb '11

08 Feb '11

Please remove fbpdf: http://aur.archlinux.org/packages.php?ID=46240 I've replaced it with fbpdf-git: http://aur.archlinux.org/packages.php?ID=46304 I uploaded the package as fbpdf, but it is a git package, so to fix my mistake, I created the fbpdf-git package. Sara -- "Nothing is too wonderful to be true, if it be consistent with the laws of nature." ~Michael Faraday

2 1

[aur-general] Disown request
by rafael ff1 08 Feb '11

08 Feb '11

Hi there. I tried to have the maintainer of *lib32-gtk-engines* and *lib32-libidl2* to fix the PKGBUILDs to comply Multilib, but got no answer by email for 10 days now. I got it ready to upload. Please disown these 2 packages? Thanks

2 4

[aur-general] Moving packages to Community
by Martti Kühne 07 Feb '11

07 Feb '11

Hello official and inofficial maintainers and AUR devs. Following the discussion in aur-general, I think some automation could solve many issues at once here. Justin Davis' community-blacklist patch is an approach in about the right direction.... although in relation to the discussion concerning these prevailing [more-official repo] adoption issues, it seems that it does not yet go far enough at the moment. There should be a redirection or at least a [we're-now-official] error page showing sort of "congratulations and sorry for the late notice" to the yet uninformed aur maintainer, if his package is not reachable any more because it was adopted in said [more-official repo] - along with this could be displayed the comments of the former package. As well, it could just become invisible in the package's search, and marked with a "I saw this" button in the former AUR maintainer's package list. When that button is clicked, the package would sink quietly into the official repo without anyone needing to complain. The only hurdle remaining is, that a package isn't up for deletion any more when it gets adopted to [more-official repo], because that could just be automated by the repo's backend maybe? I'm probably going to download the aur source inclusively Justin's approach to look into this a bit further. Even though my development skills aren't exactly in line with such a task, and if someone feels more confident, one may look into it h{im,er}self. I'd like to hear your comments on this well. cheers! mar77i

2 1