May 2024 - Aur-general - lists.archlinux.org

Package Maintainer application - Giovanni Harting
by Giovanni Harting 20 May '24

20 May '24

Hey everyone. I'm hereby applying as a package maintainer, which is kindly sponsored by David (dvzrv) and Jelle (jelly) and formally by Levente (anthraxx), for whom Jelle has taken over the sponsorship. ## Who I'm Giovanni, also known as anonfunc or idlegandalf. I've been using Arch Linux as my day-to-day driver since 2013 and Linux in general since probably 2008 (mostly server-side until 2011-12, last Windows I actually used was 7). As for notable contributions, you might have heard of ALHP, which I started in 2020. ALHP developed from the idea of utilising modern CPU extensions all the way back in Q4 2019 (after I had a quick Gentoo detour on one of my laptops). At the time, no x86_64 levels were defined, so the first rough outlines still considered building for specific gcc CPU-baselines, like Haswell for example (which seems crazy in hindsight). When the x86_64 levels were announced in 2020, I started developing a buildbot capable of doing the heavy lifting, at the time in Python. After ditching Python in 2021 (after I got annoyed of multi-process) and rewriting the buildbot in Go, the project launched in July 2021. At the time, ALHP only provided x86_64-v3, shortly after launch x86_64-v2 followed. In December 2023 the x86_64-v4 repo launched, after I got my hands on a machine capable of building v4. Not sure how many users it actually has, since I do not do any tracking, but as far as requests on the tier 0 mirror go (ALHP has 7 mirrors in total, one operated by myself), it seems to see some usage. The buildbot is completely FOSS, you can have a look down in the links section. Outside of my Arch Linux involvement I work as a DevOps engineer. I can also support Arch Linux there if needed. ## Goals & Packages I want to help with package maintenance and advance infrastructure topics with the overall goal of bringing x86_64-v3 and build automation to life, as well as helping with potential problems that may come with v3, since ALHP had plenty of those already. As for packages, I have a few that I think would benefit the general Arch Linux audience by being promoted to official packages, mostly QoL stuff: - batsignal - wljoywake - jellyfin-mpv-shim (+ deps) - prismlauncher - victoriametrics - asus-numpad - mmdbinspect I'm also open to co-maintainer roles if there are any packages in need. Candidates could include DevOps related packages like Grafana or packages from the Go ecosystem in general, since I use that language extensively. Besides the mentioned categories, I'm also interested to co-maintain: - home-assistant - jellyfin ## Links AUR packages: https://aur.archlinux.org/packages?SeB=m&K=anonfunc AUR source repo: https://somegit.dev/anonfunc/aur-packages ALHP: https://somegit.dev/ALHP/ALHP.GO ALHP Status: https://status.alhp.dev/ Feel free to criticise PKGBUILDs to your heart's content :) Improvement is a continuous thing, so keep them coming. Giovanni

3 2

Package Maintainer application - Bert Peters
by Bert Peters 20 May '24

20 May '24

Hi all, My name is Bert Peters, or bertptrs on IRC and various other places, and I'm applying to become a package maintainer for Arch Linux. My application is sponsored by Christian Heusel (gromit) and Jakub Klinkovský (lahwaacz). I started using Linux in 2011 as I started my degree in Computer Science with OpenSuse as that happened to be installed on the computers in the lab, but soon moved to Ubuntu and, after a few false starts in 2014, moved to Arch at the tail end of 2015 by spending most of 33C3 getting things to work just the way I like it and never looked at anything else. Ever since, I've been using it as my daily driver, though I'm also using other distros professionally, currently mainly Ubuntu. Professionally I work as a DevOps engineer, mostly writing yaml, bash, and Python, occasionally wrangling Nix and Ubuntu, and doing packaging for the latter two. I've also previously done RPM packaging for CentOS when I managed my university's data science lab servers. Privately I'm a big fan of Rust, which I moderate the unofficial channels (##rust, ##rust-offtopic) for on Libera, and I dabble in Ruby because once upon a time I made the decision to write my website in Jekyll. On that website, I try to write the kind tech blog articles that I like to read, explaining a varying collection of things I happened to find interesting at the time. As for existing Arch involvement, I have long been maintaining packages in the AUR, and have been a tester for the last few years. All AUR packages I currently maintain (and that have needed an upgrade somewhere in the last three years) I keep in a Git repository [1] which I manage with aurpublish. I very recently discovered pkgctl how useful pkctl can be, so I started implementing nvchecker recently to automate the maintenance further. My github profile is also a decent record I have of OSS work I did. In the time I spend away from keyboard, I do bouldering a lot and I have been teaching windsurfing for the past 15 years. If I were to be voted in as a Package Maintainer, I'd like to move the following packages to \[extra\]: - cargo-cache - jekyll (and deps) - python-plotly In addition, I looked over what current orphans I have installed and I feel confident I know enough about the following to adopt them, though I'm open to more suggestions. - java-commons-lang - libvdpau - lsb-release I'd also like to help out as a co-maintainer on packages I previously maintained in the AUR that have since been adopted into [extra]: - cargo-geiger - cargo-license - nix - nlohmann-json - spotifyd - rust (previously maintained rust-src which was merged into it) - various ruby packages and while I'm at it, I'd like to help out with the Ruby packaging in general, to bring it up to date with Ruby 3.2 and figure out a consistent way to handle Ruby's propensity for very tight version bounds. With that, I hope to have given you a good introduction of myself and my work, where I intend to start packaging, and that there's a good starting point for discussion. Thanks for reading! Bert. P.s. To get ahead of one question, no, the ptrs in my nickname are unrelated to pointers; I got this nickname before I knew what those were. It's just my name with vowels removed. [1]: https://github.com/bertptrs/aur

5 6

Lost my AUR password and e-mail
by LDA 18 May '24

18 May '24

Hi, I used to have an AUR account(lda), whose password was stored on a single laptop, which broke. This wouldn't be a problem if it weren't for the fact that the primary e-mail I used at the time(freetards.xyz) now no longer works(due to a lack of rDNS). I still however own the domain attached to it, and as such, *can* prove I own said account. So I want to ask if I could recover my password that way(since the reset page pointed there.) Thanks, LDA idiot

1 0

Kernel / utils-linux update breaks nvidia 390.xx driver dkms build - Any ideas what changed?
by David C. Rankin 09 May '24

09 May '24

AUR folks, This is a general question that may catch others off guard. Having patch for the 6.8 changes when the kernel was release and having no issues through 6.8.9-Arch1, I was very surprised to see build failures in the nvidia-utils 390.xx package after the today's update. For both Linux and Linux-LTS: ( 8/13) Install DKMS modules ==> dkms install --no-depmod nvidia/390.157 -k 6.6.30-2-lts Error! Bad return status for module build on kernel: 6.6.30-2-lts (x86_64) Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.6.30-2-lts' exited 10 ==> dkms install --no-depmod vboxhost/6.1.50_non_OSE -k 6.6.30-2-lts ==> dkms install --no-depmod nvidia/390.157 -k 6.8.9-arch1-2 Error! Bad return status for module build on kernel: 6.8.9-arch1-2 (x86_64) Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.8.9-arch1-2' exited 10 ==> dkms install --no-depmod vboxhost/6.1.50_non_OSE -k 6.8.9-arch1-2 ==> depmod 6.6.30-2-lts ==> depmod 6.8.9-arch1-2 The actual errors seem like regressions somewhere as similar bugs were fixed in the past 3-4 years for both Nvidia and Vbox. The errors are: In file included from /var/lib/dkms/nvidia/390.157/build/common/inc/conftest.h:5, from /var/lib/dkms/nvidia/390.157/build/common/inc/nv_stdarg.h:29, from /var/lib/dkms/nvidia/390.157/build/common/inc/os-interface.h:27, from /var/lib/dkms/nvidia/390.157/build/nvidia/nv-frontend.c:12: /var/lib/dkms/nvidia/390.157/build/conftest/functions.h:76:2: error: #error wait_on_bit_lock() conftest failed! 76 | #error wait_on_bit_lock() conftest failed! ... /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_ioremap_nocache’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Wimplicit-function-declaration] 568 | void *ptr = ioremap_nocache(phys, size); | ^~~~~~~~~~~~~~~ /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: initialization of ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_ioremap_nocache’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Wimplicit-function-declaration] 568 | void *ptr = ioremap_nocache(phys, size); | ^~~~~~~~~~~~~~~ | ioremap_cache /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_is_dma_direct’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:1297:9: error: implicit declaration of function ‘dma_is_direct’; did you mean ‘d_is_dir’? [-Wimplicit-function-declaration] 1297 | if (dma_is_direct(get_dma_ops(dev))) | ^~~~~~~~~~~~~ | d_is_dir All of these seem similar to earlier errors from the Linux 5.6 days. Anybody have a guess in what changed in either the new gcc or new util-linux or others that has cause all this fun? -- David C. Rankin, J.D.,P.E.

2 2

Removal of NicoHood as Package Maintainer due to inactivity
by gromit 05 May '24

05 May '24

Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer"[0] for NicoHood based on prolonged inactivity. NicoHood has not executed any packaging or AUR maintenance duties since 6 Months now, but the mentioned activity is IMO rather an outlier. When I contacted all people who were inactive in votings for a longer period of time[1] (August '23) we heard back[2] from Nico stating that he would still like to help out with Arch but does not have time/capacity due to personal circumstance right now. Since back then then not much seems to have changed: - His last voting[3] was vote nr. 140 (ended 2022-09-11), since then 11 other votings were done. - His packaging activity was limited to 3 days in the last year[4] - He did not do any AUR Moderation for that timeframe (to my knowledge) Therefore I'm requesting him to be removed as a Package Maintainer. This is not done because I want to cause any harm but rather since I think it reflects the status quo. If at some later point he has the time / resources to help out again I'm very much in favour of welcoming him back. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, chris [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an… [1]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/threa… [2]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/messa… [3]: https://aur.archlinux.org/package-maintainer [4]: https://gitlab.archlinux.org/nicohood

1 2

About the intentionally duplicated package wechat-beta-bwrap and wechat-universal and unmaintained orginal package wechat-uos
by Kimiblock Moe 05 May '24

05 May '24

Hello people, I'm Kimiblock, the maintainer of wechat-uos-bwrap, writing to request Package Maintainer's action to solve the intentionally duplicated package on AUR. WeChat is a closed-source software developed by Tencent which is used by almost all people in China. In March 5, people in #archlinux-cn discovered that there is a testing version available and shortly after, it became a installable package for China's UOS. I've packaged wechat-uos-bwrap in 2024-03-05 23:37 (CST). 2 days after in 2024-03-07 09:18 (CST), AUR account leaeasy submitted wechat-beta-bwrap. If you look at the initial commit <https://aur.archlinux.org/cgit/aur.git/commit/?h=wechat-beta-bwrap&id=76c45…> of wechat-beta-bwrap, it was almost completely copied from wechat-uos-bwrap (other than a different way to extract the .deb), even the .desktop file. The only major thing they changed is wechat.sh, which sanbox function is removed. But wechat-uos-bwrap can read a environment variable "trashAppUnsafe=1" and disable its sandbox function. So I filed a merge request (#PRQ57379) to merge wechat-beta-bwrap <https://aur.archlinux.org/pkgbase/wechat-beta-bwrap/> into wechat-uos-bwrap <https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/>. After that, one of the wechat-beta-bwrap <https://aur.archlinux.org/pkgbase/wechat-beta-bwrap/> maintainer 7Ji <https://aur.archlinux.org/account/7Ji> submitted a new package called wechat-universal-bwrap <https://aur.archlinux.org/pkgbase/wechat-universal-bwrap>, which is also a duplicate package of wechat-uos-bwrap. So, I'm thinking to merge all that duplicate packages and my wechat-uos-bwrap <https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/> into wechat-uos. Sadly, the original Maintainer DuckSoft disappeared (the last message he sent in #archlinux-cn is over 3 years ago). Therefore, I'm requesting Package Maintainers to merge wechat-beta-bwrap <https://aur.archlinux.org/pkgbase/wechat-beta-bwrap/> and wechat-universal-bwrap <https://aur.archlinux.org/pkgbase/wechat-universal-bwrap> and give Maintainer role to previous wechat-uos maintainer, sukanka <https://aur.archlinux.org/account/sukanka> so that this package can be updated. I'll merge wechat-uos-bwrap <https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/> into wechat-uos once sukanka finish updating this package and add the sandbox function. I've contacted sukanka via Matrix and he/she is willing to maintain this package. -- Sincerely, Kimiblock

7 16

Re: About the intentionally duplicated package wechat-beta-bwrap and wechat-universal and unmaintained orginal package wechat-uos
by Kimiblock Moe 01 May '24

01 May '24

Hi Aᴀʀᴏɴ, The duplicated package has 55 votes, while the original version wechat-uos-qt has 19. I’m not losing patience though, just a little curious about why this thread appeared inactive. I guess PMs have been flooded with requests recently… -- Sincerely, Kimiblock

4 4