https://tools.wmflabs.org/apt-browser/stretch-wikimedia/component/pyall/
@faidon, could you add Python 3.8 so we can begin using it in CI?
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| aptrepo: Add thirdparty/pyall component for buster-wikimedia | operations/puppet | production | +52 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdforrester-WMF | T270389 Enable Pywikibot fasttest with Python 3.8 / Python 3.9 | |||
| Resolved | Jdforrester-WMF | T268850 Provide python 3.8 in CI test images | |||
| Resolved | Legoktm | T241195 Add python3.8 to buster-wikimedia pyall component |
Event Timeline
Comment Actions
- The canonical location is nowadays https://people.debian.org/~paravoid/python-all/ (which I maintain on my free time). We (Wikimedia) probably should set up a reprepro import for that.
- The above repository has 3.8.0 beta4 for buster, I'll need to update that for a more recent version (currently looks like 3.8.1). I can do so soon-ish.
- That said, I don't have any intentions to backport 3.8 to stretch.
Comment Actions
I've updated the aforementioned apt repository with 3.8.1-2~buster1 packages Someone in SRE that's more familiar with how we do things these days (maybe @MoritzMuehlenhoff?) can update our reprepro to include that.
(As I said above, the cost/benefit tradeoff for a stretch backport is not one that makes the endeavour worth it IMHO, so I have no intentions of working on that right now)
Comment Actions
Ack, I'll take care of that.
(As I said above, the cost/benefit tradeoff for a stretch backport is not one that makes the endeavour worth it IMHO, so I have no intentions of working on that right now)
Could not agree more :-)
Comment Actions
Seems reasonable. Retitled the task accordingly. For CI purposes if someone wants to run tests against 3.4 & 3.8 we can just use both stretch and buster.
Comment Actions
Anything I/CI team can help with?
If it's not straightfoward, can we just add the python-all repo directly into the CI images, given the maintainer is extremely trusted? :)
Comment Actions
Hi, just adding to this ticket here as I have a CI job failing that would be alleviated by fixing this issue (by specifying Python 3.8 as the interpreter): https://integration.wikimedia.org/ci/job/tox-docker/15602/console.
Please note that this is not a "please fix this because my thing is broken!" request but an additional source of input that having this would be nice :)
Comment Actions
Change 650010 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[operations/puppet@production] aptrepo: Add thirdparty/pyall component for buster-wikimedia
Comment Actions
Change 650010 merged by Legoktm:
[operations/puppet@production] aptrepo: Add thirdparty/pyall component for buster-wikimedia
Comment Actions
Mentioned in SAL (#wikimedia-operations) [2020-12-21T21:42:04Z] <legoktm> manually imported debs to buster-wikimedia thirdparty/pyall component (T241195)
Comment Actions
During the import I ran into:
Moritz said this has happened with Jenkins before, and it seems like something that might need to be fixed by @faidon on his side depending on what software he used to generate the apt repo.
In any case, I used apt to manually download all the debs and imported them by hand. Thanks to Moritz for helping me through this :)
Python 3.5, 3.6 and 3.8 are now available from thirdparty/pyall for buster.