Talk:Arch User Repository

What is the correct AUR forum section?

Arch_User_Repository#Submitting_packages says it's [1], but we also have [2]. One of them should be added to Arch_User_Repository#I_have_a_PKGBUILD_I_would_like_to_submit.3B_can_someone_check_it_to_see_if_there_are_any_errors.3F. -- Karol (talk) 12:30, 7 August 2015 (UTC)

Markdown Syntax

Should there be a Markdown syntax section? [3][4] All those seem to work: link —Det^talk 16:24, 5 December 2017 (UTC)

Oh wow, yes please. I had no idea that this was possible. And it's still unclear to me what syntax it uses. —Ostiensis (talk) 20:52, 5 December 2017 (UTC)

Well, there's a preliminary section: Arch_User_Repository#Comment_syntax. --Det^talk 22:28, 13 December 2017 (UTC)

[5] Well, I don't know how to do that, since they only implemented a small part of it? --Det^talk 22:35, 13 December 2017 (UTC)

Here they use the Python-Markdown library, which "is almost completely compliant with the reference implementation, though there are a few very minor differences." -- Lahwaacz (talk) 22:50, 13 December 2017 (UTC)

Thanks for that. FWIW I've never seen that multiline code syntax before, so I wonder if it *is* some strange home-brew markdown. —Ostiensis (talk) 22:37, 13 December 2017 (UTC)

FAQ - outdated package

Do you understand what the comment means "When we are talking about a package which is flagged out of date for more than 3 months and is in general not updated for a long time, please add this in your orphan request. " ? Kewl (talk) 15:49, 13 January 2018 (UTC)

When people request a package to be orphaned because the current maintainer does not respond to out-of-date notifications, it should be clarified in the request to speed up the resolution. -- Lahwaacz (talk) 18:05, 13 January 2018 (UTC)

Yes indeed and what about the 2 weeks vs the 3 months difference in the comments? This is what I don't get, if this is more than 3 months we should say in the comments "it has been 4 months" but if it has been let say 2 months we should not mention it? The rule is not clear and I am wondering if it is more urgent to find an adopter for a package that has not been updated for 2 years or for 3 weeks. In the latter case it does seem more urgent, rather the opposite then. Kewl (talk) 18:57, 13 January 2018 (UTC)

I think that the 2 weeks are for the maintainers to react to the request, even if it is not due to out-of-date package. Anyway, the FAQ entries are not strict, I doubt that the 3 months are obligatory. -- Lahwaacz (talk) 19:15, 13 January 2018 (UTC)

I have rephrased providing some more details in line with the AUR request template. The 3 months does not seems to be anything official, the 2 weeks neither but sounds reasonable. Feel free to amend or revert. Kewl (talk) 19:41, 13 January 2018 (UTC)

Creating a new package: uploading an existing package to AUR

I have some issues with the new language introduced here, primarily that it is overly verbose, see inline comments. quequotion (talk) 16:28, 6 January 2019 (UTC)

I understand you'd prefer more time to debate, but I did consider this a minor correction as much of the language is redundant and technically inaccurate. quequotion (talk) 19:36, 6 January 2019 (UTC)

But it included multiple changes, including both the minor merging of redundant content and the non-minor removal of a policy recommendation using an edit message that was marked as minor and only specified the former... -- Eschwartz (talk) 19:57, 6 January 2019 (UTC)

If there are no objections, I plan to merge this proposal soon. quequotion (talk) 16:36, 15 January 2019 (UTC)

This makes 3 changes. Change #1, specifying PKGBUILD#Version and merging up "otherwise the AUR will not show updated version numbers", I am okay with. Change #2, relegating minor changes to a tip, I haven't changed my mind on -- I still think it should be a "do not" rather than a "you don't have to if you don't want to", and thus disagree with the change. Change #3, linkifying PKGBUILD and .SRCINFO, is confusing since now the latter is linkified twice, and the former is only linkified because the first reference to the PKGBUILD has disappeared from the preceding paragraph. -- Eschwartz (talk) 17:11, 15 January 2019 (UTC)

Thanks for the feedback. I've reintegrated the tip with the paragraph; still avoiding explicitly saying "do not", but meaning the same thing. Regarding the links, I feel like the best way to resolve that is to move "When updating.." to a Template:Note (because it is an aside; not required for every update) below "To upload..", which comes almost full circle to combining it with the note about retroactively adding .SRCINFO to the first commit. If Since we are keeping the git tutorial, it makes sense for it to be between them, as the second note is relevant to when this procedure fails in the case that .SRCINFO is missing from the initial commit.

Also, not terribly important, but the tip about .gitignore fits more logically under "To upload..." than at the end of the section. This is a complex change in the draft, but of course I would do this in stages on the actual article. quequotion (talk) 03:41, 16 January 2019 (UTC)

"update its version accordingly and regenerate .SRCINFO; otherwise the AUR will not show updated version numbers" -- this sort of sounds like failure to show updated version numbers is also the issue with not updating the PKGBUILD version. I guess this is not an issue if people think that, but it's awkward wording nevertheless. -- Eschwartz (talk) 04:11, 16 January 2019 (UTC)

Once again, thank you for the feedback. I thought of a lot of other ways to word this, but I kept coming around to the best solution being to delete this line and let users read this stuff on the PKGBUILD and .SRCINFO pages. Since we're not doing that, my compromise is to reword it as a positive course of action (rather than a warning) and try to be slightly more informative as well (version is not the only thing that may need updating in .SRCINFO) quequotion (talk) 14:22, 19 January 2019 (UTC)

I broke it into two bullets instead. What do you think of Special:Diff/564012? -- Eschwartz (talk) 03:15, 20 January 2019 (UTC)

I contracted the language a bit, but yes it makes more sense as two points. Lengthy bulleted lists are a navigation issue (the reason I'm thinking of rewriting the Other requests section) but just two or three points is fine. quequotion (talk) 20:19, 21 January 2019 (UTC)

I've been out of this discussion for a while so I won't insist too much, but I don't like keeping "When updating a package..." and "Remember to regenerate .SRCINFO..." in a Note, since those are things that must be done most of the times anyway, and now the section looks like a patchwork of colored boxes, not very readable IMO :)

I'd reinstate those two points above the "To upload or update a package" paragraph.

For the same reason (improve readability) I'd also keep the ".gitignore" Tip at the bottom, since the example of course doesn't deal with .gitignore, and it looks out of context when sandwiched between those Tips/Notes.

-- Kynikos (talk) 16:11, 20 January 2019 (UTC)

I agree about the patchwork look, but I think these points are best to be in a note--if they are really required on the page at all--as they are covered on the respective PKGBUILD and .SRCINFO pages already. These are reminders, and I think the best we can do with them is make them as short and easy to grasp as possible while linking back to the respective pages. It might help to (re)merge them with the note below the tutorial as a bulleted list with three points.

If the tip about .gitignore is at the end of the section, users will not know about it until they've already uploaded a package to the AUR (assuming most users execute the instructions on the page while reading them); not that they couldn't do it later, but I feel it's more logical to have this above the tutorial so that users may choose to do it before accidentally sending anything unnecessary to the AUR. 20:19, 21 January 2019 (UTC)

It looks okay to me right now, except I'm not sure what the point of modifying the third bullet in Special:Diff/564330 was. Specifically I think it makes more grammatical sense to use "your" not "the". Also needs to adapt to Special:Diff/564909. -- Eschwartz (talk) 04:01, 27 January 2019 (UTC)

I had in mind that the article should be impersonal, but it is kind of impossible to be purely so (the "your" in the warning about git credentials, for example, really can't be replaced). Not really important if there's no policy about it. Revised and updated. quequotion (talk) 06:05, 28 January 2019 (UTC)

I think we have sufficient consensus and its been over a week without comment, so I went ahead and merged the proposal. Closing. quequotion (talk) 16:56, 5 February 2019 (UTC)

Previous: Publishing new package content

Warning: Your commits will be authored with your global Git name and email address. It is very difficult to change commits after pushing them (FS#45425). If you want to push to the AUR under different credentials, you can change them per package with git config user.name "..." and git config user.email "...".

When releasing a new version of the packaged software,

Comment: To be technically correct, only pkgver should be updated when releasing a new version of the packaged software and pkgrel should be updated when releasing a new version of the PKGBUILD. This is documented on the PKGBUILD page, so I'd rather remove this than be more specific here. —This unsigned comment is by Quequotion (talk) 7 January 2019. Please sign your posts with ~~~~!

I'm okay with the wording that you've used below ("When updating a package..."). -- Kynikos (talk) 15:39, 20 January 2019 (UTC)

update the pkgver or pkgrel variables

Comment: I'm tempted to link to PKGBUILD#Version here instead, so as not to ignore epoch (even if it should only rarely be used), and to encourage users to thoroughly read these sections on the PKGBUILD page. —This unsigned comment is by Quequotion (talk) 7 January 2019. Please sign your posts with ~~~~!

I'm okay too. -- Kynikos (talk) 15:32, 20 January 2019 (UTC)

to notify all users that an upgrade is needed.

Comment:

The AUR does not send notifications out; users have to check for updates. —This unsigned comment is by Quequotion (talk) 7 January 2019. Please sign your posts with ~~~~!

That sounds needlessly semantic since users checking for updates will be notified by the fact that the pkgver/pkgrel has been updated, which was how I understood the wiki anyway. -- Eschwartz (talk) 18:49, 6 January 2019 (UTC)

I disagree, but more importantly its redundant with "otherwise the AUR will not show updated version numbers". The statements about updating pkgver/pkgrel and regenerating .SRCINFO can be merged, and removing a technical inaccuracy while reducing redundancy seems like a good idea to me. quequotion (talk) 19:36, 6 January 2019 (UTC)

Then that's a much better rationale (although I still don't see it as a technical inaccuracy) and should have been specified in the first place. I'm not sure why it needs to be repeated in a new paragraph, maybe to highlight the need? If so, could it be reworded to only mention this in the second paragraph? Kynikos, what was your motivation for that specific wording? -- Eschwartz (talk) 20:00, 6 January 2019 (UTC)

Sorry for the delay, I didn't have a particular motivation for that wording, I'm perfectly fine if you want to change it, as long as there's still an explicit reminder to update the PKGBUILD version variables. As Eschwartz also guessed above, I didn't use "to notify all users" literally implying that notifications are sent out, but in the sense of "to let all users know", or "so that all users can know/understand" that an upgrade is needed. -- Kynikos (talk) 15:22, 20 January 2019 (UTC)

Do not update

Comment:

I don't feel comfortable explicitly telling people not to update for any particular reason. As I said, it is convenient that this is optional, but if people want to update pkgrel to fix a typo, that's fine too. I worry saying "Do not..." here will lead to someone spending too much time wondering if the changes they've made to their package are worth an update or not, and/or not updating when it would be advisable to do so. Rather than specify a policy, I think it's better to let users figure out they can do this on their own. —This unsigned comment is by Quequotion (talk) 7 January 2019. Please sign your posts with ~~~~!

We specifically added this by request in #Current: Uploading packages and I agree with the rationale there. -- Eschwartz (talk) 18:46, 6 January 2019 (UTC)

If it is necessary to mention this at all, it would be better to say "It is not necessary to update", except that it is long. I feel "Do not" makes a policy statement we could come to regret. I should add, I was surprised to see this particular advice on the page at all; my interpretation of the discussion was that Kynikos's priority was to have a suggestion to update pkgver and pkgrel on the page, and that my bringing up that this can be avoided for convenience was an aside and not meant to shape policy. Ergo, I have relegated that point to a Template:Tip where I think it belongs. quequotion (talk) 17:05, 11 January 2019 (UTC)

You're correct about my priority, my only interest here is that there's an explicit reminder to update PKGBUILD#Version.

This has been discussed also in the parent section, I haven't understood if Eschwartz now is ok with relaxing the strength of the statement, anyway I'll leave any PKGBUILD policy decisions to the TUs, so by default I side Eschwartz here.

-- Kynikos (talk) 15:51, 20 January 2019 (UTC)

those values if only minor changes to the PKGBUILD such as the correction of a typo are being published.

Be sure to regenerate .SRCINFO whenever PKGBUILD metadata changes, such as pkgver() updates; otherwise the AUR will not show updated version numbers.

Comment: I think these can be combined and would be better placed after the following, which describes process for both the initial upload and subsequent updates. —This unsigned comment is by Quequotion (talk) 7 January 2019. Please sign your posts with ~~~~!

It looks like this is being discussed in the parent section. -- Kynikos (talk) 15:53, 20 January 2019 (UTC)

Yeah, I didn't really intend Template:Comment to be a place to have discussions so much as to (briefly) indicate precisely which content needs discussion and why--not that I mind having discussions in them either. There's no policy in place, but if a discussion is going to be long it should probably be had in the parent section. quequotion (talk) 20:19, 21 January 2019 (UTC)

To upload or update a package, add at least PKGBUILD and .SRCINFO, then any additional new or modified helper files (such as .install files or local source files such as patches), commit with a meaningful commit message, and finally push the changes to the AUR.

Comment:

I might consider agreeing on a more schematic wording as a compromise, to clarify which are supposed to be the separate commands to run; for example:

To upload a new or updated package:

1. Regenerate .SRCINFO;
2. Add at least PKGBUILD and .SRCINFO to the repository index;
   • Also add any additional new or modified helper files (such as .install files or local source files such as patches);
3. Commit with a meaningful commit message;
4. Push the changes to the AUR.

-- Kynikos (talk) 18:26, 7 December 2018 (UTC)

For example:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push

Note: If .SRCINFO was not included in your first commit, add it by rebasing with --root or filtering the tree so the AUR will permit your initial push.

Tip: To keep the working directory and commits as clean as possible, create a gitignore(5) that excludes all files and force-add files as needed.

Current: Publishing new package content

Warning: Your commits will be authored with your global Git name and email address. It is very difficult to change commits after pushing them (FS#45425). If you want to push to the AUR under different credentials, you can change them per package with git config user.name "..." and git config user.email "...".

To upload or update a package add at least PKGBUILD and .SRCINFO then any new or modified .install files, patches or other local source files; commit with a meaningful commit message, and finally push the changes to the AUR.

Tip: To keep the working directory and commits as clean as possible, create a gitignore(5) that excludes all files and force-add files as needed.

For example:

$ makepkg --printsrcinfo > .SRCINFO
$ git add -f PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push

Note:

• After modifying a package, except for very minor changes (such as fixing a typo) that would not require re-installation of the package, update its version accordingly.
• Regenerate .SRCINFO after updating such PKGBUILD metadata in order to publish it in the AUR.
• If .SRCINFO was not added before your first commit, add it by rebasing with --root or filtering the tree so the AUR will permit your initial push.

contribute to existing package

what is the best way to contribute to an existing AUR package? i cloned one and tried to push but it gave me a permission error --Soloturn (talk) 16:04, 28 January 2019 (UTC)

Users are not allowed to modify something owned by another user. It's no different from cloning a Github repository and trying to push to that. The equivalent of submitting an issue would be leaving a comment with a patch file. The AUR platform in particular allows collaboration features -- you may request that a maintainer grant you push access by adding your name as a co-maintainer. If the package is broken or out of date, see Arch User Repository#Foo in the AUR is outdated; what should I do?

This is possibly something that we should make clear in a FAQ entry. -- Eschwartz (talk) 19:49, 28 January 2019 (UTC)

I was thinking about this while writing a proposal regarding "Other requests". It is possible to request a package be disowned with "Orphan"; why not add "Co-maintain" to send a request to ask for permission to assist with a package's maintenance? Of course, it would not be unnecessary to send that request to the mailing list, and there's always the AUR comments or the forums for users to contact a maintainer otherwise; but having the feature built in to the AUR would allow us to add a fourth subsection here to recommend ground rules and possibly expedite the process of adding co-maintainers when packagers are interested in doing so. quequotion (talk) 14:45, 6 February 2019 (UTC)

Other requests rewrite

My main gripe with the current content here is that it has a bulleted list directly embedded in a bulleted list. Bulleted lists are not navigable and I think it would be helpful to have subsections to define what "Deletion" "Merge" and "Orphan" mean in AUR jargon. Some other, lower priority changes I'd like to consider include specifying the requests in the same order they appear in the drop-down menu on the AUR (they may be in the order of a previous iteration of the AUR, not sure if that's ever changed); simplifying the language where possible, and a few minor grammatical fixes. quequotion (talk) 14:28, 6 February 2019 (UTC)

Current: Other requests

Orphan, deletion and merge requests can be created by clicking on the "Submit Request" link under "Package Actions" on the right hand side. This automatically sends a notification email to the current package maintainer and to the aur-requests mailing list for discussion. Trusted Users will then either accept or reject the request.

• Orphan requests will be granted after two weeks if the current maintainer did not react.
• Merge requests are to delete the package base and transfer its votes and comments to another package base. The name of the package base to merge into is required. Note this has nothing to do with 'git merge' or GitLab's merge requests.
• Deletion requests require the following information:
  • A short note explaining the reason for deletion. Note that a package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-requests mailing list.
  • Supporting details, like when a package is provided by another package, if you are the maintainer yourself, it is renamed and the original owner agreed, etc.
  • Deletion requests can be rejected, in which case if you are the maintainer of the package you will likely be advised to disown the package to allow adoption by another packager.
  • After a package is deleted, its Git repository remains available in the AUR.

Proposal: Other requests

Deletion, merge, and orphan requests can be created by clicking on the "Submit Request" link under "Package Actions" on the right hand side. This will send a notification email to the current maintainer and to the aur-requests mailing list for discussion. A Trusted User will then either accept or reject the request.

Deletion

You may request to unlist a pkgbase from the AUR. A short note explaining the reason for deletion is required, as well as supporting details (like when a package is provided by another package, if you are the maintainer yourself, it is renamed and the original owner agreed, etc).

Note:

• It is not sufficient to explain why a package is up for deletion only in its comments because as soon as a TU takes action, the only place where such information can be obtained is the aur-requests mailing list.
• Deletion requests can be rejected, in which case if you are the maintainer you will likely be advised to disown the package to allow adoption by another maintainer.
• After a package is "deleted", its git repository remains available for cloning.

Merge

You may request to delete a pkgbase and transfer its votes and comments to another pkgbase. The name of the package to merge into is required.

Note: This is AUR-specific and not a git function.

Orphan

You may request that a pkgbase be disowned. These requests will be granted after two weeks if the current maintainer did not react.

Integrate FAQ content

This will be a massive undertaking, possibly spanning multiple articles, but I think it will be helpful to preempt a lot of these questions by having a more concise, informative page. Rather than do a full mock-up for all of the potential changes, I'd rather talk about the changes that could be made in the comments below and do mock-ups of individual sections if requested or otherwise make the discussed changes directly to the page(s) upon reaching consensus.

Comments regarding the idea (of integrating the FAQ into the article) itself should go in this heading. quequotion (talk) 16:34, 6 February 2019 (UTC)

Current: FAQ

What is the AUR?

The AUR (Arch User Repository) is a place where the Arch Linux community can upload PKGBUILDs of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the community repository to be shared with Arch Linux users in binary form.

Comment: This is redundant with the page header; any useful differences should be merged there. quequotion (talk) 16:34, 6 February 2019 (UTC)

What kind of packages are permitted on the AUR?

The packages on the AUR are merely "build scripts", i.e. recipes to build binaries for pacman. For most cases, everything is permitted, subject to the abovementioned usefulness and scope guidelines, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e. contents that are not redistributable, you may only use the file name itself as the source. This means and requires that users already have the restricted source in the build directory prior to building the package. When in doubt, ask.

Comment: This could be made clear in the Rules of submission by adding an additional rule to the effect of "packages must not violate licensing terms of their content" and merging useful language from here. quequotion (talk) 16:34, 6 February 2019 (UTC)

How can I vote for packages in the AUR?

Sign up on the AUR website to get a "Vote for this package" option while browsing packages. After signing up it is also possible to vote from the commandline with aurvote^AUR, aurvote-git^AUR or aur-auto-vote-git^AUR.

Alternatively, if you have set up ssh authentication as above, you can directly vote from the command line using your ssh key. This means that you won't need to save or type in your AUR password.

ssh aur@aur.archlinux.org vote <PACKAGE_NAME>

Comment: This could be integrated in the Feedback section as a subsection about voting.

What is a Trusted User / TU?

A Trusted User, in short TU, is a person who is chosen to oversee AUR and the community repository. They are the ones who maintain popular PKGBUILDs in community, and overall keep the AUR running.

Comment: Trusted Users is mentioned and linked to several times on the page; users can follow the links to find this out. quequotion (talk) 16:34, 6 February 2019 (UTC)

What is the difference between the Arch User Repository and the community repository?

The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with makepkg. When PKGBUILDs receive enough community interest and the support of a TU, they are moved into the community repository (maintained by the TUs), where the binary packages can be installed with pacman.

Comment: This and #How_to_get_a_PKGBUILD_into_the_community_repository should be merged into their own section; some of this is redundant with the page header. quequotion (talk) 16:34, 6 February 2019 (UTC)

Foo in the AUR is outdated; what should I do?

First, you should flag the package out-of-date indicating details on why the package is outdated, preferably including links to the release announcement or the new release tarball. You should also try to reach out to the maintainer directly by email. If there is no response from the maintainer after two weeks, you can file an orphan request. This means you ask a Trusted User to disown the package base. This is to be done only if the package requires maintainer action, that he/she is not responding and you already tried to contact him/her previously.

In the meantime, you can try updating the package yourself by editing the PKGBUILD locally. Sometimes, updates do not require changes to the build or package process, in which case simply updating the pkgver or source array is sufficient.

Note: VCS packages are not considered out of date when the pkgver changes, do not flag them as the maintainer will merely unflag the package and ignore you. AUR maintainers should not commit mere pkgver bumps.

Comment: I think there's a place for this in Feedback quequotion (talk) 16:34, 6 February 2019 (UTC)

Foo in the AUR does not compile when I run makepkg; what should I do?

You are probably missing something trivial.

1. Upgrade the system before compiling anything with makepkg as the problem may be that your system is not up-to-date.
2. Ensure you have both base and base-devel groups installed.
3. Try using the -s option with makepkg to check and install all the dependencies needed before starting the build process.

Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question. The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It is also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.

To check if the PKGBUILD is broken, or your system is misconfigured, consider building in a clean chroot. It will build your package in a clean Arch Linux environment, with only (build) dependencies installed, and without user customization. To do this install devtools and run extra-x86_64-build instead of makepkg. For multilib packages, run multilib-build See DeveloperWiki:Building in a clean chroot for more information. If the build process still fails in a clean chroot, the issue is probably with the PKGBUILD.

Comment: The AUR-specific content (check comments, etc) could be merged into Feedback; the rest should be available on other pages like PKGBUILD or makepkg, and linked to from the page; maybe we could add a subsection like "Proofing packages" that would explain about namcap and DeveloperWiki:Building in a clean chroot, etc.. quequotion (talk) 16:34, 6 February 2019 (UTC)

ERROR: One or more PGP signatures could not be verified!; what should I do?

Most likely you do not have the required public key(s) in you personal keyring to verify downloaded files. If one or more .sig files are downloaded while building the package, makepkg will automatically verify corresponding file(s) with the public key of its signer. If you do not have the required key in your personal keyring, makepkg will fail to do the verification.

The recommended way to deal with this problem is to import the required public key, either manually or from a key server. Often, you can simply find the fingerprint of the needed public key(s) in the validpgpkeys section of the PKGBUILD.

Comment: This belongs on the Makepkg page if it isn't already there. quequotion (talk) 16:34, 6 February 2019 (UTC)

How do I create a PKGBUILD?

The best resource is the wiki page about creating packages. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.

Comment: This could be integrated with the header of Submitting and maintaining packages. quequotion (talk) 16:34, 6 February 2019 (UTC)

I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?

If you would like to have your PKGBUILD reviewed, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the IRC channel, #archlinux-aur on irc.freenode.net. You can also use namcap to check your PKGBUILD and the resulting package for errors.

Comment: Mostly redundant with Submitting packages' header; maybe we could add a subsection like "Proofing packages" that would explain about namcap and DeveloperWiki:Building in a clean chroot, etc. quequotion (talk) 16:34, 6 February 2019 (UTC)

How to get a PKGBUILD into the community repository?

Usually, at least 10 votes are required for something to move into community. However, if a TU wants to support a package, it will often be found in the repository.

Reaching the required minimum of votes is not the only requirement, there has to be a TU willing to maintain the package. TUs are not required to move a package into the community repository even if it has thousands of votes.

Usually when a very popular package stays in the AUR it is because:

• Arch Linux already has another version of a package in the repositories
• Its license prohibits redistribution
• It helps retrieve user-submitted PKGBUILDs. AUR helpers are unsupported by definition.

See also Rules for Packages Entering the community Repo.

Comment: This deserves its own section on the page, ie "Submitting packages to the community repository" quequotion (talk) 16:34, 6 February 2019 (UTC)

How can I speed up repeated build processes?

See Makepkg#Improving compile times.

Comment: Not really AUR-relevant; sufficiently available on the Makepkg page. quequotion (talk) 16:34, 6 February 2019 (UTC)

What is the difference between foo and foo-git packages?

Many AUR packages are presented in regular ("stable") and development versions ("unstable"). A development package usually has a suffix such as -cvs, -svn, -git, -hg, -bzr or -darcs. While development packages are not intended for regular use, they may offer new features or bugfixes. Because these packages download the latest available source when you execute makepkg, a package version to track possible updates is not directly available for these. Likewise, these packages cannot perform an authenticity checksum, instead it is relied on the maintainer(s) of the Git repository.

See also System maintenance#Use proven software packages.

Comment: Not sure what to do with this and the remaining sections. quequotion (talk) 16:34, 6 February 2019 (UTC)

Why has foo disappeared from the AUR?

It is possible the package has been adopted by a TU and is now in the community repository.

Packages may be deleted if they did not fulfill the #Rules of submission. See the aur-requests archives for the reason for deletion.

If the package used to exist in AUR3, it might not have been migrated to AUR4. See the #Git repositories for AUR3 packages where these are preserved.

How do I find out if any of my installed packages disappeared from AUR?

The simplest way is to check the HTTP status of the package's AUR page:

$ comm -23 <(pacman -Qqm | sort) <(curl https://aur.archlinux.org/packages.gz | gzip -cd | sort)

How can I obtain a list of all AUR packages?

• https://aur.archlinux.org/packages.gz
• Use aurpkglist from python3-aur^AUR

Proposal: Feedback

Comment: Integrates two FAQ subsections and the "Comment Syntax" section into the "Feedback" section. quequotion (talk) 18:37, 6 February 2019 (UTC)

The AUR provides various means for users to communicate with package maintainers, provided they have setup an account on the AUR Web Interface.

Commenting on packages

Comments allow users to provide suggestions and respond to updates. The Python-Markdown syntax is supported, which provides basic Markdown syntax for formatting.

Note:

• This implementation has some occasional differences with the official syntax rules.
• Commit hashes to the Git repository of the package and references to Flyspray tickets are converted to links automatically.
• Long comments are collapsed and can be expanded on demand.

Tip: Avoid pasting patches or PKGBUILDs into the comments section; they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a pastebin.

Voting for packages

One of the easiest activities for all Arch users is to browse the AUR and vote for their favourite packages. All packages are eligible for adoption by a TU for inclusion in the community repository, and the vote count is one of the considerations in that process; it is in everyone's interest to vote!

While logged in, on the AUR page for a package you may click "Vote for this package" under "Package Actions" on the right. It is also possible to vote from the commandline with aurvote^AUR, aurvote-git^AUR or aur-auto-vote-git^AUR.

Alternatively, if you have set up ssh authentication, you can directly vote from the command line using your ssh key and avoid having to save or type in your AUR password.

ssh aur@aur.archlinux.org vote <PACKAGE_NAME>

Marking packages out-of-date

While logged in, on the AUR page for a package you may click "Flag package as out-of-date" under "Package Actions" on the right. You should also leave a comment indicating details as to why the package is outdated, preferably including links to a release announcement or a new release tarball. Also try to reach out to the maintainer directly by email. If there is no response after two weeks, you may file an orphan request.

Tip: In the meantime, you can try updating the package yourself by editing the PKGBUILD locally. Sometimes, updates do not require changes to the build or package process, in which case simply updating the pkgver or source array is sufficient.

Note: VCS packages are not considered out of date when the pkgver changes, do not flag them as the maintainer will merely unflag the package and ignore you.