- Aur-general - lists.archlinux.org

Questions on JDK naming
by Tommaso Dordoni 02 Jun '23

02 Jun '23

Hello, I recently started contributing to the AUR and I have some questions on JDK naming. I submitted a package called “jdk17-azul-prime-bin” yesterday, but then I realized that other Zulu jdk packages follow a different naming convention, such as “zulu-8-bin”, “zulu-17-bin”, “zulu-20-bin”... For consistency, I requested a merge to rename my package as “zulu-prime-17-bin”. Was that a good decision? In general, what is the best way to name JDK and JRE packages? For instance, how should I name the JDK and JRE Zulu Prime packages for Java 8 to differentiate them? Thank you

2 1

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 10 May '23

10 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

Error pushing package: "remote: fatal: bad object .alternate"
by é 05 May '23

05 May '23

Hi all, I'm attempting to update https://aur.archlinux.org/packages/cpuset, and cloning it works fine, however trying to commit and push changes results in the following error (snipped): ``` Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 remote: fatal: bad object .alternate fatal: bad object refs/heads/python-degiro-connector To ssh://aur.archlinux.org/cpuset.git ! [remote rejected] master -> master (missing necessary objects) error: failed to push some refs to 'ssh://aur.archlinux.org/cpuset.git' ``` Also, interestingly enough it seems that python-degiro-connector itself has some issues; cloning it via https simply fails: ``` Cloning into 'python-degiro-connector'... fatal: remote error: upload-pack: not our ref ae7907349a087b4ec7e550cccbb059dc212d2bc9 ``` Referring somehow to this commit https://github.com/archlinux/aur/commit/ae7907349a087b4ec7e550cccbb059dc212… (which seems fine to me?) I don't know how to resolve this issue as I'm not familiar with git alternates, and searching snippets of errors on the mailing list / google was not fruitful. Any suggestions? Best, éclairevoyant

2 2