[packaging] Alpine #1439

woju · 2023-07-04T14:49:10Z

Taken over #1421, with fixes and CI.

How to test

CI (esp. pkg-apk-alpine3.17)

How to test yourself

Quick and dirty, but always works. Leaves root-owned files in you repo (you can clean with sudo git clean -dxf afterwards). Proper testing would require proper alpine packaging setup (read more here: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package), which is not in scope here.

docker run -it --rm alpine:latest --volume $PWD:/gramine
cd /gramine/packaging/alpine
apk add alpine-sdk jq meson nasm
abuild-keygen -an
abuild -F -r snapshot checksum all

This change is

woju · 2023-07-04T14:52:35Z

Jenkins, test pkg-apk-alpine3.17 please

dimakuv

Reviewed 2 of 4 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: all files reviewed, all discussions resolved, not enough approvals from maintainers (1 more required)

kailun-qin

Reviewed 2 of 4 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

mkow

Reviewed 2 of 4 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

amicrity

I hope the .apk has been properly tested before, since this thing going through seems like a miracle

Reviewable status: all files reviewed, 9 unresolved discussions (waiting on @woju)

.ci/alpine3.17.dockerfile line 3 at r2 (raw file):

FROM alpine:3.17

RUN apk add \

FYI, please remember to mention that those packages should be installed prior to building on non-docker platforms (otherwise abuild will crash leaving lots of mess)

packaging/alpine/.gitignore line 1 at r2 (raw file):

/src/

what is the .gitignore file doing here? and if it really has to, build-dist should be included too

packaging/alpine/APKBUILD line 4 at r2 (raw file):

# Maintainer: Amie Raine <[email protected]>
pkgname=gramine
_real_pkgver=1.4post~UNRELEASED

this exact same apkbuild won't ever make its way to aports

packaging/alpine/APKBUILD line 8 at r2 (raw file):

    -e 's:post~UNRELEASED:.u0n0r0e0l0e0a0s0e0d_git0:' \
    -e 's:~:_:' \
)

what on earth is this, call it 0-pre or something like that, you can do more than one letter at once ;p

also about the sed, you can literally substitute it with ${_real_pkgver/~UNRELEASED/} instead of making an unreadable mess

i know, we cannot use a tilde, a commit hash and "something something alpine community bad", but we have way more options of doing it properly
"properly", as in with good practices
please refrain from perceiving the sexual orientation and/or gender identity of Alpine's core devs as more important (enough to not care about any good practices) than the fact they're more or less right on how the packaging should be done (friendly reminder, abuild is very not equal to meson)

Code quote:

_real_pkgver=1.4post~UNRELEASED
pkgver=$(printf %s "$_real_pkgver" | sed \
    -e 's:post~UNRELEASED:.u0n0r0e0l0e0a0s0e0d_git0:' \
    -e 's:~:_:' \
)

packaging/alpine/APKBUILD line 44 at r2 (raw file):

	py3-tomli-w
	"
source="$pkgname-$pkgver.tar.gz"

uhhhhh? this won't work outside of a CI, because this file won't exist; we should change that so it'll work both on CIs and using abuild on a clean system, I've proposed some changes which you didn't read mostly because you didn't like the "version" part

packaging/alpine/APKBUILD line 58 at r2 (raw file):

    # sanity check for version number
    test "$(meson introspect build/ --projectinfo | jq -r '.version')" = "$_real_pkgver" \

please refrain from using test, we don't do that for at least 10 years, it's a better practice to do if <command>; then

packaging/alpine/APKBUILD line 59 at r2 (raw file):

    # sanity check for version number
    test "$(meson introspect build/ --projectinfo | jq -r '.version')" = "$_real_pkgver" \
        || die '$_real_pkgver does not match what is in meson.build'

holy

packaging/alpine/APKBUILD line 80 at r2 (raw file):

snapshot() {
    meson setup -Dskeleton=enabled -Dlibc=musl build-dist/ ../..

please don't use meson directly, we have script/makedist.sh

why are we copying the .tar.gz into the unknown anyways?

packaging/alpine/APKBUILD line 82 at r2 (raw file):

    meson setup -Dskeleton=enabled -Dlibc=musl build-dist/ ../..
    meson dist -C build-dist/ --no-test --include-subprojects --format=gztar
    install -D build-dist/meson-dist/"$pkgname-$_real_pkgver".tar.gz "$pkgname-$pkgver.tar.gz"

it doesn't make any sense to use install, just do mv

amicrity

Reviewed 2 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 9 unresolved discussions (waiting on @woju)

nekopsykose · 2023-07-05T12:59:56Z

please refrain from perceiving the sexual orientation and/or gender identity of Alpine's core devs as more important (enough to not care about any good practices) than the fact they're more or less right on how the packaging should be done

lmao

woju

Reviewable status: all files reviewed, 9 unresolved discussions (waiting on @amicrity)

.ci/alpine3.17.dockerfile line 3 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

please remember to mention that those packages should be installed prior to building on non-docker platforms (otherwise abuild will crash leaving lots of mess)

Where exactly should I mention this? It's already mentioned in https://github.com/gramineproject/gramine/blob/7c9f0dbd19384cc13cade296a4fa2906eaae9793/Documentation/devel/building.rst#install-dependencies, though that is Debian/Ubuntu specific, but relatable to other distros. Or is there any other place this should be added?

packaging/alpine/.gitignore line 1 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

what is the .gitignore file doing here? and if it really has to, build-dist should be included too

Done (added build-dist/), thanks for pointing this out.

This .gitignore is making sure that no-one commits any temporary files, like the content of $srcdir or $pkgdir (which is those two).

packaging/alpine/APKBUILD line 4 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

this exact same apkbuild won't ever make its way to aports

Yes, it won't. It will require rework before someone submits it to aports. However, you're certainly aware that this APKBUILD's primary reason is to test alpine builds in our CI, not as preparation for submission to aports.

packaging/alpine/APKBUILD line 8 at r2 (raw file):

also about the sed, you can literally substitute it with ${_real_pkgver/~UNRELEASED/} instead of making an unreadable mess

This unreadable mess is a direct consequence of apk requiring a digit after a letter. I want to include the string "UNRELEASED" for when people will file issues. I don't want a situation where people report problems with package versioned like something released, in such cases it's hard to guess that this package was self-built from random commit after this release. "UNRELEASED" in version makes this unambiguous.

I can't make it ${\_real\_pkgver/~UNRELEASED/}, because it would contain post and therefore would be rejected by apk version --check.

please refrain from perceiving the sexual orientation and/or gender identity of Alpine's core devs

Whaaat? I don't think this has any bearing on technical issues, so I don't understand why are you bringing this subject up, it's offtopic here.

they're more or less right on how the packaging should be done (friendly reminder, abuild is very not equal to meson)

I'm aware of differences between abuild and meson, thank you. I agree with some technical choices by Alpine devs and disagree with others, it's a simple as that. This version thingy is a consequence of limitations in support of perfectly valid version string imposed by them. Best I can do is to add a comment explaining the situation, with a link to this snippet: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/23be7e321009b5c524ebb06746219760d9b40b6a/src/version.c#L37-38

packaging/alpine/APKBUILD line 44 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

uhhhhh? this won't work outside of a CI, because this file won't exist; we should change that so it'll work both on CIs and using abuild on a clean system, I've proposed some changes which you didn't read mostly because you didn't like the "version" part

This will work perfectly fine with "released" tarballs (will be called gramine-1.5.tar.gz). And yes, the main concern here is that this should work 1) in CI, 2) for manual builds of packages released directly by us, not via aports.

I understand this is not how Alpine operates their APKBUILDs, but they keep APKBUILDs separate from source code build. What I'm attempting to do here is similar to debian native packages. I haven't found a good explanation on https://wiki.alpinelinux.org/ how to do it best, the closest thing is https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Git_checkout, and that example is incomplete at best. I acknowledge that this might be because this is very uncommon thing to do (if ever done).

packaging/alpine/APKBUILD line 58 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

please refrain from using test, we don't do that for at least 10 years, it's a better practice to do if <command>; then

This project is only about 5 years old, so I don't understand how do "we don't do that for at least 10 years", and we're certainly doing that (

gramine/debian/get-linux-src-path.sh

Lines 7 to 12 in 7c9f0db

    
               test -n "$version" || continue 
        
               dpkg --compare-versions "$version" '>=' '5.11' || continue 
        
               # sanity check: if directory does not exist, break here and not in meson 
        
               dir=/usr/src/"$name" 
        
               test -d "$dir" || exit 2

). The logic here is correct, I don't understand what's wrong with it.

packaging/alpine/APKBUILD line 59 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

holy

What's the concern here, exactly?

packaging/alpine/APKBUILD line 80 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

please don't use meson directly, we have script/makedist.sh

why are we copying the .tar.gz into the unknown anyways?

script/makedist.sh has -Dlibc=glibc hardcoded in meson setup, I would have to adjust that (otherwise there would be no musl in tarball), and creates two exactly same tarballs (differing only in name) which is useless here. It's easier to simply run meson dist directly here.

We're copying tarball into the current directory ($startdir to be precise). If I'm not mistaken, we will always have is_remote false (https://gitlab.alpinelinux.org/alpine/abuild/-/blob/d4b2415fb1d52208c2dcdfb4ec547b09a671eca2/abuild.in#L419), because having anything downloaded from e.g. github is not acceptable (you shouldn't be required to push to official repository before building from local branch), therefore we need tarball in $startdir because of https://gitlab.alpinelinux.org/alpine/abuild/-/blob/d4b2415fb1d52208c2dcdfb4ec547b09a671eca2/abuild.in#L458.

packaging/alpine/APKBUILD line 82 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

it doesn't make any sense to use install, just do mv

install is equally correct, and install -D is for when this might be adapted to use SRCDEST somehow, which I'm still unsure about. In any case, the tarball needs to end up in pwd/$startdir (cf. above thread).

dimakuv

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 9 unresolved discussions, not enough approvals from maintainers (1 more required) (waiting on @amicrity)

amicrity

Reviewed 1 of 1 files at r3.
Reviewable status: all files reviewed, 8 unresolved discussions, not enough approvals from maintainers (1 more required) (waiting on @woju)

.ci/alpine3.17.dockerfile line 3 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

Where exactly should I mention this? It's already mentioned in https://github.com/gramineproject/gramine/blob/7c9f0dbd19384cc13cade296a4fa2906eaae9793/Documentation/devel/building.rst#install-dependencies, though that is Debian/Ubuntu specific, but relatable to other distros. Or is there any other place this should be added?

it's okay as long as this PR's description will be added somewhere, if not, it's really worth mentioning (for example on the mentioned website) that alpine-sdk jq meson nasm are essential for the build process (if someone sets up abuild only, and doesn't install the dependencies and runs the build, it might break itself beyond repair)

packaging/alpine/.gitignore line 1 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

Done (added build-dist/), thanks for pointing this out.

This .gitignore is making sure that no-one commits any temporary files, like the content of $srcdir or $pkgdir (which is those two).

lgtm

packaging/alpine/APKBUILD line 4 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

Yes, it won't. It will require rework before someone submits it to aports. However, you're certainly aware that this APKBUILD's primary reason is to test alpine builds in our CI, not as preparation for submission to aports.

APKBUILDs aren't meant for CI (and that's also why they hurt so much when put in a CI), just copy the commands from prepare() and build() and here'll be your CI

and please stop assuming that my goal here is to upstream this exact APKBUILD to aports, I want it to meet at least some Alpine's standards (since we will probably support Alpine for a longer time; doing so will make maintaining it way easier) instead of using deprecated (or never actually supported) configurations

packaging/alpine/APKBUILD line 8 at r2 (raw file):
nope, you just (for some reason) don't want to use semantic versioning
there are two solutions for that:

instead of UNRELEASED, do 1.4_gitX (with the X being the build number; we should go with the date but I know you really don't want to do it)
https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgver; 1.4_pre420 - good, 1.4_pre - good, 1.4_.u0n0r0e0l0e0a0s0e0d_git0 - very bad
overriding the sanitycheck() in abuild

from the link above: "To package a specific git commit, the date of the commit gets appended to the latest release, e.g. 1.0.0_git20180204." It is a proper way of doing this, but if you really don't like it, we have other options available

Whaaat? I don't think this has any bearing on technical issues, so I don't understand why are you bringing this subject up, it's offtopic here.

from what i recall that was your only explanation for making a huge mess (not going into details) and thinking that after what you will do with this APKBUILD, AL community will "fix" the issues you're trying to "circumvent"
however i don't think breaking the core principles of abuild will attract enough attention of just a few people who maintain Alpine and have better things to do (as seen above ;p)

packaging/alpine/APKBUILD line 44 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

This will work perfectly fine with "released" tarballs (will be called gramine-1.5.tar.gz). And yes, the main concern here is that this should work 1) in CI, 2) for manual builds of packages released directly by us, not via aports.

I understand this is not how Alpine operates their APKBUILDs, but they keep APKBUILDs separate from source code build. What I'm attempting to do here is similar to debian native packages. I haven't found a good explanation on https://wiki.alpinelinux.org/ how to do it best, the closest thing is https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Git_checkout, and that example is incomplete at best. I acknowledge that this might be because this is very uncommon thing to do (if ever done).

you know what also works perfectly fine with "released" tarballs? omitting the snapshot entirely

you didn't understand the example, so it makes sense why it looks "incomplete at best"

packaging/alpine/APKBUILD line 58 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

This project is only about 5 years old, so I don't understand how do "we don't do that for at least 10 years", and we're certainly doing that (

gramine/debian/get-linux-src-path.sh

Lines 7 to 12 in 7c9f0db

test -n "$version" || continue

dpkg --compare-versions "$version" '>=' '5.11' || continue

# sanity check: if directory does not exist, break here and not in meson

dir=/usr/src/"$name"

test -d "$dir" || exit 2

). The logic here is correct, I don't understand what's wrong with it.

the fact that we (as in, Invisible Things Lab) do it doesn't mean that everyone else does it too
test in bash/sh is the equivalent of [[
it's a good practice to do if [[ -d ... ]]; then, alternatively [[ ! -d ... ]] && exit 1

packaging/alpine/APKBUILD line 59 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

What's the concern here, exactly?

there's no valid reason (at least to me) to perform that check

packaging/alpine/APKBUILD line 82 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

install is equally correct, and install -D is for when this might be adapted to use SRCDEST somehow, which I'm still unsure about. In any case, the tarball needs to end up in pwd/$startdir (cf. above thread).

yeah, right, https://www.man7.org/linux/man-pages/man1/install.1.html doesn't mention that you can't do that, but usually it's used for installing precompiled pkgs to /usr, while you use it with just the intention of copying a tarball; why?

woju

Reviewable status: all files reviewed, 8 unresolved discussions, not enough approvals from maintainers (1 more required) (waiting on @amicrity)

.ci/alpine3.17.dockerfile line 3 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

it's okay as long as this PR's description will be added somewhere, if not, it's really worth mentioning (for example on the mentioned website) that alpine-sdk jq meson nasm are essential for the build process (if someone sets up abuild only, and doesn't install the dependencies and runs the build, it might break itself beyond repair)

I'll leave this out of scope for now. Maybe in later PR, for now we're running out of time.

packaging/alpine/APKBUILD line 4 at r2 (raw file):

APKBUILDs aren't meant for CI

Packaging is not only prepare() and build(), it's also dependencies, that might be or might not be present on all distros/versions. I don't want to copy instructions, copying is prone to missing something. The only sure way is to test end-to-end, and exactly the thing that will be used to package for release (and this APKBUILD is exactly it).

Yes, Alpine will be supported as long as practicable, and this APKBUILD will be living in our repo. As you can see there are several features that make it easier to maintain in our repo, like _real_pkgver that is meant to exactly reflect what is in meson.build and this version check. Optimally, abuild should support something like Debian "native packages", where debian/ directory is meant to live together with the code packaged, in the same repo. Until and unless that happens, we are doing what we can to emulate that.

packaging/alpine/APKBUILD line 8 at r2 (raw file):
Yes, and I have explained the reason why we're not doing "semantic versioning" as defined by javascript developers. This UNRELEASED string is based on experiences with past bug reports. I still haven't heard a credible explanation why you can't write consecutive letters in pkgver= (unless it's part of specific suffix) other than "just do $something_else", that something else being usually "semantic versioning", which I find lacking in necessary features. From the suggested solutions none are acceptable to us. date is non-starter, because if you checkout this same commit twice, on two different days, you should get exactly the same packages, bit for bit identical. For plain $(date) you won't get this. You can try getting timestamp from git commit, but then this gets problematic in other ways.

from what i recall

You recall wrong, also not going into details, so EOT.

packaging/alpine/APKBUILD line 44 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

you know what also works perfectly fine with "released" tarballs? omitting the snapshot entirely

you didn't understand the example, so it makes sense why it looks "incomplete at best"

I'd be grateful if you pointed me to documentation of correct solution to the problem stated above (i.e. CI). Otherwise this discussion is not productive.

packaging/alpine/APKBUILD line 58 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

the fact that we (as in, Invisible Things Lab) do it doesn't mean that everyone else does it too
test in bash/sh is the equivalent of [[
it's a good practice to do if [[ -d ... ]]; then, alternatively [[ ! -d ... ]] && exit 1

In fact, test is not equivalent to [[. [[ is bash-only syntax (not in POSIX, therefore not a good practice)andtestis a command.testis equivalent to[`, apart from closing bracket.

[ <something> ] && ... is very wrong when coupled with set -e. Only [ ] || (or test ||) is OK in the face of set -e.

packaging/alpine/APKBUILD line 59 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

there's no valid reason (at least to me) to perform that check

Yes, in theory, theory matches practice. In practice, it's different. This sanity check is meant for when I would bump meson.build but forgot to change _real_pkgver here. Those changes are done manually, so we need to ensure they're synchronised. We do this check also for all other packaging:

gramine/debian/rules

Lines 44 to 49 in 7c9f0db

    
           # assert correct version 
        
           if ! dpkg --compare-versions "$$(meson introspect --projectinfo obj-$(DEB_HOST_MULTIARCH) | jq -r .version)" = "$(DEB_VERSION)"; \ 
        
           then \ 
        
           	echo mismatched version: make sure that version in debian/changelog matches meson.build >&2; \ 
        
           	exit 1; \ 
        
           fi

gramine/gramine.spec

Lines 63 to 68 in 7c9f0db

    
           # assert correct version 
        
           if ! test "$(meson introspect --projectinfo "%{_vpath_builddir}" | jq -r .version)" = %{version} 
        
           then 
        
               echo mismatched version: make sure that version in gramine.spec matches meson.build >&2 
        
               exit 1 
        
           fi

I see no reason why we wouldn't need to perform that check, but only on Alpine.

packaging/alpine/APKBUILD line 82 at r2 (raw file):

Previously, amicrity (Amie Raine) wrote…

yeah, right, https://www.man7.org/linux/man-pages/man1/install.1.html doesn't mention that you can't do that, but usually it's used for installing precompiled pkgs to /usr, while you use it with just the intention of copying a tarball; why?

install doesn't care about what it's copying, and has some useful options that without it would require additional mkdir, chmod and/or chown. It's just very convenient. I don't care about what it's "usually" used for.

Co-authored-by: Amie Raine <[email protected]> Signed-off-by: Amie Raine <[email protected]> Signed-off-by: Wojtek Porczyk <[email protected]>

Signed-off-by: Wojtek Porczyk <[email protected]>

woju

Reviewable status: 3 of 4 files reviewed, 8 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL) (waiting on @amicrity, @dimakuv, @kailun-qin, and @mkow)

packaging/alpine/APKBUILD line 8 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

Yes, and I have explained the reason why we're not doing "semantic versioning" as defined by javascript developers. This UNRELEASED string is based on experiences with past bug reports. I still haven't heard a credible explanation why you can't write consecutive letters in pkgver= (unless it's part of specific suffix) other than "just do $something_else", that something else being usually "semantic versioning", which I find lacking in necessary features. From the suggested solutions none are acceptable to us. date is non-starter, because if you checkout this same commit twice, on two different days, you should get exactly the same packages, bit for bit identical. For plain $(date) you won't get this. You can try getting timestamp from git commit, but then this gets problematic in other ways.

from what i recall

You recall wrong, also not going into details, so EOT.

I've changed this so it outputs the commit ID of the build (in decimal...). There aren't really many other options. We can't use "build ID", because there's no such thing outside CI.

dimakuv

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: all files reviewed, 8 unresolved discussions, not enough approvals from maintainers (1 more required) (waiting on @amicrity)

mkow

Reviewed 1 of 1 files at r3, 1 of 1 files at r4, all commit messages.
Reviewable status: all files reviewed, 8 unresolved discussions (waiting on @amicrity)

mkow

Dismissed @amicrity from 8 discussions.
Reviewable status: all files reviewed, 8 unresolved discussions

a discussion (no related file):
FYI: We (me, Amie and woju) reached an agreement on priv that (if I understand correctly) we'll merge the current state of the PR, make the release and then work on making these scripts more suitable with Alpine standards.
@amicrity: I'll dismiss you from the discussions, I hope you don't mind - it seems that you forgot to unblock and went AFK, and we need to finish this PR as soon as possible (and to my understanding you were fine with the current status of the PR as long as we'll work on fixing these issues after the release).

mkow

Reviewable status: complete! all files reviewed, all discussions resolved

nekopsykose · 2023-07-08T00:04:11Z

then work on making these scripts more suitable with Alpine standards.

there's no need to, as i have no interest in accepting this software into aports itself. you should keep your downstream builds however you want to make them, and it's better for you that way too.

woju force-pushed the woju/alpine-linux-support branch 12 times, most recently from d64340b to 6bd88ec Compare July 4, 2023 17:02

woju changed the title ~~WIP Woju's Alpine linux support~~ [packaging] Alpine Jul 4, 2023

woju marked this pull request as ready for review July 4, 2023 17:03

woju force-pushed the woju/alpine-linux-support branch from 6bd88ec to 2df3dc0 Compare July 4, 2023 17:17

woju mentioned this pull request Jul 4, 2023

[packaging] add Alpine Linux build scripts #1421

Closed

dimakuv previously approved these changes Jul 5, 2023

View reviewed changes

kailun-qin previously approved these changes Jul 5, 2023

View reviewed changes

mkow previously approved these changes Jul 5, 2023

View reviewed changes

amicrity reviewed Jul 5, 2023

View reviewed changes

woju dismissed stale reviews from mkow, kailun-qin, and dimakuv via 0b8caf7 July 5, 2023 14:11

woju force-pushed the woju/alpine-linux-support branch from 2df3dc0 to 0b8caf7 Compare July 5, 2023 14:11

woju commented Jul 5, 2023

View reviewed changes

dimakuv previously approved these changes Jul 5, 2023

View reviewed changes

amicrity reviewed Jul 5, 2023

View reviewed changes

woju commented Jul 5, 2023

View reviewed changes

woju and others added 2 commits July 6, 2023 13:16

[packaging] Add APKBUILD for Alpine

b66a0b2

Co-authored-by: Amie Raine <[email protected]> Signed-off-by: Amie Raine <[email protected]> Signed-off-by: Wojtek Porczyk <[email protected]>

[CI] Build for Alpine 3.17

ab2d321

Signed-off-by: Wojtek Porczyk <[email protected]>

woju dismissed dimakuv’s stale review via ab2d321 July 6, 2023 11:27

woju force-pushed the woju/alpine-linux-support branch from 0b8caf7 to ab2d321 Compare July 6, 2023 11:27

woju commented Jul 6, 2023

View reviewed changes

dimakuv approved these changes Jul 7, 2023

View reviewed changes

mkow approved these changes Jul 7, 2023

View reviewed changes

mkow merged commit ab2d321 into master Jul 7, 2023

mkow deleted the woju/alpine-linux-support branch July 7, 2023 10:07

dimakuv mentioned this pull request Jul 11, 2023

Alpine Linux support #993

Closed

anirudhgargi mentioned this pull request Sep 11, 2023

Alpine Linux support gramineproject/gsc#105

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[packaging] Alpine #1439

[packaging] Alpine #1439

woju commented Jul 4, 2023 •

edited

Loading

woju commented Jul 4, 2023

dimakuv left a comment

kailun-qin left a comment

mkow left a comment

amicrity left a comment •

edited

Loading

amicrity left a comment

nekopsykose commented Jul 5, 2023

woju left a comment

dimakuv left a comment

amicrity left a comment •

edited

Loading

woju left a comment

woju left a comment

dimakuv left a comment

mkow left a comment

mkow left a comment

mkow left a comment

nekopsykose commented Jul 8, 2023

	test -n "$version" \|\| continue
	dpkg --compare-versions "$version" '>=' '5.11' \|\| continue

	# sanity check: if directory does not exist, break here and not in meson
	dir=/usr/src/"$name"
	test -d "$dir" \|\| exit 2

	# assert correct version
	if ! dpkg --compare-versions "$$(meson introspect --projectinfo obj-$(DEB_HOST_MULTIARCH) \| jq -r .version)" = "$(DEB_VERSION)"; \
	then \
	echo mismatched version: make sure that version in debian/changelog matches meson.build >&2; \
	exit 1; \
	fi

	# assert correct version
	if ! test "$(meson introspect --projectinfo "%{_vpath_builddir}" \| jq -r .version)" = %{version}
	then
	echo mismatched version: make sure that version in gramine.spec matches meson.build >&2
	exit 1
	fi

[packaging] Alpine #1439

[packaging] Alpine #1439

Conversation

woju commented Jul 4, 2023 • edited Loading

How to test

How to test yourself

woju commented Jul 4, 2023

dimakuv left a comment

Choose a reason for hiding this comment

kailun-qin left a comment

Choose a reason for hiding this comment

mkow left a comment

Choose a reason for hiding this comment

amicrity left a comment • edited Loading

Choose a reason for hiding this comment

amicrity left a comment

Choose a reason for hiding this comment

nekopsykose commented Jul 5, 2023

woju left a comment

Choose a reason for hiding this comment

dimakuv left a comment

Choose a reason for hiding this comment

amicrity left a comment • edited Loading

Choose a reason for hiding this comment

woju left a comment

Choose a reason for hiding this comment

woju left a comment

Choose a reason for hiding this comment

dimakuv left a comment

Choose a reason for hiding this comment

mkow left a comment

Choose a reason for hiding this comment

mkow left a comment

Choose a reason for hiding this comment

mkow left a comment

Choose a reason for hiding this comment

nekopsykose commented Jul 8, 2023

woju commented Jul 4, 2023 •

edited

Loading

amicrity left a comment •

edited

Loading

amicrity left a comment •

edited

Loading