- Arch-general - lists.archlinux.org

[arch-general] definition of "orphan"
by Matthias Bodenbinder 16 Mar '21

16 Mar '21

Hi, in the arch world I see two different definition of an "orphan". The pacman manpage says: orphans - packages that were installed as dependencies but are no longer required by any installed package. For the AUR the definition of an "orphan" is If all maintainers of an AUR package disown it, it will become an "orphaned" package. (https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Maintaining_… ) This is confusing. Would it make sense to change the wording so that it is not ambiguous anymore. Matthias

15 25

[arch-general] Gajim doesn't start
by SET 16 Mar '21

16 Mar '21

Gajim fails to start with this backtrace, since upgrade 2 days ago, and there's no newer version available. * Traceback (most recent call last): * File "/bin/gajim", line 33, in <module> * sys.exit(load_entry_point('gajim==1.2.2', 'gui_scripts', 'gajim')()) * File "/usr/lib/python3.9/site-packages/gajim/gajim.py", line 154, in main * _init_gui('GTK') * File "/usr/lib/python3.9/site-packages/gajim/gajim.py", line 90, in _init_gui * _init_gtk() * File "/usr/lib/python3.9/site-packages/gajim/gajim.py", line 105, in _init_gtk * from gajim.gtk import exception * File "/usr/lib/python3.9/site-packages/gajim/gtk/exception.py", line 37, in <module> * from gajim.common import configpaths * File "/usr/lib/python3.9/site-packages/gajim/common/configpaths.py", line 233, in <module> * _paths = ConfigPaths() * File "/usr/lib/python3.9/site-packages/gajim/common/configpaths.py", line 124, in __init__ * import pkg_resources * File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3243, in <module> * def _initialize_master_working_set(): * File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3226, in _call_aside * f(*args, **kwargs) * File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3255, in _initialize_master_working_set * working_set = WorkingSet._build_master() * File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 568, in _build_master * ws.require(__requires__) * File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 886, in require * needed = self.resolve(parse_requirements(requirements)) * File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 772, in resolve * raise DistributionNotFound(req, requirers) Should it be reported to the package maintainer, or to bugs.archlinux, or to Gajim's developpers ? Or do I miss a package ? Regards.

2 2

[arch-general] With /etc/systemd/homed.conf change of default filesystem ext4 -> btrfs, Do we set ext4?
by David C. Rankin 15 Mar '21

15 Mar '21

Archdevs, With the change in /etc/systemd/homed.conf from: < #DefaultFileSystemType=ext4 --- > #DefaultFileSystemType=btrfs If we are running ext4, do we now need to set: DefaultFileSystemType=ext4 explicitly? -- David C. Rankin, J.D.,P.E.

2 1

Re: [arch-general] [arch-dev-public] Killing python2 v3...v4...v5
by Bartłomiej Piotrowski 15 Mar '21

15 Mar '21

On 15/03/2021 19.10, Morten Linderud via arch-dev-public wrote: > Yo! > > As people know python2 has been unsupported for a year and we current have ~170 > python2 packages in our repositories. Currently the removal has been fairly slow > and done a bit ad-hoc. There has been a todo list but the follow up to that has > not really been great and I think it's reasonable for us to try and fix the > remaining packages to the best of our abilities. > > Thus I'm proposing a game plan! > > 1) Todo list for removal of all python2 checkdepends in packages > 2) Remove free python2 packages > 3) Remove packages with python3 equivalents > 4) Remove unported and unsupported packages depending on python2 > > Clearly this is ambitious and there are going to be exceptions, but it would be > great to have most of this work done within the next couple of months. > > The exceptions are largely going to be anything still using python2 for their > build system dependencies. This is a fine compromise as this should leave us > with a minimal set of packages to take care of. > > Rest of the problematic packages can be found on a handy list with what fedora > is working on: https://fedora.portingdb.xyz/ > > If there are no objections I'll start preparing the needed todo lists and figure > out the uneeded python2 packages. Should probably update the long-standing > python2 removal todo as well. > > https://archlinux.org/todo/conversion-of-programs-that-use-python-2-to-pyth… > > > Cheers! > Shouldn't this proposal go through the recently established RFC process? Cheers, Bart

2 1

Re: [arch-general] RFC: Use x86_64-v2 architecture
by Mateusz Jończyk 14 Mar '21

14 Mar '21

Hello, I am going to benchmark the performance difference between the various x86 uarch levels. I will be using Phoronix Test Suite, which has some support for performing compiler and compile flag benchmarks. I am opposed to dropping support for older CPUs, but I will perform this test fairly. That's why I'm posting this advance notice before performing actual benchmarks. I am an Ubuntu user and I am concerned that Ubuntu may require x86_64-2 in the not so distant future. I will be performing this test on Ubuntu 20.04.2 with GCC 9.3.0 [1]. I am going to use selected tests from this Phoronix article [2], but I will exclude benchmarks that do return much performance difference when using the "-O1" and "-O3" compiler flags, as: - their build scripts may ignore the CFLAGS/CXXFLAGS variables, - they may use some assembly code or C asm intrinsics, - they may have separate SSE4/AVX code paths, - the compiler is unable to optimize the code much, due to its nature. These are the benchmarks that probably would benefit the most from compiling for different uarch levels, which should be taken into account when interpreting the results. My rough comparision between "-O1" and "-O3" are at [3]. So, I will use the following tests: pts/scimark2 (all tests) pts/john-the-ripper (all tests) pts/graphics-magick ("swirl", "resizing", "HWB Color space") pts/coremark pts/himeno pts/encode-flac pts/c-ray Greetings, Mateusz Jończyk [1] GCC 9.3 does not support -march=x86_64-v2 and so. I will use switches like -march=nehalem instead. [2] https://www.phoronix.com/scan.php?page=article&item=gcc-10900k-compiler [3] https://openbenchmarking.org/result/2103131-HA-DRAFTUARC92 ---------------------- Benchmark selection details: Page 2 from the Phoronix article: cryptopp - is compiling some code with the flag "-msse4.2", so skipping it. smhasher - same fftw - has some kernels that explicitly use AVX / AVX2, point in benchmarking it, scimark - OK, I will also run some other tests from this benchmark - where the difference between "-O1" and "-O3" is nice, Page 3: TSCP - no real difference between "-O1" and "-O3" performance data, John The Ripper - small difference between "-O1" and "-O3", but leave it now GraphichMagick - OK, I'll choose tests with the biggest difference between "-O1" and "-O3": "swirl", "resizing", "HWB Color space", Page 4: AOM AV1 - no performance difference between "-O1" and "-O3", so skipping, x265 - patent encumbered format, skipping, Coremark - OK, "CoreMark Size 666 - Iterations Per Second" Himeno - OK, Stockfish - enables SSSE3 and SSE4.1 by default, leave it, FLAC Audio Encoding - OK, but probably the difference won't be big, Minion - tries to install many package dependencies, just leave it now, LevelDB - benchmark suite ignores the "-O1" flag, highly susceptible to non-quiet systems (so the results were bogus), GROMACS - same as Minion, additionally has long runtime IIRC, Darmstadt Automotive Parallel Heterogeneous Suite (daphne) - requires huge amounts of disk space, seems it will be IO-bound pgbench - I have still spinning HDDs, the benchmark was IO-bound NGiNX - it looks like it is testing both kernel and userspace, so leave it out, Additional benchmarks: n-queens - no difference between "-O1" and "-O3", build scripts seem to ignore CFLAGS, OpenSSL - no real difference between "-O1" and "-O3" c-ray - OK, let's include it

2 2

[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