@eht16 pushed 1 commit.

ef3cb321ec3bf9100baeacd6c9603e8c02be829b Add nightly and CI build scripts to create Windows installers

@eht16 pushed 1 commit.

01031a2ccceb15f08e6910810f0a199887cd12c4 Update MSYS2 keyring package

@eht16 pushed 1 commit.

18dc699d256fbbc6ec0e75aefca6033365a164f8 Add nightly and CI build scripts to create Windows installers

@eht16 pushed 1 commit.

ee8ff28c2068bf592b1a229aa3d5605f7f5dedc3 Update MSYS2 keyring

@eht16 pushed 1 commit.

897982f83f2c0e24ead04dee9efc40cf0607840a Add nightly and CI build scripts to create Windows installers

Wild!

Why is the mingw container not Arch Linux based such that pacman doesnt need to be compiled? I would also expect that other packages take less time to install.

Do I understand correctly that the Docker image is updated manually, and a PR on geany or G-P would download that pre-build image (or even use cached copies) instead of rolling the container every single time (including compiling pacman)?

Remark #1: Generally speaking I'm not a huge fan of docker but since that doesn't run on my machine it's probably OK :-) Remark #2: I use arch linux on my machine. If you don't feel familiar enough with it I can maybe help you.

Why is the mingw container not Arch Linux based such that pacman doesnt need to be compiled? I would also expect that other packages take less time to install.

Personal preference and the fact that most other CI resources are also Debian/Ubuntu based. I don't know if it would make a difference in package installation speed. Why and does it matter if it is a few seconds faster or slower? Furthermore, I'm not sure if ArchLinux's pre-compiled pacman can be used as is. The self-compiled variant uses a different path layout.

Do I understand correctly that the Docker image is updated manually, and a PR on geany or G-P would download that pre-build image (or even use cached copies) instead of rolling the container every single time (including compiling pacman)?

First, the current image available in the registry is built and uploaded by me manually. As said in the G-P PR this is an open TODO.

A CI job will try to pull the image from the registry, due to current permissions settings this probably works only for jobs trigger from the repository itself (master builds and PRs created from the repository itself, not forks).

CI jobs which are triggered by a forked repository will *not* have access to the image in the registry and so fall back to build it on the fly.

In theory, we could push that on the fly built image into the registry. But I consider this too risky to open doors for malicious input.

I didn't make my mind up finally on how to deal with the proper image management: - Should we build it reguarly independent from the CI jobs? - Which repository handles updating the image, Geany or Geany-PLugins or Infrastructure? - Should we open the restrictions and allow access to the image also for forked repositories?

Remark #1: Generally speaking I'm not a huge fan of docker but since that doesn't run on my machine it's probably OK :-)

It took me a few years also to see its advantages and why it might be useful. I think in this it's a quite convenient tool to have a isolated environment to build the code.

Remark #2: I use arch linux on my machine. If you don't feel familiar enough with it I can maybe help you.

I used Arch Linux until a few months ago as well, but IMO this is no reason to use it here :). Again, I guess it won't make a relevant different except that we would have to port the existing scripts. I guess more people out there are already or can get familiar with a Debian/Ubuntu system. Do you have any other reason for switching to ArchLinux?

One more (personal) reason to use Arch: You know I'm working on a flatpak version of Geany. Assuming we ever want to create such a flatpak image for official releases via CI, then I would certainly prefer Arch Linux because that has the latest flatpak tooling.

But that doesn't necessarily mean mingw jobs must use Arch Linux containers as well, so still your choice.

@eht16 commented on this pull request.

+COPY mingw64/bin/ /usr/local/bin/

+RUN ln -s /usr/local/pacman/bin/* /usr/local/bin/ && \ + mkdir /build + +WORKDIR /build +ENV LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pacman/lib/x86_64-linux-gnu + +# start wine to initially create config directory +RUN /usr/local/bin/mingw-w64-i686-wine hostname.exe && \ + /usr/local/bin/mingw-w64-x86_64-wine hostname.exe && \ + # install GTK3 and all its dependencies + pacman --noconfirm -Sy mingw-w64-x86_64-gtk3 && \ + # cleanup + apt-get clean && \ + rm -rf /var/lib/apt/lists/* && \ + yes | pacman -Scc && \

I guess you did not test what you suggest? `--noconfirm` does *not* clean the caches as the default for the question "Do you want to remove ALL files from cache? [y/N]" is no.

In this context `yes` seems to work as intended. Did you experience a certain problem?

I just thought it's a better match because it comes with pacman, but also because it is generally up-to-date w.r.t. to toolchains and wine. So we could build the Windows binaries using the latest and greatest toolchain.

Debian/Ubuntu is usually several years behind and I worry a bit if that might cause trouble in the future if mingw packages require a newer toolchain (mingw is also rolling like Arch AFAIK). But it's your choice.

One more (personal) reason to use Arch: You know I'm working on a flatpak version of Geany. Assuming we ever want to create such a flatpak image for official releases via CI, then I would certainly prefer Arch Linux because that has the latest flatpak tooling.

But that doesn't necessarily mean mingw jobs must use Arch Linux containers as well, so still your choice.

I was working on these scripts since 2021 or maybe even 2020 and had no problems with the toolchains provided by Debian, AFAIR. Of course, I cannot guarantee that it will keep it this way. But as previous long time ArchLinux user I also know sometimes ArchLinux is so bleeding edge that its toolchain or other components *might* be too new for other software which is not yet compatible. So I guess this can happen in both directions.

And please stop this too old joke of Debian being "several years" behind. It's usually rather 1-2 years and this is on purpose.

After all, I guess Debian and ArchLinux could work as base and given that the current setup works with Debian, I personally see no need to change it.

I don't really like that this repository knows how to build Geany and G-P.

A developer might make changes in that area and might become unable to proceed because he can't get CI to work as the job needs to be adapted.

A realistic example: we might want to switch to the meson build by default (or maybe only for specific platforms) and the PR to implement would be unable to fix the CI.

We should probably just provide the Docker image itself and not the scripts to build Geany or packages.

Agreed. We could move builders/scripts/build_mingw64_geany_plugins.sh and its companions to the Geany resp. G-P repos. Will try once I find time for it.

I guess I did it this way because the initial idea of all this started with renewing the nightly build scripts and over the time it turned out to be usable for CI builds as well.

I think the current restrictions are OK. Perhaps we could auto-update the image based on CI but I wouldn't trigger that from Geany repos but this repository (this is where the dockerfile is after all).

Sounds good to me.

Do we have anything to lose when giving forks access to the image, like losing some GH actions budget to it?

Not that I know of. To me it seems that GH actions are not billed at all for us and so there is also no budget or limit. Giving read access to forks should be OK, even if it would be read access to the world. We should note that images cannot be deleted anymore once they have been made public which is reasonable and probably also acceptable for a automatically built CI image.

...

I don't really like that this repository knows how to build Geany and G-P. A developer might make changes in that area and might become unable to proceed because he can't get CI to work as the job needs to be adapted. A realistic example: we might want to switch to the meson build by default (or maybe only for specific platforms) and the PR to implement would be unable to fix the CI. We should probably just provide the Docker image itself and not the scripts to build Geany or packages.

Agreed. We could move builders/scripts/build_mingw64_geany_plugins.sh and its companions to the Geany resp. G-P repos. Will try once I find time for it.

Done. The scripts to build Geany and Geany-Plugins are now in their respective repositories. This required to create https://github.com/geany/geany/pull/3315 but it was on my TODO anyway.

@eht16 pushed 1 commit.

7f07a62e42326f0a7b96facfeb5c3fd6a02b1f59 CI: Add workflow to build geany-mingw64-ci Docker image

@eht16 pushed 1 commit.

6a3b28232993cacca9fa411dcc4733501d14f039 CI: Add workflow to build geany-mingw64-ci Docker image

@kugel- commented on this pull request.

+#!/bin/bash

+# +# Copyright 2022 The Geany contributors +# License: GPLv2 +# +# Create a Debian repository for the Debian distribution +# requested in the environment variable ${DISTRO}. +# The repository will be signed with the GnuPG key as found +# in /gnupg (which must be provided from the caller). +# +# This script is meant to be run in a Docker container. +# + + +# codename -> suite mapping +declare -A SUITES=([buster]=stable [sid]=unstable)

buster -> bullseye

@eht16 commented on this pull request.

• python3-lxml python3-docutils

+ + +# copy pacman and scripts +COPY --from=build-pacman /windows /windows +COPY --from=build-pacman /usr/local/pacman /usr/local/pacman +COPY mingw64/bin/ /usr/local/bin/ +RUN ln -s /usr/local/pacman/bin/* /usr/local/bin/ && \ + mkdir /build + +WORKDIR /build +ENV LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pacman/lib/x86_64-linux-gnu + +# start wine to initially create config directory +RUN /usr/local/bin/mingw-w64-i686-wine hostname.exe && \ + /usr/local/bin/mingw-w64-x86_64-wine hostname.exe && \

Once for wine-i686 and once for wine-x86_64. Both commands are only executed to setup the Wind environment initially for both architectures. We need wine-x86_64 to run Geany itself and wine-i686 to execute the installer which can be built only for i686.

@eht16 commented on this pull request.

• COMPILER_VERSION=$(gcc -dumpfullversion)

+ + echo "Debian Distribution : $(grep PRETTY_NAME /etc/os-release | cut -d '=' -f 2)" + echo "Geany version : ${GEANY_VERSION}" + echo "Geany GIT revision : ${GEANY_GIT_REVISION}" + echo "GLib version : ${GLIB_VERSION}" + echo "GTK version : ${GTK_VERSION}" + echo "GCC version : ${COMPILER_VERSION}" + + cat <<EOT > ${OUTPUT_DIRECTORY}/geany/versions.json + { + "glib_version": "${GLIB_VERSION}", + "gtk_version": "${GTK_VERSION}", + "gcc_version": "${COMPILER_VERSION}", + } +EOT

Nothing yet but it might become useful when using the scripts for nightly builds to fill the table on https://www.geany.org/download/nightly-builds/.

But I'm quite undecided yet how to proceed with the nightly builds exactly and the whole Debian package builds scripts are yet to be finalized. For now, I would like to focus on the mingw64 parts to get them integrated into the pipeline.

@eht16 pushed 1 commit.

5fa145ae657a0e697ca1bab9e29ca82846d4c8aa Fix wrong tarball name and update codename for Debian stable

@eht16 commented on this pull request.

• PACKAGE_VERSION="${GEANY_VERSION}-1~$(date '+%Y%m%d')git${GEANY_GIT_REVISION}"

+} + + +run_autogen_sh() { + log "Run ./autogen.sh" + cd ${GEANY_BUILD_DIR} + # run ./autogen.sh as the Debian package won't run ./autogen.sh for us + NOCONFIGURE=1 ./autogen.sh +} + +create_tarball_for_debuild() { + log "Create source tarball" + cd ${GEANY_BUILD_DIR} + # create a source tarball, keep .git included on purpose for Geany GIT build detection + tar --transform "s,^,geany-plugins-${GEANY_VERSION}/,S" \

Fixed, thanks.

@kugel- requested changes on this pull request.

+RUN set -ex && \ + apt-get update && \ + apt-get install --no-install-recommends --assume-yes \ + build-essential meson wget xz-utils zstd gnupg2 file zstd ca-certificates \ + pkg-config m4 libarchive-dev libssl-dev libcurl4-gnutls-dev libgpgme-dev \ + python3-setuptools + +# compile Pacman +RUN set -ex && \ + wget --no-verbose https://sources.archlinux.org/other/pacman/pacman-$%7BPACMAN_VERSION%7D.tar.... && \ + echo "${PACMAN_SHA256} *pacman-${PACMAN_VERSION}.tar.xz" | sha256sum --check --strict - && \ + tar xf pacman-${PACMAN_VERSION}.tar.xz && \ + cd /pacman-${PACMAN_VERSION} && \ + meson \ + --prefix /usr/local/pacman \

I don't understand. If you prefer the app-exclusive prefix, then why do you copy it to /usr/local/bin, afterwards?

It appears that pacman is run from /usr/local/bin/pacman, afterwards, yet its prefix is /usr/local/pacman. This can cause trouble if the pacman binary encodes the prefix (remember that Geany isn't relocatable by default either).

Really, I would prefer to define one prefix and then also run the program from there. Anything else is asking for trouble and is just adding confusion (I am confused). Then you don't need `ln -s` and `LD_LIBRARY_PATH` workarounds that I find in this file.

• libcurl3-gnutls libgpgme11 libarchive13 libssl1.1 \

+ # common useful utilities \ + wget curl less nano git gnupg2 file ca-certificates dos2unix \ + zip unzip xz-utils zstd \ + # build tools \ + build-essential automake autoconf autopoint gettext libtool check cppcheck \ + # genay-plugins autogen.sh requirements + intltool libglib2.0-dev \ + # mingw-w64 \ + gcc-mingw-w64-x86-64 g++-mingw-w64-x86-64 mingw-w64-x86-64-dev mingw-w64-tools \ + # install wine to test installer and created binaries + wine wine32 wine64 \ + # install NSIS and exiftool to inspect binary metadata + nsis libimage-exiftool-perl osslsigncode \ + # Geany build dependencies \ + python3-lxml python3-docutils

Okay. I only looked at the geany build script and didn't see how it installs additional dependencies. This was my concern, that the infrastructure script must know about all dependencies. But that's not a problem then, great!

• COMPILER_VERSION=$(gcc -dumpfullversion)

+ + echo "Debian Distribution : $(grep PRETTY_NAME /etc/os-release | cut -d '=' -f 2)" + echo "Geany version : ${GEANY_VERSION}" + echo "Geany GIT revision : ${GEANY_GIT_REVISION}" + echo "GLib version : ${GLIB_VERSION}" + echo "GTK version : ${GTK_VERSION}" + echo "GCC version : ${COMPILER_VERSION}" + + cat <<EOT > ${OUTPUT_DIRECTORY}/geany/versions.json + { + "glib_version": "${GLIB_VERSION}", + "gtk_version": "${GTK_VERSION}", + "gcc_version": "${COMPILER_VERSION}", + } +EOT

I would add such artifacts only when they became needed with a clear use case.

• create_tarball_for_debuild

+ + git_clone_debian_geany + install_build_dependencies + add_changelog_entry + + build_package + copy_results + + log_and_store_build_environment + + log "Done." +} + + +main

Above you said you would like to focus on the mingw-parts. Might be a good idea to leave the Debian parts out of this PR for now, then, and deal with that in a separate, follow-up PR. Then we can discuss the proper place.

@eht16 commented on this pull request.

• create_tarball_for_debuild

+ + git_clone_debian_geany + install_build_dependencies + add_changelog_entry + + build_package + copy_results + + log_and_store_build_environment + + log "Done." +} + + +main

Ok, I removed the Debian parts for now.

@eht16 commented on this pull request.

+RUN set -ex && \ + apt-get update && \ + apt-get install --no-install-recommends --assume-yes \ + build-essential meson wget xz-utils zstd gnupg2 file zstd ca-certificates \ + pkg-config m4 libarchive-dev libssl-dev libcurl4-gnutls-dev libgpgme-dev \ + python3-setuptools + +# compile Pacman +RUN set -ex && \ + wget --no-verbose https://sources.archlinux.org/other/pacman/pacman-$%7BPACMAN_VERSION%7D.tar.... && \ + echo "${PACMAN_SHA256} *pacman-${PACMAN_VERSION}.tar.xz" | sha256sum --check --strict - && \ + tar xf pacman-${PACMAN_VERSION}.tar.xz && \ + cd /pacman-${PACMAN_VERSION} && \ + meson \ + --prefix /usr/local/pacman \

Whateveryou wish. Pacman is now installed into /usr/local but setting `LD_LIBRARY_PATH` is still necessary or alternatively running `ldconfig` to manually update the ldcache. This is because after installing Pacman with Meson, the ldcache is not updated automatically. So we still need to take care to update the ldcache.

@kugel- commented on this pull request.

+RUN set -ex && \ + apt-get update && \ + apt-get install --no-install-recommends --assume-yes \ + build-essential meson wget xz-utils zstd gnupg2 file zstd ca-certificates \ + pkg-config m4 libarchive-dev libssl-dev libcurl4-gnutls-dev libgpgme-dev \ + python3-setuptools + +# compile Pacman +RUN set -ex && \ + wget --no-verbose https://sources.archlinux.org/other/pacman/pacman-$%7BPACMAN_VERSION%7D.tar.... && \ + echo "${PACMAN_SHA256} *pacman-${PACMAN_VERSION}.tar.xz" | sha256sum --check --strict - && \ + tar xf pacman-${PACMAN_VERSION}.tar.xz && \ + cd /pacman-${PACMAN_VERSION} && \ + meson \ + --prefix /usr/local/pacman \

Can you run ldconfig in the container?

@kugel- commented on this pull request.

+RUN set -ex && \ + apt-get update && \ + apt-get install --no-install-recommends --assume-yes \ + build-essential meson wget xz-utils zstd gnupg2 file zstd ca-certificates \ + pkg-config m4 libarchive-dev libssl-dev libcurl4-gnutls-dev libgpgme-dev \ + python3-setuptools + +# compile Pacman +RUN set -ex && \ + wget --no-verbose https://sources.archlinux.org/other/pacman/pacman-$%7BPACMAN_VERSION%7D.tar.... && \ + echo "${PACMAN_SHA256} *pacman-${PACMAN_VERSION}.tar.xz" | sha256sum --check --strict - && \ + tar xf pacman-${PACMAN_VERSION}.tar.xz && \ + cd /pacman-${PACMAN_VERSION} && \ + meson \ + --prefix /usr/local/pacman \

My feeling: better update the cache properly than messing with LD_LIBRARY_PATH but I don't feel strong either.

@eht16 commented on this pull request.

+RUN set -ex && \ + apt-get update && \ + apt-get install --no-install-recommends --assume-yes \ + build-essential meson wget xz-utils zstd gnupg2 file zstd ca-certificates \ + pkg-config m4 libarchive-dev libssl-dev libcurl4-gnutls-dev libgpgme-dev \ + python3-setuptools + +# compile Pacman +RUN set -ex && \ + wget --no-verbose https://sources.archlinux.org/other/pacman/pacman-$%7BPACMAN_VERSION%7D.tar.... && \ + echo "${PACMAN_SHA256} *pacman-${PACMAN_VERSION}.tar.xz" | sha256sum --check --strict - && \ + tar xf pacman-${PACMAN_VERSION}.tar.xz && \ + cd /pacman-${PACMAN_VERSION} && \ + meson \ + --prefix /usr/local/pacman \

Ok, done.

@kugel- are you fine when I squash the commits together or do you still need the history?

Go for it? Or is anything missing?

Merged #7 into master.