You are not logged in.
Pages: 1
Does it still happen, if you upgrade the archlinux32-kering first?
It appears so, yes:
[user1@arch-server ~]$ sudo pacman -Syy
:: Synchronizing package databases...
core 109.0 KiB 363 KiB/s 00:00 [########################################################] 100%
extra 6.8 MiB 3.14 MiB/s 00:02 [########################################################] 100%
[user1@arch-server ~]$
[user1@arch-server ~]$ sudo pacman -S archlinux32-keyring
warning: archlinux32-keyring-20250119-1.0 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) archlinux32-keyring-20250119-1.0
Total Installed Size: 0.05 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [########################################################] 100%
(1/1) checking package integrity [########################################################] 100%
(1/1) loading package files [########################################################] 100%
(1/1) checking for file conflicts [########################################################] 100%
(1/1) checking available disk space [########################################################] 100%
:: Running pre-transaction hooks...
(1/1) tmp-exec.hook
:: Processing package changes...
(1/1) reinstalling archlinux32-keyring [########################################################] 100%
==> Appending keys from archlinux32.gpg...
==> Updating trust database...
gpg: next trustdb check due at 2025-06-16
[user1@arch-server ~]$ sudo pacman -S linux-lts-headers
resolving dependencies...
looking for conflicting packages...
Packages (1) linux-lts-headers-6.12.13-1.1
Total Download Size: 21.24 MiB
Total Installed Size: 87.87 MiB
Net Upgrade Size: 1.66 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
linux-lts-headers-6.12.13-1.1-pentium4 21.2 MiB 3.27 MiB/s 00:06 [########################################################] 100%
(1/1) checking keys in keyring [########################################################] 100%
(1/1) checking package integrity [########################################################] 100%
(1/1) loading package files [########################################################] 100%
:: File /var/cache/pacman/pkg/linux-lts-headers-6.12.13-1.1-pentium4.pkg.tar.zst is corrupted (invalid or corrupted package).
Do you want to delete it? [Y/n] When I tried to update I got this error:
File /var/cache/pacman/pkg/linux-lts-headers-6.12.13-1.1-pentium4.pkg.tar.zst is corrupted (invalid or corrupted package).When I check it manually it seems this package is signed with an expired key.:
[user1@arch-server sigtest]$ gpg --verify linux-lts-headers-6.12.13-1.1-pentium4.pkg.tar.zst.sig linux-lts-headers-6.12.13-1.1-pentium4.pkg.tar.zst
gpg: Signature made Mon 17 Feb 2025 08:00:53 PM CET
gpg: using RSA key 16194A82231E9EF823562181C8E8F5A0AF9BA7E7
gpg: Can't check signature: No public key
[user1@arch-server sigtest]$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 16194A82231E9EF823562181C8E8F5A0AF9BA7E7
gpg: /home/user1/.gnupg/trustdb.gpg: trustdb created
gpg: key C8E8F5A0AF9BA7E7: public key "Andreas Baumann (sign) <mail@andreasbaumann.cc>" imported
gpg: Total number processed: 1
gpg: imported: 1
[user1@arch-server sigtest]$ gpg --verify linux-lts-headers-6.12.13-1.1-pentium4.pkg.tar.zst.sig linux-lts-headers-6.12.13-1.1-pentium4.pkg.tar.zst
gpg: Signature made Mon 17 Feb 2025 08:00:53 PM CET
gpg: using RSA key 16194A82231E9EF823562181C8E8F5A0AF9BA7E7
gpg: Good signature from "Andreas Baumann (sign) <mail@andreasbaumann.cc>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 1619 4A82 231E 9EF8 2356 2181 C8E8 F5A0 AF9B A7E7I know I can set siglevel to 'never' to get around it, but will this package be signed with an up-to-date key sometime in the future?
You can set SigLevel=Never just to update the keyrings and then reenable it.
.
This solved it, although it does seems to me that installing keyrings without signature checking defeats the purpose of using a keyring.
Hi all
I had not updated my arch32 system for a couple of months. When I did a pacman -Syu today I got this error about signature TasosSah for a number of packages and then the upgrade fails::
error: iana-etc: signature from "TasosSah (Arch32 Package Signing Key) <arch32@tasossah.com>" is marginal trust
:: File /var/cache/pacman/pkg/iana-etc-20231228-1.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).Here is the Complete output of pacman -Syu.
I tried:
# pacman -Sy archlinux-keyring archlinux32-keyring But this gives the same error. I then tried:
# pacman-key --refresh-keysBut this does not resolve the issue. I then tried manually verifying the signature of archlinux-keyring, but that failed as well:
gpg --verify /var/cache/pacman/pkg/archlinux-keyring-20231222-1.0-any.pkg.tar.zst.sig /var/cache/pacman/pkg/archlinux-keyring-20231222-1.0-any.pkg.tar.zst
gpg: Signature made Sat 06 Jan 2024 04:52:51 AM CET
gpg: using RSA key 80EC18799E8BCD375C6E64ABE4D41569196B1160
gpg: Can't check signature: No public keyHow can I fix this? Should ignore pacman signature checking for archlinux-keyring and archlinux32-keyring with '--ignore ' , or would that create more problems?
Thanks, that solved it. I also did this to be sure that dhcpcd is disabled.
#systemctl disable dhcpcdI have a headless server with an Intel Atom 270 (intel D945GSEJT) motherboard with 32 bit pentum4 architecture. I use netctl for network management.
/etc/netctl/myethernet:
Connection=ethernet
Description='A basic dhcp ethernet connection using iproute'
Hostname='arch-server'
Interface=eno1
IP=dhcp
AutoWired=yesAfter a recent reboot I noticed that the network interface did not get an ip address. When I configure a static ipadress network works fine. I am not sure if have done an upgrade since the last reboot.
I presume its because dhcpcd is crashing. This is what journalctl says:
Nov 30 21:49:20 arch-server systemd-coredump[549]: [?] Process 545 (dhcpcd) of user 0 dumped core.
Stack trace of thread 545:
#0 0x00000000b7f34549 __kernel_vsyscall (linux-gate.so.1 + 0x549)
#1 0x00000000b7dbd657 n/a (libc.so.6 + 0x90657)
#2 0x00000000b7d68597 raise (libc.so.6 + 0x3b597)
#3 0x00000000b7d4f121 abort (libc.so.6 + 0x22121)
#4 0x00000000b7d501bd n/a (libc.so.6 + 0x231bd)
#5 0x00000000b7e58ef3 __fortify_fail (libc.so.6 + 0x12bef3)
#6 0x00000000b7e588bf __chk_fail (libc.so.6 + 0x12b8bf)
#7 0x00000000b7e59e85 __strlcpy_chk (libc.so.6 + 0x12ce85)
#8 0x00000000004cc096 ps_newprocess (dhcpcd + 0x36096)
#9 0x00000000004d39ce ps_root_start (dhcpcd + 0x3d9ce)
#10 0x00000000004d40a6 ps_start (dhcpcd + 0x3e0a6)
#11 0x000000000049e3d9 main (dhcpcd + 0x83d9)
#12 0x00000000b7d50b09 n/a (libc.so.6 + 0x23b09)
#13 0x00000000b7d50bcd __libc_start_main (libc.so.6 + 0x23bcd)
#14 0x000000000049f22b _start (dhcpcd + 0x922b)
ELF object binary architecture: Intel 80386What could be causing this?
Should I file a bug for systemd, and if so which info should I provide?
As a workaround I downgraded a bunch of packages that depend on python 3.11 to their latest python 3.10 one. After that I was able to build and run rdiff-backup 2.2.5-3 from aur.
Thanks for the reply. But if I build rdiff-backup using devtools32 on my arch (x86_64)) system, wouldn't that have the same python-bootstrap and setuptools. problems that I encountered when compiling directly on my arch32 system?
I realise I keep writing compile, but rdiff-backup is written in python 3 so i assume there is no compiling required, only building a package.
Would filing a bug for the python-bootstrap and setuptools packages be a good idea, or is python so generally borked on arch32 that it is useless?
Hi all
I have been useing rdiff-backup from the Arch32 repository as my backup tool for years. But the package in the repository is old and about to be deleted. So i tried compiling the latest version from the AUR for my pentium4 architecture home server.
In the PKGBUILD I changed arch=arch=(x86_64) to arch=(x86_64 pentium4). But when compiling with 'makepkg -rs' I get errors that seem to be about the build environment (python-setuptools) rather than rdiff-backup:
AttributeError: 'Distribution' object has no attribute 'exclude_package_data'. Did you mean: 'exclude_package'?Full output at https://pastebin.com/5gPwG9Z1
The maintainer from Aur is willing to help but has no 32 bit system to test on. And cross compiling from Arch does not seem a viable option since they obviously dropped 32 bit support.
What can I try to compile without these errors?
Pages: 1