test-patch and native code compile
Hi, The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile. For e.g we run into HADOOP-7147 that has been resolved as Won't fix. Hence, should we have a switch in test-patch to not run native compile ? Could open a JIRA and fix, if that's OK ? Thanks hemanth
[jira] [Created] (HADOOP-8773) Improve Server#getRemoteAddress by utilizing Server.Connection.hostAddress
binlijin created HADOOP-8773: Summary: Improve Server#getRemoteAddress by utilizing Server.Connection.hostAddress Key: HADOOP-8773 URL: https://issues.apache.org/jira/browse/HADOOP-8773 Project: Hadoop Common Issue Type: Improvement Reporter: binlijin Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Build failed in Jenkins: Hadoop-Common-trunk #525
See https://builds.apache.org/job/Hadoop-Common-trunk/525/changes Changes: [eli] HDFS-3828. Block Scanner rescans blocks too frequently. Contributed by Andy Isaacson [tgraves] YARN-87. NM ResourceLocalizationService does not set permissions of local cache directories (Jason Lowe via tgraves) [atm] HADOOP-8766. FileContextMainOperationsBaseTest should randomize the root dir. Contributed by Colin Patrick McCabe. [eli] HADOOP-8648. libhadoop: native CRC32 validation crashes when io.bytes.per.checksum=1. Contributed by Colin Patrick McCabe [eli] HADOOP-8770. NN should not RPC to self to find trash defaults. Contributed by Eli Collins [bobby] YARN-68. NodeManager will refuse to shutdown indefinitely due to container log aggregation (daryn via bobby) [eli] Fix MAPREDUCE-4580 build breakage. [todd] HDFS-3054. distcp -skipcrccheck has no effect. Contributed by Colin Patrick McCabe. [vinodkv] YARN-83. Change package of YarnClient to org.apache.hadoop. Contributed by Bikas Saha. -- [...truncated 26411 lines...] [DEBUG] (s) debug = false [DEBUG] (s) effort = Default [DEBUG] (s) failOnError = true [DEBUG] (s) findbugsXmlOutput = false [DEBUG] (s) findbugsXmlOutputDirectory = https://builds.apache.org/job/Hadoop-Common-trunk/ws/trunk/hadoop-common-project/target [DEBUG] (s) fork = true [DEBUG] (s) includeTests = false [DEBUG] (s) localRepository =id: local url: file:///home/jenkins/.m2/repository/ layout: none [DEBUG] (s) maxHeap = 512 [DEBUG] (s) nested = false [DEBUG] (s) outputDirectory = https://builds.apache.org/job/Hadoop-Common-trunk/ws/trunk/hadoop-common-project/target/site [DEBUG] (s) outputEncoding = UTF-8 [DEBUG] (s) pluginArtifacts = [org.codehaus.mojo:findbugs-maven-plugin:maven-plugin:2.3.2:, com.google.code.findbugs:bcel:jar:1.3.9:compile, org.codehaus.gmaven:gmaven-mojo:jar:1.3:compile, org.codehaus.gmaven.runtime:gmaven-runtime-api:jar:1.3:compile, org.codehaus.gmaven.feature:gmaven-feature-api:jar:1.3:compile, org.codehaus.gmaven.runtime:gmaven-runtime-1.5:jar:1.3:compile, org.codehaus.gmaven.feature:gmaven-feature-support:jar:1.3:compile, org.codehaus.groovy:groovy-all-minimal:jar:1.5.8:compile, org.apache.ant:ant:jar:1.7.1:compile, org.apache.ant:ant-launcher:jar:1.7.1:compile, jline:jline:jar:0.9.94:compile, org.codehaus.plexus:plexus-interpolation:jar:1.1:compile, org.codehaus.gmaven:gmaven-plugin:jar:1.3:compile, org.codehaus.gmaven.runtime:gmaven-runtime-loader:jar:1.3:compile, org.codehaus.gmaven.runtime:gmaven-runtime-support:jar:1.3:compile, org.sonatype.gshell:gshell-io:jar:2.0:compile, com.thoughtworks.qdox:qdox:jar:1.10:compile, org.apache.maven.shared:file-management:jar:1.2.1:compile, org.apache.maven.shared:maven-shared-io:jar:1.1:compile, commons-lang:commons-lang:jar:2.4:compile, org.slf4j:slf4j-api:jar:1.5.10:compile, org.sonatype.gossip:gossip:jar:1.2:compile, org.apache.maven.reporting:maven-reporting-impl:jar:2.1:compile, commons-validator:commons-validator:jar:1.2.0:compile, commons-beanutils:commons-beanutils:jar:1.7.0:compile, commons-digester:commons-digester:jar:1.6:compile, commons-logging:commons-logging:jar:1.0.4:compile, oro:oro:jar:2.0.8:compile, xml-apis:xml-apis:jar:1.0.b2:compile, org.codehaus.groovy:groovy-all:jar:1.7.4:compile, org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile, org.apache.maven.doxia:doxia-core:jar:1.1.3:compile, org.apache.maven.doxia:doxia-logging-api:jar:1.1.3:compile, xerces:xercesImpl:jar:2.9.1:compile, commons-httpclient:commons-httpclient:jar:3.1:compile, commons-codec:commons-codec:jar:1.2:compile, org.apache.maven.doxia:doxia-sink-api:jar:1.1.3:compile, org.apache.maven.doxia:doxia-decoration-model:jar:1.1.3:compile, org.apache.maven.doxia:doxia-site-renderer:jar:1.1.3:compile, org.apache.maven.doxia:doxia-module-xhtml:jar:1.1.3:compile, org.apache.maven.doxia:doxia-module-fml:jar:1.1.3:compile, org.codehaus.plexus:plexus-i18n:jar:1.0-beta-7:compile, org.codehaus.plexus:plexus-velocity:jar:1.1.7:compile, org.apache.velocity:velocity:jar:1.5:compile, commons-collections:commons-collections:jar:3.2:compile, org.apache.maven.shared:maven-doxia-tools:jar:1.2.1:compile, commons-io:commons-io:jar:1.4:compile, com.google.code.findbugs:findbugs-ant:jar:1.3.9:compile, com.google.code.findbugs:findbugs:jar:1.3.9:compile, com.google.code.findbugs:jsr305:jar:1.3.9:compile, com.google.code.findbugs:jFormatString:jar:1.3.9:compile, com.google.code.findbugs:annotations:jar:1.3.9:compile, dom4j:dom4j:jar:1.6.1:compile, jaxen:jaxen:jar:1.1.1:compile, jdom:jdom:jar:1.0:compile, xom:xom:jar:1.0:compile, xerces:xmlParserAPIs:jar:2.6.2:compile, xalan:xalan:jar:2.6.0:compile, com.ibm.icu:icu4j:jar:2.6.1:compile, asm:asm:jar:3.1:compile, asm:asm-analysis:jar:3.1:compile, asm:asm-commons:jar:3.1:compile, asm:asm-util:jar:3.1:compile, asm:asm-tree:jar:3.1:compile,
[jira] [Resolved] (HADOOP-8487) Many HDFS tests use a test path intended for local file system tests
[ https://issues.apache.org/jira/browse/HADOOP-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Mitic resolved HADOOP-8487. Resolution: Fixed Resolving as this is committed to branch-1-win. This way, the state of active Jiras is up to date under HADOOP-8645. Will reference this Jira once we get to fixing this in trunk. Many HDFS tests use a test path intended for local file system tests Key: HADOOP-8487 URL: https://issues.apache.org/jira/browse/HADOOP-8487 Project: Hadoop Common Issue Type: Bug Components: test Reporter: Ivan Mitic Assignee: Ivan Mitic Attachments: HADOOP-8487-branch-1-win(2).patch, HADOOP-8487-branch-1-win(3).patch, HADOOP-8487-branch-1-win(3).update.patch, HADOOP-8487-branch-1-win.alternate.patch, HADOOP-8487-branch-1-win.patch Many tests use a test path intended for local tests setup by build environment. In some cases the tests fails on platforms such as windows because the path contains a c: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: test-patch and native code compile
Makes sense, though the Jenkins runs should continue to run w/ native, right? On Thu, Sep 6, 2012 at 12:49 AM, Hemanth Yamijala yhema...@gmail.com wrote: Hi, The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile. For e.g we run into HADOOP-7147 that has been resolved as Won't fix. Hence, should we have a switch in test-patch to not run native compile ? Could open a JIRA and fix, if that's OK ? Thanks hemanth -- Alejandro
Re: test-patch and native code compile
Yea we want jenkins to run with native. How about adding making native optional in test-patch via a flag and updating the jenkins jobs to use it? On Thu, Sep 6, 2012 at 7:25 AM, Alejandro Abdelnur t...@cloudera.com wrote: Makes sense, though the Jenkins runs should continue to run w/ native, right? On Thu, Sep 6, 2012 at 12:49 AM, Hemanth Yamijala yhema...@gmail.com wrote: Hi, The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile. For e.g we run into HADOOP-7147 that has been resolved as Won't fix. Hence, should we have a switch in test-patch to not run native compile ? Could open a JIRA and fix, if that's OK ? Thanks hemanth -- Alejandro
[jira] [Resolved] (HADOOP-8583) Globbing is not correctly handled in a few cases on Windows
[
https://issues.apache.org/jira/browse/HADOOP-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Li resolved HADOOP-8583.
Resolution: Duplicate
dup of HADOOP-8739
Globbing is not correctly handled in a few cases on Windows
---
Key: HADOOP-8583
URL: https://issues.apache.org/jira/browse/HADOOP-8583
Project: Hadoop Common
Issue Type: Bug
Environment: Windows
Reporter: Ramya Sunil
Glob handling fails in a few cases on a Windows environment.
For example:
{noformat}
c:\ hadoop dfs -ls /
Found 2 items
drwxrwxrwx - Administrator supergroup 0 2012-07-06 15:00 /tmp
drwxr-xr-x - Administrator supergroup 0 2012-07-06 18:52 /user
c:\ hadoop dfs -ls /tmpInvalid*
Found 2 items
drwxr-xr-x - Administrator supergroup 0 2012-07-10 18:50
/user/Administrator/sortInputDir
drwxr-xr-x - Administrator supergroup 0 2012-07-10 18:50
/user/Administrator/sortOutputDir
c:\ hadoop dfs -rmr /tmp/*
Usage: java FsShell [-rmr [-skipTrash] src ]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Branch 2 release names
On Wed, Sep 5, 2012 at 11:04 AM, Andrew Purtell apurt...@apache.org wrote: If it's all the same to you, I'd prefer you leave the branch, or at least a tag, and just ignore it. We're pretty far away from branch-2.1.0 following branch-2 but started from that point. Subversion you don't actually ever delete anything. For example, I've deleted the branch-0.20-append, but you can still get it from: % svn ls https://svn.apache.org/repos/asf/hadoop/common/branches/branch-0.20-append@1380308 Given that would you like a dev branch (hbase-branch-2.0?)? -- Owen
Re: Branch 2 release names
No, thanks Owen. On Thu, Sep 6, 2012 at 9:27 AM, Owen O'Malley omal...@apache.org wrote: On Wed, Sep 5, 2012 at 11:04 AM, Andrew Purtell apurt...@apache.org wrote: If it's all the same to you, I'd prefer you leave the branch, or at least a tag, and just ignore it. We're pretty far away from branch-2.1.0 following branch-2 but started from that point. Subversion you don't actually ever delete anything. For example, I've deleted the branch-0.20-append, but you can still get it from: % svn ls https://svn.apache.org/repos/asf/hadoop/common/branches/branch-0.20-append@1380308 Given that would you like a dev branch (hbase-branch-2.0?)? -- Owen
Re: Branch 2 release names
Sounds fine. For now, I think we can delete branch-2.1.0-alpha, create branch-2.0.2-alpha release off branch-2 and eventually make branch-2.1.0 as the stable release in the future. Arun On Sep 4, 2012, at 11:55 AM, Owen O'Malley wrote: While cleaning up the subversion branches, I thought more about the branch 2 release names. I'm concerned if we backtrack and reuse release numbers it will be extremely confusing to users. It also creates problems for tools like Maven that parse version numbers and expect a left to right release numbering scheme (eg. 2.1.1-alpha 2.1.0). It also seems better to keep on the 2.0.x minor release until after we get a GA release off of the 2.0 branch. Therefore, I'd like to propose: 1. rename branch-2.0.1-alpha - branch-2.0 2. delete branch-2.1.0-alpha 3. stabilizing goes into branch-2.0 until it gets to GA 4. features go into branch-2 and will be branched into branch-2.1 later 5. The release tags can have the alpha/beta tags on them. Thoughts? -- Owen -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
[jira] [Created] (HADOOP-8774) Incorrect maven configuration causes mrapp-generated-classpath file to be generated in multiple places
Hitesh Shah created HADOOP-8774: --- Summary: Incorrect maven configuration causes mrapp-generated-classpath file to be generated in multiple places Key: HADOOP-8774 URL: https://issues.apache.org/jira/browse/HADOOP-8774 Project: Hadoop Common Issue Type: Bug Components: build Affects Versions: 2.1.0-alpha Reporter: Hitesh Shah Priority: Minor Running a simple mvn clean install at the top of tree shows logs such as the ones below in the HDFS tree: [INFO] --- maven-dependency-plugin:2.1:build-classpath (build-classpath) @ hadoop-hdfs-httpfs --- [INFO] Wrote classpath file '/Users/Hitesh/dev/hadoop-common/hadoop-hdfs-project/hadoop-hdfs-httpfs/target/classes/mrapp-generated-classpath'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Branch 2 release names
Uh, I meant 'create hadoop-2.0.2-alpha' release off branch-2. On Sep 6, 2012, at 11:18 AM, Arun C Murthy wrote: Sounds fine. For now, I think we can delete branch-2.1.0-alpha, create branch-2.0.2-alpha release off branch-2 and eventually make branch-2.1.0 as the stable release in the future. Arun On Sep 4, 2012, at 11:55 AM, Owen O'Malley wrote: While cleaning up the subversion branches, I thought more about the branch 2 release names. I'm concerned if we backtrack and reuse release numbers it will be extremely confusing to users. It also creates problems for tools like Maven that parse version numbers and expect a left to right release numbering scheme (eg. 2.1.1-alpha 2.1.0). It also seems better to keep on the 2.0.x minor release until after we get a GA release off of the 2.0 branch. Therefore, I'd like to propose: 1. rename branch-2.0.1-alpha - branch-2.0 2. delete branch-2.1.0-alpha 3. stabilizing goes into branch-2.0 until it gets to GA 4. features go into branch-2 and will be branched into branch-2.1 later 5. The release tags can have the alpha/beta tags on them. Thoughts? -- Owen -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
Re: Branch 2 release names
To be clear, I think we all seem to agree that we continue to make hadoop-2.0.3, hadoop-2.0.3 etc. with alpha/beta tags as appropriate until we git 'GA' at which point we release hadoop-2.1.0. Makes sense? thanks, Arun On Sep 6, 2012, at 11:38 AM, Arun C Murthy wrote: Uh, I meant 'create hadoop-2.0.2-alpha' release off branch-2. On Sep 6, 2012, at 11:18 AM, Arun C Murthy wrote: Sounds fine. For now, I think we can delete branch-2.1.0-alpha, create branch-2.0.2-alpha release off branch-2 and eventually make branch-2.1.0 as the stable release in the future. Arun On Sep 4, 2012, at 11:55 AM, Owen O'Malley wrote: While cleaning up the subversion branches, I thought more about the branch 2 release names. I'm concerned if we backtrack and reuse release numbers it will be extremely confusing to users. It also creates problems for tools like Maven that parse version numbers and expect a left to right release numbering scheme (eg. 2.1.1-alpha 2.1.0). It also seems better to keep on the 2.0.x minor release until after we get a GA release off of the 2.0 branch. Therefore, I'd like to propose: 1. rename branch-2.0.1-alpha - branch-2.0 2. delete branch-2.1.0-alpha 3. stabilizing goes into branch-2.0 until it gets to GA 4. features go into branch-2 and will be branched into branch-2.1 later 5. The release tags can have the alpha/beta tags on them. Thoughts? -- Owen -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
Re: test-patch and native code compile
We could also call uname from test-patch.sh and skip running native tests on Mac OS X. I also think that HADOOP-7147 should be open rather than won't fix, as Alejandro commented. Allen Wittenauer closed it as won't fix because he personally did not intend to fix it, but that doesn't mean it's not a bug. cheers. Colin On Thu, Sep 6, 2012 at 8:29 AM, Eli Collins e...@cloudera.com wrote: Yea we want jenkins to run with native. How about adding making native optional in test-patch via a flag and updating the jenkins jobs to use it? On Thu, Sep 6, 2012 at 7:25 AM, Alejandro Abdelnur t...@cloudera.com wrote: Makes sense, though the Jenkins runs should continue to run w/ native, right? On Thu, Sep 6, 2012 at 12:49 AM, Hemanth Yamijala yhema...@gmail.com wrote: Hi, The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile. For e.g we run into HADOOP-7147 that has been resolved as Won't fix. Hence, should we have a switch in test-patch to not run native compile ? Could open a JIRA and fix, if that's OK ? Thanks hemanth -- Alejandro
[jira] [Reopened] (HADOOP-7147) setnetgrent in native code is not portable
[ https://issues.apache.org/jira/browse/HADOOP-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe reopened HADOOP-7147: -- Assignee: (was: Allen Wittenauer) Won't fix makes it sound like this is not a valid bug, which it is. setnetgrent in native code is not portable -- Key: HADOOP-7147 URL: https://issues.apache.org/jira/browse/HADOOP-7147 Project: Hadoop Common Issue Type: Bug Components: native Affects Versions: 0.22.0, 0.23.0 Reporter: Todd Lipcon Attachments: hadoop-7147.patch, HADOOP-7147.patch HADOOP-6864 uses the setnetgrent function in a way which is not compatible with BSD APIs, where the call returns void rather than int. This prevents the native libs from building on OSX, for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8775) MR2 distcp permits non-positive value to -bandwidth option which causes job never to complete
Sandy Ryza created HADOOP-8775:
--
Summary: MR2 distcp permits non-positive value to -bandwidth
option which causes job never to complete
Key: HADOOP-8775
URL: https://issues.apache.org/jira/browse/HADOOP-8775
Project: Hadoop Common
Issue Type: Bug
Affects Versions: 2.0.0-alpha
Reporter: Sandy Ryza
The likelihood that someone would want to enter a non-positive value for
-bandwidth seems really low. However, the job would never complete if a
non-positive value was specified. It'd just get stuck at map 100%. Luckily, a
positive value would always lead to the job completing.
bash-4.1$ hadoop distcp -bandwidth 0
hdfs://c1204.hal.cloudera.com:17020/user/hdfs/in-dir
hdfs://c1204.hal.cloudera.com:17020/user/hdfs/in-dir58
hadoop distcp -bandwidth 0 hdfs://c1204.hal.cloudera.com:17020/user/hdfs/in-dir
hdfs://c1204.hal.cloudera.com:17020/user/hdfs/in-dir58
12/05/23 15:53:01 INFO tools.DistCp: Input Options:
DistCpOptions{atomicCommit=false, syncFolder=false, deleteMissing=false,
ignoreFailures=false, maxMaps=20, sslConfigurationFile='null',
copyStrategy='uniformsiz\
e', sourceFileListing=null,
sourcePaths=[hdfs://c1204.hal.cloudera.com:17020/user/hdfs/in-dir],
targetPath=hdfs://c1204.hal.cloudera.com:17020/user/hdfs/in-dir58}
12/05/23 15:53:02 WARN conf.Configuration: io.sort.mb is deprecated. Instead,
use mapreduce.task.io.sort.mb
12/05/23 15:53:02 WARN conf.Configuration: io.sort.factor is deprecated.
Instead, use mapreduce.task.io.sort.factor
12/05/23 15:53:02 INFO util.NativeCodeLoader: Loaded the native-hadoop library
12/05/23 15:53:03 INFO mapreduce.JobSubmitter: number of splits:3
12/05/23 15:53:04 WARN conf.Configuration: mapred.jar is deprecated. Instead,
use mapreduce.job.jar
12/05/23 15:53:04 WARN conf.Configuration:
mapred.map.tasks.speculative.execution is deprecated. Instead, use
mapreduce.map.speculative
12/05/23 15:53:04 WARN conf.Configuration: mapred.reduce.tasks is deprecated.
Instead, use mapreduce.job.reduces
12/05/23 15:53:04 WARN conf.Configuration: mapred.mapoutput.value.class is
deprecated. Instead, use mapreduce.map.output.value.class
12/05/23 15:53:04 WARN conf.Configuration: mapreduce.map.class is deprecated.
Instead, use mapreduce.job.map.class
12/05/23 15:53:04 WARN conf.Configuration: mapred.job.name is deprecated.
Instead, use mapreduce.job.name
12/05/23 15:53:04 WARN conf.Configuration: mapreduce.inputformat.class is
deprecated. Instead, use mapreduce.job.inputformat.class
12/05/23 15:53:04 WARN conf.Configuration: mapred.output.dir is deprecated.
Instead, use mapreduce.output.fileoutputformat.outputdir
12/05/23 15:53:04 WARN conf.Configuration: mapreduce.outputformat.class is
deprecated. Instead, use mapreduce.job.outputformat.class
12/05/23 15:53:04 WARN conf.Configuration: mapred.map.tasks is deprecated.
Instead, use mapreduce.job.maps
12/05/23 15:53:04 WARN conf.Configuration: mapred.mapoutput.key.class is
deprecated. Instead, use mapreduce.map.output.key.class
12/05/23 15:53:04 WARN conf.Configuration: mapred.working.dir is deprecated.
Instead, use mapreduce.job.working.dir
12/05/23 15:53:04 INFO mapred.ResourceMgrDelegate: Submitted application
application_1337808305464_0014 to ResourceManager at
c1204.hal.cloudera.com/172.29.98.195:8040
12/05/23 15:53:04 INFO mapreduce.Job: The url to track the job:
http://auto0:8088/proxy/application_1337808305464_0014/
12/05/23 15:53:04 INFO tools.DistCp: DistCp job-id: job_1337808305464_0014
12/05/23 15:53:04 INFO mapreduce.Job: Running job: job_1337808305464_0014
12/05/23 15:53:09 INFO mapreduce.Job: Job job_1337808305464_0014 running in
uber mode : false
12/05/23 15:53:09 INFO mapreduce.Job: map 0% reduce 0%
12/05/23 15:53:14 INFO mapreduce.Job: map 33% reduce 0%
12/05/23 15:53:19 INFO mapreduce.Job: map 100% reduce 0%
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8776) Provide an option in test-patch that can enable / disable compiling native code
Hemanth Yamijala created HADOOP-8776: Summary: Provide an option in test-patch that can enable / disable compiling native code Key: HADOOP-8776 URL: https://issues.apache.org/jira/browse/HADOOP-8776 Project: Hadoop Common Issue Type: Improvement Components: build Reporter: Hemanth Yamijala Assignee: Hemanth Yamijala Priority: Minor The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile that make it difficult to use test-patch. This JIRA is to try and provide an option to make the native compilation optional. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: test-patch and native code compile
Thanks. I've opened https://issues.apache.org/jira/browse/HADOOP-8776. Will work on options and a patch there. Hemanth On Fri, Sep 7, 2012 at 12:24 AM, Colin McCabe cmcc...@alumni.cmu.edu wrote: We could also call uname from test-patch.sh and skip running native tests on Mac OS X. I also think that HADOOP-7147 should be open rather than won't fix, as Alejandro commented. Allen Wittenauer closed it as won't fix because he personally did not intend to fix it, but that doesn't mean it's not a bug. cheers. Colin On Thu, Sep 6, 2012 at 8:29 AM, Eli Collins e...@cloudera.com wrote: Yea we want jenkins to run with native. How about adding making native optional in test-patch via a flag and updating the jenkins jobs to use it? On Thu, Sep 6, 2012 at 7:25 AM, Alejandro Abdelnur t...@cloudera.com wrote: Makes sense, though the Jenkins runs should continue to run w/ native, right? On Thu, Sep 6, 2012 at 12:49 AM, Hemanth Yamijala yhema...@gmail.com wrote: Hi, The test-patch script in Hadoop source runs a native compile with the patch. On platforms like MAC, there are issues with the native compile. For e.g we run into HADOOP-7147 that has been resolved as Won't fix. Hence, should we have a switch in test-patch to not run native compile ? Could open a JIRA and fix, if that's OK ? Thanks hemanth -- Alejandro
