- Arch-general - lists.archlinux.org

Re: Upgrade failure
by Abraham S.A.H. 04 Mar '24

04 Mar '24

> These should be an option at old.reddit.com/prefs <http://old.reddit.com/prefs> to not use new Reddit, and thus always get the old version at www. Should minimize the headaches you get with old and dusty Reddit links. Thanks, @Aaron -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

1 0

Upgrade failure
by arch＠howorth.org.uk 04 Mar '24

04 Mar '24

On Mon, 4 Mar 2024 14:07:47 +0100 (CET) "Abraham S.A.H." <arash.sah(a)tuta.io> wrote: > > https://www.reddit.com/r/archlinux/comments/1b67kih/libblockdevutils_and_up… > > Can't open. First answer: pacman -S libblockdev-utils; pacman -Syu Possibly a packaging mistake. Another reply: I had the same issue yesterday. I reran the update this morning and it worked. It was either that my mirror was not up to date or a packaging issue. If you’re not in a hurry to update give it a few hours and your mirror should update. And a third reply: I had the same problem as well, what i did was uninstall libblockdev-utils using pacman -Rdd and then i just installed the new version.

1 0

boot parameter to stop hdmi
by Jude DaShiell 04 Mar '24

04 Mar '24

Is nohdmi valid to disable hdmi on an installer boot? A contact may need this but I'm not sure since I'm not familiar with his hardware. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

1 0

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

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

25 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