- Aur-dev - lists.archlinux.org

AUR Popularity Data Questionnaire (archives)
by Kevin Morris 23 Sep '22

23 Sep '22

Hello AUR consumers, This question is for projects who use (or intend to use) the AUR's archive data. I'm trying to gather the best route for our git repository archives which will soon be released. The issue at hand: - The AUR needs to reduce its bandwidth usage as much as possible, while still satisfying consumers. Let's say in a world where 5% of archive consumers need Popularity data, then we would be pretty much wasting bandwidth serving popularity data to the other 95%. Ideas for working around this: - If Popularity data is only needed by a small amount of consumers, we're thinking about serving out a `popularity.git` repository and excluding popularity data from `metadata.git`. This means that clients that need the popularity data would need to consume two repositories, which complicates the consumption process, but popularity.git would not be shared with those who don't need it. Depending on information we gather, we may keep with popularity data being housed inside of `metadata.git`, as we have a new popularity calculation method which reduces the amount of changes drastically. As a project maintainer which wants to use AUR archives, could you please answer the following: 1. What's the project? 2. Do you need Popularity? - Why? Thanks a lot for your time; any input here helps a ton. If you want some information about the current devel of the git repository archives, see https://gitlab.archlinux.org/kevr/aurweb/-/blob/git-archives/doc/git-archiv… This state does not currently reflect our new popularity strategy, but it does show the general structure of repositories generated for these archives. Regards, Kevin -- Kevin Morris Software & Linux Enthusiast

1 0

Re: Swedish Translation aurweb
by Luna Jernberg 12 Aug '22

12 Aug '22

Translating some more now On Fri, Dec 24, 2021 at 5:38 PM Kevin Morris <kevr(a)0cost.org> wrote: > :) Thanks a lot for the translation help! > > Regards, > Kevin > > On Fri, Dec 24, 2021 at 04:03:30PM +0100, Luna Jernberg wrote: > > Hello! > > > > Started helping out a bit with the Swedish translation of aurweb now, > have > > done 21 strings so far > > -- > Kevin Morris > Software Developer > > Identities: > - kevr @ Libera >

1 3

fake up an AUR RPC responder?
by Greg Minshall 08 Aug '22

08 Aug '22

hi. i'm doing some coding around AUR, and appear to have gone over the daily limit (apologies for which). i'm wondering if anyone knows of (or has) any simple code that would use, e.g., `packages-meta-ext-v1.json.gz`, the AUR metadata pointed at here: ---- https://lists.archlinux.org/pipermail/aur-general/2021-November/036659.html ---- or any other information, to present a responder to the AUR RPC protocol? to be clear: i don't want to mirror aur.archlinux.org, just the search/info from as described in https://wiki.archlinux.org/title/Aurweb_RPC_interface so i can bang on it locally without consuming resources on aur.archlinux.org. cheers, Greg

2 2

SSH commit signatures on AUR
by Sebastian Wiesner 04 Apr '22

04 Apr '22

Hello, AUR uses SSH keys for authentication, and since a few months Git can sign commits with SSH keys. Would there be interest in combining this to somehow mark packages as verified if HEAD has a valid signature from an SSH key registered in the profile of any maintainer of that package? I don't think it'd add much in terms of security per se, but I think it'd help to encourage and spread commit signing on the AUR. That's a good thing per se, imho, but I think it'd also simplify trust management a lot, especially when automatically building many AUR packages. Currently you always need an extra RPC call to the AUR to obtain reliable maintainer information for every package, because the git clone itself doesn't carry any trust information at all. With signing however you could just scrape SSH keys from maintainers you trust every once in a while, and assemble those into an ALLOWED_SIGNERS files for "git verify-commit". Asserting that a package HEAD is trusted would then come down to a simple "git verify- commit". For this to work AUR would need to publicly expose SSH keys in user profile packages, which definitely requires some care wrt to privacy. Another challenge would be to make a UI which clearly indicates that "verified" only means the HEAD was signed by a maintainer, not that the Arch team or a TU has actually verified the PKGBUILD, let alone the package contents. But if there's interest in the feature, I'd be happy to start working on a patch to aurweb to contribute this feature. Kind regards, Basti

4 6

[PATCH] right align statistics values on dashboard page (fixes #190)
by Erik Bender 14 Feb '22

14 Feb '22

--- templates/partials/packages/statistics.html | 16 ++++++++-------- templates/partials/statistics.html | 4 ++-- web/html/css/aurweb.css | 4 ++++ 3 files changed, 14 insertions(+), 10 deletions(-) diff --git a/templates/partials/packages/statistics.html b/templates/partials/packages/statistics.html index 8a6546b9..676b78d6 100644 --- a/templates/partials/packages/statistics.html +++ b/templates/partials/packages/statistics.html @@ -4,47 +4,47 @@ <table> <tr> <td class="stat-desc">{{ "Packages" | tr }}</td> - <td>{{ package_count }}</td> + <td class="stat-val">{{ package_count }}</td> </tr> <tr> <td class="stat-desc">{{ "Orphan Packages" | tr }}</td> - <td>{{ orphan_count }}</td> + <td class="stat-val">{{ orphan_count }}</td> </tr> <tr> <td class="stat-desc"> {{ "Packages added in the past 7 days" | tr }} </td> - <td>{{ seven_days_old_added }}</td> + <td class="stat-val">{{ seven_days_old_added }}</td> </tr> <tr> <td class="stat-desc"> {{ "Packages updated in the past 7 days" | tr }} </td> - <td>{{ seven_days_old_updated }}</td> + <td class="stat-val">{{ seven_days_old_updated }}</td> </tr> <tr> <td class="stat-desc"> {{ "Packages updated in the past year" | tr }} </td> - <td>{{ year_old_updated }}</td> + <td class="stat-val">{{ year_old_updated }}</td> </tr> <tr> <td class="stat-desc"> {{ "Packages never updated" | tr }} </td> - <td>{{ never_updated }}</td> + <td class="stat-val">{{ never_updated }}</td> </tr> <tr> <td class="stat-desc"> {{ "Registered Users" | tr }} </td> - <td>{{ user_count }}</td> + <td class="stat-val">{{ user_count }}</td> </tr> <tr> <td class="stat-desc"> {{ "Trusted Users" | tr }} </td> - <td>{{ trusted_user_count }}</td> + <td class="stat-val">{{ trusted_user_count }}</td> </tr> </table> </div> diff --git a/templates/partials/statistics.html b/templates/partials/statistics.html index 0bf844b6..2a6f69db 100644 --- a/templates/partials/statistics.html +++ b/templates/partials/statistics.html @@ -10,7 +10,7 @@ {{ "Packages" | tr }} </a> </td> - <td>{{ bases.count() }}</td> + <td class="stat-val">{{ bases.count() }}</td> </tr> {% set out_of_date_packages = bases | out_of_date %} <tr> @@ -19,7 +19,7 @@ {{ "Out of Date" | tr }} </a> </td> - <td>{{ out_of_date_packages.count() }}</td> + <td class="stat-val">{{ out_of_date_packages.count() }}</td> </tr> </tbody> </table> diff --git a/web/html/css/aurweb.css b/web/html/css/aurweb.css index 22b5ac65..5c2c744d 100644 --- a/web/html/css/aurweb.css +++ b/web/html/css/aurweb.css @@ -23,6 +23,10 @@ white-space: normal; } +#pkg-stats td.stat-val { + text-align: right; +} + #actionlist form { margin: 0; padding: 0; -- 2.35.1

3 4

Translation Status
by Kevin Morris 11 Jan '22

11 Jan '22

Hi all, I'd like to thank anybody who stepped up and took part in helping us out with reviewing translations. This is an ongoing process currently, but I wanted to share some information regarding release timing of these translation updates. These new/modified translations are intended to be released when the Python aurweb port is released on aur.archlinux.org, within roughly a week or two. They are all being worked out in our development `pu` branch at the moment, which never hits live deployments. So, don't worry if it seems to be delayed; everybody will get these new translations quite soon :) Thanks again! You're all so awesome. Regards, Kevin -- Kevin Morris Software & Linux Enthusiast

1 0

Packaging upstream binaries when we already have official releases
by Brett Cornwall 30 Dec '21

30 Dec '21

Hey all, I've been getting some mixed signals on whether or not we support packaging upstream binaries in the AUR when we already have packages in the official repository. The issue reached maximum farce with the removal of telegram-desktop-bin (PRQ 30701), which prompted a long chain on aur-general (message ID dcebfd89-d4fb-92aa-52f5-668113817884(a)cock.li) For some set dressing, from the rules of submission [1]: >The submitted PKGBUILDs must not build applications already in any of >the official binary repositories under any circumstances. Check the >official package database for the package. If any version of it exists, >do not submit the package. If the official package is out-of-date, flag >it as such. If the official package is broken or is lacking a feature, >then please file a bug report. > >Exception to this strict rule may only be packages having extra >features enabled and/or patches in comparison to the official ones. In >such an occasion the pkgname should be different to express that >difference. For example, a package for GNU screen containing the >sidebar patch could be named screen-sidebar. Additionally the >provides=('screen') array should be used in order to avoid conflicts >with the official package. My statement on that thread: >Submitting a package that is only different from the technicality that >someone else built it is not enough to warrant its own package. If >there's an issue with the telegram package in the repos, users should >submit a bug report. > >As it stands, there was nothing notated in the package to suggest that >it was anything but an upstream binary, so that was why I deleted it. I was shortly rebuked by another TU, claiming that I should have inspected the package since it *obviously* is different because it was built without support for pipewire (unless I'm misunderstanding, I could not know that without comparing binaries). This could spiral off into existential questions, like "couldn't they just have a PKGBUILD based off of the Arch telegram-desktop package with different compile-time options and have called it e.g. "telegram-no-pipewire" or the concept of combining all the various flavors of The issues here are twofold: 1. Some TUs think that "built by upstream" is enough of a feature to warrant its own package while some don't. 2. Differences between official Arch packages and upstream-built binaries are pretty opaque. My ultimate questions are: Do we *definitively* allow -bin packages when we already have them in the official repos (i.e. is "built by upstream" enough of a feature to warrant the package's existence)? a. If so, can we reword the rules of submission to explicitly allow such packages so we can avoid these conflicts? i. Where do we then draw the line between something like telegram-desktop-bin where people use it for a specific feature (in this case let's just say lack of pipewire support) and a build-from-source package that builds with the appropriate flags? b. If not, can we create an RFC and come to a definitive agreement on whether or not we allow them so that we can avoid these conflicts? Do we want to support other "official" packages, such as appimage, flatpak, docker, etc.? One could logically conclude that "built by upstream" being enough of a feature to be permitted submission could extend to all these various distribution methods. If -bin is allowed alongside our official packages, Where do we draw the line? [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss…

2 2

Fwd: Swedish Translation aurweb
by Luna Jernberg 24 Dec '21

24 Dec '21

---------- Forwarded message --------- From: Luna Jernberg <droidbittin(a)gmail.com> Date: Fri, Dec 24, 2021 at 4:03 PM Subject: Swedish Translation aurweb To: <kevr(a)0cost.org>, <aur-dev(a)lists.archlinux.org>, Martin Jernberg < droidbittin(a)gmail.com> Hello! Started helping out a bit with the Swedish translation of aurweb now, have done 21 strings so far

1 0

Re: Automating cleanup of AU
by Amin Vakil 12 Dec '21

12 Dec '21

> The requests queue is getting pretty filled with requests for packages > that quite clearly have been abandoned with no chance of them ever > becoming useful. It can be pretty exhausting to keep up with that queue! > > In particular, there's a lot of "low-hanging fruit" packages that can be > pruned from the AUR: Orphaned, 0 votes, last updated years ago packages > are hardly worth keeping around, are they? > > Has such a conversation popped up before? I didn't find anything in the > archives past the patch by Lukas enabling automatic orphaning of an OOD > package after 180 days. [1] > > If automatically deleting packages on a schedule isn't welcome, would it > make sense to at least explore a patch wherein a deletion request for > e.g. an orphaned package/<10 votes/last updated >=2 years ago is > automatically accepted? > I can recall many times NetSysFire talking about how hard maintaining wiki pages could be when there isn't a deletion request for an AUR package in #archlinux-aur. I'm not sure how they can handle this automatic deletion of packages without a request for it, maybe a list of automatically deleted packages suffice? Best Regards, Amin Vakil

4 5

Automating cleanup of AUR
by Brett Cornwall 11 Dec '21

11 Dec '21

The requests queue is getting pretty filled with requests for packages that quite clearly have been abandoned with no chance of them ever becoming useful. It can be pretty exhausting to keep up with that queue! In particular, there's a lot of "low-hanging fruit" packages that can be pruned from the AUR: Orphaned, 0 votes, last updated years ago packages are hardly worth keeping around, are they? Has such a conversation popped up before? I didn't find anything in the archives past the patch by Lukas enabling automatic orphaning of an OOD package after 180 days. [1] If automatically deleting packages on a schedule isn't welcome, would it make sense to at least explore a patch wherein a deletion request for e.g. an orphaned package/<10 votes/last updated >=2 years ago is automatically accepted? That would alleviate a lot on both the dedicated requesters helping out as well as those working the queue. [1] https://lists.archlinux.org/pipermail/aur-dev/2014-July/002876.html

5 5