- Aur-general - lists.archlinux.org

[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