Hi all,
I've done ~180 builds in COPR now, and the system works really well, thanks! One little issue I've had is the last of "cost" to the non-copr repos. For instance, targeting f20, i386&x64:
f20-updates: * glib-2.0 * gnome-desktop-3.10.0 (which uses glib) * control-center-3.10.0 (and this uses a library in gnome-desktop) * gnome-shell-3.10.0 (and this uses a library in gnome-desktop)
Then I build gnome-desktop-3.11.1 in a copr which bumps the soname, which means any package that depend on it also have to be rebuilt. If I then re-submit the control-center-3.10.0 srpm this succeeds and these packages are loaded into the buildroot:
* glib-2.0 (updates) * gnome-desktop-3.11.1 (copr) * control-center-3.10.0 (local)
If I then re-submit the gnome-shell-3.10.0 build, the following set of packages is chosen:
* glib-2.0 (updates) * gnome-desktop-3.11.1 (copr) * control-center-3.10.0 (**UPDATES**) * gnome-shell-3.10.0 (local)
So the control-center-3.10.0 build is coming from the updates repo (built against the old soname) rather than the identically versioned build control-center-3.10.0 from the copr repo (built against the new soname).
Now yum and dnf have a way to prefer one repo over another, and this is the "cost" value in the .repo file. Can I suggest that either the fedora&updates repo either have a cost value set to above 1000, or that the copr repo has cost less than the default value of 1000? This should fix the issue and ensure deps are chosen from the copr rather than the fedora repos.
Thanks,
Richard
On 02/20/2014 09:54 AM, Richard Hughes wrote:
So the control-center-3.10.0 build is coming from the updates repo (built against the old soname) rather than the identically versioned build control-center-3.10.0 from the copr repo (built against the new soname).
Now yum and dnf have a way to prefer one repo over another, and this is the "cost" value in the .repo file. Can I suggest that either the fedora&updates repo either have a cost value set to above 1000, or that the copr repo has cost less than the default value of 1000? This should fix the issue and ensure deps are chosen from the copr rather than the fedora repos.
Hmm, I thought that we have release number for that. Is there some reason that you can not bump it up?
Mirek
On 22 February 2014 18:47, Miroslav Suchy msuchy@redhat.com wrote:
Hmm, I thought that we have release number for that. Is there some reason that you can not bump it up?
A lot of time when people break rawhide it's because they bump a soname of a library low down in the stack and then try to rebuild everything against the new library. When this fails, rawhide is left in a broken state for days on end. I want people to switch to a testing strategy where they build the new library in copr using a local srpm and then try building the other stuff on top of it using the copr instance they spun up. If this succeeds, then the package can be easily built for rawhide. If it fails, we can debug things without people moaning that rawhide is broken.
When we're taking the other libraries from koji, we really want to use the exact srpms from koji (which means we can't bump the release/epoch) rather than trying to rebuild all of them by hand (which is a lot of packages for GNOME for instance).
So, I can certainly work around things by downloading the srpm, exploding it, bumping the release, repacking it, and then submitting it, although this is going to increase the time takes to build a large repo for me by a order of magnitude or more.
So cost would be an awesome thing to change for me :)
Richard.
On 22 February 2014 19:36, Richard Hughes hughsient@gmail.com wrote:
When we're taking the other libraries from koji
So here you can see I'm trying to rebuild gnome-3-12 with a new version of librepo: https://copr.fedoraproject.org/coprs/rhughes/f19-gnome-3-12/builds/ -- the PackageKit build chose the librepo in updates rather than the copr one I'd built a few hours earlier. If I resubmit the build, the build may succeed, as it's pretty random where the packages come from.
Richard.
On 02/23/2014 08:52 AM, Richard Hughes wrote:
So here you can see I'm trying to rebuild gnome-3-12 with a new version of librepo: https://copr.fedoraproject.org/coprs/rhughes/f19-gnome-3-12/builds/ -- the PackageKit build chose the librepo in updates rather than the copr one I'd built a few hours earlier. If I resubmit the build, the build may succeed, as it's pretty random where the packages come from.
OK. Do you know the name of yum.conf directive from top of head? Or I should ask uncle Google? Mirek
On 23 February 2014 15:50, Miroslav Suchy msuchy@redhat.com wrote:
OK. Do you know the name of yum.conf directive from top of head? Or I should ask uncle Google?
cost=900 in the copr repo should fix things. "man yum.conf" has more details. Thanks,
Richard
On 02/23/2014 08:52 AM, Richard Hughes wrote:
So here you can see I'm trying to rebuild gnome-3-12 with a new version of librepo: https://copr.fedoraproject.org/coprs/rhughes/f19-gnome-3-12/builds/ -- the PackageKit build chose the librepo in updates rather than the copr one I'd built a few hours earlier. If I resubmit the build, the build may succeed, as it's pretty random where the packages come from.
Ha! I trusted you. I should not done that! :))
I had some spare cycles so I wanted to implement the cost=X. Then I find that mockchain already have implemented it (for more then year)! So I wondered how it is possible that you did not get package from you local repo (can it be yum bug?) and I checked the build logs of your project.
http://copr-be.cloud.fedoraproject.org/results/rhughes/f19-gnome-3-12/fedora... ^ This is the one you refer to?
But it have this lines: DEBUG util.py:281: librepo x86_64 1.6.0-1.fc19 coprbecloudfedoraprojectorg_results_rhughes_f19gnome312
So it installed librepo package from your repo. So I believe your problem was then something else. Can you please check it?
On 28 February 2014 09:26, Miroslav Suchý msuchy@redhat.com wrote:
So I wondered how it is possible that you did not get package from you local repo (can it be yum bug?)
Possible I guess.
http://copr-be.cloud.fedoraproject.org/results/rhughes/f19-gnome-3-12/fedora... ^ This is the one you refer to?
Nope. I deleted the original build, resubmitted it, deleted it, then resubmitted it and eventually the correct librepo was picked up.
was then something else. Can you please check it?
Next time it happens I'll leave the build output and forward a note to you. Thanks.
Richard.
On 02/28/2014 11:37 AM, Richard Hughes wrote:
Next time it happens I'll leave the build output and forward a note to you. Thanks.
OK. I will put it on back burner until then.
On Thu, 2014-02-20 at 08:54 +0000, Richard Hughes wrote:
Now yum and dnf have a way to prefer one repo over another, and this is the "cost" value in the .repo file. Can I suggest that either the fedora&updates repo either have a cost value set to above 1000, or that the copr repo has cost less than the default value of 1000? This should fix the issue and ensure deps are chosen from the copr rather than the fedora repos.
At least in yum this is "where do I prefer to download an _identical_ rpm from" (the config. name meaning what is the cost to download from this repo.). This is used for cases like repo. XYZ is on my local machine/network so prefer to download packages from there instead of the generic fedora repo. What you want to do is more like the priorities or protectbase plugins, where you are dealing with _different_ rpms and one set of packages should be preferred for depsolving etc. (not sure dnf has a way to do this atm).
Having two packages called X-1.2-3 which provide/require different things isn't going to be a great idea, and relying on cost to pick the right one is going to be fragile at best.
copr-devel@lists.fedorahosted.org
-
James Antill -
Miroslav Suchý -
Richard Hughes