February 2024 - Arch-general - lists.archlinux.org

Trouble connecting with NetworkManager
by SET 03 Mar '24

03 Mar '24

Hi, Since yesterday's upgrade, it's not possible to establish IPV4 networking with networkmanager 1.46.0-1 and networkmanager-qt5 5.115.0-1 on ethernet and Wi- Fi. It happens with both static and dynamic address assignment. A usable IPV6 address is obtained with DHCP on Wi-Fi. An IPV6 address is assigned on ethernet, but it is not usable to be online. # LC_ALL=C LANG=C journalctl -u NetworkManager -r |less Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6577] policy: set 'ETH0' (eth0) as default for IPv4 routing and DNS Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6566] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6556] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6551] manager: NetworkManager state is now CONNECTING Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6546] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6531] device (eth0): Activation: starting connection 'ETH0' (ea1d83f9-2dd7-4769-bbe9-ecd6aa48ff3b) Activating and deactivating NetworkManager-wait-online and NetworkManager- dispatcher do not help. Reverting to networkmanager-1.44.2-3 and networkmanager-qt5-5.112.0-1 is a working temporary solution. Devices: - Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15); Kernel driver in use: r8169 - Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78); Kernel driver in use: iwlwifi I'm reporting in the hope of a fix on the next upgrade. Regards.

6 9

Bring ARM into the fold?
by Christer Solskogen 02 Mar '24

02 Mar '24

Is it time to bring Arch Linux ARM into the fold of Arch Linux? The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run. Their forum is broken and has been broken for quite some time as well. -- chs

3 2

libblockdev - Split all provided plugins into separate packages (motivation?)
by David C. Rankin 24 Feb '24

24 Feb '24

All, David, Just did the system upgrade with the split of libblockdev packages, all went fine, though it did suggest install of the LVM plugin. I'm curious as to the motivation for the change? Easier to maintain? Smaller packages? Less overhead? etc... The trend I've seen over the past several years is to subdivide packages, which as long as they continue to work is fine, but at some point it does begin making it harder for the user to keep track of what all subpackages are required for package-X -- unless they are intimately familiar with they package and their use needs. So why was libblockdev put on the chopping-block? -- David C. Rankin, J.D.,P.E.

4 3

No graphical interface
by pete 24 Feb '24

24 Feb '24

Hi Folks having problems here i have lost access to kde plasma on the main box i have installed a new drive and reinstalled i believe it is on my /home drive where thr issue lies is anyone else having issues . i know this is scant information but i have no mail access on the machine that is having the issue wish there was someone local to me Thanks folks Pete

6 11

broken man page
by james smith 17 Feb '24

17 Feb '24

grub-btrfs [1] has a broken man page [1] https://man.archlinux.org/listing/extra/grub-btrfs/

3 2

Suggestion: use static linking instead of dynamic linking just as how rust and golang do.
by Evan Greenup 13 Feb '24

13 Feb '24

Suggestion Build executable program written in Haskell statically. (For the convenient of package maintainer, remove Haskell library packages). Reason The advantage of dynamic linking is letting multiple executable sharing same part of code. The only benefit is to reduce storage consumption. But in nowadays, storage is getting cheaper and cheaper. It is no longer be a issue now. And Haskell packages are all relatively small. However, here are a lot of drawbacks for dynamic linking of Haskell ecosystem. - Firstly is dependency version conflict. If two package depend on a same package with exclusive permitted version range, it will be a big trouble. - One dependency version update requires Arch Linux package maintainer update a series of packages which depend on this package. (Unlike Python, Haskell is compiled language with low ABI compatibility across different version). - lack of link time optimization. - Long time of upgrading via pacman. Updating many small package is really much slower than updating one big package. And registering Haskell module take a long time. Why program written in C/C++ can be distributed in dynamical linking form? C/C++ has very poor dependency resolver and package manager. C/C++ project need developer take care of dependency manually. And C/C++ compiler provide relatively stable ABI. None of those condition applies to Haskell. Details of Action Only providing: - ghc exclusive to ghcup - ghcup provide ghc, stack, cabal-install. This is similar to rustup package. - haskell-language-server like other Haskell executables, statically linked. When user install ghcup via pacman , the need to manually set default toolchain to install ghc and other tools. All non-executable Haskell library become unnecessary. Since no Haskell developer will use haskell package provided by the Linux distro. Expected Benefit - package maintainer will save a lot of time on maintaining Haskell software. - update will be much quicker. - All Haskell program packages can easily up-to-date. I believe the gain of this suggestion is significantly greater than the loss. Evan

4 3

Re: Migration from LXD to Incus
by Bernd Rinn 13 Feb '24

13 Feb '24

Hello, The issue with using the lxd-to-incus migration program is that it requires the lxd server to run in order to work. If I install incus via pacman and then try to migrate, I get: # lxd-to-incus => Looking for source server ==> Detected: manual installation => Looking for target server Error: No target server could be found This message is expected, because the target server (lxd) was uninstalled by pacman during the installation of incus. In comparison, on a Debian box, 'apt-get install incus' installs Incus in parallel to lxd and the subsequent migration program works fine. Best, > Hello, > > I am yet to migrate to incus, however the lxd-to-incus tool is provided > by the incus package [1], and thus should still work as it seems to > migrate itself (lxd is just a frontend after all). > > Let incus replace lxd, run the tool, and it should work just fine. If > not, post the error and the log here so that you can be helped further. > > > What the proper way of migrating from LXD to Incus under Archlinux? > > Seen as incus is relatively new, there is no wiki article on it, and > thus, there is no "proper" way currently, but in general if the > solution provided by upstream works, why change it? > > It goes without saying but you might want to backup before you attempt > this. > > Take care,

4 6

Odd login issue
by pete 12 Feb '24

12 Feb '24

Hi all I strange one here i boot to a text prompt then login but When i enter my username hit enter it sites there not asking for password then the login prompt will return this time enter my username hit enter it then goes correctly to password and logs in perfectly Now i do not think this is related but one of the cats knocked a cup of tea into a keyboard scrapped it totally alarmingly fast a Logitec K270 wireless thing so went and purchased a replacement exactly the same make and model changed it over new usb receiver mouse keyboard . It is strange that i only nmoticed it after that Cheers Pete

1 0

warning: directory permissions differ on /usr/lib/mysql/plugin/auth_pam_tool_dir/
by David C. Rankin 11 Feb '24

11 Feb '24

All, When these crop up from time to time on update, do we just fix them and move on, or it is worth digging into further to find out when and why the permissions changed? E.g. warning: directory permissions differ on /usr/lib/mysql/plugin/auth_pam_tool_dir/ filesystem: 700 package: 755 God knows I haven't touched that package directory permissions, so something changed over the years. In the past, I have simply changed the permissions to match the package (as long as it meets a commons sense test) and been done with it. When these appear, does anybody want further info, or just fix and forget? -- David C. Rankin, J.D.,P.E.

2 2

Join the Arch Testing Team - Call for participation
by Robin Candau 10 Feb '24

10 Feb '24

Hi, We hope y'all had a good start in the new year of 2024 --- With the new year usually come new resolutions. If you don't have any so far, we have one for you: What if you decided to give Arch a bit of help with testing package updates this year? 😃 Arch uses testing repositories [1] as a buffer for core/critical package updates (or any other package updates that would benefit from being tested first) before entering the stable repositories. Testing these package updates helps us to catch more bugs upfront and ensures flawless updates for the stable repos, and that is where you can help! By joining the official Arch Linux Testing Team [2], you'll get the ability to "sign off" packages in testing after vouching for their correctness (or reporting a bug [3] otherwise). This helps Arch Package Maintainers catching eventual bugs upfront and helps to move packages out of the testing repositories faster and more efficiently. We are not necessarily looking for in depth testing. Verifying that a program launches correctly and that you're able to perform your usual routine with it is already a good test on its own. You can also check the general testing guidelines [4]. This is a very effective and rather easy way to contribute to Arch Linux. The more testers we have, the more reliable packages updates will be. We hope to see some of you there! 😉 [1]: https://wiki.archlinux.org/title/Official_repositories#Testing_repositories [2]: https://wiki.archlinux.org/title/Arch_Testing_Team [3]: https://wiki.archlinux.org/title/Bug_reporting_guidelines [4]: https://wiki.archlinux.org/title/Arch_Testing_Team#Guidelines -- Regards, Robin Candau / Antiz

1 0