You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@infra.apache.org by "Uwe Schindler (Created) (JIRA)" <ji...@apache.org> on 2012/03/07 08:44:02 UTC
[jira] [Created] (INFRA-4521) Jenkins-built in SVN (Tmatesoft, 1.6
compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
-----------------------------------------------------------------------------------------------------------------------------------------
Key: INFRA-4521
URL: https://issues.apache.org/jira/browse/INFRA-4521
Project: Infrastructure
Issue Type: Bug
Security Level: public (Regular issues)
Components: Jenkins
Environment: FreeBSD 9 Jail, lucene.zones.apache.org
Reporter: Uwe Schindler
Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apachje.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
The points for discussion:
- Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
- If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
- If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "#asfinfra IRC Bot (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224100#comment-13224100 ]
#asfinfra IRC Bot commented on INFRA-4521:
------------------------------------------
<danielsh> summary: need to upgrade the jenkins slave to use a newer svnkit, that supports svn 1.7
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224153#comment-13224153 ]
Uwe Schindler commented on INFRA-4521:
--------------------------------------
Oliver: Yes thats the problem, the build does two things:
- using "svnversion" to get the current revision no and put it into the JAR manifest (this one is optional here, if the svnversion call does not succeed it simply puts no rev in the JAR). This is done by our ANT build.
- the serious issue we had is a more complex one (I don't really agree what is done here, but that was the only solution to solve several problems with source artifacts): When building the -src.tar.gz file, the ANT build script fetches the revision number and svn URL from the CLI and then executes "svn export" into a temporary dir for packaging the -src.tgz.
Using svnkit inside ANT is not an option for us, because we would have to bundle the svnkit jar file with our src-distribution, which is a no-go. Also this would limit people building lucene from source in the version of SVN they can use.
We solved the issue temporarily by installing svn 1.6 on the jenkins slave, but Daniel said on #asfinfra, that this could lead to problems on upgrades, because svn 1.6 conflicts with svn 1.7. The other option would be to use statically linked svn for now (I am investigating that).
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "#asfinfra IRC Bot (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224086#comment-13224086 ]
#asfinfra IRC Bot commented on INFRA-4521:
------------------------------------------
<danielsh> Preferred solution: upgrade jenkins' svn interface library. Alternatives: keep an svn1.6 static binary around, or make your build work on svn 1.6 wc's without needing svn 1.6 binaries. I can help with the last one if the former isn't feasible
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Gavin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225745#comment-13225745 ]
Gavin commented on INFRA-4521:
------------------------------
So are we now closing this issue as 'nothing to do' from our end?
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (INFRA-4521) Jenkins-built in SVN (Tmatesoft, 1.6
compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Niklas Gustavsson (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niklas Gustavsson closed INFRA-4521.
------------------------------------
Resolution: Fixed
It's probably better to have an issue for such an upgrade in the Jenkins JIRA instance (https://issues.jenkins-ci.org), rather than here at ASF. So, closing this for now.
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Olivier Lamy (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224112#comment-13224112 ]
Olivier Lamy commented on INFRA-4521:
-------------------------------------
NOTE for some license reason Jenkins doesn't and cannot include last svnkit version. The current included svnkit is based on a fork before license changed. Maybe the workaround could be about doing a new Jenkins plugin which include last svnkit for 1.7 but this cannot be included in Jenkins distribution.
BTW Uwe what your build is doing ? parsing result of svn cli to get rev ? Could you simply do it with svnkit previous version ?
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (INFRA-4521) Jenkins-built in SVN
(Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on
the upgraded FreeBSD slaves for some builds
Posted by "Uwe Schindler (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224206#comment-13224206 ]
Uwe Schindler edited comment on INFRA-4521 at 3/7/12 11:36 AM:
---------------------------------------------------------------
I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.
The last build was triggered like that:
/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion -Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz
I think thats a good solution for now. My comment from earlier that we have to bundle svnkit with our src repository is no longer valid, as we use the "emulated cli" from svnkit as replacement to native svn.
was (Author: thetaphi):
I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.
The last build was triggered like that:
{noformat}
/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion -Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz
{noformat}
I think thats a good solution for now. My comment from earlier that we have to bundle svnkit with our build is no longer valid, as we use the "emulated cli" from svnkit as replacement to native svn.
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224206#comment-13224206 ]
Uwe Schindler commented on INFRA-4521:
--------------------------------------
I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.
The last build was triggered like that:
{noformat}
/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion -Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz
{noformat}
I think thats a good solution for now. My comment from earlier that we have to bundle svnkit with our build is no longer valid, as we use the "emulated cli" from svnkit as replacement to native svn.
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Uwe Schindler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225908#comment-13225908 ]
Uwe Schindler commented on INFRA-4521:
--------------------------------------
I would like to still have a "TODO" item, so Jenkins itssef gets updated to SVN 1.7.
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (INFRA-4521) Jenkins-built in SVN (Tmatesoft,
1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "#asfinfra IRC Bot (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224082#comment-13224082 ]
#asfinfra IRC Bot commented on INFRA-4521:
------------------------------------------
<danielsh> First of all, please ensure your 'make install' does not re-fetch the distfiles on every build.
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (INFRA-4521) Jenkins-built in SVN (Tmatesoft, 1.6
compatible) conflicts with system-installed SVN (1.7) on the upgraded
FreeBSD slaves for some builds
Posted by "Uwe Schindler (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated INFRA-4521:
---------------------------------
Description:
Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
The points for discussion:
- Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
- If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
- If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
was:
Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apachje.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
The points for discussion:
- Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
- If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
- If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: INFRA-4521
> URL: https://issues.apache.org/jira/browse/INFRA-4521
> Project: Infrastructure
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Jenkins
> Environment: FreeBSD 9 Jail, lucene.zones.apache.org
> Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira