Re: Gnome Flatpak build system, descriptions and questions

On Fri, 2016-08-26 at 09:43 +0200, Alexander Larsson wrote:
On tor, 2016-08-25 at 17:29 +0100, Richard Hughes wrote:
On 25 August 2016 at 16:29, Alexander Larsson <alexl redhat com>

However, it would
make more sense for each individual application developers to
the manifest in the applications git repo.
I think this is a very good idea indeed; I was confused about the
"centralization" aspect of the builder files. Isn't this just some
globbing, if we all agree to put the manifest in the same place in
git tree?

Well, it was initially put in a separate git repo as we were just a
people trying to build a lot of apps, and that was the easiest way to
get started. However, now that things are a bit more stable moving it
to each individual repo makes sense.

There are some complexities though. There are two things we want to
build, the "latest unstable" and the "last stable release". The
solution is to store a json file with a predictable name in master
the unstable release, and in the latest stable branch for the stable

However, how do we find which git repos have such json files, and how
do we know what is the current latest stable branch? Also, its
weird to clone the entire git repo just to get a json file that then
itself may refer to the git repo.

Another issue is that we'd like the to have some control of what gets
built, at least for the stable builds. Right now we just pull the
gnome-apps-nightly repo and assumes it is correct (i.e nobody
an attack to git or MITMed our connection to, but from
there everything is verified by sha256 on all the various tarballs
are downloaded. Getting even this level of verification is trickier
when things are spread all across Ideally we should
some kind of gpg signatures for the stable commits so that we can
verify everything from that, but we don't really have that kind of
setup for gnome git.

Anyway, the best we can do now is i think having a git repo, say
apps-nightly, that has two files in it, listing for each row:
* A git repo
* A branch name
* The filename of the json manifest in the repo
One of the files would be for unstable/nightly builds, and the other
for stable builds.

You can replace all 3 of those items with a URL pointing to the file in
an https cgit.

2 problems with requiring GPG signatures for stable releases though:
- gnupg's "UI" sucks utterly
- we really should have had people signing each other's keys at GUADEC
when face to face

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]