- Aur-dev - lists.archlinux.org

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 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? 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

co-maintainer info
by Xyne 19 Nov '21

19 Nov '21

Hi, Is there currently any way to get the last packager from the aurweb RPC interface? Regards, Xyne

1 0

Help with Java Gradle
by Karmanyaah Malhotra 07 Aug '21

07 Aug '21

Hello, I maintain the package dex2jar-git, I took over this (IIRC) orphaned package a while ago because there was a shell-script bug in the build. The upstream project seems to have been abandoned. I recently received information regarding a bug from a user (deltaclock); which I hadn't noticed this myself due to not updating anything in the past week or so. I can also reproduce the bug in the package comments. But, I don't know much about Java things and am not sure what the ideal solution would be. 1. Adding a make dependency on an older gradle version from the AUR. This seems like the easiest solution but building gradle takes a lot of resources so it isn't the ideal solution. 2. Adding a patch. It would be nice if an AUR maintainer who is familiar with Java tools has a patch for this. I would be willing to transfer ownership to someone who could handle this issue better. 3. File an issue with the upstream. Unlikely to help at all, given there hasn't been a commit in nearly two years. -- Thanks, Karmanyaah Malhotra https://karmanyaah.malhotra.cc/contact/ gemini://karmanyaah.malhotra.cc

2 1

Can a new release of aurweb be published?
by Hunter Wittenborn 21 Jul '21

21 Jul '21

This email is in reference to an issue on the Arch Linux bugtracker: https://bugs.archlinux.org/task/71427 --- I'm currently working on a platform known as the MPR [1], which is quite literally the AUR, just designed for Debian-based distributions. The whole idea of the project builds upon makedeb [2], which actually uses makepkg, and does some conversion stuff on top to make the package work properly with APT. Getting back to the MPR then - I was wondering if it would be possible to get a new release published. The current 5.0.0 release has some bugs that aren't present in the live version, and it's requiring me (as stated in the issue on the bugtracker itself) to try to triage these bugs manually (which isn't too much of a problem, but for the reason mentioned next, it would be easiest if I could just get a new release with all the fixes incorporated). The MPR is currently running off of mprweb [3], which (at this point) is pretty much just aurweb with a reskin. I'm wanting to start make some more heavy modifications to the platform though, such as adding some things to the RPC JSON interface (mostly for things mentioned in makedeb's docs [4]), and possibly doing some things with the GUI. At current, the goal is to get a release of aurweb, and then just fork it and go from there. I wouldn't be using any new releases of aurweb at that point, and would just keep adding in features as I go along. If I were to make any changes that would be deemable to be contributed back to aurweb, I'd be more than glad to do so as well. I'm just wanting to, before I start any (objectionably) bigger modifications, be able to use something that's at least somewhat close to aurweb's current state. I'm not asking for anything immediately, I'm just, again, wanting something where I can have a starting point where these known bugs are just polished out. [1]: https://mpr.hunterwittenborn.com/ [2]: https://github.com/makedeb/makedeb [3]: https://github.com/makedeb/mprweb [4]: https://docs.hunterwittenborn.com/makedeb/makedeb/additional-pkgbuild-specs --- Hunter Wittenborn https://www.hunterwittenborn.com https://github.com/hwittenborn

2 3

[PATCH] change git.archlinux -> gitlab.archlinux
by turret 15 Jul '21

15 Jul '21

>From 63d463d1e8e6f8af4db564d856f691be1be2360f Mon Sep 17 00:00:00 2001 From: turret-dev <turret(a)turret-studios.tk> Date: Wed, 14 Jul 2021 20:10:12 -0500 Subject: [PATCH] change git.archlinux -> gitlab.archlinux --- INSTALL | 2 +- README.md | 4 ++-- TESTING | 2 +- doc/i18n.txt | 2 +- web/template/footer.php | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/INSTALL b/INSTALL index a32d6f5a..9bcd0759 100644 --- a/INSTALL +++ b/INSTALL @@ -12,7 +12,7 @@ read the instructions below. 1) Clone the aurweb project: $ cd /srv/http/ - $ git clone git://git.archlinux.org/aurweb.git + $ git clone https://gitlab.archlinux.org/archlinux/aurweb.git 2) Setup a web server with PHP and MySQL. Configure the web server to redirect all URLs to /index.php/foo/bar/. The following block can be used with nginx: diff --git a/README.md b/README.md index 77f3b13d..d43c6b64 100644 --- a/README.md +++ b/README.md @@ -29,8 +29,8 @@ Directory Layout Links ----- -* The repository is hosted at git://git.archlinux.org/aurweb.git -- see - doc/CodingGuidelines for information on the patch submission process. +* The repository is hosted at https://gitlab.archlinux.org/archlinux/aurweb + -- see doc/CodingGuidelines for information on the patch submission process. * Bugs can (and should) be submitted to the aurweb bug tracker: https://bugs.archlinux.org/index.php?project=2 diff --git a/TESTING b/TESTING index 972bce2c..a88464a5 100644 --- a/TESTING +++ b/TESTING @@ -7,7 +7,7 @@ INSTALL. 1) Clone the aurweb project: - $ git clone git://git.archlinux.org/aurweb.git + $ git clone https://gitlab.archlinux.org/archlinux/aurweb.git 2) Install the necessary packages: diff --git a/doc/i18n.txt b/doc/i18n.txt index 8216c084..44fb0f1f 100644 --- a/doc/i18n.txt +++ b/doc/i18n.txt @@ -21,7 +21,7 @@ strings for the translation to be usable, and it may have to be disabled. 1. Check out the aurweb source using git: -$ git clone git://git.archlinux.org/aurweb.git aurweb-git +$ git clone https://gitlab.archlinux.org/archlinux/aurweb.git aurweb-git 2. Go into the "po/" directory in the aurweb source and run msginit(1) to create a initial translation file from our translation catalog: diff --git a/web/template/footer.php b/web/template/footer.php index 572dbb26..7f97aae0 100644 --- a/web/template/footer.php +++ b/web/template/footer.php @@ -3,7 +3,7 @@ <div id="footer"> <?php if ($ver): ?> - aurweb <a href="https://git.archlinux.org/aurweb.git/log/?h=<?= htmlspecialchars($ver, ENT_QUOTES) ?>"><?= htmlspecialchars($ver) ?></a> + aurweb <a href="https://gitlab.archlinux.org/archlinux/aurweb/-/tree/<?= htmlspecialchars($ver, ENT_QUOTES) ?>"><?= htmlspecialchars($ver) ?></a> <?php endif; ?> <?= __('Copyright %s 2004-%d aurweb Development Team.', '©', date('Y')) ?> <?= __('AUR packages are user produced content. Any use of the provided files is at your own risk.') ?> -- 2.32.0

2 1