January 2022 - Arch-general - lists.archlinux.org

[arch-general] minor, DeveloperWiki, I have no permissions. A fix, 3 broken links.
by u34＠net9.ga 18 Jan '22

18 Jan '22

Referring to https://wiki.archlinux.org/title/DeveloperWiki:Package_signing#Source_packa… : I seem to have no permission to edit. A fix for 3 broken URLs is: 1. http://ftp.de.debian.org/debian/pool/main/a/acpid/acpid_2.0.4.orig.tar.gz -> https://snapshot.debian.org/archive/debian/20100422T161418Z/pool/main/a/acp… 2. http://ftp.de.debian.org/debian/pool/main/a/acpid/acpid_2.0.4-1.diff.gz -> https://snapshot.debian.org/archive/debian/20100422T161418Z/pool/main/a/acp… 3. http://ftp.de.debian.org/debian/pool/main/a/acpid/acpid_2.0.4-1.dsc -> https://snapshot.debian.org/archive/debian/20100422T161418Z/pool/main/a/acp… Please apply. As an aside, according to https://www.debian.org/News/2010/20100412, http://snapshot.debian.org/ , contain almost all packages from the main and security archives since March 2005 and more. -- jadon

1 0

[arch-general] User-Submitted Package Updates (how it could possibly work)
by Philip Evens 18 Jan '22

18 Jan '22

Interesting discussion: https://old.reddit.com/r/archlinux/comments/s5id1m/usersubmitted_package_up… https://archive.is/9wwNm Quoting: -------- A lot of packages are flagged out of date, some even for security issues. Some have no maintainer. Many have inactive maintainers and have been left to rot. Active developer resources are limited. I'd like to describe how the situation could be improved with the help of the community in a way that may not have been brought up before. Arch packages are built from very easy-to-read PKGBUILD files, similar to Makefiles. In short, users would be able to submit diffs to PKGBUILDs in the repo for updates, but not actually upload binary packages, similar to how the AUR works (and for the same reason): A diff to the PKGBUILD can be audited for errors or malice in a matter of seconds, while a (currently unreproduced) user-submitted binary shouldn't be trusted at all. The only difference in this scenario is that a trusted committer (who may or may not be the package maintainer) would have to look at the diff and commit the update to the repo, rather than users committing them. On to the first issue: that text I put in bold. Several Arch devs have mentioned (in public and private) that the culture of not "stepping on anyone's toes" prevents them from updating packages that are maintained by someone else. Conversely, there was a talk at the last Arch Conf where Lavente said he wanted more packages to be co-maintained by multiple people in case one wasn't available to actually maintain it. I don't have a technical solution to this people problem -- devs would simply have to live with the fact that users need fixes and sometimes another dev will update your package for you. Don't take it personally. The other issue: Arch has a legacy separation of core, extra, and community repos. Only "developers" can commit to core and extra, while "trusted users" are restricted to the community repo. I'm 100% sure everyone reading this has all three repos enabled, thus destroying any notion of community being "less trusted" than the other two. Having the core repo require an extra sign-off and some testing is a good idea, but otherwise I think this artificial separation should be done away with. One problem with the current situation is that "trusted users" may be available and willing to help, but can't actually update anything in the core or extra repos. Onboarding more of them doesn't help either because it takes months or years for them to be promoted to "developers," if it happens at all. So back on topic: How would users actually submit the updates to the PKGBUILDs? Eventually, when the Arch gitlab allows registration, they could be very simply sent as pull requests. Right now they would have to be sent through the existing bug tracker (the same one that specifically disallows what I'm suggesting). After being reviewed and committed, a package could be built by the developer who chose to take it... or there could be bigger infrastructure changes to save them time and effort in the long run. Here I'm talking about a large number of project devs committing the PKGBUILD changes, but only one build server (or farm) doing the compilation and (optionally through another special server) signing of the results. This is basically how it works in BSD for their package repos. The server(s) could automatically build any committed update every hour, or devs could issue a "queue this package" type of command on it, or some other way. That kind of setup would have the side benefit of only requiring users to trust one signing key, rather than a keyring of dozens of people around the world with varying degrees of personal security, and trusting the binaries sometimes just built on their daily laptops. It would also allow the package database to be signed more easily, which has been a big problem for a long time. (This is probably better for a separate discussion.) tl;dr: Users submit PKGBUILD diffs, anyone with commit access builds and pushes them. What do you think?

4 3

[arch-general] Patch for qt5-wayland to fix extreme lag on wayland
by Severus 16 Jan '22

16 Jan '22

Hi folks, I use wayland on plasma and it's extremely laggy. I googled and see this patch https://codereview.qt-project.org/c/qt/qtwayland/+/373473. I rebuild qt5-wayland and it worked very well. But the patch leads to race condition. I wonder that maintainer of qt5-wayland should include to PKGBUILD or not. Best regards, Severus -- Dẫu thế gian có tồn tại hàng vạn điều kì lạ vô thường, tôi vẫn muốn em biết rằng em là người con gái đặc biệt nhất tôi từng thương...

4 3

[arch-general] Why is README stripped from gawk package?
by David C. Rankin 09 Jan '22

09 Jan '22

All, Just a question of why the README is stripped from the gawk package. It seems that should be placed in /usr/share/doc/gawk, but that directory doesn't even exist. It holds the developer information and instead of having that information as part of the package, I ended up stumbling around gnu.org to find it (which sent me to the savannah.git... source for it) Seems like a basic README should be in ../doc/pkgname for all packages. -- David C. Rankin, J.D.,P.E.

6 6

[arch-general] Are the packages provided by mesa-dri1 still relevant ?
by Vladimir LAVALLADE 07 Jan '22

07 Jan '22

These packages depend on a kernel feature which has not been enabled in the default config since 4.19.arch1-1 (CONFIG_DRM_LEGACY) and the support for DRI1 was removed from mesa in 21.0.0. Am I missing something ? Regards,

1 0

[arch-general] Is the following a minor bug of systemd, mkinitcpio or zstd?
by u34＠net9.ga 06 Jan '22

06 Jan '22

When running mkinitcpio lately, I get: -> Running build hook: [fsck] Decompress: 1/35 files. Current: ...el/cdrom.ko.zst : 0 B... ==> Generating module dependencies I think the Decomress message is new. It didn't appear before 30-dec-2021, or so. It is aligned with the start of the line, which is not the way most of the mkinitcpio output is indented. It is probably the output of line 876 of /usr/lib/initcpio/functions: (( ${#zst_comp[*]} )) && zstd -d --rm -q "${zst_comp[@]}" Note the -q, --quiet, could be the source of confusion, since it does not override the Decompress line. Perhaps this is a zstd issue, or that the line should have had a -q specified twice. Is it a bug? Who should address it? -- u34

2 1

[arch-general] ffado-mixer error after latest "pacman -Syu"
by Susanne Schneider 02 Jan '22

02 Jan '22

hi, when trying to start ffado-mixer I receive the following message: > ... $ ffado-mixer Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line 460, in updatePanels self.addPanel(idx) File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line 339, in addPanel mixerwidget.initValues() File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", line 102, in initValues self.selectCorrectMode() File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", line 61, in selectCorrectMode self.large.initValues() File "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line 137, in initValues self.updateValues() File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", line 347, in updateValues SaffireMixerBase.updateValues(self) File "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line 105, in updateValues ctrl.setValue(vol) TypeError: setValue(self, int): argument 1 has unexpected type 'dbus.Double' Abgebrochen (Speicherabzug geschrieben) .... $ < any hit will be appreciated, either, if I can do something on my own or where to direct a bug report etc... thanks for reading, -suse (Thinkpad T520, Focusrite Saffire Pro10)

3 2

Re: [arch-general] ffado-mixer error after latest "pacman -Syu" (Zero)
by Susanne Schneider 02 Jan '22

02 Jan '22

> On 12/31/21 13:26, Susanne Schneider via arch-general wrote: >> hi, >> when trying to start ffado-mixer I receive the following message: >> >> ?? ...?? $ ffado-mixer >> Traceback (most recent call last): >> ? File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line >> 460, in updatePanels >> ??? self.addPanel(idx) >> ? File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line >> 339, in addPanel >> ??? mixerwidget.initValues() >> ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", >> line 102, in initValues >> ??? self.selectCorrectMode() >> ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", >> line 61, in selectCorrectMode >> ??? self.large.initValues() >> ? File >> "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line >> 137, in initValues >> ??? self.updateValues() >> ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", >> line 347, in updateValues >> ??? SaffireMixerBase.updateValues(self) >> ? File >> "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line >> 105, in updateValues >> ??? ctrl.setValue(vol) >> TypeError: setValue(self, int): argument 1 has unexpected type >> 'dbus.Double' >> Abgebrochen (Speicherabzug geschrieben) >> ....? $ >> < >> >> any hit will be appreciated, either, if I can do something on my own >> or where to direct a bug report etc... >> >> thanks for reading, > > You could try to change that line 105 > > File "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", > line 105, in updateValues > ??? ctrl.setValue(vol) > > into ctrl.setValue(int(vol)) > > Maybe open a bug report at Arch libffado and/or ffado.org > > ~Z > thanks a lot, that did the trick, regarding a proper bugreporting I hesitate because to my feeling the break was introduced by python 3.10, but I'm not sure... best -s

1 0