Late Fix for package building errors, introduced in january #92
Conversation
…n make scrub_clean Signed-off-by: Michael Brown (the-snowwhite) <producer@holotronic.dk>
Signed-off-by: Michael Brown (the-snowwhite) <producer@holotronic.dk>
|
@cdsteinkuehler this time I have made certain that all the .rbf bitfiles build in the docker image. |
|
OK now Its complaining about a qsys compile error in the DE10 Nano project I'm looking into it now |
|
@cdsteinkuehler |
|
They use Jenkins jobs, but I had no part in setting them up.
Vivado fails with I interrogated docker running on the server and it is not listed amongst the images I am having problems finding anything to match in the The only thing I can find is @dkhughes github repo to build the docker for vivado Looks like it needs a new entry under <maintainer> as per the https://github.com/mhaberler/mksocfpga docs (and an image to go with it 😄 ) |
|
I am in the process of setting up a Xilinux account and downloading the pre-requisites for creating the docker Know nothing about the code being compiled, but fairly familiar with docker creation, so see if @dkhughes instructions get me through |
|
OK .. Yes the builder says jenkins :-) , whats confusing me is the references to travis here: Do these files still serve any purpose or are they outdated ? I'm thinking that the quartus qsys build error (in the DE10 Nano folder) may be some leftovers from former build attempts in a cache ? |
No point removing them, in case it is desired to do it through Travis at some point later.
Well we can test that. I will wipe the workspace and manually restart the build. |
|
OK I have saved the previous output to a zip locally and wiped the workspace. The build is at https://jenkins.machinekit.io/job/mksocfpga-quartus/25/ , we will see what happens |
|
OK however I can narrow the Qsys issue down to these messages: The DE10 project is the only project that uses a pll addition, so if the reset does not work the remedy is here (fix missing temporary work directory): |
|
Ups and: I suspect the issue is in: TMP, TEMP or HOME environment variables ? |
|
All I can suggest is adding --user= to the docker build string which should add a HOME like this: the image is set up with /home/builder so: docker run --user=builder -itv $(pwd):/work cdsteinkuehler/jessie-quartus-15.1.2 /work/build.quartus.sh I am now running a local build with that... |
|
I will have to review it tomorrow, 'beer o'clock' here. Will check your outcome and that of the rebuild then. |
|
OK On a side note the socfpga-xxx debs need a stretch distribution... ? |
|
I have made a stretch image for DE0-NANO, but only by the 'upgrade and capture to image' method So a proper update would be good. I don't know re the debs, have only used pre-built images and worked from there, but Stretch is |
|
my local build (with --user=builder) completed without errors |
|
@the-snowwhite I see you have access to Jenkins, you will need to look at the output and the produced .rbf files (which look to be the full set) and see if you can see what is going wrong. The builder does not launch the docker externally as you were doing, but appears to be running I would have thought it far simpler to script it as you are doing, albeit the references to I don't have Quartus installed and cannot test locally |
That didn't work. Leads me to think the vivado docker image was local only. |
|
The work folder is a reference to the folder you are in when you run the docker image ie: I have not worked with the Vivado stuff yet so I have no clues there. |
|
Yes I do have access and came to trigger a build.. have to wait for it to finish. I have now made a copy of the jenkins project to play with. |
|
So long as you work on a copy under a different name, it will not trigger anything. The
|
|
Probably best to remove the post-build actions from your copy too, so as not to muddy the waters by trying to set a commit status in github. |
|
OK I removed the post build actions. However the main culprit is missing write permissions to a TMP directory or the HOME dir, for the ruin job. |
|
The env vars for the job are However if you look on the server, there is no user dir You could create a TMP folder in the script before the build line, pass it as an env var with open permissions. |
|
Yes I have now triggered a new build |
|
Docker Build now compiles successfully. There is an updated version here: How to proceed |
|
Well done. I will try building the dockerfile in a while and can host it if successful. |
|
Just checked and the toolchain is still available on the same URL Will let you know how it goes. |
|
I have built an image and used that in the That succeeds in building the deb, but falls over on the upload. Needs user with uid 1030: gid 1032 from what I recall, if it is done inside a docker. Jenkins is playing up in other ways, every time you save the configuration there is a huge java error trace message, but it seems to do the save operation OK. |
|
Hurrah, The deb is now in the repo @dkhughes is going to make a new docker image for the mksocfpga-vivado build in a couple of weeks. |
|
@ArcEye |
|
It does not appear in the Stretch repo, because the Jenkins builder was only set up for Jessie. However this has uncovered a problem in debrepro, whereby it is convinced that a previous non-identical instance of the same package exists and refuses to update because the checksums do not match. I think it may be time to back-up the whole repo and then wipe it all and add the packages back. Update: |
|
The repo is now fixed.
Just need to do an |
3 participants
Sorry for being late on this one, parly due to 6 weeks sick leave plus extensive testing.
On the bright side updating to u-boot 2018.01 utilizing the (new) socfpga 4.9-rt-ltsi branch, makes
machinekit run very stable on armhf Stretch .. :-)
I intend to post an updated SD image soon. elsewhere...
I will keep an eye out this time for the package build to pass...
best whishes