- Aur-general - lists.archlinux.org

Re: Waterfox G
by Aaron Liu 01 Sep '23

01 Sep '23

Oops, I've sent this to the arch-general mailing list instead! I meant to send this to aur-general, sorry. I guess forwarding it should be fine. On 9/1/23 15:15, Aaron Liu wrote: > Currently, there are 2 packages for the latest Waterfox "current": > waterfox-g-bin and waterfox-current-bin . > > My guess is as follows: This arose from Waterfox changing their > versions from "current" to "G", short for "generation". hawkeye116477, > the maintainer for the former package and former maintainer for the > latter package, decided to create a new package, waterfox-g-bin, for > later releases and keep waterfox-current-bin frozen at the last > release with "current". However, MarsSeed orphaned > waterfox-current-bin through [PRQ#42365] in June and Leo Izen claimed > it and updated it to the latest Waterfox G. > > The current situation is that Waterfox refers to "Waterfox G" as > simply "Waterfox" and both bin packages have the wrong name. What > should be done? > > Also, is it necessary to have both gtk3 and gtk2 as > dependencies? Looking at the PKGBUILDs the only difference between the > packages is waterfox-g-bin disables automatic updates + update > notifications and has the extra profile manager desktop action while > waterfox-current-bin has none of these and has the extra dependency > "nss" (is this necessary?) > > P.S.: I've Bcc'd everybody I've named in this email. I'm new to the > AUR, so tell me if that's not the right thing to do. >

1 0

Best Approach to Resolving AUR-based Dependencies When Testing with Devtools
by Sean Snell 29 Aug '23

29 Aug '23

Hello, I'd like to start testing my PKGBUILD work with devtools prior to pushing my work to the AUR however I rely on packages based in the AUR for dependencies and when I try to use *extra-x86_64-build* in the location of the PKGBUILD it works for a bit but then fails because it can't resolve the AUR-based dependency packages. That makes sense as it's replicating the local *makepkg -s* process, which would also fail if I didn't have those dependencies installed ahead of time. I normally accomplish this with yay <https://aur.archlinux.org/packages/yay> then build the PKGBUILD with *makepkg -s*. How do other AUR maintainers traditionally resolve their AUR-based dependencies when working with devtools? I'm not opposed to using yay with devtools if pulling in an AUR wrapper is appropriate; I'd just like to avoid having to manually install a bunch of dependencies by hand before I'm able to test if my PKGBUILD work is sound. Thanks!

4 3

Applying for maintainer role
by Tomaz Canabrava 16 Aug '23

16 Aug '23

Hello, My name is Tomaz Canabrava, Im a kde developer and mostly focus on Konsole. Other than that, I use arch Linux for the past 10 years, as my only Linux distro. I have experience with packaging (debian, for work) but not on arch, but it’s shell and that thing I can handle :) My sponsors are Gian and Antonio Rojas. This is not gpg signed and I’m sorry for that, but gian and Antonio can also vouch for me as the validity of this email. Best, Tomaz - kde ev member

14 33

AUR package naming for Java packages (was: [PRQ#42786] Deletion Request for autopsy-bin Rejected)
by Chih-Hsuan Yen 05 Aug '23

05 Aug '23

Thank you for bringing this up. Current guidelines for packages using prebuilt binaries, which are added in 2019 [1], are indeed unclear about Java packages. Literally, there is no rule about whether such Java packages should use a package name with "-bin" suffix or not. I propose to require the "-bin" suffix for new Java package using prebuilt binaries while allow existing packages without the "-bin" suffix (i.e., no need to submit deletion/merge requests for them). A modified rule can be: * Packages that use '''prebuilt''' [[wikipedia:Deliverable|deliverables]], when the sources are available, must use the {{ic|-bin}} suffix. An exception to this is with [[Java package guidelines#Java packaging on Arch Linux|Java]], where new Java packages using prebuilt binaries must use the {{ic|-bin}} suffix, while existing such packages without the {{ic|-bin}} suffix are allowed. The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist. Any opinions? [1] https://wiki.archlinux.org/index.php?diff=572792 Best, Chih-Hsuan Yen (yan12125) ---------- Forwarded message --------- 寄件者： Marcell Meszaros <marcell.meszaros(a)runbox.eu> Date: 2023年7月30日週日下午10:00 Subject: Re: [PRQ#42786] Deletion Request for autopsy-bin Rejected To: Chih-Hsuan Yen <yan12125(a)archlinux.org>, <aur-requests(a)lists.archlinux.org> Cc: <contact(a)lsferreira.net> >autopsy-bin is a better package name for a package built from >binaries. In that case, please kindly revise the AUR submission guidelines, because currently it explicitly mentions Java as an exception to the '-bin' name suffix requirement. [a] " * Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix. An exception to this is with Java. " [a]: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… On 30 July 2023 15:26:43 GMT+02:00, Chih-Hsuan Yen <yan12125(a)archlinux.org> wrote: >Marcell Meszaros <marcell.meszaros(a)runbox.eu> 於 2023年7月30日週日下午6:20寫道： >> >> @yan12125, why did you reject the deletion request for this duplicate? >> >> AUR/autopsy also uses the precompiled Java bytecode as source. >> >> So the two packages are truly duplicates, the only difference is that autopsy-bin is 1 year older and flagged OOD for that period. >> >> On 30 July 2023 11:05:20 GMT+02:00, notify(a)aur.archlinux.org wrote: >> >Request #42786 has been Rejected by yan12125 [1]: >> > >> >> This is a java application so the >> >suffix '-bin' is not necessary anyway. >> > >> >Java packages can be either built from sources or binaries as well. >> > >> >[1] https://aur.archlinux.org/account/yan12125/ > >autopsy-bin is a better package name for a package built from >binaries. Therefore, orphaning and updating autospy-bin is better than >deleting autospy-bin. After that, autospy can be merged into >autospy-bin in case it is not changed to be built from sources. > >Best, > >Chih-Hsuan Yen (yan12125)

3 3

unable to build with makepkg (No such file or directory)
by james smith 29 Jul '23

29 Jul '23

trying to build this https://github.com/matthewq337/auto-fdisk https://bpa.st/H6XQ

5 4

Fwd: Re: unable to build with makepkg (No such file or directory)
by Robin Candau 29 Jul '23

29 Jul '23

Forwarding my answer to the ML -------- Message transféré -------- Sujet : Re: unable to build with makepkg (No such file or directory) Date : Sat, 29 Jul 2023 18:05:03 +0200 De : Robin Candau <antiz(a)archlinux.org> Pour : james smith <cinemassacres(a)gmail.com> Le 29/07/2023 à 17:45, james smith a écrit : > trying to build this https://github.com/matthewq337/auto-fdisk > <https://github.com/matthewq337/auto-fdisk> https://bpa.st/H6XQ > <https://bpa.st/H6XQ> Hi, Can you provide a bit more details? You can provide the output of `makepkg` for instance. On a side note, by quickly looking at your PKGBUILD, I can see a bunch of issue: - Your PKGBUILD seems to build a VCS package. Your pkgname has to reflect that by adopting a `-git` suffix. - The "source." prefix in your pkgver is un-necessary. - Auto-fdisk is licensed under the MIT license so it has to be packaged by the PKGBUILD. See the first bullet point of the related wiki "license" chapter for more details [1]. - The package should depend on `bash` rather than `sh`. For what it's worth, bash being a member of the `base` metapackage [2], you don't even have to list it as a dependency if you prefer, as the `base` metapackage is assumed installed at runtime. - Missing `git` as a makedepends. And, most importantly, why did you fork the upstream project [3] and deliver your fork in the PKGBUILD [4] instead of relying on the actual upstream repo [5] directly? Is there any particular reason for that? [1] https://wiki.archlinux.org/title/PKGBUILD#license [2] https://archlinux.org/packages/core/any/base/ [3] https://github.com/matthewq337/auto-fdisk [4] https://bpa.st/H6XQ#1L7-L7 [5] https://github.com/ivmm/Auto-fdisk -- Regards, Robin Candau / Antiz

1 0

[PATCH] /etc/ld.so.conf.d
by Masato TOYOSHIMA 23 Jul '23

23 Jul '23

add /etc/ld.so.conf.d/libressl.conf --- PKGBUILD | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/PKGBUILD b/PKGBUILD index ec9caae..f3dc5f7 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -7,7 +7,7 @@ pkgname=libressl pkgver=3.7.3 -pkgrel=1 +pkgrel=2 pkgdesc="Free version of the TLS/crypto stack forked from OpenSSL" arch=(x86_64) url="https://www.libressl.org/" @@ -47,6 +47,9 @@ package() { make DESTDIR="${pkgdir}" install install -Dm644 COPYING -t "${pkgdir}"/usr/share/licenses/${pkgname}/ + mkdir -p "${pkgdir}/etc/ld.so.conf.d" + echo "/usr/lib/libressl" > "${pkgdir}/etc/ld.so.conf.d/libressl.conf" + # Remove symlink man pages that point to OpenSSL ones since the prefix is not accounted for for manlink in $(find -L "${pkgdir}"/usr/share/man/man3/ -type l) ; do -- 2.41.0

1 0

Why are patches submitted via email?
by Adam Labus 18 Jul '23

18 Jul '23

Hi, quick question: Why aren't pull requests made directly on gitlab/somewhere on the site, but instead are sent over email. Even from the human aspect, I think most devs want to track their "ego points" in the form of how many merges they made. Or is it just me who is doing it wrong and I should put patches into comments instead?

5 4

Re: Applying for maintainer role
by Tomaz Canabrava 17 Jul '23

17 Jul '23

Hello Carsten, On Mon, 17 Jul 2023 at 11:41 Carsten Haitzler <raster(a)archlinux.org> wrote: > On Mon, 17 Jul 2023 10:44:37 +0300 Tomaz Canabrava <tcanabrava(a)kde.org> > said: > > > On Mon, 17 Jul 2023 at 10:25 Jonathan Steel <jsteel(a)archlinux.org> > wrote: > > > > > On Sun 16 Jul 2023 at 15:37, Tomaz Canabrava wrote: > > > > I have experience with packaging (debian, for work) but not on arch, > but > > > > it’s shell and that thing I can handle :) > > > > > > Why not show this by maintaining some air packages? > > > > > > Mostly because there is nothing in aur that I use that lacks a > maintainer. > > But I do have a software that is not packaged yet that I can port to aur. > > > > > > > > > > This is not gpg signed and I’m sorry for that, but gian and Antonio > can > > > > also vouch for me as the validity of this email. > > > > > > Why is it not signed? > > > > > > Because I don’t have a gpg key, and when the dkim features on the email > > already are enough to validate that the email I send is from me. > > > > > > > > > > I think you should read https://wiki.archlinux.org/title/Trusted_Users > and > > > re-submit a signed application showing the minimum requirements are > met. > > > > > > I have read the wiki and I have applied to a packager position following > > the wiki rules or explaining why I didn’t follow a part of it, i won’t > > re-apply because that’s a waste of everyone’s time just for the sake of > > ticking boxes. > > > > Summary: > > - [x] known on the opensource community with multiple, and used, > programs > > - [x] packaging experience > > - [ ] aur / arch package experience > > - [x] contributes directly to upstream > > - [ ] signed the mail with gpg > > Then I would reject your application as you don't plan to re-try with a > PGP key > and don't even have one. > > A PGP key is used to show that it was YOU and not someone else that signed > a > package is a basic requirement of maintaining packages on Arch. That has > nothing to do with dkim or email. You'll need a PGP key for other things > and if > you don't have one, you can't maintain packages. Signing your email with a > PGP > key at least shows you have one and can use it for some basic things. As > you're > clear you don't have one and have no intention of showing you do by > re-applying > with a signed email I can't see how you would be able to maintain packages. > > In addition, you don't have any packaging experience on Arch. The first > step > is AUR. Get your feet wet somewhere that is simpler like AUR. I would > suggest > you get some experience there first before you have to deal with submitting > community etc. packages that actually have more layers of work to be done > over > and above what AUR needs, so AUR "work" is like learning the first 50% of > what > is needed. > > I think it'd be great if you did arrange to have a PGP key, showed us you > have > one by signing an application after you've done some AUR packaging for a > bit. > > This is what I did - I maintained some AUR packages for a while then > expanded > the number I work on and eventually applied to maintain more "core" > packages > because I too an am upstream. > > I'm not one of these "I must PGP sign everything" people. I'm not that > security-focused about my utterances by e-mail, but I do see the point of > it > for packaging and I jumped through the hoops to deal with it. > > I get your feeling of "Why bother - it's just an email", but it's a > necessary > component in the packaging pipeline and ecosystem. You're not expected to > be > some PGP guru. You're just expected to be able to sign some package to say > it > was you that packaged it an that requires you do "jump through some hoops" > at > this stage. I hope you'll reconsider. That’s completely understandable. Today I’ll create an aur component for Codevis, a software to visualize large architectures Im developing for the past three years (that just got opensourced) And I’ll also create a GPG key, and sign some email on this thread with it. Best, Tomaz > > > > -- > Carsten Haitzler <raster(a)archlinux.org> >

1 1

nvidia-470xx packages broken and maintainers don't react, how to proceed with this?
by Michael Kogan 09 Jul '23

09 Jul '23

Hello list! Currently the nvidia-470 packages [1] are broken and there is no reaction from the packages' maintainers. They did an absolutely awesome job by keeping the packages alive for a really long time and guaranteed absolutely smooth upgrades, but for some reason they currently don't react to out-of-date requests. The current situation is that the kernel module's compilation is broken, but the package still builds and installs, making the machine fallback to TTY after an update. There seem to be patches in the comments but they are tedious to use in a TTY only environment, so it would be great if some of the guys who provided the patches would be added as co-maintainer such that the patches can be included into the package. Best, Michael [1] https://aur.archlinux.org/packages/nvidia-470xx-dkms

3 4