StarMirror/qTox
1
0
Fork 0
mirror of https://github.com/qTox/qTox.git synced 2024-03-22 14:00:36 +08:00
Code Issues Projects Releases Wiki Activity
7083a7d9bd
qTox/flatpak/io.github.qtox.qTox.json

160 lines
4.2 KiB
JSON
Raw Normal View History

chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
{
"app-id": "io.github.qtox.qTox",
"runtime": "org.kde.Platform",
"sdk": "org.kde.Sdk",
chore(flatpak): update deps and bump runtime to 5.15
2020-09-04 20:14:25 +08:00
"runtime-version": "5.15",
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"command": "qtox",
"rename-icon": "qtox",
"finish-args": [
"--share=network",
"--socket=pulseaudio",
"--socket=wayland",
"--socket=x11",
"--share=ipc",
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"--talk-name=org.kde.StatusNotifierWatcher",
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"--filesystem=xdg-desktop",
"--filesystem=xdg-documents",
"--filesystem=xdg-download",
"--filesystem=xdg-music",
"--filesystem=xdg-pictures",
"--filesystem=xdg-videos",
"--filesystem=/media",
"--device=all"
],
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"add-extensions": {
"org.freedesktop.Platform.ffmpeg-full": {
"directory": "lib/ffmpeg",
chore(flatpak): update deps and bump runtime to 5.15
2020-09-04 20:14:25 +08:00
"version": "20.08",
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"add-ld-path": "."
}
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
},
chore(flatpak): update runtime to 5.14
2020-04-20 22:08:50 +08:00
"cleanup-commands": [
"mkdir -p /app/lib/ffmpeg"
],
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"cleanup": [
"/include",
"/lib/pkgconfig",
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"/share/man",
"*.la",
"*.a"
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
],
"modules": [
{
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"name": "tcl",
"subdir": "unix",
"build-options": {
"no-debuginfo": true
},
chore(flatpak): Fix JSON syntax, single quote to double quote
2021-12-19 21:48:02 +08:00
"cleanup": [ "*" ],
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"sources": [
{
"type": "archive",
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"url": "https://downloads.sourceforge.net/project/tcl/Tcl/8.6.10/tcl8.6.10-src.tar.gz",
"sha256": "5196dbf6638e3df8d5c87b5815c8c2b758496eb6f0e41446596c9a4e638d87ed"
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
}
]
},
{
"name": "sqlcipher",
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"cleanup": [
"/bin"
],
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"config-opts": [
"--enable-tempstore=yes",
"--disable-tcl"
],
chore(flatpak): reduce difference to Flathub build
2020-03-14 20:55:24 +08:00
"build-options": {
"cflags": "-DSQLITE_HAS_CODEC",
"ldflags": "-lcrypto"
},
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"sources": [
{
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
"type": "dir",
"path": "/src/sqlcipher"
chore(deploy): add snorenotify to Flatpak manifest
2018-07-13 04:14:01 +08:00
}
]
},
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
{
"name": "libsodium",
"sources": [
{
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
"type": "dir",
"path": "/src/libsodium"
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
}
]
},
chore(deps): Add support for msgpack dependency
2022-02-19 10:18:56 +08:00
{
"name": "msgpack",
"buildsystem": "cmake-ninja",
"config-opts": [
"-DCMAKE_BUILD_TYPE=Release",
"-DMSGPACK_BUILD_EXAMPLES=OFF",
"-DMSGPACK_BUILD_TESTS=OFF"
],
"sources": [
{
"type": "dir",
"path": "/src/msgpack"
}
]
},
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
{
"name": "c-toxcore",
"buildsystem": "cmake-ninja",
chore(release): Merge flathub flatpak manifest with local Remove snorenotify dep because it was accidentally included. This should have been done prior to v1.17.3 release, updated in #6264.
2020-11-25 19:53:48 +08:00
"config-opts": [
fix(flatpak): Build flatpak qTox and dependencies in Release mode
2021-12-20 16:25:30 +08:00
"-DCMAKE_BUILD_TYPE=Release",
chore(release): Merge flathub flatpak manifest with local Remove snorenotify dep because it was accidentally included. This should have been done prior to v1.17.3 release, updated in #6264.
2020-11-25 19:53:48 +08:00
"-DDHT_BOOTSTRAP=OFF",
"-DBOOTSTRAP_DAEMON=OFF",
"-DENABLE_STATIC=OFF"
],
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"sources": [
{
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
"type": "dir",
"path": "/src/toxcore"
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
}
]
},
fix(extensions): Add toxext to CI scripts
2019-11-18 06:00:25 +08:00
{
"name": "toxext",
"buildsystem": "cmake-ninja",
fix(flatpak): Build flatpak qTox and dependencies in Release mode
2021-12-20 16:25:30 +08:00
"config-opts": [
"-DCMAKE_BUILD_TYPE=Release"
],
fix(extensions): Add toxext to CI scripts
2019-11-18 06:00:25 +08:00
"sources": [
{
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
"type": "dir",
"path": "/src/toxext"
fix(extensions): Add toxext to CI scripts
2019-11-18 06:00:25 +08:00
}
]
},
{
"name": "tox_extension_messages",
"buildsystem": "cmake-ninja",
fix(flatpak): Build flatpak qTox and dependencies in Release mode
2021-12-20 16:25:30 +08:00
"config-opts": [
"-DCMAKE_BUILD_TYPE=Release"
],
fix(extensions): Add toxext to CI scripts
2019-11-18 06:00:25 +08:00
"sources": [
{
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
"type": "dir",
"path": "/src/toxext_messages"
fix(extensions): Add toxext to CI scripts
2019-11-18 06:00:25 +08:00
}
]
},
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
{
"name": "qTox",
"buildsystem": "cmake-ninja",
fix(build): disable Werror by default, keep enabled on CI To allow for easier building with different compilers on user systems. Keep strict checks on CI to make sure new warnings aren't ignored.
2020-04-12 16:34:31 +08:00
"config-opts": [
fix(flatpak): Build flatpak qTox and dependencies in Release mode
2021-12-20 16:25:30 +08:00
"-DCMAKE_BUILD_TYPE=Release",
fix(build): disable Werror by default, keep enabled on CI To allow for easier building with different compilers on user systems. Keep strict checks on CI to make sure new warnings aren't ignored.
2020-04-12 16:34:31 +08:00
"-DSVGZ_ICON=OFF",
"-DSTRICT_OPTIONS=ON"
],
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
"sources": [
{
"type": "dir",
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
"path": "/qtox/"
chore(deploy): keep our own copy of the flatpak manifest in this repo This allows us to easily add dependencies or change the build for new features, but has the downside that we have to sync to the flathub.org repo on a release
2018-07-12 20:29:01 +08:00
}
]
}
]
}
Reference in New Issue Copy Permalink