debian: prepare for https://download.jitsi.org/stable/ repo #734
Conversation
csett86
force-pushed
the
debian-package
branch
3 times, most recently
from
4c67d6e
to
47669e9
Compare
csett86
force-pushed
the
debian-package
branch
5 times, most recently
from
db08ad9
to
4cd17e7
Compare
csett86
force-pushed
the
debian-package
branch
2 times, most recently
from
8f81b06
to
1871c3b
Compare
Now requires fpm to be available in path, as the electron-builder packages fpm version is too old for --deb-generate-changes parameter
|
@damencho please review if this approach is fine for you and fits to the requirements to get the deb package included in the [https://download.jitsi.org/stable/ repo? Thank you in advance! |
| g++ (= 4:9.3.0-1ubuntu2), | ||
| g++-9 (= 9.4.0-1ubuntu1~20.04), | ||
| gcc (= 4:9.3.0-1ubuntu2), | ||
| gcc-10-base (= 10.3.0-1ubuntu1~20.04), |
There was a problem hiding this comment.
Where do all these dependencies come from? Also why the multiple flavours of gcc?
There was a problem hiding this comment.
These build-"deps" are a list of the build-essential packages that are installed in the build env. In this case I took a local snapshot, as recreating the perl script dpkg-genbuildinfo is quite some effort (and as far as I understood @damencho in #576 the .buildinfo file is not really used, thus I spared the effort and only provided the right files and checksums)
Apart from that, the long list is normal for the buildinfo file (as it just reflects what is installed on the system at the time, not what is really used for this specific build). See eg the buildinfo of a current jicofo, that also lists multiple gcc versions: https://download.jitsi.org/stable/jicofo_1.0-862-1_all.buildinfo
| Checksums-Sha256: | ||
| __SHA256__ __SIZE__ __FILE__ | ||
| Build-Origin: Ubuntu | ||
| Build-Architecture: amd64 |
There was a problem hiding this comment.
Out of curiosity, do you how things would look like if we'd want to do arm64 builds?
There was a problem hiding this comment.
Then the arch should be a parameter, and the post-build step would need to iterate over both debs. I suggest that we do this once we really provide arm64 builds, as that anyway requires some refactorings. But if you think otherwise I can also directly add it.
| dist/jitsi-meet-amd64.deb | ||
| dist/*.deb | ||
| dist/*.changes | ||
| dist/*.buildinfo | ||
| dist/jitsi-meet-x86_64.AppImage |
There was a problem hiding this comment.
So these will be uploaded as artifacts and we can use the links from the release to push it ... then we can trigger a remote ci job via web request, I think - the link and credentials will come from the env variables ...
Can we trigger the jenkins job once the artifacts are uploaded and publicly available?
There was a problem hiding this comment.
I think that should be doable from the ci.yml file yeah.
There was a problem hiding this comment.
Yes, I would propose to add a step that runs only on release publish (similar to https://github.com/jitsi/jitsi-meet-electron-sdk/blob/master/.github/workflows/ci.yml#L51-L53) whereby the artifacts are then known to be uploaded and publicly available.
Now requires fpm to be available in path, as the electron-builder
packages fpm version is too old for --deb-generate-changes parameter