September 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

Dealing with unclear upstream licensing and legality
by netsysfire＠das-labor.org 27 Sep '23

27 Sep '23

abgx360 has been deleted recently (see https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/…). I noticed it because https://wiki.archlinux.org/title/Burning_Xbox_360_games has a broken link. There are two reasons for the deletion: 1. Legality of home backups. Though we have stuff like popcorntime in the AUR or even whipper in extra, so it should not matter. 2. Bad licensing. There is no upstream license set, thus applying the default copyright rules: > You're under no obligation to choose a license. However, without a > license, the default copyright laws apply, meaning that you retain all > rights to your source code and no one may reproduce, distribute, or > create derivative works from your work. However, as the AUR only ships PKGBUILDs we are neither reproducing or distributing it and it does also not seem like a derivative work. Alad already poked upstream about this. https://github.com/BakasuraRCE/abgx360/issues/7 This was also painstakingly discussed on IRC in both -aur and -wiki, leading to walls of text. Antiz made the decision to delete in good faith and there was apparently also an internal discussion in the staff channel, which we agreed on should have been public. My opinion is that the package should be restored. I do not even use it and only noticed because of said dead link, yet the decision feels off. Antiz said that they are rethinking it, too.

7 12

Possible duplicate or bad naming (greenclip and rofi-greenclip)
by Polarian 26 Sep '23

26 Sep '23

Hello, I have found the following two packages: https://aur.archlinux.org/packages/greenclip https://aur.archlinux.org/packages/rofi-greenclip At first by name they seem like duplicates, but it seems greenclip is a source package and rofi-greenclip is a binary package but has not added the -bin suffix which has caused duplication. I can't really "flag for bad naming" so I decided to post it here to bring attention to it so it can be fixed. As greenclip is an open source project a binary package should be suffixed with -bin as per the packaging guidelines, so although greenclip is a duplicate it is actually correctly named unlike the latter. As it seems to be a rofi integration the name "rofi-greenclip" does seem like a much better name, so I would suggest the following: - rofi-greenclip is renamed to rofi-greenclip-bin as it is a binary package. - greenclip being a source package is named correctly, however as it is a rofi addition it might be better to rename it to rofi-greenclip, but there is no conventions to the best of my knowledge which "force" this rename, just a possible improvement. Let me know if I have misunderstood or made any mistakes, or if you disagree with my suggestion :) Also I hate to point this out, but the reason I found this was editing the ArchWiki, I am not playing moderator, an wiki page can not provide the right package name if there is two packages which are conflicting one another. I had to point this out to prevent bad faith so I apologise for being defensive. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev

2 4

Packages being flagged out of date
by Jeremy Gust 18 Sep '23

18 Sep '23

I have noticed several packages that have been flagged out of date, but they are not. The stated reason for the flag will be a problem the user has with the PKGBUILD that is unrelated to the program's version or if the package can be built. I did not see anything in the wiki directly addressing this, so, being relatively new to contributing to the AUR I was curious if this is considered appropriate. At least one package also has an orphan request referencing the flag, which seems misleading to me if the flag should only be used for alerting the maintainer and users to a new version upstream. I have purposely not included package names to avoid calling out anyone publicly.

5 16

AUR Cleanup Day September 20th 2023
by Daniel M. Capella 18 Sep '23

18 Sep '23

Our bi-yearly AUR Cleanup Day is coming up this Wednesday, but we currently have a very large number of requests in the queue. The Trusted Users will instead be having a spa day this year. If you feel the urge to hunt down packages and file requests against them, knock yourself out. https://wiki.archlinux.org/title/AUR_Cleanup_Day -- Best, Daniel <https://danielcapella.com>

1 0

Java version to use
by Polarian 17 Sep '23

17 Sep '23

Hello, I have looked around for an answer to this, but I have yet to find one. I try to stay quite rigid to the Arch way of doing things, trying to use the latest version of all tools to build said codebase. I have just updated one of my packages to use the Arch Gradle version instead of the gradle version used by upstream, I have also recently migrated the same project to using the latest version of node as it is compatible. For more information about this migration, see: https://github.com/reposilite-playground/reposilite-aur/issues/17. So this brings up a new question, what Java version to build packages with? Older Java versions are supported, and compiling with older Java gives more backwards compatibility (new Java versions can use old bytecode, but old Java versions cant use new bytecode). Personally I am tipping towards building with the latest java version (jdk-openjdk), if the code provided by upstream compiles just fine for said version, shouldn't we promote using the latest versions instead of building with the "officially recommended" versions, this is Arch, the idea is to use the newest tools which are packaged is it not? I got a feeling people might complain not being able to use their old versions of Java with newer builds, but new Java versions have performance improvements, memory improvements, and just general improvements to allow the JVM to run better, so why not push for the latest version to get used? I know this breaks Java ideology, which is compile once run anywhere, but I say compile latest and have the best optimisations possible. I am interested to see what others think about this, as it is within the AUR I can trail this and see how it goes. Of course, if the project doesn't build with the latest version, use an older runtime, but why are we adding >=11, Java 11 is old now, and although it is LTS and the most common version, the performance difference between 11 and 20. I have found the following (I do not know how reliable said statistics is), but it should give a general idea of why I believe this is beneficial: https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html Please let me know what others think about this? It boils down to compatibility or performance, and I would go for performance, but my opinion is NOT all that matters :) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev

1 0

How is this package even in AUR?
by GoldenKnightFly 17 Sep '23

17 Sep '23

Hello, how is the `bun-termux` package even in AUR? It's literally a package for Termux, not for Arch Linux. Take a look at the PKGBUILD: mv "${srcdir}/bun-linux-aarch64/bun" "${PREFIX}/bin/bun" It's literally pointing to Termux prefix which is `/data/data/com.termux/files/usr`.

5 7

Need advice on how to address possible conflict with former (no longer existing) AUR package
by Ildar Sagdejev 12 Sep '23

12 Sep '23

I published my first ever AUR package: https://aur.archlinux.org/packages/polyglot-git As per the submission guidelines, I made sure that neither `polyglot` nor `polyglot-git` currently exist in any official repositories or the AUR. Upon publishing my package, I saw that it is listed as optionally required by four other AUR packages, including this one (due to listing `polyglot` as provided in the PKGBUILD): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=polyglot-winboard-git The package `polyglot` no longer exists, but its PKGBUILD is still available: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=polyglot As things stand, those four packages will automatically pull in the one I just published as a dependency for no good reason. I'm asking for advice as to which actions it would be most proper to take at this point.

4 4

Problems with AUR packager Xiota and motivewave
by Xavier Baez 06 Sep '23

06 Sep '23

The variable they recommended was build_id but that didn't create a clean makepkg --printsrcinfo > .SRCINFO Here are some of the comments, it's like https://aur.archlinux.org/packages/motivewave#comment-932313 https://aur.archlinux.org/packages/motivewave#comment-932245 https://aur.archlinux.org/packages/motivewave#comment-932340 https://aur.archlinux.org/packages/motivewave#comment-932245 https://aur.archlinux.org/packages/motivewave#comment-932340 Xiota also manages chaotic AUR, so he created an 'issue' where two packages wouldn't be able to exist, so he deleted motivewave and created motivewave-latest-bin Then I got re-uploaded, and within hours he re-deleted me again. He also blocked me from their Git. Then he moved again to AUR motivewave to team up and the comments started again. I would like to know what the rules are, today at Labor Day 3 AM the change requests arrive again, yesterday I had to leave church to come home and do more changes Test the package, was working. I don't want to be forced to use variables or have a permanent code reviewer. Be called incompetent or imply I am dumb and need help. This is in the git and shows how their suggestions actually broke the package. I created my custom variable but the nit picking has not continued. Calling a person non competent, rude, rude, rude. Especially when today the issue has been resolved. Here is how the package broke because code review. commit 1bceb28d1875deb4a303e6f13ee51e1ea86c0011 Author: Xavier Baez <xavierbaez(a)gmail.com> Date: Sun Sep 3 09:12:02 2023 -0700 changes suggested by muflone When .SRCINFO is automatically generated with makepkg the following changes happen in SRCINFO - source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/500/motivewave_.deb + source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/{}/motivewave{6.7.10}_amd64.deb diff --git a/.SRCINFO b/.SRCINFO index e82622d..1dd9db6 100644 --- a/.SRCINFO +++ b/.SRCINFO @@ -1,7 +1,7 @@ pkgbase = motivewave pkgdesc = Advanced trading and charting application. pkgver = 6.7.10 - pkgrel = 3 + pkgrel = 4 url = https://www.motivewave.com arch = x86_64 license = custom @@ -13,7 +13,7 @@ pkgbase = motivewave depends = xorg-xrandr provides = motivewave conflicts = motivewave-latest-bin - source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/500/motivewave_.deb + source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/{}/motivewave{6.7.10}_amd64.deb sha512sums = c97e3bb78236d6ef1ae8581e29b128e6ee512f8241617dbcab5989f3068bfa6bbe9b9c091bb09b238ea891f59e6c12ef13ceee079610f3fc95722c58c4769bb9 -- Regards Xavier

6 6

Re: Problems with AUR packager Xiota and motivewave
by Aaron Liu 05 Sep '23

05 Sep '23

AUR TUs are kinda busy and they don't delete things immediately. I'm not sure why they want you to remove the conflicts before it is deleted but that's not why xiota accused you of incompetence either. Also, please include aur-general in your replies. If your email client has a "reply to list" button use that; if not try using a "reply all" button. On 2023/9/4 18:53, Xavier Baez wrote: > I want to maintain the package. > motivewave-latest-bin was supposed to be deleted yesterday. > > If that package is removed then motivewave wouldn’t have any > conflicting packages. > > motivewave has motivewave-latest-bin listed as conflicts (which is > accurate) > > And motivewave-latest-bin has motivewave listed as conflicts (which is > accurate) > > So today Xiota accused me of incompetence, motivewave indeed conflicts > with motivewave-latest-bin. > > Not following Xiota commands step by step does not make me incompetent. > > Xiota claims the motivewave-latest-bin package will be deleted, but > only after I remove motivewave-latest-bin as a conflict. > > > I wonder what’s the interest in me removing motivewave-latest-bin > first, and why does he even cares about that. > > According to > https://wiki.archlinux.org/title/PKGBUILD#conflicts > > These packages are in conflict. > They have the exact same source. > > > On Mon, Sep 4, 2023 at 3:29 PM Aaron Liu <aaronliu0130(a)gmail.com> wrote: > > I don't see why you're that infuriated. xiota is indeed a bit > combative with language but save for removing `conflicts` their > suggestions all look good. Simply adding the "no same owner" > removes the need for all that find chmod and chown stuff and just > put the conflicting packing name under "conflicts", no need to > make a new variable. > > You can't accuse a suggestion of being wrong if you don't > implement it completely and you already did implement the dynamic > URL in the pkgbuild right; why are you still suggesting that > implementing it breaks the package? It already works albeit > suboptimally because the no-same-owner stuff hasn't been implemented. > > You do not have to maintain this package. Nobody is forcing you to > go back from church or a funeral. Your email seems like you're > nitpicking their admittingly combative language, and I don't see > any nitpicks in the line-by-line review. "Code review" has no > negative connotations. > > On 2023/9/4 15:20, Xavier Baez wrote: >> The variable they recommended was build_id >> but that didn't create a clean >> >> makepkg --printsrcinfo > .SRCINFO >> >> Here are some of the comments, it's like >> >> https://aur.archlinux.org/packages/motivewave#comment-932313 >> https://aur.archlinux.org/packages/motivewave#comment-932245 >> https://aur.archlinux.org/packages/motivewave#comment-932340 >> https://aur.archlinux.org/packages/motivewave#comment-932245 >> https://aur.archlinux.org/packages/motivewave#comment-932340 >> >> Xiota also manages chaotic AUR, so he created an 'issue' where >> two packages wouldn't be able to exist, so he deleted motivewave >> and created motivewave-latest-bin >> >> Then I got re-uploaded, and within hours he re-deleted me again. >> He also blocked me from their Git. >> >> Then he moved again to AUR motivewave to team up and the comments >> started again. >> >> I would like to know what the rules are, today at Labor Day 3 AM >> the change requests arrive again, yesterday I had to leave church >> to come home and do more changes Test the package, was working. >> I don't want to be forced to use variables or have a permanent >> code reviewer. >> Be called incompetent or imply I am dumb and need help. >> >> This is in the git and shows how their suggestions actually broke >> the package. >> I created my custom variable >> >> but the nit picking has not continued. >> >> Calling a person non competent, rude, rude, rude. >> Especially when today the issue has been resolved. >> >> Here is how the package broke because code review. >> >> commit 1bceb28d1875deb4a303e6f13ee51e1ea86c0011 >> Author: Xavier Baez <xavierbaez(a)gmail.com> >> Date: Sun Sep 3 09:12:02 2023 -0700 >> >> changes suggested by muflone >> >> When .SRCINFO is automatically generated with makepkg >> >> the following changes happen in SRCINFO >> - source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/500/motivewa… >> + source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/{}/motivewav… >> <https://downloads.motivewave.com/builds/%7B%7D/motivewave%7B6.7.10%7D_amd64…> >> >> diff --git a/.SRCINFO b/.SRCINFO >> index e82622d..1dd9db6 100644 >> --- a/.SRCINFO >> +++ b/.SRCINFO >> @@ -1,7 +1,7 @@ >> pkgbase = motivewave >> pkgdesc = Advanced trading and charting application. >> pkgver = 6.7.10 >> - pkgrel = 3 >> + pkgrel = 4 >> url = https://www.motivewave.com >> arch = x86_64 >> license = custom >> @@ -13,7 +13,7 @@ pkgbase = motivewave >> depends = xorg-xrandr >> provides = motivewave >> conflicts = motivewave-latest-bin >> - source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/500/motivewa… >> + source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/{}/motivewav… >> <https://downloads.motivewave.com/builds/%7B%7D/motivewave%7B6.7.10%7D_amd64…> >> sha512sums = >> c97e3bb78236d6ef1ae8581e29b128e6ee512f8241617dbcab5989f3068bfa6bbe9b9c091bb09b238ea891f59e6c12ef13ceee079610f3fc95722c58c4769bb9 >> >> >> -- >> Regards >> >> Xavier >> >>

1 0