I'm definitely checked out in the master branch:
[tgl@rh3 master]$ git push Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.13 KiB, done. Total 6 (delta 3), reused 0 (delta 0) To ssh://tgl@pkgs.fedoraproject.org/postgresql d44dce3..2e73ff7 master -> master
but:
[tgl@rh3 master]$ fedpkg build Building postgresql-9.1.3-1.fc17 for f17-candidate Created task: 3822862 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862 Watching tasks (this may be safely interrupted)... 3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free 3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free -> open (x86-02.phx2.fedoraproject.org)
WTF? Do I need to fix this, and if so how?
regards, tom lane
Dne 27.2.2012 17:09, Tom Lane napsal(a):
I'm definitely checked out in the master branch:
[tgl@rh3 master]$ git push Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.13 KiB, done. Total 6 (delta 3), reused 0 (delta 0) To ssh://tgl@pkgs.fedoraproject.org/postgresql d44dce3..2e73ff7 master -> master
but:
[tgl@rh3 master]$ fedpkg build Building postgresql-9.1.3-1.fc17 for f17-candidate Created task: 3822862 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862 Watching tasks (this may be safely interrupted)... 3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free 3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free -> open (x86-02.phx2.fedoraproject.org)
WTF? Do I need to fix this, and if so how?
regards, tom lane
Have you tried git pull before?
Vit
On 02/27/2012 09:09 AM, Tom Lane wrote:
I'm definitely checked out in the master branch:
[tgl@rh3 master]$ git push Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.13 KiB, done. Total 6 (delta 3), reused 0 (delta 0) To ssh://tgl@pkgs.fedoraproject.org/postgresql d44dce3..2e73ff7 master -> master
but:
[tgl@rh3 master]$ fedpkg build Building postgresql-9.1.3-1.fc17 for f17-candidate Created task: 3822862 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862 Watching tasks (this may be safely interrupted)... 3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free 3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free -> open (x86-02.phx2.fedoraproject.org)
WTF? Do I need to fix this, and if so how?
regards, tom lane
git pull
(to bring in the f17 branch and mark devel as f18)
Orion Poplawski orion@cora.nwra.com writes:
On 02/27/2012 09:09 AM, Tom Lane wrote:
WTF? Do I need to fix this, and if so how?
git pull (to bring in the f17 branch and mark devel as f18)
Hmm, that package indeed hadn't had f17 git pull'd yet. (I had scripted a git pull in all my package directories after the branch, but I think that it failed in this one due to uncommitted changes.)
So you're saying that fedpkg's behavior depends on the existence of other, un-checked-out, branches in my local repo? This seems a tad ... unreliable. Not to say surprising.
regards, tom lane
On 2/27/12 8:37 AM, Tom Lane wrote:
Orion Poplawskiorion@cora.nwra.com writes:
On 02/27/2012 09:09 AM, Tom Lane wrote:
WTF? Do I need to fix this, and if so how?
git pull (to bring in the f17 branch and mark devel as f18)
Hmm, that package indeed hadn't had f17 git pull'd yet. (I had scripted a git pull in all my package directories after the branch, but I think that it failed in this one due to uncommitted changes.)
So you're saying that fedpkg's behavior depends on the existence of other, un-checked-out, branches in my local repo? This seems a tad ... unreliable. Not to say surprising.
regards, tom lane
I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
Jesse Keating wrote:
I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
What was wrong with the good old dist-rawhide target? Making master always use a rawhide target obviates the need of having to check out what n in fn-candidate to build for.
Kevin Kofler
On 2/27/12 5:53 PM, Kevin Kofler wrote:
Jesse Keating wrote:
I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
What was wrong with the good old dist-rawhide target? Making master always use a rawhide target obviates the need of having to check out what n in fn-candidate to build for.
Kevin Kofler
Because you still don't know what %{?dist} (and others) should be. What does "dist-rawhide" mean? Well it could be .fc17, or it could mean .fc18, which could make a big difference to conditionals within the spec file.
Although the plan was at one time to make use of the dist-rawhide target, I'm not sure what derailed that plan, and if possible we should go through with that plan, but the above problem remains (it'd just come into play less often).
Dne 28.2.2012 02:59, Jesse Keating napsal(a):
On 2/27/12 5:53 PM, Kevin Kofler wrote:
Jesse Keating wrote:
I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
What was wrong with the good old dist-rawhide target? Making master always use a rawhide target obviates the need of having to check out what n in fn-candidate to build for.
Kevin Kofler
Because you still don't know what %{?dist} (and others) should be. What does "dist-rawhide" mean? Well it could be .fc17, or it could mean .fc18, which could make a big difference to conditionals within the spec file.
Although the plan was at one time to make use of the dist-rawhide target, I'm not sure what derailed that plan, and if possible we should go through with that plan, but the above problem remains (it'd just come into play less often).
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
Vit
Vít Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
Yes, for fedpkg build, the client should not have to care about what %{?dist} is at all. It should just ask Koji to build the current git hash in Rawhide and that's it.
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at writes:
Vít Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
Yes, for fedpkg build, the client should not have to care about what %{?dist} is at all. It should just ask Koji to build the current git hash in Rawhide and that's it.
Nope, it's not that easy, as some purely-local operations (eg "fedpkg srpm") also want to know the dist tag.
I don't actually have a problem with Jesse's solution now that I know about it; it was just surprising that fedpkg would depend on other branches besides the one I have checked out.
regards, tom lane
Tom Lane wrote:
Kevin Kofler kevin.kofler@chello.at writes:
VÃt Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
Yes, for fedpkg build, the client should not have to care about what %{?dist} is at all. It should just ask Koji to build the current git hash in Rawhide and that's it.
Nope, it's not that easy, as some purely-local operations (eg "fedpkg srpm") also want to know the dist tag.
Those operations can use Jesse's heuristics, but there's no good reason to use them for fedpkg build.
Kevin Kofler
On Wed, 2012-02-29 at 05:31 +0100, Kevin Kofler wrote:
Tom Lane wrote:
Kevin Kofler kevin.kofler@chello.at writes:
VÃt Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
Yes, for fedpkg build, the client should not have to care about what %{?dist} is at all. It should just ask Koji to build the current git hash in Rawhide and that's it.
Nope, it's not that easy, as some purely-local operations (eg "fedpkg srpm") also want to know the dist tag.
Those operations can use Jesse's heuristics, but there's no good reason to use them for fedpkg build.
I would certainly be very confused if `fedpkg mockbuild` produced a f17 rpm but `fedpkg build` produced an f18 one.
Dne 29.2.2012 06:05, Mathieu Bridon napsal(a):
On Wed, 2012-02-29 at 05:31 +0100, Kevin Kofler wrote:
Tom Lane wrote:
Kevin Koflerkevin.kofler@chello.at writes:
VÃt Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
Yes, for fedpkg build, the client should not have to care about what %{?dist} is at all. It should just ask Koji to build the current git hash in Rawhide and that's it.
Nope, it's not that easy, as some purely-local operations (eg "fedpkg srpm") also want to know the dist tag.
Those operations can use Jesse's heuristics, but there's no good reason to use them for fedpkg build.
I would certainly be very confused if `fedpkg mockbuild` produced a f17 rpm but `fedpkg build` produced an f18 one.
Either you or Tom Lane would be confused either way. But I prefer you to be confused, sorry ;) I agree with Kevin.
Vit
On 2/28/12 12:58 AM, Vít Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
For the pure "build" command case, sure, we let koji decide. In fact, the way I've re-written the backend to fedpkg to make more use of python properties and lazy loading, the build command may not actually try to get this data. It's only the local commands that really matter.
Jesse Keating jkeating@redhat.com writes:
On 2/28/12 12:58 AM, Vít Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
For the pure "build" command case, sure, we let koji decide. In fact, the way I've re-written the backend to fedpkg to make more use of python properties and lazy loading, the build command may not actually try to get this data. It's only the local commands that really matter.
Oh? In the complaint that started this thread, I showed an example of launching "fedpkg build" in master branch and getting an fc17-candidate result. That seems to me to prove that it isn't koji deciding.
In the particular case here it was harmless, since I would've just gone and built the identical SRPM in f17 a bit later anyway, and (I trust) rawhide will inherit the new f17 package too.
I can see the argument why "fedpkg srpm" and friends should produce similar results to what you get from "fedpkg build", because I have lost count of the number of times I've cursed the fact that it's impossible to reproduce the koji build environment elsewhere. On the whole I'm not attracted to introducing still another discrepancy compared to what happens in local builds.
regards, tom lane
On 2/29/12 1:25 PM, Tom Lane wrote:
Jesse Keatingjkeating@redhat.com writes:
On 2/28/12 12:58 AM, VÃt Ondruch wrote:
If you say to Koji that it should checkout master at remote machine, build a SRPM etc, why the Koji can't determine the proper %{?dist} at remote machine? Why it takes the %{?dist} from local machine instead? It makes no sense. It might work for other branches, but master is bit different, so it should be handled differently.
For the pure "build" command case, sure, we let koji decide. In fact, the way I've re-written the backend to fedpkg to make more use of python properties and lazy loading, the build command may not actually try to get this data. It's only the local commands that really matter.
Oh? In the complaint that started this thread, I showed an example of launching "fedpkg build" in master branch and getting an fc17-candidate result. That seems to me to prove that it isn't koji deciding.
Right, that's the way it is now, because I never went through with hardcoding the target as 'dist-rawhide'. Once I do that, it may bypass the block of code that looks at the branch names.
In the particular case here it was harmless, since I would've just gone and built the identical SRPM in f17 a bit later anyway, and (I trust) rawhide will inherit the new f17 package too.
I can see the argument why "fedpkg srpm" and friends should produce similar results to what you get from "fedpkg build", because I have lost count of the number of times I've cursed the fact that it's impossible to reproduce the koji build environment elsewhere. On the whole I'm not attracted to introducing still another discrepancy compared to what happens in local builds.
regards, tom lane
On Wed, Feb 29, 2012 at 16:25:22 -0500, Tom Lane tgl@redhat.com wrote:
In the particular case here it was harmless, since I would've just gone and built the identical SRPM in f17 a bit later anyway, and (I trust) rawhide will inherit the new f17 package too.
I believe rawhide still inherits from stable, not testing. So it takes a while for packages built for non-rawhide to make it to rawhide.
On Mon, Feb 27, 2012 at 12:14:49PM -0800, Jesse Keating wrote:
On 2/27/12 8:37 AM, Tom Lane wrote:
Orion Poplawskiorion@cora.nwra.com writes:
On 02/27/2012 09:09 AM, Tom Lane wrote:
WTF? Do I need to fix this, and if so how?
git pull (to bring in the f17 branch and mark devel as f18)
Hmm, that package indeed hadn't had f17 git pull'd yet. (I had scripted a git pull in all my package directories after the branch, but I think that it failed in this one due to uncommitted changes.)
So you're saying that fedpkg's behavior depends on the existence of other, un-checked-out, branches in my local repo? This seems a tad ... unreliable. Not to say surprising.
regards, tom lane
I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
Didn't RHEL-CVS use a file in the local directory called 'branch'(?)
Rich.
On Tue, Feb 28, 2012 at 11:18 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Feb 27, 2012 at 12:14:49PM -0800, Jesse Keating wrote:
On 2/27/12 8:37 AM, Tom Lane wrote:
Orion Poplawskiorion@cora.nwra.com writes:
On 02/27/2012 09:09 AM, Tom Lane wrote:
WTF? Do I need to fix this, and if so how?
git pull (to bring in the f17 branch and mark devel as f18)
Hmm, that package indeed hadn't had f17 git pull'd yet. (I had scripted a git pull in all my package directories after the branch, but I think that it failed in this one due to uncommitted changes.)
So you're saying that fedpkg's behavior depends on the existence of other, un-checked-out, branches in my local repo? This seems a tad ... unreliable. Not to say surprising.
regards, tom lane
I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
Didn't RHEL-CVS use a file in the local directory called 'branch'(?)
I believe Fedora-CVS had the same. Except it needed to be updated at branch time, and fetched from the server across all checkouts. Makefile.common is what hid all that and nobody noticed because you had to be on the network to do anything with CVS anyway.
Doing the same in git would still require a 'git pull' to get the updated file.
josh
On 2/28/12 8:47 AM, Josh Boyer wrote:
I was looking for a way to determine the behavior of the master
branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this.
Didn't RHEL-CVS use a file in the local directory called 'branch'(?)
I believe Fedora-CVS had the same. Except it needed to be updated at branch time, and fetched from the server across all checkouts. Makefile.common is what hid all that and nobody noticed because you had to be on the network to do anything with CVS anyway.
Doing the same in git would still require a 'git pull' to get the updated file.
Yep. Stale information in the branch file was one of the things I wanted to solve. Of course, I don't think I can solve it completely without requiring a network action, unless we move away from using master for rawhide and instead always have a specific branch for each release.
devel@lists.stg.fedoraproject.org