swh-apps: Fix swh-loader-bzr application image build

It's currently broken [1] on the breezy deps [2].

[2]

...
11:21:45        ModuleNotFoundError: No module named 'configobj'
11:21:45        [end of output]
...
11:21:48  Failed to build breezy
11:21:48  ERROR: Could not build wheels for breezy, which is required to install pyproject.toml-based projects

[1] https://jenkins.softwareheritage.org/job/swh-apps/job/build-docker-image/72/console

mentioned in commit swh/infra/ci-cd/swh-charts@c17fda74

changed the description

Fix is in [1] (out of [2])

[1] https://gitlab.softwareheritage.org/swh/devel/swh-docs/-/blob/master/Makefile.local#L23-34

[2]

10:11 <+Lunar^>       ModuleNotFoundError: No module named 'configobj'
10:12 <+olasd> this happened before, but I don't remember if and how we fixed it
10:31 <+vlorentz> it's fixed in the dev build thanks to this: https://gitlab.softwareheritage.org/swh/devel/swh-docs/-/blob/master/Makefile.local#L23-34
10:32 <+swhbot> ^ Makefile.local · master · Platform / Development / swh-docs · GitLab
10:48 <+ardumont> thx, you probably gave me the fix for https://gitlab.softwareheritage.org/swh/infra/sysadm-environment/-/issues/4862
10:48 <+swhbot> ^ swh-apps: Fix swh-loader-bzr application image build (#4862) · Issues · Platform / Infrastructure / sysadm-environment · GitLab

Best task to solve are the ones that do not need work (for the one that is trying to solve it that is). (work actually happened directly at the swh.loader.bzr module/package level [3]).

The image builds for loader high priority and bzr are back to normal [1] [2]. Thanks to the work of @anlambert and @vlorentz [3]

[2] https://jenkins.softwareheritage.org/job/swh-apps/job/build-docker-image/78/console

[1] https://jenkins.softwareheritage.org/job/swh-apps/job/build-docker-image/79/console

[3]

14:44 <+anlambert> logs said "Collecting breezy<3.3.0 (from swh.loader.bzr)" but yes breezy is not pinned to <3.3.0 in bazaar loader requirements
14:46 <+vlorentz> ah, that's it
14:47 <+vlorentz> configobj was added to build-system.requires two days after the 3.3.0 release
14:49 <+anlambert> it seems swh.loader.bzr v1.3.2 vas retrieved from PyPI but I pushed the v1.3.3 on it this morning, I launched another doc publish build, it should work this time
15:09 <+anlambert> it worked, doc can be published again, the jenkins job was broken since 22 april
15:21 <+ardumont> great
15:21 <+ardumont> thx
15:23 <+Lunar^> thanks
15:23 <+ardumont> so, nothing to do downstream right, you fixed the swh.loader.bzr release so all swh.loader.bzr (which do stuff with breezy) should just work?
15:27 <+ardumont> one of the image build (which does more than one loader seem to agree)

closed

mentioned in commit swh/infra/ci-cd/swh-charts@d7ae3dde

mentioned in commit swh/infra/ci-cd/swh-charts@acb4af07

mentioned in commit swh/infra/ci-cd/swh-charts@6c960f73