apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2022-12-21T18:49:35Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7103Add ability for apk to extract files, extended headers, and metadata directly...2022-12-21T18:49:35ZChris GiorgiAdd ability for apk to extract files, extended headers, and metadata directly from .apksCurrently, apk offers no direct way to extract specific contents or
metadata from .apks files and the pax headers utilized in the .apk
archive format are not easily read with any available tool.
Many scripts need to extract a subset of ...Currently, apk offers no direct way to extract specific contents or
metadata from .apks files and the pax headers utilized in the .apk
archive format are not easily read with any available tool.
Many scripts need to extract a subset of files from a .apk, and the
current method requires either downloading to a temp directory or using
apk fetch to stdout pipe repeatedly (which is very wasteful for multiple
invocations), verifying with ‘apk verify’, listing with ‘tar -tvf’ piped
to sed (using a subshell to generate the expressions) looking for the
desired files, capturing which of the desired files are found in the
.apk, and finally extracting the found files using ‘tar -xvf’.
Additionally, none of the available tools can read the pax headers in a
usable form, reducing one to parsing the raw tar stream with awk to
extract the desired headers and metadata, such as checksums.
apk should expose functionality allowing extracting or retrieving all
information from each entry as well as accessing archive-level
meta-data, and should support basic fnmatch style globbing of entries to
be extracted.
*(from redmine: issue id 7103, created on 2017-04-08)*v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7102Information available via 'apk info' on a package is incomplete with respect ...2022-12-21T20:00:36ZChris GiorgiInformation available via 'apk info' on a package is incomplete with respect to contents of .PKGINFO.Currently ‘apk info’ can not retrieve all information of interest on a
package, especially once Issue \#7101 is implemented.
‘apk info’ (or perhaps a more direct ‘apk query’) should be able to
extract any information stored in a .apk f...Currently ‘apk info’ can not retrieve all information of interest on a
package, especially once Issue \#7101 is implemented.
‘apk info’ (or perhaps a more direct ‘apk query’) should be able to
extract any information stored in a .apk file in raw or slightly cooked
form suitable for use in scripts.
*(from redmine: issue id 7102, created on 2017-04-07)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7101Allow apk to operate on .apk FILE most places PACKAGE is specified2022-12-21T20:00:36ZChris GiorgiAllow apk to operate on .apk FILE most places PACKAGE is specifiedCurrently, apk only allows package names where PACKAGE is accepted by
the various tools (see Issue 7100 for request for full atoms).
In most cases, it would also make sense to operate on a .apk FILE in the
same manner.
For instance,
...Currently, apk only allows package names where PACKAGE is accepted by
the various tools (see Issue 7100 for request for full atoms).
In most cases, it would also make sense to operate on a .apk FILE in the
same manner.
For instance,
apk info -L /tmp/linux-grsec-4.9.20-r0.apk
-or-
apk fix -i ./my-wip-package-0.11-r0.apk
*(from redmine: issue id 7101, created on 2017-04-07)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7100apk should support the use of full '$pkgname-$pkgver' atom as returned by 'ap...2024-03-22T11:45:14ZChris Giorgiapk should support the use of full '$pkgname-$pkgver' atom as returned by 'apk search -x $pkgname' everywhere '$pkgname' is usedCurrently, apk does not consider a full package atom, including version
($pkgname-$pkgver) to match a package which matches that exact atom.
For instance:
# apk search -x linux-grsec
linux-grsec-4.9.20-r0
# apk search -x $...Currently, apk does not consider a full package atom, including version
($pkgname-$pkgver) to match a package which matches that exact atom.
For instance:
# apk search -x linux-grsec
linux-grsec-4.9.20-r0
# apk search -x $(apk search -x linux-grsec)
#
This issue is present in all places where apk expects a $pkgname and
receives a complete atom in the format returned by ‘apk search -x
$pkgname’.
This behavior is counter-intuitive and leads to significant additional
effort being required in parsing within scripts calling apk to strip the
version, perform an operation with apk, then check the version actually
retrieved.
apk should accept the full atom as returned by ‘apk search -x’, and
throw an error if the version specified doesn’t match the available
$pkgver.
*(from redmine: issue id 7100, created on 2017-04-07)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/6081apk info --depends is slow2022-12-21T18:50:51Zalgitbotapk info --depends is slow*(from redmine: issue id 6081, created on 2016-08-25)**(from redmine: issue id 6081, created on 2016-08-25)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5980Ability to Default to --no-cache2019-12-27T14:52:15ZNoah NordrumAbility to Default to --no-cacheGiven that
docker --no-cache add curl
would be best practice in a docker container (I assume), it would be
nice if there was a mechanism to change that default.
I can think of a number of ways:
- compile flag
- separate ap...Given that
docker --no-cache add curl
would be best practice in a docker container (I assume), it would be
nice if there was a mechanism to change that default.
I can think of a number of ways:
- compile flag
- separate apk-tools package
- /etc/apkrc
- environment variable that is always added to the command line like
APK\_OPTIONS that could be set to —no-cache in the alpine base image
or you could just tell me to keep using in my root container :)
alias apk="apk --no-cache"
I know it seems I’m being super lazy, but I think it’s best to provide
best practices as the default options and then let people deviate if
they choose.
*(from redmine: issue id 5980, created on 2016-07-28)*
* Relations:
* relates #8161v3.0Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5977Parallel Downloads for "apk add"2024-02-23T12:34:41ZNoah NordrumParallel Downloads for "apk add"I think it would be great to have the option to do parallel downloads of
packages, with a configurable amount of threads. Something like “apk
—no-cache —parallel=8 add openjdk8”. (with a default of 1)
You could also grab the various AP...I think it would be great to have the option to do parallel downloads of
packages, with a configurable amount of threads. Something like “apk
—no-cache —parallel=8 add openjdk8”. (with a default of 1)
You could also grab the various APKINDEXes using that same thread pool.
If you didn’t want to hammer the CDNs, you could add a hard-coded
exemption to \*.alpinelinux.org or something.
I’m running a local mirror of dl-cdn.alpinelinux.org, so I would really
like to take advantage of my internal bandwidth.
Since all the dependency information is in APKINDEX, I would think it
wouldn’t be too painful to throw it in a prioritized queue and delegate
to an executor of some kind, but I haven’t looked at the internals
(yet).
*(from redmine: issue id 5977, created on 2016-07-27)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5369Add support for LZ42024-02-19T15:48:48ZCarlo LandmeterAdd support for LZ4According to the author on: https://github.com/Cyan4973/lz4 lz4
decompresses almost by a factor 7 compared to zlib while keeping
compression at similar level.
Would this be an possible candidate to replace zlib in apk?
*(from redmine...According to the author on: https://github.com/Cyan4973/lz4 lz4
decompresses almost by a factor 7 compared to zlib while keeping
compression at similar level.
Would this be an possible candidate to replace zlib in apk?
*(from redmine: issue id 5369, created on 2016-04-05)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5073Priority for directory permissions2024-03-19T12:58:43ZKaarle RitvanenPriority for directory permissionsCurrently, apk uses a specific algorithm to combine the directory mode
and owner information from all installed packages. In some cases,
rendering the desired permissions in the file system requires adjusting
the APKBUILD file of all pac...Currently, apk uses a specific algorithm to combine the directory mode
and owner information from all installed packages. In some cases,
rendering the desired permissions in the file system requires adjusting
the APKBUILD file of all packages containing the directory.
The suggested solution is to allow setting a directory permission
priority on per package basis. This attribute would control which
package takes precedence in determining the permissions, similar to how
‘replaces\_priority’ affects file permissions and content. If the
highest priority would be claimed by multiple packages, apk would revert
to the current behavior, taking only the highest-priority packages into
account.
*(from redmine: issue id 5073, created on 2016-02-04)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5056Repeated fields in apk info with multiple repositories2022-12-21T20:00:36ZMark WhiteRepeated fields in apk info with multiple repositories`apk info` repeats some fields when multiple repositories are in use.
For example, with a clean Alpine 3.3.1, set /etc/apk/repositories to:
http://dl-1.alpinelinux.org/alpine/v3.3/main
@edge http://dl-1.alpinelinux.org/alpine/ed...`apk info` repeats some fields when multiple repositories are in use.
For example, with a clean Alpine 3.3.1, set /etc/apk/repositories to:
http://dl-1.alpinelinux.org/alpine/v3.3/main
@edge http://dl-1.alpinelinux.org/alpine/edge/main
Running `apk update && apk info vim` produces:
vim-7.4.943-r2 description:
advanced text editor
vim-7.4.943-r2 webpage:
http://www.vim.org
vim-7.4.943-r2 installed size:
25038848
vim-7.4.943-r2 description:
advanced text editor
vim-7.4.943-r2 webpage:
http://www.vim.org
vim-7.4.943-r2 installed size:
25038848
With `apk info -a` on an installed package, not all fields are repeated;
eg “contains” is only printed once, but “description” is repeated.
*(from redmine: issue id 5056, created on 2016-01-31)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10989Question: About apk-tools-zsh-completion2024-03-27T23:37:17ZMalik NQuestion: About apk-tools-zsh-completionIt seems I have a package called apk-tools-zsh-completion, but I cant find it in the world file, not with `whereis apk-tools-zsh-completion`, and not in the aports repository. It is only visible in gnome software with the same version nu...It seems I have a package called apk-tools-zsh-completion, but I cant find it in the world file, not with `whereis apk-tools-zsh-completion`, and not in the aports repository. It is only visible in gnome software with the same version number like apk-tools 2.14.1.
What might have caused this and how I can source those files in my .zshrc?https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10988should provider format allow `,` and `[`2024-03-27T14:51:23ZSertonixshould provider format allow `,` and `[`alpine linux includes providers that don't follow the current spec since they contain `,` and `[` characters. The question is if they should be allowed or excluded as providers.
```
cmd:[
cmd:sxmo_deviceprofile_fairphone,fp4.sh
cmd:sxmo...alpine linux includes providers that don't follow the current spec since they contain `,` and `[` characters. The question is if they should be allowed or excluded as providers.
```
cmd:[
cmd:sxmo_deviceprofile_fairphone,fp4.sh
cmd:sxmo_deviceprofile_kobo,clarahd.sh
cmd:sxmo_deviceprofile_lge,hammerhead.sh
cmd:sxmo_deviceprofile_longcheer,l8150.sh
cmd:sxmo_deviceprofile_motorola,harpia.sh
cmd:sxmo_deviceprofile_nokia,omap3-n900.sh
cmd:sxmo_deviceprofile_oneplus,cheeseburger.sh
cmd:sxmo_deviceprofile_oneplus,dumpling.sh
cmd:sxmo_deviceprofile_oneplus,enchilada.sh
cmd:sxmo_deviceprofile_oneplus,fajita.sh
cmd:sxmo_deviceprofile_pine64,pinebook-pro.sh
cmd:sxmo_deviceprofile_pine64,pinebook.sh
cmd:sxmo_deviceprofile_pine64,pinenote.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.0.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.1.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.2.sh
cmd:sxmo_deviceprofile_pine64,pinephone-pro.sh
cmd:sxmo_deviceprofile_pine64,rockpro64-v2.1.sh
cmd:sxmo_deviceprofile_purism,librem5r2.sh
cmd:sxmo_deviceprofile_purism,librem5r3.sh
cmd:sxmo_deviceprofile_purism,librem5r4.sh
cmd:sxmo_deviceprofile_qcom,msm8226-mtp.sh
cmd:sxmo_deviceprofile_samsung,a3u-eur.sh
cmd:sxmo_deviceprofile_samsung,a5u-eur.sh
cmd:sxmo_deviceprofile_samsung,coreprimevelte.sh
cmd:sxmo_deviceprofile_samsung,e5.sh
cmd:sxmo_deviceprofile_samsung,e7.sh
cmd:sxmo_deviceprofile_samsung,grandmax.sh
cmd:sxmo_deviceprofile_samsung,gt510.sh
cmd:sxmo_deviceprofile_samsung,i9300.sh
cmd:sxmo_deviceprofile_samsung,j5.sh
cmd:sxmo_deviceprofile_samsung,j5x.sh
cmd:sxmo_deviceprofile_samsung,n8010.sh
cmd:sxmo_deviceprofile_shift,axolotl.sh
cmd:sxmo_deviceprofile_wingtech,wt88047.sh
cmd:sxmo_deviceprofile_xiaomi,beryllium.sh
cmd:sxmo_deviceprofile_xiaomi,elish.sh
cmd:sxmo_deviceprofile_xiaomi,polaris.sh
cmd:uutils-[
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10987apk3 fails to parse apk2 install_if2024-03-27T15:36:33ZSertonixapk3 fails to parse apk2 install_ifWhen I run `apk3 -s upgrade` on an apk2 system I get false package installation:
```
~/src/apk-tools$ output/src/apk -s upgrade
(1/4) Installing opensmtpd-openrc (7.4.0p1-r1)
(2/4) Installing opensmtpd-doc (7.4.0p1-r1)
(3/4) Installing o...When I run `apk3 -s upgrade` on an apk2 system I get false package installation:
```
~/src/apk-tools$ output/src/apk -s upgrade
(1/4) Installing opensmtpd-openrc (7.4.0p1-r1)
(2/4) Installing opensmtpd-doc (7.4.0p1-r1)
(3/4) Installing owfs-doc (3.2p4-r0)
(4/4) Installing tcptraceroute-doc (1.5b7-r4)
OK: 4855 MiB in 1366 packages
```
apk2:
```
~$ apk -s upgrade
OK: 4855 MiB in 1366 packages
```
It seems that apk3 doesn't parse the install_if field correctly in apk2 packages:
```
~/src/apk-tools$ output/src/apk info tcptraceroute-doc --install-if
tcptraceroute-doc-1.5b7-r4 has auto-install rule:
docs
```
apk2:
```
~$ apk info tcptraceroute-doc --install-if
tcptraceroute-doc-1.5b7-r4 has auto-install rule:
docs
tcptraceroute=1.5b7-r4
```
This may be related to the still undocumented `digit{letter{digit}}` format used on alpine linux (https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972#note_380899).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10986xattrs are not correctly treated by audit2024-03-26T13:09:53ZDaniel Kolesaxattrs are not correctly treated by auditWhen you have binaries with xattrs, they will always show as `x` in audit:
```
x usr/bin/clockdiff
x usr/bin/ping
```
the binaries otherwise have correct permissions/xattrsWhen you have binaries with xattrs, they will always show as `x` in audit:
```
x usr/bin/clockdiff
x usr/bin/ping
```
the binaries otherwise have correct permissions/xattrshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10985can't read --protected-paths from pipe2024-03-25T10:06:54ZSertonixcan't read --protected-paths from pipe`apk audit --protected-paths /dev/stdin` doesn't read stdin at all.
The reason seems to be that the `apk_blob_from_file` function doesn't handle pipes/fifos.`apk audit --protected-paths /dev/stdin` doesn't read stdin at all.
The reason seems to be that the `apk_blob_from_file` function doesn't handle pipes/fifos.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10984meson: openssl_static dependency in libfetch results in double linking2024-03-21T12:07:36ZDaniel Kolesameson: openssl_static dependency in libfetch results in double linkingThe recent changes brought in a libfetch dependency on openssl, however this results in openssl for now harmlessly being linked twice. Worse would be if it tried to link the second openssl statically, which it does not for now. Either wa...The recent changes brought in a libfetch dependency on openssl, however this results in openssl for now harmlessly being linked twice. Worse would be if it tried to link the second openssl statically, which it does not for now. Either way, it should only link once.
potential patch:
```
From 58feb1d66f8ec5e1f607dabd8c83ae725c3dc1ac Mon Sep 17 00:00:00 2001
From: q66 <q66@chimera-linux.org>
Date: Thu, 21 Mar 2024 12:04:58 +0100
Subject: [PATCH] libfetch: fix openssl dependency specification
We shouldn't include the full static linkage as it may accidentally
bring static openssl into the apk link path. We only care about the
includes here, so do that.
---
libfetch/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libfetch/meson.build b/libfetch/meson.build
index 7406fbb..59ea789 100644
--- a/libfetch/meson.build
+++ b/libfetch/meson.build
@@ -38,7 +38,7 @@ libfetch = static_library(
'fetch',
libfetch_src,
c_args: libfetch_cargs,
- dependencies: openssl_static_dep,
+ dependencies: openssl_dep.partial_dependency(compile_args: true, includes: true),
)
libfetch_dep = declare_dependency(
--
2.44.0
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10983can no longer extract packages as user since --usermode changes2024-03-21T12:36:12ZDaniel Kolesacan no longer extract packages as user since --usermode changesThe usermode changes were made for apk add, but do not account for manual package extraction.The usermode changes were made for apk add, but do not account for manual package extraction.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10982apk3: conflicts are broken since recently2024-03-20T18:37:56ZDaniel Kolesaapk3: conflicts are broken since recentlySome of the recent changes broke package conflicts. Instead, the `!` is stripped and it's considered a dependency. The actual package metadata in adb is still correct.Some of the recent changes broke package conflicts. Instead, the `!` is stripped and it's considered a dependency. The actual package metadata in adb is still correct.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10981apk3: running triggers now always leaves apk in error state2024-03-20T13:40:45ZDaniel Kolesaapk3: running triggers now always leaves apk in error state```
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
E...```
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
Executing base-shells-0.1-r0.trigger
Regenerating /etc/shells...
1 error; 1286 MiB in 145 packages
root@cbuild: ~$ apk fix
After this operation, 0 B of additional disk space will be used.
OK: 1286 MiB in 145 packages
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
Executing base-shells-0.1-r0.trigger
Regenerating /etc/shells...
1 error; 1286 MiB in 145 packages
```
Relevant commit is probably 60fec0bd3de1c3f8f6747fbc170765c69e0de438https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10980apk3: segfaults since recent updates2024-03-20T15:06:42ZDaniel Kolesaapk3: segfaults since recent updatesTried to update in Chimera from c8c9df1825760e558f44397500af2a2f4bca18d4 to latest master.
Immediately encountered a segfault:
```
root@cbuild: ~$ apk add perl
The following NEW packages will be installed:
less perl
After this operat...Tried to update in Chimera from c8c9df1825760e558f44397500af2a2f4bca18d4 to latest master.
Immediately encountered a segfault:
```
root@cbuild: ~$ apk add perl
The following NEW packages will be installed:
less perl
After this operation, 51 MiB of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/2) Installing less (643-r0)
(2/2) Installing perl (5.38.2-r0)
8% ███████████████ Segmentation fault (core dumped)
root@cbuild: ~$ lldb -c core.12
(lldb) target create --core "core.12"
Core file '/tmp/core.12' (x86_64) was loaded.sl-x86_64.so.1...
(lldb) bt
* thread #1, name = 'apk', stop reason = signal SIGSEGV: address not mapped to object
* frame #0: 0x00007c4e64fcbce1 libapk.so.2`apk_db_dir_prepare(db=0x000059597e8d3830, dir=0x00007c4e644c5c70) at database.c:276:20
frame #1: 0x00007c4e64fd949f libapk.so.2`apk_db_install_file(ectx=0x00007ffec51c63a0, ae=0x00007ffec51c3de8, is=0x0000000000000000) at database.c:2757:3
frame #2: 0x00007c4e64fdb5b4 libapk.so.2`apk_extract_v3_next_file [inlined] apk_extract_v3_directory(ectx=0x00007ffec51c63a0) at extract_v3.c:128:6
frame #3: 0x00007c4e64fdb3dc libapk.so.2`apk_extract_v3_next_file(ectx=0x00007ffec51c63a0) at extract_v3.c:164:8
frame #4: 0x00007c4e64fdb196 libapk.so.2`apk_extract_v3_data_block(db=0x00007ffec51c4088, b=<unavailable>, is=0x00007ffec51c3f60) at extract_v3.c:192:6
frame #5: 0x00007c4e64fbd630 libapk.so.2`adb_m_process at adb.c:244:7
frame #6: 0x00007c4e64fbd22c libapk.so.2`adb_m_process(db=0x00007ffec51c4088, is=0x00007c4e64832f30, expected_schema=<unavailable>, t=0x000059597e8d35b8, cb=<unavailable>) at adb.c:280:9
frame #7: 0x00007c4e64fdaf1d libapk.so.2`apk_extract_v3(ectx=0x00007ffec51c63a0, is=0x00007c4e64f04fc0) at extract_v3.c:253:6
frame #8: 0x00007c4e64fd4fe2 libapk.so.2`apk_db_install_pkg [inlined] apk_extract(ectx=<unavailable>, is=0x00007c4e64f04fc0) at extract_v3.c:292:41
frame #9: 0x00007c4e64fd4fdd libapk.so.2`apk_db_install_pkg [inlined] apk_db_unpack_pkg(db=0x000059597e8d3830, ipkg=0x00007c4e62fd2010, upgrade=<unavailable>, cb=(libapk.so.2`progress_cb at commit.c:129:37), cb_ctx=0x00007ffec51c64c0, script_args=0x00007ffec51c5240) at database.c:2996:6
frame #10: 0x00007c4e64fd4e21 libapk.so.2`apk_db_install_pkg(db=0x000059597e8d3830, oldpkg=0x0000000000000000, newpkg=0x00007c4e6399e610, cb=(libapk.so.2`progress_cb at commit.c:129:37), cb_ctx=0x00007ffec51c64c0) at database.c:3047:7
frame #11: 0x00007c4e64fc880a libapk.so.2`apk_solver_commit_changeset(db=0x000059597e8d3830, changeset=0x00007ffec51c65a0, world=0x00007c4e62a77a40) at commit.c:377:9
frame #12: 0x00007c4e64fca62e libapk.so.2`apk_solver_commit(db=0x000059597e8d3830, solver_flags=0, world=0x00007c4e62a77a40) at commit.c:813:7
frame #13: 0x000059597e861359 apk`add_main(ctx=0x00007c4e651039f0, ac=<unavailable>, args=0x00007c4e65163e50) at app_add.c:209:6
frame #14: 0x000059597e86073a apk`main(argc=1, argv=0x00007ffec51c7348) at apk.c:616:6
frame #15: 0x00007c4e65457bca ld-musl-x86_64.so.1`libc_start_main_stage2(main=(apk`main at apk.c:493), argc=<unavailable>, argv=0x00007ffec51c7338) at __libc_start_main.c:95:7
frame #16: 0x000059597e85fa76 apk`_start + 22
(lldb) p dir->owner
(apk_db_dir_instance *) NULL
```