- Aur-general - lists.archlinux.org

[aur-general] Status of virtualbox_bin{, _beta, -1, -2, -3} and virtualbox-sun
by Lukas Fleischer 09 Feb '11

09 Feb '11

Hey, folks! In consequence to recent deletion requests concerning the pre-built VirtualBox packages in the AUR, I decided that we should agree on what to do with them in consensus. The status quo is that the PUEL (Personal Use and Evaluation License) edition of VirtualBox is gone as of release 4.0, since people can now use additional features with "virtualbox" from [community] and a closed-source extension pack [1]. Instead, Oracle provides a pre-built VirtualBox package as the "successor" of the PUEL edition which, however, is exactly the same thing as the package in [community]. Afaik, the only difference is that the [community] package is compiled by us whereas the binary package is built by Oracle. We currently have at least six source tarballs based on that pre-built version in the AUR: - virtualbox_bin [2] - virtualbox_bin_beta [3] - virtualbox_bin-1 [4] - virtualbox_bin-2 [5] - virtualbox_bin-3 [6] - virtualbox-sun [7] virtualbox_bin-{1,2,3} are legacy packages. They still have a considerable number of votes. Following points emerged during earlier discussions: Pro deletion: - There shouldn't be any packages in the AUR that provide exactly the same stuff as another package in the official repos. - The [community] package is preferable to the AUR packages as it is maintained by some Arch dev and contains Arch-specific patches. People might also be confused by the high number of votes on virtualbox_bin. Against: - Why delete them? These packages still have AUR maintainers, upstream's still active, they don't break things, they ain't real dupes. - The binary packages can be used to check for upstream faults in case the official virtualbox package breaks. Any further opinions? [1] https://aur.archlinux.org/packages.php?ID=44761 [2] https://aur.archlinux.org/packages.php?ID=9753 [3] https://aur.archlinux.org/packages.php?ID=27339 [4] https://aur.archlinux.org/packages.php?ID=19613 [5] https://aur.archlinux.org/packages.php?ID=27853 [6] https://aur.archlinux.org/packages.php?ID=44826 [7] https://aur.archlinux.org/packages.php?ID=31996

2 1

[aur-general] Please delete mcabber-module-si-git and mcabber-module-streams-git
by Patrice Peterson 09 Feb '11

09 Feb '11

Hey all, Please delete the following two packages: mcabber-module-si-git http://aur.archlinux.org/packages.php?ID=35175 mcabber-module-streams-git http://aur.archlinux.org/packages.php?ID=35175 They aren't maintained anymore and are superseded by the mcabber-module-jingle-git package. Thanks! Regards, Patrice.

2 1

[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