Meeting: 3rdparty and nightlies

[L. E. Segovia]

Hey!

(inline replies for clarity)

On 25/01/2023 05:48, Ben Cooksley wrote:
> On Wed, Jan 25, 2023 at 2:18 AM L. E. Segovia <amy at amyspark.me
> <mailto:amy at amyspark.me>> wrote:
> 
>     Hi all,
> 
> 
> Hi Amy,
>  
> 
> 
>     (cc Ben for specifics)
> 
>     - What kind of packages are being required by syadmin? Will they be
>     granular image layers, like the ASWF does for their Docker setup?
>     https://github.com/AcademySoftwareFoundation/aswf-docker
>     <https://github.com/AcademySoftwareFoundation/aswf-docker>
> 
> 
> The packages could come in whatever form works best for Krita, however
> for the sake of simplicity and being cross platform i'd suggest a simple
> tarball for each dependency.
> You can use the DESTDIR / INSTALL_PATH variables to divert the "make
> install" phase of each dependency in turn to a separate folder which can
> then be turned into a tarball.
> 
> This is how Linux distributions do their packaging, and is also how the
> CI system works (with said CI artifacts also supporting apps.kde.org
> <http://apps.kde.org>).
> You can find an example artifact for Krita
> at https://invent.kde.org/groups/teams/ci-artifacts/-/packages?search[]=krita <https://invent.kde.org/groups/teams/ci-artifacts/-/packages?search[]=krita>
>  

Going to research this more, but using DESTDIR/INSTALL_PATH feels like
an Autotoolism-- in any case, it should give at least problems when
relocating dependencies e.g. with pkg-config .pc files. (I may have
already seen such a problem with the Python 3.10 build last night, am
awaiting confirmation.)

What I had in mind was one of:

- the ASWF's overlaid Docker images, where each artifact image calls
upon the images of its dependencies
- Homebrew's usage of Docker scratch containers to store the artifact
contents

> 
>     - Whether Docker or not, is Sysadmin making available the container
>     registry feature of Gitlab?
> 
> 
> There are no plans to make the Container Registry feature of Gitlab
> available, as we have a namespace on Dockerhub which hosts our images.
> 
> If you are thinking of creating custom images, i'd first advise you
> first to strongly consider using the centrally maintained/updated images.
> If they are actually completely unsuitable then submit a MR to add the
> appropriate image there.
> 
> For Linux the centos7-craft image is the image used to build all our
> other appimages, so please don't reinvent the wheel there.
> 
> For Windows you likely will need to create a custom image due to Krita's
> use of MIngW-LLVM and Strawberry Perl among other things. Given you
> still need at least part of the Windows SDK, please use windows-msvc2019
> as your base (which also includes Python and Git) - the Windows SDK
> components are a real mission to get installed reliably in Docker which
> took more than a few goes to get working and I don't fancy looking after
> that in more than one place.

I do not think we need extra base images (see above re: homebrew). But
you're right in that we will need at least to customize the compiler. We
can already deploy Strawberry Perl if missing.

>  
> 
> 
>     Cheers,
> 
>     amyspark
> 
> 
> Thanks,
> Ben
>  
> 
> 
>     On 24/01/2023 07:04, Halla Rempt wrote:
>     > We discussed that this morning on IRC. There's no ETA for when
>     making builds on invent will be possible: first signing needs to be
>     in place. It will mean a lot of changes to our tooling. Ben also
>     wants us to start using gitlab packages instead of a single
>     depencency build thing so we can update them more granularly.
>     >
>     > On dinsdag 24 januari 2023 09:49:26 CET Halla Rempt wrote:
>     >> I guess we'd first have to ask Ben when invent's CI is up to
>     making release and nightly builds?
>     >>
>     >> On maandag 23 januari 2023 17:59:15 CET L. E. Segovia wrote:
>     >>> Hi all,
>     >>>
>     >>> As discussed on the meeting, we need to figure out a path
>     forward with
>     >>> 3rdparty and the nightly builds. Sysadmin will decommission Jenkins
>     >>> Soon(tm) and as part of it we should set a stable 3rdparty build
>     up in
>     >>> Gitlab Runner. This is needed sooner than later because we'd need to
>     >>> make a 5.1.x build available, before switching stable branches.
>     >>>
>     >>> Please write back and let me know when you're available.
>     >>>
>     >>> Cheers,
>     >>>
>     >>> amyspark
>     >>>
>     >>>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >
>     >
>     >
>     >
> 
>     -- 
>     amyspark 🌸 https://www.amyspark.me <https://www.amyspark.me>
> 

-- 
amyspark 🌸 https://www.amyspark.me