[GNC-dev] [MAINT] Cleaning up Code (the server)

Geert Janssens geert.gnucash at kobaltwit.be
Thu Aug 22 04:29:57 EDT 2019

Op dinsdag 13 augustus 2019 22:53:34 CEST schreef John Ralls:
> > On Aug 13, 2019, at 9:14 AM, Derek Atkins <derek at ihtfp.com> wrote:
> >> There don't seem to be any flatpak release builds. Should there be and if
> >> so should I include them in the release downloads on SourceForge and
> >> Github?
> > 
> > Not yet.  Remember that right now code is sitting behind a tiny straw.
> > Once I can move back to my main network then we can advertise that.
> This wouldn't be advertising, it would be me downloading one flatpack at
> release and uploading it to SF and Github just as I do with Windows
> releases.

Flatpak by default works slightly differently: instead of distributing a 
selfcontained installer it stores all builds in a public repo and that's where 
users would expect to get it from. The most widely known and used repo is 
currently flathub.org.

Also you don't upload a fully built package to flathub. Instead you commit the 
build manifest and their buildsystem will use that to reproduce the necessary 
build artefacts that allows users to install the newest gnucash package from 

I have recently become co-maintainer (well, defacto maintainer) of the gnucash 
repo on flathub. I have been tweaking their build manifest file to be closer 
to the one we use for our nightly builds.
My ultimate goal is to be able to simply push the manifest generated for our 
release nightly build to flathub. The idea is that if our nightly build server 
can successfully build the release, flathub will be able to as well. As they 
use the same strictly defined sandboxes that should work most of the cases.

The only caveat: flathub builds for 4 architectures (arm, aarch64, i386, 
x86_64), we build only for one. So if we have architecture incompatibilities, 
things may break anyway. That would require manual tweaks of the manifest for 
flathub. The typical handling of package failures (on distros as well) is 
adding patches to fix the issue. These patches would probably also be applied 
to our source repos so they'll become incorporated in the next release 



More information about the gnucash-devel mailing list