#1006 closed defect (fixed)
Build broken @ r8656
| Reported by: | tekkie | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | |
| Component: | Build System | Version: | |
| Keywords: | Cc: |
Description
Patching file multimedia/xvid/Makefile using Plan A...
Hunk #1 succeeded at 15.
done
Hmm... Looks like a unified diff to me...
The text leading up to this was:
|+++ multimedia/xvid/Makefile 2011-09-28 07:23:02.000000000 -0700
Patching file multimedia/xvid/Makefile using Plan A...
Hunk #1 succeeded at 15.
done
/usr/src/FreeNAS8/trunk/build/nanobsd/nanobsd.sh -c /usr/src/FreeNAS8/trunk/nanobsd/freenas-common -n -j 5
Sourcing /usr/src/FreeNAS8/trunk/nanobsd/freenas-common
do_build.sh: ERROR: FreeNAS build FAILED; please check above log for more details
[root@donky /usr/src/FreeNAS8/trunk]# svn update
At revision 8656.
Attachments (5)
Change History (25)
comment:1 Changed 18 months ago by tekkie
- Component changed from Backend to Build System
- Version 8.0.2-RELEASE deleted
comment:2 Changed 18 months ago by JoeSchmuck
comment:3 Changed 18 months ago by gcooper
Probably environmental. svn status / svn diff shows what...?
comment:4 Changed 18 months ago by JoeSchmuck
Not sure what you are asking for. I tried a new build from scratch and it failed. Ended up isolating the break to 8640. Suspect all that 'git' code has something to do with it.
What is odd, I added a line that echos the SVNREVISION and REVISION, in the nano_env just after the location where these are identified and did this in both pre 8640 the rev numbers pop up twice (didn't expect that) but in the newer 8640 version it pops up once. Does that mean nano_env is entered twice? Sure looks that way prior to 8640.
Not sure what is going on.
I don't have the time to build again until tomorrow, if you need something specific done please note it here or PM me.
comment:5 Changed 18 months ago by gcooper
r8669 should help. I'll take a look at it again today to see where things stand with a 'touched' workspace, but a virgin workspace looks sane according to last night's nightly.
How are you invoking the build and what are the changes to your local workspace (that's what I was driving at with my previous question)? You will need to touch FreeBSD/.pulled BTW... it's something that I did to work around the fact that partially pulled builds continued ungracefully and barfed later on (see: r8568 )..
Ultimately, yes.. the reentrant nano_env stuff needs to go away. We just have bigger fish to fry, so I let things be (getting rid of the reentrancy introduces an interesting problem because nanobsd.sh defines a bunch of variables and ignores preset defaults -- for better or for worse).
A proper solution would probably be to split up the components into a 'before' and 'after' group, similar to what the bsd.*.mk files do.
comment:6 Changed 18 months ago by JoeSchmuck
Failure again building r8671. I've attached my putty.log (broken down into under 256K chunk, all files need to restore the zip) and please realize I run a script normally to which will get the SVN code and then run do_build. The other day I ran the commands separately with the same results. In this build I started with no trunk folder. To view the script I have it on the forums or I can forward it if needed. Either way the nano_env file is hosed up unless there were other files that needed an update but never saw it.
There is no special setup to my workspace, it's simply FreeBSD in a VM. The environment variable for the CVSUP is all I set and here is the code I effectively run...
export FREEBSD_CVSUP_HOST=cvsup8.freebsd.org cd /usr/local/freenas/ svn co https://freenas.svn.sourceforge.net/svnroot/freenas/trunk/ sh build/do_build.sh
It's integrated into a script but these are the commands that come out. At the end I calculate the SHA and save it in a file and post how long everything took.
I just updated FreeBSD (10 patches) and will try again completely manually, no script.
Changed 18 months ago by JoeSchmuck
comment:7 Changed 18 months ago by JoeSchmuck
Same results, broken still.
Here are the last few lines that worked and the error:
Applying patch ports-xvid.patch... Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- multimedia/xvid/Makefile 2011-09-28 07:22:40.000000000 -0700 |+++ multimedia/xvid/Makefile 2011-09-28 07:23:02.000000000 -0700 -------------------------- Patching file multimedia/xvid/Makefile using Plan A... Hunk #1 succeeded at 15. done /usr/local/freenas/trunk/build/nanobsd/nanobsd.sh -c /usr/local/freenas/trunk/nanobsd/freenas-common -j 17 Sourcing /usr/local/freenas/trunk/nanobsd/freenas-common do_build.sh: ERROR: FreeNAS build FAILED; please check above log for more details Freenas#
I'm done with this one, there is nothing else I can provide. If it's not important enough to fix then fine. I can't believe the developers don't have this problem unless they are building it completely different from the instructions provided in the ReadMe? file.
comment:8 Changed 18 months ago by gcooper
I'm not saying that it's not important.. there's just some missing piece in the puzzle that's screwing up the applecart right now that falls outside of our standard environment.
It might fall under the same umbrella of failures that was causing problems yesterday in the nightlies.
And it's still between 10-6 PST here, so this me doing a best effort to analyze things from work with all of the other random interruptions that happen from multiple vectors.
comment:9 follow-up: ↓ 10 Changed 18 months ago by JoeSchmuck
Sorry for the attitude, that's not normally my style, I'm normally more level headed and helpful. It's been one of those days and I shouldn't have taken out here. Again, my apologizes.
comment:10 in reply to: ↑ 9 Changed 18 months ago by gcooper
Replying to JoeSchmuck:
Sorry for the attitude, that's not normally my style, I'm normally more level headed and helpful. It's been one of those days and I shouldn't have taken out here. Again, my apologizes.
No worries -- I've had people scream at me before for no reason, or for reasons that weren't my fault at work (BestBuy?... uh...).
I tried extracting the zips earlier and it failed, but I'll try again soon with a client that's less dumbed down than unzip (alzip, winrar, etc).
comment:11 Changed 18 months ago by gcooper
Hmm.. didn't spot anything in the log. Could you update to the latest version of svn and call sh -x do_build.sh ? I want to see where exactly it fails with your environment (nano_env output and output from nanobsd.sh are the important parts -- the svn / csup output's basically noise).
comment:12 Changed 18 months ago by tekkie
svn update @
+ command -v svnversion
+ svnversion=/usr/local/bin/svnversion
+ command -v git
+ git_cmd=
+ error 'FreeNAS build FAILED; please check above log for more details'
+ echo 'do_build.sh: ERROR: FreeNAS build FAILED; please check above log for more details'
do_build.sh: ERROR: FreeNAS build FAILED; please check above log for more details
+ exit 1
Somebody added git as a dependency... without actually saying so in the SVN change set or updating the README.
PS. How can one get commit rights to the SVN repository? :)
comment:13 Changed 18 months ago by gcooper
Ok -- that makes sense.
git isn't a dependency (it's a developer tool) and that issue's easy to fix.
comment:14 Changed 18 months ago by gcooper
- Resolution set to fixed
- Status changed from new to closed
Fixed in r8684.
comment:15 Changed 18 months ago by yaberauneya
In [8684/freenas]:
comment:16 Changed 18 months ago by yaberauneya
In [8684/freenas]:
comment:17 Changed 18 months ago by yaberauneya
In [8684/freenas]:
comment:18 Changed 18 months ago by yaberauneya
In [8684/freenas]:
comment:19 Changed 18 months ago by yaberauneya
In [8684/freenas]:
comment:20 Changed 18 months ago by yaberauneya
In [8684/freenas]:

8640 broke it.
I placed a copy from r8639 of nano_env into the build directory and it builds fine.
Looking at the 8639 version it looks to be entered twice where 8640 might cause it to bomb. I could be wrong as this is not where I'm a technical expert for sure.