> The Buildbot has detected a new failure on builder svn-x64-ubuntu-gcc
> while building ASF Buildbot.
> Full details are available at:
> http://ci.apache.org/builders/svn-x64-ubuntu-gcc/builds/6128 > Buildbot URL: http://ci.apache.org/ > Buildslave for this Build: svn-x64-ubuntu
> Build Reason: scheduler
> Build Source Stamp: [branch subversion/trunk] 1385395
> Blamelist: stefan2
> BUILD FAILED: failed Build
> sincerely,
> -The Buildbot
What's happening here is the Perl bindings are failing.
core.c: In function ‘boot_SVN___Core’:
core.c:42819:5: error: expected expression before ‘/’ token
core.c:42819:37: error: too many decimal points in number
core.c:42812:3: warning: unused variable ‘items’ [-Wunused-variable]
Given that the bindings haven't been touched, it isn't failing on CentOS
and the code that's an issue is generated by SWIG. I believe that the
problem is because someone upgraded the version of SWIG from 2.0.4 to 2.0.7
somewhere between Friday and Sunday.
Current builds:
checking for swig... /usr/bin/swig
checking swig version... 2.0.7
Last successful build:
checking for swig... /usr/bin/swig
checking swig version... 2.0.4
By comparison the CentOS buildbot is at a much older version of SWIG:
checking for swig... /usr/bin/swig
checking swig version... 1.3.29
Was there a particular reason someone upgraded to 2.0.7? Can someone point
me in the right direction to find out who made this change? I'll dig into
this further tomorrow but it'd be useful if I had the context behind the
change to the slave.
On Tue, Sep 18, 2012 at 11:48 PM, Ben Reser <b...@reser.org> wrote:
> What's happening here is the Perl bindings are failing.
> core.c: In function ‘boot_SVN___Core’:
> core.c:42819:5: error: expected expression before ‘/’ token
> core.c:42819:37: error: too many decimal points in number
> core.c:42812:3: warning: unused variable ‘items’ [-Wunused-variable]
> Given that the bindings haven't been touched, it isn't failing on CentOS
> and the code that's an issue is generated by SWIG. I believe that the
> problem is because someone upgraded the version of SWIG from 2.0.4 to 2.0.7
> somewhere between Friday and Sunday.
> Current builds:
> checking for swig... /usr/bin/swig
> checking swig version... 2.0.7
> Last successful build:
> checking for swig... /usr/bin/swig
> checking swig version... 2.0.4
> By comparison the CentOS buildbot is at a much older version of SWIG:
> checking for swig... /usr/bin/swig
> checking swig version... 1.3.29
> Was there a particular reason someone upgraded to 2.0.7? Can someone
> point me in the right direction to find out who made this change? I'll dig
> into this further tomorrow but it'd be useful if I had the context behind
> the change to the slave.
So it's tomorrow now here in Seattle, went ahead and reproduced the issue.
The line it's erring out on is a C++ style comment:
// Casts only needed for Perl < 5.10.
which is inside an extern "C". So it's a SWIG bug. I've verified that
it's still present in 2.0.8.
Right now the perl bindings aren't building for me with 2.0.4, so I'm not
sure how that was working on the build bot before.
I'm heading to bed now. I'll report this to the swig folks tomorrow and
hopefully figure out why the perl bindings aren't building for me on 2.0.4.
<philip.mar...@wandisco.com> wrote:
> In build/ac-macros/swig.m4 the -ansi flag is explicltly removed for the
> Ruby bindings so that gcc accepts things like that.
Thanks, that worked. I've committed something to that effect in r1389658.
On Mon, Sep 24, 2012 at 8:02 PM, Ben Reser <b...@reser.org> wrote:
> On Wed, Sep 19, 2012 at 2:14 AM, Philip Martin
> <philip.mar...@wandisco.com> wrote:
>> In build/ac-macros/swig.m4 the -ansi flag is explicltly removed for the
>> Ruby bindings so that gcc accepts things like that.
> Thanks, that worked. I've committed something to that effect in r1389658.
The svn-x64-ubuntu-gcc bot currently lives in my basement, and was
recently upgraded to the latest Ubuntu beta release, which bumped a
number of dependency versions. The biggest issue with the bindings is
the bump to Ruby 1.9 which we explicitly don't support because the
tests are not currently compatible with it. It seems that Ruby 1.9 is
the Next Big Thing, and 1.8 is soon to unsupported, so a number of
distros are moving to it as the default.
I've spent the evening digging into what it would take to support Ruby
1.9, but my Ruby-fu is so weak that it'll be more than an evening for
me to actually make progress on the issue. I invite more capable
hands to join in the effort.
On Mon, Sep 24, 2012 at 7:38 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> The svn-x64-ubuntu-gcc bot currently lives in my basement, and was
> recently upgraded to the latest Ubuntu beta release, which bumped a
> number of dependency versions. The biggest issue with the bindings is
> the bump to Ruby 1.9 which we explicitly don't support because the
> tests are not currently compatible with it. It seems that Ruby 1.9 is
> the Next Big Thing, and 1.8 is soon to unsupported, so a number of
> distros are moving to it as the default.
> I've spent the evening digging into what it would take to support Ruby
> 1.9, but my Ruby-fu is so weak that it'll be more than an evening for
> me to actually make progress on the issue. I invite more capable
> hands to join in the effort.
Yeah I noticed the Ruby failure. If the machine running this buildbot
is being shared by some other use for you maybe we should split this
off. I have a KVM setup dedicated for Subversion work and would be
happy to host this slave as a dedicated guest. This would allow us to
have upgrades only when we wanted them for the specific build slave.
Obviously the work to move to 1.9 would still need to be done, but
there's really not much value in having our build bot fail on
something we're not expecting to work.
On Mon, Sep 24, 2012 at 11:15 PM, Ben Reser <b...@reser.org> wrote:
> On Mon, Sep 24, 2012 at 7:38 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> The svn-x64-ubuntu-gcc bot currently lives in my basement, and was
>> recently upgraded to the latest Ubuntu beta release, which bumped a
>> number of dependency versions. The biggest issue with the bindings is
>> the bump to Ruby 1.9 which we explicitly don't support because the
>> tests are not currently compatible with it. It seems that Ruby 1.9 is
>> the Next Big Thing, and 1.8 is soon to unsupported, so a number of
>> distros are moving to it as the default.
>> I've spent the evening digging into what it would take to support Ruby
>> 1.9, but my Ruby-fu is so weak that it'll be more than an evening for
>> me to actually make progress on the issue. I invite more capable
>> hands to join in the effort.
> Yeah I noticed the Ruby failure. If the machine running this buildbot
> is being shared by some other use for you maybe we should split this
> off. I have a KVM setup dedicated for Subversion work and would be
> happy to host this slave as a dedicated guest. This would allow us to
> have upgrades only when we wanted them for the specific build slave.
> Obviously the work to move to 1.9 would still need to be done, but
> there's really not much value in having our build bot fail on
> something we're not expecting to work.
For the time being, the Ruby build step and tests have been commented
out of the relevant scripts.
I think there is value in running a bot on a stock (albeit currently
beta) install of a popular Linux distribution. We don't control our
users' machines, and pretty soon many of them will be upgrading to the
latest Ubuntu. A not-insignificant-number of those people will
discover their Subversion Ruby scripts don't work anymore. This is
unfortunate, and the sooner we can find these problems, the better.
Running a bot in this type of environment is one way to do so. (Plus,
I haven't committed a line of code in 3 months: I have to do
_something_ to feel more useful than just kibitzing on dev@. :) )
You are, of course, welcome to run yet another bot with its own
configuration, but I recommend we still use this one.
On Mon, Sep 24, 2012 at 8:27 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> For the time being, the Ruby build step and tests have been commented
> out of the relevant scripts.
> I think there is value in running a bot on a stock (albeit currently
> beta) install of a popular Linux distribution. We don't control our
> users' machines, and pretty soon many of them will be upgrading to the
> latest Ubuntu. A not-insignificant-number of those people will
> discover their Subversion Ruby scripts don't work anymore. This is
> unfortunate, and the sooner we can find these problems, the better.
> Running a bot in this type of environment is one way to do so. (Plus,
> I haven't committed a line of code in 3 months: I have to do
> _something_ to feel more useful than just kibitzing on dev@. :) )
> You are, of course, welcome to run yet another bot with its own
> configuration, but I recommend we still use this one.
Well I agree there's value in that configuration, since as you rightly
point out it does alert us to upcoming issues. Coming from a
continuous delivery workplace here recently I was thinking that the
primary purpose of the buildbots was to alert us to breakage after
code changes. If the environment the build bot is running in is
changing out from under it, you can't tell at a glance that the build
was broken due to a code change or an environmental change on the
build bot.
> I've spent the evening digging into what it would take to support Ruby
> 1.9, but my Ruby-fu is so weak that it'll be more than an evening for
> me to actually make progress on the issue. I invite more capable
> hands to join in the effort.
There were patches submitted last year but I could not get them to work:
Philip Martin <philip.mar...@wandisco.com> writes:
> Hyrum K Wright <hy...@hyrumwright.org> writes:
>> I've spent the evening digging into what it would take to support Ruby
>> 1.9, but my Ruby-fu is so weak that it'll be more than an evening for
>> me to actually make progress on the issue. I invite more capable
>> hands to join in the effort.
> There were patches submitted last year but I could not get them to work:
On Tue, Sep 25, 2012 at 12:29 AM, Ben Reser <b...@reser.org> wrote:
> On Mon, Sep 24, 2012 at 8:27 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> For the time being, the Ruby build step and tests have been commented
>> out of the relevant scripts.
>> I think there is value in running a bot on a stock (albeit currently
>> beta) install of a popular Linux distribution. We don't control our
>> users' machines, and pretty soon many of them will be upgrading to the
>> latest Ubuntu. A not-insignificant-number of those people will
>> discover their Subversion Ruby scripts don't work anymore. This is
>> unfortunate, and the sooner we can find these problems, the better.
>> Running a bot in this type of environment is one way to do so. (Plus,
>> I haven't committed a line of code in 3 months: I have to do
>> _something_ to feel more useful than just kibitzing on dev@. :) )
>> You are, of course, welcome to run yet another bot with its own
>> configuration, but I recommend we still use this one.
> Well I agree there's value in that configuration, since as you rightly
> point out it does alert us to upcoming issues. Coming from a
> continuous delivery workplace here recently I was thinking that the
> primary purpose of the buildbots was to alert us to breakage after
> code changes. If the environment the build bot is running in is
> changing out from under it, you can't tell at a glance that the build
> was broken due to a code change or an environmental change on the
> build bot.
Good point: it does require extra dev time to answer that question in
the case of false negatives.
Incidentally, I'm still seeing swig-pl build errors on that bot. From
reading above, I thought these were addressed. Is that correct?
On Thu, Sep 27, 2012 at 9:10 PM, <build...@apache.org> wrote:
> The Buildbot has detected a new failure on builder svn-x64-ubuntu-gcc while building ASF Buildbot.
> Full details are available at:
> http://ci.apache.org/builders/svn-x64-ubuntu-gcc/builds/6234
