<div dir="ltr"><div dir="ltr">On Thu, Jan 26, 2023 at 1:30 AM L. E. Segovia <<a href="mailto:amy@amyspark.me">amy@amyspark.me</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">Hey!<br>
<br>
(inline replies for clarity)<br>
<br>
On 25/01/2023 05:48, Ben Cooksley wrote:<br>
> On Wed, Jan 25, 2023 at 2:18 AM L. E. Segovia <<a href="mailto:amy@amyspark.me" target="_blank">amy@amyspark.me</a><br>
> <mailto:<a href="mailto:amy@amyspark.me" target="_blank">amy@amyspark.me</a>>> wrote:<br>
> <br>
>     Hi all,<br>
> <br>
> <br>
> Hi Amy,<br>
>  <br>
> <br>
> <br>
>     (cc Ben for specifics)<br>
> <br>
>     - What kind of packages are being required by syadmin? Will they be<br>
>     granular image layers, like the ASWF does for their Docker setup?<br>
>     <a href="https://github.com/AcademySoftwareFoundation/aswf-docker" rel="noreferrer" target="_blank">https://github.com/AcademySoftwareFoundation/aswf-docker</a><br>
>     <<a href="https://github.com/AcademySoftwareFoundation/aswf-docker" rel="noreferrer" target="_blank">https://github.com/AcademySoftwareFoundation/aswf-docker</a>><br>
> <br>
> <br>
> The packages could come in whatever form works best for Krita, however<br>
> for the sake of simplicity and being cross platform i'd suggest a simple<br>
> tarball for each dependency.<br>
> You can use the DESTDIR / INSTALL_PATH variables to divert the "make<br>
> install" phase of each dependency in turn to a separate folder which can<br>
> then be turned into a tarball.<br>
> <br>
> This is how Linux distributions do their packaging, and is also how the<br>
> CI system works (with said CI artifacts also supporting <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a><br>
> <<a href="http://apps.kde.org" rel="noreferrer" target="_blank">http://apps.kde.org</a>>).<br>
> You can find an example artifact for Krita<br>
> at <a href="https://invent.kde.org/groups/teams/ci-artifacts/-/packages?search[]=krita" rel="noreferrer" target="_blank">https://invent.kde.org/groups/teams/ci-artifacts/-/packages?search[]=krita</a> <<a href="https://invent.kde.org/groups/teams/ci-artifacts/-/packages?search[]=krita" rel="noreferrer" target="_blank">https://invent.kde.org/groups/teams/ci-artifacts/-/packages?search[]=krita</a>><br>
>  <br>
<br>
Going to research this more, but using DESTDIR/INSTALL_PATH feels like<br>
an Autotoolism-- in any case, it should give at least problems when<br>
relocating dependencies e.g. with pkg-config .pc files. (I may have<br>
already seen such a problem with the Python 3.10 build last night, am<br>
awaiting confirmation.)<br></blockquote><div><br></div><div>Whilst it may seem like an "Autotoolism" it is very much fully supported by CMake (and likely other build systems)</div><div>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. </div><div><br></div><div>I'd be very surprised if Python did not properly support DESTDIR/INSTALL_ROOT.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What I had in mind was one of:<br>
<br>
- the ASWF's overlaid Docker images, where each artifact image calls<br>
upon the images of its dependencies<br>
- Homebrew's usage of Docker scratch containers to store the artifact<br>
contents<br></blockquote><div><br></div><div>Docker is not available for native use on macOS to my knowledge, which creates a bit of a problem there no?</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>
>     - Whether Docker or not, is Sysadmin making available the container<br>
>     registry feature of Gitlab?<br>
> <br>
> <br>
> There are no plans to make the Container Registry feature of Gitlab<br>
> available, as we have a namespace on Dockerhub which hosts our images.<br>
> <br>
> If you are thinking of creating custom images, i'd first advise you<br>
> first to strongly consider using the centrally maintained/updated images.<br>
> If they are actually completely unsuitable then submit a MR to add the<br>
> appropriate image there.<br>
> <br>
> For Linux the centos7-craft image is the image used to build all our<br>
> other appimages, so please don't reinvent the wheel there.<br>
> <br>
> For Windows you likely will need to create a custom image due to Krita's<br>
> use of MIngW-LLVM and Strawberry Perl among other things. Given you<br>
> still need at least part of the Windows SDK, please use windows-msvc2019<br>
> as your base (which also includes Python and Git) - the Windows SDK<br>
> components are a real mission to get installed reliably in Docker which<br>
> took more than a few goes to get working and I don't fancy looking after<br>
> that in more than one place.<br>
<br>
I do not think we need extra base images (see above re: homebrew). But<br>
you're right in that we will need at least to customize the compiler. We<br>
can already deploy Strawberry Perl if missing.<br></blockquote><div><br></div><div>If something changes infrequently then it makes more sense to have it burned into the image.</div><div>Ensures that things run faster and use less resources for one.</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>
> <br>
> <br>
>     Cheers,<br>
> <br>
>     amyspark<br>
> <br>
> <br>
> Thanks,<br>
> Ben<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</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>
> <br>
>     On 24/01/2023 07:04, Halla Rempt wrote:<br>
>     > We discussed that this morning on IRC. There's no ETA for when<br>
>     making builds on invent will be possible: first signing needs to be<br>
>     in place. It will mean a lot of changes to our tooling. Ben also<br>
>     wants us to start using gitlab packages instead of a single<br>
>     depencency build thing so we can update them more granularly.<br>
>     ><br>
>     > On dinsdag 24 januari 2023 09:49:26 CET Halla Rempt wrote:<br>
>     >> I guess we'd first have to ask Ben when invent's CI is up to<br>
>     making release and nightly builds?<br>
>     >><br>
>     >> On maandag 23 januari 2023 17:59:15 CET L. E. Segovia wrote:<br>
>     >>> Hi all,<br>
>     >>><br>
>     >>> As discussed on the meeting, we need to figure out a path<br>
>     forward with<br>
>     >>> 3rdparty and the nightly builds. Sysadmin will decommission Jenkins<br>
>     >>> Soon(tm) and as part of it we should set a stable 3rdparty build<br>
>     up in<br>
>     >>> Gitlab Runner. This is needed sooner than later because we'd need to<br>
>     >>> make a 5.1.x build available, before switching stable branches.<br>
>     >>><br>
>     >>> Please write back and let me know when you're available.<br>
>     >>><br>
>     >>> Cheers,<br>
>     >>><br>
>     >>> amyspark<br>
>     >>><br>
>     >>><br>
>     >><br>
>     >><br>
>     >><br>
>     >><br>
>     >><br>
>     ><br>
>     ><br>
>     ><br>
>     ><br>
> <br>
>     -- <br>
>     amyspark 🌸 <a href="https://www.amyspark.me" rel="noreferrer" target="_blank">https://www.amyspark.me</a> <<a href="https://www.amyspark.me" rel="noreferrer" target="_blank">https://www.amyspark.me</a>><br>
> <br>
<br>
-- <br>
amyspark 🌸 <a href="https://www.amyspark.me" rel="noreferrer" target="_blank">https://www.amyspark.me</a><br>
</blockquote></div></div>