Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to oldest supported distro releases #1

Merged
merged 1 commit into from
Jul 30, 2023

Conversation

genodeftest
Copy link
Member

Please note that this implicitly updates the oldest tested Python version to 3.8, so I adapted the comment.

Please note that this implicitly updates the oldest tested Python version to 3.8, so I adapted the comment.
@genodeftest
Copy link
Member Author

genodeftest commented Jun 16, 2023

Building all those three "new" versions worked fine for me (on my local machine).

I am aware that afterwards we need to update the following files in exaile/exaile:

and it would be nice to update the __future__ statements across the tree.

Copy link
Member

@sjohannes sjohannes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Actually I think we can safely go directly to Python 3.9, which is compatible with latest versions of the snail-pace OSes: RHEL, Ubuntu LTS, and Debian Stable.

For reference, these are the RHEL, Ubuntu, and Debian versions that are still supported, with their Python versions:

OS Python version
RHEL 7 cbf checking
RHEL 8 3.6
Ubuntu 20.04 (old LTS) 3.8
Debian bullseye (oldstable) 3.9
RHEL 9 (latest) 3.9
Ubuntu 22.04 (latest LTS) 3.10
Debian bookworm (stable) 3.11

@genodeftest
Copy link
Member Author

Looks good to me. Actually I think we can safely go directly to Python 3.9, which is compatible with latest versions of the snail-pace OSes: RHEL, Ubuntu LTS, and Debian Stable.

Would be fine for me too. This would mean updating Ubuntu to 22.04 immediately. Is this something we should discuss or would you feel fine with just doing it?

(People who are still on Ubuntu 20.04 will also not update Exaile, I guess)

@sjohannes
Copy link
Member

Hm, I suppose you could make a PR on exaile/DEPS and wait a bit to see if there are objections.

@genodeftest
Copy link
Member Author

I've started a poll in exaile/exaile#880 :)

@genodeftest
Copy link
Member Author

@sjohannes : Could you please merge this PR (I don't have write access)? I'd stay with 3.8 for now, respecting rokm's opinion in the poll. Feel free to modify to 3.9 though, I don't have strong feelings here :)

@sjohannes
Copy link
Member

Huh, interesting, the Developers group was missing write access to the repository. I've added it now.

@sjohannes sjohannes merged commit 61b1e03 into exaile:master Jul 30, 2023
@genodeftest genodeftest deleted the patch-1 branch July 30, 2023 13:44
@genodeftest
Copy link
Member Author

Thank you!

@sjohannes
Copy link
Member

Not sure why CI hasn't been running. Possibly caused by this change I made: 5a1e5d4

@genodeftest
Copy link
Member Author

genodeftest commented Jul 30, 2023

Note: I had to manually trigger the CI build under https://github.com/exaile/exaile-testimg2/actions/workflows/ci.yml using the Run workflow button. The CI hasn't run for a few months now although a cron job is configured.

Anyway, it is still missing the container tags on https://github.com/exaile/exaile-testimg2/pkgs/container/exaile-testimg/versions?filters%5Bversion_type%5D=tagged

Edit: The containers won't be pushed to the registry because it is configured to only be done on push or scheduled build, not on nightly build.

@genodeftest
Copy link
Member Author

Not sure why CI hasn't been running. Possibly caused by this change I made: 5a1e5d4

I don't think you broke it as the last runs were in February 2023, 2 months after your change.

@sjohannes
Copy link
Member

I don't think you broke it as the last runs were in February 2023, 2 months after your change.

GitHub stops running scheduled tasks if the repository hasn't been modified for some time, but I thought it was longer than 2 months. Pretty annoying.

The containers won't be pushed to the registry because it is configured to only be done on push or scheduled build, not on nightly build.

I've added the workflow_dispatch event to this so that manual runs also trigger the docker push. I don't know if there's a "merge" event or if that's also handled by push.

@genodeftest
Copy link
Member Author

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants