Meeting: 3rdparty and nightlies

Wed Jan 25 18:14:51 GMT 2023

On Thu, Jan 26, 2023 at 1:30 AM L. E. Segovia <amy at amyspark.me> wrote:

> 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.)
>

Whilst it may seem like an "Autotoolism" it is very much fully supported by
CMake (and likely other build systems)
Note that this is an environment variable, not something you pass as a
configuration argument, and it only should be present when running "make
install" not during any other part of the build process.

I'd be very surprised if Python did not properly support
DESTDIR/INSTALL_ROOT.

> 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
>

Docker is not available for native use on macOS to my knowledge, which
creates a bit of a problem there no?

>
> >
> >     - 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.
>

If something changes infrequently then it makes more sense to have it
burned into the image.
Ensures that things run faster and use less resources for one.

>
> >
> >
> >
> >     Cheers,
> >
> >     amyspark
> >
> >
> > Thanks,
> > Ben
>

Cheers,
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230126/d8eab55a/attachment-0001.htm>