- Aur-dev - lists.archlinux.org

[aur-dev] [PATCH] acctfuncs.inc.php: Allow translation of missing strings
by canyonknight 20 Jan '14

20 Jan '14

Signed-off-by: canyonknight <canyonknight(a)gmail.com> --- web/lib/acctfuncs.inc.php | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/web/lib/acctfuncs.inc.php b/web/lib/acctfuncs.inc.php index fe748a2..52eb551 100644 --- a/web/lib/acctfuncs.inc.php +++ b/web/lib/acctfuncs.inc.php @@ -425,7 +425,7 @@ function try_login() { $userID = valid_user($_REQUEST['user']); if ( user_suspended($userID) ) { - $login_error = "Account Suspended."; + $login_error = __('Account suspended'); } elseif ( $userID && isset($_REQUEST['passwd']) && valid_passwd($userID, $_REQUEST['passwd']) ) { @@ -490,7 +490,7 @@ function try_login() { } else { - $login_error = "Error trying to generate session id."; + $login_error = __('An error occurred trying to generate a user session.'); } } elseif (passwd_is_empty($userID)) { $login_error = __('Your password has been reset. ' . -- 1.8.5.3

2 1

[aur-dev] Split package support
by Lukas Fleischer 18 Jan '14

18 Jan '14

Hi, I changed my mind again and I think the next release should be 3.0.0, bringing full meta data and split package support. This is my idea of how split packages should be displayed: * One page per built package. Comments, votes and maintainer information are shared among packages that belong to the same PKGBUILD, though. The delete and merge functions will also operate on package bases, not on built packages. * A new pkgbase field on the package details page that is clickable and starts a package search on all packages belonging to the same base. The AUR already tags packages with properties of the corresponding binary packages (think of dependencies) and people want (need?) this, so this seems like the right thing to do. What do you think of that? Any objections? Regards, Lukas

2 4

[aur-dev] [PATCH/RFC 0/6] Promote the use of .AURINFO
by Lukas Fleischer 17 Jan '14

17 Jan '14

Check [1] for a related discussion on aur-general. What this patch series basically does is: * Tell people to use `mkaurball` (which adds .AURINFO after building) instead of `makepkg --source`. * Show a deprecation warning when people use `makepkg --source` anyway. * Add a few changes in order to make the parser work with the slightly updated .AURINFO format used by mkaurball. Comments welcome. [1] https://mailman.archlinux.org/pipermail/aur-general/2014-January/026720.html Lukas Fleischer (6): Rename "depend" field to "depends" in .AURINFO Strip whitespace from .AURINFO lines Detect split packages from .AURINFO Promote the use of mkaurball Add a warning for packages without .AURINFO pkgsubmit.php: Improve visibility of errors web/html/pkgsubmit.php | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) -- 1.8.5.3

2 8

[aur-dev] AUR 2.3.1 released
by Lukas Fleischer 13 Jan '14

13 Jan '14

Changes since 2.3.0: * Small fixes to the TU area. * Reject empty e-mail address on the password reset form. * Fixes to the typeahead plugin (fixes FS#34461, FS#34471). * Fix split package error handling (fixes FS#37496). You can check the Git log [1] for a complete list of commits. [1] https://projects.archlinux.org/aur.git/log/?id=v2.3.1

1 0

[aur-dev] [PATCH] Fix split package error handling
by Lukas Fleischer 11 Jan '14

11 Jan '14

Do not remove parentheses from the pkgname to make sure the split package detection works properly. Also, fix a regression introduced in 4bb6e88 (pkgsubmit.php: Simplify package name validation, 2013-03-05) that resulted in the split package error message never showing up. Fixes FS#37496. Signed-off-by: Lukas Fleischer <archlinux(a)cryptocrack.de> --- web/html/pkgsubmit.php | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/web/html/pkgsubmit.php b/web/html/pkgsubmit.php index d2fe512..a2ec6dd 100644 --- a/web/html/pkgsubmit.php +++ b/web/html/pkgsubmit.php @@ -180,10 +180,12 @@ if ($uid): } if (!empty($lparts)) { - # this is a variable/value pair, strip out - # array parens and any quoting, except in pkgdesc - # for pkgdesc, only remove start/end pairs of " or ' - if ($lparts[0]=="pkgdesc") { + # this is a variable/value pair, strip + # out array parens and any quoting, + # except in pkgdesc for pkgname or + # pkgdesc, only remove start/end pairs + # of " or ' + if ($lparts[0] == "pkgname" || $lparts[0] == "pkgdesc") { if ($lparts[1]{0} == '"' && $lparts[1]{strlen($lparts[1])-1} == '"') { $pkgbuild[$lparts[0]] = substr($lparts[1], 1, -1); @@ -286,8 +288,7 @@ if ($uid): $pkg_name = $new_pkgbuild['pkgname']; if ($pkg_name[0] == '(') { $error = __("Error - The AUR does not support split packages!"); - } - if (!preg_match("/^[a-z0-9][a-z0-9\.+_-]*$/", $pkg_name)) { + } elseif (!preg_match("/^[a-z0-9][a-z0-9\.+_-]*$/", $pkg_name)) { $error = __("Invalid name: only lowercase letters are allowed."); } } -- 1.8.5.2

1 0

[aur-dev] No recipient addresses found in message header
by Pierre Schmitz 11 Jan '14

11 Jan '14

Hi, I see a couple of these errors in our log. I assume we try to send a mail without any or an empty recipient. > postfix/sendmail[3523]: fatal: php-aur(992): No recipient addresses found in message header -- Pierre Schmitz, https://pierre-schmitz.com

2 2

[aur-dev] [PATCH] Forbid developers to vote
by Balló György 11 Jan '14

11 Jan '14

According to Trusted User Bylaws, TUs (and only TUs) must take part in votes. Developers who want to take part in votes should set their account type to 'Trusted User'. --- web/html/tu.php | 3 +++ 1 file changed, 3 insertions(+) diff --git a/web/html/tu.php b/web/html/tu.php index a6aa292..5d4e37d 100644 --- a/web/html/tu.php +++ b/web/html/tu.php @@ -39,6 +39,9 @@ if ($atype == "Trusted User" || $atype == "Developer") { if ($isrunning == 0) { $canvote = 0; $errorvote = __("Voting is closed for this proposal."); + } else if ($atype == "Developer") { + $canvote = 0; + $errorvote = __("Only Trusted Users are allowed to vote."); } else if ($row['User'] == username_from_sid($_COOKIE["AURSID"])) { $canvote = 0; $errorvote = __("You cannot vote in an proposal about you."); -- 1.8.5.2

2 1

[aur-dev] [PATCH] Go to package when selecting a typeahead suggestion
by Lukas Fleischer 11 Jan '14

11 Jan '14

From: Joris Steyn <jorissteyn(a)gmail.com> Directly jump to the package details when selecting an entry from the drop-down list. Implements FS#34471. Signed-off-by: Lukas Fleischer <archlinux(a)cryptocrack.de> --- web/html/home.php | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/web/html/home.php b/web/html/home.php index ddbb0fd..e80efaa 100644 --- a/web/html/home.php +++ b/web/html/home.php @@ -118,7 +118,11 @@ $(document).ready(function() { matcher: function(item) { return true; }, sorter: function(items) { return items; }, menu: '<ul class="pkgsearch-typeahead"></ul>', - items: 20 + items: 20, + updater: function(item) { + document.location = '/packages/' + item; + return item; + } }).attr('autocomplete', 'off'); }); </script> -- 1.8.5.2

3 4

[aur-dev] Git repos for AUR packages
by Lukas Fleischer 09 Jan '14

09 Jan '14

Hi, I think the idea of integrating Git with the AUR [1] is a very good one and should be a milestone for the 3.0.0 release. The idea is to create a Git repository per package. Pros: * Full history of each AUR package, even if the maintainer changes. * Lays the foundations for supporting multiple maintainers per package. * Makes it easier to contribute patches (see git-format-patch(1), branches and pull requests). * cgit might do quite a lot of the work required on the front-end side. PKGBUILD previews, history view, tarball generation, Git clone support, ... * Updating packages will be easier (`git pull` followed by `makepkg -i` instead of doing all the work from the web browser or via an AUR helper). Cons: * Needs more space on the AUR server. Currently, an AUR package uses ~17KiB on the official Arch Linux AUR server. This will probably increase by a factor of 10. Shouldn't be too problematic unless we get a lot of new packages or a lot of updates. * More load on the AUR server. Especially if we no longer store tarballs but use cgit to generate them on the fly (needs to be discussed). Migration should be easy since we can use a small shell script to convert all packages into Git repositories. The first idea is to slightly change the package submission process to extract the whole tarball, parse the PKGBUILD and do a Git commit with the tarball content. There will be an additional text field to enter a (part of the) commit message that is used. As mentioned above, all package repositories will be accessible via cgit. The PKGBUILD preview (and maybe also the tarball download) will be replaced with a simple link to cgit. Later, we should think of how to support support for git-push(1). The main issues are * Authentication: Virtual accounts, somehow connected to the AUR DB? * Integration of the PKGBUILD/.AURINFO parser: Git hook? * DoS protection: Quotas, ... Any comments and suggestions are welcome! Regards, Lukas [1] https://bugs.archlinux.org/task/23010

6 10

[aur-dev] [RFC] Per-user package submission and management
by Techlive Zheng 09 Jan '14

09 Jan '14

As I suggested in a previous mail, the package evolution would be much more community driven if AUR allows user to submit its own varient of an "official" AUR package with the URL like [2], while the "official" AUR package stays at [1]. [1]: http://aur.archlinux.org/packages/xyz [2]: http://aur.archlinux.org/account/john/packages/xyz Git Integration --------------- This functionality is similar to a Git fork on platforms like Github, but it is doable without Git. We can have this first, then consider the integration with Git. As I explained previously in another mail, it is really bad to support 'git push' for "offcial" AUR packages, (`git-push` for user's package varient is accetable, but it should have a lower priority), so the integration with Git is just simply to setup a read-only public Git interface for each package. Detailed Explaination --------------------- Each varient of the "official" AUR package should have its own votes. On the "official" AUR package page, these varients as well as their votes should be listed, and sorted by the votes, so that user will have an alternative to try if the "official" one fails to build. The difference for a varient than the "official" one should be explained on the varient's page. The style of a user's package varient page should have obviously difference to the "offcial" AUR package page, or a notification message should be shown at the top to say something like "This package is not support by AUR community, use with caution!". With per-user package submission, we will have the follwing benefits: * Easy patch submission and maintainership management * If an "official" AUR package is unmaintained for a while and the maintainer is no longer active, someone who is willing to take over the maintainership could submit its modifciation of the PKGBUILD as his package first, then ask the AUR-GENERAL list for a review of his PKGBUILD to ensure it is following the Arch's PKGBUILD standards, and then TUs can assign him as the new maintainer to the "official" AUR package. This maintainership means the "official" AUR package will use his source tarball since then. His personal package varient still exists but will be hidden from the list on the "official" AUR package page. (The technical detail depends on how this is implemented, it could be a symlink to the maintainer's package directory on the filesystem level, or a pure duplication of the maintainer's package sources, or just an internal redirection to the maintainer's package varient for the offcial package URL.) * If the maintainer of an "offcial" AUR package is active, and someone feels the "official" AUR package could be improved, he could submit his modified PKGBUILD as his package first, then send the maintainer a Patch Request, the maintainer could then do a review to see if it is worth adopting. We could implement a friendly web interface for this patch review process. If the maintainer accepts the patch, he could apply the patch on the web interface or do it manually. If the maintainer declines the patch, then the user could still maintain it as a package varient if he wants, or ask the AUR-GENERAL list for a disscution. Of course, deletion permission for a user's package varient should be granted to the user itself, he does not need to ask AUR-GENERAL list for a deletion. If consider the integration with Git, this should be implemented similar to a Git Pull Request but simpler. For AUR, I do not think we need something as complicated as Pull Request. Pull Request in a platform like Github usually means a non-fastward merge with full change history on both merge sides. We do not need detailed change history, a new commit with final changes that makes our "official" AUR package better is enought, so, "Patch Request" might be proper. * Better package outdate flagging mechanism With per-user package submission, we could implement a better outdate flagging mechanism. When someone flags a package outdated, he needs to provide the newest `pkgver` number. With this `pkgver` number, all varients of this package will be checked and flagged if outdated. On the "official" AUR package's page, only these updated package varients will be shown, others will be marked in red and hided (needs a clik to show). * Package deletion and merging handling Package deletion and merging is only for "official" AUR packages. User can keep and maintain what ever package varient he wants as his own. * If an "official" AUR package is deleted by TUs for some reasons (proprietary software, un-standard naming convention, or being merged into other package, etc), the entry for this package (basically the name) should be kept in the database, as well as the reason why it is deleted, so that when a user visits the page or attempts to create it again, he will know why this package is not supported by the AUR community. If he insists it is resonable to create such a package, he could request it in AUR-GENERAL list for TUs attention, or he can just maintain it as its own package, but no AUR "official" version exists. For package varients whose "official" version is deleted, a notable notification should be alarmed at the top of varient's page, so that the user will know this package is not supported by the community, thus has no "official" version exists, and why, and what alternatives are recommended to choose. * If a never-existent package was created, then the "official" package will be automatically created, and the maintainer is assigned to the one who uploaded this package in the first palce. With per-user package submission, we could unify all the PKGBUILDs to AUR, easy to search, easy to review, absolutely community-oriented evolution for packages. (Currently, people store PKGBUILDs in all kinds of places, Github, Pastebin, and no integration with AUR.) Possible Cons ------------- * Lots of package varients Yes, but it is easier to keep the "official" one alive and updated, and let the user's package varient die naturally, it does not matter. For packages no one is willing to maintain, we can just remove the maintainer and mark the "official" AUR package inactive and disable the download. The PKGBUILD still can be found in the users' package varient, just the AUR doesn't have a "official" one due to lacking of a maintainer, until someone step in and take the responsiblity to maintain it. We can deal with thousands of outdated, unmaintained packages in AUR this way, nothing loss, nothing hurt. * More complicated AUR structure Is it? I think it should be easy to people who use Linux, especially Arch Linux, right? End Notes --------- This is some of my thoughts about how improves the AUR, comments and discussions are highly welcome. After all, I just to help making the Arch Linux better and better.

1 1