Am Mon, 06 Dec 2021 19:26:34 +0100 schrieb Christian Boltz :

If nobody objects, I'll delete the following packages in a week:

- protobuf (link to Factory) - python-six and python-six:test (outdated link to Factory) - python-urllib3 and python-urllib3:test (outdated link to Factory) - salt (outdated link to Factory, only build target is 15.2, and that is unresolvable)

No objections, just one informal addition from a quick Salt call in NUE: 1 SUSE Linux Enterprise Server 12 SP5 + forum.infra.opensuse.org 1 openSUSE Tumbleweed + gcc-stats.infra.opensuse.org 3 openSUSE Leap 15.2 + progress.infra.opensuse.org + lnt.infra.opensuse.org + mailman3.infra.opensuse.org 57 openSUSE Leap 15.3 + some minions (at least 2), that did not return, hrmpf. Provo and QSC machines are all 15.3.

hefur also doesn't have a build target anymore, but since it's a real package (and is probably still used on download.o.o), I won't delete it.

+1 Regards, Lars

Am Sun, 19 Dec 2021 00:05:31 +0100 schrieb Christian Boltz :

I also found some more cleanup candidates - this time, I propose to disable the build for everything newer than 15.3 (which technically means "disable build by default, and only enable it for the currently enabled repos").

Please leave Tumbleweed enabled per default: This allows to easily see breaking changes in Tumbleweed, which is the Leap-ng. I know that people don't like to update their systems (mailman3, anyone? ;-) - but this does not help, as we are enforced to stay on a maintained system. So - as soon as the next Leap (15.4) get's stable, we will migrate our systems. As I don't like to do the migration all at once, I would love to see in front, if a package fails during development - means: if a package fails in Tumbleweed. => Default enabled repos: * Tumbleweed * Leap-ng (as soon, as it exists) * Leap-current (15.3 atm) * Leap-maintained (15.2 until end of this year) => Rest only on demand. We could disable Leap-maintained as well, but I know that this will be too much work for some admins.

Packages that are exactly the same in openSUSE:infrastructure and Leap 15.3 according to "osc rdiff": - check_postgres - monitoring-plugins-bind9 - monitoring-plugins-count_file - monitoring-plugins-haproxy - monitoring-plugins-keepalived - monitoring-plugins-sar-perf

Hey, cool. This means that most of "my" packages ended in Leap :-) But if you disable/remove them, please keep in mind that you have to do a "migration" ("zypper dup" or an explicit "zypper install *")of these packages on the affected systems. Otherwise these packages will never see any update.

Packages with only minor differences between openSUSE:infrastructure and Leap 15.3: - nrpe (only diff is "/bin/bash" -> "/{usr/,}bin/bash" in the AppArmor profile - not relevant for Leap 15.x)

Fine with me to delete this as well.

I'll adjust the build targets of these packages in a week in nobody objects.

I'd say: salt might be our friend here, to get the local packages migrated to their Leap versions. Regards, Lars

Am Sun, 19 Dec 2021 17:29:43 +0100 schrieb Sasi Olin :

mailman3 is running Leap 15.3 since two days ago.

Hey, GREAT to hear! :-) Looks like I missed some announcement somewhere? hint: I started to add my "Infra-Changes" to the next meeting ticket, which - at least for me - helps me to remember when and what I did. I'm fine, if we agree on another practice (like news.o.o article or news on progress.o.o) but we should find a way to tell other admins what is happening. Regards, Lars

Hello, Am Sonntag, 19. Dezember 2021, 17:12:12 CET schrieb Lars Vogdt:

Am Sun, 19 Dec 2021 00:05:31 +0100 schrieb Christian Boltz:

...

I also found some more cleanup candidates - this time, I propose to disable the build for everything newer than 15.3 (which technically means "disable build by default, and only enable it for the currently enabled repos").

Please leave Tumbleweed enabled per default: This allows to easily see breaking changes in Tumbleweed, which is the Leap-ng. I know that people don't like to update their systems (mailman3, anyone? ;-) - but this does not help, as we are enforced to stay on a maintained system. So - as soon as the next Leap (15.4) get's stable, we will migrate our systems. As I don't like to do the migration all at once, I would love to see in front, if a package fails during development - means: if a package fails in Tumbleweed.

Seems I missed to mention a "detail" in my proposal - I want to disable the build for Tumbleweed and >= 15.4 __only for the packages listed in my mail__. [Note: This mail has an updated list, scroll down.] Does that sound better to you? For the other packages (especially those that are not in Tumbleweed or Leap), it makes sense to keep the build enabled as you proposed:

=> Default enabled repos: * Tumbleweed * Leap-ng (as soon, as it exists)

FYI: 15.4 is already in OBS, so... ;-) (but please wait with adding it to the infra repo until I finished the cleanup)

* Leap-current (15.3 atm) * Leap-maintained (15.2 until end of this year)

=> Rest only on demand. We could disable Leap-maintained as well, but I know that this will be too much work for some admins.

Agreed.

...

Packages that are exactly the same in openSUSE:infrastructure and Leap 15.3 according to "osc rdiff": - check_postgres - monitoring-plugins-bind9 - monitoring-plugins-count_file - monitoring-plugins-haproxy - monitoring-plugins-keepalived - monitoring-plugins-sar-perf

Hey, cool. This means that most of "my" packages ended in Leap :-)

:-)

But if you disable/remove them, please keep in mind that you have to do a "migration" ("zypper dup" or an explicit "zypper install *")of these packages on the affected systems. Otherwise these packages will never see any update.

I know, and that's why I'd keep them enabled for 15.3 and older so that we don't accidently" lock" these packages. When we zypper dup to 15.4, zypper should in theory ask for a vendor change.

...

Packages with only minor differences between openSUSE:infrastructure and Leap 15.3: - nrpe (only diff is "/bin/bash" -> "/{usr/,}bin/bash" in the AppArmor profile - not relevant for Leap 15.x)

Fine with me to delete this as well.

...

I'll adjust the build targets of these packages in a week in nobody objects.

I'd say: salt might be our friend here, to get the local packages migrated to their Leap versions.

Might also be an option, but it's more work than keeping 15.3 enabled and doing the vendor change when dup'ing to 15.4. BTW: There are some more packages that are in 15.3, but in an older version (and in some cases, it's the same version, but with less patches). I won't complain if someone pushes those packages to 15.4 so that we don't have to keep them in the infra repo. Which reminds me - I should run my script[1] again to compare 15.4 with the infra repo to see if some of them were already pushed ;-) Packages that are the same in Leap 15.4 and the infra repo (a few more than in the 15.3 vs. infra comparison): - apache2-mod_maxminddb - check_postgres - coturn - meson - monitoring-plugins-bind9 - monitoring-plugins-count_file - monitoring-plugins-haproxy - monitoring-plugins-keepalived - monitoring-plugins-sar-perf Packages with minor differences to Leap 15.4 that are not relevant for / not needed in the infrastructure repo: - nrpe (AppArmor profile change for /usr/bin/bash, see my previous mail) - nagios-rpm-macros (unbreak build for SLE 12 and RHEL 7, move macros.nagios to _rpmmacrodir) Any objections to disabling the build of these packages for >=15.4 and Tumbleweed? (We'll switch to the "official" packages on zypper dup.) Also, I'd say that we can/should disable the build for Tumbleweed for all packages that are linkpac'ed to openSUSE:Factory (because we get exactly the same package and only waste build power). Any objections? (I don't have a package list for that yet, and will probably have to check all linked packages manually. I'll send a report with the package list after doing the cleanup. Regards, Christian Boltz [1] what a big word for a few lines ;-) - but nevertheless, if someone is interested, I can share the script. -- Die erprobte Strategie der Managementmotivation im Operating [ist] eine, die ich gerne mit "Teile die Schmerzen" beschrieben möchte. Zum Beispiel setzt man den Projekteigentümer auf dieselbe Alerting-Methode wie den Sysadmin, der am Ende Sonntag nachts um 4 Uhr wegen eines Alarms die vorbeugende Wartung durchführen muß. [...] Wenn wir nun also einen jungen Projektverantwortlichen haben, bei dem das Handy Sonntag nachts um vier die Frau und das 6 Monate alte Kind weckt, dann ist diese Person nach einigen Wochen unmittelbaren Alerting-Erlebens sehr viel zugäng- licher. [http://blog.koehntopp.de/archives/2859-Wieso-zehn-Prozent.html]