<div dir="ltr"><div dir="ltr">On Wed, Oct 12, 2022 at 2:51 AM Steven Robbins <<a href="mailto:steve@sumost.ca">steve@sumost.ca</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, October 11, 2022 3:20:06 A.M. CDT Ben Cooksley wrote:<br>
> On Tue, Oct 11, 2022 at 6:49 PM Steven Robbins <<a href="mailto:steve@sumost.ca" target="_blank">steve@sumost.ca</a>> wrote:<br>
<br>
> > I am trying to understand how libraries are selected for installation on<br>
> > the<br>
> > KDE CI/CD machines. <br>
<br>
> There are a couple of things here to pull apart.<br>
> <br>
> First, the Gitlab CI jobs you mention above themselves don't use Craft at<br>
> all at build time, so the above configurations you are referring to have no<br>
> impact whatsoever.<br>
<br>
Ah, that's one crucial detail, thanks!<br>
<br>
> Those jobs rely on KDE specific Docker containers on Linux and Windows, and<br>
> on FreeBSD is a fixed statically provisioned machine.<br>
> For Linux and FreeBSD, we use only distribution provided packages for those<br>
> systems - while on Windows we use Craft to deploy a static and<br>
> centrally managed list of packages on the system.<br>
<br>
OK.  Can you help me understand the full scope of Craft?  Is it solely for the <br>
windows CI configuration?  I've heard that there are also distribution builders <br>
(for flatpack and the like) -- is Craft involved in any of that?<br></blockquote><div><br></div><div>There are two parts of our systems:</div><div>a) Continuous Integration, which runs unit tests, code quality checks and monitors code to ensure it compiles</div><div>b) Continuous Delivery, which produces binaries for end users to use.</div><div><br></div><div>Prior to the move to Gitlab, (a) was handled by <a href="http://build.kde.org">build.kde.org</a>, while (b) was handled by <a href="http://binary-factory.kde.org">binary-factory.kde.org</a>.</div><div>While the move to GItlab for (a) is complete, it has yet to be completed for (b) but will be in the next few months.</div><div><br></div><div>Craft is for the most part only involved in (b). </div><div><br></div><div>The only places Craft is used in (a) is to produce Docker images for Windows and Android which the system uses to carry out its CI runs.</div><div>These image builds are always using a static configuration which is centrally maintained and cannot be varied on a per-project basis.</div><div><br></div><div>With regards to the production of Binaries, Craft is used for the following types of builds:</div><div>(a) Windows installers, portable archives and store upload bundles </div><div>(b) Android APKs</div><div>(c) Linux Appimages</div><div>(d) macOS *.app / DMG bundles</div><div><br></div><div>Linux Flatpak bundles are built using their own tooling, which is what the existing Gitlab Flatpak job we already have in place does.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> You are therefore subject to whatever versions of ffmpeg are provided by<br>
> OpenSUSE (our Linux Docker image provider) and FreeBSD for those platforms,<br>
> and on Windows whatever Craft has specified as the default version of<br>
> ffmpeg.<br>
<br>
OK -- this explains windows I suppose, as the default ffmpeg is indeed set to <br>
5.0.1 [1].  Is this the default setting you refer to?<br>
<br>
[1] <a href="https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/libs/ffmpeg/ffmpeg.py#L25" rel="noreferrer" target="_blank">https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/libs/<br>
ffmpeg/ffmpeg.py#L25</a></blockquote><div><br></div><div>Yes, that is the setting.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
For OpenSUSE and FreeBSD: is there a central location I can check to <br>
understand what version of suse/freebsd is being presently used?  How often <br>
are OS updates done?  Is there an annoucement list to track this?<br></blockquote><div><br></div><div>The SUSE images are updated periodically on an as-needed basis to bring in updates or additional packages we need.</div><div>There is no set schedule for this. (same applies for the other Docker images we have)</div><div><br></div><div>You can view the build logs for all our Docker images (covering LInux, Android and Windows) in the CI section of <a href="https://invent.kde.org/sysadmin/ci-images/">https://invent.kde.org/sysadmin/ci-images/</a></div><div>Our Dockerfile definitions are hosted in that same repository.</div><div><br></div><div>For FreeBSD, those VMs are maintained by the KDE FreeBSD team on Virtual Machines provided by KDE Sysadmin.</div><div>These are maintained manually, and once again there is no schedule for this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Now comes my real question.  At present, Digikam aims to support both FFMPEG 4 <br>
and 5.  Therefore it is best to test both configurations.  Is there any <br>
mechanism to have TWO CI runners per OS -- one with each version of ffmpeg?<br></blockquote><div><br></div><div>Sorry, but it is unnecessary to have two builds per operating system when you will get just as good coverage by having Linux build with ffmpeg 4 and Windows build with ffmpeg 5.</div><div>We adopt the same process for testing compiler coverage, with Linux handling GCC, FreeBSD handling Clang and Windows handling MSVC.</div><div><br></div><div>Additionally, Digikam is one of three projects that consume significant amounts of CI resources, so i'd very much rather that didn't grow further.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> With regards to your Craft Blueprint above, my understanding is that what<br>
> you have there is not valid syntax, as Craft doesn't look at individual<br>
> blueprints to resolve versions to use.<br>
> This is why in your Binary Factory configuration you have the following<br>
> specified:<br>
> <br>
> 'Digikam':<br>
>  buildBlueprint: "digikam"<br>
>  versions:<br>
>  - name: 'Nightly'<br>
>    target: 'master'<br>
>    packageAppx: True<br>
>    options:<br>
>    - 'libs/ffmpeg.version=4.4'<br>
>  platforms:<br>
>  - 'macos'<br>
>  - 'win64'<br>
>  - 'mingw64'<br>
>  - 'appimage-centos7'<br>
>  - 'android-x86_64'<br>
<br>
OK, but then is anything actually adhering to "libs/ffmpeg.version=4.4"?  <br>
Clearly the windows CI runner is not.<br></blockquote><div><br></div><div>This is from your Binary Factory build configuration, which is the (b) I mentioned above and quite separate and different to (a).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks very much!<br>
-Steve<br></blockquote><div><br></div><div>Regards,</div><div>Ben </div></div></div>