I will have a look and will let you know
Hey @olofk @oleg-nenashev, I am willing to work on olofk/serv#8 , do you think it is good idea to keep it here . Can you look into this
hey @oleg-nenashev , @stffrdhrn and I observed that last run of https://ci.librecores.org/job/Projects/job/OpenRISC/job/or1k_marocchino/ was 14 days . cant we have done it periodically ( more frequently ) and also @stffrdhrn wanted to trigger ( re - run
) the build, but I guess we are not able to build it . Can you help with this
) the build, but I guess we are not able to build it . Can you help with this
@Nancy-Chauhan @Nancy-Chauhan @oleg-nenashev I want to make some changes to how FuseSoC is installed in the base image. Can I make a local version of that image and test it on my machine somehow?
I have a vague memory of seeing this before on a ubuntu system
usually you can put the commands in one line, like 'source xyz && ./run-script'
note any script files need to be installed in the image or downloaded before you run them
Obviously
hestitant to remove it without knowing why it's there in the first place. Something with cocotb? Can we use python3-dev in that case?
Same with mercurial. We should probably document why those packages are installed
Just realized that cocotb isn't even installed in the base image. If no one opposes, I will trim down the list now to only install what we actually use
Or are we moving from the base image altogether?
@olofk, please see librecores/docker-images#33. I'm open to help adapting existing lcci images after we discuss a possible roadmap.
And the multistage builds make a lot of sense. I read about that but couldn't figure out how it worked. Think I got it now with the cache_yosys example
As a gentoo user I'm very used to compile- vs run-time dependencies :)
@1138-4EB ok, this looks interesting but I guess we still don't have a good solution for the problem of building images with several of these tools? Right now I need an image with fusesoc, verilator, (maybe gtkwave) and some other stuff like Zephyr. There is no way of building fusesoc. verilator and gtkwave separately and then combine into one image, right?
- If everyone needs to compile it, it's easier to distribute a precompiled binary with deps in an image. This would be for things that takes a while to compile and where there aren't any readily available packages (e.g. verilator)
- Things that are complicated to build. I have personally given up trying to install ghdl on my machine with anything else but the mcode backend. I just can't get it to work
- Things that require a very specific runtime environment. This would apply to most proprietary EDA tools
For the rest of the stuff I guess sharing docker recipes rather than images makes more sense and let people build their own customized images
I tested the new version, can cut the release if needed
@Nancy-Chauhan It is definitely in our list, just created jenkins-infra/jenkins.io#2683 which moves this project idea to GSoC 2020. CC @martinda. I will be available for meetings after Dec 09