building "master" under mock buildroot
All, I'm preparing a FreeRADIUS 3 RPM, in the hope we can move to a pre-release of the "master" branch, for a bit of soak testing but also because I'm tired of backporting stuff to our local 2.x branch ;o) Sadly, the source builds fine in the "native" OS, but doesn't build under "mock" (and RPM "build in chroot" tool). I'm extremely reluctant to deviate from our normal build procedures. The errors at the end of the log are pretty mysterious: + make gcc /builddir/build/BUILD/freeradius3-3.0.0pre1/scripts/jlibtool.c -o /builddir/build/BUILD/freeradius3-3.0.0pre1/scripts/jlibtool /builddir/build/BUILD/freeradius3-3.0.0pre1/scripts/jlibtool.c: In function 'parse_args': /builddir/build/BUILD/freeradius3-3.0.0pre1/scripts/jlibtool.c:1771: warning: assignment discards qualifiers from pointer target type Making all in src... ln -sf include freeradius-devel Making all in src/include... gmake[4]: *** [features.h] Error 1 gmake[3]: *** [include] Error 2 gmake[2]: *** [all] Error 2 gmake[1]: *** [src] Error 2 RPM build errors: make: *** [all] Error 2 More annoying, if I "mock shell" into the buildroot and re-try "make", it all works fine. I can't see any obvious culprits such as an environment variable further up. Does anyone have any idea what could cause the build to fail in this way, with those gmake errors?
Phil Mayers wrote:
Making all in src/include... gmake[4]: *** [features.h] Error 1
Ah. I had fixed that for the new make, but not the old system. I've pushed a fix.
More annoying, if I "mock shell" into the buildroot and re-try "make", it all works fine. I can't see any obvious culprits such as an environment variable further up.
Does anyone have any idea what could cause the build to fail in this way, with those gmake errors?
grep doesn't need "-o". The mock shell probably implements a limited grep. Alan DeKok.
On 15/11/12 13:15, Alan DeKok wrote:
Phil Mayers wrote:
Making all in src/include... gmake[4]: *** [features.h] Error 1
Ah. I had fixed that for the new make, but not the old system. I've pushed a fix.
That's not it sadly :o(
More annoying, if I "mock shell" into the buildroot and re-try "make", it all works fine. I can't see any obvious culprits such as an environment variable further up.
Does anyone have any idea what could cause the build to fail in this way, with those gmake errors?
grep doesn't need "-o". The mock shell probably implements a limited grep.
Well... it's hard to tell. The "mock" buildroot is just a minimal linux install, but it has all the standard GNU utils - there's nothing weird about /bin/grep in it. I can't speak for what "rpmbuild" is setup to do inside "mock", however, and I suspect that it might be aliasing or otherwise fiddling with what "@grep" ends up pointing to. I've no idea how to troubleshoot that, though... I hate building software...
On 15/11/12 13:37, Phil Mayers wrote:
On 15/11/12 13:15, Alan DeKok wrote:
Phil Mayers wrote:
Making all in src/include... gmake[4]: *** [features.h] Error 1
Ah. I had fixed that for the new make, but not the old system. I've pushed a fix.
That's not it sadly :o(
Ok, I know what it is. If your locale is UTF-8, grep defaults to using PCRE regexps it seems. The existing regexp is such: grep "^\#define\s*WITH_.*" autoconf.h Note the "\s". However, inside the rpmbuild environment, this doesn't work, though "grep -P" explicitly does. I suspect it would be safer to avoid PCRE in grep, and use this: egrep '^#define[[:space:]]+WITH_.*' ...which also works. I had to hook onto the "Makefile" with a "bash" callout to find this out!
On 15/11/12 15:27, Phil Mayers wrote:
On 15/11/12 13:37, Phil Mayers wrote:
On 15/11/12 13:15, Alan DeKok wrote:
Phil Mayers wrote:
Making all in src/include... gmake[4]: *** [features.h] Error 1
Ah. I had fixed that for the new make, but not the old system. I've pushed a fix.
That's not it sadly :o(
Ok, I know what it is.
I opened a "pull" request with that and an rlm_rediswho build fix.
On 15 Nov 2012, at 16:08, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 15/11/12 15:27, Phil Mayers wrote:
On 15/11/12 13:37, Phil Mayers wrote:
On 15/11/12 13:15, Alan DeKok wrote:
Phil Mayers wrote:
Making all in src/include... gmake[4]: *** [features.h] Error 1
Ah. I had fixed that for the new make, but not the old system. I've pushed a fix.
That's not it sadly :o(
Ok, I know what it is.
I opened a "pull" request with that and an rlm_rediswho build fix.
Regarding the patches: * grep works fine if you stick with BREs (I don't believe we use egrep directly in any of the existing configure.in files and it seems best to stick with the simplest and most widely available implementation) * PCAP_NETMASK_UNKNOWN is actually defined as: #define PCAP_NETMASK_UNKNOWN 0xffffffff In recent versions. * I'll pull the fixes for redis in manually (Thanks!) -Arran
On 15/11/12 17:20, Arran Cudbard-Bell wrote:
Regarding the patches: * grep works fine if you stick with BREs
Sure, whatever works.
* PCAP_NETMASK_UNKNOWN is actually defined as: #define PCAP_NETMASK_UNKNOWN 0xffffffff
I was basing that off here: http://seclists.org/wireshark/2010/Jul/113 ...which implies (at a quick glance) that you're expected to pass in "0" in older code. But I didn't "git log" the file to see what the old code did. Again - whatever works, not fussed.
In recent versions.
* I'll pull the fixes for redis in manually (Thanks!)
Yeah... I've got some more, but I'll wait until you've done your bit before opening a "pull".
On 15 Nov 2012, at 18:21, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 15/11/12 17:20, Arran Cudbard-Bell wrote:
Regarding the patches: * grep works fine if you stick with BREs
Sure, whatever works.
* PCAP_NETMASK_UNKNOWN is actually defined as: #define PCAP_NETMASK_UNKNOWN 0xffffffff
I was basing that off here:
http://seclists.org/wireshark/2010/Jul/113
...which implies (at a quick glance) that you're expected to pass in "0" in older code. But I didn't "git log" the file to see what the old code did.
Again - whatever works, not fussed.
Ah ok. I've seen people submitting similar patches to other projects that set all the bits high, but I guess the libpcap developers know best. It's not even used in radsniff unless people want to do their own custom ip filters.
In recent versions.
* I'll pull the fixes for redis in manually (Thanks!)
Yeah... I've got some more, but I'll wait until you've done your bit before opening a "pull".
Done. Yeah there were some pretty poor typos, looks like no one's actually tried to build that code in a while. We really need to get an automated build system setup again. Even if the server is almost completely devoid of unit tests and functional tests we can at least make sure the modules compile. -Arran
On 11/16/2012 10:55 AM, Arran Cudbard-Bell wrote:
Done. Yeah there were some pretty poor typos, looks like no one's actually tried to build that code in a while. We really need to get an automated build system setup again.
Even if the server is almost completely devoid of unit tests and functional tests we can at least make sure the modules compile.
I was wondering about that recently. It doesn't seem so terribly hard to have a "tests/" directory containing some known-good server configs testing various functionality, and a shell script driving auth requests into it via radtest/eapol_test. Sort of like "make test" in ISC bind. Unit tests - well, that might be trickier, I guess. Are there any decent C unittest frameworks?
On 16 Nov 2012, at 11:11, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 11/16/2012 10:55 AM, Arran Cudbard-Bell wrote:
Done. Yeah there were some pretty poor typos, looks like no one's actually tried to build that code in a while. We really need to get an automated build system setup again.
Even if the server is almost completely devoid of unit tests and functional tests we can at least make sure the modules compile.
I was wondering about that recently. It doesn't seem so terribly hard to have a "tests/" directory containing some known-good server configs testing various functionality, and a shell script driving auth requests into it via radtest/eapol_test. Sort of like "make test" in ISC bind.
git pull ./configure make make tests These were originally added by a guy at Mancala networks, they test basic functionality and have caught some issues in the past. It might be good to expand them.
Unit tests - well, that might be trickier, I guess. Are there any decent C unittest frameworks?
lua-TestMore and LuaJIT might be an interesting solution, though it would only allow you to test exposed library functions which would limit how much testing you could do with modules. -Arran
Arran Cudbard-Bell wrote:
These were originally added by a guy at Mancala networks,
Uh, no. I wrote most of them, including the test framework Others contributed a few tests.
they test basic functionality and have caught some issues in the past. It might be good to expand them.
Yes. There's a *lot* of functionality in the server. We could very well have 1000 small individual tests. Alan DeKok.
On 16 Nov 2012, at 15:46, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
These were originally added by a guy at Mancala networks,
Uh, no. I wrote most of them, including the test framework Others contributed a few tests.
Ah sorry. Well technically you were also a guy at Mancala networks :)
they test basic functionality and have caught some issues in the past. It might be good to expand them.
Yes.
There's a *lot* of functionality in the server. We could very well have 1000 small individual tests.
What do you think about the LuaJIT idea? There's been murmerings of an automated header parser on the LuaJIT list. -Arran
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers