December 2021 - Aur-dev - lists.archlinux.org

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

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

Review Translation Merge Requests
by Kevin Morris 05 Dec '21

05 Dec '21

Hello AUR users & devs, We've got a large amount of translation updates incoming from Transifex, and we really need to get these reviewed as much as we can before merging into the devel branch. Almost every language has updates. The proposed translation updates can be seen and reviewed in their relevent merge requests, located in https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests Each MR is titled "Update {domain} translations" If you wish to test these on a live website, you'll need `docker` and `docker-compose` packages. Checkout to and pull the `update-{domain}` branch on kevr's fork at https://gitlab.archlinux.org/kevr/aurweb, then run the following in the repository: $ docker-compose build $ docker-compose up -d nginx When the `nginx` service is up, you can browse to https://localhost:8444, change the language to your target, and check it out. Each translation string has a comment with the filename of the originator of the string; this can be used to deduce the route where the translation is used, and the msgid can be used to figure out where in the route it should translate. Thanks for reading, we really appreciate any help that you guys give to us <3 Regards, Kevin -- Kevin Morris Software Developer Identities: - kevr @ Libera

2 2