maxking
Can a new minor release be tagged soon?
Would be nice to take advantage of new postorius and some of the fixes etc added since oct.
I believe it would be best to parametrise and automate image builds in CI (here), in so new releases and builds become more easy.
It would be nice to have a new release soon as the libldap library is still missing.
2331cb3 was already merged but is not yet in the latest tag.
Thank you in advance.
This is also mildly concerning, as it is one of the publicly announced installation methods.
It used to be the only installation method in the beginning, why many installations may depend on this setup to be supported already.
In case the project has fallen out of support, it could be good to coordinate here about putting the repository into shared maintainership at an independent GitHub organisation, or with upstream about a soft-fork, say continuation, of the repository and adopting it into gitlab.com/mailman/.
The forks could be synced, in so the old image names and CI setups for image builds can be continued to be used.
I haven't had a chance to fix the CI yet, which is broken for some reason and need to take a look at it. If someone can help debug and propose required changes for the CI to pass, I can maybe cut a release this weekend.
I believe it would be best to parametrise and automate image builds in CI (here), in so new releases and builds become more easy.
It mostly is automated, there is not much to do except make a release with a tag.
say continuation, of the repository and adopting it into gitlab.com/mailman/.
I don't expect rest of the Mailman developers to worry about packaging as well. I don't know if "first" in the list really has a lot of insinuation but that definitely wasn't the intent. Mailman developers really only support virtualenv style install, for anything else, you want to the packaging team's help.
Can you give some detail on what is currently broken and how the images are usually being built?
I hadn't seen a previous issue about missing builds, but now that you mention it and given the previous failed runs, it appears this is broken for many months now?
Can be good for everyone to find an issue in the future, in case they are not aware themselves, so the community can look at it together.
Am I correct in assuming, that we are talking about the cron-builds pipelines in CircleCI?
- https://app.circleci.com/pipelines/github/maxking/docker-mailman?branch=main
- https://app.circleci.com/pipelines/github/maxking/docker-mailman/2171/workflows/e6a52639-df38-4eea-be4d-6a1ed8f5ab49/jobs/4109
- https://app.circleci.com/pipelines/github/maxking/docker-mailman/2171/workflows/e6a52639-df38-4eea-be4d-6a1ed8f5ab49/jobs/4109/parallel-runs/0/steps/0-106
From looking at the logs of the last job, it seems there is an issue with not being able to import utc.
ImportError: cannot import name 'utc' from 'django.utils.timezone' (/usr/lib/python3.11/site-packages/django/utils/timezone.py)
Maybe it's really just a packaging or rather an upstream issue?
It's these two lines in HyperKitty:
- https://gitlab.com/search?group_id=124427&scope=blobs&search=from+django.utils.timezone+import+now%2C+utc
This may have broken with upgrading to Django 5, where utc is depreciated.
From the Django 5.0 release notes | Django documentation | Django:
The django.utils.timezone.utc alias to datetime.timezone.utc is removed.
This line seems to allow Django versions larger than v4, including v5
- https://gitlab.com/mailman/hyperkitty/-/blob/master/pyproject.toml#L25
The build chooses Django 5:
- https://app.circleci.com/pipelines/github/maxking/docker-mailman/2171/workflows/e6a52639-df38-4eea-be4d-6a1ed8f5ab49/jobs/4109/parallel-runs/0/steps/0-104?invite=true#step-104-91494_71
Therefore it's an upstream issue at HyperKitty.
There are other open issues regarding time zone handling:
- https://gitlab.com/mailman/hyperkitty/-/issues/505
I have filed a new issue:
- https://gitlab.com/mailman/hyperkitty/-/issues/509
Until this is resolved, we could enforce a specific Django version by either patching the requirements file during the build, or by installing any other Django version lower than v5 that satisfies the version requirement.
I had to bump the release minor version instead of patch this time since we bumped min required postgres version and last time it had caused issues with some folks when jumping from 9.6 to 11.
https://github.com/maxking/docker-mailman/releases/tag/v0.5.0
btw, thanks @almereyda for taking out time to file issues with upstream Mailman. I'll take a look at those.
I didn't do anything, but thanks. It was @maxking who helped above with pointing at the CircleCI infrastructure. Apparently the errors have been going on and were known for a while, but seemingly noone ever took the courage to just have a look?
It's a good reminder to all of us to raise observations as issues or to leave comments in existing ones, when we become aware of them.
Can we release a new version soon?
There was an important change to include ldap library .
https://github.com/maxking/docker-mailman/issues/703
Thank you in advance, Thomas
p.s. Do we need a new issue for this or can we just reopen it?
I can push a release out, i need to get django-mailman 1.3.15 out first since that's causing CI to fail for dev containers. Working on both releases today.