[LU-688] A patch made to b1_8 has exposed an issue which shows itself as an issue on the Ubuntu build Created: 16/Sep/11 Updated: 03/Feb/16 Resolved: 03/Feb/16 |
|
| Status: | Closed |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 1.8.7, Lustre 1.8.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Chris Gearing (Inactive) | Assignee: | Brian Murrell (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 2190 |
| Description |
|
A patch made to b1_8 has exposed an issue which shows itself as an issue on the Ubuntu build. No other builds are affected. The error only under Ubuntu is The strange thing is the source does not [appear] to contain the word 'auster.sh', perhaps this is a Lustre issue, but starting with Jenkins seems to make most sense. // From the Skype Chat. The error only under Ubuntu is The strange thing is the source does not [appear] to contain the word 'auster.sh' At present I'm trying to replicate localling, but figured whilst I do that I should ask you folks for ideas. after a checkout from git, a source tarball is created via 'make dist', and the tarball is used to feed the package production process ah, the commit message: there ya go oh, heh. you're the author of that commit. and now i understand what you mean re: the string "auster.sh" sorry, started talking before i'd started thinking... hmm. this is weird. when i pull that changeset and grep i don't find auster.sh either. i wonder if it has something to do with the buildstep stuff in the job configuration... looking at that now i don't see any hard-coded instances of 'auster.sh' there either i dunno, probably best to ping brian, as he knows the ubuntu packaging best. hrm. can i not checkout the branch that gerrit creates with: nm chrisgearing: somewhere somebody's broken b1_8 so that autogen.sh does not work on a post-"make dist"ed tarball source pool Checking for a complete tree... chrisgearing: it seems unbelievable though, that the change that's causing that problem went in 3 years ago and this issue is only just now being discovered. perhaps the ability to use autogen.sh on a tarball extracted source tree has just never been needed. but even in our own building, i'd expect this to have been needed before now. chrisgearing: probably somebody more familiar with the history of b1_8 needs to figure out the right solution. you should file a ticket. feel free to CC me on it. My change was rename auster.sh to auster and change the makefile which is the only place the word auster.sh existed. Brian has lost me in his assessement [because of my lack of knowledge] I don't even know what to put in a ticket. I can't raise it agsint b1_8 because the bug doesn't occur until my patch is pushed - which can't be pushed!
|
| Comments |
| Comment by Brian Murrell (Inactive) [ 16/Sep/11 ] |
|
To be clear, this is an LU- ticket and not at TT- ticket. The reason the issue only affects Ubuntu is because Ubuntu (in fact any DEB) is the only build that completely exercises the build system. RPM based builds don't test as many steps as DEB builds do. They should, but they don't. But that's another ticket. The issue here is that a git checkout has a /libcfs dir in it but a "make dist" tarball does not. Further to the issue is that the patch that does the auster.sh rename alters a Makefile.am file. When one of those is altered, one must run autogen.sh. autogen.sh checks for a /libcfs dir as part of it's validation that it's running in a lustre tree. Since an unpacked tarball doesn't have the /libcfs dir in it, that fails. Since autogen.sh fails to run (and really, the build should fail and stop there, but again, that's another ticket) lustre/tests/Makefile is not re-generated from lustre/tests/Makefile.am and thus the auster.sh rename is not reflected in that Makefile. So, the solution here is whatever allows autogen.sh to be run in a tarball unpacked source tree. That could mean removing the libcfs check from autogen.sh or including the (emptry) libcfs dir in the tarball, or perhaps something else. I'm not familiar enough with what's all gone on around that to be definitive myself. Maybe one needs to stand back a bit and compare b1_8 to master in this regard and make them more similar. |
| Comment by James A Simmons [ 03/Feb/16 ] |
|
Really outdated old issue. |