You are not logged in.
Pages: 1
I honestly don't know - gcr-4 is currently not installed... When I look at the list of required by here: https://www.archlinux32.org/packages/pe … tra/gcr-4/ I do see gnome-keyring, which I have indeed installed, also libmna.
On the other hand, if I try to uninstall gcr, I get this:
[emgaron@hamish ~]$ sudo pacman -R gcr
[sudo] password for emgaron:
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing gcr breaks dependency 'gcr' required by gnome-keyring
:: removing gcr breaks dependency 'gcr' required by gvfs
:: removing gcr breaks dependency 'gcr' required by libnmaI just tried to run an upgrade on my EeePC for the first time in a few weeks and the upgrade fails while trying to install gcr-4:
(171/171) checking keys in keyring [##################################################################] 100%
(171/171) checking package integrity [##################################################################] 100%
(171/171) loading package files [##################################################################] 100%
(171/171) checking for file conflicts [##################################################################] 100%
error: failed to commit transaction (conflicting files)
gcr-4: /usr/lib/gcr-ssh-agent exists in filesystem (owned by gcr)
gcr-4: /usr/lib/systemd/user/gcr-ssh-agent.service exists in filesystem (owned by gcr)
gcr-4: /usr/lib/systemd/user/gcr-ssh-agent.socket exists in filesystem (owned by gcr)
Errors occurred, no packages were upgraded.Could this be caused by gcr 3.41.1-3.0 still being in staging? When I look the the file list of 3.41.1-3 upstream, the offending files don't seem to be part of that package...
And so it does - thanks a million for your effort there!
No problem, I patched 1.4.0rc1 and it is currently building.
Great - thank you very much!
I wonder why upstream is releasing release candidates? It can only be because stable versions are even worse..
Hm - all I can see is that on my "normal" Arch Linux machines the installed (and working) version of Clementine is 1.4.0rc2-2, so it has to have built somehow. As for the release candidates: the last stable release from Clementine is 1.3.1, which is some six years old and has a number of bugs - going for 1.4.0rcX actually makes sense to me in that situation.
Ouch... I'm afraid, the days where I could at least have hoped to be of any assistance in that bug are long gone...
But I'm also a bit confused - Clementine seems to request an older libprotobuf.so than what is installed:
$ ldd `which clementine`
linux-gate.so.1 (0xb7fb4000)
libprotobuf.so.30 => not found
libmygpo-qt5.so.1 => /usr/lib/libmygpo-qt5.so.1 (0xb6eae000)
[...]That should not be related to the bug you mention or am I missing something?
Wow, that was quick, thank you! And yes, the nextcloud-client is working again!
Another issue I ran into after the latest upgrade: the nextcloud-client is no longer starting. The error message states "Cannot mix incompatible Qt library (5.15.5) with this library (5.15.6)". When looking at what is installed for Qt, I do indeed see qt5-base and a few others at 5.15.6, while there are still some other Qt-related libraries at 5.15.5 (I can provide a list if needed). Will the other packages also be updated?
I just updated my trusty old eeePC 1000H for the first time in months. Everything went well; however, since the update, Clementine no longer starts. The error message I get points to a missing libprotobuf.so.30 (installed is libprotobuf.so.32) - I take is that this is "just" a matter of rebuilding the package?
In any case, the certificate seems to have been updated, so cudos to whoever is responsible!
Absolutely fabulous, thank you very much! I'm still amazed at what my 10 year old eeePC 1000H still can do as a daily driver thanks to your efforts!
No idea where to put this, so apologies for posting this in the wrong place:
Apparently, the certificate for bbs.archlinux32.org has expired today (03/06/2019) - I can no longer connect to the forum using Firefox, as Firefox refuses to make a connection to a site that has HSTS set and an expired certificate (using Chromium to write this).
Not quite sure whether this is the right subforum and I cannot file bugs, so...
Since the upgrade to pentium 4 packages, clementine fails with an error message that libcryptopp.so.7 is missing. Apparently, clementine needs to be rebuilt with the newer libcryptopp that is supplied for pentium4. For now, I have worked around this by extracting the missing library from the i686 package - seems to work... ;-)
Actually for you I wonder if there's something up with your package mirrors in fact. I'm on 5.1.3-1.4 and on pentium4, which I guess came from the testing repo. There's now a -1.5 in testing, but core is still on -1.3.
Looking in i686, that has -1.3 and -1.4 in core. This seems to be a discrepancy that will catch anyone not using the testing repos, although if you only use one -u to your pacman -Sy invocation you might avoid the mess.
Just to confirm: I'm indeed not using the testing repos, so that would make sense
After the last update, pacman 5.1.3-1.4 had already been installed and I had never changed the Architecture-entry from "auto". "pacman-conf Architecture" responded with "pentium4", so I started with the full switch to the new architecture (my EeePC 1000H was still on i686).
All went well, however, after the update, "pacman-conf Architecture" suddenly responded with "i686". I then found out that the architecture switch had downgraded pacman back to 5.1.3-1.3 and there seems to be no update candidate for pentium4. Hence, I changed pacman.conf to "Architecture=pentium4" for the time being.
Is that supposed to happen or did I mess something up? Other than that (and the fact that a number of packages are still i686), the system is running just fine...
I have an ancient BookPC i810 (P3 Celeron 1GHz, Intel i810 chipset) which I intend to give away. To check whether it is actually still working, I installed Arch32 and eventually succeeded, but I did run into two issues:
When booting, the text on the console got garbled. I think this might be related to this problem, though I did not spend much time investigating. I ended up setting GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub, which solved the problem.
The PS/2 devices (both mouse and keyboard) were not detected once the machine was up. Fortunately, I had a USB keyboard, so I could continue... This turned out to be related to PS/2 support being modular. Contrary to what is written in that article, it was not sufficient to add "atkdb" to the "MODULES=" line in mkinitcpio.conf - I also had to add the "i8042" module explicitly, as the kernel apparently failed to detect that. After that, the PS/2 devices worked normally again.
Hopefully, this is helpful for someone at some point. :-)
There were various issues around rust and librsvg to compile without SSE2 instructions. Should
be fixed now in stable.
Yes! At least it is now on the old BookPC i810 I'm currently installing on. I was already considering to use xdm... Thanks for fixing this!
Keep in mind that this is a *really* old box (a P3 Celeron, not any of that newfangled stuff, Intel i810 chipset) - I previously had a 2013-installation of Arch running on that and decided to re-install because I could not upgrade to Arch32 anymore (got into a dependency loop - pacman too old, newer pacman requires newer libcrypto and glibc, and so on). I'm willing to bet it's a module/driver issue.
Point (2) above is really weird, there must be something else going on... I tried once more and got an error on a different key (and could not upgrade archlinux32-keyring because pacman refused to install anything w/o keys). Then I called it a night and today, first thing I noticed was that the BIOS-battery was empty. So I fixed that and re-configured the BIOS, then tried the whole install again. pacstrap is running as we speak, happily installing...
Point (1) is still valid - I have no PS/2 keyboard at the install prompt. I think I might be running into this problem caused by the PS/2 keyboard support being modular these days.
Hi all,
I'm currently trying to install Arch32 on an old Book PC (1GHz Celeron). I've burned the 2019.01.04 image on CD (that machine cannot boot from USB) and booting works fine. Then I run into these problems:
1) The PS/2 keyboard is no longer recognised once Arch32 has booted up (it works in BIOS, so the keyboard and connection is ok). I'm currently working around that using an USB-keyboard (fortunately does work)
2) I've partitioned and formatted the drive and now fail at the "pacstrap /mnt base" step. The system updates the repositories without error and downloads all packages, but then fails to install any of them with the error message 'signature from Erich Eckner (just to sign arch packages) <...> is marginal trust'. If I try to install anything directly with pacman, I get the same error.
Any ideas?
rhythmbox isn't the only package that is missing libidn.so.11 - lynx and elinks are also broken (same error). On my system, I have extracted libidn.so.11 from /var/cache/pacman/pkg/libidn-1.33-2-i686.pkg.tar.xz (i.e. the old version still in cache) and manually copied it to /usr/lib. Of course, this is only a stop-gap workaround and I will remove that file as soon as the other packages have been updated.
When I look at the versions of those packages, I notice that there have been several updates (output from "pacman -Ss gstreamer"):
extra/gst-plugins-bad 1.12.4-5.0 [installed]
extra/gst-plugins-base 1.14.0-1.0 [installed: 1.12.4-1.0]
extra/gst-plugins-base-libs 1.14.0-1.0 [installed: 1.12.4-1.0]
extra/gst-plugins-good 1.12.4-2.0 [installed]
extra/gst-plugins-ugly 1.12.4-3.0 [installed]
extra/gstreamer 1.14.0-1.0 [installed: 1.12.4-1.0]
(quite possible that I missed an update in between - been lazy recently)
Note that none of the gst-plugins-{good,bad,ugly} has an updated candidate for version 1.14.0 (yet). They do, however, exist in version 1.14.0 in the main Arch Linux package list, but they've only been updated on March 30th (i.e. yesterday).
Further, the package "gst-plugins-base-lib" does not exist yet on my installation.
My conclusion from this: There has been a major reshuffling of the file-to-package mapping between version 1.12.4 and 1.14.0 - apparently, some files have been moved from gst-plugin-{good,bad,ugly} to gst-plugin-base-lib. As the packages for gst-plugin-{good,bad,ugly} have not been updated to version 1.14.0 yet in the Arch32 repositories, this results in the conflicts that we see, as the old versions also still own those files. I will therefore wait for a couple of days before re-trying the update. I would not at all be surprised if this conflict vanished as soon as the new versions of said packages have been added to the Arch32 repositories.
Pages: 1