On 3/1/23 18:43, Laszlo Ersek wrote:
On 3/1/23 17:54, Eric Blake wrote:
> I took the easy route of crippling what I couldn't get working, on the
> grounds that partial coverage is better than none now that we have
> Cirrus CI checking commits on additional platforms.
>
> This series got me to a green checkmark:
>
https://gitlab.com/ebblake/nbdkit/-/pipelines/793156983
>
> but depends on an as-yet uncommitted patch in libvirt-ci:
>
https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/360
>
> Eric Blake (5):
> ci: Expose more env vars needed by build.sh
> ci: Another attempt at MacOS
> rust: Skip CI builds on MacOS
> golang: Skip CI builds on MacOS and newer FreeBSD
> perl: Skip CI builds on newer FreeBSD
>
> .gitlab-ci.yml | 3 +++
> ci/cirrus/build.yml | 3 +++
> ci/cirrus/macos-12.vars | 4 ++--
> ci/gitlab.yml | 7 +++++++
> ci/gitlab/build-templates.yml | 31 ++++++++++++++++++++++++++++++-
> ci/gitlab/builds.yml | 11 ++++++++---
> ci/manifest.yml | 20 +++++++++++++++-----
> 7 files changed, 68 insertions(+), 11 deletions(-)
>
series
Acked-by: Laszlo Ersek <lersek(a)redhat.com>
One question (for my understanding) about the context of patch#1:
-e "s|[@]PYPI_PKGS@|$PYPI_PKGS|g"
what's this [@] notation? Why do we need to sink the at-sign into a
bracket expression?
Ugh, is it possible that the replacement covers the file *itself* that
contains these sed scripts? IOW, that we don't use plain "@FOOBAR@" nor
"\\@FOOBAR@" because sed would then modify the command file itself?
(This seems extreme, admittedly, but I've got no other idea. Another
hack for the same purpose could have been @{1}FOOBAR@, as an extended
regex.)
Laszlo