- 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

libblockdev split plugins
by Abraham S.A.H. 02 Mar '24

02 Mar '24

Hello everyone, Probably a little late, but I noticed that `plugins of libblockdev` package has been split out to a few individual, smaller packages, as optional dependencies. Probably, most of the users already noticed that. However, when I did check, I found that all split plugin packages — `libblockdev-*` — take significant size compared to `libblockdev` package itself. `libblockdev` is less than 220 KiB. So splitting it really reduces the size of the package and helps dependency resolution, specially for `udisks2`. Nevertheless, `udisks2` already depends on 8 of those 14 split packages… And many users may need some of them explicitly as well.So at the end of the day, most of them are installed anyway! Interestingly, as far as I know, `libblockdev` is not required by any other package than `udisks2`!! So the benefit of splitting it will not go for any other package. My question is, was such dividing really beneficial? Considering that, it probably brings more work to the maintainer and doesn't do any significant change to the ending of the story? -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

3 4

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