- Arch-general - lists.archlinux.org

[arch-general] Wiki contributions summarily deleted
by David C. Rankin 13 Mar '21

13 Mar '21

Archdevs, This is getting ridiculous. Every wiki contribution is now summarily deleted, e.g. https://wiki.archlinux.org/index.php?title=Security&diff=next&oldid=654296 Editor's summary: Unsubstantiated claim and poor note. What? Toshiba has stored BIOS password outside of the BIOS for a decade. (not to mention anyone familiar with BIOS security should have encountered this years ago) And yet zero effort is made validate or invalidate the information without even the courtesy to ask to clarification. I have noted this before. Help with Arch's wiki has changed to the point it is literally a waste of time. In the past Arch was welcoming of help with the wiki, it benefits the community and us all, but that is apparently no longer the case. The guidelines are substantially the same as they have always been, but contributions are just deleted summarily. Why the change? -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] Default dtags in Arch
by Nicola Mori 11 Mar '21

11 Mar '21

I'm tracking down an inconsistent behavior of my application when compiled under different distributions. It seems that under Arch the -Wl,-rpath, linker flag will set an RPATH into the library, while under Ubuntu 20.04 and 18.04 the same flag results in a RUNPATH being set. So it seems to me that the linker have different defaults on the two distributions, maybe set at linker compilation time; is this reasonable/correct? Also, since RUNPATH seems to be the modern and more secure way (see e.g. here: https://wiki.archlinux.org/index.php/Arch_package_guidelines/Security#RPATH…) I am wondering if there is a specific reason why RPATH is still the default on Arch and if there are plans to move to RUNPATH. To further elaborate on this, if I'm correct the trend on Linux is towards RUNPATH, i.e. giving precedence to library folders specified by an environment variable (LD_LIBRARY_PATH) over those hard-coded in the binaries. Then on macOS it seems to be the opposite, namely deprecating DYLD_LIBRARY_PATH in favor of DYLD_FALLBACK_LIBRARY_PATH to give precedence to rpath. Both approaches are motivated by the potential security issues with the other approach, and all seems to depend on which security hole (a malicious environment variable or write access to library folders encoded in rpaths) is perceived as more important... Thanks in advance for any clarification, Nicola

1 0

[arch-general] Orphaned community package
by Simon Perry 11 Mar '21

11 Mar '21

Hi gang, I was wondering what the best avenue would be to request an update to a community package which no longer has a maintainer? The package in question is: https://archlinux.org/packages/community/x86_64/libsidplayfp/ Cheers. -- Simon Perry

2 1

[arch-general] Mirror not synchronized since January
by Henry-Joseph Audéoud 09 Mar '21

09 Mar '21

Hi all, Today, I discover two machines not having same version of one package. Both are up-to-date (just did a `pacman -Suy`). But they do not use the same mirror. Indeed: $ curl -s -I 'http://archlinux.de-labrusse.fr/core/os/x86_64/core.db' | grep -i Last-Modified: Last-Modified: Tue, 19 Jan 2021 22:22:50 GMT $ curl -s -I 'https://mirror.wormhole.eu/archlinux/core/os/x86_64/core.db' | grep -i Last-Modified: last-modified: Mon, 08 Mar 2021 21:58:07 GMT I understand there may be a little time gap between mirror synchronize themselves. But 19 January seems far from today. Is this expected? P.S.: I did not checked other mirrors. -- Henry-Joseph Audéoud

4 4

[arch-general] Resume from sleep doesn't work any more
by Andy Pieters 08 Mar '21

08 Mar '21

Hi all As per the subject, Arch goes nicely to sleep, but waking up goes wrong. I see the entries in the dmesg logs: [32990.466213] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.466250] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.466256] nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device DVI-I-1. [32990.466785] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.466791] nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-0. [32990.467214] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices [32990.467219] nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-1. [32990.467678] nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices Which are mentioned in the Arch Linux NVIDIA troubleshooting: https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#System_does_not… I have applied the fix: sudo strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort | tail -1 Windows 2015 cat /boot/loader/entries/arch.conf title Arch Linux linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=UUID=0d9c3207-a30f-4273-95fa-80e0cf5624ba rw nvidia-drm.modeset=1 resume=PARTUUID=82a0cf4c-5d39-7647-94e3-be1a46741847 acpi_osi=! \"acpi_osi=Windows 2015\" Which is how I boot: cat /proc/cmdline initrd=\intel-ucode.img initrd=\initramfs-linux.img root=UUID=0d9c3207-a30f-4273-95fa-80e0cf5624ba rw nvidia-drm.modeset=1 resume=PARTUUID=82a0cf4c-5d39-7647-94e3-be1a46741847 acpi_osi=! \"acpi_osi=Windows 2015\" I've tried any combination of with and without quotes But resuming from spend still doesn't work. I don't recall exactly when this started happening but things used to work for years... This system has got a built-in Intel GPU and I can switch between setting the intel as IGD in the cmos. but using this setting has no bearing...

1 0

[arch-general] pkgstats and detailed hardware information
by u34＠net9.ga 06 Mar '21

06 Mar '21

Am I right that pkgstats does not collect detailed information about the hardware used? Is it a good idea that it will asks permission for doing that? -- u34

1 0

Re: [arch-general] [arch-dev-public] RFC: Use x86_64-v2 architecture
by mpan 06 Mar '21

06 Mar '21

If a separate arch/repo is going to be set up, perhaps it would be wiser to go straight for v3? May yield even better results and eliminates the need to bump the version after a few years. Since people have a choice, there is no risk of leaving v1 and v2 users behind. If there is going to be a “hard bump” in requirements, giving no option to use older hardware, I would like to point out that there are a few issues. • Somewhere in the thread it was mentioned that we’re talking about CPUs older than 15 years. Mine (E5300) is Q4 2008 and it is v1, with the highest point in sales occurring even later: I bought it around 2010 and it was by no means considered “old” at the time. That means machines not older than 10 years are being eliminated. • I see surprisingly many people claim they do not support v2. It’s hardly reliable data, but it suggests that such a change is closer to kicking out 1/4 of the user base than “unimportant” 1%. • So far no hard data to support the change, in particular one that would outweigh the downsides. It’s undeniable that tuning for newer CPUs increases performance in *some* software. But not only users of such programs, if they care about speed, compile them themselves; but — more importantly — that type of software does not represent the typical user experience. To argue such a change makes sense, one has to either provide data showing improvement, that is both statistically significant and noticeable, or the gain would have to be so huge that no further testing is needed (e.g. 50% increase in speed). For a typical user, not some selected pieces of software or synthetic tests. So far the only arguments I hear are “because it’s newer” and, in this thread, that someone believes the battery life got extended (though by unknown factor and that only applies to laptops). Wasn’t the latest mkinitcpio move to zstd enough of a warning? • The change forces throwing away perfectly good hardware. Sure, abandoning 686 did the same, but then it was a question of maintaining a separate architecture, the arguments were very strong and in the end 686 users would be left behind anyway with or without Arch’s move to x86_64 only. In here we’re talking only about unquantified performance and battery life improvement. I believe that a separate arch/repo would be a better idea.

1 0

[arch-general] Why move LTS to 5.10 when VirtualBox guests Kernel Panic with 5.10?
by David C. Rankin 24 Feb '21

24 Feb '21

Archdevs, You move of both linux and linux-lts to the same kernel is bewildering. That eliminates all fallback capability lts provides. Currently, virtualbox Arch guests are broken on 5.10 (as with most other distros). See: https://www.virtualbox.org/ticket/20055 With linux on 5.10 and lts on 5.4 it was workable to have lts guests. Now you have linux and linux-lts as the same kernel. How does that make sense? -- David C. Rankin, J.D.,P.E.

11 18

[arch-general] PAM 1.3.1 -> 1.5.1 did pam_tally get removed?
by Anton Hvornum 24 Feb '21

24 Feb '21

Hi. This might be suited for the newbie corner, but I'm testing my luck with the mailing list for the first time. I can't remember if I've added the following to /etc/pam.d/system-login or not: auth required pam_tally2.so onerr=succeed file=/var/log/tallylog The reason why I'm asking is because after a system upgrade, that line has now disappeared. And I did not see anything on the archlinux bulletin board about a pam change. The tally logs still appear to update however, just not through the system-login config. Best wishes: Anton Hvornum

7 7

[arch-general] Relicencing Wiki Content under Creative Commons
by alpabrz＠protonmail.com 22 Feb '21

22 Feb '21

Greeting Archers, I would like to reuse and expand a Template from the ArchWiki for another Wiki. For that it would be ideal to relicence the content from GFDL 1.3 to CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike). This page [1] states that GDFL v1.3 was explicitly designed to make interoperation with Creative Commons possible, but only when the content was created before November 1, 2008. And you can not use this permission after August 1, 2009, which would mean my re-licencing would be illegal. Is this correct or am I missing something here? No-one probably cares but I figured I'd ask here nonetheless. Thanks and salutations, alpabrz [1]: https://www.gnu.org/licenses/fdl-1.3-faq.en.html

1 0