Hello, openSUSE:infrastructure contains some packages that don't have a build target anymore. (This typically means they were enabled only for older distributions like Leap 42.3.) 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) 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. Regards, Christian Boltz -- Der geistige Horizont ist der Abstand zwischen Brett und Kopf.
Am Mon, 06 Dec 2021 19:26:34 +0100 schrieb Christian Boltz <opensuse@cboltz.de>:
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
Hello, Am Mittwoch, 8. Dezember 2021, 15:47:18 CET schrieb Lars Vogdt:
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)
As promised, I just deleted these packages.
No objections, just one informal addition from a quick Salt call in NUE: 1 SUSE Linux Enterprise Server 12 SP5 + forum.infra.opensuse.org
Also community.i.o.o - which nowadays only hosts two websites that can probably be moved to other existing VMs. 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"). Visible changes will be: - no longer build these packages for Tumbleweed - don't build these packages for build targets we add in the future, for example 15.4. 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 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) I'll adjust the build targets of these packages in a week in nobody objects. Regards, Christian Boltz -- <dragotin> where is that lazy chicken btw? <suseROCKs> Ouch! <dragotin> oh - code of conduct violated? <dragotin> "It is not allowed to call henne a lazy chicken!" <suseROCKs> revised last week: It is required to call him that [from #opensuse-project]
Am Sun, 19 Dec 2021 00:05:31 +0100 schrieb Christian Boltz <opensuse@cboltz.de>:
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 19. Dezember 2021 17:12:12 MEZ schrieb Lars Vogdt <lars@linux-schulserver.de>:
Am Sun, 19 Dec 2021 00:05:31 +0100 schrieb Christian Boltz <opensuse@cboltz.de>:
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.
mailman3 is running Leap 15.3 since two days ago. LCP [Sasi] https://lcp.world/
Am Sun, 19 Dec 2021 17:29:43 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
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
On Sun, Dec 19 2021 at 05:40:27 PM +0100, Lars Vogdt <lars@linux-schulserver.de> wrote:
Am Sun, 19 Dec 2021 17:29:43 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
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.
Yeah, sorry, I just did this as a part of a fix to the mailing list archives that stopped working, not really announcing anywhere. It was quicker to dup to Leap 15.3 than to wait for 15.2 build to finish, so I just went for it. LCP [Sasi] https://lcp.world/
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]
Hello, happy new year! Am Sonntag, 19. Dezember 2021, 20:00:31 CET schrieb Christian Boltz: [...]
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
As promised last year ;-) I just disabled the build of these packages for future releases (and Tumbleweed), so that we can get rid of them long-term in the infrastructure repo. I kept them enabled for 15.3 and and older so that we don't need to actively vendor-change them on all VMs now.
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)
This package is a bit more interesting[tm] than I thought. After looking at 15.3 again, I noticed that it has /bin/bash -> /usr/bin/bash. For now I didn't disable that package to avoid breakage (but I disabled the Tumbleweed build, see below). However, that also means that the AppArmor profile shipped in the official 15.3 and 15.4 package will break nrpe. I took the liberty to submit SR 943430 ;-) (Lars, as one of the package maintainers, you'll probably need to review it.) When that SR is accepted, I'll disable the build for future Leap releases.
- nagios-rpm-macros (unbreak build for SLE 12 and RHEL 7, move macros.nagios to _rpmmacrodir)
Nothing done for this package because it one was already disabled for 15.3 in a previous cleanup round - something my script didn't look at ;-)
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.
Also done. I disabled the Tumbleweed build for the following packages that are linkpac'ed to Factory (those marked with * via their devel project): - clamav - dehydrated - libmaxminddb - mailgraph * - monitoring-plugins-mailstat * - nrpe * - perl-JSON-Parse * - python-FormEncode - python-limnoria * - python-maxminddb - python-requests I also did a osc wipebinaries --build-disabled -r openSUSE_Tumbleweed openSUSE:infrastructure to avoid keeping soon-outdated RPMs. (This also means we should do a zypper dup --allow-vendor-change on the few Tumbleweed VMs we have.) There's also an "interesting" case - python-geoip2 is linkpac'ed to Factory, but to an old version. Additionally, the build is disabled for all repos. If nobody objects, I'll delete the package from the infrastructure repo. Regards, Christian Boltz --
Gruß, Ratti (Der sich jetzt noch ein Brötchen mit Hack holt. Fleisch-Essen ruleZ :-) ) Hey, froehnst Du der Fleischeslust, Du Ratte? :-) [> Ratti und Jessica Bleche in suse-linux]
participants (3)
-
Christian Boltz -
Lars Vogdt -
Sasi Olin