On Fri, Jan 24, 2025 at 4:44 PM Justin Zobel <jus...@1707.io> wrote:
> On 24/1/25 02:55, Volker Krause wrote: > > On Donnerstag, 23. Januar 2025 10:21:08 Mitteleuropäische Normalzeit Ben > > Cooksley wrote: > >> On Thu, Jan 23, 2025 at 7:21 AM Volker Krause <vkra...@kde.org> wrote: > >>> On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben > >>> > >>> Cooksley wrote: > >>>> On Thu, Jan 23, 2025 at 5:49 AM Volker Krause <vkra...@kde.org> > wrote: > >>>>> On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit > >>> Albert > >>> > >>>>> Astals Cid wrote: > >>>>>> neochat - NEW > >>>>>> > >>>>>> * https://invent.kde.org/network/neochat/-/pipelines/869365 > >>>>>> > >>>>>> * flatpak build fails > >>>>> Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 > I > >>>>> guess, > >>>>> looks like an API change in libQuotient with the corresponding > version > >>>>> change > >>>>> still pending (ie. a similar problem we occasionally hit with > >>>>> Poppler). > >>>>> > >>>>> The quick solution for this would probably be (temporarily) switching > >>>>> Flatpak > >>>>> to the latest release of libQuotient. The IMHO proper solution would > >>> be to > >>> > >>>>> have version bumps at the beginning of a development cycle that > >>>>> changes > >>>>> API. > >>>> This also raises another question though - should we be strongly > >>>> discouraging use of heavily moving targets like upstream dev / master > >>>> branches and instead favouring the use of stable branches? > >>>> Not really ideal if upstream can essentially break our builds without > us > >>>> doing anything. > >>> I can't comment on NeoChat, but for Itinerary the builds against the > >>> latest > >>> versions of essential (external) dependencies with varying > >>> intentions/success > >>> in keeping backward compatibility (ZXing, Poppler, Quotient) are very > much > >>> deliberate, to catch breakage/regressions early (same as we are now > doing > >>> for > >>> KF with Qt pre-releases). > >>> > >>> And this is actually working, NeoChat has been fixed to build with the > >>> upcoming > >>> Quotient version, same for Itinerary/Poppler. The only thing we are > >>> missing > >>> for those fixes to take effect is those dependencies bumping their > version > >>> numbers. > >>> > >>> We could work around that by doing configure-time detection using a > >>> compile > >>> test, but that's a lot of extra work, so we'd better try to address > this > >>> upstream first. > >>> > >>> > >>> I'd very much suggest the use of release tarballs (or stable branches) > for > >>> apps that aren't continuously monitoring their dependencies this way > >>> though, > >>> but I'm not aware we have such a case. > >> Doesn't this interfere somewhat with the long term eventual goal of us > >> pushing Flatpak binaries directly to Flathub though? > >> (not to mention make stable branch builds impossible to reproduce in the > >> long run) > > For Itinerary at least the release branch is using release tarballs > rather > > than (latest) Git branches, matching what we have on Flathub. (This does > imply > > some manual work at branch time, but at least for me that's more than > offset by > > what this saves in catching issues early). > > > > But you are right of course that this is abusing Flatpak a bit as CI. > That's > > not ideal but it's just very tempting as it has minimal extra cost > (Flatpak > > has to build those dependencies anyway, and Flatpak builds run less > often than > > normal CI builds). > > > > Regards, > > Volker > > I've moved this to a new email subject as it's no longer just about > failing CI builds. > > My proposal would be have 3 files in the repository that are Flatpak > related: > > - .flatpak-manifest.yml will continue to exist for git master builds and > be deployed to https://cdn.kde.org/flatpak/ > > - org.kde.appname.json which will be for Flathub stable builds will only > run on release branches when a tag is made (I am hoping CI can be > triggered by a tag). > > - Both will reference a file called org.kde.appname.dependencies.json > which contains the the dependencies that get build for the app and will > point to tarballs or tags for released versions. > Not sure how that solves the issue? Currently the issue is the version of the dependencies - with us using master / equivalent branches in our Flatpak jobs. Having a shared file for that would ensure that impacts Flathub builds or other stable builds we run as well. I had been thinking that having a separate file that would be used instead of .flatpak-manifest.yml if present when doing a build on a stable branch would be a good solution. Under this you would have a .flatpak-manifest.yml and a .flatpak-manifest-stable.yml file When building on master the .flatpak-manifest.yml file would be used, but when on a release branch / tag the .flatpak-manifest-stable.yml file would be used instead (if present). That would eliminate needing the release manager / developer to update .flatpak-manifest.yml on branching a new stable release branch. > Flatpak supports referencing external files for build dependencies and > you can use JSON or YAML interchangeably. > > I think this will be good for Flatpak builds as we really want them > targeting the stable released tarballs, not some function in git master > of a dependency that *MIGHT* be released in time for the next KDE release. > > Cheers, Ben
