Re: master branch still invokes build in f17-candidate??
Dne 29.2.2012 20:13, Jesse Keating napsal(a): unless we move away from using master for rawhide and instead always have a specific branch for each release. Please don't do that. Thank you. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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.kof...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
Jesse Keating jkeat...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/29/12 1:25 PM, Tom Lane wrote:
Jesse Keatingjkeat...@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
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On Wed, Feb 29, 2012 at 16:25:22 -0500, Tom Lane t...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On Mon, Feb 27, 2012 at 12:14:49PM -0800, Jesse Keating wrote: On 2/27/12 8:37 AM, Tom Lane wrote: Orion Poplawskior...@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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On Tue, Feb 28, 2012 at 11:18 AM, Richard W.M. Jones rjo...@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 Poplawskior...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
Kevin Kofler kevin.kof...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
Tom Lane wrote:
Kevin Kofler kevin.kof...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On Wed, 2012-02-29 at 05:31 +0100, Kevin Kofler wrote:
Tom Lane wrote:
Kevin Kofler kevin.kof...@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.
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
Mathieu Bridon wrote: I would certainly be very confused if `fedpkg mockbuild` produced a f17 rpm but `fedpkg build` produced an f18 one. build is the common case and should always work; srpm, mockbuild etc. are extras, I don't care if they break. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
master branch still invokes build in f17-candidate??
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://t...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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://t...@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 Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
Orion Poplawski or...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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://t...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/27/12 8:37 AM, Tom Lane wrote: Orion Poplawskior...@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 Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
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).
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
