- Aur-general - lists.archlinux.org

[aur-general] TU application for Caleb, aka alerque
by Caleb Maclennan 05 Jul '21

05 Jul '21

Hello all! My name is Caleb Maclennan (AUR moniker “caleb”, most other places “alerque”). I’m a long time Arch Linux user and AUR contributor looking to get more involved, and specifically to join the TU group so that I can help out with packages in [community]. I’m particularly interested in the Lua ecosystem (which thanks largely to @Daurnimator is much less of a mess than it was a year ago when I first started looking into becoming a TU, but could still use a helping hand) as well as anything related to font development or typesetting. As you’ll see I have some experience in FOSS, software packaging, and Linux in general, but maybe the most important thing is I can still learn and I’m open to learning and adapting so that my contributions are in cooperation with the rest of the community, not in conflict with it. Two existing TUs, Daurnimator and Archange, have agreed to sponsor my application: * https://archlinux.org/people/trusted-users/#daurnimator * https://archlinux.org/people/trusted-users/#Archange For full disclosure I did put out feelers about a year ago looking for sponsors and didn’t get any takers at the time. Nobody outright refused but several emails went unanswered and TUs in IRC commented on various things but nobody “bit”. As for the minimum basic requirements: * I definitely know my way around shell scripts (I prefer ZSH, but have a good grasp of Bash and POSIX usage too) and also most VCS systems. * I’ve been maintaining hundreds of AUR packages for some years, some of them cleaner than others. I would expect anything destined for [community] to be held to a high standard of cleanliness and testing and won’t be offended if some hacks I’ve let slide in the AUR aren’t appropriate for other repos. * The weak point in my application may be my low bbs/mailing list involvement, but you can check my Stack Exchange profile or other places to see that I’m not clueless. I’ll be willing to keep in touch with other TUs (and the bug tracker, which I feel like is sometimes neglected for community packages). * Yes I can Google words. * Below I’ll outline some packages and my various interests in them. * I have some past involvement reporting in the Flyspray and GitLab trackers for Arch packages and projects. * I don’t recall sending patches for any Arch projects yet, only patches for packaging. * I have lots of other FOSS involvement, everything from well known projects like Harfbuzz or Pandoc to esoteric VIM plugins. I have upstream contributions to dozens of projects in [community] already and a large chunk of the things I current package on the AUR. Packages I have previously maintained in the AUR which have already been adopted into [community]; where extra hands are welcome I could still help with these: * age * birdfont * gentium-plus-font * git-annex * git-crypt * gitlab * gitlab-workhorse * grunt-cli * lua-filesystem * lua51-penlight * mattermost * otf-libertinus * pqiv * python-hsluv * python-pytoml * shutter (later demoted back to AUR for good reason) * ttf-hack * xkcdpass * yq Other packages already in [community] which interest me and I would potentially be interested in co-maintaining, help keeping up to date, fixing packaging bugs, etc: * hledger: upstream contributor \ Flyspray packaging reports have taken months and some years * lilypond * lua-penlight: upstream contributor \ has often been months OOD even when patches in Flyspray * pandoc: upstream contributor \ is less ofter a problem recently but historically was often OOD in \ community, I know the Haskell deps are deep dark depths, but having \ it OOD has been a constant pain point for me * sword * tridactyl: upstream contributor * vim-nerdcommentor: upstream maintainer * vim-nerdtree: upstream contributor Current (semi) orphans in [community] I might pick up: * python-fonttools \ (current maintainer Andrzej recently said they need help) * python-unicodedata2 (same) Things I currently maintain in the AUR that I would like to see eventually migrated to [community], of course dependent on all the packaging details and usage stats being copastetic: * asterisk * csvkit * epubcheck * font-manager * gitlab-pages * lua-busted * lua-posix * marktext * myrepos * praat * programmers-dvorak * sile: upstream maintainer (+12 lua-* deps) * ttfautohint * vcsh * xiphos * zerobane-studio * zettlr Things I don’t maintain in the AUR but would like to see moved someday (off the top of my head, I’m sure there are more): * bottom * duf * git-delta * gitahead * gitlab-glab * wp-cli AUR packages: * Maintainer (553): https://aur.archlinux.org/packages/?K=caleb&SeB=m * Co-maintainer (90): https://aur.archlinux.org/packages/?K=caleb&SeB=c Even with hundreds of AUR packages I only get a trickle of OOD flags because I follow most of the projects I package upstream. At the very least I subscribe to release notices, but often I’m more involved and use the packages myself, so am motivated to keep them up to date. I have just a wee bit of *nix experience over the past 27 years, for example you can have a look around my Stack Exchange profile for the Unix & Linux site: https://unix.stackexchange.com/users/1925/caleb?tab=topactivity Over the years I’ve been involved in quite a few FOSS projects: * Github profile: https://github.com/alerque * Gitlab profile: https://gitlab.com/alerque * OpenHub profile: https://www.openhub.net/accounts/alerque This won’t even be my first Linux distro rodeo. After cutting my teeth on early RedHat (when it came on 4 floppies!) I eventually became heavily involved in PLD Linux development from 1998 to 2012 (when I started switching to Arch Linux). I was a member of the CDG (Core Developers Group) and contributed thousands of packaging updates. I was always in good standing with the other team members. My current Arch usage includes use or admin responsibilities OS on 9 desktops, 4 laptops, 13 assorted devices (RPis, print and NAS servers), 6 permanent cloud servers, 3 bare metal servers, and any number of containers (ephemeral cloud server instances, local and remote Docker/lxc services, VirtualBox, etc.). It has been my daily driver for desktop and server use for 9 years now. Thank you for your consideration, and I look forward to hopefully many more years of being part of a great distro! Caleb P.S. Obligatory flame war fodder: (Neo)vim forever, always use Oxford commas, spaces not tabs, döner and tacos.

15 34

[aur-general] Package `pijul` in both AUR and Community-Testing
by Markus Arians 02 Jul '21

02 Jul '21

Hi everyone, today I noticed I was unable to push to the AUR repository for the pijul package with the server hook error message "remote: error: package already provided by [community-testing]: pijul". Sure enough, the package exists in the Community-Testing repository (see https://archlinux.org/packages/community-testing/x86_64/pijul/) Now, as far as I understand, packages can be "promoted" to the community / community-testing repository, however, in this case it seems like a new package with the same name has been created. Is this the usual procedure? What will my responsibilities as packager of the AUR pijul package be? What happens to the AUR package? Should I just leave it as it is? Submit a delete request? Thanks for your help! Markus

6 10

[aur-general] Mailing List Address Update
by Kevin Morris 26 Jun '21

26 Jun '21

Hi aur-general, The mailing list has undergone a specific modification in which <list>@archlinux.org no longer deals with or redirects to <list>@lists.archlinux.org. At this point, the newly required address for the aur-general mailing list is: aur-general(a)lists.archlinux.org Thank you all for the hard work you do and contributing to AUR for the benefit of the community! Regards, Kevin Morris kevr @ Libera -- Kevin Morris Software Developer Identities: - kevr @ Libera

1 0

[aur-general] Issue a warning while (re)packaging a binary package?
by Jan Kohnert 18 Jun '21

18 Jun '21

Hi, a new version of a (binary) package I'm maintaining (clockify-desktop) requires an executable /tmp directory to run. So I'd thought about adding a warning to the PKGBUILD if /tmp is mounted noexec (as on all of my maschines). Unfortunately I could not find a hint in the documentation if 1. this idea is considered "good behaviour" 2. where exactly to put the warning. My first attempt whould be something like adding a pre/post install check, if the directory is executable and print a message in case it is not. Any thoughts on this one? Thanks and best regards -- MfG Jan

4 5

[aur-general] Renaming packages - scaleft client and server tools
by Tony G. 13 Jun '21

13 Jun '21

Hello! I maintain a few packages and was pointed out by a user that the naming should be different (due to being a prebuilt deliverable). I found in the forums a similar case[0] and the suggestion was to send an email to this DL. I've already created a new repository with the new names, but I'd like to merge the old packages into the new ones. In the thread I read that it is possible to preserve comments and votes, if that's possible that would be great. In any case any pointer to what's the best approach is appreciated. | Old package | New package | | -------------------- | ------------------------ | | scaleft-client-tools | scaleft-client-tools-bin | | scaleft-server-tools | scaleft-server-tools-bin | Thanks!! [0] https://bbs.archlinux.org/viewtopic.php?id=175628 -- Tony G.

2 2

[aur-general] NVHPC packages changes the default compiler for the System
by Jayesh Badwaik 10 Jun '21

10 Jun '21

Dear All, I hope this is the correct place to post the message. The `nvhpc` package adds a files `/etc/profile.d/nvhpc.sh` to the system. This file sets the environment variables: export CC=$nvcompdir/bin/nvc export CXX=$nvcompdir/bin/nvc++ export FC=$nvcompdir/bin/nvfortran export F90=$nvcompdir/bin/nvfortran export F77=$nvcompdir/bin/nvfortran export CPP=cpp This changes the default compiler of the system and thereby causing all utilities which honor the environment variable to fail. I wish that the `nvhpc.sh` should not be installed in `/etc/profile.d` and instead should be in a location which is not read by default. That way, the user who wants to opt into it can opt in. I know AUR is maintained by volunteers, but I'm hoping to reach the maintainer of the `nvhpc` packages through this mail. Thank you. -- Best Jayesh Badwaik Juelich Supercomputing Center Forschungzentrum Juelich

1 0

[aur-general] About the vuescan-bin package updating problm
by Thibault Molleman 30 May '21

30 May '21

So, I like the Vuescan app and I respect the developer for having made it. Really glad I paid for it. BUT it has to be said that installing/updating this aur package is a disaster. Basically: the download urls and/or the checksums keep changing to the point where 90% of the time when you try to update/install it, the pkgbuild is already out of date. I emailed the developer asking if he could adopt a better download url system. He replied: "No, I want people to only download VueScan from www.hamrick.com and I’m trying to figure out ways of disabling downloading from other sites." I explained to him that downloading from a repo or via a pkgbuild is such a convenient method and one of the key selling points of using Linux tbh. But haven't received an answer back (it has only been 3 days. But still). I really hope this 'issue' can somehow be resolved so people can properly install this great app without the constant cat-mouse game of trying to update the checksum fast enough. Cheers, Thibault

4 7

Re: [aur-general] Notification of GPL violation
by Manhong Dai 26 May '21

26 May '21

> Date: Thu, 20 May 2021 15:05:21 -0500 > From: "David C. Rankin" <drankinatty(a)gmail.com> > To: aur-general(a)lists.archlinux.org > Subject: Re: [aur-general] Notification of GPL violation > Message-ID: <c2e5a266-a494-7057-e4af-cbe57964c677(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > On 5/18/21 2:06 AM, Brett Cornwall via aur-general wrote: > > On 2021-05-17 21:16, Carsten Haitzler via aur-general wrote: > > > On Mon, 17 May 2021 13:32:26 +0000 lawl via aur-general > > > <aur-general(a)lists.archlinux.org> said: > > > > > > > Hello > > > > > > > > I'm the developer of NoiseTorch ( > > > > https://github.com/lawl/NoiseTorch/) > > > > I faithfully believe that the package "noisetorch" in the > > > > ArchLinux User > > > > Repository ("AUR") ( > > > > https://aur.archlinux.org/packages/noisetorch/) violates > > > > my license (GPLv3). > > > > > > > > I have the asked previous maintainer of this package to not apply > > > > patches or > > > > make it clear that this is a fork that's being conveyed. Several > > > > Arch Linux > > > > trusted users were also informed of this: > > > > https://github.com/lawl/NoiseTorch/issues/2#issuecomment-785262068 > > > > > > I am just looking at the AUR repository for this right now. It has > > > no patches. > > > It does not modify anything from the original. It builds the > > > original with > > > standard go tooling and options available in that toolchain (not > > > modifications > > > to your software) and then packages up the resulting build. The > > > only addition > > > is ADDING a .desktop file to that package archive to make it easier > > > to run the > > > application. This does not modify the software. So by your quotes > > > below it > > > meets > > > the license requirements. I don't know what was in the AUR pkg repo > > > before but > > > it certainly seems to be fine now. > > > > For anyone else wondering what the fuss is all about, this is a long- > > running > > bout of drama stirred up by the developer of Noisetorch [1]. They are > > hostile > > and will not be reasoned with, unfortunately. > > > > We are under no obligation to listen to these demands as we do not > > distribute > > the software and only supply a build script for which a user may > > build their > > own package. Kowtowing to this petulance will hardly solve the > > problem > > long-term as it is clear that *any* packages not made by the > > developer are > > treated with hostility. > > > > But I guess hashworks has already extended the olive branch; We'll > > have to see > > whether that's enough... > > > > > > [1] > > https://github.com/lawl/NoiseTorch/issues/2#issuecomment-785262068 > > I have reviewed all commits from > 811aec6641ff509bd44cd80aa872f71df502e36a > forward and there was no GPLv3 violation to begin with. The patch of > the > version is irrelevant to the operation or use of the software. > > (notwithstanding that Arch doesn't distribute anything to begin with) > > Probably kinda hard for a Go programmer to understand... > I know I will be the minority in this list. However, this statement doesn't sound right to me if the patch file is applied to the original source code. Unlike the file PKGBUILD, a patch file constitutes a modified source code because it does include some original code. No matter whether the modification is for use, or operation, or just even a typo fix, GPLV3 section 5 "Conveying Modified Source Versions" [1] doesn't distinguish them. I had a similar experience in terms of the AUR package SGE. I put my source code modification into a single patch file and put it to AUR git. Without my modification, SGE won't work with latest Linux anymore. However, due to an AUR website bug confirmed by a TU, the package was taken over without any emails sent to me. After a lot of back and force with the second maintainer, I finally gave up re-owning the package or making the software better within AUR. Instead I asked the second maintainer to add my name to the single patch file so I get the credit I deserve. However, the second maintainer denied that. He split the patch into many small patch files without my name in any of them, and insists that it is enough to have my name as the first AUR package maintainer. Then I asked him to remove my code modification, also was denied. Then I tried to ask TU to remove the package many times, all TUs denied my request, except the last TU deleted all those small patch files after he understood this is a serious copyright violation issue. Here is my understanding about those copyright conflicts. If you modified any source code, then GPL license will be applied, you have to copy the original copyright without any modification and then add yours, just as section 4 in GPL v3 says "You may convey verbatim copies of the Program's source code as you receive it" It is understandable that many AUR maintainers, or programmers like myself, don't know the details and often violates some copyright law more or less. We are lucky that most upstream programmers don't mind it. But, should such issue arise, I would do my best to make the upstream programmer happy or just find another alternative software. I know I am the minority in this list because the AUR SGE got two up- votes ironically after it didn't work anymore, and the second maintainer is even promoting the binary version based on my modification on some other repos. But, life is too short, I can live with it. I am writing this email because I just hope my painful experience can help this list know copyright better. [1] https://www.gnu.org/licenses/gpl-3.0.en.html Best, Manhong

18 54

[aur-general] Mass removal of packages.
by Derek Taylor 24 May '21

24 May '21

I received a notice that several of my suckless builds (dwm-distrotube-git, st-distrotube-git, dmenu-distrotube-git) have been deleted from the AUR due to being "for one person". That's certainly reasonable but these packages are not for one person. A lot of people use these and depend on them. Again, these builds are not for one person. What can be done about this? Thanks in advance, DT

5 4

[aur-general] Notification of GPL violation
by lawl 20 May '21

20 May '21

Hello I'm the developer of NoiseTorch (https://github.com/lawl/NoiseTorch/) I faithfully believe that the package "noisetorch" in the ArchLinux User Repository ("AUR") (https://aur.archlinux.org/packages/noisetorch/) violates my license (GPLv3). I have the asked previous maintainer of this package to not apply patches or make it clear that this is a fork that's being conveyed. Several Arch Linux trusted users were also informed of this: https://github.com/lawl/NoiseTorch/issues/2#issuecomment-785262068 Unfortunately this seemed to have little effect, forcing me to officially notify the ArchLinux project of this violation. The GPLv3 in Section 5 clearly states that modified versions must be marked as such > 5. Conveying Modified Source Versions. > > You may convey a work based on the Program, or the modifications to > produce it from the Program, in the form of source code under the > terms of section 4, provided that you also meet all of these conditions: > > a) The work must carry prominent notices stating that you modified > it, and giving a relevant date. The term conveyance is also clearly defined in the GPL: > To "propagate" a work means to do anything with it that, without > permission, would make you directly or secondarily liable for > infringement under applicable copyright law, except executing it on a > computer or modifying a private copy. Propagation includes copying, > distribution (with or without modification), making available to the > public, and in some countries other activities as well. > > To "convey" a work means any kind of propagation that enables other > parties to make or receive copies. Mere interaction with a user through > a computer network, with no transfer of a copy, is not conveying. Since AUR is distributing packages to automate the process receiving modified versions of the source code, I believe this constitutes conveyance of a modified version, irregardless of where the original source code tarball is fetched from. Please ensure the cessation of violation of the license immediately. Regards lawl Sent with [ProtonMail](https://protonmail.com) Secure Email.

14 24