- Arch-general - lists.archlinux.org

Pacman/icu conflict: error while loading shared object
by Jeanette C. 09 Jun '25

09 Jun '25

Hey hey, I just updated icu, which broke pacman. I then used pacman-static to install the latest pacman version, using pacman-static, but no change. icu version: 76.1-1 pacman version: 7.0.0.r6.gc685ae6-6 Error message: pacman: error while loading shared libraries: libicuuc.so.75: cannot open shared object file: No such file or directory Can anyone suggest a workaround? Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c Just hang around and you'll see, There's nowhere I'd rather be <3 (Britney Spears)

4 11

Issues with Viewers for "special" images
by Ralf Mardorf 09 Jun '25

09 Jun '25

Hi, yesterday after the latest updates I tried to view some "special" images. I tried to view a JPEG 2000 with extra/geeqie and with extra/krita and I tried to view some FITS {,demo} images with extra/stellarsolver and extra/kstars. I don't know if this worked before, it was the first time I tried to view those kinds of images by my Arch Linux install. It was impossible to view the JPEG 2000 and more or less impossible to view FITS images. Just extra/stellarsolver was able to view a FITS demo image, but failed most of the times, too. I was able to view the JPEG 2000 image on an iPad Pro. I don't want to troubleshoot those issues, I'm just interested if somebody was ever able to view JPEG 2000 and/or FITS images with applications from the official repos. Regards, Ralf

6 11

Akonadi / KMail broken imap resource
by Bennett Piater 09 Jun '25

09 Jun '25

Hi, My IMAP resources broke in Kontact/KMail this week. My first idea was to try akonadictl restart, followed by fsck and vacuum. The restart triggered a mariadb migration, which was successful (shouldn't that have happened automatically before...?). However, it didn't change much. The logs were full of errors like these - the imap resource crashes, with no clear cause: org.kde.pim.akonadicontrol: ProcessControl: Application "/usr/bin/ akonadi_imap_resource" stopped unexpectedly ( "Process crashed" ) org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' crashed! 0 restarts left. org.kde.pim.akonadiserver: New notification connection (registered as Akonadi::Server::NotificationSubscriber(0x7fe4b02b4f00) ) org.kde.pim.akonadiserver: Subscriber Akonadi::Server::NotificationSubscriber(0x7fe4b02b4f00) identified as "AgentBaseChangeRecorder - 93936498547840" org.kde.pim.akonadiserver: Subscriber "AgentBaseChangeRecorder - 93936498547840" disconnected org.kde.pim.akonadicontrol: ProcessControl: Application "/usr/bin/ akonadi_imap_resource" stopped unexpectedly ( "Process crashed" ) org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' crashed too often. Giving up! I then tried deleting the mariadb and having akonadi re-create it, which helped me once in the past (should be fine since it's only an indexed cache). Finally, I tried deleting and re-adding the account in kontact. None of the above worked. Any ideas how to proceed? Is there more that I could try to reset? Are there more detailed logs somewhere? I'm hoping arojas has an idea - you're a heroic maintainer, thank you in any case! Cheers, Bennett

1 0

Signstar design concepts - questions
by cen 04 Jun '25

04 Jun '25

Hi, reading through https://signstar.archlinux.page/architecture/design.html can someone explain how the SSS shares are distributed among holders? Do they physically meet for a beer and each takes out a print out from initial console setup? Could you perhaps pre-bake share holder's SSH keys into the image and do a one share per key as the do first login? This way they could retrieve it remotely. My second question is if confidential compute was considered instead of a dedicated physical hardware and OS? Could you replace the setup with a confidential VM that runs signstar as verifiable service?

2 2

stable-repos Newsfeed Never Showed linux 6.14.7.arch2-1 x86_64 after it left core-testing?
by David C Rankin 25 May '25

25 May '25

Arch Admins, I use the newsfeeds extensively to keep track of what packages are coming for server updates. This past cycle with linux 6.14.7.arch2-1, it appeared in core-testing (https://archlinux.org/feeds/packages/x86_64/core-testing/) on 5/22, but I never show it reaching: https://archlinux.org/feeds/packages/all/stable-repos/ This is really just to pass this along in case there is a problem with the feeds. However, if anyone knows why this occurred, I'm curious about that fact as well. -- David C. Rankin, J.D.,P.E.

1 0

[ANNOUNCE] Proposed fix for dnssec-anchors package (outdated trust anchors + unused makedepends)
by meowmeowbeanz 24 May '25

24 May '25

Hi arch-dev-public, I'm announcing a proposed moderate change to the dnssec-anchors package per the developer manual guidelines. ## Summary Fix for 5+ year old DNSSEC trust anchors and unused makedepends in the dnssec- anchors package. ## Issues Addressed - GitLab Issue: #2 (outdated trust anchors) - Existing Bug: #77100 (unused makedepends, assigned to jelly) ## Proposed Changes - Restore dynamic trust anchor generation in build() function - Filter for KSK records (flag 257) to eliminate DNSSEC warnings - Update package version to 20250523-1 - Remove dependency on static 2019 files ## Testing - Verified DNSSEC validation works correctly - Eliminated knot-resolver warnings - Confirmed proper ad flag behavior with drill/kdig ## Merge Request Available at: https://gitlab.archlinux.org/archlinux/packaging/packages/ dnssec-anchors/-/merge_requests/1 The change preserves the established purpose (providing DNSSEC trust anchors) while updating to current practices and fixing confirmed bugs. Comments and feedback welcome. Thanks, meowmeowbeanz

1 0

openSUSE removes Deepin from official distro on security grounds - Arch have similar concerns?
by David C Rankin 14 May '25

14 May '25

Devs, The Register posted an article about openSUSE removing the Deepin desktop based on dbus abuse and other security and packaging violations. The issues are documented and linked in the article: https://go.reg.cx/tdml/dfd67/684a187f/7019d634/4gJn Has Arch done a similar analysis or have similar concerns? openSUSE have removed it from the distro, but left the package available in the community packager's repoo (similar to AUR setup). Not sure whether that is something to consider here. The concern being that by providing official packages openSUSE gave Deepin the aura of being up to the distros security standards where apparently that isn't something that was warranted. -- David C. Rankin, J.D.,P.E.

2 1

Bash [[ foo =~ regex ]] behavior changed with last update, gentoo patches?
by David C Rankin 09 May '25

09 May '25

Arch devs, I have a script that parses IP and CIDR notation using the following to capture IPs: [[ $1 =~ ^([^.]{1,3})[.]([^.]{1,3})[.]([^.]{1,3})[.]([^.]{1,3})$ ]] # validate 5 elements in BASH_REMATCH array if [ "${#BASH_REMATCH[@]}" -eq 5 ]; then ... (yes, I can improve it -- but that's not the point here) Then to capture CIDR: [[ $1 =~ ^([^.]{1,3})[.]([^.]{1,3})[.]([^.]{1,3})[.]([^.]{1,3})/(.*)$ ]] # validate 6 elements in BASH_REMATCH array if [ "${#BASH_REMATCH[@]}" -eq 6 ]; then ... This script was used to automatically update ipset lists and save /etc/ipset.conf. It has worked for years. Today after update to bash-5.2.037-3-x86_64 I get: $ ipsa 38.0.0.0/8 /home/david/scr/adm/ipset_add.sh: line 6: [: 0/8: integer expression expected /home/david/scr/adm/ipset_add.sh: line 6: [: 0/8: integer expression expected valid IP: 38.0.0.0/8 ipset v7.23: Hash is full, cannot add more elements The problem being for the first time ever, the regex in: [[ $1 =~ ^([^.]{1,3})[.]([^.]{1,3})[.]([^.]{1,3})[.]([^.]{1,3})$ ]] parsed the IP as 38 0 0 0/8 (with the "/8") instead of 38 0 0 0 filling the ipset blocklist completely with sequential 38.x.x.x IPs. Technically this regex matching is correct as the final character list [^.] doesn't preclude inclusion of '/', but this is a definite change from all prior bash versions. Is this the intended result of the gentoo patches change to the package? I've since fixed the regex with [^./] as the final list. Are there any other known changes to regex parsing with the changes to the bash PKGBUILD and patches? -- David C. Rankin, J.D.,P.E.

3 3

Package building and signing
by Pocket 06 May '25

06 May '25

I am building packages using makepkg for the raspberry pi 4 platform I changed the CFLAGS adding -march=armv8-a -mtune=cortex-a72 (makepkg.conf). I started to build all the packages that make up the "Building in a clean chroot" following the building in a claen chroot on the wiki. All when well. I will then build all the "base" package followed by all the packages I use on a "desktop" system. I would now like to make a custom repository for those packages and then have pacman install from there, eventually to remove the core extra etc repositories. I know how to create the custom repository (from the various wiki docs) using repo-add. I have a nginx web server on a remote raspberry pi and it will serve those packages from /etc/pacman.conf [custom] SigLevel = Optional TrustAll Server = http://www.home.arpa/Repository So my questions are as follows 1. How to get pacman to pull the packages from the custom repository first 2. I would like to sign the packages in the custom repository. I have looked at some of the information regarding signing packages(maybe missing some of them). It was totally confusing. I need guidance in the form of Step 1, step 2 etc. Is there such docs in existance? -- Hindi madali ang maging ako

5 8

Stop makepkg from running gpg on .sig files
by Sebastian Wiesner 06 May '25

06 May '25

Hello, apparently makepkg automatically attempts to verify .sig files in the SOURCES array with gpg. Can I somehow stop this behaviour? I have .sig URLs but these aren't GPG signatures, but SSH signatures I'd like to validate in a custom verify() function. Currently, I'm working around this by renaming the upstream .sig files to .sigssh in SOURCES, but that's rather inconvenient. Cheers, Basti

2 4