- Aur-general - lists.archlinux.org

[aur-general] Standardized CPAN Package Versions
by Xyne 10 Feb '11

10 Feb '11

Hi, I have CC'd this to aur-general as this concerns all CPAN packagers on Arch. CPAN package versions are a mess on Arch Linux. It seems that many if not most CPAN packagers on Arch are unaware of how CPAN deals with versions and thus they do not correctly translate the CPAN version. Most of the time a naive translation is used instead, and this prevents Pacman from working correctly. To give an example, CPAN considers "1.15" to be a later version than "1.23.0", whereas Pacman will consider the latter version the newer version. This is because "1.15" is short for "1.150" on CPAN, whereas "1.23.0" is short for "1.023.0". This can be confirmed using the "version" module[1]. I have written a simple Perl script[2] that addresses this issue.* It accepts CPAN versions as command-line arguments and prints out standardized Pacman package versions. The package versions enable Pacman to correctly compare CPAN packages, e.g. when resolving minimal dependencies. I propose that the script be packaged and made an official tool for Perl package developers.** It should also be included on the Perl Package Guidelines wiki page[3]. I hope that this will be seriously considered as it addresses a real issue. Tools that generate CPAN packages for Pacman (e.g. Bauerbill) cannot work properly when there is no consistency in how Arch packages are versioned. Please note as well that this is completely separate from my previous (and continued) contention regarding the "provides" array of CPAN packages. Regards, Xyne [1]: http://search.cpan.org/~jpeacock/version-0.88/ [2]: http://xyne.archlinux.ca/scripts/pacman/ver_cpan2pacman [3]: https://wiki.archlinux.org/index.php/Perl_Package_Guidelines * The script only depends on Perl. The name and license are preliminary. I will gladly change both to something more suitable. * I would be willing to maintain it, but an official tool should probably be included in [core] or [extra], not [community].

4 8

[aur-general] AIDE out-of-date
by Tony C 10 Feb '11

10 Feb '11

Hi, AIDE has been flagged out-of-date since July of 2010. I went ahead and tidied up the PKGBUILD for the most recent version of AIDE. Please update this in AUR. https://aur.archlinux.org/packages.php?ID=22591 Kind Regards, -- Tony

5 7

[aur-general] Please delete gimp-save-for-web
by Marcel Korpel 10 Feb '11

10 Feb '11

Hi, Can someone please delete gimp-save-for-web [1], as it is a duplicate of gimp-plugin-saveforweb [2] (though it has a nice package ID ;). Thanks! Regards, Marcel [1] http://aur.archlinux.org/packages.php?ID=20000 [2] http://aur.archlinux.org/packages.php?ID=13473

2 1

[aur-general] How to handle installers in PKGBUILDs
by Michael Schubert 10 Feb '11

10 Feb '11

Hi, I am already maintaining a couple of PKGBUILDs and wanted to add one for CellDesigner, which is used to model biochemical pathways. The download is only available as binary package with its own installer. Now, I thought that I could use the installer inside a PKGBUILD with $pkgdir as root. However, the installer cross-references some files in others with absolute paths, i.e. when the package is installed it still links to the build dir instead of the system dir. Because of the way the cross-refs are inserted, simple sed'ing these does not work. The obvious solution would be to use fakeroot/chroot in the $pkgdir and use to to emulate a root directory structure. My question now is: (1) am I on the right track and (2) is there any standard way to do this in PKGBUILDs? I couldn't find any sample PKGBUILDs concerning this issue and the ArchWiki contains no information either. Any help would be appreciated. Cheers, Michael

4 6

[aur-general] Deletion Request
by Fergus Symon 10 Feb '11

10 Feb '11

Hi, The package latex-minted (http://aur.archlinux.org/packages.php?ID=45813) is provided by texlive-latexextra, and I believe the author wants it deleted. Thanks, Fergus

2 1

Re: [aur-general] How to handle installers in PKGBUILDs
by jesse jaara 09 Feb '11

09 Feb '11

On 9.2.2011 14.08, "Michael Schubert" <mschu.dev(a)gmail.com> wrote: > > Hi, > > I am already maintaining a couple of PKGBUILDs and wanted to add one > for CellDesigner, which is used to model biochemical pathways. The download > is only available as binary package with its own installer. > > Now, I thought that I could use the installer inside a PKGBUILD with $pkgdir > as root. However, the installer cross-references some files in others with > absolute paths, i.e. when the package is installed it still links to the > build dir instead of the system dir. Because of the way the cross-refs are > inserted, simple sed'ing these does not work. > > The obvious solution would be to use fakeroot/chroot in the $pkgdir and use > to to emulate a root directory structure. My question now is: (1) am I on > the right track and (2) is there any standard way to do this in PKGBUILDs? > > I couldn't find any sample PKGBUILDs concerning this issue and the ArchWiki > contains no information either. > Any help would be appreciated. > > Cheers, Michael Usually the installers are shell acripts with a binary tar.gz blob in the end of the file. This can be cat:ed from the file and piped to tar. This is what the installer does Open it and you see how to cat the contents and what else might ne needed

3 3

Re: [aur-general] Moving packages to Community
by Nicky726 09 Feb '11

09 Feb '11

Hi, fellow Archers, I feel a need to express my support to the opinion stated by Greg Imreh and Thomas Hatch. There is an unique relation between the contributor/maintainer and the PKGBUILD. This relation calls for respect. So please TUs/devs act as people and show it by letting first the contributor/maintainer know, that you are about to adopt a PKGBUILD to the binary repo. Surely adoption in the repo by itself is greater good for the package and Arch and therefor goal of every maintainer, so there hardly will be objections from the maintainer, but just taking it without a word is very rude. There would be no package to adopt, if there was not for the AUR contributor/maintainer. To Angel Velasquez: the nature of the relation is not like an ownership, but more like an authorship. Is it that much to show your respect to the author by a polite question? After all we are people, not mindless machines nor animals. Nicky -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)

14 16

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

09 Feb '11

Hey, Could you please delete mcabber-module-streams (http://aur.archlinux.org/packages.php?ID=35176)? It's a dependency for mcabber-modules-si-git (which was deleted earlier), and it's superseded by mcabber-module-jingle-git as well. Thanks in advance, Patrice.

2 1

[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