- Aur-general - lists.archlinux.org

[aur-general] Package deletion request
by Thomas S Hatch 02 Jan '11

02 Jan '11

lwt: https://aur.archlinux.org/packages.php?ID=33268 Has been replaced by the properly named: ocaml-lwt: http://aur.archlinux.org/packages.php?ID=39089 Thanks! -Thomas S Hatch

2 1

[aur-general] delete req,
by jwbirdsong 31 Dec '10

31 Dec '10

gmic at http//aur.archlinux.org/packages.php?ID=39897 Unmaintained dup of community pkg gmic thanks

2 1

[aur-general] ArchStudio
by Bernardo Barros 31 Dec '10

31 Dec '10

Hello everyone! I set up a repository based on a modified version of ArchAudio, with some of my stuff and lots of PKGBUILDs from AUR's contributors. Hope this helps to update and maintain ArchAudio alive and updated. Just source for now, no binaries. It is a hg repo, so it can also be hosted inBitBucket and Google Code, and can be easily forked, hacked and pushed back. The contribution work can be much easier this way, I think. The initial idea is not _necessarily_ to replace ArchAudio repo binaries, but set up a pool for development of the most updated and new in terms of professional audio packages for ArchLinux. https://bitbucket.org/smoge/archstudio Happy New Year! Bernardo

1 0

[aur-general] Duplicate Lyx 2.0beta2
by Bernardo Barros 31 Dec '10

31 Dec '10

It seems to be the same thing for me: http://aur.archlinux.org/packages.php?ID=37964 http://aur.archlinux.org/packages.php?ID=44306 the only difference is --enable-build-type=pre, that I thinks does not change much. Cheers!!

2 1

[aur-general] Chmod files in a package
by Nathan Owens 31 Dec '10

31 Dec '10

I am working on package bglibs, it has a installer that installs the libs and such. Namcap gives that usr/lib/bglibs/lib/... needs 444 or 644 directories and files need permission set to 644 or 444. I have tried chmod -R 644 $pkgdir/usr/lib/bglibs/lib and that doesn't work. Also I have tried: for dir in $pkgdir/usr/lib/bglibs/lib do chmod -R 644 $dir done also I have tried: find $pkgdir/usr/lib/bglibs/lib -type d -exec chmod 644 {}\; None of the above worked.

2 4

Re: [aur-general] Breaking the unspoken rule: AUR helper in [community]
by Evangelos Foutras 30 Dec '10

30 Dec '10

On Thu, Dec 30, 2010 at 4:16 AM, Dan McGee <dpmcgee(a)gmail.com> wrote: > http://www.archlinux.org/packages/community/i686/cower/ > > Thoughts? I was under the impression we didn't do this, and definitely > on purpose, otherwise people have *no* idea the AUR is different in a > lot of ways. Making people go the "hard way" to get a helper installed > at least presents some (necessary) barrier. This should have been posted to aur-general, where TUs can reply. Personally, I don't feel strong either way. As it was explained to me on IRC, cower doesn't include any building or installation functionality, it only searches for packages, downloads them, and can also check for updates to installed, unsupported, packages.

10 15

Re: [aur-general] [arch-dev-public] adding hunspell-xx packages
by Andreas Radke 30 Dec '10

30 Dec '10

Am Thu, 30 Dec 2010 16:06:15 +0100 schrieb Andreas Radke <a.radke(a)arcor.de>: > hunspell-de is alive. hunspell-en as well. same for hyphen-de (we already had hyphen-en from the hyphen split pkg) mythes-de and mythes-en. Feel free to add more languages sets (hunspell/hyphen/mythes) you need. Always check whether Fedora (http://pkgs.fedoraproject.org/gitweb/) or OpenOffice (http://wiki.services.openoffice.org/wiki/Dictionaries) has a more recent version. Now we need to rebuild OOo/LibO and Mozilla packages to make use of them. AUR and Community packages may need fixes for the proper file locations. -Andy

3 3

Re: [aur-general] [arch-dev-public] Breaking the unspoken rule: AUR helper in [community]
by Ionuț Bîru 30 Dec '10

30 Dec '10

On 12/30/2010 04:16 AM, Dan McGee wrote: > http://www.archlinux.org/packages/community/i686/cower/ > > Thoughts? I was under the impression we didn't do this, and definitely > on purpose, otherwise people have *no* idea the AUR is different in a > lot of ways. Making people go the "hard way" to get a helper installed > at least presents some (necessary) barrier. > > -Dan this is my mistake suggesting him to push it community mostly because cower is not like yaourt. It doesn't help building anything and users still have to familiar themselves with PKGBUILD and makepkg. i consider cower being a cli interface from aur and it much better than the html version. with it i can found more easily packages because it has bash completion, searching has regex. Just try to find the link for opera build from aur using the html interface vs cower. The only "rule" i found in wikis about this subject is: Note: There is not and will never be an official mechanism for installing build material from UNSUPPORTED. All users should be familiar with the build process. Maybe we should change that and include all aur helpers that interface with the official json api from aur.archlinux.org. -- Ionuț

4 3

Re: [aur-general] [arch-dev-public] Breaking the unspoken rule: AUR helper in [community]
by dave reisner 30 Dec '10

30 Dec '10

On Wed, Dec 29, 2010 at 9:16 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > http://www.archlinux.org/packages/community/i686/cower/ > > Thoughts? I was under the impression we didn't do this, and definitely > on purpose, otherwise people have *no* idea the AUR is different in a > lot of ways. Making people go the "hard way" to get a helper installed > at least presents some (necessary) barrier. > > -Dan > I suppose it depends on what we want the barrier to be. In lieu of one of Xyne's flowcharts, consider the raw interaction with the AUR to be something like: search -> download -> extract -> makepkg -> pacman cower draws the line after extraction, because I consider the process to be trivial up until that point. A completely uninformed user who learns how to use the AUR website and/or cower is still left in the same position after extraction -- they have some strange text files on their hard drive. A monkey* could get this far. The responsibility still lies with the user to understand what they've downloaded and what needs to be done with those files. makepkg, and the understanding of, is too important to be masked by another program. I do, however, understand the concern that existance of a tool in community to fetch said strange files may make them appear to be more supported than unsupported. dave * a real monkey, not one of our users.

1 0

[aur-general] Belated Arch Holiday Madness
by Kaiting Chen 30 Dec '10

30 Dec '10

Hi aur-general, I was out of the country while the whole Holiday Madness moves were taking place. Therefore I'm adopting my packages a little late. It looks like I'll be moving radvd, libx86emu, hwinfo, netperf, and nsd to [community]. They'll probably hit [community-testing] tomorrow and [community] in a couple of days. Merry Christmas and Happy New Years everyone! --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

1 0