Re: [aur-general] Updating AUR versions server side

> > [...] I believe the .SRCINFO file was added so that the AUR could discover > > a PKGBUILD's version without needing to evaluate arbitrary scripts. > > As far as I know the AUR did not, at any point, evaluate arbitrary > scripts to retrieve metadata. It did parse (or attempt to...) the >

Re: [aur-general] Updating AUR versions server side

> > What if regular, non development, AUR packages were tested server side > > for new versions? > > Won't that make more sense than the maintainer having to run pkgver() > > manually from time to time? > > We shall not evaluate user-uploaded shellscripts on the AUR server. Most > AUR helpers

Re: [aur-general] TU membership application

> > Well, I think it should be the other way around, you first mentor someone > > and look with them into their packages and then decided about sponsorship. > > That's your opinion, and here's mine: I don't think that's important. If a > candidate looks promising and there is an intention to both

Re: [aur-general] Deletion of discord-updater{,-canary}?

> The pkgver() function is ran after the sources are downloaded. So > doing source=('$pkgname-$pkgver::url') will not work. Thanks though. Pooh. Gotcha.

Re: [aur-general] Deletion of discord-updater{,-canary}?

> Adding a pkgver() to Discord in a clean way is proving to be quite annoying. > Adding this to the source=() > 'https://discordapp.com/api/download/canary?platform=linux=tar.gz' > causes makepkg to download a file named 'canary?platform=linux=tar.gz' > even though the download output from curl

Re: [aur-general] TU Application: Andrew Crerar

> ttf-google-fonts-git: > - `install -dm755 ...; install -Dm644 ...;` is kind of like sprinkling > your code with `sleep 1` (I think) I understand what you mean, but Andrew might not. To put a finer point on it, `install -dm755` is unnecessary, because install's `-D` flag creates directories

Re: [aur-general] pisg-fixed

> > well, i beg your pardon if i made the assumption that TU and the entire > AUR structure was smart enough to understand a merge request of a > differently-owned package as an orphan request for a clearly fixed package. > > i humbly beseech myself towards your graces and fall upon my sword for >

Re: [aur-general] TU Application: Morten Linderud

> > python-vagrant: > > - test cases could be run > > - you could distribute the LICENSE.MIT file as MIT is not a common > > The testing is sorta peculiar as it requires vagrant and virtualbox(!) to run. > Haven't gotten the cases to run after installing them so I have to work a bit > more on

Re: [aur-general] TU Application: Thore Bödecker

> And on my router at home. Neat! What are you using for router hardware? I've done this as well. I used a desktop with ethernet and wifi expansion cards for several years, and then moved to a PC Engines apu2c2 . It seems like you have a good set of system

Re: [aur-general] How do you deal with pkgver() version controlled PKGBUILDs?

You can use `git add --patch` to add specific portions of a file to the git staging area. git add --patch PKGBUILD git checkout -- PKGBUILD

Re: [aur-general] Adopt Monkeysphere

Some small suggestions: * I'd suggest quoting the first item in the `source` array, on line 14. The variables being interpolated into that string should never contain spaces or other undesirable characters, but why take a chance? * Lines 15-17 contain tab characters. I'd suggest replacing them

Re: [aur-general] libgroove package review, round 2

--noextract​ A, so that's the functional difference between `prepare` and `package`! Thanks. I haven't tested any of my packages with `--noextract`, but I'll spend some time getting familiar with that option. — Jeremy Ichimonji10 Audet

[aur-general] libgroove package review, round 2

Hi all, I'm hoping to push a change [1] [2] to my libgroove package. I know that the change _works_, but I'm not sure if it's _correct_. Upstream has added a sample pkg-config config file to their source code. I'd like to install a slightly modified version of that config file to users' systems.

Re: [aur-general] package review

Just a small correction: test() is no default function, the function you should use is check() Thank you. I wonder why you have a test program but don't use it in the test() function of your PKGBUILD? Pure ignorance. :/ This is a great idea, and I'll put it on my to-do list. It looks like

[aur-general] package review

Hi, Would anyone be so nice as to review my libgroove package? The current package [1] and proposed package [2] are both on GitHub. The package is for a C library, and I am hoping to add a pkg-config config file (libgroove.pc) to the package. I've never written one of these before, and am worried

Re: [aur-general] Package deletion

Ack. Sorry about the noise. Just looked at the other emails sent around and saw that there were (two?) other threads created about this same issue. (That is itself annoying.)

Re: [aur-general] Removal request

Stefan, The preferred method of submitting removal requests is now through the AUR web interface. Search for the File Request link. — Jeremy 'Ichimonji10' Audet

Re: [aur-general] Categories

What happens if something really belongs in two categories? In that case, one should use a tagging mechanism instead of a categorization mechanism. On the other hand, I think we should remove category because only a few packages actually use correct category. It is almost useless. +1 — Jeremy

Re: [aur-general] Meta packages in AUR?

If you're serious about using a custom package across all your systems in a native way, one option is to add a new paragraph into /etc/pacman.conf: # An example of a custom package repository. See the pacman manpage for # tips on creating your own repositories. #[custom]

Re: [aur-general] Package ownership change request for yaourt-git

How can VCS packages be out of date at all? Client machines will only update a VCS package if: 1. The package maintainer updates a VCS package and gives it a newer version number than what is installed on a user's machine, and a user updates their packages. 2. The user explicitly requests that

Re: [aur-general] Package ownership change request for yaourt-git

Really, most ofthis is mostly irrelevant TBH. This is a common point of confusion. Because of this, I think it is worth addressing and therefore relevant. The official way of using the PKGBUILDs is manually with makepkg. I suspect that the usual use case for interacting with the AUR is with

Re: [aur-general] Package ownership change request for yaourt-git

Anyone using VCS packages from the AUR, should be following the package upstream and rebuilding it as they go. Aha. This gets to the heart of things. I've been assuming that many VCS package users will install a VCS package and henceforth rely upon the package maintainer to update the VCS

Re: [aur-general] Information request about libnss-mysql

Old accounts (older than either 500 days or two years, not sure which) were recently purged. [1] libnss-mysql was last updated in May 2012, which would probably explain why the submitter, maintainer and packager is listed as None. I'll leave it up to the TUs to confirm this hypothesis and let you

Re: [aur-general] python-rst2beamer

sinma, rst2beamer appears to be intended for use by end users on the command line. [1] Thus, the package should be called rst2beamer, not python{,2}-rst2beamer. The package should also install a simple wrapper script at /usr/bin/rst2beamer. There's a couple other issues with the package, too:

Re: [aur-general] python-rst2beamer

Ack. That [1] should have led to https://pypi.python.org/pypi/rst2beamer

[aur-general] merge request

Please merge ruby-adsf [1] into adsf [2]. adsf is primarily intended for use by end users, not as a library. Thus, according to the packaging guidelines in the wiki, the language-specific prefix should be stripped. I maintain both packages. — Jeremy Ichimonji10 Audet [1]

Re: [aur-general] python packages as depends and easy_install

Does this PKGBUILD look ok? If pypump is a tool that users interact with directly (e.g. through the command line or a graphical program), then sure, that looks fine. However, if pypump is a library, then the package should be named python-pypump-git. I've had a quick look at the documentation

Re: [aur-general] deletion request

bump

Re: [aur-general] python packages as depends and easy_install

Would it be ok to use easy_install-2.7 pypump in a build function or something? No. Please make an actual package for pypump, and make p depend on pypump normally. I would just make a pypump package, but I cloned the repository, and I'm not really sure where all that stuff goes lol. Don't

Re: [aur-general] AUR logo

Is there a reason the Arch services {aur,bbs,wiki,bugs}.archlinux.org all use the same logo? KISS?

[aur-general] deletion request

Please delete ruby-reek. [1] As a tool intended primarily for use by users on the command line, it is badly named, and I have uploaded reek [2] to take its place. There are no votes or comments of worth, so there is little reason to merge packages. I am the maintainer of both packages. — Jeremy

[aur-general] merge request

Please merge ruby-nanoc [1] into nanoc [2]. Nanoc is primarily intended for use by end users, not as a library. Thus, according to the packaging guidelines, the language-specific prefix should be stripped. I maintain both packages. — Jeremy Ichimonji10 Audet [1]

Re: [aur-general] Duplicated package removal request

After breifly reading through the readme, I'd also opine that the project's official name is md5deep. Also note this line from the readme: For historical reasons, the program has different options and features when run with the names hashdeep and md5deep. This line would indicate that one of

Re: [aur-general] Duplicated package removal request

Correction: hashdeep was merged into md5deep. (Hashdeep doesn't exist anymore, so I think that's what you meant to say?)

Re: [aur-general] Package orphaning policy improvement - RFC

+1 — Jeremy Ichimonji10 Audet

Re: [aur-general] Update package python2-scitools

Joey, As stated, the usual policy is to email the maintainer directly. If they do not respond in two weeks, or if there is some other outstanding circumstance, the package will be orphaned. The reason for this policy is that package maintainers can unsubscribe themselves from package comments,

Re: [aur-general] swiften-git, spectrum2-git

Make sure to wrap all variable interpolations in double quotes. For example: SWIFTEN_INSTALLDIR=${pkgdir}/usr force-configure=1 This is also acceptable: SWIFTEN_INSTALLDIR=${pkgdir}/usr force-configure=1 Also, did you forget to add ';' to the end of your `find` statement? I'm not

Re: [aur-general] swiften-git, spectrum2-git

Don't clone Git repositories manually. Pacman has the ability to do that itself. For an example, see [1]. I also believe it's good practice to make -git packages conflict with and provide non-git versions of the same package. I would place the following lines in your spectrum2-git package:

Re: [aur-general] swiften-git, spectrum2-git

Ooho! That's cool. Thanks for the info, Florian. — Jeremy

[aur-general] disown request: ruby-ruby2ruby

Hi, Please disown ruby-ruby2ruby. [1] I flagged the package out of date 25 days ago, commented on it 19 days ago and emailed the maintainer 14 days ago. [1] https://aur.archlinux.org/packages/ruby-ruby2ruby/ — Jeremy 'Ichimonji10' Audet

Re: [aur-general] [arch-dev-public] GHC 7.8.1 packaging decisions for Arch Linux

Doesn't every language with its own package manager have this problem? For example, Python. Is there a good solution? Users knowing about this issue and making their own decisions is the current solution on every distro I'm familiar with. Aye. There are some upshots to allowing users to

Re: [aur-general] Upgrading a beta package?

I don't think there's any particular policy regarding which package versions should be provided by a *-beta package. That said, I agree with Martti Kuhne: a beta if there is one package makes much more sense than an always beta package. In other words, always keep the *-beta package as up to date

Re: [aur-general] RFC on the location of PHP binaries

Thanks for the clarification. The .phar extension will effectively put all PHP apps in their own namespace, and that seems like a good conflict-avoidance mechanism to me. (Of course, other folks are free to disagree.) --Jeremy

Re: [aur-general] RFC on the location of PHP binaries

In case anyone is interested, since we've received no answer, we've decided with /usr/share/webapps/bin/ So long as this solution interoperates nicely with web applications written with other frameworks (e.g. Flask, Django, Rails), then I trust your judgment. --Jeremy

[aur-general] deletion request: pylint-python3

Please delete pylint-python3 [1]. It is out of date, incorrectly named and a duplicate of python-pylint [2]. [1] https://aur.archlinux.org/packages/pylint-python3/ [2] https://www.archlinux.org/packages/extra/any/python-pylint/ --Jeremy

Re: [aur-general] Prefered way to create users/groups and handle files ownership

Software shouldn't really rely on files being owned/writable by certain users. Sure, software shouldn't rely on files being owned/writable by *certain* users. But it's reasonable for software to rely on files being owned/writable by *a* user. Consider, for example, `mpd` and `subsonic`. Both

Re: [aur-general] [Removal Request] lightworks

The lwks package includes the word Lightworks in the description, which means it can be found easily. Also, the lwks package has 21 votes to lightworks 0. That said, I have no personal experience with lightworks or how other distributions treat the package, so I have no solid opinion on the

Re: [aur-general] Prefered way to create users/groups and handle files ownership

As for a better solution? Hmm. `install` (and probably other tools too) can reference user and group names directly. [...] The problem with that is that the uid/gid for the permissions will be computed on the machine where the package is built, [...] It won't work for packages from AUR either.

Re: [aur-general] a cpan2aur, npm2aur, gem2arch like utility for Python

I've been looking, but I haven't yet found a utility like cpan2aur or gem2arch, etc for Python 'eggs' or whatever they're called The usual term is package.

Re: [aur-general] Prefered way to create users/groups and handle files ownership

The reason why permissions should be set in the PKGBUILD is because that way pacman can track them. Interesting. I didn't know Pacman could do that. The phrases UID, uid and gid do not appear in the man pages for pacman or pkgbuild. Is this undocumented behaviour? Then it's up to the

Re: [aur-general] Fwd: Community package [virtualbox-guest-utils] marked out-of-date

That's great. Thanks for sharing. --Jeremy

Re: [aur-general] Axiom (CAS) -- Same program, three packages (and licenses)?

Is a comment to the maintainer and waiting for answer sufficient? A comment may not be noticed by the maintainer, as the maintainer can disable email notifications for their own packages. You should email the maintainer if: * You want to ensure that the maintainer knows about the incorrect

Re: [aur-general] package review and merge request

Could django-extensions [1] be merged into python2-django-extensions [2]? [1] https://aur.archlinux.org/packages/django-extensions/ [2] https://aur.archlinux.org/packages/python2-django-extensions/

[aur-general] package review and merge request

Could someone look over my package python2-django-extensions [1]? In particular, I'm curious about a namcap warning. [2] Namcap complains that python should be a dependency, because some scripts call python. However, this is a python 2 package, so that warning seems nonsensical. Thoughts? If all

Re: [aur-general] package review and merge request

Also, I don't think you need to include the LICENSE file directly, as the tarball has the same file and you are actually copying that. Whoops. Thank you. I've fixed that. Please make sure the scripts are actually intended for python2, though. I just posted to the django-extensions google

Re: [aur-general] package review and merge request

User Trbs from the mailing list replied [1] promptly. He stated that the shebangs should not exist and suggested I create a patch to remove them entirely. (He also removed the shebangs from the official repo.) Thanks for the sample code, Doug and carstene1ns. I used it as the basis for a

Re: [aur-general] PKGBUILD review request

I created a pull request on GitHub. See: https://github.com/dobyrch/termboy-go/pull/1 --Jeremy

[aur-general] request: review packages

Hi all, I've created two split packages: django-tables2 [1] and factory_boy [2]. Could someone look them over? I've never created a split package before. [1] https://github.com/Ichimonji10/PKGBUILDs/blob/django-tables2/django-tables2/PKGBUILD [2]

Re: [aur-general] request: review packages

Be aware, though, that the AUR doesn't support split packages, so you have to work around that. Specifically, something like this: pkgname=python-factory_boy true pkgname=(python-factory_boy python2-factory_boy) Ah! Thank you. I've seen that construct in other packages, and it had always

Re: [aur-general] file exist in filesystem

I am trying to create a git package, which provides the non-git packages If one package provides another, only one of the two packages may be installed. :: mesa-git and mesa are in conflict. Remove mesa? [y/N] y Pacman is reminding you that only one of the two packages may be installed.

Re: [aur-general] file exist in filesystem

from a non-existent package (mesa-git) Whoops. That should read from a non-existent package (mesa).

Re: [aur-general] file exist in filesystem

https://wiki.archlinux.org/index.php/Pkgbuild#license mesa-git and other -git packages built from same source *should* replace packages from [extra] as they provide *everything* packages from [extra] do (*exactly* the same files/directories/etc) The licenses installed in `/usr/share/licenses/*`

Re: [aur-general] file exist in filesystem

Ah. I'm sorry if I've misunderstood your questions. --Jeremy

Re: [aur-general] Disown a number of ruby-* packages

For the last one, I think we can ignore the prefix as we already did for python packages (like python-dateutil and python2-memcached, they both have a python- prefix on pypi index). But... as you wish :) I also interpret those naming rules with a grain of salt. For example, the vim-a [1] and

Re: [aur-general] Changes in Arch packaging standards

Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release. This is wonderfully simple and straightforward. It's also current practice. Let's keep using it. There are basically 2 scenarios to

[aur-general] Deletion request

Please delete nightskyhd-hib [1]. It is obsolete and nightsky-game [2] should be used instead. nightskyhd-hib has only one vote and three comments, none of which apply to nightsky-game. [1] https://aur.archlinux.org/packages/nightskyhd-hib/ [2] https://aur.archlinux.org/packages/nightsky-game/

Re: [aur-general] Review request for first AUR package

Please review it in case I've missed something. You can drop the `pkgdir= #TODO` line completely. makepkg defines $pkgdir for you. [1] namcap emits several warnings. Run `namcap sic-1.2-1-x86_64.pkg.tar.xz` to see them. [1] https://www.archlinux.org/pacman/PKGBUILD.5.html#_build_function.

Re: [aur-general] Review request for first AUR package

I've removed the pkgdir line, fixed the namcap warnings, Great! and reuploaded the package now. Is the new .tar.gz file available at the same location? [1] I'm still getting the exact same set of files. Thanks for your help, Thank *you* for taking the time to email this list. is there

Re: [aur-general] vim-python2

I've flagged the package and emailed the maintainer I see the package was flagged on the 12th. Did you email the maintainer on the same day? Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react. [1] Of course, I'm not a TU, so

Re: [aur-general] [OT] how to post messages (was Re: espeakup's service file yet again lol)

On Tue, Nov 19, 2013 at 2:58 AM, Martti Kühne mysat...@gmail.com wrote: You're so deep. (sic! ref: [0]) cheers! mar77i [0] http://lists.suckless.org/dev/1311/18114.html That is *hilarious*. Thanks for the laughs. Also, I just discovered that gmail has a plain text mode. Hallelujah.

Re: [aur-general] Custom licence directory ?

first package i encountered is extra/nvidia-utils [0] (PKGBUILD can be retrieved via abs [1]) there you find install -D -m644 LICENSE ${pkgdir}/usr/share/licenses/nvidia/LICENSE ln -s nvidia ${pkgdir}/usr/share/licenses/nvidia-utils the same is done for a lot of lib32-packages in multilib.

Re: [aur-general] espeakup's service file yet again lol

It doesn't though. Lol what am I missing here? I prefer stuff top posted but, I believe it is up to the individual to choose their own style. Come up with something witty if you want, but what is the answer? Let's say someone just joined the mailing list and wants to know what the previous

Re: [aur-general] disown request: ruby-ruby_parser

I fail at parsing this... date still seems to be in the future :-) Ha! That's a typo on my part, and I should have written October. Whoops. --Jeremy

Re: [aur-general] [RFC] freeplane-git PKGBUILD

I would discourage the use of all-caps variable names. Shells typically use all-caps for their environment variables, and although I don't know of any shells that use _BUILD_DIR or _APPNAME as environment vars, the possibility exists. On Thu, Nov 7, 2013 at 10:38 AM, Leonidas Spyropoulos

Re: [aur-general] disown request: ruby-ruby_parser

Thank you. On Sat, Nov 2, 2013 at 3:13 PM, Xyne x...@archlinux.ca wrote: On 2013-11-02 11:19 -0400 Jeremy Audet wrote: Hi, Please disown ruby-ruby_parser. [1] I emailed the maintainer about his package on November 19th (exactly two weeks ago), flagged his package out of date over two

Re: [aur-general] disown request: mingw-w64-libxml2

Whoop. Sorry about the extra noise, Evangelos. I didn't realize that you'd already replied; the desktop version of gmail shows only two messages in this email chain, but the gmail version shows three. I don't know what's up with that. --Jeremy On Sat, Nov 2, 2013 at 10:45 AM, Jeremy Audet

Re: [aur-general] disown request: mingw-w64-libxml2

At the risk of stepping in a TU's territory: When did you email the maintainer? The comments on that page do show an interest in maintaining the package (thank you), but they do not indicate that the maintainer was ever emailed about the state of his package. --Jeremy Ichimonji10 Audet On Sat,

Re: [aur-general] PKGBUILD for zetacoin-qt-git

1. Add zetacoin-qt.desktop to the `source` and `sha256sums` arrays. They were already added, do you mean zetacoin-qt-git.install? Whoops, I misread the PKGBUILD. Ignore my suggestion. No, you do not need to add zetacoin-qt-git.install to the `source` and `sha256sums` arrays. 2. Add a function

[aur-general] disown request: ruby-ruby_parser

Hi, Please disown ruby-ruby_parser. [1] I emailed the maintainer about his package on November 19th (exactly two weeks ago), flagged his package out of date over two weeks ago, and commented on his package over two weeks ago. I've received no response. [1]

Re: [aur-general] PKGBUILD for zetacoin-qt-git

Thanks for your input, Doug. I didn't know that letters were verboten. Other than that one issue, the PKGBUILD looks great to me. On Sat, Nov 2, 2013 at 12:21 PM, Bruno Jimenez brunoji...@gmail.com wrote: Hi, Updated version of the PKGBUILD: http://pastebin.com/LRyYqpuZ Whoops, I misread

Re: [aur-general] PKGBUILD for zetacoin-qt-git

emails. Here's the PKGBUILD: http://pastebin.com/gVP8UeJq Thanks in advance! Bruno On Thu, 2013-10-31 at 20:33 -0400, Jeremy Audet wrote: Where is the PKGBUILD file? Can you provide a link? I think the mailing list strips attachments off emails. If so, your best bet is to use

Re: [aur-general] PKGBUILD for zetacoin-qt-git

Where is the PKGBUILD file? Can you provide a link? I think the mailing list strips attachments off emails. If so, your best bet is to use a service like pastebin or gist. --Jeremy Ichimonji10 Audet On Thu, Oct 31, 2013 at 11:27 AM, Bruno Jimenez brunoji...@gmail.comwrote: Hi, I have been

Re: [aur-general] python-sleekxmpp merge request

According to the wiki, -git should be used, not -devel. [1] Also, the PKGBUILD files can be improved. Pacman 4.1 provides the ability to clone git repos automatically, and omitting the package() function from a PKGBUILD is deprecated. See the wiki [2] or one of my packages [3] for a more modern

[aur-general] orphan request: vim-badwolf-git

I'd like to maintain the vim-badwolf-git [1] package. I flagged the package out of date, posted a comment with a link to an updated package and emailed the maintainer two weeks ago. I've gotten no response. The maintainer last updated one of his 33 packages on June 1st. [1]

Re: [aur-general] orphan request: vim-badwolf-git

Thank you. Adoped and updated. On Thu, Oct 17, 2013 at 3:22 PM, Jonathan Steel m...@jsteel.org wrote: On Thu 17 Oct 2013 at 09:28, Jeremy Audet wrote: I'd like to maintain the vim-badwolf-git [1] package. I flagged the package out of date, posted a comment with a link to an updated

Re: [aur-general] deletion requests

bump Links to AUR pages: * https://aur.archlinux.org/packages/alsa-driver.hda-intel.hda-codec-realtek-git/ * https://aur.archlinux.org/packages/alsa-driver.hda-intel.hda-codec-realtek/ --Jeremy Ichimonji10 Audet On Thu, May 23, 2013 at 9:24 AM, Jeremy Audet ichimonj...@gmail.com wrote

[aur-general] deletion requests

The following packages should be deleted: * alsa-driver.hda-intel.hda-codec-realtek * alsa-driver.hda-intel.hda-codec-realtek-git The packages are broken (I tried updating the PKGBUILDs, unsucessfully), obsolete (as per http://www.alsa-project.org/main/index.php/Download#alsa-driver) and

Re: [aur-general] nanoc3 deletion request

Xyne wrote: In general, PKGBUILDs uploaded to the AUR should adhere to all standards in such a way that they could be moved into a repo without further changes. Omitting key variables just because the AUR lacks support for them is a bad idea in my opinion. This makes sense to me. If

Re: [aur-general] nanoc3 deletion request

Just remember there is actually no use for replaces in the aur. That directive is only useful in the regular repositories. Provides and conflicts is all you actually need for a clean update. Replaces is used by pacman to find if there is anything in the repositories that replaces something

[aur-general] nanoc3 deletion request

I'm requesting the deletion of the AUR package nanoc3. [1] The AUR currently includes two similarly-named packages: nanoc and nanoc3. At one time, nanoc provided v2.x of the gem, and nanoc3 provided v3.x of the gem. [2] However, nanoc has supseded nanoc3. If you look at rubygems.org, you can see