Bugzilla – Bug 1112615
Binaries shown by osc ls -b and in the web ui aren't true reflections of the binaries in the physical repo
Last modified: 2023-10-17 14:08:59 UTC
See Bug 1068792 Comment 116 and more, the Tumbleweed and Factory repos in home:plater have binaries from libmlt and it's linked package webvfx that were created 28-Sep-2018 09:54 regardless of the web ui and osc ls -b home:plater/libmlt openSUSE_Tumbleweed x86_64 showing nothing or in the case of a new build, showing the correct version-release. This bug seems to be a subset of Bug 725211 and Bug 958899 but is more serious as it has prevented the fixing of a bug. Nothing has dislodged the libmlt Tumbleweed and Factory binaries, wipebinaries recreate package using os meta which worked in Bug 958899. Ok the recreate via meta and delete package has finally worked and they've gone but there's a serious bug if Packages can be stuck in the repo like that I thought that the reporter wasn't installing the test packages. I've managed to wipe every binary from the openSUSE_Tumbleweed and openSUSE_Factory repos and have recreated libmlt. A possible clue : I'm in the habit of deleting the package via the web ui and then immediately rebranching it. In the case of libmlt I did this without deleting the linked package. Anyway packages physically in the repository should match the ones in the web ui or "osc ls -b" if they are shown as published. Obs should pick up the problem if they don't match.
If I can get this to happen again, I must see what osc getbinaries does.
sure, deleting and recreating it in a not buildable way can cause this (build failure or disabled. excluded state will remove binaries). use wipebinaries if you want to explicit delete the build results It seems you mix build area and publish area, but without a reproducer or a pointer to an existing setup we can not do anything.
just to complete this, disabled or failed build results can keep former successful results forever. This is by design.
Not really invalid, why doesn't osc ls -b or the web ui indicate that there are stale binaries preventing the new ones from being published. No build failures in this equation. I had to wipe all binaries from my project to dislodge the old phantom ones. There's a bug that needs fixing, maybe a paying customer will release an update that won't actually be there. Why doesn't osc ls -b or the web ui indicate the true state of the repository? Sorry I couldn't wait to fix my bug but this will happen again.
please tell me then the exact binary and the location (project/repo) which you want to get rid of and can't. home:plater/libmlt openSUSE_Tumbleweed x86_64 seems to built then binaries which get published atm.
Unfortunately I managed to eventually delete the offending binaries so you are just going to have to trust me or look at what happened in Bug 1068792 Comment 116 and Comment 122. The 6.10.0-118.1 libmlt binaries must have somehow gained permissions that prevented them from being overwritten or possibly because of the higher release number? home:plater/libmlt binaries published after 28-Sep-2018 09:54 did not overwrite the binaries that were published at 28-Sep-2018 09:54 in the openSUSE_Factory and the openSUSE_Tumbleweed repositories. The Leap_15.0 repository functioned as expected. How is this possible? I only managed to clear the problem with "osc wipebinaries --all home:plater do I have to do this every time I want to delete and rebranch a package?
I can trust you, but I can not fix anything without a reproducer or having the situation. The problems in the bugreport you mentioned seems to be on package/rpm level if there were files installed, not owned by packages. It can happen that you keep old binaries if they are still the built result of anyother package container. This is on purpose then, you can see this in the DISTURL of the package.. rpm -q --qf '%{DISTURL}\n' $package
When I realised that there was a problem I opened my Tumbleweed vm and found that zypper really was seeing the wrong binaries regardless of what was indicated by osc, I then navigated to the physical repository and saw that this was true. How does osc know that the binaries are published and how is it possible that the physical repo binaries can differ. Isn't there a check?
(In reply to Adrian Schröter from comment #7) > I can trust you, but I can not fix anything without a reproducer or having > the situation. > > The problems in the bugreport you mentioned seems to be on package/rpm level > if there were files installed, not owned by packages. > > It can happen that you keep old binaries if they are still the built result > of anyother package container. This is on purpose then, you can see this in > the DISTURL of the package.. > > rpm -q --qf '%{DISTURL}\n' $package You don't understand, the problem is that although the web ui indicated that release version -113.1 was published the reporter could only see the binaries from 28-Sep-2018 09:54 bearing the release version -118.1 Why did the web ui indicate that release -113.1 was published when a release from a previous deleted entity was actually there? The not owned libmltopencv.so isn't the problem. The problem is how can obs indicate one release is published when in actual fact it isn't. This is a potential security risk.
the "osc ls -b" command shows you the binaries from the build area. The same might be true for the webui, depending about the location you look at. The publishing gets triggered when all builds of the entire repo are done for this architecture (no scheduled/blocked/building jobs anymore). And then there might be a queue of other projects waiting for publishing, since it is relative expensive. You can see that the binaries are published or not published for example via the "osc results -v" command.
The osc results, I use osc r -v , command showed the binaries as published. I deleted the libmlt package 2018-09-27 when the bug was reopened and then I rebranched it, so the binaries that remained were from the last build prior to that as indicated by the file date they (release 118.1) had. After that I built a changed package every day and then checked that it was published before asking the bug reporter to install and test. None of those builds were physically published in the repository that the reporter was attempting to install from: https://download.opensuse.org/repositories/home:/plater/openSUSE_Tumbleweed/x86_64/ up to and beyond 2018-10-20 about 23 days. I just attempted to reproduce this home:plater/libmlt had release 116.1 so I deleted the package via the web ui and branched it again as quickly as possible, the old 116.1 binaries remained in: https://download.opensuse.org/repositories/home:/plater/openSUSE_Tumbleweed/x86_64/ only until the new binaries were indicated as published then by coincidence release 113.1 was there and are the release shown by the web ui and downloaded via osc getbinaries. The build service is remarkably fast atm, maybe I can get it right if the old binaries take longer to delete than the new ones take to publish.
sure, nothing changes in download.opensuse.org until the entire repository has been processed. There are no inconsistent states on purpose there. And keep in mind that when your remove a package and restore it in a bit identical way, the scheduler considers them as unchanged and will not trigger anything. Except it looks at it during the short time period hen you just have removed it by chance.
Not exactly the same as last time: I'm creating the new package OpenShadingLanguage (see bug 1120406) in home:plater:blender, I started off with version 1.10.2 but found that blender wouldn't build with that version so I reverted to 1.9.9 and then to 1.9.13. Blender builds with both 1.9s. It won't build on line though and after 1.10.2 is long replaced locally after refreshing the blender repository: # zypper se -s -r blender libos Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+---------------------------+---------+------------------+--------+----------- i | liboslcomp1_10 | package | 1.10.2-lp150.7.1 | x86_64 | blender | liboslcomp1_10-debuginfo | package | 1.10.2-lp150.7.1 | x86_64 | blender i | liboslexec1_10 | package | 1.10.2-lp150.7.1 | x86_64 | blender | liboslexec1_10-debuginfo | package | 1.10.2-lp150.7.1 | x86_64 | blender i | liboslnoise1_10 | package | 1.10.2-lp150.7.1 | x86_64 | blender | liboslnoise1_10-debuginfo | package | 1.10.2-lp150.7.1 | x86_64 | blender i | liboslquery1_10 | package | 1.10.2-lp150.7.1 | x86_64 | blender | liboslquery1_10-debuginfo | package | 1.10.2-lp150.7.1 | x86_64 | blender but if I browse https://download.opensuse.org/repositories/home:/plater:/blender/Leap_15.0/x86_64 I find version 1.9.13 listed but locally zypper installs 1.10.2 This seems to be persistent so I hope you can find the gremlin this time.
The reporter in the current bug I'm working on has also had a problem with: http://download.opensuse.org/repositories/home:/plater:/blender/Leap_15.0 Could my suspicions be right and this is as a result of incorrect mirror handling? Who needs to be added to this bug?