On 15/02/2024 14.31, Larry Len Rainey wrote:
Getting this today (repo list at bottom)
zypper dup
'apparmor-docs-3.1.7-1.1.noarch.rpm' [/var/tmp/AP_0xi8dYFp/noarch/apparmor-docs-3.1.7-1.1.noarch.rpm]
expected afe4d69e9749e1798412c520c01b266856af22bf8a9f3342c33368dd224e1b0b9f3b24f5c330de85290e2db31b8ab083466fe6363a06e8bf0aa519f13884feae but got 33c05a3a7c0232392229d52abdd78d7d1106fb4eb312e820731f67747b9e2d89253ec3a941bf7169b6ec29fe92d64355b10296b94a9b7f26ee1760dfa1baa7cf
This is fallout from the version bump when packages got replaced with a different version under the same name. It is still a ToDo to get OBS to create proper numbering e.g. fix https://github.com/openSUSE/open-build-service/issues/15079 I hope, it will settle over the next hours as mirrors rsync the new version and download.o.o re-scans these. I also told the download-redirector to re-scan now, in case that helps. Ciao Bernhard M.
On Donnerstag, 15. Februar 2024, 17:13:13 CET Bernhard M. Wiedemann via openSUSE Factory wrote:
On 15/02/2024 14.31, Larry Len Rainey wrote:
Getting this today (repo list at bottom)
zypper dup
'apparmor-docs-3.1.7-1.1.noarch.rpm' [/var/tmp/AP_0xi8dYFp/noarch/apparmor-docs-3.1.7-1.1.noarch.rpm]
expected afe4d69e9749e1798412c520c01b266856af22bf8a9f3342c33368dd224e1b0b9f3b24f5c330de85290e2db31b8ab083466fe6363a06e8bf0aa519f13884feae but got 33c05a3a7c0232392229d52abdd78d7d1106fb4eb312e820731f67747b9e2d89253ec3a941bf7169b6ec29fe92d64355b10296b94a9b7f26ee1760dfa1baa7cf
This is fallout from the version bump when packages got replaced with a different version under the same name. It is still a ToDo to get OBS to create proper numbering e.g. fix https://github.com/openSUSE/open-build-service/issues/15079
erm, even when you always have the same revision number for the checkin counter, you should still have a different build counter. Are you sure that this is not a different issue here? -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
On Feb 28 2024, Adrian Schröter wrote:
On Donnerstag, 15. Februar 2024, 17:13:13 CET Bernhard M. Wiedemann via openSUSE Factory wrote:
On 15/02/2024 14.31, Larry Len Rainey wrote:
Getting this today (repo list at bottom)
zypper dup
'apparmor-docs-3.1.7-1.1.noarch.rpm' [/var/tmp/AP_0xi8dYFp/noarch/apparmor-docs-3.1.7-1.1.noarch.rpm]
expected afe4d69e9749e1798412c520c01b266856af22bf8a9f3342c33368dd224e1b0b9f3b24f5c330de85290e2db31b8ab083466fe6363a06e8bf0aa519f13884feae but got 33c05a3a7c0232392229d52abdd78d7d1106fb4eb312e820731f67747b9e2d89253ec3a941bf7169b6ec29fe92d64355b10296b94a9b7f26ee1760dfa1baa7cf
This is fallout from the version bump when packages got replaced with a different version under the same name. It is still a ToDo to get OBS to create proper numbering e.g. fix https://github.com/openSUSE/open-build-service/issues/15079
erm, even when you always have the same revision number for the checkin counter, you should still have a different build counter.
Are you sure that this is not a different issue here?
It can also happen when a noarch (sub-)package is republished, but from a build by a different architecture. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Mittwoch, 28. Februar 2024, 17:32:21 CET Andreas Schwab wrote:
On Feb 28 2024, Adrian Schröter wrote:
On Donnerstag, 15. Februar 2024, 17:13:13 CET Bernhard M. Wiedemann via openSUSE Factory wrote:
On 15/02/2024 14.31, Larry Len Rainey wrote:
Getting this today (repo list at bottom)
zypper dup
'apparmor-docs-3.1.7-1.1.noarch.rpm' [/var/tmp/AP_0xi8dYFp/noarch/apparmor-docs-3.1.7-1.1.noarch.rpm]
expected afe4d69e9749e1798412c520c01b266856af22bf8a9f3342c33368dd224e1b0b9f3b24f5c330de85290e2db31b8ab083466fe6363a06e8bf0aa519f13884feae but got 33c05a3a7c0232392229d52abdd78d7d1106fb4eb312e820731f67747b9e2d89253ec3a941bf7169b6ec29fe92d64355b10296b94a9b7f26ee1760dfa1baa7cf
This is fallout from the version bump when packages got replaced with a different version under the same name. It is still a ToDo to get OBS to create proper numbering e.g. fix https://github.com/openSUSE/open-build-service/issues/15079
erm, even when you always have the same revision number for the checkin counter, you should still have a different build counter.
Are you sure that this is not a different issue here?
It can also happen when a noarch (sub-)package is republished, but from a build by a different architecture.
yes, but the publisher is usually taking care of this and does not switch it. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
On Mittwoch, 28. Februar 2024, 17:39:31 CET Adrian Schröter wrote:
On Mittwoch, 28. Februar 2024, 17:32:21 CET Andreas Schwab wrote:
On Feb 28 2024, Adrian Schröter wrote:
On Donnerstag, 15. Februar 2024, 17:13:13 CET Bernhard M. Wiedemann via openSUSE Factory wrote:
On 15/02/2024 14.31, Larry Len Rainey wrote:
Getting this today (repo list at bottom)
zypper dup
'apparmor-docs-3.1.7-1.1.noarch.rpm' [/var/tmp/AP_0xi8dYFp/noarch/apparmor-docs-3.1.7-1.1.noarch.rpm]
expected afe4d69e9749e1798412c520c01b266856af22bf8a9f3342c33368dd224e1b0b9f3b24f5c330de85290e2db31b8ab083466fe6363a06e8bf0aa519f13884feae but got 33c05a3a7c0232392229d52abdd78d7d1106fb4eb312e820731f67747b9e2d89253ec3a941bf7169b6ec29fe92d64355b10296b94a9b7f26ee1760dfa1baa7cf
This is fallout from the version bump when packages got replaced with a different version under the same name. It is still a ToDo to get OBS to create proper numbering e.g. fix https://github.com/openSUSE/open-build-service/issues/15079
erm, even when you always have the same revision number for the checkin counter, you should still have a different build counter.
Are you sure that this is not a different issue here?
It can also happen when a noarch (sub-)package is republished, but from a build by a different architecture.
yes, but the publisher is usually taking care of this and does not switch it.
wipebinaries calls can lead to such problems though, since there is no former binary anymore. Do you run these? -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
On 28/02/2024 17.09, Adrian Schröter wrote:
erm, even when you always have the same revision number for the checkin counter, you should still have a different build counter.
Are you sure that this is not a different issue here?
here it comes from https://github.com/openSUSE/open-build-service/issues/15079 because I branch a fixed (TW) revision from Factory it gets reset to 1.1 that can subsequently get released as Slowroll update and at the time of version bump, I sync latest Factory packages where I need to keep the i586 part to keep Mesa-32bit and wine-32bit building. I also delete some packages and re-branch on next update - that could also cause a re-use of checkin+rebuild counters. Ciao Bernhard M.
On Mittwoch, 28. Februar 2024, 20:25:19 CET Bernhard M. Wiedemann wrote:
On 28/02/2024 17.09, Adrian Schröter wrote:
erm, even when you always have the same revision number for the checkin counter, you should still have a different build counter.
Are you sure that this is not a different issue here?
here it comes from https://github.com/openSUSE/open-build-service/issues/15079
because I branch a fixed (TW) revision from Factory it gets reset to 1.1
it gets set to CI_CNT 1. But the build counter should still increase when you rebuild a package which had same version-CI_CNT before. So, yes, it is a CI_CNT downgrade, but still does not explain why you have build results with same name.
that can subsequently get released as Slowroll update and at the time of version bump, I sync latest Factory packages where I need to keep the i586 part to keep Mesa-32bit and wine-32bit building.
I also delete some packages and re-branch on next update - that could also cause a re-use of checkin+rebuild counters.
Yes, this can cause it. When removing the history it is really lost. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
participants (4)
-
Adrian Schröter -
Andreas Schwab -
Bernhard M. Wiedemann -
Larry Len Rainey