The turris-build package has a ./generate_medkit, which actually downloads all the packages from repo.turris.cz. You have to seriously hack around to get it to build from local packages, which is just weird. A problem with the ./compile defaults is that it basically tries to build every single package as a module (they need to be modules because of the way medkit generation works).
It never finishes, because there is always some non-essential package that does not build. That’s also why it takes more than 100G of disk, and dozens of hours.
One needs a more minimal .config for the openwrt part. I’m rather disappointed with the CI here, and I’d really like to contribute to making this work better, but the cz.nic guys are pretty much all focused on next release.
I will be happy to share my formulas: I can build hbk (5.0 now), but my results seem to have foris code broken, and I’m not sure if that’s my fault or not. I can build 4.0.5, but I always seem to have to screw with the updater-ng code.
That is weird as non-essential packages do not halt build. They report error but won’t halt build.
compile_pkgs script is designed to build whole Turris OS and that way all package but it doesn’t have to be used that way. You can run compile_pkgs prepate_tools to get just minimal configured build system. With that you can run make package/XXXX/compile to selectively compile packages. All dependencies are automatically compiled (and only those). This is described in readme here Turris / Turris OS / Turris Build · GitLab.
Yes that is limitation that is multiple times reiterated here on forum. It makes sense for us as it was easier to implement it this way originally (before updater was able to handle relative paths in scripts). Adding ability to build medkit from local repository is unfortunately low priority. If you need to add just some package from your local build then you can do it by adding updater script that includes that repository and mixing it with packages on our server builds final medkit. If you are trying to replicate our build setup without using our packages then you have to hack it for now unfortunately.
For the benefit of others who might google, if you get a /usr/bin/env too many arguments errors when (re)building things it means that some directory under bin/packages just has too many things.
I can’t find the part of the makefiles where it tries to enumerate too many files (it’s an openwrt bug), so I just blow away a bunch of .ipk files and try again.
make package/luci/compile
...
make[2]: execvp: /usr/bin/env: Argument list too long
make[2]: *** [../../luci.mk:279: /mnt/caches/turris-build/build/bin/packages/aarch64_cortex-a53/luci/luci_git-20.155.55664-f35803e-1_all.ipk] Error 127
make[2]: Leaving directory '/mnt/caches/turris-build/build/feeds/luci/collections/luci'
time: package/feeds/luci/luci/compile#1.92#0.24#2.03
make[1]: *** [package/Makefile:113: package/feeds/luci/luci/compile] Error 2
make[1]: Leaving directory ‘/mnt/caches/turris-build/build’
so I did:
rm bin/packages/aarch64_cortex-a53/luci/*.ipk
make package/luci/compile
Also, I don’t understand the origin of this complaint:
where "$br" is somehow empty and a 40-hex ref is created. Please
examine these refs and maybe delete them. Turn this message off by
running "git config advice.objectNameWarning false"
I mean, I get why it is complaining, but I don’t know where in the makefiles this is being caused, but so far, it seems benign. Maybe things are related.