- Aur-general - lists.archlinux.org

Re: sm64ex-bin Discussion
by Corey Bruce 13 Sep '24

13 Sep '24

Also please leave the supermario64 package as I aim to get sm64ex-bin back will make changes to supermario64 to do the extraction Thanks Corey

1 0

sm64ex-bin Discussion
by corey bruce 13 Sep '24

13 Sep '24

Hi there Adam sm64ex-bin does not provide any of the rom files and only the binary, if a user wants to use this package they will have to provide the files themself as for the rom extraction the rom extraction and the binary is separate and the extracted rom files are extracted in a separate location and aren't included in the binary itself, the developers could have provided a binary but didn't which is why I compile them myself. I could provide a extraction method with the package if it also makes everyone happy as I wanted to provide a binary package as I also care about the user experience. Thanks Corey On 10/9/24 11:58 pm, Brian Allred wrote: > Sep 10, 2024, 04:46 by cdfrosty(a)gmail.com: > > Hello everyone, I hope you are all doing well > > I just wanted to talk about the discussion about my package > sm64ex-bin, I was informed to chat about it on the mailing list so > I wanted to make sure I was in the right place. I will admit the > initial issue frustrated me and felt a little targeted especially > when most of my other bin packages use binaries from my > repository but I wanted to discuss the issue and resolve any > allegations of slander that was put on with no factual evidence to > provide when I have been a long time package developer on the AUR > and a longer time developer on Github and Gitlab which I use now. > > It isn't against the rules to compile from source and host the > binaries on your own repository especially if the original > repository does not provide any or doesn't provide them for > specific architectures, I wanted to create a bin package for a > project for user to use and enjoy the project without needing to > wait for compiling times especially on Raspberry pi devices every > time while also bundling it with my launch scripts if needed,. For > example NZPortable-bin binaries are provided from my git > repository for the nzportable-bin package but I am officially > supported by the team to do so and it's a bit harsh to slander me > with assumptions that I am a bad actor with no evidence, it's also > pretty rule and a bit insulting to my credibility. > > All I ask is to have the ability to re upload my package and > continue to maintain the bin package for sm64ex-bin for all the > users who use it including myself, I am happy to talk about any > upstanding issues and fix any concerns if there is any. > > > Thank you > > > Corey Bruce > > Hey Corey, > > From a user perspective, my main concern would be that the source used > to compile the hosted binary file is available. If you're literally > only hosting a binary file, then I expect the source code used to > compile said file would be the original source - in this case from the > sm64ex repo. If you're including source modifications during the build > process, then I would expect the modified source to be available, and > ideally (though not a hard requirement), I'd prefer the binary file > hosted as a GitHub/GitLab release asset on the same repo. > > The other issue I could see is if a compiled form of sm64ex no longer > requires the user to provide the game ROM. If your sm64ex-bin package > can be installed and run without the user ever providing a ROM file, > then I can understand an AUR admin being hesitant to host that package. > > I'm not privy to any previous comments or allegations, so I can't > speak to those. And I'm not an AUR admin or Arch staff member. But > again, from a user perspective, as long as the source used to compile > the binary file is available, it doesn't really bother me where the > file is hosted or who's hosting it. I don't see a big difference > between you hosting the file and maintaining the AUR package versus an > original developer doing so. > > Hopefully this issue can be resolved amicably. > > Brian Allred

2 1

Is epoch increment optional on version scheme change in -git packages?
by dreieck 12 Sep '24

12 Sep '24

Dear AUR-maintainers, in this post [¹] I was told to raise this issue on this mailing list, so I do so. Note that I will not stay part of this mailing list; if there is an authorative answer maybe the best is to post it also to [¹] so everyone can notice. The issue is described in full in [²] and some short discussion followed. I also copypaste the issue here (from the Forum -- so forum-syntax): --- regarding [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223046… discussion[/url] about the AUR-package [url=https://aur.archlinux.org/packages/gr-lora_sdr-git]gr-lora_sdr-git[/url] I want to ask about the `$epoch` variable in `-git` packages in the AUR. The maintainer argues that `$epoch` [i]may[/i] be used, but not has to, when the versioning scheme changes so that a newer version of the `PKGBUILD` would result in a lower version according to `pacman`'s version compare logic. In this case, the old `$pkgver` (before adoption and fixing of the AUR package) was `8133965`, the new one now is `0.5.r4.g8133965`. [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223049… maintainer argues as following to not increment `$epoch`[/url]: [quote=xiota] AUR is still build on demand. AUR helper and Chaotic AUR users will receive notification and can force the update if they want. Users unwilling to manually force the upgrade can keep the old version. It's ultimately their choice. [/quote] [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223046… was reasoning that `$epoch` _must_ be incremented in such a case[/url]: [quote=dreirund] [quote=xiota] Also, I don't use epoch on AUR packages because they're build on demand. [/quote] But for the packages in the AUR you still need to set `$epoch`. Since the AUR is independently usable from `chaotic-aur`. The version scheme change you did in `gr-lora_sdr-git` requires an increment of `$epoch` in the AUR package, since the old version was `8133965`, the new one is `0.5.r4.g8133965`, which is lower by version compare logic. So setting `epoch=1` in the AUR package actually is required. [/quote] [url=https://wiki.archlinux.org/title/PKGBUILD#epoch]The wiki[/url] seems not to be clear about it, it may be read in both ways: [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223060… standpoint[/url]: [quote=dreirund] Regardless what opinions anyone has, the guidelines are clear about that: [url]https://wiki.archlinux.org/title/PKGBUILD#epoch[/url] [quote=https://wiki.archlinux.org/title/PKGBUILD#epoch] It is used when the version numbering scheme of a package changes (or is alphanumeric), breaking normal version comparison logic. [/quote] [/quote] and [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223066…] to that: [quote=xiota] From your own reference: [quote=quote=https://wiki.archlinux.org/title/PKGBUILD#epoch] Warning: epoch should only be used when [b]absolutely required[/b] to do so. [/quote] There is no statement requiring epoch to be used. Only requirements to meet when it is used. [/quote] So, is there any clear official rule for this case? --- [i]EDIT:[/i] After a discussion [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223046… there[/url], the maintainer has moved the discussion thread "[i]to a repository you don't have access to.[/i]". Regards! --- Regards!, @dreieck. [¹] https://bbs.archlinux.org/viewtopic.php?pid=2184346#p2184346 [²] https://bbs.archlinux.org/viewtopic.php?pid=2184286

6 6

sm64ex-bin Discussion
by corey bruce 10 Sep '24

10 Sep '24

Hello everyone, I hope you are all doing well I just wanted to talk about the discussion about my package sm64ex-bin, I was informed to chat about it on the mailing list so I wanted to make sure I was in the right place. I will admit the initial issue frustrated me and felt a little targeted especially when most of my other bin packages use binaries from my repository but I wanted to discuss the issue and resolve any allegations of slander that was put on with no factual evidence to provide when I have been a long time package developer on the AUR and a longer time developer on Github and Gitlab which I use now. It isn't against the rules to compile from source and host the binaries on your own repository especially if the original repository does not provide any or doesn't provide them for specific architectures, I wanted to create a bin package for a project for user to use and enjoy the project without needing to wait for compiling times especially on Raspberry pi devices every time while also bundling it with my launch scripts if needed,. For example NZPortable-bin binaries are provided from my git repository for the nzportable-bin package but I am officially supported by the team to do so and it's a bit harsh to slander me with assumptions that I am a bad actor with no evidence, it's also pretty rule and a bit insulting to my credibility. All I ask is to have the ability to re upload my package and continue to maintain the bin package for sm64ex-bin for all the users who use it including myself, I am happy to talk about any upstanding issues and fix any concerns if there is any. Thank you Corey Bruce

3 2

sm64ex-bin Discussion
by corey bruce 10 Sep '24

10 Sep '24

Hi there Brian there are no modifications to the source code or building process, all binaries are built exactly from the source code as documented on the official sm64ex repository and I never said anything about any source or build process being modified or change. The issue was with sm64ex-bin which is just a binary package and doesn't provide anything on it's own. Since the binaries are just directly compiled from the source code https://github.com/sm64pc/sm64ex as stated on the repository https://gitlab.com/linuxbombay/sm64ex and there is no issues I hope I can get permission to re upload my package without any issues. Thanks Corey

1 0

Re: [PRQ#63544] Orphan Request for visual-paradigm-community
by Rein Fernhout (Levitating) 04 Sep '24

04 Sep '24

This package of mine was requested to be orphaned and then the same user immediately approved their own request. I would've liked some time to react. The same user requested (and approved) my package genimage-git to be orphaned, which was wrongly flagged out of date (it is a VCS) package. On 2024-09-04 15:01, notify(a)aur.archlinux.org wrote: > epicycle6 [1] filed an orphan request for visual-paradigm-community > [2]: > > out-of-date > > [1] https://aur.archlinux.org/account/epicycle6/ > [2] https://aur.archlinux.org/pkgbase/visual-paradigm-community/

3 3

Is it allowed to use pkgrel for the upstream version?
by Ralf Mardorf 24 Aug '24

24 Aug '24

Hi, I wonder if it's allowed to use pkgrel for the upstream version? If so, then there is no correct information related to the pkgrel available, see https://aur.archlinux.org/packages/firedragon https://aur.archlinux.org/packages/firedragon-bin My comment, including a correction ;) at the bottom: https://aur.archlinux.org/packages/firedragon#comment-987718 "Hi, please, don't misuse the package release for the unusual versioning of upstream. If upstream's versioning is 1.2.3-1 then make the pkgver 1.2.3.1, if it's 1.2.3-1.1 then make the pkgver 1.2.3.1.1. For example take a look at how it is done for extra/linux-rt or extra/linux-rt-lts. Leave the pkgrel to the package release -1, -2, -3 and leave dotted pkgrel to the users, so a user can build an individual -1.1, -1.2 etc. and automatically follow the AUR, if the package maintainer bumps the pkgver or pkgrel. Don't break the pkgrel, just because upstream does use such an odd versioning. The pkgrel is for the package release, not for the upstream version. Regards, Ralf Correction: Replace the "-" by a "_", see https://wiki.archlinux.org/title/PKGBUILD#pkgver " After taking a look at the Wiki I corrected my comment. IIUC then the pkgver of extra/linux-rt or extra/linux-rt-lts isn't correct,too, but at least a correct pkgrel is provided by those packages from extra, while it's broken for the AUR's firedragons. Regards, Ralf

2 2

Registration with wrong email
by asalde_le1 18 Aug '24

18 Aug '24

]Hi! Today I wanted to register an account by email asalde.le1(a)gmail.com with username asalde_le1, but accidentally wrote it as gmail.xom, so I can't receive password link. Can you please reset the account? Thank you in advance!

2 1

Package Maintainer Application - Quentin Michaud
by mh4ckt3mh4ckt1c4s 15 Aug '24

15 Aug '24

Hi everyone, My name is Quentin, or mh4ckt3mh4ckt1c4s/mh4ckwascut on the AUR and other Arch projects, and I'm applying to become a Package Maintainer. My application is sponsored by Robin Candau (Antiz) and Rémi Gacogne (rgacogne). I'm a graduated CS/networking engineer who is pursuing his studies as a PhD student in cybersecurity at the Institut Polytechnique de Paris, France (for the curious an abstract of the topic of my PhD is available here: https://theses.fr/s374883) I started programming in high school, and as I was more and more interested in "how computers work", I naturally started to tinker with Linux. After a little distro hopping, I wanted to dive more into the inner workings of a Linux distribution and Arch was the distro of choice. I fell in love with the rolling release, the always up-to-date packages, the wiki, and the AUR, among others. I now run Arch not only on my main laptop, but on my experimentation machines as well. I tried to go further, explored Gentoo and LFS, but I sticked with Arch as the distro allowing me to best tailor my computers to my needs while being fast and simple (who doesn't hate compilation times?). With the time I familiarized myself with the AUR, adopted a package I was using that was orphaned, and started submitting my own packages. I ended using a lot of little-used packages from the AUR, such as pentesting tools (for Capture The Flags) and fancy stuff related to my PhD. Most of these packages were orphaned or had bugs, and I started the habit of regularly looking for abandoned packages that I was using and picking them up on the AUR. A few times, I stumbled on outdated packages in the extra repo (ruby-iostruct and LLVM are the ones I remember), and I thought that if my beloved Arch was sometimes not up-to-date, maybe I could help and make Arch a little better. That's why I'm sending this mail today! Alongside packaging, I helped on other topics around Arch, such as becoming a package tester or improving a few articles in the wiki. Alongside Arch, I'm involved in OSS in general, contributing to various projects I use. All can be found on my GitHub and GitLab profiles, but big projects I have contributed to are LLVM, GitLab and YunoHost. When I'm not coding something or maintaining my homelab, I'm running or reading to clear my head. As a Package Maintainer, I would like to bring from my AUR packages to the extra repo podman-desktop, which I feel makes sense as podman and various related tools are already in extra, and a few WebAssembly packages such as wasi-tools. I also plan to merge my zaproxy-desktop package with zaproxy that is already in extra. As for the packages I can co-maintain, I would be happy to help with LLVM-related packages, or any other package that would need help and where I would be useful, like containerization or security tools. Relevant links: My AUR packages: https://aur.archlinux.org/packages?K=mh4ckwascut&SeB=m My GitHubs (perso and work): https://github.com/mh4ckt3mh4ckt1c4s and https://github.com/mh4ck-Thales GitLab: https://gitlab.com/mh4ckt3mh4ckt1c4s/ My personal website: https://www.mh4ckt3mh4ckt1c4s.xyz/ The YunoHost application I created and maintained for over a year: https://github.com/YunoHost-Apps/searxng_ynh My GitLab contributions: https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=all&a… My LLVM contributions: https://github.com/llvm/llvm-project/issues?q=involves%3Amh4ck-Thales Hoping that gives you a good introduction of myself and my motivations. Thanks for reading, cheers! Quentin

9 18

Maintainer: m3thodic packages need updating - no e-mail to contact (hidden)
by David C. Rankin 11 Aug '24

11 Aug '24

Aur folk, I was trying to install createrepo_c that has sent me down dependency-hell of out-of-date packages. The last that I couldn't fix was libmodulemd maintained by m3thodic. The package was flagged out of date on 4/27/24. I don't know if the maintainer is just gone for a while, or if the packages are abandoned. The createrepo package depends on this and other AUR packages and is dead-in-the-water for now. How to handle this? -- David C. Rankin, J.D.,P.E.

2 2

AUR Maintenance Saturday 13 July 12:00 UTC
by Jelle van der Waa 13 Jul '24

13 Jul '24

Hi all, We are having some performance issues with the AUR's git repository which requires some maintenance. [1] This means that the AUR will be unavailable for some time starting 12:00 UTC till it is done (hopefully 2 hours, could be more). [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/599

2 1

Unable to push to or clone from existing aur package repo
by Chris Speck 13 Jul '24

13 Jul '24

Hello, My AUR username is "cspeck-aai" and I am the maintainer of the "slack-desktop-wayland" package: https://aur.archlinux.org/packages/slack-desktop-wayland I have ssh set up and created and maintain this package. Today I attempted to push a change to bump the package version and found that I am unable to push: --- ✔ ~/src/slack-desktop-wayland [master ↑·1|✔] 16:22 $ git push aur(a)aur.archlinux.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. --- Also weirdly, I cannot clone it: --- $ git clone ssh://aur@aur.archlinux.org/slack-desktop-wayland.git Cloning into 'slack-desktop-wayland'... aur(a)aur.archlinux.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. --- I have not changed anything on my end. I double and triple checked my SSH keys. I also double checked that I'm not on any VPN or tunnel. Further, I can still use the ssh query interface, and I am still able to log in and it still shows me as the owner of this package: --- ✔ 16:23 $ ssh aur(a)aur.archlinux.org help Commands: adopt <name> Adopt a package base. disown <name> Disown a package base. flag <name> <comment> Flag a package base out-of-date. git-receive-pack Internal command used with Git. git-upload-pack Internal command used with Git. help Show this help message and exit. list-repos List all your repositories. restore <name> Restore a deleted package base. set-comaintainers <name> [...] Set package base co-maintainers. set-keywords <name> [...] Change package base keywords. unflag <name> Remove out-of-date flag from a package base. unvote <name> Remove vote from a package base. vote <name> Vote for a package base. ✔ ~/src/slack-desktop-wayland [master ↑·1|✔] 16:49 $ ssh aur(a)aur.archlinux.org list-repos slack-desktop-wayland --- I know that my ssh keys and setup are working because it used to function with the AUR and I continue to use it every hour of the day at work. Any idea what is going wrong? Can you please help me fix this? Also, I am away for a few days at the start of next week - could you please prevent any "orphaned package" requests while my access issues are fixed? Regards, Chris

4 4

Offensive comments
by Arne Brücher 12 Jul '24

12 Jul '24

I just received dozens of offensive comments including death threats on my AUR-package standardnotes-bin. I asked for support in the Arch Linux Telegram group and the user Muflone deleted the comments and suspended the account. The account's name was fruitwater6 and was created today. I also have an email address of the account and screenshots of the comment. I would appreciate if there was the ability to report comments and block users as well as an explicit way of reporting such issues.

2 1

Houston, we have a problem
by Mark Wagie 12 Jul '24

12 Jul '24

Multiple accounts (at least two) just spammed the same nonsensical comment multiple times--at least 40, I lost track. Please remove the comments and ban the associated accounts. Package: https://aur.archlinux.org/pkgbase/standardnotes-bin/ Accounts: https://aur.archlinux.org/account/MechEngineering2/ https://aur.archlinux.org/account/fruitwater6/ Sent with [Proton Mail](https://proton.me/) secure email.

1 0

hostility in the comments
by james smith 10 Jul '24

10 Jul '24

A request for the pkgbuild to be updated[1] [2] quickly degenerated in insults [1]https://aur.archlinux.org/packages/sunshine?O=10#comment-981082 [2]https://aur.archlinux.org/packages/sunshine?O=10#comment-981374

5 4

Fixing extra/python-tensorflow, which is incompatible to python-numpy 2.0
by Claudia Pellegrino 07 Jul '24

07 Jul '24

Dear AUR folks, Last week, the python-numpy package was upgraded to v2.0. Since then, extra/python-tensorflow [1] has been raising a runtime error: ```sh $ sudo pacman -Syu python-tensorflow […] $ pacman -Q python-tensorflow python-numpy python-tensorflow 2.16.1-9 python-numpy 2.0.0-1 $ /usr/bin/python -c 'import tensorflow' […] File "/usr/lib/python3.12/site-packages/tensorflow/python/ops/numpy_ops/np_dtypes.py", line 30, in <module> complex_ = np.complex_ ^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/numpy/__init__.py", line 397, in __getattr__ raise AttributeError( AttributeError: `np.complex_` was removed in the NumPy 2.0 release. Use `np.complex128` instead.. Did you mean: 'complex64'? ``` For the full output, see: https://0x0.st/Xa9Q.log Given that upstream is still working on NumPy 2 support [2], the error message makes sense. Users can fix this incompatibility for themselves by either a) manually downgrading `python-numpy` to v1.x from their cache; or b) installing `python-numpy1` [3] from the AUR, which I uploaded today. Judging from the progress of the upstream issue [2], NumPy v2 support in tensorflow may not be exactly around the corner. Until then, users are going to have a hard time figuring out one of these workarounds on their own. I think all packages from core and extra are supposed to Just Work. So I wonder what might be a more user-friendly way to fix `extra/python-tensorflow` for everyone? Would it make sense to move `python-numpy1` from the AUR to `extra` to allow `python-tensorflow` to depend on `python-numpy1`? [1]: https://archlinux.org/packages/extra/x86_64/python-tensorflow/ [2]: https://github.com/tensorflow/tensorflow/issues/67291 [3]: https://aur.archlinux.org/packages/python-numpy1 Regards Claudia (aka Auerhuhn)

2 1

AUR registration invalid e-mail
by Jens Hülser 26 Jun '24

26 Jun '24

Hi everyone, I am currently trying to register to the AUR website. The welcome email is already here, so I suppose I did not use the wrong address when setting up the account. Unfortunately, the password reset page gives me an 'Invalid e-mail' when I try to set my password. I use a password manager, so I there should be no typos involved. Nevertheless, I tried the manual route, entering the email adress and a very simple password (just very temporarily, of course!) very carefully one character at a time, double checking everything. I also tried using my user name, did not work either. Now that I am reasonably sure that I made at least no obvious mistakes, I am kindly asking for assistance here. The email address I used is jens.huelser(a)gmail.com. Anyone willing to help out a bloody noob? BR Jens

2 1

1 week break bittin
by Luna Jernberg 20 Jun '24

20 Jun '24

Hey! i will be in Germany helping out at the openSUSE Conference 25th of June to 2th July and won't have time to update my AUR packages during that period, a couple of them have comaintainers however

1 0

User jiangyc reuploads
by Fabio Loli 18 Jun '24

18 Jun '24

Hi, user jiangyc continue to re-upload 1panel-stable-bin; a duplicate of 1panel-bin 1panel-bin is orphan while their pkgbuild use curl in pkgver() and build() to get version and download, they have been informed on the first upload to not do that, I get there may be a language barrier but didn't get a reply and behaviour continued Third deletion request will come soon Please take appropriate action

1 0

Please take actions against a problematic user
by Kimiblock Moe 17 Jun '24

17 Jun '24

Hi all, I'm Kimiblock, requesting AUR moderators to take action against packager 7Ji and 2 packages: wechat-universal-bwrap and wechat-beta-bwrap. Despite the fact that we already discussed[a][b]: wechat-universal-bwrap and wechat-beta-bwrap is now duplicated packages of the original wechat-uos-bwrap (which has been renamed to wechat-uos-qt to avoid confusion[c]), user 7Ji still filed a deletion request against wechat-uos-bwrap[d]. He filed the deletion request because "don't want unrelated comments in the history of -universal, neither its votes". Ironically, he admitted that wechat-beta-bwrap is based on wechat-uos-bwrap and another package wechat-uos-qt is based on -beta-bwrap. He then said he "would want no history from -uos-bwrap". This is a serious violation of AUR submission guidelines[e]: "*Check the AUR* if the package *already exists*. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention." and this is not the end of this user's problematic behaviour. In the merge request of wechat-beta-bwrap filed by me, he said: "Additionally, as of writing, `wechat-beta-bwrap` has 21 votes, and `wechat-uos-bwrap`has 11 votes, it is not right to merge from a highly voted one a lowly voted one". This can't be right: if someone can mislead AUR users and let them vote the duplicated package, then the original package should be merged into the duplicated one? I can't understand the rationale behind this. All in all, please take actions against this user and 2 duplicated packages: wechat-universal-bwrap and wechat-beta-bwrap. -- Sincerely, Kimiblock [a]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [b]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… [c]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… [d]: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… [e]: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss…

1 0

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

14 Jun '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 17

Package Maintainer application - Giovanni Harting
by Giovanni Harting 12 Jun '24

12 Jun '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

6 10

User tallero comments
by james smith 02 Jun '24

02 Jun '24

A request for the pkgbuild to be updated[1] [2] quickly degenerated in insults [1]https://aur.archlinux.org/packages/duckstation#comment-960352 [2]https://aur.archlinux.org/packages/duckstation#comment-960355 Please take appropriate action

3 2

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

27 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

6 7

My pkgbuilds
by matt quintanilla 26 May '24

26 May '24

before sending my packages(2 is the git version)[1][2] to the aur is there anything wrong/needs to be fixed? [1]https://mystb.in/022f92bd534784600a [2]https://mystb.in/5f8321d4575ef003fd My working hours may not be your working hours. Please do not feel obligated to reply outside of your normal work schedule Matt Quintanilla he/him https://www.mattquintanilla.xyz/

1 0