- Aur-general - lists.archlinux.org

TU Application - tpkessler
by Torsten Keßler 20 Nov '22

20 Nov '22

Hi! I'm Torsten Keßler (tpkessler in AUR and on GitHub) from Saarland, a federal state in the south west of Germany. With this email I'm applying to be become a trusted user. After graduating with a PhD in applied mathematics this year I'm now a post-doc with a focus on numerical analysis, the art of solving physical problems with mathematically sound algorithms on a computer. I've been using Arch Linux on my private machines (and at work) since my first weeks at university ten years ago. After initial distro hopping a friend recommended Arch. I immediately liked the way it handles packages via pacman, its wiki and the flexibility of its installation process. Owing to their massively parallel architecture, GPUs have emerged as the leading platform for computationally expensive problems: Machine Learning/AI, real-world engineering problems, simulation of complex physical systems. For a long time, nVidia's CUDA framework (closed source, exclusively for their GPUs) has dominated this field. In 2015, AMD announced ROCm, their open source compute framework for GPUs. A common interface to CUDA, called HIP, makes it possible to write code that compiles and runs both on AMD and nVidia hardware. I've been closely following the development of ROCm on GitHub, trying to compile the stack from time to time. But only since 2020, the kernel includes all the necessary code to compile the ROCm stack on Arch Linux. Around this time I've started to contribute to rocm-arch on GitHub, a collection of PKGBUILDs for ROCm (with around 50 packages). Soon after that, I became the main contributor to the repository and, since 2021, I've been the maintainer of the whole ROCm stack. We have an active issue tracker and recently started a discussion page for rocm-arch. Most of the open issues as of now are for bookkeeping of patches we applied to run ROCm on Arch Linux. Many of them are linked to an upstream issue and a corresponding pull request that fixes the issues. This way I've already contributed code to a couple of libraries of the ROCm stack. Over the years, many libraries have added official support for ROCm, including tensorflow, pytorch, python-cupy, python-numba (not actively maintained anymore) and blender. Support of ROCm for the latter generated large interest in the community and is one reason Sven contacted me, asking me if I would be interested to take care of ROCm in [community]. In its current version, ROCm support for blender works out of the box. Just install hip-runtime-amd from the AUR and enable the HIP backend in blender's settings for rendering. The machine learning libraries require more dependencies from the AUR. Once installed, pytorch and tensorflow are known to work on Vega GPUs and the recent RDNA architecture. My first action as a TU would be to add basic support of ROCm to [community], i.e. the low level libraries, including HIP and an open source runtime for OpenCL based on ROCm. That would be enough to run blender with its ROCm backend. At the same time, I would expand the wiki article on ROCm. The interaction with the community would also move from the issue tracker of rocm-arch to the Arch Linux bug tracker and the forums. In a second phase I would add the high level libraries that would enable users to quickly compile and run complex libraries such as tensorflow, pytorch or cupy. #BEGIN Technical details The minimal package list for HIP which includes the runtime libraries for basic GPU programming and the GPU compiler (hipcc) comprises eight packages * rocm-cmake (basic cmake files for ROCm) * rocm-llvm (upstream llvm with to-be-merged changes by AMD) * rocm-device-libs (implements math functions for all GPU architectures) * comgr (runtime library, "compiler support" for rocm-llvm) * hsakmt-roct (interface to the amdgpu kernel driver) * hsa-rocr (runtime for HSA compute kernels) * rocminfo (display information on HSA agents: GPU and possibly CPU) * hip-runtime-amd (runtime and compiler for HIP, a C++ dialect inspired by CUDA C++) All but rocm-llvm are small libraries under the permissive MIT license. Since ROCm 5.2, all packages successfully build in a clean chroot and are distributed in the community repo arch4edu. The application libraries for numerical linear algebra, sparse matrices or random numbers start with roc and hip (rocblas, rocsparse, rocrand). The hip* packages are designed in such a way that they would also work with CUDA if hip is configured with CUDA instead of a ROCm/HSA backend. With few exceptions (rocthrust, rccl) these packages are licensed under MIT. Possible issues: There are three packages that are not fully working under Arch Linux or lack an open source license. The first is rocm-gdb, a fork of gdb with GPU support. To work properly it needs a kernel module currently not available in upstream linux but only as part of AMD's dkms modules. But they only work with specific kernel versions. Support for this from my side on Arch Linux was dropped a while ago. One closed source package is hsa-amd-aqlprofile. As the name suggests it is used for profiling as part of rocprofiler. Above mentioned packages are only required for debugging and profiling but are no runtime dependencies of the big machine learning libraries or any other package with ROCm support I'm aware of. The third package is rocm-core, a package only part of the meta packages for ROCm with no influence on the ROCm runtime. It provides a single header and a library with a single function that returns the current ROCm version. No source code has been published by AMD so far and the official package lacks a license file. A second issue is GPU support. AMD officially only supports the professional compute GPUs. This does not mean that ROCm is not working on consumer cards but merely that AMD cannot guarantee all functionalities through excessive testing. Recently, ROCm added support for Navi 21 (RX 6800 onwards), see https://docs.amd.com/bundle/Hardware_and_Software_Reference_Guide/page/Hard… I own a Vega 56 (gfx900) that is officially supported, so I can test all packages before publishing them on the AUR / in [community]. #END Technical details On the long term, I would like to foster Arch Linux as the leading platform for scientific computing. This includes Machine Learning libraries in the official repositories as well as packages for classical "number crunching" such as petsc, trilinos and packages that depend on them: deal-ii, dune or ngsolve. The sponsors of my application are Sven (svenstaro) and Bruno (archange). I'm looking forward to the upcoming the discussion and your feedback on my application. Best, Torsten

7 15

Comment on cemu page
by Fabio Loli 17 Nov '22

17 Nov '22

User Anuskuss have returned today to harass the cemu maintainer https://aur.archlinux.org/packages/cemu#comment-890175 Previous behaviour can be seen on aur-requests about cemu and cemu comments section

1 0

Are CachyOS PKGBUILDs allowed on AUR?
by Frederic Bezies 15 Oct '22

15 Oct '22

Hello. CachyOS - https://cachyos.org/ - is another archlinux based distribution with a lot of custom tools and kernels, using KDE as a GUI. I installed in a VM CachyOS and noticed all its customized package in a dedicated repository. My question is: are these custom PKGBUILD are or not allowed on AUR? Here is a link to all CachyOS related PKGBUILDs (30): https://aur.archlinux.org/packages?O=0&K=cachyos Thanks a lot for your kind answer. -- Frederic Bezies fredbezies(a)gmail.com

3 2

Lost account
by Nielzsen 26 Sep '22

26 Sep '22

Hi, I deleted the gmail address linked to my AUR account "Nielzsen" (which is roman.brasseur(a)gmail.com) Is there a way to recover it despite my mistake? Regards.

2 2

May be http://mirroir.wptheme.fr/archlinux/$repo/os/$arch is failing
by marnout 20 Sep '22

20 Sep '22

Hello every body, I had problems with the updates. For some weeks pacman told me everything is up to date, there is nothing to do. So, I commented the first mirror (http://mirroir.wptheme.fr/archlinux/$repo/os/$arch) and then I had 116 packages to update. Maybe this mirror is failing. For me the problem is solved. Friendly. N.B. Sorry if my English is not good, I do not speak English, but a little. -- Mourad Arnout 25 rue de la Vieille Pierre 79800 Exoudun http://arad.free.fr https://github.com/marnout

2 2

RFC / RFO: Extra (CI) files in AUR packages
by Knut Ahlers 16 Sep '22

16 Sep '22

Hey there, I'd like to fetch some comments / opinions regarding maintaining AUR packages with the help of automated build systems. I do maintain several packages in the AUR containing the typical files as `PKGBUILD`, `.SRCINFO`, files referenced in the `source()` section and a special script `update-version.sh`. This script is not mentioned in the PKGBUILD and not used during the build process. It contains the required steps to figure out the latest version of the package and to patch the PKGBUILD. This script is a) used to document how the package is updated and b) is used by my CI system (atm Jenkins) to check for updates and update the package. (Extra steps to verify the package is still building fine before doing any update are common to all packages and are executed after this package-specific script.) For most of my packages there were no complaints about this and users seem to be happy to get the updates usually delivered within an hour after release. Though in one package (librespeed-cli) I got two comments asking me to remove that script. Now I found no explicit statement in the package / AUR submission guidelines against this. Therefore I'd like to ask other maintainers / TUs for your opinions: Are you strictly against adding a script which documents / is used for the update? Is it fine to keep it there? Shall it be removed though doing no harm? Cheers Knut -- Knut Ahlers Software & Infrastructure Developer Web & Blog: https://ahlers.me/ GPG-Key: 0xD215AD7D (https://knut.in/gpg)

2 1

Re: [aur-general] Why was xenia-git orphaned immeditately?
by Sandy Carter 11 Sep '22

11 Sep '22

Glad to hear it wasn't intentional. I find it very strange indeed that the system accepted the request. I don't remember it being flagged OOD but that's on me. Would you mind orphaning xenia-git so I can pick it up again? It would require some rebasing of the patch branches. On Sun, Sep 11, 2022 at 7:36 PM Alessandro Marchioro < marciozgaming(a)gmail.com> wrote: > Hi, I had the same question, I was trying to get an update to the package > without orphaning but by clicking the link it was automatically orphaned by > the system in no time, instead of respecting the time as per the page > suggestion, is this because it was out of date for over a year? > > I wasn't trying to get access as a maintainer other than make it build > again with a simple patch of the PKGBUILD, due to the fact that I was > trying out the emulator with the latest builds on Arch and saw it on a bad > state. > > I too wanna be sure that you are the maintainer, it wasn't my intention in > being the one for this package. > > Hope you'll understand, > > Alessandro > Il 12 set 2022, 01:30 +0200, Sandy Carter <bwrsandman(a)gmail.com>, ha > scritto: > > Hello, > > I used to maintain xenia-git [1] and have since its creation. I am also > the author of the Linux threading, windowing, debug and other patches that > the package uses. > > At *19:20:00 UTC* today, an orphan request was submitted and immediately > orphaned by user ilbuonmarcio. The user made no attempt to contact me about > the issue either by email or in the comments. If they had, I would have > responded as I usually do to issues in my packages. > > I am active on AUR and have been for over 10 years now. I usually can fix > a package issue in a day to a week. > > According to the arch wiki: > > Orphan requests will be granted after two weeks if the current > maintainer did not react > > I was not given the time to react as it is now a few hours later. > > I would like to request this orphaning be undone and steps can be taken to > avoid this happening again. > > Thank you, > -- > Sandy > > [1] https://aur.archlinux.org/packages/xenia-git > >

1 0

[aur-general] Why was xenia-git orphaned immeditately?
by Sandy Carter 11 Sep '22

11 Sep '22

Hello, I used to maintain xenia-git [1] and have since its creation. I am also the author of the Linux threading, windowing, debug and other patches that the package uses. At *19:20:00 UTC* today, an orphan request was submitted and immediately orphaned by user ilbuonmarcio. The user made no attempt to contact me about the issue either by email or in the comments. If they had, I would have responded as I usually do to issues in my packages. I am active on AUR and have been for over 10 years now. I usually can fix a package issue in a day to a week. According to the arch wiki: > Orphan requests will be granted after two weeks if the current maintainer did not react I was not given the time to react as it is now a few hours later. I would like to request this orphaning be undone and steps can be taken to avoid this happening again. Thank you, -- Sandy [1] https://aur.archlinux.org/packages/xenia-git

1 0

[aur-general] Compiling with CMake
by Guilhem Saurel 08 Sep '22

08 Sep '22

Hi, In AUR, there are many packages with an old-school > mkdir build && cd build > cmake -DCMAKE_INSTALL_PREFIX=/usr .. > make Other packages say they require ninja and use > mkdir build && cd build > cmake -DCMAKE_INSTALL_PREFIX=/usr -G Ninja .. > ninja But I think we should let the end user choose if they want make or ninja, by letting them configure their CMAKE_GENERATOR environment variable¹ Currently if someone has CMAKE_GENERATOR=Ninja in their environment, many AUR packages in the first category will fail, because eg.: > […] > -- Configuring done > -- Generating done > -- Build files have been written to: /home/nim/.cache/paru/clone/octomap/src/octomap-1.9.8/octomap/build > make: *** No targets specified and no makefile found. Stop. And on the other hand for the second case, packages say they require ninja while they would work as well with make. Therefore I think we should ask CMake to compile, no matter which generator is available on the machine and/or was chosen by the user, with: > mkdir build && cd build > cmake -DCMAKE_INSTALL_PREFIX=/usr .. > cmake --build . Or even better > cmake -B build -S . -DCMAKE_INSTALL_PREFIX=/usr > cmake --build build Any opinions ? Should we put that on the wiki² ? Or write an RFC, like ³ ? Cheers ! Guilhem, aka. Nim65s ¹: https://cmake.org/cmake/help/latest/envvar/CMAKE_GENERATOR.html ²: https://wiki.archlinux.org/title/CMake_package_guidelines ³: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/10

2 2

[aur-general] TU Application - blakkheim
by T.J. Townsend 06 Sep '22

06 Sep '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello. I'd like to apply to become a trusted user. I started using Arch around 2009 when we still had the curses installer, rc.conf, hal... the good old days. I left at some point and came back as a full-time user about three years ago. You can find me on IRC under the name blakkheim, usually in #archlinux-security since that's my main area of interest. I'm the maintainer or co-maintainer for a few OpenBSD-derived packages in the AUR: openiked, rpki-client, and openbgpd. I've been involved with OpenBSD since 2014 and became a project committer there in early 2016. In the last two years I've submitted just over 150 patches to the Arch bug tracker: https://bugs.archlinux.org/index.php?opened=32638&status[]= Some community packages I'd like to co-maintain are openntpd, opensmtpd, libressl, sndio, mandoc, signify, dnscrypt-proxy, bmake, scrot, firejail, xcalib, mktorrent, parallel, ncmpcpp... And more (frankly, lots more) in the core/extra repos if that option opens up in the future. I keep up with many software projects via their mailing lists and RSS/atom feeds. If I'm accepted, one of my goals will be to get missing security fixes into Arch's repository shortly after their upstream release. The sponsors of my application are dvzrv, kpcyrd, and anthraxx. (yep, three) -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRUwf0nM2HqUUojd5Pylr3lA2jGzgUCYvuMwwAKCRDylr3lA2jG zvh9AQDOvEQbJdu3vfoPUY+Q+amtiwOatfD7nHje2XcviXF82gD/SL2aw0SNm9/Q sxcT+MltS0EoPTyR+OwOU9lHkpyuFQw= =4mzL -----END PGP SIGNATURE-----

9 16

[aur-general] My package is being flagged as out-of-date falsely by a specific user repeatedly
by Reza Jahanbakhshi 06 Sep '22

06 Sep '22

Hi, This user https://aur.archlinux.org/account/bittin is flagging https://aur.archlinux.org/packages/mesa-git as out-of-date repeatedly. I asked him not to do so in the package page comments section. I also tried to email him directly and explained to him that this is a git package and it's not necessary to update it with every version. But, the package is still being flagged. What should I do? Thanks,

2 1

[aur-general] Spam in AUR comments
by hawkeye116477＠gmail.com 31 Aug '22

31 Aug '22

Welcome, I'd like to report spam in AUR comments at aur.archlinux.org/packages/waterfox-classic-bin#comment-879702, written by user Shijrat62. (I haven't previously subscribed, so I'm sending again)

2 1

[aur-general] package splitting
by Thomas 29 Aug '22

29 Aug '22

Hi, I have 2 questions: 1) when is it allowed and / or good practice to split multiple packages by 1 PKGBUILD? For example I have created a package which pulls 3 debian packages and creates 3 Arch packages from it. I want to do that in 1 PKGBUILD by package splitting. Is that a good idea or should this avoided (if so why..)? 2) I found a bug in package splitting regarding the variable "pkgdesc" - when in AUR: it simply gets ignored when used in package_<pkgname> functions. Example: https://aur.archlinux.org/packages/systemd-libs-git -> Line 220: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=systemd-git#n220 It should work though according to: https://archlinux.org/pacman/PKGBUILD.5.html#_package_splitting It seems to work when in the regular package database - which is using the same PKGBUILD as the AUR ofc: https://archlinux.org/packages/core/x86_64/systemd-libs/ -> Is this the right place to report an issue like that? Thanks in advance Thomas

4 4

[aur-general] ungoogled-chromium-bin package submission
by networkException 27 Aug '22

27 Aug '22

Hello, I maintain / administer the ungoogled-chromium project and its Arch Linux packaging. Last year I asked[1] about the submission rules for an ungoogled-chromium-bin package as previous packages have all been removed. Since then our GitHub Actions workflow for releases has been adjusted to hopefully comply with the requirements[2]. At the moment updates will be handled manually by me but the code for automating this already exists. Now it has come to my attention that the ungoogled-chromium-bin package is blacklisted due contentious violations by people not affiliated with the project itself. Would it be possible to remove this blacklist entry to be able to submit our binaries? I imagine that providing an official package will also stop people submitting packages with workaround names. Kind regards, networkException 1: The previous conversation regarding this topic https://lists.archlinux.org/pipermail/aur-general/2021-September/036581.html 2: The commit updated our release workflow https://github.com/ungoogled-software/ungoogled-chromium-archlinux/commit/8…

2 1

[aur-general] Using the bug tracker to patch outdated packages (was: TU Application - blakkheim)
by Claudia Pellegrino 25 Aug '22

25 Aug '22

Hi Leonidas, > What stops you from opening bug report and submitting patches for those > now without being a TU? If these are in core/extras your options would > be the same as you have now, right? Wait, is this actually a thing? As a non-TU, one thing that has deterred me from using the bug tracker to submit patches for outdated packages is this warning: > Do NOT report bugs when a package is just outdated, or it is in the AUR. > Use the 'flag out of date' link on the package page, or the Mailing List. followed by: > REPEAT: Do NOT report bugs for outdated packages! and similarly, on the wiki: > Reasons for not being a bug > […] > A package which is not-up-to-date. Use the Flag Package Out-of-Date feature on Arch's packages website. That’s a total of three warnings. Enough for me to decide to not take chances. Your suggestion seems to contradict those warnings though. What am I missing? Regards Claudia (aka Auerhuhn)

3 2

Re: [aur-general] [PRQ#37061] Deletion Request for taskfile-gotask-git
by Martin Rys 22 Aug '22

22 Aug '22

(resending as I was not subscribed to aur-general before) > It tab-completes very great. And even earlier than in your version. Only if you remember it starts with a 'g', instead of the original 't'. If you're following official documentation and trying to use 'task' and wondering why it's red and not found, tab-complete will save you there. > Moreover, before making this package happen I was speaking with original > maintainer via email, and he declines binary renaming "because docs says > it's task". Moreover I agree with Egor - why should we change names to > make a mess in user's brains while reading documentation? Because the alternative is making the package conflict with `task`, so one cannot have both installed on the system. That is worse. The user is free to setup an alias to use 'task' as per the documentation if they do not also use community/task. > As I can see, you've just picked up this package and "fixed" it without > even trying to contact me and filed a deletion request for package that > fixes problem in more proper way (using org's name). The package did not download, was out of date, did not build, conflicted with [community], had missing completions (still does for fish/ps to be honest) and had a wrong license. The proper way to deal with those is not creating yet another AUR package, the proper way is to fix the existing one, which I have done, and then noticed you duplicated the package, hence I filed this deletion request. > Again, I'm asking to reconsider and withdraw/deny this request. https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… See second rule here, your package at this point is just naming the binary differently, which is just pointless duplication, let's rather reach consensus on what it should be named as. Maybe this entire issue should perhaps be raised upstream as 'task' is very generic. Taskwarrior started in 2008 and task in 2017. Though I doubt anything useful would come of it. Anyway the options are - A) go-task B) task-go C) keep task and conflict with community/task D) Something else Martin On Mon, Aug 22, 2022 at 3:02 PM Martin Rys <spleefer90(a)gmail.com> wrote: > > > It tab-completes very great. And even earlier than in your version. > > Only if you remember it starts with a 'g', instead of the original 't'. > If you're following official documentation and trying to use 'task' > and wondering why it's red and not found, tab-complete will save you > there. > > > Moreover, before making this package happen I was speaking with original > > maintainer via email, and he declines binary renaming "because docs says > > it's task". Moreover I agree with Egor - why should we change names to > > make a mess in user's brains while reading documentation? > > Because the alternative is making the package conflict with `task`, so > one cannot have both installed on the system. That is worse. > The user is free to setup an alias to use 'task' as per the > documentation if they do not also use community/task. > > > As I can see, you've just picked up this package and "fixed" it without > > even trying to contact me and filed a deletion request for package that > > fixes problem in more proper way (using org's name). > > The package did not download, was out of date, did not build, > conflicted with [community], had missing completions (still does for > fish/ps to be honest) and had a wrong license. > > The proper way to deal with those is not creating yet another AUR > package, the proper way is to fix the existing one, which I have done, > and then noticed you duplicated the package, hence I filed this > deletion request. > > > Again, I'm asking to reconsider and withdraw/deny this request. > > https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… > See second rule here, your package at this point is just naming the > binary differently, which is just pointless duplication, let's rather > reach consensus on what it should be named as. > > Maybe this entire issue should perhaps be raised upstream as 'task' is > very generic. Taskwarrior started in 2008 and task in 2017. Though I > doubt anything useful would come of it. > > Anyway the options are - > A) go-task > B) task-go > C) keep task and conflict with community/task > D) Something else > > Martin

2 2

Re: [aur-general] [PRQ#37061] Deletion Request for taskfile-gotask-git
by Stanislav N. aka pztrn 22 Aug '22

22 Aug '22

Hello, forwarding a discussion about package deletion to AUR general list, as our thread didn't reach aur-requests. 22.08.2022 00:23, Stanislav N. aka pztrn пишет: > 21.08.2022 23:56, Martin Rys пишет: >> I believe the request is still valid no matter which naming convention >> the executable will use. > > I disagree, as: > >> I renamed it from task to task-go because that makes the most sense >> for tab completion. > > ...will lead us to constant typos if using taskwarrior. > > Believe me, I already was on that side. When "task-go" was picked by me > as binary name, it was a pain to use it together with > zsh-autosuggestions as it suggests last taskwarrior command. "go-task" > is more than fine, it even do not cross with 99% of Go tools out there. > >> I do not have any strong attachment to task-go, but I believe go-task >> (which indeed is the name of the org on GitHub) is not good as the >> user has to remember it and it does not tab-complete. > > It tab-completes very great. And even earlier than in your version. > > Moreover, before making this package happen I was speaking with original > maintainer via email, and he declines binary renaming "because docs says > it's task". Moreover I agree with Egor - why should we change names to > make a mess in user's brains while reading documentation? > > As I can see, you've just picked up this package and "fixed" it without > even trying to contact me and filed a deletion request for package that > fixes problem in more proper way (using org's name). > > Again, I'm asking to reconsider and withdraw/deny this request. Hope that arch team will figure this out. -- With best regards, Stanislav Nikitin (also known as pztrn). Email: pztrn(a)pztrn.name Telegram: @pztrn

1 0

[aur-general] TU Application - serebit
by arch＠serebit.com 15 Aug '22

15 Aug '22

Hello all, My name is Campbell Jones, my online handle is serebit, and this is my application to become a Trusted User. I've been graciously sponsored by Jonas Witschel (diabonas) and Leonidas Spyropoulos (artafinde). I'm 22 years old, I live in Maryland (though I'm in Ireland for a couple more weeks), and I've been developing software to some degree for about a decade now. My hobbies involve software development, playing video games (some favorites being Titanfall 2 and ULTRAKILL), critiquing my friends' art and animation pieces, building computers, learning about space, and hugging my dogs. My favorite movies are Into the Spider-Verse and Interstellar. =============== HISTORY =============== Feel free to skip reading this if it gets boring! My exploits with programming started with programs on my TI-84 calculator to aid me in math class, and have culminated in closing in on a Bachelor's degree in Computer Science, which I'll have by the end of this year. I've also landed a post-grad position as a software engineer working on non-classified software used by the Navy and Coast Guard, which will primarily involve working with RHEL and aiding with improvements to build systems and version control. I'm the sole developer of Wraith Master, an open-source application to configure the RGB LEDs on the Wraith Prism CPU cooler, and one of the core developers of the Budgie desktop environment. My first experience with Unix was with my family's iMac, which I used to begin my programming journey with software like QB64, then Python, Processing, and Java. In early 2017, after building a computer of my own, I elected to dual boot Windows 10 and Ubuntu, so I could continue to use a Unix-like environment for the purposes of developing software. However, dissatisfaction with the Unity desktop led me to install Mint instead at the suggestion of others, followed by Solus. I ended up liking Solus enough to stick with it for the next four years and change. Soon after installing Solus, I began to investigate its processes for package submission and updating, and I decided to participate. I started with submitting packages for inclusion, then began to build packages myself, and eventually took up volunteer maintainership of packages. By the time I left Solus, I was maintaining the entire JVM stack, including handling the large-scale migration from JDK 8 to JDK 11 and patching software to facilitate that migration; in one excruciating case, I spent two full days patching modelio to build on JDK 11. I had also taken up maintainership of the Intel GPU compute stack, aka "neo", and several other miscellaneous packages like Kitty, libwacom, and shotcut. Occasionally, I would find reason to submit patches for packages to the upstream projects as well. In any case, I left Solus in January 2022, along with Joshua Strobl, one of the prior "core team" members. I would rather not air dirty laundry in a publicly available thread, so I won't go into details here, but it ultimately came down to a split between the "core team" members over serious issues with development and conduct that had been festering for some time. With the departure of Josh came the departure of Budgie, which became a standalone project backed by prior contributors, including myself. I had previously swapped out the system tray backend in Budgie for my own implementation of the XEMBED spec, which resolved numerous longstanding issues with the tray applet, and I wanted to continue moving Budgie forward now that it had been freed from the shackles of Solus. Upon leaving Solus, I decided to find a new distribution that could replace it on my personal machines. It had to satisfy the criteria of being rolling release, having up-to-date software in its repositories, having a fast package manager, and having Budgie as an option in its installer - so I elected to install EndeavourOS as a way of getting a somewhat curated experience on Arch. I had already been maintaining a couple AUR packages for Wraith Master for some time, so I had some experience with the PKGBUILD format already, and I decided to take up maintainership of Budgie's various AUR packages (mostly -git variants of existing packages) in order to update them to the new repository that had been set up under Buddies of Budgie. =============== END HISTORY =============== Ultimately, my motivation with applying to be a Trusted User is an extension of my prior motivation to aid with Solus packaging, and my motivation to maintain Budgie's AUR packages. Arch doesn't have a dedicated maintainer for Budgie's community packages, and I believe I would be an ideal candidate to fill that role. Though I haven't been on Arch for long, I have been maintaining packages for years, and I'm more than willing to learn and abide by the standards that Arch has set for its community and repositories. To address the minimum requirements: - I'm well acquainted with bash, sh, and csh (the latter not by choice...) - I maintain a few packages in the AUR with what I believe to be clean and quality PKGBUILDs - I've recently joined the Arch Matrix channel and plan to stay - I like to think my Google-Fu is well-trained! It had to be after the years I've spent being the dedicated technical support person for my family and friends... - I know exactly what packages I want to maintain as a start - the Budgie stack! As for the extra requirements: - I've reported some issues with Budgie packages on the bug tracker, so a little bit of involvement there - I have not submitted patches for Arch projects - I've been contributing to and maintaining open-source projects for years My first order of business after becoming a Trusted User would be to clean up the PKGBUILDs for the following Budgie packages: - budgie-desktop - budgie-desktop-view - budgie-screensaver Second order of business would be to move the AUR package "budgie-control-center" into the community repository, as it is a necessary component of the Budgie stack and has additionally reached the minimum requirements for inclusion. Finally, I would begin discussions of how the "budgie-extras" package could be modified or split, with cooperation from upstream if necessary. I'd also like to push for SPDX license ID support in the PKGBUILD format after having discussed it with Jonas. Thank you for reading this massive email, and I look forward to receiving your feedback! Best, Campbell Jones =============== LINKS =============== GitHub: https://github.com/serebit GitLab: https://gitlab.com/serebit AUR: https://aur.archlinux.org/account/serebit Bugs: https://bugs.archlinux.org/user/37021 Solus: https://dev.getsol.us/p/serebit Mastodon: https://fosstodon.org/@serebit Matrix: @serebit:matrix.org Homepage: https://serebit.com

4 11

[aur-general] Transifex aurweb
by Leonidas Spyropoulos 03 Aug '22

03 Aug '22

Hi Lucas, I'm trying to get some translation updates for aurweb and I believe this is managed from you. Can you please add me to the aurweb team so I can export them and update the repository .po files. Thanks you, -- Leonidas Spyropoulos PGP: 59E43E106B247368

1 0

[aur-general] Python packaging: weird behaviour
by j.r 25 Jul '22

25 Jul '22

Hello list, I'm currently trying to adapt my AUR packages to the new PEP 517 based build workflow [1]. Some users of the telegram-tg [2] package reported after I changed it to PEP 517, that they are missing the actual python files in the final package. I investigated a bit further and found out if I build with makechrootpkg (like I usually do) the files are inside the package (that's why I didn't notice), but if I use yay for example (which uses makepkg without a clean chroot), the package does not contain the files. Now I'm a bit confused and don't know how to debug this further, could somebody please help me or at least give me a hint? Thanks in advance j.r [1] https://wiki.archlinux.org/title/Python%20package%20guidelines#Standards_ba… [2] https://aur.archlinux.org/packages/telegram-tg

1 0

[aur-general] Brazillian's mirrors are not found
by Gabriel Dutra 18 Jul '22

18 Jul '22

Dear all, On the download package, the following mirrors are not found. - archlinux-br.com.br <https://archlinux-br.com.br/archlinux/iso/2022.07.01/> - archlinux-br.com.br <http://archlinux-br.com.br/archlinux/iso/2022.07.01/>

4 6

[aur-general] Python Package Update Review Request
by Sean Snell 30 Jun '22

30 Jun '22

Hello, I'm fairly new to the PEP 517 workflow for Python Packaging however python-dephell / setuptools have created a problem where deprecated components are being invoked which, after further research, I've learned are related to the streamdeck-ui package <https://aur.archlinux.org/packages/streamdeck-ui> I maintain (*that I didn't make, I adopted*) failing to build <https://pastebin.com/qNbJNH8y>. I believe I've figured out that updating to the PEP 517 workflow should allow the issues we're seeing to go away and allow building to work again for the foreseeable future because the updates would eliminate the need for the failing modules invoked for build() and if I've read this all correctly the standard update means the package would remaining usable for longer. If I could get a review of the attached PKGBUILD that would be great! Thanks, Sean Build errors from previous version: https://pastebin.com/qNbJNH8y PS - Can I get pointed in the right direction for info on setting up PGP keys? Thanks!

3 2

[aur-general] Incorrect email at account registration
by JafsZero 27 Jun '22

27 Jun '22

Hello, Recently I created my account for the AUR but when adding my email I wrote incorrectly the domain as .xom instead of .com and I can't get the verification link to continue with the account registration process. The username is JafsZero with Jafszero(a)gmail.com as the correct email. Not Jafszero(a)gmai.xom

2 1

[aur-general] Packaging Python projects without setup.py or PEP 517
by Attila Fidan 23 Jun '22

23 Jun '22

What's the recommended way to go about packaging a Python project that doesn't use PEP 517 or setuptools/distutils? Is there a method with pip, is just copying the files to $pkgdir fine, or should a PEP 517/setup.py be implemented through a patch?

1 0

[aur-general] Locked out of my account
by dan soucy 21 Jun '22

21 Jun '22

Hi all, I am hoping to regain access to my aur account. The email used was `danso(a)archlinux.info`, using the now dead email service once hosted by (forum user) tredaelli. Here is one contribution I made to gcalcli, back in the day: https://aur.archlinux.org/cgit/aur.git/commit/?h=gcalcli&id=b0d53542afe559c…

2 2