[opensuse-buildservice] Repository publishing broken on b.o.o ?
Hi, I recently noticed some strange discrepancy of the downloadable packages that were created after building: The size/checksum of the rpm file on download.opensuse.org does not match the metadata that is recorded in the repository's primary.xml.gz E.g: When downloading https://download.opensuse.org/repositories/home:/felfert/Fedora_29/x86_64/eh... The resulting size is 622240 bytes and the sha256sum is eb77ce147162cd3ab9a997e31b865b3e22f7457327f12eac202e6b54210a4547 However in the corresponding https://download.opensuse.org/repositories/home:/felfert/Fedora_29/repodata/... The size is recorded as 622248 and the sha256 as 11524992b6ca3bc8f2bc0b7f82c0c3875c1c9ca3f87e8b9072cce2bff2331466 Obviously, dnf complains when attempting to install or update the package. I rebuilt the affected packages, but this did not help. Any clues? Thanks -Fritz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mittwoch, 24. Juli 2019, 11:14:45 CEST Fritz Elfert wrote:
Hi,
I recently noticed some strange discrepancy of the downloadable packages that were created after building:
The size/checksum of the rpm file on download.opensuse.org does not match the metadata that is recorded in the repository's primary.xml.gz
E.g:
When downloading https://download.opensuse.org/repositories/home:/felfert/Fedora_29/x86_64/eh s-devel-1.5.1-173.fc29.x86_64.rpm
The resulting size is 622240 bytes and the sha256sum is eb77ce147162cd3ab9a997e31b865b3e22f7457327f12eac202e6b54210a4547
However in the corresponding https://download.opensuse.org/repositories/home:/felfert/Fedora_29/repodata/ 064d3aa4fe373fa91f0edbfcc22328585f5bb381f3661b3d951accaa12baaf22-primary.xml .gz
most likely a mirror is broken. Check with curl or wget from where it comes really and report it to admin@opensuse.org please. (since the download infrastructure is not part of OBS). thanks adrian
The size is recorded as 622248 and the sha256 as 11524992b6ca3bc8f2bc0b7f82c0c3875c1c9ca3f87e8b9072cce2bff2331466
Obviously, dnf complains when attempting to install or update the package. I rebuilt the affected packages, but this did not help. Any clues?
Thanks -Fritz
-- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
I see the same problem at https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:Ubunt... While syncing from Uyuni: 12:16:35 ERROR: Download failed: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master:... - Target file isn't valid. Checksum should be 74865c660277651be129867d0627041dd1e76cbfe65419d25908bfc6f329ce2e (sha256).. If I verify the Packages file, the sha256 sum for the package listed there is 74865c660277651be129867d0627041dd1e76cbfe65419d25908bfc6f329ce2e But from all the mirrors that offer it: https://paste.opensuse.org/view//33286947 the sha256 sum is 78ba353494f8cf1bfa88f32939cf1c4345adcea46348d184798adab993b1bfb8: https://paste.opensuse.org/view//41392602 I tried "osc wipebinaries --all systemsmanagement:Uyuni:Master:Ubuntu1604-Uyuni-Client-Tools && osc rebuild --all systemsmanagement:Uyuni:Master:Ubuntu1604-Uyuni-Client-Tools" just in case, but no luck. Same happens at https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:Ubunt... Being that: - All three mirrors are broken - The dates for the packages seems to be fine at the mirrors. - This seems to be happening (in our case= only for Ubuntu Uyuni packages (at least openSUSE seems to be fine, for example https://provo-mirror.opensuse.org/repositories/systemsmanagement:/Uyuni:/Mas... is c319a3a00b4cfba9c599d6d25daf79823709d6fd494de0bbb823bae2e4167fd9 as at the repodata) I wonder if this really a problem with the mirrors, or there's something else. @Fritz, did you finally open a ticket at admin@opensuse.org? On miércoles, 24 de julio de 2019 11:29:12 (CEST) Adrian Schröter wrote:
On Mittwoch, 24. Juli 2019, 11:14:45 CEST Fritz Elfert wrote:
Hi,
I recently noticed some strange discrepancy of the downloadable packages that were created after building:
The size/checksum of the rpm file on download.opensuse.org does not match the metadata that is recorded in the repository's primary.xml.gz
E.g:
When downloading https://download.opensuse.org/repositories/home:/felfert/Fedora_29/x86_64/ eh s-devel-1.5.1-173.fc29.x86_64.rpm
The resulting size is 622240 bytes and the sha256sum is eb77ce147162cd3ab9a997e31b865b3e22f7457327f12eac202e6b54210a4547
However in the corresponding https://download.opensuse.org/repositories/home:/felfert/Fedora_29/repodat a/ 064d3aa4fe373fa91f0edbfcc22328585f5bb381f3661b3d951accaa12baaf22-primary. xml .gz
most likely a mirror is broken. Check with curl or wget from where it comes really and report it to
admin@opensuse.org
please. (since the download infrastructure is not part of OBS).
thanks adrian
The size is recorded as 622248 and the sha256 as 11524992b6ca3bc8f2bc0b7f82c0c3875c1c9ca3f87e8b9072cce2bff2331466
Obviously, dnf complains when attempting to install or update the package. I rebuilt the affected packages, but this did not help. Any clues?
Thanks
-Fritz
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
On 28.07.19 12:40, Julio Gonzalez wrote:
I see the same problem at [...]
I tried "osc wipebinaries --all systemsmanagement:Uyuni:Master:Ubuntu1604-Uyuni-Client-Tools && osc rebuild --all systemsmanagement:Uyuni:Master:Ubuntu1604-Uyuni-Client-Tools" just in case, but no luck.
This is redundant, because wipebinaries triggers a rebuild anyway, but more important: What I learned in the meantime is that this is *not* sufficient. In order to get the binaries re-transferred, one has to do the following: 1. Disable builds 2. osc wipebinaries --all 3. (Important) wait, until the file disappears from all mirrors. Can take quite long. 4. Enable builds again I am currently in the waiting phase.
Same happens at https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:Ubunt...
Being that:
- All three mirrors are broken - The dates for the packages seems to be fine at the mirrors. - This seems to be happening (in our case= only for Ubuntu Uyuni packages (at least openSUSE seems to be fine, for example https://provo-mirror.opensuse.org/repositories/systemsmanagement:/Uyuni:/Mas... is c319a3a00b4cfba9c599d6d25daf79823709d6fd494de0bbb823bae2e4167fd9 as at the repodata)
I wonder if this really a problem with the mirrors, or there's something else.
@Fritz, did you finally open a ticket at admin@opensuse.org?
I did, but the ticket is still untouched as of right now (Jul 29, 03:00 GMT) Ticket: https://progress.opensuse.org/issues/54605 (unfortunately it is set to private - don't know why and I cannot change this) Also: In my case, the US-Mirror had the correct file. gwdg and lysator had the wrong one, so in my case, it really appears to be a mirror problem. CU -Fritz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On lunes, 29 de julio de 2019 5:05:09 (CEST) Fritz Elfert wrote:
On 28.07.19 12:40, Julio Gonzalez wrote:
I see the same problem at
[...]
I tried "osc wipebinaries --all systemsmanagement:Uyuni:Master:Ubuntu1604-Uyuni-Client-Tools && osc rebuild --all systemsmanagement:Uyuni:Master:Ubuntu1604-Uyuni-Client-Tools" just in case, but no luck. This is redundant, because wipebinaries triggers a rebuild anyway, but more important:
Mmmm... not what the manual page says, so that's why I launched it. But good to know :-)
What I learned in the meantime is that this is *not* sufficient. In order to get the binaries re-transferred, one has to do the following:
1. Disable builds 2. osc wipebinaries --all 3. (Important) wait, until the file disappears from all mirrors. Can take quite long. 4. Enable builds again
I am currently in the waiting phase.
But are you sure this works? I am specially worried this will work one time, and then when a package changes, the same procedure is needed.
Same happens at https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:Ub untu1804-Uyuni-Client-Tools
Being that:
- All three mirrors are broken - The dates for the packages seems to be fine at the mirrors. - This seems to be happening (in our case= only for Ubuntu Uyuni packages (at least openSUSE seems to be fine, for example https://provo-mirror.opensuse.org/repositories/systemsmanagement:/Uyuni:/ Master:/openSUSE_Leap_15-Uyuni-Client-Tools/openSUSE_Leap_15.0/x86_64/gola ng-github-boynux-squid_exporter-1.6-lp150.4.2.x86_64.rpm is c319a3a00b4cfba9c599d6d25daf79823709d6fd494de0bbb823bae2e4167fd9 as at the repodata)
I wonder if this really a problem with the mirrors, or there's something else.
@Fritz, did you finally open a ticket at admin@opensuse.org?
I did, but the ticket is still untouched as of right now (Jul 29, 03:00 GMT) Ticket: https://progress.opensuse.org/issues/54605 (unfortunately it is set to private - don't know why and I cannot change this)
Also: In my case, the US-Mirror had the correct file. gwdg and lysator had the wrong one, so in my case, it really appears to be a mirror problem.
CU -Fritz
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
On 29.07.19 09:37, Julio Gonzalez wrote: [...]
1. Disable builds 2. osc wipebinaries --all 3. (Important) wait, until the file disappears from all mirrors. Can take quite long. 4. Enable builds again
I am currently in the waiting phase.
But are you sure this works? I am specially worried this will work one time, and then when a package changes, the same procedure is needed.
No, I am not shure. I got this from an old post on opensuse-buildservice@opensuse.org. We will see. I will report back, if this solved my problem or not. As of right now, *none* of the mirrors has picked up any change, not even in the repodata subdir. CU -Fritz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
So in my case I didn't disable builds, but now it seems things are working again! :-) Not sure if it got fixed on its own (slow publishing queue again, maybe?) or Michael/Adrian (CC) did something. On lunes, 29 de julio de 2019 10:48:23 (CEST) Fritz Elfert wrote:
On 29.07.19 09:37, Julio Gonzalez wrote:
[...]
1. Disable builds 2. osc wipebinaries --all 3. (Important) wait, until the file disappears from all mirrors. Can take quite long. 4. Enable builds again
I am currently in the waiting phase.
But are you sure this works? I am specially worried this will work one time, and then when a package changes, the same procedure is needed.
No, I am not shure. I got this from an old post on opensuse-buildservice@opensuse.org. We will see. I will report back, if this solved my problem or not. As of right now, *none* of the mirrors has picked up any change, not even in the repodata subdir.
CU -Fritz
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
And it seems it's happening again, now with another package: 15:11:57 ERROR: Download failed: https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Master:/Ubuntu1604-Uyuni-Client-Tools/xUbuntu_16.04/ all/salt-ssh_2019.2.0+ds-1_all.deb - Target file isn't valid. Checksum should be b119694c43a2f0a5cd0501772bfcd4b5ce7da5c4fdb6e5e3fcbd0a00296f7d4f (sha256).. 15:11:57 2/7 : salt-ssh_2019.2.0+ds-1_all.deb (failed) @Fritz, was it fixed in your case? On martes, 30 de julio de 2019 9:26:20 (CEST) Julio Gonzalez wrote:
So in my case I didn't disable builds, but now it seems things are working again! :-)
Not sure if it got fixed on its own (slow publishing queue again, maybe?) or Michael/Adrian (CC) did something.
On lunes, 29 de julio de 2019 10:48:23 (CEST) Fritz Elfert wrote:
On 29.07.19 09:37, Julio Gonzalez wrote:
[...]
1. Disable builds 2. osc wipebinaries --all 3. (Important) wait, until the file disappears from all mirrors. Can take quite long. 4. Enable builds again
I am currently in the waiting phase.
But are you sure this works? I am specially worried this will work one time, and then when a package changes, the same procedure is needed.
No, I am not shure. I got this from an old post on opensuse-buildservice@opensuse.org. We will see. I will report back, if this solved my problem or not. As of right now, *none* of the mirrors has picked up any change, not even in the repodata subdir.
CU
-Fritz
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
On 01.08.19 15:14, Julio Gonzalez wrote:
And it seems it's happening again, now with another package:
15:11:57 ERROR: Download failed: https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Master:/Ubuntu1604-Uyuni-Client-Tools/xUbuntu_16.04/ all/salt-ssh_2019.2.0+ds-1_all.deb - Target file isn't valid. Checksum should be b119694c43a2f0a5cd0501772bfcd4b5ce7da5c4fdb6e5e3fcbd0a00296f7d4f (sha256).. 15:11:57 2/7 : salt-ssh_2019.2.0+ds-1_all.deb (failed)
@Fritz, was it fixed in your case?
Nope. And here it starts with other packages too :-( The current mirror situation is quite desolate: *None* of the suggested mirrors for my location (DE) has correct packages. The suggested mirrors for my location are: ftp.gwdg.de ftp.lysator.liu.se provo-mirror.opensuse.org To me, this smells like the master (staging?) has problems and cannot be reached by the mirrors, but of course, without having rsync access to that one I cannot be shure. Apparently, *some* resync attempt has been made, because I see *old* binaries with a newer timestamp on the mirror though. Still, the newer binaries that should be there, are not. Also: My ticket #54605 that I submitted 8 days ago to admin@opensuse.org is still untouched (nobody assigned, Done: 0%) Frustrated -Fritz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hi Fritz, I finally managed to get the problem solved for my Ubuntu repositories, so I guess your problem could be the same. In my case, I was trying to publish a rebuild of a package, but sadly the Debian packaged we had, didn't increase the build number at the control files. By having a look at https://download.opensuse.org/repositories/home:/felfert/ Fedora_29/x86_64/ehs-devel-1.5.1-173.fc29.x86_64.rpm I think it's the same. Is "-173" coming from your SPEC and you are trying to publish a rebuild? If that's the case, I have to be honest (if mls is reading me): I didn't understand 100% the explanation of why it's happening (I should stop multitasking one day), but I understood that the solution is increasing the release number. In your case that could be fixed by adding a suffix to -173 that gets increased each time the package rebuilds. If I am not wrong, adding this to your Project Config: Release: <SPEC_REL>.<B_CNT> And launching a rebuild of the project osc rebuild -a <YOUR_PROJECT> Should fix your issues. I can't find anything about this a the official doc: https://openbuildservice.org/help/manuals/obs-user-guide/ cha.obs.prjconfig.html But I know for a fact that you can change the Release like that, as we use something similar at Uyuni (for RPMs), and I had a look at this issue: https://github.com/openSUSE/open-build-service/issues/536 Let us know if your problem gets fixed. On jueves, 1 de agosto de 2019 16:56:29 (CEST) Fritz Elfert wrote:
On 01.08.19 15:14, Julio Gonzalez wrote:
And it seems it's happening again, now with another package:
15:11:57 ERROR: Download failed: https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Master:/Ubuntu1604-Uyuni-Client-Tools/xUbuntu_1 6.04/ all/salt-ssh_2019.2.0+ds-1_all.deb - Target file isn't valid. Checksum should be b119694c43a2f0a5cd0501772bfcd4b5ce7da5c4fdb6e5e3fcbd0a00296f7d4f (sha256).. 15:11:57 2/7 : salt-ssh_2019.2.0+ds-1_all.deb (failed)
@Fritz, was it fixed in your case?
Nope. And here it starts with other packages too :-( The current mirror situation is quite desolate:
*None* of the suggested mirrors for my location (DE) has correct packages. The suggested mirrors for my location are:
ftp.gwdg.de ftp.lysator.liu.se provo-mirror.opensuse.org
To me, this smells like the master (staging?) has problems and cannot be reached by the mirrors, but of course, without having rsync access to that one I cannot be shure.
Apparently, *some* resync attempt has been made, because I see *old* binaries with a newer timestamp on the mirror though. Still, the newer binaries that should be there, are not.
Also: My ticket #54605 that I submitted 8 days ago to admin@opensuse.org is still untouched (nobody assigned, Done: 0%)
Frustrated -Fritz
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
participants (3)
-
Adrian Schröter -
Fritz Elfert -
Julio Gonzalez