Conversation
Adds building, and uploading to GH releases, for amd64 debian packages. I was unable to fully test this because: * I don't have access to the actions context of this repo * Self hosted runners are being used, which I cannot mimic * I built the binary for this package on Gentoo, which doesn't match the protobuf versions in Ubuntu, but I was able to get past a lot of shared link issues. I likely missed one or two dependencies. Feel free to take this over the finish line. Closes: vicinaehq#269
| - name: Install nfpm | ||
| run: |- | ||
| echo 'deb [trusted=yes] https://repo.goreleaser.com/apt/ /' | sudo tee /etc/apt/sources.list.d/goreleaser.list | ||
| sudo apt-get update -y | ||
| sudo apt-get install nfpm |
There was a problem hiding this comment.
This would probably go into scripts/runners long term
|
|
||
| build-deb: | ||
| needs: build-binary | ||
| runs-on: [self-hosted, Linux, X64, appimage] |
There was a problem hiding this comment.
We could opt to use ubuntu-<xyz> here 😄
|
Well, the main issue with this is not really the packaging aspect of things but rather the really out of date dependencies these systems ship with (debian in particular). We could probably have a working deb package for latest ubuntu but I'm pretty sure the QT version alone would block older systems. Some of the other dependencies are more manageable and can be linked statically like I do for protobuf and cmark-gfm already. Given what I just said it's likely the appimage + script is the best solution to this issue for older systems, but maybe I'm missing something. As for arm64, yes the self hosted runner is x86_64 and emulation is too slow to be viable. I could work on getting a github runner ready for that purpose, but they are much slower and require more setup for QT + latest gcc + node etc... |
|
Don't hate me immediately, but maybe in that case we could ship an app image inside? It's not the most orthodox but it would solve that problem |
I'm not sure whether it's really orthodox or not but if it works it works, I don't really care, and I don't see a better solution. What you could try to do, is look at what I do in the script install (which uses the appimage) and try to tweak it for deb packages. That's probably the best approach. |
2 participants
Adds building, and uploading to GH releases, for amd64 debian packages.
I was unable to fully test this because:
protobuf versions in Ubuntu, but I was able to get past a lot of
shared link issues. I likely missed one or two dependencies.
I did not add arm64 support because the self-hosted runners appear to be
amd64 only.
Possible issue with this method: We will rely on the version of libs used in the
runner (e.g., protobuf)
Feel free to take this over the finish line.
Closes: #269