The golang-sssd docker image installs golang-go from stretch-backports.

A quick codesearch through puppet finds:

modules/profile/manifests/toolforge/grid/exec_environ.pp
377
378        apt::pin { $nodejs_packages:
379            pin      => 'release a=stretch-backports',
380            priority => '2000',
381            before   => Package['nodejs'],
...
391            ]:
392            ensure          => latest,
393            install_options => ['-t', 'stretch-backports'],
394        }
395
396        # T67354, T215693 - Tesseract OCR from stretch-backports
397        $tesseract_packages = [
398            'tesseract-ocr-all',
...
406        }
407
408        # T248376 - {python,python3}-requests from stretch-backports
409        $requests_packages = [
410            'python-requests',
412        ]
413        apt::pin { $requests_packages:
414            pin      => 'release a=stretch-backports',
415            priority => '2000',
416            before   => Package[$requests_packages],
418        package { $requests_packages:
419            ensure          => latest,
420            install_options => ['-t', 'stretch-backports'],
421        }
422

Didn't we replace tesseract with a newly packaged and compiled version, @aborrero? If we did, maybe that comment or something else needs to be removed?

In T256881#6273177, @Bstorm wrote:

Didn't we replace tesseract with a newly packaged and compiled version, @aborrero? If we did, maybe that comment or something else needs to be removed?

Yes, it's coming from the component/tesseract-410-bpo component. I'll submit a patch to update the comment.

Change 608966 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[operations/puppet@production] toolforge: Update comment reflecting source of tesseract packages

https://gerrit.wikimedia.org/r/c/operations/puppet/ /608966

@MoritzMuehlenhoff and I just discovered we need systemd >= 239 (from stretch-bpo) for Toolforge bastions for the resource limiting thing.

In T256881#6273177, @Bstorm wrote:

Didn't we replace tesseract with a newly packaged and compiled version, @aborrero? If we did, maybe that comment or something else needs to be removed?

This is true!

In T256881#6273209, @Legoktm wrote:

Yes, it's coming from the component/tesseract-410-bpo component. I'll submit a patch to update the comment.

Thanks for the patch! :-)

In T256881#6273949, @aborrero wrote:

@MoritzMuehlenhoff and I just discovered we need systemd >= 239 (from stretch-bpo) for Toolforge bastions for the resource limiting thing.

Ugh, I'd forgotten that. The version of SGE in buster is the same as in stretch, so upgrading would work if that wouldn't also suddenly upgrade the bastion's exec environment as well.

Change 608966 merged by Bstorm:
[operations/puppet@production] toolforge: Update comment reflecting source of tesseract packages

https://gerrit.wikimedia.org/r/c/operations/puppet/ /608966

In T256881#6274887, @Bstorm wrote:

In T256881#6273949, @aborrero wrote:

@MoritzMuehlenhoff and I just discovered we need systemd >= 239 (from stretch-bpo) for Toolforge bastions for the resource limiting thing.

Ugh, I'd forgotten that. The version of SGE in buster is the same as in stretch, so upgrading would work if that wouldn't also suddenly upgrade the bastion's exec environment as well.

I've imported the current systemd version from stretch-backports (except the udebs, but those are irrelevant and only used for the Debian installer) into the component/systemd241. Could anyone check that these are fine with an existing Toolforge instance?

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

In T256881#6276936, @MoritzMuehlenhoff wrote:

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

I will investigate a bit more about these. They are dependencies of the openstack suite, so it would make sense to have them in the osbpo repository.

===== NODE GROUP =====                                                                                   
(22) cloudvirt[1001-1003,1005,1007-1009,1012-1014,1017-1021,1023,1025-1030].eqiad.wmnet                  
----- OUTPUT of 'aptitude why librados2' -----                                                           
i   nova-common  Depends python3-nova (= 2:18.1.0-6+deb10u1~bpo9+1)                                      
i A python3-nova Depends python3-ceph                                                                    
i A python3-ceph Depends python3-rgw                               
i A python3-rgw  Depends librados2 (>= 0.72.2)

Change 610121 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Remove stretch-backports from bootstrapvz config

https://gerrit.wikimedia.org/r/610121

Change 612612 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Stop including backports on Stretch production hosts

https://gerrit.wikimedia.org/r/612612

Change 613611 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Disable backports on stretch

https://gerrit.wikimedia.org/r/613611

Change 612612 abandoned by Muehlenhoff:
[operations/puppet@production] Stop including backports on Stretch production hosts

Reason:
Not going to bother with the spec mess

https://gerrit.wikimedia.org/r/612612

In T256881#6282184, @aborrero wrote:

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

I will investigate a bit more about these. They are dependencies of the openstack suite, so it would make sense to have them in the osbpo repository.

Did you hear back from the osbpo people? Otherwise let's copy these to something like component/ceph and include it in the openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch classes? These are the last remaining packages, otherwise https://gerrit.wikimedia.org/r/c/operations/puppet/+/613611 would be good to merge

In T256881#6328603, @MoritzMuehlenhoff wrote:

In T256881#6282184, @aborrero wrote:

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

I will investigate a bit more about these. They are dependencies of the openstack suite, so it would make sense to have them in the osbpo repository.

Did you hear back from the osbpo people? Otherwise let's copy these to something like component/ceph and include it in the openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch classes? These are the last remaining packages, otherwise https://gerrit.wikimedia.org/r/c/operations/puppet/+/613611 would be good to merge

Their suggestion was to mirror the stretch-backports repo and therefore workaround the archival :-P

This is all a bit annoying. I was very happy about no longer using components in our internal repo and not having to babysit packages.

I cannot currently build new tools-sgeexec nodes because of dependency hell related to the tesseract-ocr package:

The following packages have unmet dependencies:
libtesseract4 : Depends: liblept5 (>= 1.75.3) but 1.74.1-1 is to be installed
E: Unable to correct problems, you have held broken packages.

is this breakage related to this task?

In T256881#6400692, @Andrew wrote:

I cannot currently build new tools-sgeexec nodes because of dependency hell related to the tesseract-ocr package:

The following packages have unmet dependencies:
libtesseract4 : Depends: liblept5 (>= 1.75.3) but 1.74.1-1 is to be installed
E: Unable to correct problems, you have held broken packages.

is this breakage related to this task?

That seems possible. See also T247422: Update Tesseract on Toolforge to v4.1.0 for other Tesseract related things that might be complicating it.

moving this again to doing. Will try to take a final look this week.

Change 613611 merged by Muehlenhoff:
[operations/puppet@production] Disable backports on stretch for production

https://gerrit.wikimedia.org/r/613611

FYI, stretch-backports is now removed from production servers, the Puppet code for Toolforge has been moved to modules/profile/manifests/wmcs/instance.pp as an interim.

Change 610121 merged by Muehlenhoff:
[operations/puppet@production] Remove stretch-backports from bootstrapvz config

https://gerrit.wikimedia.org/r/610121