2026-08-01 12:12:30 <Newbyte> Could someone close this: v
2026-08-01 12:12:31 <Newbyte> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/16484
2026-08-01 12:13:16 <WhyNotHugo> Getting blocked from the wiki with Request Id 5a2d80dffd4d44964d650f6de883d4fb.
2026-08-01 12:13:31 <WhyNotHugo> Er, it worked a few seconds later.
2026-08-02 09:14:36 <alexaandru> hi all! Could someone take a look at !106338 ? I tried to backport the github-cli security fixes from master to 3.24, it's my 1st non-master MR, hope I got things right... :-) Thank you!!
2026-08-02 13:33:31 <mid> Hi! In an APKBUILD there is one main package "M", and two (non mutually exclusive) subpackages "A" and "B". Is it possible to make apk to automatically install the subpackage "A", say as a default backend, if the user only requests to install "M" without requesting apk to add, along with it, neither "A" nor "B"?
2026-08-02 13:42:41 <mid> well, maybe this use case is bad, better always depend on "A", or even on none of them, and provide good documentation 😉
2026-08-02 14:05:32 <quinq> I suppose put A in the package dependencies, and not B
2026-08-02 14:22:52 <mid> yes but I wanted to not necessarily install A if only M and B were requested, but I don't think it's worth it in my case, sorry for the noise
2026-08-02 15:19:16 <Sertonix[m]> A and B can provide C (as unversioned virtual provider) and M can depend on C. A can use provider_priority to be prefered
2026-08-02 15:22:23 <quinq> But if A and B provide C, wouldn't they be mutually exclusive?
2026-08-02 16:58:05 <Sertonix[m]> Not if C is unversioned
2026-08-02 17:31:38 <quinq> ok
2026-08-02 17:41:21 <mid> thanks!
2026-08-03 08:08:06 <ikke> gitlab is unavailable, linode is performing emergency maintenance
2026-08-03 08:22:08 <ikke> It's back
2026-08-03 19:25:21 <nickbors> can anyone help me package my first daemon? i have abuilds forked and i was wondering if i should create it under testing or under community
2026-08-03 19:27:09 <mio> nickbors: new aports start in testing/, with exception for direct dependency, e.g. of an existing aport in community/
2026-08-03 19:27:52 <nickbors> i only depend on zig at build time
2026-08-03 19:31:51 <mio> sorry, meant if whatever you're packaging is needed by an existing aport to build/run
2026-08-03 19:32:09 <mio> if not, it can probably start in testing/
2026-08-03 19:32:59 <nickbors> okay got it haha
2026-08-03 19:33:02 <nickbors> thanks for the help
2026-08-03 19:33:08 <mio> you're welcome
2026-08-03 19:33:24 <nickbors> mio: does the version start with a v?
2026-08-03 19:34:22 <nickbors> my naming convention is vX.X.X currently at https://git.nickbors.cc/<name>-<version>.tar.gz so i assume pkgver should be e.g v1.1.1
2026-08-03 19:34:46 <nickbors> or do i leave the v in the url but make the pkgver without it
2026-08-03 19:34:47 <mio> pkgver? no
2026-08-03 19:35:07 <mio> maybe have a look at https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgver
2026-08-03 19:35:40 <mio> so in your case, 1.1.1
2026-08-03 19:36:20 <mio> and url can use v$pkgver if that is how you've tagged it
2026-08-03 19:36:29 <nickbors> okay got it
2026-08-03 20:02:24 <nickbors> mio: sorry to bug you but do i need a .initd if my package already has an openrc conf (i made it for alpine) 
2026-08-03 20:03:12 <nickbors> i wont need to install that right? or i can just install it from $srcdir/contrib/openrc/$pkgname
2026-08-03 20:05:28 <mio> the latter
2026-08-03 20:09:04 <mio> (e.g. install to "$pkgdir"/etc/init.d/ and add an $pkgname-openrc to subpackages)
2026-08-03 20:09:41 <nickbors> thanks for the details
2026-08-03 20:10:43 <mio> you're welcome
2026-08-03 20:20:52 <nickbors> mio: my daemon requires a database. How would i go about migrations? just pre/post upgrade?
2026-08-03 20:21:41 <nickbors> my daemon isnt in charge of the schema because unix philosophy but i suppose id want migrations to be a thing haha
2026-08-03 20:29:58 <mio> not sure, sorry, maybe others can better advise there. some packages include migration scripts
2026-08-03 20:31:31 <mio> different from .{pre,post}-upgrade
2026-08-03 21:00:12 <durrendal> nickbors: what I typically do is write a migration function into the software itself, then when you load the DB you can check the schema version and walk it through the update process on first load.
2026-08-03 21:00:33 <durrendal> that doesn't work for everything though so take it with a grain of salt, it's just the pattern I've personally reached for.
2026-08-03 21:01:06 <nickbors> durrendal: yeah i settled on that haha 
2026-08-03 21:01:09 <nickbors> thanks for the tip
2026-08-03 21:02:38 <durrendal> no problem, sometimes the path of least resistance is worth it. Plus in the future if another maintainer (or you) port it to a different distro the logic remains bound to the application rather than a specific packaging system
2026-08-03 21:03:47 <nickbors> durrendal: thats always a plus haha
2026-08-03 21:04:01 <nickbors> i was thinking of making a seperate util (like how postgres has pg_migrate)
2026-08-03 21:04:43 <nickbors> i have 3 scripts now its ALMOST time for a ctl haha
2026-08-03 21:04:54 <nickbors> but im avoiding doing real cli arg parsing lol
2026-08-03 21:06:03 <durrendal> nothing wrong with that method either, sometimes a handful of shell scripts with clear schema/1_$x.sh 2_$x.sh labelling is easier
2026-08-03 21:07:12 <durrendal> if you went that route you probably could wire it into post-install scripts. Or, maybe your openrc script could have a migrate function that invokes those scripts which you package alongside everything
2026-08-03 21:08:05 <nickbors> no i meant like one big migrate shell script that just read the schema version, find awk sed chained its way and piped to psql haha. The other scripts are for adding/deleting users
2026-08-04 13:19:08 <mid> a bit of self-promo (!): I have submitted !106361, a new aport that packages `dav-next`, a humble work of mine. I know that the approval (or not) or new aports can take long time, but I say this here because before ± officially announcing my humble great work (🤣) to the 👀 of the World, and because a nginx module it is not easy to compile / install / setup,  I'd like to have it at least packaged for Alpine and hopefull
2026-08-04 13:19:08 <mid> y have some feedback from interested people in its community. If there is a better way to proceed then of course feel free to tell me!
2026-08-04 18:10:54 <Habbie> mid, i have no feedback, but cool project :)
2026-08-04 18:18:09 <mid> thank you!
2026-08-05 03:26:28 <nickbors> hey guys! I just merged + mailed my first aport (a pastebin service i made in zig). If any of you have time, could you sanity check !106437? any help would be much appreciated :)
2026-08-05 05:41:03 <jvvv> nickbors: in the subpkg function, patze(), you are using the already defined builddir value ("$srcdir"/patze-v$pkgver") but the PWD for that function should already be $builddir
2026-08-05 05:43:38 <jvvv> actually you have done that in the package() function also... redundant
2026-08-05 05:44:46 <jvvv> it's a pretty minor nit, though I do think you should adjust it
2026-08-05 05:45:44 <jvvv> otherwise, looks good to me, especially for your first aport
2026-08-05 06:20:16 <nickbors> thanks jvvv, thats encouraging to hear! ill get around to that
2026-08-05 08:32:10 <jvvv> yw
2026-08-05 10:19:11 <ncopa> I'd like to tag an edge snapshot. would be great if we could get the edge builders idle
2026-08-05 10:19:37 <ncopa> so maybe hold big/heavy merges for now?
2026-08-05 15:37:01 <ikke> riscv64 16/24
2026-08-05 18:14:06 <ncopa> edge snapshot tagged. feel free to push again
2026-08-05 18:16:00 <ncopa> will do docker image update later tonight
2026-08-05 20:05:05 <sam_> does alpine (or apk) sandbox builds from the network?
2026-08-05 20:05:09 <sam_> (either by default or optionally)
2026-08-05 20:05:18 <sam_> my understanding was no (when summarising what various distros/pms do)
2026-08-05 20:05:39 <ikke> sam_: default, no. `abuild rootbuild` would
2026-08-05 20:06:04 <sam_> thank you!
2026-08-05 20:07:19 <ikke> Some packages still opt-in to networking using the `net` option
2026-08-05 20:07:46 <ikke> go/rust packages for example would need `net`
2026-08-06 11:58:44 <Habbie> git pull from https://gitlab.alpinelinux.org/alpine/aports.git appears to hang
2026-08-06 11:58:51 <Habbie> i wonder if Anubis is involved
2026-08-06 12:00:52 <Habbie> oh it went through
2026-08-06 12:25:54 <Habbie> hey, when did ~/packages change to ~/.local/share/abuild
2026-08-06 12:27:50 <PureTryOut> Oh did it? Nice! Although that shouldn't happen automatically and break workflows ofc. Still glad I don't need my ~ littered anymore though 😄
2026-08-06 13:04:10 <Habbie> i might add a symlink, to be fair ;)
2026-08-06 13:22:04 <roselandgoose> Habbie, PureTryOut : pretty sure that's configurable with an env var. idk if the default changed recently or not
2026-08-06 13:22:13 <Habbie> the default feels changed to me
2026-08-06 13:22:27 <Habbie> in fact seeing what this 3.24 abuild has done in a few minutes will confirm that
2026-08-06 13:22:35 <Habbie> (unless it changed before the 3.24 release)
2026-08-06 13:24:42 <roselandgoose> i think its $REPODEST, per abuild(1) ENVIRONMENT section
2026-08-06 13:25:15 <roselandgoose> is that var set in your env?
2026-08-06 13:26:08 <Habbie> it's not set in my 3.24 env, where abuild just now created ~/packages
2026-08-06 13:26:28 <Habbie> REPODEST is also not set in my edge env
2026-08-06 13:27:35 <roselandgoose> but on the edge machine .local/share/abuild received the built packages? interesting
2026-08-06 13:27:46 <Habbie> yes
2026-08-06 13:28:09 <roselandgoose> checkout /etc/abuild.conf as well, where these variables are conventionally set
2026-08-06 13:28:32 <roselandgoose> otherwise I must be mistaken/missing something that has changed
2026-08-06 13:28:55 <Habbie> i'll do some more digging in a bit
2026-08-06 13:34:02 <Habbie> https://gitlab.alpinelinux.org/alpine/abuild/-/work_items/9997
2026-08-06 13:34:11 <Habbie> changed in abuild 3.18.0_rc3
2026-08-06 13:35:01 <Habbie> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/531
2026-08-06 13:35:17 <Habbie> in /etc/abuild.conf, the #REPODEST line indeed is different between 3.24 and edge
2026-08-06 13:43:04 <jvvv> I think the change is applied by /usr/share/abuild/default.conf:32
2026-08-06 13:43:43 <jvvv> That is on edge. I don't have a 3.24 box up rn
2026-08-06 13:47:35 <jvvv> After extracting the lastest abuild for 3.24, that conditional is not in the default.conf
2026-08-06 13:51:14 <jvvv> Looking at the various places in usr/bin/abuild and usr/share/abuild/functions.sh, I don't see how REPODEST would default to .local/share/abuild unless it is set in your /etc/abuild.conf or .abuild/abuild.conf
2026-08-06 13:52:19 <jvvv> That is, for 3.24 stable. On edge, it depends on if .local/share/abuild exists or not, and if REPODEST is already set
2026-08-06 13:59:07 <Habbie> on 3.24 i still get ~/packages, so that fits
2026-08-06 13:59:42 <Habbie> on edge it happens even without ~/.local present beforehand
2026-08-06 13:59:53 <Habbie> note that i'm not complaining and don't need help, i was just briefly surprised
2026-08-06 13:59:59 <Habbie> what worries me is how many other people are surprised ;)
2026-08-06 14:01:27 <jvvv> Sertonix[m]: shouldn't usr/share/default.conf first check for REPODEST being set before defaulting to anything? The way it is now, it looks like it will override REPODEST being set in etc/abuild.conf or .abuild/abuild.conf
2026-08-06 14:02:32 <jvvv> or is default.conf sourced before etc/abuild.conf and .abuild/abuild.conf?
2026-08-06 14:03:20 <Sertonix[m]> default.conf is sourced first
2026-08-06 14:07:24 <jvvv> Sorry, I see it now, in readconfig()
2026-08-06 17:02:21 <Mis012[m]> any idea if anything can be done about tilix (and gtkd) conflicting with libunwind-dev by way of ldc-runtime->llvm-libunwind (not -dev)
2026-08-06 20:20:07 <Habbie> it would be nice if apkbuild-lint also marked things WARNING or ERROR, like abuild validate does
2026-08-07 02:18:52 <Sertonix[m]> Habbie: Just to make sure, was there a ~/packages directory before ~/.locale/share/abuild was used?
2026-08-07 07:24:13 <Habbie> Sertonix[m], no
2026-08-07 07:36:54 <Saijin_Naib[m]> anyone have bandwidth to review !99156 !106234 !106236 !97494
2026-08-07 08:58:44 <fabricionaweb> Hi, I have one open PR that needs review :D aports:add !106038
2026-08-07 08:58:58 <fabricionaweb> good morning everyone, happy friday, happy coding