Bump libcap epoch

[jonjohnsonjr]

This hasn't been rebuilt in a while but the provides are broken.

[sdk] ❯ apk add libcap
WARNING: opening ./../../packages: No such file or directory
ERROR: unable to select packages:
  libcap-2.68-r0:
    conflicts: libcap-2.69-r0
    satisfies: world[libcap] libcap-2.69-r0[so:libcap.so.2] libcap-2.69-r0[so:libpsx.so.2]
  libcap-2.69-r0:
    conflicts: libcap-2.68-r0
    satisfies: world[libcap]

[russellhaering]

@jonjohnsonjr I don't know enough about apk to know whether this change is causing the issue I'm seeing, or will fix it after some kind of propagation, but starting sometime within the last 8 hours or so building the following dockerfile began to fail with the same error you posted:

FROM cgr.dev/chainguard/wolfi-base:latest

RUN apk update && apk add libcap

[joshrwolf]

temporarily reverting this as it caused so conflicts: #11099

[joshrwolf]

@russellhaering with the updated package temporarily withdraw, please let me know if the issue you're seeing persists.

we'll get libcap updated once we get to the bottom of why this broke

[russellhaering]

I'm still seeing the same issue, but as a workaround apk update && apk add libcap~2.68 seems to work.

I tried to debug a little bit, if it helps it appears to me that the withdraw didn't work, or maybe hasn't been fully published yet.

Specifically, if you run this (or pull and inspect the index without the horrible bash one-liner):

$ curl https://packages.wolfi.dev/os/aarch64/APKINDEX.tar.gz | tar -xO | grep -A 12 -B 12 -m 1 -a 2\.69-r1

You'll see:

C:Q1o/fOFiktsTit/6L/bBg4+DZBEXs=
P:libcap
V:2.69-r1
A:aarch64
S:33469
I:176528
T:POSIX 1003.1e capabilities
L:BSD-3-Clause OR GPL-2.0-only
o:libcap
t:1705063674
c:f22a2e2e2eb465788c6d9a617eafa25eeadd4afb
D:so:ld-linux-aarch64.so.1 so:libc.so.6 so:libpsx.so.2
p:so:libcap.so.2=2

Which implies to me that libcap-2.69-r1 is still in the index for some reason.

I do see this workflow run which at a glance looks like it should have removed it from the index though.

The workaround above is good enough for me, but also happy to help debug however I can.

[lpcalisi]

libcap build is making a circular dependency.

libcap-2.68-r0 provides:
so:libcap.so.2=2
so:libpsx.so.2=2

but 2.69-r0

libcap-2.69-r0 depends on:
so:ld-linux-aarch64.so.1
so:libc.so.6
so:libcap.so.2
so:libpsx.so.2

libcap-2.69-r0 provides:

and after 2.69-r1 build, depends on libpsx.so.2 yet

libcap-2.69-r1 depends on:
so:ld-linux-aarch64.so.1
so:libc.so.6
so:libpsx.so.2

libcap-2.69-r1 provides:
so:libcap.so.2=2

[lpcalisi]

I'm not sure why, but i believe i found it's happens.

In build logs libcap.so.2.69 and libpsx.so.2.69 have an program interpreter, it makes that no enter in this melange block and not generate provides information right. Besides, I think that we maybe make some confusion with libcap in libc condition

if !hdl.Options().NoProvides && (interp == "" || strings.HasPrefix(basename, "libc")) {

More context

Last libcap package apparently builded right was 2.68-r0 a few days before this commit

Maybe @kaniini could help us with this

[ajayk]

The issue is tracked here on melange chainguard-dev/melange#920