- Arch-general - lists.archlinux.org

Incus exprience
by Abraham S.A.H. 05 Mar '24

05 Mar '24

Hello everyone, I was using LXC — unprivileged — containers for my only two containers. I don't know how much but about a year, perhaps. Meanwhile, reading announcements of Incus following their GitHub release notifications. I was just interested. With v0.5 release, I jumped in, gave it a try and yeah!! it was simpler than LXC itself. Exactly opposite to my guessing. So far, everything was going well. Two little problems that I reported, one has to be documented in archwiki and the other will be fixed in 0.7. Since I dodged LXD directly from LXC to Incus. I want to know what's the difference between their _interfaces_. Am I missing anything from LXD in Incus? -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

2 4

Future of libdepends and libprovides
by Marius Kittler 05 Mar '24

05 Mar '24

Hi, I've just seen the mail https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux… on the "staff only" list. Since this probably affects AUR packages and other places where the whole community is involved such as the Wiki and unofficial repos I think it should be discussed here as well. Am Montag, 4. März 2024, 14:43:54 CET schrieb Balló György: > In short term, we should revert this commit [3] at distribution level > to avoid breakages. That would be much appreciated, also from my point of view as AUR package maintainer and maintainer of an unofficial repository. (If official packages need to be updated then I assume the same also applies to AUR packages. This will probably take even longer as every maintainer will have to take care of their packages individually.) > In long term, we have to decide via RFC what to do with libdepends and > libprovides. We could probably make a slow, manual transition to the > new 'autodeps' feature in pacman, but it still does not support > optional autodeps, [4] which means that would be impossible to mark any > binary deps as optional. That's of course problematic for plugins or binaries only required for optional features. I think we need a solution for that before enabling this new 'autodeps' feature globally by default. I also hope that the 'autodeps' feature will not run into problems with special libraries, e.g. ones that are only intended for cross-compilation purposes like https://aur.archlinux.org/packages/android-x86-64-zlib. It would be very annoying if one had to exclude those libraries manually. Having to add `options=('!autodeps')` would probably be ok although it means updating tons of AUR packages maintained by different people and of course also updating the relevant Wiki pages. Speaking of the Wiki: It still mentions library dependencies, e.g. in the last paragraph of https://wiki.archlinux.org/title/PKGBUILD#depends. This section should be updated and the alternative be documented instead if you decide to actually remove the support. It would also make sense to announce that change on https://archlinux.org so people actually know that they should stop using libdepends/libprovides. Note that I think moving forward with 'autodeps' is generally useful. For maintaining my own repository I even introduced a feature in my build service to keep track of all the dependencies on soname-level so I know when I'll have to rebuild packages. So this is the right approach - we just need to be careful no break existing packages/workflows without a transition period and clear announcements. Best Reagards Marius

2 3

removal of yuzu from the official repos
by james smith 05 Mar '24

05 Mar '24

as most of you have heard the yuzu has been shutdown by nintendo[1] and the github page removed[2] therefore the package needs to be considered for removal from the official repos as there will be no more updates and the package links to the github will be broken in a matter of time [1] https://storage.courtlistener.com/recap/gov.uscourts.rid.56980/gov.uscourts… [2]https://github.com/yuzu-emu/yuzu

4 3

Upgrade failure
by David Bohman 04 Mar '24

04 Mar '24

% sudo pacman -Syu :: Synchronizing package databases... core is up to date extra is up to date :: Starting full system upgrade... :: Replace libblockdev-utils with extra/libblockdev? [Y/n] resolving dependencies... looking for conflicting packages... error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: libblockdev and libblockdev-utils are in conflict % It looks like both packages provide libbd_utils.so=3-64.

7 10

Fwd: [to Arch General] Consolidating our mkinitcpio hooks
by David C. Rankin 04 Mar '24

04 Mar '24

I've followed the mkinitcpio v38 thread and efforts to not break systems. This has me concerned. I have 3 Arch servers with many mdadm RAID arrays. What changes will I have to make regarding mdadm_udev to ensure my system doesn't break? Will simply updating once all the packages hit the mirrors be all that is required?: * mkinitcpio 38-1 * systemd xxxx * lvm2 xxxx * mdadm xxxx * cryptsetup xxxx Or will manual intervention be needed? -------- Forwarded Message -------- Subject: Re: Consolidating our mkinitcpio hooks Date: Sat, 2 Mar 2024 14:07:14 +0100 From: Morten Linderud <foxboron(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Yo, mkinitcpio v38 has been released and I made a personal test setup with the changes and everything seems to work fine on my end. To make sure we are limiting breakage I propose the following news item to go along with the update. Please note I'll insert the relevant versions when the packages hit the testing repositories sometime tomorrow if there are no objections to the current plan. Draft here: https://md.archlinux.org/ixPJWhJXTj6Arlyq3wb9jA # News Item Subject: mkinitcpio hook migration and early microcode With the release of mkinitcpio v38 several hooks provided from Arch packages has moved to the mkinitcpio upstream. The moved hooks are systemd, udev, encrypt, sd-encrypt, lvm2 and mdadm_udev. To ensure we are not breaking the boot of users we have introduced temporary conflicts into the respective packages to prevent you from installing packages that are no longer compatible. The following packages needs to be installed together: * mkinitcpio 38-1 * systemd xxxx * lvm2 xxxx * mdadm xxxx * cryptsetup xxxx Please note the `mkinitcpio` flag `--microcode` has been deprecated in favour of a new `microcode` hook. This also allows you to drop the mircocode `initrd` lines from your boot configuration as they are now included in your initramfs. -- Morten Linderud PGP: 9C02FF419FECBE16 -- David C. Rankin, J.D.,P.E.

3 3

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