More db-update woes (seems only affecting pentium4)...

Karmak23 · 2019-12-04 13:06:27

Hello all,

In https://bugs.archlinux32.org/index.php? … B0%5D=open Erich said :

deep42thought wrote:

The problem was, that db-update did not check the version of the dependencies - so this could have happened to any package which did not pull in other dependencies carrying the version directly in the name (like libraries and symbols)

It seems this has already made more harm with QT :

https://bugs.archlinux32.org/index.php? … B0%5D=open

and perhaps :

https://bugs.archlinux32.org/index.php? … B0%5D=open
https://bugs.archlinux32.org/index.php? … B0%5D=open

In fact, the pentium4 current status is becoming slowly quite unusable (python & QT apps broken). Is there a way to stop moving packages to stable, or re-push working / synchronized libraries versions to stable ?

I can't remember exactly which (I've tried at least 10 recently), but a lot of AUR packages are failing to build because of python 3.7/3.8 problem. I'm on pentium4, by the way. Andreas seems to confirm i686 is not affected in https://bugs.archlinux32.org/index.php? … B0%5D=open.

Last edited by Karmak23 (2019-12-04 13:11:35)

Karmak23 · 2019-12-04 20:39:59

Some Python GI applications are broken. It seems because Python 3.8 made its way to stable, python-gobject too, but the applications are still depending on python 3.7. Example : **blueman**. Downgrading python to latest 3.7 and python-cairo makes blueman work again, but downgrading python at the system-wide seems a bad idea, generally speaking...

levi · 2019-12-04 20:56:47

Hmm, yes, if this still hasn't been resolved for python on stable yet then that's not a good look for this project, I'd argue.

But at the same time, I'd argue that if that's your only problem, then enabling the testing repos results in less breakages of this type. IIRC the testing repos are a clone of the upstream Arch stable release branch except for a few things that fail to build on target hardware, and certainly it seems to be immune to db-update woes.

Still QT apps in testing seem broken to me. I only have keepassxc installed that uses QT on my system as I recall, and trying to start that error with 'Executable 'keepassxc' requires Qt 5.13.2, found Qt 5.13.1.'. Apparently keepassxc was updated on Nov 17 and 25th here, although I don't think I tried to run it during that juncture, so I can't say when it broke exactly. So if QT apps are important to you, then enabling the testing repos doesn't seem to help, because that breakage doesn't seem to be caused by db-update.

FWIW I can't get keepassxc working by downgrading it. The last two releases give the same error, while the 2.5.0-2.0 release reckons the GL internal version number is actually too high. But I'm not going to try anything else; it's not something I actively use, so it's not worth me spending much more time trying to fix it.

deep42thought · 2019-12-05 07:12:06

the problem here is, that some python packages simply do not build and block all the rest - aaand that I really want to finish my thesis currently

Karmak23 · 2019-12-05 10:43:17

Can I help ?

I'm a (retired by choice) python developer and system administrator.

Here, python-pycups is broken (no downgrade installation candidate...), so is system-config-printer, and i cannot print without using my hands or console, youtube-dl is broken for a similar reason (pkg_resources is 3.8, python is 3.7...) and have no time for that because my stove is broken too and it's my priority to rebuild it ;-) (done; hearth rebuilt with refractory bricks )

But fixing python packages *could* be a matter of minutes (or more) between two fire lauches or baby-nursing or wood chopping.
I could also submit patches for AUR build files to add pentium4 arch where relevant. Stil again, no time, but if I can reach a streamlined process state, this could happen.

Tell me.

Last edited by Karmak23 (2019-12-05 22:28:29)

deep42thought · 2019-12-06 10:08:42

You can find broken python packages here: https://archlinux32.org/buildmaster/bui … oken&next=

Meanwhile, we changed the moving logic to ignore packages which have been broken for more than a day, so only *those* should break in stable, while all the others should get moved synchronously.

levi · 2019-12-06 18:01:59

That link doesn't capture all of the broken dependencies. Not all python code comes from a package that begins python- for a start, and I'd guess other stuff doesn't actually get exercised at build time, and I don't know what sort of internal test jigs are run on the build servers, if any.

If it would be of any use, almost anyone here with the free bandwidth could write a quick script to import everything at the head of all python packages, and report back if any of those fail (ideally it would try and catch all ImportErrors and just log a message so it can go and test the rest still in one run). I don't know if there are any packages with conflicting names, or any other conflicts between simultaneously installed packages, but it may be worth writing a shell script to start an execution of the cpython interpreter for each one, because I don't know off the top of my head any way to purge imported packages from the root namespace, and that would be slightly more representative of the way these things were used.

Would the build machines have all python packages installed at the end of the build process? Could we just look in /usr/lib/python3.*/site-packages (after running python --version to discover what that x should be), or would we need to interface with pacman to pull down all of the python libs after discovering what they were all called somehow?

Edit: And of course, this isn't always an error that's exposed by testing after building, if it was promoted to stable by db-update either before or after the minor python version ticks over, that'll result in a basic undiscoverable python library, which actually is the problem at hand here I tend to think. The method above will still indicate if anyone actually installs all of the stable python libs and tried to use them, but that's not something we do ahead of time as far as I know. Ideally everything that ships a python library should be marked with the major and minor version of python it was built again, so their update can be timed appropriately, but how to do that is kind of beyond my ken here.

Last edited by levi (2019-12-06 18:07:56)

deep42thought · 2019-12-07 11:54:51

the link was not supposed to list broken python packages in the repositories, but rather python packages which fail to build and thus block moving all of python3.8 to testing and then to stable.
Packages with broken dependencies in the database can be found here - but that's only, what is known to the database: if any additional packages have broken dependencies, I want to know about it because it's a bug in our dependency tracking, then.

regards,
deep42thought

levi · 2019-12-09 00:19:23

Okay, thanks for clarifying. I'm running python3.8 which I got from the testing repos though, and now I've just checked and it seems to have migrated to stable. Perhaps that happened since you posted though.

I've ran 'find /usr/lib/python3.7/site-packages/ -type f -exec pacman -Qo {} \;|awk '{print $5}'|sort|uniq' on my machine, since it has the testing repos enabled and I'm on python3.8. Since it uses sort it won't print anything until it's done, and it takes just over a minute on my hardware.

I then realised I'd been rather lax in updating my system, and hadn't updated for about two weeks.

But before I'd updated, the resulted bad packages printed, I can't find a documented python dependency on:
avahi
bind-tools
ldb (it has a missing dependency on python in i686 but not in pentium4??)
lensfun
libproxy
libibus
libgexiv2
libblockdev
libbytesize
python-gobject
volume_key (in pentium4 but not in i686)

Unless a dependency has been added to the database for those in the past couple of weeks, I'd suggest they still need looking at. The fact they've all been updated could mean some of them just happened to be updated by coincidence, and they did end up mismatched on my system a couple of weeks ago. Although I guess they might have had a dependency on python that's simply not shown on that webpage because it's testing against a more recent set of updates to the repo than I was running.

The only thing in my /usr/lib/python3.7/site-packages now is uno.py/unohelper.py which are links owned by my install of libreoffice-still, which hasn't seen an update for about two months now. It's not stopping the program from launching though, or editing the files that I've edited since my python migrated to 3.8. I guess it's provided for other tools to interface with libreoffice, and the only thing I have that declares a dependency on libreoffice-still is my dictionary pack.

If others can run my command to check their python3.7 folder(s) they might find out stuff I've simply not installed, and especially if they're not users of the testing repos it'd be worth them posting their results here even if they report no problems.

Arch Linux

#1 2019-12-04 13:06:27

More db-update woes (seems only affecting pentium4)...

#2 2019-12-04 20:39:59

Re: More db-update woes (seems only affecting pentium4)...

#3 2019-12-04 20:56:47

Re: More db-update woes (seems only affecting pentium4)...

#4 2019-12-05 07:12:06

Re: More db-update woes (seems only affecting pentium4)...

#5 2019-12-05 10:43:17

Re: More db-update woes (seems only affecting pentium4)...

#6 2019-12-06 10:08:42

Re: More db-update woes (seems only affecting pentium4)...

#7 2019-12-06 18:01:59

Re: More db-update woes (seems only affecting pentium4)...

#8 2019-12-07 11:54:51

Re: More db-update woes (seems only affecting pentium4)...

#9 2019-12-09 00:19:23

Re: More db-update woes (seems only affecting pentium4)...

Board footer