So it’s something we changed or something changed on one of the i486 build slaves.

Happens only on the AMD-K6, all other machines with CPUs with limited special instructionsets (Pentium-S, AMD Geode) are working fine.

]]>FS#37: ISO 2018.05.01 is not bootable with qemu or Virtualboxhttps://bugs.archlinux32.org/index.php?do=details&task_id=37
2019-01-23T18:29:02ZAndreas Baumann
I tried the i686 image. Booting leads to kernel panic.Adding an explicit init=/lib/systemd/systemd parameter also panics.
qemu-system-i386 -cdrom archlinux-2018.05.01-i686.iso
It also panics in Virtualbox.
The same ISO works with libvirtd though.
I tried the i686 image. Booting leads to kernel panic.Adding an explicit init=/lib/systemd/systemd parameter also panics.

]]>FS#49: ffmpeg update failures in release and testinghttps://bugs.archlinux32.org/index.php?do=details&task_id=49
2018-10-29T11:50:56ZLevi
When I have done a pacman -Syu recently, it offers to update libx264 with x264:
:: Replace libx264 with testing/x264? [Y/n]
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing libx264 breaks dependency 'libx264.so=152-32' required by ffmpeg
As can be seen there, it fails because a dependency is not met.
This is reportedly also a problem on the release branches.
Using pacman&#8217;s query functionality I can see that x264 claims to provide libx264.so=155-32 rather than 152-32 i.e. x264 is too new for the current version of ffmpeg.
I consider this a high priority defect because ffmpeg is used by rather a lot of a/v playback and transcoding software.
Steps to reproduce
$ pacman -Syu
Workaround
Press n and enter when it offers to upgrade libx264. Ensure you&#8217;re not using multiple -ys on your pacman invocation.
Suggested fix
Provide an updated ffmpeg.
When I have done a pacman -Syu recently, it offers to update libx264 with x264:

Using pacman’s query functionality I can see that x264 claims to provide libx264.so=155-32 rather than 152-32 i.e. x264 is too new for the current version of ffmpeg.

I consider this a high priority defect because ffmpeg is used by rather a lot of a/v playback and transcoding software.

Steps to reproduce

$ pacman -Syu

Workaround

Press n and enter when it offers to upgrade libx264. Ensure you’re not using multiple -ys on your pacman invocation.

Suggested fix

Provide an updated ffmpeg.

]]>FS#55: protobuf 3.6.0 needs pushing from testing to stablehttps://bugs.archlinux32.org/index.php?do=details&task_id=55
2018-10-28T18:03:16ZLevi
As per https://bbs.archlinux32.org/viewtopic.php?pid=5140
Python-protobuf 3.6.0 has already been pushed to extra for a long time now, but protobuf is still at version 3.5.2. As far as I&#8217;m aware, the set in testing all works.
For completeness, puthon2-protobuf 3.6.0 probably needs to be migrated to stable extra as well.
As per https://bbs.archlinux32.org/viewtopic.php?pid=5140

Python-protobuf 3.6.0 has already been pushed to extra for a long time now, but protobuf is still at version 3.5.2. As far as I’m aware, the set in testing all works.

For completeness, puthon2-protobuf 3.6.0 probably needs to be migrated to stable extra as well.

]]>FS#48: Testing repo missing a new version of python-sixhttps://bugs.archlinux32.org/index.php?do=details&task_id=48
2018-09-24T08:45:56ZLevi
I&#8217;ve become aware that python-six doesn&#8217;t identify that it depends specifically on python3.6 (it claims in the text that it&#8217;s for python 3 as well as python 2, which I don&#8217;t believe can be true; it only puts python files in /usr/lib/python3.6).
It has however allowed python 3.7 into the testing repo while no new version of python-six is available, and this version of python3 can no longer find a version of six when you import it.
As far as I know this is not an issue for anyone strictly on the release repos yet, and still won&#8217;t be an issue for anyone not using python-six either directly or indirectly.
Steps to reproduce
(upgrade at least python from the testing repos)# python# import six&amp;gt; ...&amp;gt; ModuleNotFoundError: No module named &#8216;six&#8217;
Steps to fix
A new version of python-six that supplies its files to python3.7/site-packages should be built and uploaded to the testing repos, and it should probably identify its dependent versions better.
I note arch64 has a newer python-six that supplies its libs to python3.7 just fine, although it also doesn&#8217;t identify its versions to my liking.
I’ve become aware that python-six doesn’t identify that it depends specifically on python3.6 (it claims in the text that it’s for python 3 as well as python 2, which I don’t believe can be true; it only puts python files in /usr/lib/python3.6).

It has however allowed python 3.7 into the testing repo while no new version of python-six is available, and this version of python3 can no longer find a version of six when you import it.

As far as I know this is not an issue for anyone strictly on the release repos yet, and still won’t be an issue for anyone not using python-six either directly or indirectly.