Cobrador on Nostr: ## CW 5 review Last week worked on OpenWRT deployments some more. We already had the ...
## CW 5 review
Last week worked on OpenWRT deployments some more. We already had the ability to build packages, upload them to blossom, advertise them on nostr, install them in OpenWRT images and download them onto the router. However, this stiff only worked for the `GL-MT3000`, not for the `GL-AR300m` and arjenstens (nprofile…7u3d)'s latest changes to the packages weren't present in the OpenWRT images that were created.
### Problems with `golang.mk`
We are building a newer version of `golang` before we build our go-based packages, because the golang that comes with OpenWRT is outdated to the extent that it isn't compatible with our nostr dependencies. There is a file called `golang.mk`, which Makefiles use to specify the target architecture of a build. I created the file as a placeholder because the SDK expected it to be present for the build, but there seem to be problems with the architecture I specify and the way I introduce the file to the SDK.
#### How `golang.mk` is introduced
I was only building the relay when I first created `golang.mk`, so I used the relay's Makefile to copy it from my custom feed to the correct location in the SDK. This worked fine for a while, but it meant that the relay's Makefile needed to run before the Makefile of any other go based packages in order to avoid errors. Now I am introducing the file in the script that [triggers the makefiles](https://github.com/OpenTollGate/tollgate-sdk/blob/ddb56a007978bb4ffc7d9e8bb999871a419ecf6d/build-firmware#L155-L157), so that its always present when one of the go-based packages is built.
##### Building for `GL-AR300m`
Earlier I mentioned that the image builder worked for the `GL-MT3000`, but not for the `GL-AR300m`. It turned out that the packages that the SDK produced for the `GL-AR300m` also [couldn't be installed](https://njump.me/nevent1qqstjrl8v80srjz7prwu9xx49wnha6vmvcnv80r3ecmq7y0g2y5mdmqpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg86u6zkjdqrlppxyrar37y79l0urmqtjh8ue24pnx7gl7ktwtfwsspsgqqqqqqs05gqrv) on the router manually. This probably had something to do with the fact that there is a `nand` and a `nor` version of that router and that `golang.mk` was miss-configured. Your expertise is most welcome to ensure that we pass reasonable arguments to the compiler and to ensure that we can target a wide range of routers efficiently.
#### Changes not taking effect
As you can see in the following diagram, OpenWRT packages are listed in a custom feed, which points the SDK to the right branch of the package's repo. A file in the SDK's repository lists feeds to be considered when making packages and the image builder pre-installs packages that the SDK produced in an OpenWRT image for the users to install.
Previously the [nostr announcements](https://njump.me/nevent1qqs0367hrqx70y7std5xjladu46d5pc7u4lhf7gw0yme8k5zjcr5wqcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg8d577gs99pxwfm2u4stjlw3fkksa83hwqg5tuyel3ejnfalxzdrypsgqqqqqqsk6vpzk) of freshly compiled packages didn't mention which branch of a specific package was used to create the package, but [now they do](https://njump.me/nevent1qqsv57c768688zwsy928l6hnjfw5h0wx2tt4travk2kuxkp3raa644gpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg8d577gs99pxwfm2u4stjlw3fkksa83hwqg5tuyel3ejnfalxzdrypsgqqqqqqskdwqym).
Unfortunately, changes that we make to the source code in the binaries still don't reflect in the package when we execute it, even though we have reassured ourselves that we are building the right branch. Perhaps code is being cached somewhere, but this problem occurs even when I start from a completely clean slate.
### Git workflows to the rescue
It is critical that the changes we make reflect in the packages we release, so clearly the spaghetti deployment needs to be simplified. I got a [minimal version](https://github.com/OpenTollGate/tollgate-sdk/pull/4) of the build to work without pushing to blossom and without announcements on nostr. Unfortunately, `noscl` didn't find its private key when running in a git actions workflow, but I hope to get the whole build setup working in git actions, so that we can be more systematic about how we address the problem of changes to packages not taking effect in our binaries.
#weeklyreview
Last week worked on OpenWRT deployments some more. We already had the ability to build packages, upload them to blossom, advertise them on nostr, install them in OpenWRT images and download them onto the router. However, this stiff only worked for the `GL-MT3000`, not for the `GL-AR300m` and arjenstens (nprofile…7u3d)'s latest changes to the packages weren't present in the OpenWRT images that were created.
### Problems with `golang.mk`
We are building a newer version of `golang` before we build our go-based packages, because the golang that comes with OpenWRT is outdated to the extent that it isn't compatible with our nostr dependencies. There is a file called `golang.mk`, which Makefiles use to specify the target architecture of a build. I created the file as a placeholder because the SDK expected it to be present for the build, but there seem to be problems with the architecture I specify and the way I introduce the file to the SDK.
#### How `golang.mk` is introduced
I was only building the relay when I first created `golang.mk`, so I used the relay's Makefile to copy it from my custom feed to the correct location in the SDK. This worked fine for a while, but it meant that the relay's Makefile needed to run before the Makefile of any other go based packages in order to avoid errors. Now I am introducing the file in the script that [triggers the makefiles](https://github.com/OpenTollGate/tollgate-sdk/blob/ddb56a007978bb4ffc7d9e8bb999871a419ecf6d/build-firmware#L155-L157), so that its always present when one of the go-based packages is built.
##### Building for `GL-AR300m`
Earlier I mentioned that the image builder worked for the `GL-MT3000`, but not for the `GL-AR300m`. It turned out that the packages that the SDK produced for the `GL-AR300m` also [couldn't be installed](https://njump.me/nevent1qqstjrl8v80srjz7prwu9xx49wnha6vmvcnv80r3ecmq7y0g2y5mdmqpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg86u6zkjdqrlppxyrar37y79l0urmqtjh8ue24pnx7gl7ktwtfwsspsgqqqqqqs05gqrv) on the router manually. This probably had something to do with the fact that there is a `nand` and a `nor` version of that router and that `golang.mk` was miss-configured. Your expertise is most welcome to ensure that we pass reasonable arguments to the compiler and to ensure that we can target a wide range of routers efficiently.
#### Changes not taking effect
As you can see in the following diagram, OpenWRT packages are listed in a custom feed, which points the SDK to the right branch of the package's repo. A file in the SDK's repository lists feeds to be considered when making packages and the image builder pre-installs packages that the SDK produced in an OpenWRT image for the users to install.
Previously the [nostr announcements](https://njump.me/nevent1qqs0367hrqx70y7std5xjladu46d5pc7u4lhf7gw0yme8k5zjcr5wqcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg8d577gs99pxwfm2u4stjlw3fkksa83hwqg5tuyel3ejnfalxzdrypsgqqqqqqsk6vpzk) of freshly compiled packages didn't mention which branch of a specific package was used to create the package, but [now they do](https://njump.me/nevent1qqsv57c768688zwsy928l6hnjfw5h0wx2tt4travk2kuxkp3raa644gpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg8d577gs99pxwfm2u4stjlw3fkksa83hwqg5tuyel3ejnfalxzdrypsgqqqqqqskdwqym).
Unfortunately, changes that we make to the source code in the binaries still don't reflect in the package when we execute it, even though we have reassured ourselves that we are building the right branch. Perhaps code is being cached somewhere, but this problem occurs even when I start from a completely clean slate.
### Git workflows to the rescue
It is critical that the changes we make reflect in the packages we release, so clearly the spaghetti deployment needs to be simplified. I got a [minimal version](https://github.com/OpenTollGate/tollgate-sdk/pull/4) of the build to work without pushing to blossom and without announcements on nostr. Unfortunately, `noscl` didn't find its private key when running in a git actions workflow, but I hope to get the whole build setup working in git actions, so that we can be more systematic about how we address the problem of changes to packages not taking effect in our binaries.
#weeklyreview