Hi,
Thank you very much the quick reaction. I believe, having two parallel bugtracks is probably the worst among all possible options. If I get an access to the host of the trac, I could likely fix it, but no prob if I do not get it as an anonym internet user :-)
So the current reality is that the new bugtrack works and the old does not, so I suggest to track the new one.
I collected some minor but important changes, in various merge requests now. That is 5 changes. These were required for me to make the project compilable as it was written in the project front page docs. All of them are in my gitlab project repo:
https://gitlab.com/peter.horvath/mediagoblin
The brances prefixed with "mr/" (merge request) are those I would suggest to include. Their details:
* mr/bcrypt-python310-compilability
Newer pythons have no more some collection classes imported by the used (and quite old) celery version. My experiments showed, at least celery >= 4.3 is needed. Unfortunately, comment says that there no more sqlite transport alias exists, which make tests fail. Suggestion: first, make the project compatible with recent celery, second, fix the test cases :-) Beside that, some newer libraries (particularly, rust-related depencies or the bcrypt) are needed.
* mr/bugfix/12-autoconf That is the issue #12 in the sourcehut bugtraq. The gnu autoconf needed a minor tuning, it does not love embedded IF-s any more, but has a better nearly-equivalent syntax. Without that, the bootstrap.sh-based deployment, as written in the project tutorial, won't work.
* mr/gitignore-fix After a successful build, many intermediate files appear as new sources. Normally these should be covered by a gitignore (so that a "git clean" should be able to recover the prune source tree), I imporoved the gitignore to handle them.
* mr/no-system-pip That is a matter of taste. I suggest to not use and to not expect system pips. I think, being independent from the possible build systems (containers) would worth more than not needing to install trivial python libs (likely lxml).
* mr/pipinst The compilation with python setup.py does not really work and it is very unstable. Python loves today much more "pip install". This patch changes the Makefile.in to do a "pip install" instead of "python setup".
Kindly regards,
Peter
(P.s. I think it is very likely that you never needed docker to host your bugtrack. Docker promises a lot but actually it is just a chroot. Running demons in chroot is a big pain.)