3 ms·

"I’m no longer hosting a fork of the main repository, instead favouring a fresh clone of the upstream repository on each build, and applying patches and overlay

"I’m no longer hosting a fork of the main repository, instead favouring a fresh clone of the upstream repository on each build, and applying patches and overlays where needed to make the code build for our targets. The hope here is to make our build system more resilient to changes in the upstream repository so as to avoid manual intervention as much as possible." How is this better than a fork? Git seems like it would handle merges much better than this DIY patch pile.

headmelted 9y ago
Sorry for the late reply, was at NIDevConf yesterday and only just got a look at this. I agree - I was originally doing this with rebases. The problem I ran into over time was that because things upstream were changing around without my knowledge (which they should), files would move and the replayed steps would break. Even worse was when the rebase would succeed due to no merge conflicts, only to find out later on that the code file is now jibberish as the core team have taken a different direction earlier in the file / in an import / removed a variable etc. I could have gone through and manually worked around this, but so much was changing, and so quickly (which is a good thing) that it was an uphill battle. It's also possible that this is a solved problem in git rebase that I'm not aware of (I'm far from an expert), but by that point I'd kind of come to the realisation I was doing it wrong anyway (hacking together multiple Ubuntu versions, pulling packages from different releases etc.) I now have a docker container I've put together that I intend to expand on (it's "cobbler" in my github, and referenced from this project) that builds the toolchain as a layer over Xenial - this takes a lot of the other hackery out of the equation. It's beside the point but given that the goal of this when I set out was better tools on ARM and Chromebooks, I'm hoping to expand the docker image out to all of the architectures that debian supports (should be trivial) with static user-space QEMU enabled for all of them with mounted binfmt support (less trivial, but privileged mode should make it doable) - the idea being that adding a foreign architecture for something that's already building on Travis / Circle / Gitlab etc. should be as simple as "switch-arch arm64" before compiling and testing. Obviously, this assumes no exotic platform-specific calls. Sorry for the rambling response, and thanks for the question.

headmelted 9y ago

Sorry for the late reply, was at NIDevConf yesterday and only just got a look at this. I agree - I was originally doing this with rebases. The problem I ran into over time was that because things upstream were changing around without my knowledge (which they should), files would move and the replayed steps would break. Even worse was when the rebase would succeed due to no merge conflicts, only to find out later on that the code file is now jibberish as the core team have taken a different direction earlier in the file / in an import / removed a variable etc. I could have gone through and manually worked around this, but so much was changing, and so quickly (which is a good thing) that it was an uphill battle. It's also possible that this is a solved problem in git rebase that I'm not aware of (I'm far from an expert), but by that point I'd kind of come to the realisation I was doing it wrong anyway (hacking together multiple Ubuntu versions, pulling packages from different releases etc.) I now have a docker container I've put together that I intend to expand on (it's "cobbler" in my github, and referenced from this project) that builds the toolchain as a layer over Xenial - this takes a lot of the other hackery out of the equation. It's beside the point but given that the goal of this when I set out was better tools on ARM and Chromebooks, I'm hoping to expand the docker image out to all of the architectures that debian supports (should be trivial) with static user-space QEMU enabled for all of them with mounted binfmt support (less trivial, but privileged mode should make it doable) - the idea being that adding a foreign architecture for something that's already building on Travis / Circle / Gitlab etc. should be as simple as "switch-arch arm64" before compiling and testing. Obviously, this assumes no exotic platform-specific calls. Sorry for the rambling response, and thanks for the question.