Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On Fri, Nov 25, 2011 at 06:49:13PM +0100, Nils Philippsen wrote: On Thu, 2011-11-24 at 17:26 +0100, Jim Meyering wrote: config.h: rm -f $@ $@-t; \ I'd rather not remove the target right at the beginning... Why not? You don't really know what 'config.h' is. It might have been set to something weird like a link or device. 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: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On Wed, Nov 23, 2011 at 10:20:50AM -0500, Kaleb S. KEITHLEY wrote: On 11/23/2011 10:08 AM, Orion Poplawski wrote: On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote: I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...` respectively. I can also build using mock, both x86_64 and i386, with `mock -r epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...` respectively. In all the above cases I get all the expected RPMs and the build.log shows no errors. But when I do a `fedpkg build` or a `koji --scratch ...` in the el6 branch of my fedora-scm tree the builds fall down with an error compiling a y.tab.c file. Suffice it to say it builds for f16 and rawhide just fine using the exact same sources and spec file. Build logs aren't particularly helpful and since they succeed in mock and rpmbuild I can't debug the build issue locally. Obviously there's a compile error of the y.tab.c file, but I can't see why it doesn't work in koji when it does work everywhere else. Perhaps there's some extra fedpkg flag I should be using for epel builds? Perhaps try without parallel make? Yes, that makes it work. This might indicate a bug in the Makefile, so really that should be fixed. If you could point to the place in the source where it fails, then we could take a look. Parallel makes are desirable, particularly on modern multicore processors where each core might be slow but you've got lots of them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On 11/24/2011 01:54 PM, Richard W.M. Jones wrote: On Wed, Nov 23, 2011 at 10:20:50AM -0500, Kaleb S. KEITHLEY wrote: On 11/23/2011 10:08 AM, Orion Poplawski wrote: On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote: I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...` respectively. I can also build using mock, both x86_64 and i386, with `mock -r epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...` respectively. In all the above cases I get all the expected RPMs and the build.log shows no errors. But when I do a `fedpkg build` or a `koji --scratch ...` in the el6 branch of my fedora-scm tree the builds fall down with an error compiling a y.tab.c file. Suffice it to say it builds for f16 and rawhide just fine using the exact same sources and spec file. Build logs aren't particularly helpful and since they succeed in mock and rpmbuild I can't debug the build issue locally. Obviously there's a compile error of the y.tab.c file, but I can't see why it doesn't work in koji when it does work everywhere else. Perhaps there's some extra fedpkg flag I should be using for epel builds? Perhaps try without parallel make? Yes, that makes it work. This might indicate a bug in the Makefile, so really that should be fixed. If you could point to the place in the source where it fails, then we could take a look. Parallel makes are desirable, particularly on modern multicore processors where each core might be slow but you've got lots of them. The Fedora buildsystem is particularly good at rooting out parallel build issues due to its very high parallelism, as I found out recently when it uncovered a long-standing build issue in pptp: http://marc.info/?l=pptpclient-develm=132102054518031 Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote: http://marc.info/?l=pptpclient-develm=132102054518031 This is indeed rather unexpected behaviour of make! BTW I think your patch is incomplete, since it will create an incomplete config.h if the disk runs out of space. I think this would be better, and should also avoid the parallel make problem: config.h: echo /* text added by Makefile target config.h */ $@-t echo #define PPTP_LINUX_VERSION \$(VERSION)$(RELEASE)\ $@-t echo #define PPPD_BINARY \$(PPPD)\ $@-t echo #define IP_BINARY \$(IP)\ $@-t mv $@-t $@ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
Richard W.M. Jones wrote:
On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
http://marc.info/?l=pptpclient-develm=132102054518031
This is indeed rather unexpected behaviour of make!
BTW I think your patch is incomplete, since it will create an
incomplete config.h if the disk runs out of space. I think this would
be better, and should also avoid the parallel make problem:
config.h:
echo /* text added by Makefile target config.h */ $@-t
echo #define PPTP_LINUX_VERSION \$(VERSION)$(RELEASE)\ $@-t
echo #define PPPD_BINARY \$(PPPD)\ $@-t
echo #define IP_BINARY \$(IP)\ $@-t
mv $@-t $@
Yes, that is better and does solve the problem.
Here's a good rule I've been following since I was first burned by this:
never redirect directly to a Makefile target. (where target means $@
or any literal that is equivalent). That means redirect output to a
temporary file like Rich did above, and only when that process is known
to have succeeded do you rename the temporary file to $@.
However, I would volunteer some additional suggestions:
- use a {...} group (cheaper than a (...) subshell) so we redirect only once;
that reduces the duplication of the $@-t, and eliminates the dichotomy
of the initial $@-t, while all subsequent ones are $@-t.
- use outer single quotes so you don't have to backslash-escape the
inner double quote chars. less syntax is more maintainable.
- make the file read-only, so it is clearer that it is generated,
and thus harder to change accidentally. The only down-side to
this part is that you then have to be careful to remove any
preexisting $@ or $@-t, since redirecting onto a read-only file
will often fail.
config.h:
rm -f $@ $@-t; \
{ \
echo '/* text added by Makefile target config.h */'; \
echo '#define PPTP_LINUX_VERSION $(VERSION)$(RELEASE)'; \
echo '#define PPPD_BINARY $(PPPD)'; \
echo '#define IP_BINARY $(IP)'; \
} $@-t chmod a-w $@-t mv $@-t $@
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
Kaleb S. KEITHLEY wrote:
...
Perhaps there's some extra fedpkg flag I should be using for epel builds?
Perhaps try without parallel make?
Yes, that makes it work.
Thanks for the tip.
When running make from the command line, I always use -j$N, for 1 N.
But of course, I rarely type the -j option.
Not only do builds complete more quickly, but doing that
helps flush out problems like yours.
I run this shell code to create an alias:
_make_init()
{
local n=$(nproc 2/dev/null || getconf _NPROCESSORS_ONLN 2/dev/null)
test $n -gt 0 \
|| n=$(grep -c '^processor :' /proc/cpuinfo 2/dev/null)
case $n in 0) n=1;; esac
local make_j=$((2 * $n + 1))
# Create an alias for make that uses -j$N, where $N is determined
# once at shell start-up.
alias make=make -j$make_j
}
_make_init
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
epel 6 fedpkg build or koji scratch builds failing — I'm stumped
I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...` respectively. I can also build using mock, both x86_64 and i386, with `mock -r epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...` respectively. In all the above cases I get all the expected RPMs and the build.log shows no errors. But when I do a `fedpkg build` or a `koji --scratch ...` in the el6 branch of my fedora-scm tree the builds fall down with an error compiling a y.tab.c file. Suffice it to say it builds for f16 and rawhide just fine using the exact same sources and spec file. Build logs aren't particularly helpful and since they succeed in mock and rpmbuild I can't debug the build issue locally. Obviously there's a compile error of the y.tab.c file, but I can't see why it doesn't work in koji when it does work everywhere else. Perhaps there's some extra fedpkg flag I should be using for epel builds? -- K -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote: I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...` respectively. I can also build using mock, both x86_64 and i386, with `mock -r epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...` respectively. In all the above cases I get all the expected RPMs and the build.log shows no errors. But when I do a `fedpkg build` or a `koji --scratch ...` in the el6 branch of my fedora-scm tree the builds fall down with an error compiling a y.tab.c file. Suffice it to say it builds for f16 and rawhide just fine using the exact same sources and spec file. Build logs aren't particularly helpful and since they succeed in mock and rpmbuild I can't debug the build issue locally. Obviously there's a compile error of the y.tab.c file, but I can't see why it doesn't work in koji when it does work everywhere else. Perhaps there's some extra fedpkg flag I should be using for epel builds? Perhaps try without parallel make? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 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: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On 11/23/2011 10:08 AM, Orion Poplawski wrote: On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote: I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...` respectively. I can also build using mock, both x86_64 and i386, with `mock -r epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...` respectively. In all the above cases I get all the expected RPMs and the build.log shows no errors. But when I do a `fedpkg build` or a `koji --scratch ...` in the el6 branch of my fedora-scm tree the builds fall down with an error compiling a y.tab.c file. Suffice it to say it builds for f16 and rawhide just fine using the exact same sources and spec file. Build logs aren't particularly helpful and since they succeed in mock and rpmbuild I can't debug the build issue locally. Obviously there's a compile error of the y.tab.c file, but I can't see why it doesn't work in koji when it does work everywhere else. Perhaps there's some extra fedpkg flag I should be using for epel builds? Perhaps try without parallel make? Yes, that makes it work. Thanks for the tip. Regards, -- K -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
