Re: multiple infrastructure issues / support bottlenecks

[Ben Sturmfels]

Hi Peter,

Peter Horvath <horvath.akos.peter@gmail.com> writes:

> 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 :-)

Great, if you're serious about offering to help here, that would be much
appreciated. I'll be in touch privately to arrange access for you to
take a look. Essentially we'd be aiming to move Trac out of
docker-compose to be running directly on a virtual machine. There's a
lot of history in Trac, so it's useful to keep it around. We will need
to make it obviously that new issues should go in sourcehut though. The
"bug tracker" and "bug tracker (legacy)" links on the website imply
this, but it's not obvious if you visit them directly.

> 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".

Thanks, these all sound like useful contributions and sorry again for
the delay in reviewing them. I'll take a look likely after the
Christmas/New Year period and respond to you.

> (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.)

The docker-compose approach was set up before I came on as maintainer,
but I'm sure it made sense at the time. With hindsight, I think Trac
will be simpler to maintain going forward if it's running directly on
the virtual machine.

Regards,
Ben