May 2023 - Aur-general - lists.archlinux.org

[aur-general] TU rename Bylaws amendment vote
by Konstantin Gizdov 25 Oct '23

25 Oct '23

Hi, As per the TU Bylaws following the discussion to rename the Truster Users [1], the Trusted Users themselves must vote to approve the renaming. Hence, please, cast your vote on whether you agree the Bylaws be amended and the "Trusted User" role is renamed into "Package Maintainer". Vote is located at - https://aur.archlinux.org/tu/140 -- Regards, Konstantin [1] - https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7

2 6

Autobot caught in use?
by Polarian 03 Jun '23

03 Jun '23

Hello, I was looking at the AUR today and I have realised a ton of packages with the prefix r-<package name> being updated within a minute of each other, and then found the user to be publishing them: https://aur.archlinux.org/account/BioArchLinuxBot By the name it seems this is a Bot, Anthraxx and Jelle have already discussed how this is not acceptable in a previous thread, see: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… A draft has also been submitted on the ArchWiki to set this into stone: https://wiki.archlinux.org/title/Talk:AUR_submission_guidelines#Automation_… Therefore I am bringing this user, and the packages which this has occurred on to the TUs here. I have also attached an image to this email which is a screenshot of the recently updated packages, you can use the rss feeds to back this up as well, it clearly shows that a large number of r packages were updated BY THE SAME USER within the span of 10 minutes. Let me know what you think :) Have a good day, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 7

Harrassment?
by Pellegrino Prevete 13 May '23

13 May '23

the "xiota" aur user, I never talked even once as far as I remember, and who somehow came to maintain "gnome-contact-git", defined me "a squatter who has never pushed an update to packages" in an orphan request. I'm notifying him I have reported the issue here. Cheers

3 2

Binary AUR packages when associated packages exist in the repos
by é 12 May '23

12 May '23

I would like to reopen the discussion to delete a package (yuzu-mainline-bin) that exists in [community] (yuzu). As per AUR guidelines [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. yuzu-mainline-bin provides zero extra features or functionality compared to the repo build, at least, no one has yet mentioned such. The name itself refers to yuzu-mainline which is exactly what the repo package is building. As a result I filed a deletion request, but this was apparently rejected [2] with the reasoning that "Yuzu only seems to support binaries", along with some links to comments from upstream as well as a link to a previous thread [3] on the ML from 2021 where this topic was mentioned before. The other point mentioned in the AUR package comments [4] is that the repo version can be out of date frequently. Again, that is addressed in the quote above, still doesn't justify the AUR package. To me, the entire purpose of having the official repos is to have binary builds (presumably done in a clean environment with some minimal source verification), so we don't have to rely on arbitrary developers to have clean environments and only really need to trust the TUs who build that package. If there are issues with a package, they are first reported to Arch maintainers via bug report (this is in accordance with the "please file a bug report" in the quoted passage above). This applies to any package, and yuzu is neither an exception nor special case here. Also the entire point of having distros in the first place is that you have someone (who is usually not upstream) maintaining the package and making sure it slots well into your system. I don't know of any package in any distro where the distro builds the package, but upstream is expected to support it. So why should a specific -bin package exist in the AUR just because upstream is in accordance with decades of tradition? Either way they clearly do not want unnecessary bug reports from inexperienced users [5], so any Arch user reporting a bug with the repo package upstream would be unhelpful to both Arch and Yuzu. Best, éclairevoyant [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… [2] https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… [3] https://lists.archlinux.org/pipermail/aur-dev/2021-December/005056.html [4] https://aur.archlinux.org/packages/yuzu-mainline-bin#comment-913540 [5] https://github.com/yuzu-emu/yuzu/blob/master/.github/ISSUE_TEMPLATE/bug_rep…

4 4

Re: Broken Package
by paul.mirkwood 09 May '23

09 May '23

Thanks artafinde for the clarification, and thanks also Polarian, your explanations were worth reading! > As an additional sidenode, if the issue you want to report is that the package is > broken because it can't be built, the maintainer has already highlighted that it is due > to gcc update, and they are awaiting upstream to patch the issue. That was posted 3 > days ago so I assume it is still valid right now as I do not see any recent commits to > the AUR for this package. (not since 2023-04-18) This is indeed what I'm talking about, sorry I should've read the comments on Aurweb before posting here. Since the problem has already been reported, I feel like there's no more to do but waiting if the maintainer is willing to backport the patch. I totally understand that packages may break, I was kind of wondering why upstream would have released a non-compiling version, but I have the explanation now. Have a good day/night, Mirkwood

2 2

Broken package
by paul.mirkwood 09 May '23

09 May '23

Hello everyone, I'm pretty new here so I hope you will forgive me if my question isn't appropriate. I don't want to blame anyone, but is it normal that non -git packages may be broken? (maybe it is, I genuinely don't know) Currently, the mangohud package is broken even though upstream has fixed the bug. The mangohud-git package is also fine. Best regards, and thanks for your answers, Mirkwood ------- Forwarded Message ------- De : paul.mirkwood <paul.mirkwood(a)protonmail.com> Date : mardi 9 mai 2023 à 10:51 PM Objet : Broken package À : aur-general(a)lists.archlinux.org <aur-general(a)lists.archlinux.org> > Hello everyone, > > I'm pretty new here so I hope you will forgive me if my question isn't appropriate. > I don't want to blame anyone, but is it normal that non -git packages may be broken? > (maybe it is, I genuinely don't know) > Currently, the mangohud package is broken even though upstream has fixed the bug. > The mangohud-git package is also fine. > > Best regard, and thanks for your answers, > Mirkwood

3 3

Help with old large commit to AUR
by Iyán Méndez Veiga 09 May '23

09 May '23

Hi, I have an issue trying to update a package in AUR. I get the following error: $ aurpublish python-tweedledum git push using: aur:python-tweedledum.git master Enumerating objects: 12, done. Counting objects: 100% (12/12), done. Delta compression using up to 8 threads Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 870.96 KiB | 6.80 MiB/s, done. Total 9 (delta 4), reused 0 (delta 0), pack-reused 0 remote: Checking connectivity: 9, done. remote: error: The following error occurred when parsing commit remote: error: ef079835003ac029a21f2bcec32ece1a62bc19d0: remote: error: maximum blob size (488.28KiB) exceeded remote: error: hook declined to update refs/heads/master To aur:python-tweedledum.git ! [remote rejected] c19571c71b3b6c9d3ea28ba069d965b22509bd0a -> master (hook declined) I think the issue is that in the past I commited a large patch file (by mistake) instead of including the url in the sources array (that's commit ef079835), and somehow the remote didn't complain back then but it does now. I have removed that patch and replace it with the upstream url, but I can't push a new version. This is what I'm trying to commit: https://github.com/iyanmv/PKGBUILDs/commit/ 5e642048f438b3857007621d8b778689776244f3 Hopefully some trusted user can help me. Thanks, Iyán -- Iyán Méndez Veiga GPG 0x422E3694311E5AC1

2 1

Non-git AUR with submodules
by Christian 07 May '23

07 May '23

Hi, I took over the package blink1. It is not a -git package so it should have a stable checksum, in my opinion. But since the project it builds uses a submodule, the package uses source=("git+https:/…) and SKIP for the checksum. This way prepare() can do a submodule init and submodule update. Is there a better way to deal with submodules? Or would it be better to download the released binary for the correct architecture and install that? As I currently understand it this would only be acceptable for a -bin package, wouldn't it? (I found no clear guidance when to use that prefix, e.g. zoom) This is my first AUR and I'd like to do it properly. Best, Christian

3 3

keyrings on the AUR
by Fabian Bornschein 06 May '23

06 May '23

Hi, I'd like to ask what's the current status on gpg keys, "keyrings" on the AUR? A few years back they where removed[1]. If I search for 'keyring' right now a few pop up. I guess there are different reasons for them to appear, like for example the 'linuxmint-keyring' is different from the 'alph-keyring', where one is from a pacman repo and the other one is not. However it would be good to have a consistent rule/guideline what's OK and what not. [1] <https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/…> --- Sincerely, Fabian Bornschein

1 0

AUR unavailable because of broken refs
by Morten Linderud 05 May '23

05 May '23

Hi, The AUR is currently unavailable because of some broken refs in the underlying Git repository that needs to be fixed. We are working on solving the issue but it might take a couple more hours. -- Morten Linderud PGP: 9C02FF419FECBE16

3 2