- Arch-general - lists.archlinux.org

kernel from own built package won't boot
by solsTiCe d'Hiver 19 Mar '24

19 Mar '24

Hi, I have made a thread on the forum: https://bbs.archlinux.org/viewtopic.php?id=293601 But I did not get much help. I don't know if it is appropriate to post here. I have dug a bit into my issue, and when I build an official PKGBUILD for a kernel, be it linux or linux-zen (pkctl repo clone linux); makepkg --skippgpcheck; sudo pacman-U linux-...), the kernel is not booting with an error. At first, I was thinking it was related to either Secure Boot or shim, or the UKI, but later tests in VMs using BIOS revealed the problem was still there. And I got an error message from the kernel: "ZSTD-compressed data is corrupt" (when booting with limine in BIOS) I found that very string in ./lib/decompress_unzstd.c. in the kernel source. I even rebuilt the kernel inside the VM to rule out host issue (?). I later used an initramfs with no compression (COMPRESSION="cat") and using uncompressed modules in it (MODULES_DECOMPRESS="yes"). But the problem remained. I tried to boot the kernel with the same package on another machine. Still the same. How could this happen? Is it my installation of archlinux? The compilation of the kernel ? Is it something else? What? mkinitcpio? but why does it work with the official package, then? Could you reproduce it? Thanks

2 1

New pacman -Sc floods screen with warnings
by David C. Rankin 17 Mar '24

17 Mar '24

Just updated and went to clear old cache packages with 'pacman -Sc' and... 05:35 2pi:~> pms -c Packages to keep: All locally installed packages Cache directory: /var/cache/pacman/pkg/ :: Do you want to remove all other packages from cache? [Y/n] removing old packages from cache... warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: png2ico: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description warning: abs: unknown key 'makepkgopt' in package description ..... <snip 50-70 more What's up with this? -- David C. Rankin, J.D.,P.E.

2 3

openfin alternative (consultant needed)
by James Tobin 12 Mar '24

12 Mar '24

Hi, I'm working with a fintech company that is looking to hire a consultant that can help them explore alternatives to having to stay reliant on OpenFin. Consequently, I had hoped that you might like to discuss Consequently I had hoped some members of this list may like to discuss further All the best, James

1 0

Small question about mkinitcpio and linux.preset
by Óscar García Amor 09 Mar '24

09 Mar '24

Hello folks, With the latest update of mkinitcpio when running `mkinitcpio -P` you get the following warning: ``` WARNING: Deprecated option 'ALL_microcode' found. Update '/etc/mkinitcpio.d/linux.preset' to use the 'microcode' hook instead. ``` It is clear to me that this is because that option must be removed from the `/etc/mkinitcpio.d/linux.preset` file, but what surprises me is the following: ``` % pacman -Qo /etc/mkinitcpio.d/linux.preset error: No package owns /etc/mkinitcpio.d/linux.preset ``` Who generated the `linux.preset`? It is supposed to have been the `linux` package but right now I can't find how this file was generated. If someone could explain to me how this file is generated at the time of installation I would be very grateful. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

4 5

`makepkg` generates two packages
by lacsaP Patatetom 09 Mar '24

09 Mar '24

hi, when I run `makepkg`, it generates a second package with the `-debug` "extension" (eg. `mypackage-w.x.y-z-x86_64.pkg.tar.zst` and `mypackage-debug-w.x.y-z-x86_64.pkg.tar.zst`). I couldn't find anything about this on the wiki : is this a new feature and/or is there a parameter to pass to `makepkg` to avoid building it ? regards, lacsaP.

9 15

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