Python package: Upgrate/Restore failes on CI

I have no idea what’s wrong here: YunoRunner for CI with my project GitHub - YunoHost-Apps/pyinventory_ynh: YunoHost app package for: https://github.com/jedie/PyInventory

grafik

It’s currently my PR: Update to PyInventory v0.13.0 by jedie · Pull Request #78 · YunoHost-Apps/pyinventory_ynh · GitHub

My first idea to fix this was this change:

grafik

But both variants results in the same error:

This kind of error happens on debian based systems, if python3-venv is not installed.
But python3-venv is in my pkg_dependencies list and will be (re-)installed in restore script.

So that error should not happen, isn’t it?

Any idea?

Hm! It seems that this only failed on @tituspijean CI, but not on the official one, see: YunoRunner for CI

1 Like

Now it’s the same on the official CI, e.g.: YunoRunner for CI

grafik

Any idea?!? Think it’s a problem in CI, isn’t it?

I now created CI: Backup/Restore fails because of missing "python3-venv" package · Issue #1960 · YunoHost/issues · GitHub

Since I have been pinged, I ran some tests. And I can very officially say that I have no idea what’s going on. :confused:

Side note jedie, you are posting your issue all over the place. I completely sympathize, but it’s making it difficult to see the full scope of your investigations. (e.g. you found out that there is no issue on the Bullseye CI).

1 Like

Read that on debian it could be related to locales.
Did you try to add export LC_ALL=C before upgrading your venv ?

No. But why should this been done on a YunoHost package level? This is something that should be setup by YunoHost “core”, isn’t it?

The package works in the past and i never change something around the locales. So i think it’s not the problem.

It seems also that this is flaky. But debug flakyness is hard, because CI server are so slow :frowning: See also my new Thread about this here: YunoHost package maintaining: Continuous integration? Trouble with CI

Yes, sorry about this. That’s the trouble with forum.yunohost.org vs. GitHub. I didn’t quite understand the YunoHost philosophy behind it :wink:

Back to topic: Yes, on Bullseye it works. But it maybe just because of flakiness?!?

as a no coder, i am not on github. for that the forum is need and better understandable for me

To investiguate firstly at a package level before an escalation at a core level. Just an idea to help, your choice to test or not.

Somebody a other idea?!?

locales is not the problem: Test venv upgrade with LC_ALL=C by ewilly · Pull Request #89 · YunoHost-Apps/pyinventory_ynh · GitHub

I had a thought, not tested. Could it be that if fails to upgrade because… there’s nothing to upgrade?

–upgrade Upgrade the environment directory to use this version
of Python, assuming Python has been upgraded in-place.

Can you try making a version of the app that specifically uses e.g. Python 3.6, and try to upgrade it to Python 3.7? (But I would agree that if that’s the case, it is quite a cryptic error message)

Think that’s not the problem. The problem is that python3-venv package is missing…

Interesting, now i have the same error on my test VirtualBox YunoHost: https://paste.yunohost.org/raw/yoqoponafi

EDIT: Think pyinventory-ynh-deps_0.13.0~ynh1_all.deb doesn’t contain python3-venv … How can i generate the same .deb file or get this temporary .deb file?!?

That’s what I don’t understand: if you have listed the dependency in _common.sh and used the ynh_install_app_dependencies, it should be in there.

Maybe a debian package problem? And bullseye fix it?

With Bugfix CI run by jedie · Pull Request #90 · YunoHost-Apps/pyinventory_ynh · GitHub i merge the “setup venv” code and split it up with without-pip and ensurepip, e.g.:

python3 -m venv --without-pip "${final_path}/venv"
...
ynh_exec_as $app $final_path/venv/bin/python3 -m ensurepip

In the end, it shouldn’t make a difference.
Because of slow CI, i will see the result maybe tomorrow here:

stable seems not to be scheduled, yet: YunoRunner for CI

That’s the solution that worked: YunoRunner for CI

1 Like