Greetings.
I know some of you have run into this situation:
If you have a package where there is no *.spec file present and you try to run any of the fedora cvs Makefile.common targets, nothing happens and the command just hangs.
Turns out it's doing a grep of the spec file to figure out if the package is noarch or not. When there is no spec file the grep hangs.
Here's a very hacky patch that should at least error out in this case.
Makefile hackers welcome to provide a better one.
kevin -- Index: Makefile.common =================================================================== RCS file: /cvs/extras/common/Makefile.common,v retrieving revision 1.127 diff -u -r1.127 Makefile.common --- Makefile.common 15 Apr 2009 04:57:41 -0000 1.127 +++ Makefile.common 24 Apr 2009 21:15:03 -0000 @@ -35,6 +35,9 @@
BUILD_FLAGS ?= $(KOJI_FLAGS)
+ifndef $(SPECFILE) +SPECFILE = "NO_SPEC_FILE_FOUND" +endif LOCALARCH := $(if $(shell grep -i '^BuildArch:.*noarch' $(SPECFILE)), noarch, $(shell uname -m))
## a base directory where we'll put as much temporary working stuff as we can
Am 24.04.2009 23:54, schrieb Kevin Fenzi:
Greetings.
I know some of you have run into this situation:
If you have a package where there is no *.spec file present and you try to run any of the fedora cvs Makefile.common targets, nothing happens and the command just hangs.
Turns out it's doing a grep of the spec file to figure out if the package is noarch or not. When there is no spec file the grep hangs.
Here's a very hacky patch that should at least error out in this case.
Makefile hackers welcome to provide a better one.
kevin
Index: Makefile.common
RCS file: /cvs/extras/common/Makefile.common,v retrieving revision 1.127 diff -u -r1.127 Makefile.common --- Makefile.common 15 Apr 2009 04:57:41 -0000 1.127 +++ Makefile.common 24 Apr 2009 21:15:03 -0000 @@ -35,6 +35,9 @@
BUILD_FLAGS ?= $(KOJI_FLAGS)
+ifndef $(SPECFILE) +SPECFILE = "NO_SPEC_FILE_FOUND" +endif LOCALARCH := $(if $(shell grep -i '^BuildArch:.*noarch' $(SPECFILE)), noarch, $(shell uname -m))
## a base directory where we'll put as much temporary working stuff as we can
Looks like this is the week of Makefile.common patches, I have another one:
cvs diff -u Makefile.common
Index: Makefile.common =================================================================== RCS file: /cvs/extras/devel/common/Makefile.common,v retrieving revision 1.127 diff -u -r1.127 Makefile.common --- Makefile.common 15 Apr 2009 04:57:41 -0000 1.127 +++ Makefile.common 27 Apr 2009 14:14:00 -0000 @@ -26,6 +26,10 @@ #BRANCH:=$(shell cvs rlog rpms/$(NAME)/F-11/$(SPECFILE) >/dev/null 2>&1 && echo "F-12" || echo "devel") #endif BRANCHINFO = $(shell grep ^$(BRANCH): $(COMMON_DIR)/branches | cut -d: --output-delimiter=" " -f2-) +ifeq (,$(BRANCHINFO)) +BRANCH:=$(shell pwd | awk -F '/' '{ print $$(NF-1) }' ) +BRANCHINFO = $(shell grep ^$(BRANCH): $(COMMON_DIR)/branches | cut -d: --output-delimiter=" " -f2-) +endif TARGET := $(word 1, $(BRANCHINFO)) DIST = $(word 2, $(BRANCHINFO)) DISTVAR = $(word 3, $(BRANCHINFO))
This should fix builds from a single-distribution CVS tree which you can check out p.e. with 'cvs co F-11'. This broke one year ago with Makefile.common cvs release 1.95 as those changes didn't consider the different directory layout for the single-distribution CVS tree (p.e. it is .../vim/F-11 for the complete checkout but .../F-11/vim when you check out just one single distribution)
Karsten
Karsten Hopp (karsten@redhat.com) said:
Am 24.04.2009 23:54, schrieb Kevin Fenzi:
Greetings.
I know some of you have run into this situation:
If you have a package where there is no *.spec file present and you try to run any of the fedora cvs Makefile.common targets, nothing happens and the command just hangs.
Turns out it's doing a grep of the spec file to figure out if the package is noarch or not. When there is no spec file the grep hangs.
Here's a very hacky patch that should at least error out in this case.
Makefile hackers welcome to provide a better one.
...
Looks like this is the week of Makefile.common patches, I have another one:
They both look fine... go ahead and apply.
Bill
On Mon, 27 Apr 2009 16:15:27 +0200 Karsten Hopp karsten@redhat.com wrote:
...snip...
This should fix builds from a single-distribution CVS tree which you can check out p.e. with 'cvs co F-11'. This broke one year ago with Makefile.common cvs release 1.95 as those changes didn't consider the different directory layout for the single-distribution CVS tree (p.e. it is .../vim/F-11 for the complete checkout but .../F-11/vim when you check out just one single distribution)
Hum. I can't do a 'cvs co F-11' anymore... how do you get that part working?
(I thought we broke that in trying to make the cvs modules file scale to the number of packages we have).
Karsten
kevin
On Monday 27 April 2009 04:54:56 pm Kevin Fenzi wrote:
On Mon, 27 Apr 2009 16:15:27 +0200 Karsten Hopp karsten@redhat.com wrote:
...snip...
This should fix builds from a single-distribution CVS tree which you can check out p.e. with 'cvs co F-11'. This broke one year ago with Makefile.common cvs release 1.95 as those changes didn't consider the different directory layout for the single-distribution CVS tree (p.e. it is .../vim/F-11 for the complete checkout but .../F-11/vim when you check out just one single distribution)
Hum. I can't do a 'cvs co F-11' anymore... how do you get that part working?
(I thought we broke that in trying to make the cvs modules file scale to the number of packages we have).
we disabled vhecking out release modules, it was causing a huge slowdown in cvs actions. you can check out devel still i think but that is all.
Dennis
On 04/27/2009 03:07 PM, Dennis Gilmore wrote:
On Monday 27 April 2009 04:54:56 pm Kevin Fenzi wrote:
On Mon, 27 Apr 2009 16:15:27 +0200 Karsten Hoppkarsten@redhat.com wrote:
...snip...
This should fix builds from a single-distribution CVS tree which you can check out p.e. with 'cvs co F-11'. This broke one year ago with Makefile.common cvs release 1.95 as those changes didn't consider the different directory layout for the single-distribution CVS tree (p.e. it is .../vim/F-11 for the complete checkout but .../F-11/vim when you check out just one single distribution)
Hum. I can't do a 'cvs co F-11' anymore... how do you get that part working?
(I thought we broke that in trying to make the cvs modules file scale to the number of packages we have).
we disabled vhecking out release modules, it was causing a huge slowdown in cvs actions. you can check out devel still i think but that is all.
I think checking out release modules still needs to be possible. If that means we need to use a read-only mirror to facilitate this, I'd be okay with it, but not being able to check out a tree is a pretty bad regression that I just ran into. For the record, it would make doing moz security updates much more scriptable as I don't need to rely on people telling me when their packages need to be added/dropped to the auto rebuilds.
Christopher Aillon wrote:
I think checking out release modules still needs to be possible. If that means we need to use a read-only mirror to facilitate this, I'd be okay with it, but not being able to check out a tree is a pretty bad regression that I just ran into. For the record, it would make doing moz security updates much more scriptable as I don't need to rely on people telling me when their packages need to be added/dropped to the auto rebuilds.
I think we'd need a new script to enable this. Checking out, editing, and committing the modules file was responsible for making mass branching take over two days (rather than ~ 4 hours) two releases ago. So having a separate mirror for people looking to checkout a release module is only half of the work... populating it is what we really need to figure out.
-Toshio
On Mon, 27 Apr 2009 15:23:25 -0700 Christopher Aillon caillon@redhat.com wrote:
On 04/27/2009 03:07 PM, Dennis Gilmore wrote:
On Monday 27 April 2009 04:54:56 pm Kevin Fenzi wrote:
On Mon, 27 Apr 2009 16:15:27 +0200 Karsten Hoppkarsten@redhat.com wrote:
...snip...
This should fix builds from a single-distribution CVS tree which you can check out p.e. with 'cvs co F-11'. This broke one year ago with Makefile.common cvs release 1.95 as those changes didn't consider the different directory layout for the single-distribution CVS tree (p.e. it is .../vim/F-11 for the complete checkout but .../F-11/vim when you check out just one single distribution)
Hum. I can't do a 'cvs co F-11' anymore... how do you get that part working?
(I thought we broke that in trying to make the cvs modules file scale to the number of packages we have).
we disabled vhecking out release modules, it was causing a huge slowdown in cvs actions. you can check out devel still i think but that is all.
I think checking out release modules still needs to be possible. If that means we need to use a read-only mirror to facilitate this, I'd be okay with it, but not being able to check out a tree is a pretty bad regression that I just ran into. For the record, it would make doing moz security updates much more scriptable as I don't need to rely on people telling me when their packages need to be added/dropped to the auto rebuilds.
Just a late followup to this.
With some changes checked in tonight this should be possible again.
a 'cvs co F-11' should get you all the F-11 branches of all packages. ;) (likewise F-9 , F-10, EL-4, EL-5 for epel).
kevin
devel@lists.stg.fedoraproject.org
-
Bill Nottingham -
Christopher Aillon -
Dennis Gilmore -
Karsten Hopp -
Kevin Fenzi -
Toshio Kuratomi