You are not logged in.

#1 Re: Installation » SSL Certificate for this forum expired » 2019-06-21 15:33:44

In any case, the certificate seems to have been updated, so cudos to whoever is responsible!

#2 Re: Installation » Pentium 4: clementine fails due to missing library » 2019-06-21 15:30:28

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!

#3 Installation » SSL Certificate for this forum expired » 2019-06-03 21:17:17

Replies: 6

No idea where to put this, so apologies for posting this in the wrong place:

Apparently,  the certificate for 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).

#4 Installation » Pentium 4: clementine fails due to missing library » 2019-06-03 20:58:31

Replies: 3

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 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... ;-)

#5 Re: Announcements » new pacman will auto-install pentium4 packages » 2019-05-19 19:08:33

levi wrote:

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

#6 Re: Announcements » new pacman will auto-install pentium4 packages » 2019-05-18 11:40:10

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...

#7 Kernel & Hardware » Quirks with BookPC i810 » 2019-03-13 17:12:16

Replies: 0

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. :-)

#8 Re: Kernel & Hardware » Bug report: LXDM fails with invalid op-code in librsvg-2:2.42.1-1.0 » 2019-03-13 16:47:31

andreas_baumann wrote:

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!

#9 Re: Installation » Install failure with 2019.01.04 » 2019-03-11 23:13:25

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.

#10 Re: Installation » Install failure with 2019.01.04 » 2019-03-11 22:00:13

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.

#11 Installation » Install failure with 2019.01.04 » 2019-03-10 18:36:58

Replies: 4

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?

#12 Re: Pacman / Pacman Upgrades » pacman libidn upgrade breaks rhythmbox » 2018-10-27 21:53:41

rhythmbox isn't the only package that is missing - lynx and elinks are also broken (same error). On my system, I have extracted 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.

#13 Re: Pacman / Pacman Upgrades » gst-plugins-bad, gst-plugins-base-lib and gst-plugins-base: same files » 2018-03-31 10:41:19

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.

Board footer

Powered by FluxBB