Was building a pkg from master/ branch in git today, and was more than a little surprised to see that the build went against f16-updates-candidate target, instead of f17-candidate as I'd expect.
I strongly suspect it had to do with this particular pkg (kdebindings) had only active git branches: f15, devel , and that fedpkg tries to guess what target to use for master/ based on the latest active branch and adding one? :)
Either way, it ended up getting it wrong in this case, and hopefully can be fixed.
To be clearer, when I said "active git branches", I guess I really meant "active branches in pkgdb", where pkgdb devel maps to git master/
oh boo. How often does this happen where a package will skip a branch like this? I suppose if it gets retired at some point and brought back... *sigh*. I'll have to come up with a different algorithm to find out what master should map to.
How often? I'd guess not a lot, may not be worth worrying too much about.
This happens when the remote master branch is switched to a new release, whilst the local master branch stays at the older version. You need to do 'git pull' in order to workaround that (and that's not so easy when some changes have been already made locally), but anyway it isn't nice that the build succeeds with wrong release whilst in fact it is not pushed to the corresponding remote branch.
This really needs to be fixed in fedpkg.
Hrm, this is a tough one. I realized that for doing builds, we have an optimization that looks to see if the build has already been done in the system. To know that, we have to know what the n-v-r of the build would be, which includes the dist macro. This means that even if we just hardcode the use of 'rawhide' build target for master, we still have to figure out what Fedora that targets.
If we don't do the optimization to see if a build has already been done, then users would have to wait for a koji builder init a chroot to do the scm checkout and srpm creation from SCM before it would know what the n-v-r of the build would be, and /then/ potentially have the build failed. That could be a waste of many minutes.
I'm going to think on this some more.
Ok, I've committed something that might help. If we're doing a real build command, we've already got a koji session opened up. I can detect that and just query koji for what the rawhide target is pointing to. This will get us accurate information for what the n-v-r might be. If we don't already have a koji session, we might be doing offline local work, in which case just look at local data.
It's in commit c97e877e20ac9ddc71a8d34edbf97e2071f5a8d4
rpkg-1.14-1.fc16,fedpkg-1.9-1.fc16 has been submitted as an update for Fedora 16.
fedpkg-1.9-1.fc15,rpkg-1.14-1.fc15 has been submitted as an update for Fedora 15.
fedpkg-1.9-1.fc17,rpkg-1.14-1.fc17 has been submitted as an update for Fedora 17.
Package fedpkg-1.9-1.fc17, rpkg-1.14-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedpkg-1.9-1.fc17 rpkg-1.14-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
fedpkg-1.9-1.fc15, rpkg-1.15-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
fedpkg-1.9-1.fc16, rpkg-1.15-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
fedpkg-1.9-1.fc17, rpkg-1.15-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.