- Aur-general - lists.archlinux.org

AUR git history rewriting
by aur user 07 Mar '23

07 Mar '23

If this is possible, would a TU who knows how to do this reply to me off-list? It is a matter of privacy, so I don't want a permanent record of my username and what I'm trying to remove left in the maling list. "In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their real name in a published commit." https://wiki.archlinux.org/title/AUR_Trusted_User_guidelines#Rewriting_git_…

2 1

repo-add command existing entry, when no entry is within the database
by Polarian 03 Mar '23

03 Mar '23

Hello, So yesterday I have encountered an issue when updating my Unofficial Repository (PolarRepo). Onedev is a split package, into onedev (the actual package) and onedev-new (only contains new files). (see https://aur.archlinux.org/pkgbase/onedev) They both do not conflict each other when installed, and was working on the repository for the last 5 updates, but forever what reason now, it stopped working. The following occurs when trying to add the entry: polarian in ~/polarrepo at PolarianServer … ➜ repo-add polarrepo.db.tar.gz onedev-new-8.0.5-1-x86_64.pkg.tar.zst ==> Extracting polarrepo.db.tar.gz to a temporary location... ==> Extracting polarrepo.files.tar.gz to a temporary location... ==> Adding package 'onedev-new-8.0.5-1-x86_64.pkg.tar.zst' ==> WARNING: An entry for 'onedev-8.0.5-1' already existed -> Adding package signature... -> Computing checksums... -> Removing existing entry 'onedev-8.0.5-1'... -> Creating 'desc' db entry... -> Creating 'files' db entry... ==> Creating updated database file 'polarrepo.db.tar.gz' I have already attempted to delete the entry before adding it using repo-delete, but this issue persists. If you inspect the repository database (https://polarrepo.polarian.dev/polarrepo.db.tar.gz) you will see onedev-new is not actually in the database anymore, and yet when I try to add it, it is never added... Anyone have any idea what is going on? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 7

Re: Account Suspended
by irecca.kun＠gmail.com 01 Mar '23

01 Mar '23

On 3/1/23 10:30, Oskar Roesler wrote: > The TU's aren't judges in criminal court. It's totally ok and beneficial if they apply some pragmatism and common sense. Hell, even real court judges are allowed to vary in their decisionmaking. No, you're not discriminated because they stopped your reaction. I hope you can understand and accept that. I understand. But I just don't get why I was banned. TU said this will be helpful to identify not complying packages. I just did that. It wasn't an automated script or something. And this is just requests, it is for TUs to make a decision. Unfortunately there is no "check" request type for simply bring attention, so I filled deletes. Also I don't see any mentions about how much requests user can make. If you guys have problems with it, please share the limits publicly, e.g. on the wiki page. P.S. Regarding common sense. I will be glad if someone will explain how my package (libinput-light), which was created to drop libwacom dependency (How much users have wacom tablets? I think even 1% of the userbase will be generous overestimation.), considered harmful and deleted, but packages like https://aur.archlinux.org/packages/linux-slim stripped down to hell and literally stating "Zero compatibility" in the description are still alive for years? TU's aren't judges, as you said, but I definitely want some justice here.

3 6

Account Suspended
by irecca.kun＠gmail.com 01 Mar '23

01 Mar '23

Hello. My AUR account (Hanabishi) was suspended. There is a mistake happened. You maybe thought that I am abusing requests, but my actions are actually agreed with TU. I am just helping to find duplicate packages (already present in official repos), which are violating AUR submission guidelines.

5 5

update gvim and vim-runtime
by marnout 13 Feb '23

13 Feb '23

Hello devoted TU, Yesterday I upgraded my archlinux. Among the updated packages were gvim and vim-runtime. I then noticed that there is a mess in the syntax highlighting of the bash scripts. I reinstalled the previous versions (9.0.1182-1) of gvim and vim-runtime, and everything was back to normal. Suspecting the sh.vim or bash.vim coloring files, I copied them to ~/.vim/syntax and updated gvim and vim-runtime again (from 9.0.1182-1 to 9.0.1302-1) and everything works fine. I do not ask for help, since I have solved my problem. I'm sorry, maybe this is not the right place to report what I think is a bug. Sincerely yours P.S. I have been using archlinux for a few years and I am very happy with it. I would like to make a donation with my credit card from time to time. Is 'click & pledge' the right place to help archlinux modestly? -- Mourad Arnout 25 rue de la Vieille Pierre 79800 Exoudun http://arad.free.fr

3 2

JSW (Java Service Wrapper) advice
by Polarian 11 Feb '23

11 Feb '23

Hello, So I have discussed the JSW issues in other threads, but now I have decided to make a dedicated thread for it as I feel it is a major issue with projects which depend on it. JSW makes things difficult when packaging software, you need the new version of the software to "patch" (of sorts) the old version, and then you remove the new version... which is already difficult enough to do, and is something I am working on within the onedev package: https://onedev.polarian.dev/polarrepo/onedev/~issues/1 However I have been looking for other user-based improvements, JSW provides a variety of scripts, such as database backup, restoring etc. These shouldn't be added to the PATH directly as it would "blotify" it of sorts, so I was thinking of making a wrapper script/program to call these scripts depending on the command line arguments passed. This would be a very simple script. If not written in bash, it could be added as a hard dependency of the package, or as a optional dependency (wrapper script to make JSW scripts more usable). JSW programs are very non-generic to the point that the only choice you got is to dump them into /opt/ and try your best to get them to work with the package manager, did I mention JSW is proprietary and is distributed under multiple EULAs? (which makes this situation even more of a kick in the balls). I have discussed isolation and removal of JSW from the codebase, it is possible to make it optional but the developer of onedev is currently not willing to do this, unless there is good reason (aka the AUR package does well, and there is a draft package proving the support is there for it) -> this is what I think he wanted to the best of my knowledge. Once I have the main package properly working, I have got on my todo list to attempt to strip the JSW wrapper out (the docker builds to a jar without the JSW, however it is a "incomplete" build which will need patching to fully function as far as I am aware). I plan to push this in the future to onedev-oss, or rename onedev to onedev-bin and then move the non-JSW one to be onedev, and then eventually merge them into a single package if the non-JSW manages to be as stable as the JSW, but this unfortunately will be unlikely due to the strong dependency on JSW. Does anyone have any advice they can give on packaging applications using JSW, and the idea of wrapping the JSW scripts into a single executable/script which can be put within the path (preferably to /usr/bin) to make it easier for users to manage their applications? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

1 0

AUR Package Naming: greetd-regreet-git or regreet-git?
by rharish 09 Feb '23

09 Feb '23

Hello, I created a greeter for the greetd login daemon called ReGreet (https://github.com/rharish101/ReGreet). I wanted to publish a PKGBUILD for this to the AUR, and hence I requested a review on the Arch Forums here: https://bbs.archlinux.org/viewtopic.php?pid=2083695. Lone_Wolf on the forums pointed out that the package should be called "regreet-git". However, all other greeters for greetd (greetd-gtkgreet, greetd-qtgreet, greetd-ddlm-git) all start with the "greetd-" prefix. What should I name my package? "regreet-git" or "greetd-regreet-git"? Should I stick with what the guidelines say, or the informal naming convention of greetd greeters? For your reference, I'm attaching the PKGBUILD and the .install file here.

1 0

Can't seem to find the issue within PKGBUILD
by Polarian 03 Feb '23

03 Feb '23

Hello, https://onedev.polarian.dev/polarrepo/reposilite/~files/fix Find above the link to the git repository, please check branch fix and not master. A lot of these edits were not made by me and were made by another user, but I can't seem to find what is causing the following issue when trying to install this package: (3/4) Creating temporary files... Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib/dbus. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/dbus. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /etc (owned by root) during canonicalization of /etc. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/lock. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/sudo. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd/netif. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd/netif. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd/netif. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/systemd. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib/systemd. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/cache. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/lib/tpm2-tss/system. Detected unsafe path transition / (owned by build) → /run (owned by root) during canonicalization of /run/tpm2-tss. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log/journal. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log/journal. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log/journal. Detected unsafe path transition / (owned by build) → /var (owned by root) during canonicalization of /var/log/journal/remote. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/snd/seq. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/snd/timer. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/loop-control. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/net/tun. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/fuse. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/kvm. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/vhost-net. Detected unsafe path transition / (owned by build) → /dev (owned by root) during canonicalization of /dev/vhost-vsock. error: command failed to execute correctly (4/4) Arming ConditionNeedsUpdate... Some advice would be appreciated! Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 1

Multiple packages in PKGBUILD and creating groups?
by Polarian 31 Jan '23

31 Jan '23

Hello, I have two questions, I merged it into one post to prevent people complaining about Polarian Notifications (aka me popping up on their email every 5 mins). Does anyone have a good reference I can use to properly make a multi-package PKGBUILD, I have no experience doing this and I want to stick to conventions, and the PKGBUILD ArchWiki page does not seem to cover it. Secondly, is it possible to create PKG groups within the AUR, I would like to group a few packages together, but I am unsure if I am allowed, or able to do this, unless it is added to an official repository. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

3 5

Removal of Kyle Keen (keenerd) as Trusted User/ Package Maintainer
by David Runge 29 Jan '23

29 Jan '23

Hi all, I would like to bring up the removal of Kyle Keen (keenerd) [1] as Trusted User/ Package Maintainer on the basis of inactivity [2]. As main key holder I have been trying to get Kyle's previous packager key revoked (no @archlinux.org UID, RSA2048, SHA-1 binding signature) and have a new one be created since October 2021. Jelle also tried to reach out to get a response via arch-dev-public in May 2022 [3]. There had been no reply to my requests, until I had DevOps disable SSH access to the package server in July of last year (which I had to do as packages were still being released and I had to rebuild them constantly [4][5] for us to be able to disable one of the main packager keys). After some time an @archlinux.org mail address had been requested and a ticket been created for archlinux-keyring [6]. However, since October 2022 this process is dormant again (after pinging about missing bits). Other issues were raised around the splitting of the python-jaraco packages [7], which stalled updates to a bunch of the building blocks of the Python ecosystem due to no response from Kyle. After spending 16 months on a key change and multiple times of failing to follow up, I am of the opinion, that Kyle is not able to keep up with packaging and the process that is required for it (e.g. communication with other packagers or key holders). The discussion period on this topic lasts for three days (starting today), after which there will be a voting period of five days. Best, David [1] https://aur.archlinux.org/packages?K=keenerd&SeB=m [2] https://tu-bylaws.aur.archlinux.org/#_special_removal_of_an_inactive_tu [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [4] https://archlinux.org/todo/rebuild-packages-signed-by-48c3b1f30ddd0fe67e516… [5] https://archlinux.org/todo/rebuild-packages-signed-by-48c3b1f30ddd0fe67e516… [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/201 [7] https://archlinux.org/packages/?q=python-jaraco -- https://sleepmap.de

2 5