2022-06-01 02:25:34 <rbq> Hi, timlegge, while doing the rebuild for Perl 5.36.0, I noticed that one of your aports (perl-math-pari) has to fetch additional sources from FTP. Just wondering if you're aware of this.
2022-06-01 09:55:38 <timlegge> rbq: I did know that but had forgotten.  I believe it will use the pari library if it is installed.  I will take a look.
2022-06-01 10:00:19 <rbq> There's a pari package in testing/, however, I think it's an older version
2022-06-01 10:08:23 <rbq> No wait, it's a newer version (2.13.3), Math::Pari, on the other hand, fetches version 2.3.5 from FTP
2022-06-01 10:20:18 <rbq> There's also https://metacpan.org/release/ILYAZ/Math-Pari-2.030523/source/README-after2_3_5 , so I guess there's not much we can do about it
2022-06-01 10:41:05 <timlegge> https://metacpan.org/release/ILYAZ/Math-Pari-2.030523/source/INSTALL starting line 66 says it can use a preinstalled version with issues
2022-06-01 10:41:38 <timlegge> I will look closer tonight as it patches the pari version it uses to build
2022-06-01 11:00:30 <rbq> Ok, thanks for taking the time to look into this, however after reading the list of potential problems and how this way of building pari isn't really supported, if it doesn't work, I guess we'll just leave things the way they are now
2022-06-01 12:14:28 <PureTryOut> So uh just building things with abuild rootbld, my `/var/tmp` directory suddenly takes up 102GB. Why does abuild use `/var/tmp` rather than `/tmp` and why does it not clean up after itself?
2022-06-01 12:18:30 <panekj> do you perhaps have set TMP, TEMP or TMPDIR envvar?
2022-06-01 12:19:08 <panekj> rootbld binds /tmp https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2459
2022-06-01 12:20:57 <PureTryOut> None of those are set no
2022-06-01 12:23:49 <psykose> do you have cleanup/error_cleanup bldroot
2022-06-01 12:25:01 <PureTryOut> I'm not sure what you mean
2022-06-01 12:25:20 <psykose> in abuild.conf
2022-06-01 12:25:23 <panekj> in `/etc/abuild.conf` ERROR_CLEANUP
2022-06-01 12:25:37 <panekj> and CLEANUP
2022-06-01 12:27:56 <psykose> as for why it uses /var/tmp, /tmp is usually tmpfs
2022-06-01 12:32:48 <PureTryOut> ah yes I changed ERROR_CLEANUP a while ago to debug something, seems I forgot to set it back
2022-06-01 12:32:55 <PureTryOut> And yeah I have `/tmp` as tmpfs, that's kinda the point lol
2022-06-01 12:35:05 <psykose> exactly, so if it used /tmp, a bunch of large things would fail to build
2022-06-01 12:35:24 <psykose> if you want it to be tmpfs, add an entry for /var/tmp to be one, and it's fixed
2022-06-01 12:35:37 <psykose> i don't have 64gb of memory, so i don't
2022-06-01 12:48:13 <nmeum> fun, yet another use-after-free in busybox ash
2022-06-01 12:48:25 <nmeum> the gift that never keeps on giving
2022-06-01 12:48:51 <psykose> my favorite :)
2022-06-01 12:49:20 <nmeum> also: somehow Denys has been very active regarding reviewing of BusyBox patches lately so I guess we also just have to fix this downstream as well :(
2022-06-01 13:23:00 <PureTryOut> psykose: ah yeah sure makes sense actually
2022-06-01 13:23:15 <PureTryOut> strangely enough my /tmp is only 8GB while this machine has 16GB RAM 🤔
2022-06-01 13:23:21 <psykose> the default is 50%
2022-06-01 13:23:31 <psykose> you can add size=x% to mount options
2022-06-01 13:23:33 <PureTryOut> Oh, TIL
2022-06-01 13:24:49 <skarnet> ohey I used all my RAM in /tmp, I wonder why I can't run 'ls' :think:
2022-06-01 13:27:19 <PureTryOut> Yeah no it makes sense lol
2022-06-01 21:20:48 <omni> ptrc: yes, and I can find my way there, it doesn't matter too much to me
2022-06-02 04:55:21 <panekj> are all go packages rebuilt when go is updated?
2022-06-02 04:55:37 <craftyguy> from what I've seen: ya
2022-06-02 04:55:55 <panekj> I would an answer from dev
2022-06-02 04:56:03 <ikke> yes
2022-06-02 04:56:21 <panekj> ok, so can we please merge go stuff to abuild before 1.18.3 
2022-06-02 04:57:13 <craftyguy> the aports git log also shows that historically that has been the case :P
2022-06-02 04:58:00 <panekj> craftyguy: I have seen that, thank you, don't take it personally but I prefer an answer from someone who is currently part of Alpine team
2022-06-02 04:58:10 <craftyguy> 👍
2022-06-02 04:58:44 <craftyguy> ya I'm not important enough to give any definitive answers here :D
2022-06-02 05:00:12 <panekj> ncopa is away for this week right?
2022-06-02 05:01:09 <ikke> yes
2022-06-02 05:01:35 <panekj> craftyguy: it's more of the "this person from alpine team said it, therefore we can blame them (not really)" :P
2022-06-02 05:02:13 <panekj> also this pertains to your MR "abuild.conf: disable Go's buildvcs"
2022-06-02 05:08:55 <sam_> oh that thing lol
2022-06-02 05:08:58 <sam_> what a load of junk
2022-06-02 05:09:12 <panekj> not only
2022-06-02 05:09:13 <sam_> i wish they'd added it in a release before changing the behaviour all of a sudden
2022-06-02 05:13:15 <panekj> it's also about modcacherw and trimpath
2022-06-02 11:50:00 <funspectre_> Hi, I've got some packages built. What's the process to contribute them and serve as maintainer for them?
2022-06-02 11:51:13 <craftyguy> funspectre_: I think this is still relevant: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2022-06-02 11:51:52 <craftyguy> you can also send patches to the alpine gitlab, instead of using git send-email (as the last section suggests)
2022-06-02 11:57:29 <funspectre_> Thanks craftyguy 
2022-06-02 12:04:13 <Saijin_Naib> thanks for contributing new packages funspectre_!
2022-06-02 12:11:09 <PureTryOut> 
ACTION needs incremental builds in combination with rootbld lol

2022-06-02 12:13:30 <psykose> ccache gets most of the way there for c/++ only
2022-06-02 12:14:40 <craftyguy> PureTryOut: ya I usually move to rootblk after I get it building 'natively' on my system first
2022-06-02 12:14:57 <craftyguy> s/rootblk/rootbld/
2022-06-02 12:14:57 <alpine-meetbot> craftyguy meant to say: PureTryOut: ya I usually move to rootbld after I get it building 'natively' on my system first
2022-06-02 12:15:32 <craftyguy> not sure if that's the best way, but it saves a lot of time with having to run rootbld a bunch of times
2022-06-02 12:16:21 <PureTryOut> I don't like not using rootbld though :'(
2022-06-02 12:16:49 <PureTryOut> I never use abuild without rootbld actually, does ccache work "automatically" when doing `-r`?
2022-06-02 12:17:21 <psykose> you need the USE_CCACHE=1, and because the defaults changed you need to set CCACHE_DIR=home/.ccache in your profile
2022-06-02 12:17:43 <psykose> (because otherwise the default ccache dir is in home/.cache/.. but it only bind mounts the other one)
2022-06-02 12:17:56 <psykose> aside from that, sure, it works
2022-06-02 12:18:44 <craftyguy> PureTryOut: ya, I use rootbld to confirm makedepends is correct. but for getting the thing to build in the first place (e.g. patchign out glibc-isms and such), does it really matter if that happens iteratively in rootbld or 'natively'?
2022-06-02 12:19:48 <psykose> not really
2022-06-02 12:21:09 <PureTryOut>  /home/.ccache ? That's a weird directory, are you sure?
2022-06-02 12:21:45 <PureTryOut> craftyguy: I suppose not but I like to know my host system doesn't "infect" the build with any dependencies it might have installed that are not specified in the APKBUILD
2022-06-02 12:21:56 <PureTryOut> Also it blocks network access by default which is a big plus to me
2022-06-02 12:23:50 <craftyguy> oh ya that's helpful (blocking network access) !
2022-06-02 12:24:49 <psykose> yourhome/.ccache
2022-06-02 12:33:18 <PureTryOut> Ah that makes more sense haha
2022-06-02 12:33:19 <Hello71> ~/.ccache
2022-06-02 12:36:21 <PureTryOut> Ah darn my host system indeed infects the build environment too much. Guess it's no ccache for me
2022-06-02 12:36:50 <psykose> you don't need to build normally to use it, just setting that up will use it in rootbld only anyway
2022-06-02 12:37:05 <PureTryOut> Oh that's better!
2022-06-02 12:37:29 <PureTryOut> Does anyone know if musl implements mallinfo? I found https://www.openwall.com/lists/musl/2022/01/07/7 but I'm unsure if it got merged and is available in Alpine
2022-06-02 12:37:40 <psykose> to actually dispatch anything to it /usr/lib/ccache/bin has to be first in path
2022-06-02 12:37:43 <psykose> it does not implement it, no
2022-06-02 12:37:54 <PureTryOut> Darn ok, ifdef'ing it out then
2022-06-02 12:38:05 <psykose> in chromium it's patched out, in qt6-qtwebengine you seemingly backported a definition like that and used that instead
2022-06-02 12:38:06 <psykose> doesn't really matter
2022-06-02 12:38:21 <PureTryOut> Strangely enough the compiler passed a block that checks for it `#ifdef HAVE_STRUCT_MALLINFO`, but then complained there was no mallinfo on the next line
2022-06-02 12:38:25 <psykose> ah, no, the qt6 one is much smaller
2022-06-02 12:39:06 <PureTryOut> you mean https://git.alpinelinux.org/aports/tree/testing/qt6-qtwebengine/0003-qt-musl-mallinfo.patch?
2022-06-02 12:39:26 <PureTryOut> that patches it out as well
2022-06-02 12:40:02 <psykose> ah, no, i ported that, i think i was thinking of res_ninit in 0004-resolve
2022-06-02 12:40:40 <PureTryOut> ah yes
2022-06-02 12:41:03 <psykose> as for the HAVE_STRUCT_MALLINFO, idk why it would detect it
2022-06-02 12:41:12 <psykose> it's not in the musl headers; you could look at the configure test
2022-06-02 12:45:14 <PureTryOut> I have no interest in dissecting this too much, this is an old version of the software anyway. I'm purely compiling it for bootstrapping. So I'm just changing it do `#if defined(__GLIBC__)`
2022-06-02 12:45:23 <PureTryOut> *to
2022-06-02 12:45:31 <psykose> tell me what it is and i'll have a look
2022-06-02 12:46:13 <PureTryOut> commit 02eeed29df112728564a5dde6417fa4622b57a06 of gperftools, which is used in a very old Dart build
2022-06-02 12:46:37 <PureTryOut> and then `src/libc_override_gcc_and_weak.h`
2022-06-02 12:47:08 <PureTryOut> But this all invoked through gn which is not fun to work with
2022-06-02 12:47:42 <Ariadne> ah yes `gn`, the other terrible google build system
2022-06-02 12:47:50 <Ariadne> (actually there are 4 of them, all bad in different ways)
2022-06-02 12:48:28 <psykose> it doesn't detect mallinfo for me
2022-06-02 12:48:40 <Ariadne> isnt mallinfo a glibcism
2022-06-02 12:48:58 <psykose> yes
2022-06-02 12:49:17 <psykose> all this needs is seemingly the c++17 throw fix
2022-06-02 12:49:23 <psykose> and a single nullptr fix
2022-06-02 12:50:23 <psykose> `rg mallinfo /usr/include` should tell you if something there has it, the configure check is just checking its presence in <malloc.h>
2022-06-02 12:51:57 <PureTryOut> Ariadne: yeah, I got a special gn package just for this build because they refuse to version their build system...
2022-06-02 12:52:47 <PureTryOut> and of course that old version still depends on python2 so once I have this working I need to patch that to python3...
2022-06-02 12:53:13 <psykose> to be fair everything that uses gn has a specific commit of it
2022-06-02 12:53:48 <PureTryOut> yes because they don't version their gn and are completely backwards incompatible all the god damn time
2022-06-02 12:53:48 <psykose> and that goes for basically everything that uses anything from google; they all vendor a random commit, seen in basically anything that uses gtest, gmock, gn, abseil, etc
2022-06-02 12:54:15 <psykose> at least in the case of abseil they're backwards compatible for a long time and it doesn't matter if you patch it into the system one, hah
2022-06-02 13:01:13 <PureTryOut> oh ccache is amazing to have
2022-06-02 13:03:06 <psykose> there are a very small number of things that fail with ccache, because their build systems 'detect' it and then expect funny stuff, instead of just using the compilers from path
2022-06-02 13:03:19 <psykose> but so far, that has only been.. uhh, dolphin-emu i think failed and that was it
2022-06-02 13:03:22 <psykose> and i've build most of aports
2022-06-02 13:07:50 <PureTryOut> I always do a full clean build after I have things working anyway, just to make sure
2022-06-02 14:15:08 <orbea> psykose: dolphin-emu works with ccache...
2022-06-02 14:15:31 <orbea> was there ever a time it hasn't?
2022-06-02 14:18:21 <psykose> seemingly it does
2022-06-02 14:18:31 <psykose> i remember a time where something didn't maybe it was even something else! :p
2022-06-02 14:23:07 <orbea> :P
2022-06-02 14:23:57 <orbea> maybe it was something like changing the -D defines being passed to the compiler
2022-06-02 14:56:38 <PureTryOut> Could I get another ssh key added to dev.alpinelinux.org? Right now my desktop has one but often I work on my laptop and I like to push things from there as well 😛
2022-06-02 15:12:58 <ikke> PureTryOut: sure
2022-06-02 15:13:14 <ikke> You can even do it yourself :P
2022-06-02 15:13:23 <ikke> Unless you don't have access atm
2022-06-02 15:14:51 <PureTryOut> Well I'm not on my desktop atm, so no I don't have access haha
2022-06-02 15:15:14 <PureTryOut> Could you add `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIErif/OzOaBuvNvqcL1ZMUcksK48VeI0zjNV/FB7R474 bart@spaceblade-2022-06-02`?
2022-06-02 15:16:08 <ikke> PureTryOut: ✅
2022-06-02 15:16:13 <PureTryOut> Thanks!
2022-06-02 15:16:34 <psykose> is that where people can leave the dev tarballs of things that don't have stable upstreams
2022-06-02 15:16:37 <PureTryOut> (what was the username again?)
2022-06-02 15:16:41 <psykose> can i have access for like two things
2022-06-02 15:16:42 <ikke> PureTryOut: puretryout
2022-06-02 15:16:43 <PureTryOut> psykose: yup
2022-06-02 15:16:49 <ikke> psykose: sure, can arrange that
2022-06-02 15:16:56 <PureTryOut> Ah thanks
2022-06-02 15:17:11 <ikke> psykose: username psykose?
2022-06-02 15:17:21 <psykose> ye
2022-06-02 15:19:00 <PureTryOut> In my case the upstream is stable but doesn't offer tarballs, so I'm uploading a tarball made in the snapshot function 🤷
2022-06-02 15:19:36 <ikke> psykose: try psykose@dev.alpinelinux.org
2022-06-02 15:19:50 <psykose> think you added the wrong key
2022-06-02 15:19:58 <ikke> ok, which should I add?
2022-06-02 15:20:00 <psykose> ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ1GNaR5BlDlMvqtJYJPRZIvyBiBwNpRp9d2p8ES3ErY 
2022-06-02 15:20:21 <ikke> done
2022-06-02 15:21:51 <psykose> still says denied for some reason
2022-06-02 15:22:15 <ikke> account is locked, let me fix that
2022-06-02 15:22:24 <ikke> try again
2022-06-02 15:22:27 <psykose> ah, is it the usual locked-account doesn't work with opensshd
2022-06-02 15:22:27 <psykose> hehe
2022-06-02 15:22:32 <psykose> works
2022-06-02 15:23:23 <psykose> thanks!
2022-06-02 15:23:43 <ikke> the archive symlink in your homedir points to https://dev.alpinelinux.org/archive/
2022-06-02 15:24:30 <ikke> there is also a public_html dir
2022-06-02 15:24:40 <ikke> That hosts https://dev.alpinelinux.org/~psykose/
2022-06-02 15:24:48 <psykose> mhm
2022-06-02 15:32:24 <PureTryOut> oh I saw the public_html but never knew what it was used for. Interesting, I have no use for that whatsoever haha
2022-06-02 17:24:38 <funspectre_> I have built and tested my packages for x86_64. I guess it is safe to assume that covers x86 too. How do I test my packages against the other architectures?
2022-06-02 17:26:08 <boomanaiden154> Create a MR on Gitlab and then the CI will build everything and run tests if you have them configured.
2022-06-02 17:32:09 <psykose> dont forget to make the mr from a branch that is not master, and follow the codingstyle/commitstyle, and use similar build-system aports as inspiration :)
2022-06-02 19:52:00 <c7s> how does /etc/init.d/udhcpd even work at all, given that /usr/sbin/$SVCNAME doesn't exist? is there something I don't understand about openrc that makes this work?
2022-06-02 19:52:17 <c7s> or rather /usr/sbin/udhcpd doesn't exist
2022-06-02 19:52:29 <c7s> which I assume is the value in the variable
2022-06-02 19:56:26 <Hello71> apk add busybox-extras
2022-06-02 19:57:41 <ikke> /etc/init.d/udhcpd comes from busybox-initscripts, which contains a collection of services that are installed regardless if the actual binary is available
2022-06-02 19:58:31 <c7s> right
2022-06-02 20:16:25 <skarnet> yeah we'll have to talk about busybox-initscripts
2022-06-02 20:16:42 <skarnet> next week if I can, or the one after
2022-06-02 20:19:06 <Ermine> "We are going to have a serious talk"
2022-06-02 20:29:07 <skarnet> busybox-initscripts and I are going to have a friendly talk. I have prepared an axe.
2022-06-02 20:39:14 <minimal> Thunderdome? 2 men enter, 1 man leaves
2022-06-02 20:50:42 <c7s> hm, we could sell tickets
2022-06-03 05:57:21 <Misthios> Where can i place bets
2022-06-03 06:39:30 <rbq> omni: Hello, for yojson add 'ocaml-seq-dev' to depends_dev, 'ocaml-seq' to depends, add '-p yojson' to dune build in build(), and 'yojson' (yes, build needs -p, install doesn't...and if you want to select multiple "subpackages", they are separated by commas for dune build, and spaces for dune install) to dune install in package(); that should make it compile
2022-06-03 06:46:44 <rbq> '-p yojson' is needed to prevent the other "subpackage" (yojson-bench, which needs Jane Street's Core that we don't have packaged) from being compiled, I think, dune by default tries to compile all "subpackages"
2022-06-03 06:52:18 <rbq> Hi, fcolista, while doing the rebuild for Perl 5.36, one of your aports (perl-io-tty) has its tests fail randomly on the 3 ARM architectures, so I've disabled perl-io-tty's tests on ARM for now, I hope you're alright with that
2022-06-03 06:53:55 <fcolista> rbq, yes...but you should be aware that if perl-io-tty is a dependency of other packages, this will become a mess
2022-06-03 06:54:21 <fcolista> did you checked that?
2022-06-03 06:54:22 <rbq> I've disabled tests only, not the whole package
2022-06-03 06:55:01 <rbq> The package compiles, just has 1 subtest that fails
2022-06-03 06:55:13 <fcolista> so you disabled the test for that arches
2022-06-03 06:55:18 <rbq> Yes
2022-06-03 06:55:26 <fcolista> so we are fine
2022-06-03 06:55:41 <rbq> I guess so :)
2022-06-03 06:56:39 <rbq> timlegge: I also had to disable tests for your perl-barcode-zbar (which started failing after yesterday's ImageMagick upgrade), and for your perl-math-pari, I had to use `make -j1`, hope you are alright with those changes
2022-06-03 06:57:05 <rbq> Anyway, the Perl rebuild MR is !34890
2022-06-03 10:05:25 <timlegge> rbq: no problem I will look into fixing them
2022-06-03 10:12:34 <rbq> Ok, the problem with perl-math-pari and parallel make doesn't happen all the time. It could probably be solved by retrying the build, but the pipeline for the Perl 5.36.0 rebuild MR already takes about 1.5 hours to complete, so I switch to `make -j1` just to be safe.
2022-06-03 10:12:51 <rbq> s/switch/switched/
2022-06-03 10:12:51 <alpine-meetbot> rbq meant to say: Ok, the problem with perl-math-pari and parallel make doesn't happen all the time. It could probably be solved by retrying the build, but the pipeline for the Perl 5.36.0 rebuild MR already takes about 1.5 hours to complete, so I switched to `make -j1` just to be safe.
2022-06-03 11:04:25 <timlegge> rbq:  the -j1 for math-pari is fine
2022-06-03 11:06:59 <rbq> Ok :)
2022-06-03 12:27:08 <indy> Ariadne, hi, how to make apk-tools package from 'upstream' git?
2022-06-03 12:30:39 <panekj> build with meson
2022-06-03 12:30:42 <panekj> indy: ^
2022-06-03 12:43:59 <PureTryOut> hmm for some reason ccache only seems to work with rootbld for me... However rootbld  always wipes the build directory after a failed build...
2022-06-03 12:45:41 <rbq> timlegge: I was not thorough enough with my investigations. The failing test for perl-barcode-zbar was actually caused by ImageMagick being upgraded while the Perl rebuild pipeline was running, which resulted in a version of ImageMagick still linked to the old Perl 5.34 being installed (as it has a never version number) while testing perl-barcode-zbar. I've retried the tests with ImageMagick properly 
2022-06-03 12:45:47 <rbq> linked to the new Perl 5.36, and they all pass. I'm very sorry about this, I'll re-enable tests for perl-barcode-zbar.
2022-06-03 12:46:43 <timlegge> perfect nothing for me to do.  I like it
2022-06-03 12:47:20 <indy> panekj, Ariadne i need urgently resolv jfrog issue i'm facing @ work
2022-06-03 12:48:43 <indy> option one is to take binary from ci and copy to container
2022-06-03 12:50:29 <panekj> you could just build it locally?
2022-06-03 12:51:28 <panekj> if you need .apk file then you can just build it with abuild
2022-06-03 12:52:44 <panekj> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2022-06-03 12:53:35 <panekj> but then you'd have to modify it to use commit archive instead of specific tag
2022-06-03 12:55:03 <panekj> (and use meson)
2022-06-03 13:05:14 <Ariadne> indy: apk-tools 2.12.10 will be out later today
2022-06-03 13:09:50 <indy> Ariadne, thanks a lot, just tested apk.static-x86_64 (2.12.9) from ci artefacts and it works with jfrog
2022-06-03 13:16:54 <rbq> durrendal: Hello, I tried compiling sbcl on x86 without sb-thread, and it seems to solve the memory fault; I also tried compiling with and without sb-thread on an older release of Alpine that uses musl 1.1, and no memory faults happened there
2022-06-03 13:19:04 <rbq> So, probably the problem is in the interaction of sb-thread and musl 1.2 on x86
2022-06-03 13:24:33 <durrendal> rbq: very interesting, I can't say I'm surprised sb:thread seems to be the cause of most problems lately. Do you have an MR open for it yet?
2022-06-03 13:26:42 <rbq> No
2022-06-03 13:27:25 <rbq> You can try it out first, it needs an explicit --without-sb-thread
2022-06-03 13:46:37 <durrendal> I'll give it a shot and if it works on my end too I'll make an MR for it.
2022-06-03 13:46:51 <rbq> Ok :)
2022-06-03 13:47:10 <durrendal> Thanks again by the way, seriously beyond thrilled to see sbcl working again
2022-06-03 13:48:21 <rbq> You're welcome, I've also been amazed by its speed (well...after looking at ecl take such a long time to compile sbcl)
2022-06-03 13:49:01 <rbq> Anyway, I actually used the sbcl 2.2.1 that was added to Alpine v3.12 to compile sb 2.2.5 for x86
2022-06-03 13:49:18 <rbq> It still works with edge
2022-06-03 13:49:29 <rbq> and is so much faster :)
2022-06-03 13:53:22 <durrendal> watching ecl compile sbcl is like watching paint dry haha. It works though
2022-06-03 13:54:03 <durrendal> I would love to switch over to building sbcl with sbcl, I know there's a few packages that are built that way, but I haven't a clue how to go about packaging for that use case
2022-06-03 13:54:46 <psykose> you would have a sbcl-bootstrap built with ecl i guess, then sbcl depends on sbcl-bootstrap and provides it itself
2022-06-03 13:54:58 <psykose> that sounds quite pointless though, it doesn't actually take very long, and it works
2022-06-03 13:56:24 <psykose> unless there is some Serious performance gain from it building itself afterward
2022-06-03 13:58:56 <durrendal> I actually don't know that there is a performance gain or not from building it that way
2022-06-03 13:59:01 <rbq> That's what I've been wondering too, but seeing as the sbcl built with ecl builds nyxt in around 5 minutes, probably not much
2022-06-03 13:59:15 <durrendal> sbcl building sbcl is much faster than ecl building it, but I guess we're building sbcl with ecl either way based on that workflow 
2022-06-03 13:59:25 <psykose> well yeah, has to start somewhere
2022-06-03 13:59:35 <psykose> and unless it's being rebuild 10x a day.. not much to gain
2022-06-03 13:59:47 <psykose> you can benchmark it for the latter case; run whatever sbcl benchmark there is
2022-06-03 13:59:56 <psykose> then change ecl-dev with sbcl, rebuild it, do it again
2022-06-03 14:00:06 <psykose> though make sure your rebuilding doesn't add more optimisations by accident :p
2022-06-03 14:00:41 <psykose> if it's literally '2x faster' somehow i guess it would make some sense
2022-06-03 14:01:59 <durrendal> I'll add it to the TODO list after I make sure all the rest of my packages are OK.
2022-06-03 14:02:04 <durrendal> I've been underwater too long
2022-06-03 14:59:43 <rbq> psykose: The pipeline for the Perl rebuild MR has succeeded for 4 archs, however now there is a merge conflict, does that mean I'll have to rebase and restart the pipeline all over again?
2022-06-03 15:00:36 <psykose> you can wait for this one to finish
2022-06-03 15:00:46 <psykose> no, doesn't really matter, the conflicts are just from things changing in the meantime
2022-06-03 15:01:17 <rbq> I've already had that happen once or twice
2022-06-03 15:01:50 <psykose> and it will keep happening :)
2022-06-03 15:02:47 <rbq> Anyway, what'll the next step be like after this?
2022-06-03 15:03:20 <psykose> dunno, i'll probably merge it at some point
2022-06-03 15:04:38 <rbq> Ok, and the merge conflicts can be solved at that point?
2022-06-03 15:06:37 <psykose> no, you have to solve them
2022-06-03 15:06:42 <psykose> well
2022-06-03 15:07:02 <psykose> i say that, but usually i just do it myself, because nobody knows how to solve git merge conflicts and breaks half the commits
2022-06-03 15:07:49 <rbq> Ok
2022-06-03 15:08:44 <rbq> I'm quite sure the other archs will pass the pipeline, so if you want me to try solving the merge conflict that just appeared now and restart the pipeline, let me know
2022-06-03 15:12:13 <psykose> i'm not sure why you have to solve anything to see the pipeline finish
2022-06-03 15:12:17 <psykose> it doesn't stop
2022-06-03 15:13:43 <rbq> The pipeline or the merge conflicts? :)
2022-06-03 15:14:28 <psykose> former
2022-06-03 15:15:48 <rbq> Ok, but just to check, it does start from the beginning every time I push something new, or is there a way to make it run only what's changed in the latest push?
2022-06-03 15:18:33 <psykose> former
2022-06-03 15:32:28 <rbq> Alright, I guess I'll wait for the current pipeline to finish
2022-06-03 16:37:37 <wej> https://about.gitlab.com/releases/2022/06/01/critical-security-release-gitlab-15-0-1-released/
2022-06-03 16:47:32 <ikke> wej: We've received the notification. 
2022-06-03 16:47:53 <ikke> We're still on 14.10, and most vulnerabilies either affect 15.x or EE features
2022-06-03 16:48:02 <ikke> But I'll deploy a fix soon
2022-06-03 16:58:59 <wej> ikke: alright, just wanted to make sure, you didn't miss it :)
2022-06-03 17:44:05 <donoban>  /j #remmina
2022-06-03 17:44:11 <donoban> :P
2022-06-03 21:30:08 <ikke> restarting gitlab for updates
2022-06-03 21:35:28 <ikke> done
2022-06-03 21:39:26 <psykose> didn't explode, amazing
2022-06-03 21:43:11 <craftyguy> \o/
2022-06-04 13:06:26 <andypost[m]> ikke: RV builder hangs again
2022-06-04 13:07:53 <ikke> Load average: 1100.00 1100.00 1085.57
2022-06-04 13:07:55 <ikke> :D
2022-06-04 13:11:27 <psykose> lol
2022-06-04 13:15:28 <ikke> Some CPU stall / lock
2022-06-04 13:16:14 <ikke> https://tpaste.us/rnvx 
2022-06-04 13:20:30 <ikke> andypost[m]: builder is back
2022-06-04 13:30:03 <skarnet> a monstrous load average like that generally points to D state processes, i.e. a hardware or kernel bug
2022-06-04 13:56:47 <ikke> skarnet: The dmesg output I pasted makes that very clear
2022-06-04 13:58:46 <skarnet> indeed
2022-06-04 14:56:39 <panekj> could someone merge !35029?
2022-06-04 14:59:23 <panekj> ty <3 psykose
2022-06-04 15:00:21 <ptrc> ty <3 psykose
2022-06-04 17:02:45 <jalberti> Hi! I came across https://nvd.nist.gov/vuln/detail/CVE-2022-30065, and I see corresponding https://security.alpinelinux.org/vuln/CVE-2022-30065, but I'm missing busybox on this list here https://security.alpinelinux.org/branch/3.16-main. Why is this CVE omitted in the "potentially vulnerable packages"? 
2022-06-04 17:03:32 <ikke> There is no CPE URI known yet
2022-06-04 17:03:45 <ikke> They have added it later
2022-06-04 17:05:12 <ikke> jalberti: fyi, nvd has several feeds. One feed per year, and one feed with new CVEs
2022-06-04 17:05:37 <ikke> The secfixes tracker automatically imports the new CVE feed, but not yet the yearly feeds
2022-06-04 17:07:04 <jalberti> ikke: thanks!
2022-06-04 17:07:18 <ikke> fyi, I'm importing the yearly feeds now, so it should appear soon
2022-06-04 17:09:49 <jalberti> I'm really surprised we as an industry have still not figured it out. It's a mess, shouldn't be that hard, but I guess it's an art not science. :)
2022-06-04 17:10:19 <panekj> Figure out what?
2022-06-04 17:15:11 <jalberti> Nothing specific to alpine, I'm just saying, each time I come across bad data, it's the same root cause, systems are not speaking with each other frequently enough, are not speaking the same language, etc. ... just like in real life, communication is hard, and not as precise as it could be. :)
2022-06-04 17:16:31 <ikke> jalberti: the issue is that different organizations have different priorities / goals
2022-06-04 17:17:09 <ikke> And as long as those goals are misalligned, these issues will remain
2022-06-04 17:18:28 <jalberti> dito
2022-06-04 17:19:30 <jalberti> ikke: thx, I see the list is updated now, and thanks for explaining the root cause
2022-06-04 17:19:32 <panekj> https://imgs.xkcd.com/comics/standards.png
2022-06-04 17:59:57 <ikke> Is the nvd.nist.gov tls cert expired?
2022-06-04 18:00:06 <ikke> "Websites prove their identity via certificates, which are valid for a set time period. The certificate for nvd.nist.gov expired on 1/30/2022."
2022-06-04 18:00:20 <panekj> yes
2022-06-04 18:00:22 <ikke> Sound like an old cert was deployed
2022-06-04 18:01:02 <panekj> old LE cert lol
2022-06-04 18:03:15 <ikke> Hmm, a serie of dnsmasq CVEs that have been disputed are still shown as possibly vulnerable on security.a.o
2022-06-05 13:48:03 <jingles> I've updated https://wiki.alpinelinux.org/wiki/Raspberry_Pi#Preparation with an extra option to enable USB on Pi Compute Module 4 with I/O board
2022-06-05 13:53:15 <ikke> 👍
2022-06-05 14:15:35 <jingles> Although having just done that, I have since found this:
2022-06-05 14:15:37 <jingles> https://github.com/raspberrypi/rpi-imager/commit/78f003fca7c5f9c3e7ffa432aeb6942940b5a6f3
2022-06-05 14:16:12 <jingles> "SDXC controller was not playing nice with rpiboot."
2022-06-05 14:22:32 <jingles> Although my fix seems to work for me, maybe a more robust solution would be to implement the above commit.
2022-06-05 14:24:30 <jingles> Is there a suitable place to raise that as an issue? I'm not 100% familiar with the project structure yet.
2022-06-05 14:49:56 <psykose> not sure where the commit would be implemented
2022-06-05 14:52:01 <psykose> our default config.txt for instance only loads the kernel, it doesn't set anything else; if you're referring to the [cm4] section and hotfixing something in there
2022-06-05 14:52:21 <psykose> as for everything else, it's part of the kernel config, and we try to not touch it from the default upstream one
2022-06-05 14:53:21 <psykose> one of the overriden lines in ours is `CONFIG_USB_DWC2=m`, which is related it seems, but that does not impose the requirement of using the overlay or anything
2022-06-05 14:53:21 <psykose> h
2022-06-05 14:53:23 <psykose> hm
2022-06-05 15:11:00 <jingles> Yeah, fair. I'm slightly out of my depth there as I'm still sussing this stuff out. More than anything, I just wanted to bring the cm4 USB issue to dev attention.
2022-06-05 15:13:42 <minimal> jingles: Alpine does not currently appear to set up any config.txt entries for cm3 or cm4 at all
2022-06-05 15:14:16 <minimal> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.arm.sh#L18
2022-06-05 15:14:39 <jingles> Shall I add an issue on aports?
2022-06-05 15:14:46 <psykose> why does this wiki page even recommend vc4-fkms-v3d for rpi4
2022-06-05 15:14:49 <psykose> tsk tsk
2022-06-05 15:16:54 <psykose> or recommended 128+ of gpu_mem
2022-06-05 15:17:51 <minimal> jingles: I guess you could open an issue for cm4 (and cm3 and pi02w) entries to be added to the config.txt
2022-06-05 15:18:11 <jingles> minimal: Will do
2022-06-05 15:18:30 <psykose> ah, thought we had a 02w already
2022-06-05 15:18:32 <psykose> guess not
2022-06-05 15:21:26 <minimal> psykose: actually after checking https://www.raspberrypi.com/documentation/computers/config_txt.html the "[pi0]" entry covers Zero, Zero W, Zero 2 W
2022-06-05 15:21:34 <psykose> ah, neat
2022-06-05 15:21:36 <minimal> confusing eh? lol
2022-06-05 15:22:16 <jingles> minimal: I will ignore the pi02w part in my issue then :)
2022-06-05 15:22:18 <psykose> ah, the 02 is 02w
2022-06-05 15:22:32 <minimal> also the samem doc is confusing as it says "[pi4]" covers CM4 but it also listed a "[cm4]" entry as well
2022-06-05 15:23:09 <minimal> and the "[pi3]" entry includes the CM3 and CM3+
2022-06-05 15:23:40 <jingles> minimal: That is really confusing
2022-06-05 15:24:22 <minimal> jingles: even with the above in mind I guess you should open an issue for a "[cm4]" to be added for the "dtoverlay=dwc2,dr_mode=host" entry
2022-06-05 15:24:31 <jingles> Sure
2022-06-05 16:06:06 <jingles> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13908
2022-06-05 16:06:59 <jingles> I would attack this myself, but I haven't set up the build environment yet
2022-06-05 16:07:12 <jingles> Doing that now
2022-06-05 16:07:40 <psykose> are there any drawbacks to dtoverlay=dwc2 for people that do not attach a usb/whatever i/o thing to the cm4
2022-06-05 16:08:18 <psykose> because if there are, i think it makes more sense for the defaults to work for the default device; nothing attached, and then to correctly document that if you add stuff you need to change it
2022-06-05 16:08:25 <psykose> i can't seem to find anything on that option for some reason
2022-06-05 16:10:54 <jingles> Yeah, I'd be happy with that if it's mentioned in the tutorial
2022-06-05 16:14:02 <jingles> Potential problems with dwc2
2022-06-05 16:14:03 <jingles> https://raspberrypi.stackexchange.com/questions/77059/what-does-dtoverlay-dwc2-really-do
2022-06-05 16:14:08 <jingles> I'm still reading
2022-06-05 16:15:22 <jingles> "In host mode performance will pale cf dwc_otg, hence it's only recommended for gadget mode." This is a bit vague, but doesn't sound promising to me
2022-06-05 16:51:19 <jingles> Right. I'm out. Catch you in the near future o/
2022-06-05 16:51:47 <jingles> I've updated the issue with your concern, psykose
2022-06-05 16:52:03 <psykose> noticed :) fwiw i have no idea what any of these tunables really do
2022-06-05 16:52:08 <psykose> and sadly i don't have a cm4 to test things with
2022-06-05 16:52:11 <psykose> just a regular pi4
2022-06-05 16:52:30 <psykose> have a great day!
2022-06-05 16:52:42 <jingles> ty ty you too
2022-06-06 00:14:01 <rbq> psykose: There's a merge conflict again in the Perl rebuild MR. Should I try solving it or wait for more and solve them all at once?
2022-06-06 00:14:12 <psykose> i would probably wait for more
2022-06-06 00:14:35 <psykose> i could just merge it, but you see, then i would also be responsible for breaking everything in aports :)
2022-06-06 00:14:40 <psykose> (because it probably will)
2022-06-06 00:14:56 <psykose> and i would rather wait for ncopa to come back from vacation and do it
2022-06-06 00:15:48 <rbq> Alright
2022-06-06 00:16:50 <rbq> I figured you were probably waiting for him or something, since he was the one doing previous Perl rebuilds
2022-06-06 07:08:10 <ncopa> good morning
2022-06-06 07:08:30 <ncopa> im back. what have i missed?
2022-06-06 07:25:44 <indy> Ariadne, thanks for 2.12.10 in edge :) will land apk 2.12.10 in 3.16?
2022-06-06 08:06:43 <psykose> ncopa: perl 5.36 which you should merge :p
2022-06-06 08:12:53 <rbq> Thanks for mentioning that, psykose :d
2022-06-06 08:44:05 <psykose> :)
2022-06-06 09:20:25 <ncopa> ok. will try have a look at it later today
2022-06-06 09:20:35 <ncopa> how did it go with ppc64le and binutils?
2022-06-06 09:24:47 <psykose> didn't find anything, i tried whatever outstanding ppc patches there were on the ml
2022-06-06 09:26:05 <psykose> the linux-lts 5.15.45 update removed CONFIG_EFI_STUB=y again, are you sure it's there without it
2022-06-06 09:26:18 <psykose> as for perl, it's !34890
2022-06-06 09:30:47 <ncopa> let me check the CONFIG_EFI_STUB thingy
2022-06-06 09:31:17 <ncopa> drats....
2022-06-06 09:35:18 <psykose> ncopa: oh, and wrt perl there was a zlib issue what was making some tests fail, and it looks like the zlib code was wrong
2022-06-06 09:35:22 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/blob/8cf49ef8b00d78e8cd8c08bf82d123237984f8f2/main/zlib/off_t.patch
2022-06-06 09:35:26 <psykose> (not committed yet)
2022-06-06 09:35:50 <psykose> as far as i could see z_off_t was being used as an off_t type but in musl this is always 64, so long was incorrect
2022-06-06 09:36:08 <psykose> (and we always have off_t anyway, so it should be fine like that)
2022-06-06 09:36:41 <psykose> description has the rest of the info
2022-06-06 09:37:18 <ncopa> has patch been sent upstream?
2022-06-06 09:37:24 <psykose> i wanted to ask you first :)
2022-06-06 09:37:43 <psykose> i assume for upstream they have a reason to not just use off_t (there is an ifdef path the defines it as off_t elsewhere, and this is some other path)
2022-06-06 09:38:03 <psykose> you can read the zconf file, it's not that big
2022-06-06 09:39:15 <psykose> https://github.com/madler/zlib/blob/master/zconf.h.in#L480
2022-06-06 09:39:26 <psykose> only with Z_SOLO, otherwise it's long
2022-06-06 09:46:09 <ncopa> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
2022-06-06 09:46:19 <ncopa> off_t is in posix
2022-06-06 09:46:38 <ncopa> this should be reported to upstream zlib
2022-06-06 09:47:04 <psykose> i guess i will just open an issue then, maybe zlib targets something non-posix :)
2022-06-06 09:47:26 <psykose> if that patch looks fine (it's in the perl MR) then there is no other comments from me
2022-06-06 09:47:44 <ncopa> the question is, was it always like this with musl? if not what introduced it?
2022-06-06 09:47:46 <psykose> without it checks won't pass/hang on a few things
2022-06-06 09:47:51 <psykose> mm
2022-06-06 09:47:54 <psykose> that i'm not sure about
2022-06-06 09:48:20 <ncopa> but this only affects 32bit architectures, right?
2022-06-06 09:48:29 <psykose> i assume something changed in new perl (Compress::Raw::Zlib) in .36 that makes it be more strict about this
2022-06-06 09:48:30 <psykose> yeah
2022-06-06 09:48:35 <psykose> long will be correctly 64 on 64
2022-06-06 09:49:23 <ncopa> I suspect that some change in configure script broke this
2022-06-06 09:50:29 <ncopa> this could be a security issue. int overflow 
2022-06-06 09:50:52 <psykose> maybe :) can't speak that far
2022-06-06 09:52:54 <ncopa> in either case, first step is to report it upstream
2022-06-06 09:53:08 <ncopa> then we can analyse what introduced it
2022-06-06 09:53:13 <ncopa> and how to properly fix it
2022-06-06 09:53:31 <psykose> it's always been that way
2022-06-06 09:54:48 <psykose> i'm not sure if it even interacts with off_t really; there's even a part of the api that lets you query the size of z_off_t it was compiled with
2022-06-06 09:54:55 <psykose> maybe this is more of a perl bug for not checking?
2022-06-06 09:56:10 <psykose> searching for stuff is hard
2022-06-06 09:58:29 <psykose> there's even stuff like
2022-06-06 09:58:32 <psykose> `return (z_off_t)pfile_in_zip_read_info->stream.total_out;`
2022-06-06 09:58:58 <psykose> and total_out there is 'uLong'
2022-06-06 09:59:12 <ncopa> seems like zlib is correct. at least during compile time, it will define  z_off_t off_t
2022-06-06 09:59:23 <ncopa> on armv7 that is
2022-06-06 09:59:59 <psykose> where does it define that? because the zconf.h header that other programs import, can only define it as long
2022-06-06 10:00:21 <psykose> which means that while it itself will define it as off_t, the header exposed will say long
2022-06-06 10:01:44 <psykose> or, rather, i'm not sure what even uses the zconf
2022-06-06 10:01:53 <rbq> Compress::Raw::Zlib defines Z_SOLO
2022-06-06 10:02:02 <rbq> psykose: Thanks for fixing the merge conflict :)
2022-06-06 10:02:07 <psykose> ah, it's included by zlib.h
2022-06-06 10:02:23 <rbq> This causes the first correct "#define z_off_t off_t" to be ignored
2022-06-06 10:02:37 <rbq> and instead the second "#define z_off_t long" is picked up by Compress::Raw::Zlib
2022-06-06 10:02:51 <psykose> oh i read it completely backwards, haha
2022-06-06 10:03:00 <psykose> i read it as ifdef
2022-06-06 10:03:01 <psykose> classic
2022-06-06 10:03:12 <psykose> i guess this is actually completely correct, and only programs that define Z_SOLO are broken
2022-06-06 10:03:28 <psykose> so, nothing is broken by this, and it's always off_t, except for maybe a random program that defines Z_SOLO for some reason
2022-06-06 10:03:41 <rbq> and only broken for 32-bit
2022-06-06 10:03:47 <psykose> yep, only 32-bit z_solo
2022-06-06 10:03:51 <psykose> but i guess it's still a report to make
2022-06-06 10:03:57 <psykose> how about you do it :)
2022-06-06 10:04:15 <ncopa> lib is correct
2022-06-06 10:04:15 <rbq> Report to zlib or Compress::Raw::Zlib?
2022-06-06 10:04:20 <ncopa> zlib
2022-06-06 10:04:24 <ncopa> ncopa-edge-armv7:~/aports/main/zlib (master)$ ./a.out 
2022-06-06 10:04:25 <ncopa> size of z_off_t: 8
2022-06-06 10:04:48 <psykose> yeah, now include zlib.h with Z_SOLO
2022-06-06 10:05:00 <psykose> gcc -DZ_SOLO ..; a.out
2022-06-06 10:05:41 <ncopa> ncopa-edge-armv7:~/aports/main/zlib (master)$ gcc -D Z_SOLO test.c && ./a.out 
2022-06-06 10:05:41 <ncopa> size of z_off_t: 4
2022-06-06 10:05:43 <ncopa> yup
2022-06-06 10:05:52 <ncopa> what is Z_SOLO in the first place?
2022-06-06 10:05:58 <psykose> i honestly cannot find a reference
2022-06-06 10:06:13 <psykose> but Compress::Raw::Zlib passes it for some reason
2022-06-06 10:06:25 <psykose> i don't know what it's supposed to mean, it changes a lot of stuff in the headersx
2022-06-06 10:06:35 <ncopa> according google: "Z_SOLO is used to compile and use zlib without the use of any external libraries. It is for use in embedded environments."
2022-06-06 10:06:39 <psykose> ah, right
2022-06-06 10:07:48 <psykose> so, i guess it doesn't even link to libc? in that case it would 'make sense'? but i'm not sure why it breaks the tests unless you also patch it to 64
2022-06-06 10:07:54 <psykose> i guess it really is a perl issue
2022-06-06 10:08:12 <rbq> Does it break the test on 64-bit?
2022-06-06 10:08:30 <psykose> you tell me
2022-06-06 10:08:32 <psykose> don't think so
2022-06-06 10:08:42 <rbq> From what I remember, it didn't
2022-06-06 10:09:08 <ncopa> Z_SOLO is undocumented
2022-06-06 10:09:49 <rbq> The tests for crc32/adler32_combine were only added to Compress::Raw::Zlib version 2.104
2022-06-06 10:10:03 <rbq> I think Perl has been on version 2.101 until Perl 5.36
2022-06-06 10:10:50 <rbq> I tried running the latest Compress::Raw::Zlib testsuite on previous versions of 32-bit Perl, and the same error occurs
2022-06-06 10:11:43 <rbq> It will also hang Perl on 32-bit ARM (I tried on armv7, and from what happened to the armhf builder, I'd say that happens there too)
2022-06-06 10:12:35 <rbq> crc32_combine will hang 32-bit Perl on ARM, adler32_combine just seems to give the wrong result
2022-06-06 10:14:41 <ncopa> "Changes in 1.2.5.2 (17 Dec 2011) ... - Add a ./config --solo option to make zlib subset with no library use"
2022-06-06 10:14:57 <ncopa> what does "no library use" mean?
2022-06-06 10:16:19 <ncopa> rbq> Compress::Raw::Zlib defines Z_SOLO
2022-06-06 10:16:22 <ncopa> where?
2022-06-06 10:16:27 <rbq> Configure.pl?
2022-06-06 10:16:42 <rbq> Oops, Makefile.PL
2022-06-06 10:17:15 <rbq> https://github.com/pmqs/Compress-Raw-Zlib/blob/master/Makefile.PL#L94
2022-06-06 10:17:21 <ikke> ncopa: welcome back :-)
2022-06-06 10:17:58 <ncopa> thanks!
2022-06-06 10:18:02 <psykose> indeed there is a WriteMakefile( DEFINE => "-DZ_SOLO ..
2022-06-06 10:18:18 <ncopa> i wonder why. i found this. not sure its related. http://madler.net/pipermail/zlib-devel_madler.net/2012-February/002809.html
2022-06-06 10:19:07 <ncopa> ok. i think it might be a bug in zlib after all. when -DZ_SOLO is used, z_off_t gets wrong with musl libc
2022-06-06 10:19:24 <ncopa> now, i dont know if --solo means build without libc, or what it really means
2022-06-06 10:23:01 <rbq> Maybe this can help: https://stackoverflow.com/questions/12930302 (it contains an answer by one of the authors of Zlib)
2022-06-06 10:23:06 <psykose> haha https://madler.net/pipermail/zlib-devel_madler.net/2012-February/002815.html
2022-06-06 10:23:09 <psykose> good old ML banter
2022-06-06 10:23:47 <psykose> 'one of the authors' indeed :)
2022-06-06 10:24:11 <psykose> shrug, i guess it is a bug in zlib, but it's also really weird for something to define this
2022-06-06 10:24:34 <ncopa> yup. i think its a bug in both
2022-06-06 10:24:35 <psykose> up to you ncopa, sounds equally ok to just patch the Makefile.PL to not pass it
2022-06-06 10:24:57 <psykose> and i guess one of us can open an issue too
2022-06-06 10:25:05 <ncopa> i think we should report it to both
2022-06-06 10:25:07 <psykose> yep
2022-06-06 10:25:24 <ncopa> psykose: care to help me with that?
2022-06-06 10:26:11 <psykose> i think rbq should do the honors as i don't know what perl is doing here; i'll go open one in zlib
2022-06-06 10:26:52 <psykose> although looking at it still i'm getting confused on why the tests fail, if indeed zlib is 'supposed to not use any external code', yet somehow fails these tests with the 'external' musl 64-bit off_t
2022-06-06 10:26:54 <psykose> blech
2022-06-06 10:27:19 <ncopa> sounds good to me. maybe rbq can help us report it to perl?
2022-06-06 10:28:56 <psykose> well, https://metacpan.org/dist/Compress-Raw-Zlib is just some persons library
2022-06-06 10:29:06 <ncopa> Compress-Raw-Zlib seems to ship a fork of zlib
2022-06-06 10:29:13 <psykose> (i thought it was part of perl but i was wrong)
2022-06-06 10:29:26 <ncopa> perl bundles some of those perl libs
2022-06-06 10:29:33 <ncopa> so you may be correct
2022-06-06 10:30:52 <rbq> Compress::Raw::Zlib contains a vendored zlib-src
2022-06-06 10:31:09 <rbq> which we are removing in the APKBUILD
2022-06-06 10:31:30 <ncopa> and perl contains a vendored Compress::Raw::Zlib
2022-06-06 10:31:59 <psykose> we remove the vendored zlib-src in perl, but not in perl-compress-raw-zlib
2022-06-06 10:32:16 <rbq> Yes, I was just about to say that
2022-06-06 10:32:17 <psykose> but afaik this same issue is present regardless if the -D is passed so it doesn't quite matter
2022-06-06 10:32:38 <ncopa> yup
2022-06-06 10:32:50 <ncopa> we should nuke the -DZ_SOLO from perl
2022-06-06 10:33:51 <rbq> Have a look at https://github.com/pmqs/Compress-Raw-Zlib/blob/master/Zlib.xs#L68
2022-06-06 10:34:08 <ncopa> i just saw that
2022-06-06 10:34:11 <rbq> "Use Z_SOLO to build source means need own malloc/free"
2022-06-06 10:34:33 <ncopa> which is kinda ridiculus in perl context
2022-06-06 10:34:40 <ncopa> i think perl should not use Z_SOLO
2022-06-06 10:35:06 <rbq> and it does seem to define some "own malloc/free" stuff behind the ifdef "AT_LEAST_ZLIB_1_2_5_2"
2022-06-06 10:36:39 <ncopa> it is calling safemalloc
2022-06-06 10:38:10 <psykose> also just checked real quick; the perl-compress-raw-zlib does indeed build actual zlib and statically links it into the .o
2022-06-06 10:38:29 <ncopa> and uses perl's safemalloc
2022-06-06 10:38:40 <psykose> yep
2022-06-06 10:38:46 <ncopa> might be the reason why they use Z_SOLO
2022-06-06 10:38:51 <ncopa> to override the malloc
2022-06-06 10:39:49 <ncopa> safemalloc may be either Perl_malloc or safesysmalloc
2022-06-06 10:40:29 <psykose> ah, and i see the reason stuff fails with the non-vendored one is because the zlib-compile-flags say z_off_t was 64, but it passes z_solo and then uses a 32-bit definition while using the system one
2022-06-06 10:40:39 <psykose> the more i stare at this the more i'm getting confused
2022-06-06 10:40:49 <psykose> but really is it even a zlib issue at this point, it's mixing two differently compiled ones
2022-06-06 10:43:32 <ncopa> yup
2022-06-06 10:46:07 <psykose> that github answer from madler even says you cannot mix the two
2022-06-06 10:46:17 <psykose> either compile with solo and always define it, or don't
2022-06-06 10:46:48 <psykose> weh, i guess it's just a perl issue, and we should nuke this definition and go also unbundle the standalone one
2022-06-06 10:47:08 <psykose> and report it to perl
2022-06-06 10:47:21 <psykose> s|github|stackoverflow
2022-06-06 10:47:42 <ncopa> https://src.fedoraproject.org/rpms/perl/blob/rawhide/f/perl.spec#_4252
2022-06-06 10:47:47 <ncopa> fedora also unbundle zlib
2022-06-06 10:49:46 <rbq> It seems Compress::Raw::Zlib has had problems with Z_SOLO before (here, on Windows): https://www.perlmonks.org/?node_id=955450
2022-06-06 10:53:33 <panekj> hi, ncopa, Go 1.18.3 was released, could you please merge go flags MRs in abuild so we can tackle that in go upgrade?
2022-06-06 11:08:30 <ncopa> panekj: will try have a look today. thanks
2022-06-06 11:18:45 <rbq> Are unversioned provides= no longer automatically chosen with apk-tools 2.12.10?
2022-06-06 11:32:05 <psykose> the only related commit since .9 is https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/3b013f458225c2ad8a0d96ec3eb3dde2533e0312
2022-06-06 11:32:20 <rbq> Yes, I'm looking at that now
2022-06-06 11:32:32 <psykose> and you should be getting an error it seems if something is wrong
2022-06-06 11:32:37 <rbq> But it doesn't say anything about versioned provides=
2022-06-06 11:32:54 <rbq> I'm comparing the difference between perl-test-tester and jbuilder
2022-06-06 11:33:25 <psykose> can you post something i can run to get the issue you have
2022-06-06 11:33:34 <rbq> Both are without provider_priority
2022-06-06 11:34:28 <rbq> Just `apk add -vi` perl-test-tester and jbuilder (separately)
2022-06-06 11:34:44 <rbq> jbuilder is provided by dune, and perl-test-tester by perl-test-simple
2022-06-06 11:35:38 <rbq> I looked at their APKBUILDs, perl-test-simple has provides="perl-test-tester" and dune has provides="jbuilder=$pkgver-r$pkgrel"
2022-06-06 11:35:41 <psykose> it installs fine?
2022-06-06 11:35:49 <psykose> oh
2022-06-06 11:35:53 <rbq> perl-test-simple errors out, while jbuilder autoselects dune
2022-06-06 11:35:56 <ncopa> rbq: i added a few comments to !34890
2022-06-06 11:36:00 <rbq> Sorry, perl-test-tester
2022-06-06 11:36:25 <psykose> it should select dune, it's the only provider
2022-06-06 11:36:29 <psykose> unless i'm missing something
2022-06-06 11:36:44 <rbq> provider_priority
2022-06-06 11:36:56 <rbq> Only provider without provider priority is no longer autoselected
2022-06-06 11:37:10 <rbq> if I'm reading the commit description right
2022-06-06 11:37:33 <psykose> yes but this only affects perl-test-tester which now fails, it doesn't seem to affect jbuilder?
2022-06-06 11:37:39 <psykose> unless i'm misunderstanding what you are saying
2022-06-06 11:37:54 <rbq> but it seems being versioned removes the need for provider priority
2022-06-06 11:38:30 <rbq> In the APKBUILD for perl-test-simple and dune: perl-test-simple has provides="perl-test-tester" (unversioned) and dune has provides="jbuilder=$pkgver-r$pkgrel"
2022-06-06 11:38:47 <psykose> ah, that's what you mean
2022-06-06 11:39:06 <psykose> i suppose it has that effect, somehow
2022-06-06 11:39:16 <psykose> seems fine to me, means nothing would be broken
2022-06-06 11:39:34 <psykose> we have a lot of provides=x=$pkgver without a provider_priority, would be quite funny if they all broke
2022-06-06 11:40:32 <rbq> So, how should I fix the tests that are now failing for the Perl rebuild due to perl-test-tester. Should I add a version to that provides=, or just change the checkdepends to the actual package (perl-test-simple)?
2022-06-06 11:41:36 <rbq> Only 1 package seems to depend on the virtual perl-test-tester, and that is perl-test-deep
2022-06-06 11:41:45 <psykose> i will just remove it
2022-06-06 11:43:52 <rbq> Remove the provides="perl-test-tester" from perl-test-simple, and change perl-test-deep to depend on perl-test-simple?
2022-06-06 11:46:43 <psykose> yep, and i already did that
2022-06-06 11:47:32 <rbq> Ok, thanks :)
2022-06-06 11:49:08 <psykose> ncopa: should i remove the vendored zlib from the standalone perl-compress-raw-zlib too?
2022-06-06 11:49:39 <rbq> How removing the -DZ_SOLO that ncopa suggested, are you including that too (or will I have to do it)...it seems the two of you are still discussing the $JOBS thing
2022-06-06 11:50:26 <rbq> About the standalone perl-compress-raw-zlib, perhaps it would be better if that was moved to a provides= in the main perl package and the standalone package removed?
2022-06-06 11:50:47 <rbq> Because without the vendored zlib, they would be...the same
2022-06-06 11:51:15 <psykose> you seem to have a point
2022-06-06 11:51:23 <psykose> i think arch does this? they have a huge provides= in the perl
2022-06-06 11:51:42 <psykose> https://github.com/archlinux/svntogit-packages/blob/packages/perl/trunk/PKGBUILD
2022-06-06 11:51:45 <rbq> Well, probably the standalone package could be upgraded without waiting for Perl (don't know how the update cycle for vendored CPAN mdules in Perl is like)
2022-06-06 11:51:48 <psykose> conveniently, we can also steal the numbers
2022-06-06 11:52:18 <psykose> well; i dunno, it's right there vendored into perl
2022-06-06 11:52:31 <psykose> if we don't devendor it (doesn't sound like a good idea), then really we're just keeping two all over the place
2022-06-06 11:52:42 <psykose> if everything works fine just with the perl ones, then maybe it's fine
2022-06-06 11:54:55 <rbq> Hmm, the one in perl gets installed to the core_perl directory whereas the standalone one goes into vendored_perl
2022-06-06 11:55:14 <psykose> i don't think that makes a difference for the importing
2022-06-06 11:57:27 <rbq> The @INC input order in `perl -V` shows vendor_perl before core_perl
2022-06-06 11:57:40 <psykose> yes, what i mean is that it still loads
2022-06-06 11:57:51 <rbq> and I've just tested it, if the standalone perl-compress-raw-zlib is installed, it gets loaded instead of the core_perl one
2022-06-06 11:59:30 <rbq> So, there might be a point for perl-compress-raw-zlib being upgradable faster than the one bundled in core Perl
2022-06-06 11:59:52 <ncopa> i think we should remove the bundled zlib in perl-compress-raw-zlib, and use the system onw
2022-06-06 12:00:57 <psykose> sure
2022-06-06 12:01:16 <psykose> done
2022-06-06 12:02:30 <rbq> Hmm, but on the other hand, once we've removed the bundled zlib in perl-compress-raw-zlib, there'd be one less reason to urgently upgrade it (bugs in the bundled zlib)
2022-06-06 12:11:21 <ncopa> yup
2022-06-06 12:11:55 <ncopa> something is broken in apk-tools i think
2022-06-06 12:12:04 <psykose> what now :)
2022-06-06 12:12:34 <ncopa> $ doas apk upgrade -U -a 2>&1 | tpaste
2022-06-06 12:12:34 <ncopa> https://tpaste.us/Z4Zz
2022-06-06 12:12:43 <psykose> yep
2022-06-06 12:12:46 <psykose> it's the new change from above
2022-06-06 12:12:57 <psykose> https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/3b013f458225c2ad8a0d96ec3eb3dde2533e0312
2022-06-06 12:13:10 <psykose> i can just fix all of these
2022-06-06 12:13:21 <psykose> ah
2022-06-06 12:13:25 <psykose> wait, it breaks cmd:?
2022-06-06 12:13:25 <ncopa> right, so my thought was that i delete those two:
2022-06-06 12:13:35 <psykose> kyua doesn't provide anything
2022-06-06 12:13:46 <psykose> that means this breaks anyone that adds anything with cmd: and it's from one package
2022-06-06 12:14:02 <psykose> or does it
2022-06-06 12:14:16 <ncopa> $ doas apk del ninja cmd:kyua 2>&1 | tpaste
2022-06-06 12:14:16 <ncopa> https://tpaste.us/lV1o
2022-06-06 12:15:14 <psykose> that is broken for sure
2022-06-06 12:15:17 <psykose> but also it's strange
2022-06-06 12:15:22 <psykose> if i add cmd:kyua it's broken
2022-06-06 12:15:32 <psykose> if i add something like cmd:mosquitto_sub (also only one provider) it works
2022-06-06 12:15:39 <psykose> i think it's broken for cmd: being the same as pkgname?
2022-06-06 12:15:55 <psykose> but either way this is not good
2022-06-06 12:25:17 <ncopa> hum. something else is broken
2022-06-06 12:27:15 <raspbeguy> hello, is it possible to use rsync URLs as alpine repositories ?
2022-06-06 12:33:23 <psykose> to use rsync to fetch only like one file at once?
2022-06-06 12:34:20 <raspbeguy> kind of
2022-06-06 12:34:36 <panekj> you can use rsync standalone but it won't work with apk
2022-06-06 12:34:44 <psykose> i mean conceptually that doesn't really make sense
2022-06-06 12:34:55 <raspbeguy> ok
2022-06-06 12:35:06 <psykose> you can rsync clone a mirror if you want, and then point it to the local path /path/rsyncclone and that would work
2022-06-06 12:35:13 <psykose> and i guess that 'used rsync for an alpine repository'
2022-06-06 12:35:19 <psykose> at the cost of cloning the entire mirror
2022-06-06 12:35:25 <raspbeguy> asking because I set a mirror on my NAS which has a rsyncd daemon already running
2022-06-06 12:35:51 <raspbeguy> guess I'll set a http server then
2022-06-06 12:36:26 <psykose> apk add darkhttpd; vi /etc/conf.d/darkhttpd (document_root); ..
2022-06-06 12:36:27 <psykose> :)
2022-06-06 12:37:50 <rbq> So, what should I do about the $JOBS thing...it seems $(nproc) is what abuild.conf sets JOBS to
2022-06-06 12:38:54 <ncopa> but you cannot guarantee that
2022-06-06 12:39:03 <psykose> we can and we do
2022-06-06 12:39:57 <ncopa> $ doas apk fix
2022-06-06 12:39:57 <ncopa>   Huh? Error reporter did not find the broken constraints.
2022-06-06 12:39:57 <ncopa> ERROR: unable to select packages:
2022-06-06 12:40:03 <ncopa> not sure whats broken on my system
2022-06-06 12:40:08 <ncopa> but somethign is broken
2022-06-06 12:40:16 <psykose> apkbuilds run only with abuild, abuild reads abuild.conf, default abuild.conf has it
2022-06-06 12:40:40 <psykose> i really don't see the point of guarding against someone changing the defaults, should we also add a formal parser for abuild.conf to make sure they didn't add anything silly in there? :p
2022-06-06 12:40:58 <panekj> we should change abuild.conf to abuild.yaml
2022-06-06 12:41:09 <ncopa> echo "" > /etc/abuild.conf
2022-06-06 12:41:24 <ncopa> or even rm /etc/abuild.conf
2022-06-06 12:41:28 <psykose> yeah, and that means you broke your abuild
2022-06-06 12:42:43 <psykose> do we check for REPODEST in abuild? no, it has to be set there
2022-06-06 12:42:45 <psykose> and so on
2022-06-06 12:43:42 <panekj> no? https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2803
2022-06-06 12:44:19 <psykose> apparently i am bad at grep
2022-06-06 12:44:25 <panekj> C:
2022-06-06 12:44:33 <ncopa> and you can override it? REPODEST=/tmp/something abuild ... ?
2022-06-06 12:44:38 <panekj> yes
2022-06-06 12:44:54 <panekj> but also https://gitlab.alpinelinux.org/alpine/abuild/-/commit/69aea2246288c37b7f2961d7a31983465eb925a5
2022-06-06 12:46:44 <panekj> imo, JOBS in abuild is fine, as preventive measure you can add check in abuild
2022-06-06 12:46:46 <ncopa> default config is just a suggestion. i think would be nice if abuild works without any config. but thats just my opinion
2022-06-06 12:46:53 <panekj> s/in abuild/in abuild.conf
2022-06-06 12:46:53 <alpine-meetbot> panekj meant to say: imo, JOBS in abuild.conf is fine, as preventive measure you can add check in abuild
2022-06-06 12:47:52 <panekj> ncopa: it's not really a suggestion if abuild uses it. it would be a suggestion if it was something like abuild.conf.example
2022-06-06 12:48:10 <psykose> then we should probably ${JOBS:=1} in abuild itself, and the same for the other variables
2022-06-06 13:10:54 <rbq> Ok, I see what goes wrong if $JOBS is not set...make runs infinite jobs if there's no argument to -j
2022-06-06 13:11:01 <psykose> ye
2022-06-06 13:11:21 <psykose> but we can also go add a single export into abuild, and poof.. it is never unset without `unset`, so..
2022-06-06 13:11:59 <psykose> `export JOBS=${JOBS:-1}`, feel free to wire me the million dollars :p
2022-06-06 13:13:50 <psykose> we define the specification of it, so i'm not sure what the issue would be
2022-06-06 13:14:09 <psykose> and the default would just be one, as would be expected if someone deleted the config
2022-06-06 13:20:41 <rbq> So, how about I delete the -j off the make and just let it use MAKEFLAGS (to avoid the infinite jobs problem), but leave 'TEST_JOBS=$JOBS' as it is, if TEST_JOBS is not set nothing as unexpected as infinite jobs happens
2022-06-06 13:21:01 <psykose> sure
2022-06-06 13:21:28 <psykose> ah but you see what if someone put "abc" into JOBS? that would fail, you need an if condition..
2022-06-06 13:21:41 <psykose> :p
2022-06-06 13:21:56 <rbq> Oh god
2022-06-06 13:42:42 <rbq> Ok, I think I'll use HARNESS_OPTIONS=j"$JOBS" instead of TEST_JOBS=$JOBS, it makes sure $JOBS is a number, and if JOBS is unset it gives it a default of 9
2022-06-06 13:43:34 <psykose> i was mostly trolling
2022-06-06 13:43:51 <psykose> and by mostly i mean entirely, i expect the users to not be idiots to some extent
2022-06-06 13:44:05 <panekj> expecting too much
2022-06-06 14:01:15 <ncopa> *shrug* im just expressing my opinion. if other package maintainers don't want it different, i won't argue
2022-06-06 14:01:58 <psykose> what i'm saying doesn't go against it, it's adding something to abuild so it works with no config
2022-06-06 14:03:22 <ncopa> rn im more worried about the apk upgrade failure. I cannot upgrade and I don't know how to fix it
2022-06-06 14:05:08 <psykose> well, you can start by renaming the things in world that got renamed
2022-06-06 14:05:12 <psykose> all the fonts are an easy candidate
2022-06-06 14:05:33 <psykose> removing fonts-base, removing makedepends
2022-06-06 14:05:53 <psykose> bsd-simple-themes also doesn't exist
2022-06-06 14:05:53 <psykose> etc
2022-06-06 14:05:59 <psykose> i think then it might just fix itself
2022-06-06 14:06:04 <psykose> not sure why it ends up in that state
2022-06-06 14:06:40 <panekj> shouldn't apk fix report about not existing package if it was renamed?
2022-06-06 14:07:10 <psykose> i don't think it does
2022-06-06 14:07:40 <psykose> i could be wrong as i didn't actually check, but a rename without provides= in my experience just refuses to do anything
2022-06-06 14:13:38 <psykose> rbq: also i don't think you need the off_t patch anymore really, but i could be wrong
2022-06-06 14:15:02 <rbq> Probably, but if as you say z_off_t is a off_t type then having it as long is not really correct as long just happens to have the same size as off_t
2022-06-06 14:27:22 <Ariadne> indy: after some testing
2022-06-06 14:29:27 <indy> Ariadne, today i tried use package from edge in 3.16 and works like a charm, installs from both repositories, basic (main, community) and jfrog
2022-06-06 14:31:08 <Ariadne> ok well it will be done when it’s done
2022-06-06 14:31:45 <indy> :)
2022-06-06 16:57:54 <andypost[m]> any idea why aarch64 CI is broken https://gitlab.alpinelinux.org/alpine/aports/-/jobs/739016
2022-06-06 16:59:46 <psykose> the mirror didn't sync yet
2022-06-06 17:00:13 <andypost[m]> thanks, so will wait
2022-06-06 17:02:13 <psykose> and fixed
2022-06-07 00:27:22 <rbq> Ok, ncopa, psykose, I have opened an issue at Compress::Raw::Zlib about z_off_t having the wrong size on 32-bit Alpine: https://github.com/pmqs/Compress-Raw-Zlib/issues/12
2022-06-07 00:27:34 <psykose> ah, much appreciated :)
2022-06-07 00:28:03 <rbq> Thanks, if it's not too late for you, maybe you could have a quick read and see if I've left out anything obvious
2022-06-07 00:28:39 <psykose> i just read the whole issue; seems correct to me
2022-06-07 00:29:59 <psykose> tis only 2something am
2022-06-07 00:30:01 <psykose> :)
2022-06-07 00:30:43 <rbq> Ah well...the time of the day for us computer people
2022-06-07 00:34:35 <rbq> Just to confirm, the off_t change to 64-bit everywhere was done at the same time as the time64 transition (that means this doesn't affect musl 1.1), right?
2022-06-07 00:37:16 <psykose> mm
2022-06-07 00:38:09 <psykose> no, 64 off_t was from the start
2022-06-07 00:38:26 <psykose> > musl does not support legacy 32-bit-off_t whatsoever., 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c, 2012
2022-06-07 00:38:42 <rbq> Ok, that probably explains why I couldn't find anything about off_t in the time64 page
2022-06-07 00:38:47 <psykose> aye
2022-06-07 00:39:18 <rbq> I was also looking at that commit :)
2022-06-07 00:43:05 <rbq> Anyway, I was just wondering if there are any other pages that have some explanation on the musl's off_t...as the Wiki FAQ I linked to uses the words "idiotic" and "nonsense"...probably not giving a very good first impression for those not already using musl
2022-06-07 00:43:18 <rbq> s/the//
2022-06-07 00:43:18 <alpine-meetbot> rbq meant to say: Anyway, I was just wondering if re are any other pages that have some explanation on the musl's off_t...as the Wiki FAQ I linked to uses the words "idiotic" and "nonsense"...probably not giving a very good first impression for those not already using musl
2022-06-07 00:43:35 <rbq> s/the //
2022-06-07 00:43:35 <alpine-meetbot> rbq meant to say: Anyway, I was just wondering if re are any other pages that have some explanation on musl's off_t...as the Wiki FAQ I linked to uses the words "idiotic" and "nonsense"...probably not giving a very good first impression for those not already using musl
2022-06-07 00:57:43 <psykose> if you think about it is quite idiotic though /s
2022-06-07 00:59:05 <panekj> picoro?
2022-06-07 01:02:52 <rbq> Hello, panekj
2022-06-07 01:03:07 <rbq> I don't really get the reference to 'picoro'
2022-06-07 01:03:57 <panekj> ah, musl wiki
2022-06-07 01:04:01 <panekj> nevermind then
2022-06-07 01:05:26 <minimal> panekj: he did write/modify some of the wiki pages in the past
2022-06-07 01:05:49 <panekj> but not musl wiki surely?
2022-06-07 01:06:40 <minimal> panekj: yeah from memory there was a bit of a wiki-edit-war between him and someone else last last year
2022-06-07 01:06:48 <minimal> s/last last/late last/
2022-06-07 01:06:48 <alpine-meetbot> minimal meant to say: panekj: yeah from memory there was a bit of a wiki-edit-war between him and someone else late last year
2022-06-07 01:07:08 <minimal> sorry, on the Alpine wiki I mean
2022-06-07 01:07:56 <panekj> yeah, I know, I've spite-modified wiki pages before to remove some of his content (:
2022-06-07 06:56:40 <ncopa> we need do something about our provides in aports: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10847#note_240569
2022-06-07 06:58:53 <ikke> I think it's also a documentation issue that needs to be solved 
2022-06-07 06:59:01 <ncopa> problem is that if there is an unversioned provider, apk will not make a selection for you to satisfy the dependency. this is by design
2022-06-07 06:59:15 <ncopa> yes, i think people dont understand how provides works
2022-06-07 07:00:24 <ncopa> so I wonder if we should change abuild to add the pkgver to provides, unless provider_priority is specified
2022-06-07 07:01:15 <ncopa> or simply error if no version or provider_priority was specified
2022-06-07 07:05:38 <fabled> No version provides is useful for virtual things. Like exim could provide mail-transport-agent without version
2022-06-07 07:06:02 <ncopa> but then you should set provider_priority?
2022-06-07 07:06:26 <ncopa> i mean, if provider_priority is unset, it defautls to 0, right?
2022-06-07 07:06:52 <fabled> Not necessarily. If package depends on mail-transport-agent it is user decision if he wants exim or postfix.
2022-06-07 07:07:18 <fabled> So it would be correct for APK to ask user make a decision
2022-06-07 07:07:42 <ncopa> but if provider_priority is unset apk-tools will give it same value as '0'?
2022-06-07 07:07:49 <fabled> Yes
2022-06-07 07:08:32 <ncopa> so, my thinking here is, that abuild can check that provider has either a version or a provider_priority
2022-06-07 07:08:45 <ncopa> if none of those are set, abuild can error out
2022-06-07 07:08:56 <ncopa> that way we force user to be explicity about the intention
2022-06-07 07:09:14 <ncopa> if you actually want end user to make the selection, then you must set provider_priority=0
2022-06-07 07:09:19 <ncopa> if that is the intention
2022-06-07 07:09:35 <fabled> That's one option yes
2022-06-07 07:10:17 <ncopa> the idea is to enforce the package maintainer to express the intent
2022-06-07 07:11:00 <ncopa> what other options do we have?
2022-06-07 07:15:07 <ncopa> if i understand correctly, if there are two provides, same name, different version:  provides="foo=1.0"  and provides="foo=1.1", then will apk pick foo=1.1?
2022-06-07 07:15:25 <ncopa> and if foo=1.0 is installed, it will upgrade to foo=1.1?
2022-06-07 07:17:17 <fabled> Subject to normal dependcy checking. E.g. if someone requires the older version it does not upgrade.
2022-06-07 07:17:23 <fabled> But yes
2022-06-07 07:19:47 <ncopa> right, then i understand correct. thanks
2022-06-07 07:26:45 <ncopa> thinking more about https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10810#note_215526
2022-06-07 07:27:11 <ncopa> i think it is kinda nice that apk picks the single provider if it only is one
2022-06-07 07:27:39 <ncopa> in the busybox' provides=/bin/sh case
2022-06-07 07:27:51 <ncopa> and there are 2 different repos with different versions of busybox
2022-06-07 07:28:29 <ncopa> could apk find out that the two provides are the same provide but with different version, and select the newest?
2022-06-07 07:28:49 <ncopa> instead of treating them as two different provides
2022-06-07 07:36:42 <fabled> what if the repository contains myshell with provides=/bin/sh, should apk then do busybox or myshell?
2022-06-07 07:39:50 <ncopa> in that case it should return the "note: please select one of the 'provided by' packages explicitly" error
2022-06-07 07:41:07 <ncopa> i find it slightly awkward that apk returns an error with "please select one of..." when there only is a single option
2022-06-07 07:45:33 <fabled> so the same mess follows if someone happens create package providing the same virtual name?
2022-06-07 07:46:28 <ncopa> good question
2022-06-07 07:47:57 <ncopa> what happens now if there is a dependency of foo, and myfoo provides foo (without version) and there is a package with name foo=1.0?
2022-06-07 07:50:08 <ncopa> it will pick the package with name foo, due to it as a version right?
2022-06-07 07:50:20 <fabled> the one with version get's autoselected (assuming the unversioned one does not get pulled becuse of some other dependency wanting it by name)
2022-06-07 07:52:18 <ncopa> > so the same mess follows if someone happens create package providing the same virtual name?
2022-06-07 07:52:21 <ncopa> I guess yes
2022-06-07 07:52:35 <ncopa> but you'd get the error with a list of two options
2022-06-07 07:52:45 <ncopa> and the error would show up less frequent
2022-06-07 07:53:43 <ncopa> so you think its better the error always shows up?
2022-06-07 07:54:29 <ncopa> i guess that also makes sense, you don't get surprises. you always get the error, or never, regardless of how many providers there are
2022-06-07 08:04:53 <fabled> on option in add / upgrade might be to add to world the package name that is the single provider, but i'm not sure if i like that or not
2022-06-07 08:05:24 <fabled> because then whether you get an error or not depends on what repositories you have configured
2022-06-07 08:06:15 <ncopa> yeah, i get that
2022-06-07 08:08:13 <ncopa> how do you generate the checksum for https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/test/provides.repo?
2022-06-07 08:11:06 <fabled> by hand, just generate random token, easiest to take existing and modify/random it (keep first two, and last two characters)
2022-06-07 08:13:28 <ncopa> I'd like to add a test for https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10847#note_240452
2022-06-07 08:50:17 <indy> Ariadne, i saw apk-tools 2.12.10 disappeared from edge
2022-06-07 09:38:28 <ncopa> indy: it was downgraded til we have fixed the upgrade issues
2022-06-07 09:52:37 <ncopa> hmpf.... i can no longer reproduce the huh? error
2022-06-07 10:06:36 <ncopa> ok, since I have no reproducer, im gonna upgrade apk-tools to 2.12.10 again til we have a new one. we need to fix this issue and cannot be done without a reproducer
2022-06-07 10:13:25 <ncopa> this is really annoying, adding back the unversioned lm_sensors does not trigger the huh? error anymore
2022-06-07 10:13:29 <ncopa> im out of ideas
2022-06-07 10:13:45 <ncopa> no idea why it happens or how to reproduce it
2022-06-07 11:24:25 <rbq> ptrc: Hello, have you taken another look at community/gnurl?
2022-06-07 14:30:48 <ncopa> still tryin to create a testcase for the huh? error, but i am not able to do so
2022-06-07 14:31:26 <ikke> Does it still happen with aports, or no longer there either?
2022-06-07 14:31:52 <ncopa> happens with aports. apk add sane-backends hplip-sane
2022-06-07 14:32:19 <ncopa> but when creating the testcase, it apparently installs
2022-06-07 14:32:26 <ncopa> so it must be something else in addition
2022-06-07 14:32:47 <ncopa> and common dependency, or similar
2022-06-07 14:33:39 <ncopa> doh
2022-06-07 14:33:41 <ncopa> im stupid
2022-06-07 14:34:17 <ncopa> got it working now, after banging my head into it
2022-06-07 14:34:36 <ncopa> i did copy paste of the index in test case
2022-06-07 14:34:46 <ncopa> the case i copied from had a 'k:1'
2022-06-07 14:34:55 <ncopa> which is provider_priority i guess
2022-06-07 14:35:08 <ncopa> so the provider_priority was set
2022-06-07 14:36:01 <ikke> aha
2022-06-07 14:36:39 <ncopa> so my original xfce4-sensors-plugin+lm_sensors would have caught it too
2022-06-07 14:37:22 <ikke> Do we still need to go over all aports for unversioned + unprioritized provides?
2022-06-07 14:37:35 <ncopa> depends on what we land on
2022-06-07 14:37:37 <ikke> ok
2022-06-07 14:38:39 <ncopa> fabled preferred that it always errors out, which prevents unexpected surprises if there are future packages with same provides
2022-06-07 14:38:48 <ncopa> or packages with same provides from other repos
2022-06-07 14:39:13 <ncopa> so you dont get an error when you add a repository
2022-06-07 14:39:18 <ncopa> you get the error on first apk add
2022-06-07 14:39:34 <ncopa> which kinda makes sense
2022-06-07 14:40:44 <ikke> Yeah, to me as well
2022-06-07 14:41:35 <ncopa> the downside is that the error message you get is: you need to select one of the listed providers:
2022-06-07 14:41:42 <ncopa> and there is only a single provider
2022-06-07 14:43:02 <ikke> In archlinux, the package manager would ask you which you want to install and allows you to select one with a number
2022-06-07 14:43:04 <ncopa> so you could argue that apk is stupid to do a selection when there is only a single option. a smarter apk would pick the only option available when there only is a single option
2022-06-07 14:43:07 <ikke> but I guess that does not really fit apk
2022-06-07 14:43:20 <ncopa> well, apk is non-interactive by design
2022-06-07 14:43:22 <ikke> yea
2022-06-07 14:44:05 <ncopa> i think fabled's suggestion is a more stupid and simple solution
2022-06-07 14:44:20 <ikke> That it always errors out?
2022-06-07 14:44:23 <ncopa> yeah
2022-06-07 14:44:47 <ikke> And I think it urges us to fix the issue when it happens :)
2022-06-07 14:44:55 <fabled> could adjust the error in the case there's only one provider to be more like "please add package X explicitly"
2022-06-07 14:44:57 <ikke> which I suppose should not be often
2022-06-07 14:45:33 <ncopa> fabled: yeah, that might be an idea. btw i have a testcase for you now for the error reporter
2022-06-07 14:47:37 <ncopa> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10847#note_240665
2022-06-07 14:48:40 <fabled> ncopa: thanks. i'll try to find a slot to fix the huh error
2022-06-07 14:50:28 <ncopa> meanwhile i think i'll work on abuild, to error out on unversioned provides without explicit provider_priority
2022-06-07 14:50:45 <ncopa> it will force the package maintainer to be explicit on the intention
2022-06-07 14:50:55 <ikke> yes, I think that would be good as well
2022-06-07 15:22:09 <Ermine> What can wrong with PATH_MAX on ppc64le ? https://gitlab.alpinelinux.org/Ermine/aports/-/jobs/739601
2022-06-07 15:23:13 <ikke> I think that's not defined in ppc64le
2022-06-07 15:23:46 <ikke> Ah, you need to include limits.h
2022-06-07 15:24:19 <ikke> Ermine: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/bridge-utils/fix-PATH_MAX-on-ppc64le.patch
2022-06-07 15:25:08 <Ermine> ikke: thank you
2022-06-07 15:27:04 <panekj> ncopa: any update on go/abuild stuff?
2022-06-07 15:28:03 <ikke> ncopa has been rather busy fixing things after an apk-tools upgrade
2022-06-07 15:28:40 <panekj> I know, but go was upgraded
2022-06-07 15:29:42 <ikke> I see
2022-06-07 15:31:14 <panekj> the MRs could be already merged anyways
2022-06-07 15:31:31 <panekj> abuild would just need a new release later
2022-06-07 15:31:50 <panekj> well, "later"
2022-06-07 15:32:08 <ncopa> which MR? i looked at the abuild MRs yesterday and got distractec by a simple MR
2022-06-07 15:32:18 <ncopa> which turned out to need some more time
2022-06-07 15:32:54 <panekj> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/142
2022-06-07 15:32:59 <panekj> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/143
2022-06-07 15:33:00 <panekj> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/134
2022-06-07 15:35:09 <ncopa> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/142 will not automatically be applied to the builders, due to we have changes in the config (i think)
2022-06-07 15:43:30 <nmeum> yes, at least that was the case the last time I pushed changes to /etc/abuild.conf
2022-06-07 21:05:25 <Behemoth> I was looking through my packages and found that quassel-core pulls in a ton of x11 and wayland dependencies. Could someone please move the UI libraries into it's own package?
2022-06-07 21:16:39 <psykose> sure, that's just because all the library parts are together
2022-06-07 21:50:05 <psykose> Behemoth: should be improved on edge once it rebuilds
2022-06-07 21:50:40 <Behemoth> Thank you
2022-06-07 22:49:21 <rbq> I see there's a Python upgrade too :)
2022-06-07 22:51:40 <psykose> isnt
2022-06-07 22:52:37 <rbq> Aren't you working on it?
2022-06-07 22:52:56 <psykose> you see nothing
2022-06-07 22:53:13 <psykose> :3
2022-06-07 22:53:23 <rbq> Perhaps I'm still dreaming then :d
2022-06-07 22:53:55 <rbq> Just wondering how that usually goes...so I can compare it with Perl
2022-06-07 22:54:12 <psykose> nothing happens
2022-06-07 22:54:26 <psykose> for these minor vers
2022-06-07 22:54:36 <psykose> for 3.11... every python module needs a rebuild
2022-06-07 22:54:41 <rbq> Ok
2022-06-07 22:54:43 <psykose> anything that places things in /usr/lib/python*
2022-06-07 22:54:56 <rbq> That's due to the *.pyc files, right?
2022-06-07 22:55:00 <psykose> location
2022-06-07 22:55:15 <psykose> /usr/lib/python3.10/site-packages/..
2022-06-07 22:55:17 <rbq> Oh...so the directory changes
2022-06-07 22:55:20 <psykose> python only loads from its own version
2022-06-07 22:55:20 <psykose> yea
2022-06-07 22:58:34 <rbq> Just saw the comment about Tkinter's pkgver needing to be synchronized with Python. What happens if there's a new Tk and Tkinter needs a rebuild?
2022-06-07 22:59:37 <psykose> pkgrel is separate
2022-06-07 23:00:31 <rbq> Oh, I must not be fully awake also...so Tkinter's pkgrel is bumped, and Python is happy :)
2022-06-07 23:01:14 <psykose> something something dreaming
2022-06-08 00:14:31 <Behemoth> Damn... turns out quassel still pulls in x11 and mesa somehow. Together with ffmpeg-dev and murmur.
2022-06-08 00:15:37 <psykose> nothing should pull in ffmpeg-dev
2022-06-08 00:15:48 <psykose> could you apk del it and see why it's there
2022-06-08 00:21:08 <psykose> as for libx11, it's pulled in by qt5-qtbase
2022-06-08 00:21:14 <psykose> because it pulls in.. xdg-utils
2022-06-08 01:06:43 <Behemoth> I meant to say that ffmpeg-dev, murmur and quassel-core pull in mesa and x11
2022-06-08 01:09:55 <psykose> none of those pull in anything from mesa
2022-06-08 01:10:28 <psykose> and you shouldn't be adding -dev things and expecting to not pull in things
2022-06-08 01:10:39 <psykose> and as for x11, it's caused only by that above reason, and i'll fix it shortly
2022-06-08 01:11:01 <Behemoth>   mesa: ffmpeg-dev quassel-core murmur
2022-06-08 01:11:01 <Behemoth> World updated, but the following packages are not removed due to:
2022-06-08 01:11:01 <Behemoth> # apk del mesa
2022-06-08 01:11:07 <Behemoth> Maybe I missunderstand this output
2022-06-08 01:12:45 <psykose> it's certainly very confusing output :) it's pulled in because of ffmpeg-dev being there at the same time
2022-06-08 01:15:16 <Behemoth> aah
2022-06-08 01:16:13 <psykose> (probably by some install_if somewhere and the 100 things ffmpeg-dev has)
2022-06-08 01:17:24 <psykose> the same does happen with murmur+ffmpeg-libs though
2022-06-08 01:19:42 <Behemoth> If I del ffmpeg-dev, qt5-qtbase-x11 and mesa get removed though.
2022-06-08 01:20:14 <psykose> yeah
2022-06-08 01:20:27 <Behemoth> finally some motivation to just learn how to use x264 with a muxer instead of pulling in all of ffmpeg...
2022-06-08 01:20:52 <Behemoth> That already was a pain because I need a dynamic crt ._.
2022-06-08 01:21:23 <Behemoth> Thanks for your help
2022-06-08 01:21:48 <psykose> you don't need the -dev for sure regardless
2022-06-08 01:21:51 <psykose> but the real reason here is like
2022-06-08 01:22:10 <Behemoth> I'm using libav
2022-06-08 01:23:16 <psykose> qt5-qtwayland has an install_if on wayland-libs-client, and wayland-libs-client is pulled in by ffmpeg-libs->libva, so it autoinstall qt5-qtwayland, which then pulls in the mesa parts
2022-06-08 01:23:40 <psykose> you can remove everything with a `apk add -t qt5-qtwayland`
2022-06-08 01:24:04 <psykose> ah, you're using it as a library, sure
2022-06-08 06:55:32 <psykose> nmeum: afaik !34493 will need someone to manually build rust on s390x with the patches to bootstrap it for us, will you do it or was that someone else
2022-06-08 06:56:02 <rbq> Hello, psykose
2022-06-08 06:56:12 <psykose> what's up
2022-06-08 06:56:26 <rbq> Any idea if !32894 is being considered for merging?
2022-06-08 06:56:55 <rbq> Because there's this bug: https://github.com/vim/vim/issues/10512
2022-06-08 06:57:47 <psykose> hmm
2022-06-08 06:57:56 <psykose> well, that only matters when we get to it
2022-06-08 06:58:00 <rbq> I've tested it, with Perl 5.36, --with-perlinterp=dynamic is not respected, and it's as if --with-perlinterp was passed instead
2022-06-08 06:58:10 <rbq> and vim links to libperl.so
2022-06-08 06:58:37 <psykose> indeed :)
2022-06-08 06:58:49 <rbq> Hopefully upstream can find a fix for it soon
2022-06-08 06:59:27 <rbq> (Btw, I just looked at vim's Github...and it seems a new version is tagged almost everyday, sometimes 2 versions are tagged in a day...never knew it was like that)
2022-06-08 06:59:50 <rbq> s/2 versions/more than 2 versions/
2022-06-08 06:59:50 <alpine-meetbot> rbq meant to say: (Btw, I just looked at vim's Github...and it seems a new version is tagged almost everyday, sometimes more than 2 versions are tagged in a day...never knew it was like that)
2022-06-08 07:00:35 <psykose> they tag every commit
2022-06-08 07:00:42 <rbq> Wow
2022-06-08 07:00:43 <psykose> (i have no idea why)
2022-06-08 07:00:47 <psykose> pcsx2 does the same
2022-06-08 07:00:47 <psykose> shrug
2022-06-08 07:00:55 <psykose> i mean, it doesn't really matter either way
2022-06-08 07:01:16 <rbq> So, how do we decide when to upgrade? When there's a security/bug fix involved?
2022-06-08 07:01:26 <psykose> pretty much
2022-06-08 07:01:31 <rbq> Ok
2022-06-08 07:01:33 <psykose> though funnily there's cves fixed only in edge
2022-06-08 07:01:40 <psykose> maybe i should just bump it in all the branches
2022-06-08 07:02:03 <psykose> also, time to see how much stuff explodes with perl 5.36
2022-06-08 07:02:04 <psykose> :)
2022-06-08 07:02:20 <rbq> You're going to merge it?
2022-06-08 07:02:30 <rbq> Oh wait, it's already done
2022-06-08 07:02:41 <rbq> Just saw #alpine-commits 
2022-06-08 07:05:04 <rbq> Thanks :)
2022-06-08 07:05:54 <rbq> and I just saw what happens when you link to a Github issue in the commit description
2022-06-08 07:09:27 <psykose> yep, the github issue gets pinged
2022-06-08 07:09:40 <psykose> i think being subscribed to the issue pings as well
2022-06-08 07:09:50 <psykose> it's quite neat, really
2022-06-08 07:10:57 <psykose> that also works for us, because we mirror to github, if you feel like adding those whenever :)
2022-06-08 07:20:14 <psykose> Behemoth: both issues should be fixed in edge post rebuild, and those should go away once that's done :)
2022-06-08 09:50:36 <donoban> hi, could someone tell me how to fetch 3.16-stable branch? My latest attempt: git fetch upstream :remotes/upstream/3.16-stable
2022-06-08 09:51:02 <donoban> lol, it worked
2022-06-08 09:55:55 <donoban> ow, now I can't push
2022-06-08 09:57:46 <psykose> from a fresh valid clone all you need to do is something like `checkout -b 3.16-yourthing 3.16-stable` and you don't have to manually do anything else to fork off that branch
2022-06-08 09:58:05 <psykose> and then you need to do the usual push -u origin .. to actually push it as always
2022-06-08 09:58:11 <psykose> not sure what state you ended up in
2022-06-08 09:58:27 <donoban> uhM
2022-06-08 09:59:29 <donoban> From donoban/aports:3.16-stable into alpine/aports:master   Change branches
2022-06-08 09:59:35 <donoban> it looks wrong
2022-06-08 10:00:30 <psykose> you have to manually change target branch
2022-06-08 10:00:38 <psykose> but also use an actual feature branch smh
2022-06-08 10:01:05 <donoban> I changed the target branch and now it thinks that there are 1133 new commits
2022-06-08 10:01:06 <psykose> (by manually i mean you have to go and select aports:3.16-stable every time, unless there's some magic i don't know of)
2022-06-08 10:01:21 <psykose> then that means your '3.16-stable' is not actually 3.16 stable
2022-06-08 10:01:38 <psykose> look at the log and compare to https://git.alpinelinux.org/aports/log/?h=3.16-stable
2022-06-08 10:01:55 <psykose> you probably created a 3.16-stable from master or something
2022-06-08 10:02:08 <donoban> that seems the problem
2022-06-08 10:02:41 <donoban> ok I'm gonna delete it and try again
2022-06-08 10:03:14 <psykose> branch -D 3.16-stable; git checkout -b 3.16-stable origin/3.16-stable
2022-06-08 10:03:15 <psykose> or something
2022-06-08 10:03:20 <psykose> assuming all the stuff is fetched fine
2022-06-08 10:03:59 <donoban> uhM
2022-06-08 10:04:13 <donoban> git checkout -b 3.16-stable origin/3.16-stable ends in another apprently copy of master
2022-06-08 10:05:42 <donoban> 7ad4ca6325 (HEAD -> master, upstream/master, upstream/3.16-stable, origin/3.16-stable) HEAD@{8}: pull upstream master: Fast-forward
2022-06-08 10:06:02 <donoban> looks that it pulled master into my 3.16-stable?
2022-06-08 10:07:02 <psykose> no idea, you tell me, based on that ( ->) even upstream/3.16-stable is 'master'
2022-06-08 10:07:28 <psykose> if i had ssh to your computer i would check, but i don't :3
2022-06-08 10:07:51 <panekj> super secret hug
2022-06-08 10:07:54 <donoban> hehe
2022-06-08 10:11:25 <rbq> psykose: Is there something going on with test-aa-notify.py of apparmor?
2022-06-08 10:11:35 <psykose> you tell me
2022-06-08 10:12:07 <rbq> I'm not the Python person :)
2022-06-08 10:13:22 <psykose> i'm not the python or apparmor person either
2022-06-08 10:13:22 <psykose> :3
2022-06-08 10:13:37 <donoban> yeah! I'm now at commit 2b8f2c1f66c75d5667b0c1932c115644a06cbc30 (HEAD -> 3.16-stable, upstream/3.16-stable)
2022-06-08 10:14:29 <rbq> but I found: https://sources.debian.org/patches/apparmor/3.0.4-2/upstream-commit-8a21472175501823303a8af270bd38a60ff4ac9c-test-suite-compatibility-with-python-3.10.patch/
2022-06-08 10:14:59 <rbq> and it looks...a bit different from our python-3.10-test-aa-notify.patch
2022-06-08 10:15:54 <donoban> ok, 
2022-06-08 10:16:25 <rbq> Ok, ours was added to the aports tree in December, while the Debian patch says it's from February
2022-06-08 10:16:45 <rbq> So, maybe there's more fixed stuff in their patch?
2022-06-08 10:17:05 <psykose> i mean, it passes on every other arch
2022-06-08 10:17:27 <rbq> Yes, that would make it even more mysterious
2022-06-08 10:17:56 <donoban> psykose: !35165 it's not very important but author changed it just for alpine
2022-06-08 10:18:26 <donoban> great thanks
2022-06-08 10:18:48 <psykose> i still have not slept
2022-06-08 10:19:08 <rbq> Wow, that's not good
2022-06-08 10:19:13 <donoban> uhM, what hour is there?
2022-06-08 10:19:20 <donoban> or what time*
2022-06-08 10:19:39 <rbq> 
ACTION stops bothering psykose

2022-06-08 10:19:49 <skarnet> psykose: new rule: nobody has merge rights on gitlab if they've been up for 16 hours or more :P
2022-06-08 10:19:49 <psykose> 12
2022-06-08 10:19:55 <psykose> mm
2022-06-08 10:20:00 <psykose> only 20 so far
2022-06-08 10:20:22 <donoban> hehe
2022-06-08 10:20:37 <psykose> and i have to pick someone up in 4 hours
2022-06-08 10:20:44 <skarnet> as in... drive?
2022-06-08 10:20:51 <psykose> public transport
2022-06-08 10:21:13 <donoban> world is safe
2022-06-08 10:21:14 <skarnet> oh, no big deal then, it's your brain
2022-06-08 10:22:07 <skarnet> but taking a nap right now and cramming 2 sleep cycles before you have to go would do you some good :P
2022-06-08 10:22:21 <psykose> maybe but those aren't very comfy usually
2022-06-08 10:22:38 <psykose> not a huge fan of the short scared-did-i-sleep-too-long naps
2022-06-08 10:22:49 <skarnet> that's what alarm clocks are for
2022-06-08 10:23:11 <psykose> yeah but a) hate those and b) but What If it was wrong ?? panic
2022-06-08 10:23:12 <panekj> alarm clocks are for people who can wake up to them
2022-06-08 10:23:54 <skarnet> I also hate alarm clocks, but when I need to sleep but be awake N hours with N < 8, they're useful
2022-06-08 10:24:07 <skarnet> s/awake N/awake in N/
2022-06-08 10:24:07 <alpine-meetbot> skarnet meant to say: I also hate alarm clocks, but when I need to sleep but be awake in N hours with N < 8, they're useful
2022-06-08 10:24:28 <panekj> my anxiety is my alarm clock, so I usually wake up on time myself
2022-06-08 10:24:42 <panekj> but it doesn't work all the time
2022-06-08 12:28:24 <Ermine> I want to make subpackages, but I only have 'make install'. Can I move stuff to subpackage dirs in package() ?
2022-06-08 12:28:44 <panekj> you can make separate function for subpackage and use amove
2022-06-08 12:30:16 <panekj> example: https://git.alpinelinux.org/aports/tree/community/wezterm/APKBUILD#n93
2022-06-08 13:02:59 <ikke> Ermine: you move things in the respective subpackage functions
2022-06-08 13:03:32 <ikke> amove like panekj suggested is one way to do it 
2022-06-08 13:03:39 <Ermine> panekj, ikke: thank you
2022-06-08 13:11:32 <psykose> it's actually preferred to install everything to pkgdir in package() like what you get now, and move it after
2022-06-08 13:11:47 <psykose> it doesn't really matter, but it easier to see the full install tree
2022-06-08 13:25:13 <ikke> And it being called split functions also make more sense that way 
2022-06-08 16:08:19 <Ermine> If package has plugins, how should I name their subpackages? $pkgname-plugin-$pluginname or $pkgname-$pluginname ?
2022-06-08 16:11:04 <ikke> I don't think there is any policy around that
2022-06-08 16:11:21 <ikke> For docker the maintainer chose docker-cli-<plugin>
2022-06-08 16:47:44 <Hello71> isn't it bad that a few thousand aports are broken because ninja (virtual): note: please select one of the 'provided by' packages explicitly; provided by: samurai
2022-06-08 17:07:56 <Ariadne> Hello71: yes, but it is easily fixed
2022-06-08 17:11:15 <Ariadne> ikke: i wonder how hard it would be to make melange support your apkbuild parser
2022-06-08 17:56:37 <pabloyoyoista> ikke: is there any chance you can have a look at the open MR for appstream in infra? Should fix some issues and provide support for v3.16
2022-06-08 19:01:27 <ikke> Ariadne: What would melange need?
2022-06-08 19:01:40 <ikke> pabloyoyoista: I'll try to look at it, sorry, I've been a bit busy
2022-06-08 19:04:56 <pabloyoyoista> Thank you ikke! It's no issue if it is delayed, I just don't want it to totally sink in the backlog :D
2022-06-08 20:37:23 <ikke> Ariadne: what kind of API do you expect?
2022-06-08 20:38:12 <ikke> Ariadne: Right now I basically just expect an io.Reader with the contents of an APKBUILD, and return a struct with the metadata
2022-06-08 21:48:44 <Ariadne> ikke: that seems fine, we would need the shell script parts too i guess
2022-06-08 21:49:51 <ikke> What do you mean with the shellscript parts?
2022-06-08 21:50:49 <ikke> The interpreter is an existing go module
2022-06-08 21:51:06 <ikke> https://pkg.go.dev/mvdan.cc/sh/v3@v3.5.1/interp
2022-06-08 22:34:42 <Ermine> I have a bunch of "ar: `u' modifier ignored since `D' is the default (see `U')". Can I ignore them?
2022-06-08 22:50:53 <Ermine> And does openrc support extra commands with dashes?
2022-06-09 02:32:08 <psykose> you mean like `service start ..`?
2022-06-09 02:32:13 <psykose> and those warnings don't matter
2022-06-09 02:46:43 <rbq> ptrc: Just wondering, have you taken another look at gnurl?
2022-06-09 02:47:15 <ptrc> i don't remember, sec
2022-06-09 02:47:52 <ptrc> ah, it was the "they get tests from curl but remove random stuff" case..
2022-06-09 02:48:38 <psykose> ptrc: 🥺
2022-06-09 02:48:54 <rbq> Yes, it seems the failing test is also related to some directory they removed
2022-06-09 02:49:37 <rbq> psykose: Should be !34480
2022-06-09 02:49:58 <psykose> i'm just trolling her because she is next to me
2022-06-09 02:50:06 <rbq> Oh...
2022-06-09 02:50:18 <rbq> So, she was who you picked up yesterday?
2022-06-09 02:51:48 <psykose> yeah
2022-06-09 02:54:01 <ptrc> rbq: thanks for the variable hint; it seems to work locally, so i pushed it and i think the mr is ready now
2022-06-09 02:54:10 <rbq> You're welcome :)
2022-06-09 04:52:31 <craftyguy> psykose: is !31848 still blocked? it's not clear by your latest comment there
2022-06-09 04:53:31 <panekj> psykose: smh
2022-06-09 04:54:18 <boomanaiden154> The milestone got changed to 3.17, so I think it won’t get merged until that release cycle comes up.
2022-06-09 04:54:32 <boomanaiden154> Not totally sure though.
2022-06-09 04:54:44 <craftyguy> uh
2022-06-09 04:55:19 <ikke> That's not necessarily what the milestone means
2022-06-09 04:55:21 <craftyguy> that seems like a long time to hold off on upgrading mesa, just because some folks might have some old gpus
2022-06-09 04:55:44 <panekj> It might be merged on edge any time
2022-06-09 04:57:45 <ikke> We are as a matter of fact in the 3.17 release cycle
2022-06-09 05:06:13 <psykose> well that's the point, we can't upgrade it because some folks have old gpus
2022-06-09 05:06:29 <psykose> so either we need to drop the entire alpine x86 port, or we need to find out how to package mesa-amber correctly
2022-06-09 05:06:37 <psykose> and as someone who does not have 'old gpus' someone else can figure that out
2022-06-09 05:07:18 <psykose> gallium only support i915+ on the intel side, and the pentium4 baseline goes below that
2022-06-09 05:23:13 <sam_> we did it where amber depends on some bits from mesa proper still
2022-06-09 05:23:18 <sam_> i don't know the ins and outs but matt's a mesa dev so i'm assuming it's for a good reason
2022-06-09 05:32:08 <psykose> i'm not sure what you mean, i thought amber is just the (entire) 21.x tree, and they don't really coexist
2022-06-09 05:34:02 <psykose> i know there's some -Damber flag that 'does stuff' but from a packaging perspective they are providing the same files in the same locations, so that doesn't really help
2022-06-09 05:34:29 <psykose> unless.. i can build the 21.x amber drivers, and move only the /usr/lib/dri* files provided by amber, and delete everything else and keep the 22.x ones
2022-06-09 05:34:38 <psykose> that would certainly be easy
2022-06-09 05:35:22 <psykose> oh, right, they get an _amber suffix
2022-06-09 05:35:23 <psykose> hm
2022-06-09 05:37:00 <psykose> i guess the only real conflicts are the osmesa/gbm etc
2022-06-09 06:14:36 <psykose> oh, the suffix seems to only be with glvnd
2022-06-09 06:16:14 <psykose> so.. without glvnd do you provide the libGL from 22.x? or do you need just a literal second mesa package
2022-06-09 06:19:28 <sam_> i think we always do glvnd now
2022-06-09 06:25:39 <psykose> i guess that would work to 'change' to libglvnd but it would have near 0 purpose aside from.. this
2022-06-09 06:25:40 <psykose> meh
2022-06-09 06:35:00 <orbea> sam_: i wish it didn't force that
2022-06-09 07:30:08 <dhruvin__> I see that the replaces field allows me to overwrite (conflicting) files of an installed package when I installed a new package. But when uninstalling that package, the said "conflicting" files won't get back.
2022-06-09 07:30:47 <dhruvin__> I managed to use pre-install and post-deinstall to get those conflicting files back. But is it a correct way? Or is there a better way using APKBUILD that I may be missing?
2022-06-09 07:33:26 <dhruvin__> To give you an example, I am writing a custom package that modifies /etc/xdg/waybar/config (to give themed look, among other things). I can use replaces field to overwrite it. But I want the default /etc/xdg/waybar/config file back when user deletes my custom package.
2022-06-09 07:34:58 <ikke> that's not a use case that apk itself supports 
2022-06-09 07:36:20 <ikke> It requires the user to run apk fix <pkg> to restore the files 
2022-06-09 07:37:36 <ikke> And one thing sgoy should take into account is that if the user modified the config themselves, installing your package would not overwrite the config but install it as an .apknew file 
2022-06-09 07:45:54 <dhruvin__> oh, I didn't test that user modified file case. thanks for the heads up and suggestions.
2022-06-09 08:12:35 <kunkku> does anyone else suffer from xfce4-session hanging on startup?
2022-06-09 08:25:41 <kunkku> v3.16 works, edge does not
2022-06-09 08:34:07 <kunkku> seems to be caused by today's libx11 update
2022-06-09 08:36:22 <sam_> possibly https://bugs.gentoo.org/841857 / https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157
2022-06-09 08:41:38 <kunkku> it's odd that it works with 1.8 but not 1.8.1
2022-06-09 08:41:59 <psykose> 1.8.1 adds a single additional lock thing that can be disabled, but these issues seem unrelated
2022-06-09 08:43:08 <psykose> you can try --disable-thread-safety-constructor and see if that alone fixes it
2022-06-09 08:46:42 <kunkku> seems to work
2022-06-09 08:47:10 <psykose> epic
2022-06-09 08:48:00 <kunkku> readme says: "This may expose bugs in clients which did not follow documented rules for calling libX11 functions."
2022-06-09 08:48:25 <psykose> aye, though it's not surprising all of xfce is a pile of bugs
2022-06-09 08:48:26 <kunkku> so I assume this is the case for xfce
2022-06-09 08:48:39 <psykose> pushed the disable so -r1 should be fine
2022-06-09 08:51:11 <diestl> Greetings! Hopefully on topic: The default_dev (https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1605) function 
2022-06-09 08:54:00 <diestl> Copies all .so files out of {pkg}/lib into the -dev subpackage.  Aren't those required for running the original application?  As I am typing this I am realising that this is probably a static linking thing right?
2022-06-09 08:54:45 <diestl> Sorry for the broken up messages, my enter key is extra sensitive today it seems
2022-06-09 09:36:40 <dhruvin__> is there a way to execute `apk fix somepackage` while running inside `someotherpackage.post-deinstall`? i.e. to acquire lock while running a deinstall script? if not, how should I automate running apk fix after deinstall of some other package?
2022-06-09 09:44:37 <psykose> no, the .so is usually a symlink to the actual library
2022-06-09 09:44:49 <psykose> those are .so.1 or whatever
2022-06-09 09:44:51 <psykose> depends
2022-06-09 09:45:31 <PureTryOut> So uh, I have things failing to build because `/usr/include/stdio.h` gives me permission denied. The file however has 644 permissions and the `/usr/include` folder (obviously) has 755
2022-06-09 09:46:22 <PureTryOut> How can this happen?
2022-06-09 09:47:50 <PureTryOut> Oh wut no `/usr/include` has 644 for some reason, how the hell did that happen lol
2022-06-09 09:48:33 <PureTryOut> Still in abuild rootbld that is still happening 🤔
2022-06-09 10:08:07 <omni> !35184 !35196
2022-06-09 10:08:22 <rbq> Hi, omni
2022-06-09 10:08:42 <omni> \o
2022-06-09 10:09:10 <rbq> Do you check your personal merge requests?
2022-06-09 10:10:14 <omni> rbq: hmm.. something in particular?
2022-06-09 10:11:24 <rbq> Not really, just some OCaml stuff :)
2022-06-09 10:13:50 <diestl> @psykose so the intent is that the symlink is in the -dev package but the actual shared object is still in the main package?  Why is that desirable?  I'm not trying to criticise of course, just trying to understand the convention.  In my particular case I either have to install the gdal-dev package to get the single /usr/lib/libgdal.so or create the symlink myself, both of which seem kind of undesirable.
2022-06-09 10:14:08 <diestl> I would expect that the .so.* files would be in -dev also, or that all the .so* files are in the main package I guess
2022-06-09 10:17:48 <ikke> diestl: In general, applications link to the *.so.* files
2022-06-09 10:17:55 <ikke> but when linking, it needs the *.so file
2022-06-09 10:19:21 <PureTryOut> Huh it just happened again, `/usr/include` went chmod 644. What the hell
2022-06-09 10:30:18 <PureTryOut> Ah it's a faulty package I was messing around with, awesome...
2022-06-09 10:33:46 <diestl> ikke: Thanks for that!  Apparently I had explicitly configured django to look for /usr/lib/libgdal.so instead of letting it discover libgdal.so.* by itself.  Not that that matters because it turns out django doesn't even support the version of gdal shipped with alpine 3.16, which is why any of this came up as an issue in the first place.  This conversation has easily saved me hours/days of frustration, thank you.
2022-06-09 10:34:54 <ikke> diestl: you're welcome
2022-06-09 11:57:28 <Hello71> "06:16 <psykose> so.. without glvnd do you provide the libGL from 22.x? or do you need just a literal second mesa package" i think that should work now, but not sure it is "supported"
2022-06-09 12:44:38 <Piraty> file conflict. https://termbin.com/zf8r , caused by dbd90b52ccfb3303c44e6d573a6b9f842a981448
2022-06-09 13:02:37 <Piraty> pabloyoyoista: ^
2022-06-09 13:59:57 <libredev> Is alpine secure enough to run it on server ?
2022-06-09 14:03:57 <durrendal> libredev: I use it on all of my personal infrastructure, and have plenty of actual production servers at work that run Alpine in containers and on bare metal. It's just like any other linux distro, make sure to tweak your configurations
2022-06-09 14:04:36 <libredev> ok do u have any guides for server
2022-06-09 14:07:45 <durrendal> I typically use the NIST checklists as a baseline, they don't have one specific to Alpine that I know of, but configuration of a service is more or less the same across distros. The difference being there's no Selinux or Systemd in Alpine, that is to say, this isn't a one to one guide on securing an Alpine box, but might point you in the right direction,
2022-06-09 14:07:47 <durrendal> https://ncp.nist.gov/checklist/909
2022-06-09 14:09:40 <libredev> ok thanks
2022-06-09 14:16:28 <Piraty> libredev: there are several tools to audit system runtime config, like checksec.sh or lynis, ltp
2022-06-09 14:17:16 <Piraty> cis-cat benchmarks are useful at times, but not in good shape in my experience
2022-06-09 14:29:17 <libredev> can i install system without non free blob.
2022-06-09 15:17:31 <Piraty> likely depends on your hardware
2022-06-09 16:24:16 <Piraty> doesn't alpine maintain a service detecting file conflicts across packages ?
2022-06-09 17:05:01 <ikke> No, not at the moment 
2022-06-09 18:46:03 <omni> rbq: like coq and ocaml-yojson?
2022-06-09 18:47:02 <omni> I have a few MRs, some pretty stale, occationally I take time to go through them and see what I can do
2022-06-09 18:48:05 <omni> I don't mind if anyone would pick up any of what I may have there
2022-06-09 23:56:07 <rbq> omni: Sorry I didn't clarify what I meant...it is the merge requests under omni/aports not alpine/aports
2022-06-10 02:51:39 <rbq> psykose: Seems like the aarch64 CI for scryer-prolog is stuck at "Installing rust-stdlib". Does it usually take this long?
2022-06-10 02:51:59 <psykose> no, just hung
2022-06-10 02:52:04 <rbq> Ok
2022-06-10 04:08:21 <psykose> ddevault: fya i bumped jinja2 again, only found ~3 things in aports that were incompatible and fixed them; just a heads up if you were using something that wasn't compatible from elsewhere
2022-06-10 07:11:34 <psykose> sam_: do you know of what they changed in llvm14 for the cmake llvm_include_dirs? they are llvm_install_prefix/include in both cases, but in 14 they make the prefix /usr instead of the actual /usr/lib/llvmXX root, so whem something uses LLVM_INCLUDE_DIRS via find_package(LLVM) in cmake they get a /usr/include which obviously has nothing correct in it
2022-06-10 07:14:23 <ddevault> thanks psykose
2022-06-10 07:14:39 <ddevault> I've been gradually working on getting my end up-to-date, but we only ship alpine stable so it's not an issue
2022-06-10 07:14:47 <psykose> ah, sure thing :)
2022-06-10 07:17:16 <sam_> huh! so I remember we had a bit of fuss about the LLVM_ENABLE_RUNTIMES stuff but that's more about splitting up the build (and then it broke more: https://github.com/llvm/llvm-project/commit/5c4cf01f47da35816a252c4656b36404b4b8615c)
2022-06-10 07:17:27 <sam_> i'm guessing we weren't affected because we set CMAKE_INSTALL_PREFIX=/usr/lib/llvmXX
2022-06-10 07:17:33 <sam_> and we move the stuff out as needed?
2022-06-10 07:17:40 <sam_> or am i misunderstanding
2022-06-10 07:24:27 <psykose> we set the same
2022-06-10 07:25:09 <psykose> it's CMAKE_INSTALL_PREFIX=/usr/lib/llvm14.. and then in cmake/LLVMConfig.cmake it's https://img.ayaya.dev/CTKipd6PdJl6 afterward
2022-06-10 07:25:19 <psykose> (that makes it /usr? unless i am bad at cmake)
2022-06-10 07:26:04 <psykose> and yes, i also noticed the completely broken runtimes stuff without a full llvm checkout.. not sure how you are supposed to use a compiler-rt+llvm-base tarball to actually build it without the 'deprecated' config, do they want everyone to clone full llvm tree
2022-06-10 07:27:34 <psykose> if you want the specific build it's this https://gitlab.alpinelinux.org/alpine/aports/-/blob/1863b561bd1f385cfb8a68643408baef1d5f2f0c/main/llvm14/APKBUILD
2022-06-10 07:28:30 <sam_> ah, sorry, I was looking at clang, and not llvm
2022-06-10 07:35:01 <sam_> the cmake stuff does weird things to try figure out where it is and calculates paths based on it (looking at /usr/lib/llvm/14/lib/cmake/llvm/LLVMConfig.cmake for me)
2022-06-10 07:35:05 <sam_> we don't install the symlink though
2022-06-10 07:35:16 <sam_> i'm guessing some packages (maybe all) pick up your symlink first
2022-06-10 07:35:24 <sam_> then with that "find the root of where i am" logic in the .cmake, they conclude /usr/include?
2022-06-10 07:37:15 <psykose> ah.. yeah, /usr/lib/llvm14/lib/cmake/llvm -> ../../../cmake/llvm14, then 3 more up is usr/include
2022-06-10 07:37:16 <psykose> weh
2022-06-10 07:37:42 <psykose> not sure how to fix that one
2022-06-10 07:38:03 <psykose> and just now i notice CLANG_INCLUDE_DIRS has been the same /usr/include incorrectly for a while too, hah, but most things are not broken by that i don't think
2022-06-10 07:39:43 <psykose> yeah, clang13 has the same 3x get_filename_component in it, has for a while, for llvm it's only now since 14
2022-06-10 07:42:19 <psykose> i assume the memes around line 200 of moving stuff around are what break this
2022-06-10 07:43:26 <sam_> i'm wondering what happens if that gets dropped; llvm stuff should know to call llvm-config anyway i think but i might be missing something
2022-06-10 07:44:04 <psykose> yeah; everything that uses llvm-config already works
2022-06-10 07:44:16 <psykose> and things that used cmake.. used to work, and will instead go from being broken now to working again
2022-06-10 07:44:45 <psykose> so all this will break is.. things that hardcode /usr/include/llvmXX ?
2022-06-10 07:45:01 <psykose> i will rebuild basically everything anyway so i will find out
2022-06-10 07:45:06 <sam_> let's try it
2022-06-10 07:45:09 <psykose> thanks for the pointer
2022-06-10 07:45:11 <sam_> my gut is there's either none of those or they're junk
2022-06-10 07:45:17 <sam_> np, let me know what happens!
2022-06-10 07:46:27 <psykose> also do you have an idea for why clang cmake include dir is also /usr/include? qt-creator tries to build against something from llvm/ but only has clang_include_dirs in the link thing, so either it's wrong and assuming stuff incorrectly, or we have an error for clang as well
2022-06-10 07:46:56 <psykose> given the usual clang includes are indeed /usr/include/clang and work with <clang/*> i assume it's qt-creator being dumb
2022-06-10 07:47:40 <sam_> https://github.com/alpinelinux/aports/blob/master/main/clang/APKBUILD#L65 
2022-06-10 07:47:58 <sam_> what's the deal w that
2022-06-10 07:48:28 <sam_> oh i guess clang isn't parallel installable 
2022-06-10 07:48:32 <sam_> i would not be surprised if some layout thing gets confused by one of them being in a different prefix maybe
2022-06-10 07:48:39 <sam_> qt-creator is always a pain though so you might just be right there and i'm overthinking
2022-06-10 07:49:02 <sam_> let me look
2022-06-10 07:49:25 <sam_> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-qt/qt-creator/qt-creator-6.0.0.ebuild#n181 LOL
2022-06-10 07:49:33 <sam_> ok yeah it's qt-creator being qt-creator
2022-06-10 07:50:29 <sam_> (I think)
2022-06-10 07:50:41 <psykose> hehe
2022-06-10 07:51:05 <psykose> yeah, that's the exact fix for the plugin_clangformat
2022-06-10 07:51:06 <psykose> :)
2022-06-10 07:51:09 <psykose> neat
2022-06-10 08:08:51 <psykose> ah, without a /usr/lib/cmake/llvm it can't find llvm at all; and adding just a singular `ln -sfv /usr/lib/llvm14/lib/cmake/llvm /usr/lib/cmake/llvm` has the exact same issue as before
2022-06-10 08:08:56 <psykose> was there some other way to massage cmake
2022-06-10 08:12:40 <sam_> you can set LLVM_ROOT_DIR but i don't think you'll like doing that everywhere; is an llvm-config on PATH?
2022-06-10 08:15:46 <psykose> it is, yeah
2022-06-10 08:16:01 <psykose> /usr/bin/llvm-config -> ../lib/llvm14/bin/llvm-config*
2022-06-10 08:16:21 <psykose> note that i'm pretty sure the lldb/whatever things don't use that but just raw cmake find_package
2022-06-10 08:19:35 <psykose> lld/lldb/openmp all fail in the same way here depending on that symlink, either can't find via cmake or it's the wrong includedir
2022-06-10 08:21:45 <psykose> and funnily, for lld only there is -DLLVM_CONFIG=llvm-config that.. fixes this. but not for the others of course
2022-06-10 08:22:55 <sam_> oh okay, I was checking cvise, and it uses llvm-config to find out where they're hidden for me
2022-06-10 08:23:02 <sam_> but this is the internal llvm stuff
2022-06-10 08:23:03 <sam_> crap
2022-06-10 08:23:21 <psykose> yeah, everything that uses actual llvm-config works for sure, not worried there
2022-06-10 08:26:31 <sam_> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/lldb/lldb-14.0.4.ebuild doesn't look very interesting, the only magic is llvm_pkg_setup, but that's only for PATH munging anyway
2022-06-10 08:27:14 <sam_> what error do you end up getting?
2022-06-10 08:27:37 <sam_> the configure output for me doesn't seem to mention finding llvm
2022-06-10 08:28:31 <sam_> obviously it does have to but not sure where yet
2022-06-10 08:29:49 <sam_> apparently can do -DLLVM_DIR but i don't get why need to
2022-06-10 08:31:15 <psykose> with the symlink, it doesn't have the -I to /usr/lib/llvm14/include, (because LLVM_INCLUDE_DIRS from cmake is /usr/include), so it's 'fatal error: 'llvm/Frontend/OpenMP/OMP.inc' file not found' yada yada
2022-06-10 08:31:53 <psykose> without the symlink https://img.ayaya.dev/CTuwKj1fvqxm
2022-06-10 08:35:11 <psykose> back on llvm13 the LLVMConfig.cmake has a simple set(LLVM_INSTALL_PREFIX "/usr/lib/llvm13") at the top, and that makes it work fine, the new ones have the relative stuff so i'm not sure where they expect to be found from if they only work all the way inside the prefix
2022-06-10 08:35:16 <sam_> i'm fried i think but can try think on it more tomorrow, feel free to continue to braindump
2022-06-10 08:35:54 <psykose> sure thing :) out of ideas for now anyways
2022-06-10 08:35:56 <psykose> take care
2022-06-10 08:36:36 <sam_> you too!
2022-06-10 08:38:08 <psykose> (also hotpatching the LLVMConfig.cmake works, so i might just go for that)
2022-06-10 08:38:11 <psykose> though it's a little ugly
2022-06-10 08:51:55 <raspbeguy> hello, I try to write an init file to enable a non-privilegied daemon to bind to a reserved port
2022-06-10 08:52:47 <raspbeguy> the current workaround is to manually do setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary
2022-06-10 08:53:12 <psykose> that's generally what we've done in aports, although it's not a very good solution
2022-06-10 08:53:21 <psykose> the slightly better ones are.. ehh
2022-06-10 08:53:48 <psykose> there's `setpriv`, but that requires an entire package
2022-06-10 08:54:02 <raspbeguy> psykose, so the current method is to execute it on the APKBUILD file ?
2022-06-10 08:54:04 <psykose> openrc 0.45 (released 2 days ago) has native support for adding caps
2022-06-10 08:54:22 <psykose> which sounds ideal, though it would need us to a) upgrade to it lol b) enable that functionality
2022-06-10 08:54:34 <psykose> i already have in !35190 , but will take a bit
2022-06-10 08:54:37 <raspbeguy> that would be cool
2022-06-10 08:55:30 <raspbeguy> psykose, do you have an example of apkbuild that does the setcap ?
2022-06-10 08:55:37 <psykose> testing/soju
2022-06-10 08:55:43 <raspbeguy> thanks
2022-06-10 08:57:28 <raspbeguy> another question: when can a package be moved from testing to community?
2022-06-10 08:58:08 <psykose> if it works and you've tested it
2022-06-10 08:58:13 <raspbeguy> oh ok
2022-06-10 08:58:54 <raspbeguy> I'm currently workin on testing/biboumi to make it actually usable (add the init file, user, etc)
2022-06-10 08:58:59 <randomcomp> and it must be maintained too :P
2022-06-10 08:59:28 <raspbeguy> when it will be done and accepted I'll move it to community
2022-06-10 09:08:23 <psykose> sam_: i just restored the older behaviour for now.. https://img.ayaya.dev/r187GjfZtB5z
2022-06-10 09:08:39 <psykose> also this has had a patch sitting there for '5 years' actually, lmfao https://reviews.llvm.org/D29969
2022-06-10 09:10:49 <psykose> (that deleted snippet is just moved to `find_prefix_from_config` now in another file)
2022-06-10 11:45:43 <Ermine> Please take a look at !35144
2022-06-10 11:51:31 <raspbeguy> I did my merge request : https://gitlab.alpinelinux.org/alpine/aports/merge_requests/35242
2022-06-10 13:00:56 <omni> rbq: thanks! didn't see any notice in gitlab of that
2022-06-10 13:11:54 <rbq> No problem :)
2022-06-10 15:31:19 <pabloyoyoista> Hi, for a while I've been wanting to disable out-of-date notifications for pre-release versions that we would usually not package. Most specifically, I'm talking about GNOME libraries and projects that follow "odd minor version is dev-release". I the emails I receive, it says that the notification comes from Anitya <https://release-monitoring.org/>
2022-06-10 15:31:54 <pabloyoyoista> So it seems like that is something totally out of the control of alpine, yet they fire notifications towards alpine
2022-06-10 15:33:15 <pabloyoyoista> Does anybody have any pointers on how is that happening/how to solve it? Is maybe somebody from alpine involved?
2022-06-10 15:37:01 <ikke> pabloyoyoista: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/blob/master/tools/anitya-watch.lua
2022-06-10 15:37:09 <ikke> https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/blob/master/tools/anitya-check-all.lua
2022-06-10 15:38:46 <psykose> the https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/merge_requests/48 that is open is specifically for that
2022-06-10 15:39:01 <psykose> i don't think it catches the case where first they send the new version, and afterward it's marked as prerelease
2022-06-10 15:39:13 <psykose> but it should catch like 80% of them that are pre-flagged based on version numbering
2022-06-10 15:40:49 <pabloyoyoista> Thanks a lot both for the info! Then I guess it's  just waiting for it to be integrated :)
2022-06-10 15:41:47 <psykose> it would also be nice to have a fix for https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/issues/40 because roughly half the manual flags are completely pointless
2022-06-10 15:42:04 <psykose> https://img.ayaya.dev/zZeumntdjAOQ.png the pinnacle of human communication
2022-06-10 15:44:36 <skarnet> 10/10 ship it
2022-06-10 15:45:37 <pabloyoyoista> Fun :')
2022-06-10 15:45:41 <Ermine> There are a lot of packages flagged like this
2022-06-10 15:48:35 <psykose> and you even need some custom css like that to read the flags otherwise you have to slowly move the cursor over each one :p
2022-06-10 15:51:29 <Ermine> stupid idea: verify that 'new version' field contents looks like version number, so people don't type crap in this field
2022-06-10 15:53:13 <minimal> psykose: is that coming from anitya or from someone clicking the "Flag" button on an entry in pkgs.alpinelinux.org?
2022-06-10 15:54:26 <psykose> manual flag
2022-06-10 15:54:30 <psykose> anitya ones all have the same message
2022-06-10 16:39:48 <rbq> psykose: I think Risgit is using the Gitlab web interface only, so unfortunately they probably won't understand what you mean by rebase
2022-06-10 16:41:55 <psykose> maybe, no idea
2022-06-10 16:42:58 <psykose> if they actually sat down and said 'hey could you walk me through this' i would perhaps have the time to do so, but instead all they seem to be able to post is 'gitlab unsuitable for human usage alpine terrible unsuitable trash for development build fine on my server please merge package' so i've gotten just a little tired of it
2022-06-10 16:43:34 <rbq> Oh well
2022-06-10 16:44:00 <ikke> 23 commits, fun
2022-06-10 16:44:16 <psykose> just one
2022-06-10 16:44:25 <ikke> There is a new draft MR
2022-06-10 16:44:34 <psykose> i could go fix it in like 3 minutes but do i really want to
2022-06-10 16:54:05 <nmeum> does anyone have an opinion on !28541 ?
2022-06-10 16:54:55 <nmeum> background: we currently have a lot of packages that depend on mkinitfs directly the idea here would be to have them depend on a virtual package called initramfs-generator to allow users to choose different initramfs generation tools (mkinitfs, booster, …) instead of forcing mkinitfs
2022-06-10 16:55:40 <nmeum> if my $provides knowledge is correct the PR should still use mkinitfs by default though as it has the highest provider_priority?
2022-06-10 16:56:38 <psykose> if it works as we think it does then it seems perfectly okay
2022-06-10 16:56:53 <ikke> nmeum: yes, that sounds right
2022-06-10 16:57:20 <psykose> but iirc there were some cases where the priority is not the only thing, and the 'version' or shorter dep chain took priority
2022-06-10 16:57:26 <psykose> i never found a definitive answer
2022-06-10 16:57:33 <ikke> You cannot combine different types
2022-06-10 16:57:49 <ikke> It should either be a virtual package, or a concrete package (with version)
2022-06-10 16:58:11 <ikke> The shorter dep chain affected jack / pipewire iirc
2022-06-10 16:58:17 <psykose> ah, right, so the reason the jack/pipewire-jack stuff happened is because jack itself is not a virtual
2022-06-10 16:59:28 <ikke> and virtual packages should always have a priority defined
2022-06-10 17:00:38 <psykose> in better news llvm14 looks quite ready
2022-06-10 17:00:57 <nmeum> psykose: yes, that's why I am asking because I don't want to trigger some sort of corner case where mkinitfs gets uninstalled and systems no longer boot ':D
2022-06-10 17:01:33 <nmeum> so…since initramfs-generator is a virtual this shouldn't be a problem?
2022-06-10 17:01:34 <ikke> nmeum: You created a virtual package (provides="initramfs-generator"), and it has a priority
2022-06-10 17:01:38 <ikke> correct
2022-06-10 17:01:44 <psykose> yeah, since it's virtuals only it should be fine
2022-06-10 17:01:58 <nmeum> ok!
2022-06-10 17:02:37 <nmeum> one thing I noticed is that you can no longer have dependencies with version requirements, e.g. linux-lts previously depended on mkinitfs>=3.6.0 but since it depends on the virtual initramfs-generator now this is no longer possible
2022-06-10 17:03:02 <nmeum> but I don't think we need the versioned dependency anymore since most people will have upgraded mkinitfs by now, right?
2022-06-10 17:06:52 <ikke> I suppose
2022-06-10 17:06:57 <ikke> What was the reason that was needed?
2022-06-10 17:07:00 <ikke> Was that due to simpledrm?
2022-06-10 17:07:09 <nmeum> no, compressed kernel modules
2022-06-10 17:07:12 <ikke> ah
2022-06-10 17:07:37 <nmeum> f2ae372e8b25366af33550980fa9e0f98d0d2c75
2022-06-10 17:09:50 <nmeum> it's already part of the 3.16 release so I don't think we need in edge anymore
2022-06-10 17:13:12 <minimal> nmeum: the idea behind that was to avoid broken initramfs upon upgrades. If you remove it then in theory people upgrading from e.g. 3.14 to 3.17 (whenever it comes out) could hit the same issue if they didn't specify the right apk options
2022-06-10 17:14:32 <ikke> minimal: you mean that it makes sure the kernel is upgraded whenenver initramfs is upgraded?
2022-06-10 17:15:22 <nmeum> no, it ensures that mkinitfs is upgraded at least to 3.6.0 before the kernel is upgraded
2022-06-10 17:15:22 <minimal> it was more to make sure that mkinitfs itself was upgraded as the old mkinitfs feature files didn't specify "ko*"
2022-06-10 17:15:56 <nmeum> do we actually support upgrading from 3.14 to 3.17?
2022-06-10 17:16:47 <minimal> well 1st 3.17 isn't out yet :-) and we do support upgrading (whether that's directly between 2 versions or via a sequence of upgrades)
2022-06-10 17:17:29 <nmeum> I would assume that a few things break if you upgrade from 3.14 to 3.17 directly without upgrading to 3.15 and 3.16 in between
2022-06-10 17:17:35 <minimal> s/)/ is another matter)/
2022-06-10 17:17:35 <alpine-meetbot> minimal meant to say: well 1st 3.17 isn't out yet :- is another matter) and we do support upgrading (whether that's directly between 2 versions or via a sequence of upgrades)
2022-06-10 17:18:10 <minimal> it still also would leave the matter of upgrading from a release to Edge
2022-06-10 17:18:18 <minimal> i.e. 3.14 -> Edge
2022-06-10 17:20:46 <nmeum> I mean, the committ which added the version dependency also mentions that this only happens when people don't run `apk -aU upgrade` which is what we recommend when upgrading alpine versions
2022-06-10 17:20:56 <nmeum> I wouldn't really consider this a blocker for a virtual initramfs-generator package then
2022-06-10 17:21:31 <minimal> yeah people often don't read trivial docs like Release Notes :-)
2022-06-10 17:22:24 <minimal> nmeum: I'm interested in the virtual-initramfs-generator as I just started looking into booster (and also the dracut MR)
2022-06-10 17:22:59 <nmeum> I also saw the dracut MR and it is yet another reason to get rid of the static mkinitfs dependency :)
2022-06-10 17:40:46 <nmeum> psykose ikke: you are ok with me merging this virtual package change, yes?
2022-06-10 17:41:05 <nmeum> speak now or forever hold your peace (:
2022-06-10 17:41:41 <ikke> nmeum: I'm not opposed to it, just don't know enough to have a very informed opinion
2022-06-10 17:42:39 <skarnet> I don't know what you people are talking about, but just in case: dracut is a horror story, don't use it to create your initramfses.
2022-06-10 17:43:13 <nmeum> this is not about dracut in particular it's just about allowing people to use different initramfs generators without forcing mkinitfs
2022-06-10 17:43:19 <skarnet> that's fine.
2022-06-10 17:43:47 <skarnet> but if people try to create their Alpine initramfses with dracut, they're in for a ride. :P
2022-06-10 17:45:30 <psykose> nmeum: yeah, looks alright to me :)
2022-06-10 17:45:42 <psykose> sorry, am busy removing the last python2 thing in all of aports
2022-06-10 17:46:44 <psykose> well, and llvm
2022-06-10 17:47:13 <psykose> there, that's done
2022-06-10 18:56:57 <nmeum> merged the virtual initramfs-generator change, fingers crossed it doesn't break anything
2022-06-10 19:00:58 <raspbeguy> Now the first MR is merged, let's do a second one https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35262
2022-06-10 19:19:03 <raspbeguy> Thanks psykose for both of them
2022-06-10 20:10:43 <ikke> I made something: https://tpaste.us/70pB?hl=true
2022-06-10 20:13:28 <ikke> Lists packages which have virtual provides without provider_priority
2022-06-10 20:22:58 <psykose> how should the lua ones be changed
2022-06-10 20:24:33 <ikke> postgres uses pkgver
2022-06-10 20:24:39 <ikke> or rather, majorver
2022-06-10 20:28:19 <ikke> https://github.com/antonmedv/expr is fun
2022-06-10 20:28:31 <psykose> you mean =$majorver-r$pkgrel?
2022-06-10 20:28:48 <psykose> what should luajit be? and is 5.4 being the biggest preferred?
2022-06-10 20:29:15 <ikke> provider_priority is an integer
2022-06-10 20:29:56 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/postgresql14/APKBUILD#L43
2022-06-10 20:30:16 <ikke> So at least in the case of postgres, the newest version is preferred
2022-06-10 20:30:46 <psykose> ah, like that
2022-06-10 20:30:53 <psykose> but sure, same question
2022-06-10 20:31:25 <ikke> https://tpaste.us/1lj0?hl=true
2022-06-10 20:31:29 <ikke> for all packages
2022-06-10 20:32:19 <ikke> Right now the default provider is 5.4, but I think it used to be 5.3 for a long itme
2022-06-10 20:33:17 <psykose> also adding =$pkgver instead of priority fixes it too right
2022-06-10 20:33:47 <ikke> That would not make sense
2022-06-10 20:33:53 <ikke> lua5.4 providing lua5.4
2022-06-10 20:33:56 <ikke> lua=5.4
2022-06-10 20:33:58 <ikke> hmm
2022-06-10 20:34:03 <ikke> or does it
2022-06-10 20:34:07 <psykose> not for lua, in general
2022-06-10 20:34:27 <ikke> It would
2022-06-10 20:36:10 <ikke> hmm, if I do: apk add lua, I get 5.1 now
2022-06-10 20:36:28 <Ermine> btw are lua and luajit different things?
2022-06-10 20:36:45 <ikke> Same language
2022-06-10 20:37:14 <ikke> https://luajit.org/luajit.html
2022-06-10 20:38:40 <Ermine> oic
2022-06-10 20:39:33 <ikke> psykose: I think the destinction is basically if you want the version to determine the priority, or you want to determine it manually
2022-06-10 20:40:08 <psykose> yeah, though in most of these cases the provides= matches the name of another package, so it would always lose if it's the higher version, haha
2022-06-10 20:41:36 <ikke> Yes, you should not use it to provide another existing package
2022-06-10 20:41:58 <ikke> which I think happened with jack-pipewire
2022-06-10 20:42:36 <ikke> example that fabled mentioned:
2022-06-10 20:42:38 <ikke> "fabled │ Not necessarily. If package depends on mail-transport-agent it is user decision if he wants exim or postfix."
2022-06-10 20:42:46 <ikke> so there is an intermediate virtual package
2022-06-10 20:42:59 <ikke> But issue is discoverability
2022-06-10 20:53:03 <ikke> poppler-qt5 misses an = btw
2022-06-10 20:53:10 <ikke> provides="poppler-qt4-$pkgver-$pkgrel"
2022-06-10 20:53:25 <ikke> vaultwarden as well
2022-06-10 20:59:57 <ikke> https://tpaste.us/pnoW 
2022-06-10 21:00:18 <psykose> ye
2022-06-10 21:00:20 <psykose> fixed them all
2022-06-10 21:00:27 <psykose> gonna push the 30 commits in a bit
2022-06-10 21:00:34 <ikke> Just playing with my new toy :D
2022-06-10 21:00:38 <psykose> :)
2022-06-10 21:00:45 <psykose> i think some don't exist
2022-06-10 21:00:48 <psykose> like ba-bazel4
2022-06-10 21:00:54 <psykose> or tg-telegram-cli
2022-06-10 21:00:59 <ikke> I think the goal was to help transition
2022-06-10 21:01:09 <psykose> i can't find them is what i mean
2022-06-10 21:01:13 <psykose> unless i am terrible at grep today
2022-06-10 21:01:14 <psykose> (again)
2022-06-10 21:01:20 <ikke> psykose: I mean, when bazel4 is removed
2022-06-10 21:01:23 <psykose> ah
2022-06-10 21:01:33 <psykose> right
2022-06-10 21:02:01 <skarnet> ba-bazel4 is youzel4
2022-06-10 21:15:28 <ikke> 3862 packages with checks disabled!
2022-06-10 21:16:22 <ikke> ./pkgquery -r ~/projects/alpine/aports/ 'pkg.Options.Has("!check")' | wc -l                                                                                                                  3862
2022-06-10 21:22:04 <ikke> riscv64 has the most disabled packages (1767), followed by s390x (1636)
2022-06-10 21:22:27 <psykose> is it 3862 with any arch or 3862 of global !check
2022-06-10 21:22:43 <psykose> seems about right just for things that have no tests or that don't really test anything in general
2022-06-10 21:22:51 <ikke> psykose: just global
2022-06-10 21:22:54 <psykose> ah
2022-06-10 21:22:58 <psykose> also, python2 is now gone
2022-06-10 21:23:46 <skarnet> grats!
2022-06-10 21:24:08 <psykose> :)
2022-06-10 21:26:53 <psykose> wonder how many more complaints there will be
2022-06-10 21:27:00 <ikke> heh
2022-06-10 21:35:03 <ikke> 61 packages with a pkgrel >10
2022-06-10 21:38:18 <psykose> we will never beat archs record
2022-06-10 21:38:40 <ikke> What is the record?
2022-06-10 21:38:42 <psykose> ..of which i'm not sure what it even is, but cabal-install is -148
2022-06-10 21:40:50 <psykose> hasktags -244, haha
2022-06-10 21:41:17 <psykose> too many haskell rebuilds
2022-06-10 21:43:13 <ikke> djbdns: 47
2022-06-10 21:43:24 <ikke> That's our record
2022-06-10 21:44:41 <psykose> and not touched since 2016 :)
2022-06-10 21:45:28 <psykose> also ppc seems to be stuck on uploading
2022-06-10 21:47:24 <Ermine> wow, djbdns is maintained
2022-06-10 21:48:42 <ikke> psykose: I suppose the network is slow
2022-06-10 21:48:45 <ikke> rsync is still goiung
2022-06-10 21:48:46 <psykose> more like it's so good it doesn't need to be
2022-06-10 21:48:55 <psykose> ikke: it's possible, but i saw it be there 5 hours ago
2022-06-10 21:49:04 <psykose> so.. dial up slow, sure :3
2022-06-10 21:57:02 <Ermine> psykose: sorry for being a bit obtrusive, can you check my trafficserver mr? :)
2022-06-11 14:46:28 <psykose> Ermine: ah, sorry, i went to bed for 15 hours right after you posted that
2022-06-11 15:06:55 <lucidiot> quick nap
2022-06-11 15:09:36 <ikke> :D
2022-06-11 16:35:06 <Ermine> psykose: no problem
2022-06-11 18:15:52 <ikke> Interesting. Anyone knew that apk-readme existed?
2022-06-11 18:33:18 <psykose> heard of it once ever
2022-06-11 20:03:06 <randomjohn> set novice
2022-06-11 20:03:29 <randomjohn> hello
2022-06-11 20:03:44 <randomjohn> i'm having trouble trying to change the boot order of the pi4
2022-06-11 21:07:07 <lucidiot> huh, a readme? why would i read that
2022-06-11 21:12:08 <psykose> dontreadme.md
2022-06-11 21:20:32 <lucidiot> writeme.md
2022-06-12 07:34:15 <raspbeguy> I submitted a new aport !35281
2022-06-12 09:07:47 <omni> in !35272 I noticed that CONFIG_BSD_PROCESS_ACCT is not set in lts.ppc64le.config, but is in virt.ppc64le.config
2022-06-12 18:08:07 <panekj> PureTryOut: plain text email went through the first time :P
2022-06-12 18:08:19 <PureTryOut> Oh wtf
2022-06-12 18:08:22 <PureTryOut> Then why did Sourcehut complain damn it
2022-06-12 18:08:28 <PureTryOut> It just said "it was not sent"
2022-06-12 18:09:13 <panekj> complain to the sourcehut author? :D
2022-06-12 19:10:42 <ikke> It's confusing. If it's multi-part, it complains about the html but sends the plain-text
2022-06-12 19:12:12 <PureTryOut> Yeah that is confusing
2022-06-13 10:11:24 <omni> so push to gitlab seem to work fine for me over both IPv6 and IPv4, but every pull takes ~2 minutes for some reason...
2022-06-13 15:22:25 <HRio> is this patch realy complete? https://git.alpinelinux.org/aports/commit/?id=ec39fd2b2f64fde0319c4b127749e7d84c3027aa should the %ghost diretive not be handled in a "APKBUILD way
2022-06-13 15:24:44 <HRio> after this fix was included in alpine I get a mail from logratate that /var/lib/logrotate.status is world readable, and that it due to that is skipping lock acqusition
2022-06-13 15:25:25 <HRio> s/acqusition/acquisition/
2022-06-13 15:25:25 <alpine-meetbot> HRio meant to say: after this fix was included in alpine I get a mail from logratate that /var/lib/logrotate.status is world readable, and that it due to that is skipping lock acquisition
2022-06-13 15:26:09 <ikke> HRio: ok, so there probably should be a post-install that fixes the permissions?
2022-06-13 15:26:17 <ikke> or post-update rather
2022-06-13 15:26:30 <HRio> yes, I would think so to
2022-06-13 15:30:56 <ikke> omni: git pull is also slow for me, but not sure exactly why it happens
2022-06-13 15:31:07 <ikke> omni: but it does not take 2 minuttes
2022-06-13 15:34:34 <omni> now it takes 5 minutes...
2022-06-13 15:48:10 <ikke> omni: does it help if you run git gc / git maintenance run locally?
2022-06-13 15:51:17 <omni> hmm... let's see...
2022-06-13 15:51:28 <omni> there's so much to git that I don't know
2022-06-13 16:00:28 <omni> git gc didn't help, it seems, but was probably good to run in any case
2022-06-13 16:13:12 <omni> now, the last pull took 9 minutes...
2022-06-13 16:28:58 <rbq> durrendal: Hello. If there's nothing wrong with !35106 , could you give it your approval? Thanks.
2022-06-13 16:40:41 <durrendal> absolutely, thanks once again, that slipped under my radar entirely
2022-06-13 16:43:39 <rbq> You're welcome
2022-06-13 17:04:49 <dalias> fabled_, do you have a chance to take a look at the mail onthe musl list about netlink code?
2022-06-13 18:49:30 <raspbeguy> Could !35281 be reviewed please?
2022-06-13 19:31:02 <ikke> Ariadne: https://gitlab.alpinelinux.org/alpine/go/-/releases/v0.5.0
2022-06-14 05:19:29 <fabled_> dalias: replied
2022-06-14 08:13:52 <eddsalkield> would someone be able to let me know how the process of cutting a new release from edge works? on the releases page it says that v3.16 was branched on 2022-05-23, but I had some packages (e.g. vit) that were built before that (on 2022-04-18 for vit) and weren't included in the release
2022-06-14 08:14:32 <eddsalkield> I would have expected that all packages in edge before the branch date would find their way into the release, maybe there's something I'm missing?
2022-06-14 08:43:57 <rbq> eddsalkield: vit is in the 'testing' repository, and testing isn't included in stable releases (only main and community are included)
2022-06-14 09:00:41 <eddsalkield> ah that makes sense, thanks!
2022-06-14 13:07:34 <dalias> fabled_, thanks
2022-06-14 13:55:30 <ncopa> any opinion on kyua/atf-test vs bats for shell script testsuite?
2022-06-14 14:13:39 <minimal> ncopa: when writing bats tests for the 1st time I did find it hard to debug things (having said that the bats in Alpine does not seem to be the current upstream version at https://github.com/bats-core which has more functionality)
2022-06-14 14:16:25 <ddevault> do the builders use ccache?
2022-06-14 14:16:33 <minimal> ncopa: to clarify, things like bats-asserts and bats-file are not packaged by Alpine currently
2022-06-14 14:16:35 <ikke> ddevault: no
2022-06-14 14:16:39 <ddevault> thanks
2022-06-14 14:17:18 <ikke> minimal: ncopa prefers kyua nowadays
2022-06-14 14:18:05 <ikke> minimal: bats-asserts and bats-file are shipped as separate projects
2022-06-14 14:18:20 <ikke> They are not part of bats-core
2022-06-14 14:19:01 <minimal> ikke: yeah, my point was that bats-asserts seemed to make it easier to debug stuff than with just bats-core
2022-06-14 14:20:47 <minimal> I wrote bats tests for a MR as ncopa requested it - this was before the decision to use kyua. My MR, !32330, is still unmerged, am I expected to now write kyua tests before it will be considered for merging?
2022-06-14 14:21:58 <ikke> minimal: I would not think so
2022-06-14 14:22:34 <ikke> I manually included bats-assert and bats-file in the test environment for alpine-gitlab-ci
2022-06-14 14:23:19 <ikke> minimal: I suppose someone would need to create packages for those
2022-06-14 15:43:52 <Ermine> ikke: do you mean bats-asserts and bats-file ?
2022-06-14 15:44:17 <ikke> yes
2022-06-14 15:48:25 <ncopa> minimal: i will take care of the porting of it when I get there, so dont worry
2022-06-14 15:48:40 <ncopa> minimal: i also found it a bit tricky to debug bats
2022-06-14 15:49:33 <ncopa> i have tested to port some of the abuild tests to kuya/atf-sh and I must say that atf-check is much nicer than bats
2022-06-14 15:49:49 <ncopa> its faster too, which is a good thing
2022-06-14 15:54:16 <minimal> ncopa: yes I had to resort to peppering "echo" statement in the BATS file to diagnose things. I have not looked at kuya yet
2022-06-14 15:55:10 <ncopa> kyua can be used as a wrapper around bats
2022-06-14 15:55:25 <ncopa> but i think the real win is atf-sh
2022-06-14 15:55:49 <ncopa> i can publish some of the tests im working on for abuild soonish, so you can compare with the bats variants
2022-06-14 15:59:12 <ikke> btw, I created a tool that can query APKBUILDs based on an expression language
2022-06-14 15:59:24 <ncopa> cool
2022-06-14 15:59:43 <ikke> Need to still publish it
2022-06-14 16:00:54 <ikke> This prints all packages that have unversioned provides, but also no provider_priority:
2022-06-14 16:01:00 <ikke> ./pkgquery -r ~/projects/alpine/aports/ 'any(pkg.Provides, {.Constraint == ""}) && pkg.ProviderPriority == "" && print(join(map(pkg.Provides, {.Pkgname}),", "))'
2022-06-14 16:01:30 <ncopa> wow
2022-06-14 16:03:31 <ikke> https://github.com/antonmedv/expr/blob/master/docs/Language-Definition.md
2022-06-14 16:06:57 <ncopa> compare bats tests: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/tests/abuild-fetch.bats
2022-06-14 16:07:07 <ncopa> with atf-sh: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/kyua/tests/abuild_fetch_test
2022-06-14 16:09:26 <ncopa> i havent ported the "abuild-fetch: test locking" yet
2022-06-14 16:18:07 <ncopa> will do so tomorrow
2022-06-14 16:28:31 <ncopa> ikke: that tool seems very useful
2022-06-14 16:28:41 <ikke> ncopa: Ok, I'll make effort to publish it
2022-06-14 16:29:14 <ikke> The tool itself is just 101 lines of code :)
2022-06-14 18:59:32 <ikke> ncopa: https://gitlab.alpinelinux.org/kdaudt/apkgquery
2022-06-14 20:44:16 <ncopa> ikke: nice!
2022-06-14 22:51:53 <omni> sourcery
2022-06-15 10:56:37 <ncopa> finding bugs while refactoring bats tests -> kyua/atf
2022-06-15 11:00:32 <ikke> hmm, interesting
2022-06-15 11:22:05 <Ermine> Is there any policy on which uid/gid daemon should run with? Or is it fine if it runs as nobody?
2022-06-15 11:24:03 <ncopa> Ermine: normally we create a user/group for each daemon
2022-06-15 11:24:43 <ncopa> 31/31 passed (0 failed)
2022-06-15 11:25:02 <ncopa> $ grep @test tests/*.bats | wc -l
2022-06-15 11:25:02 <ncopa> 27
2022-06-15 11:25:16 <ncopa> so I have done over 50% now
2022-06-15 12:37:44 <Ermine> ncopa: and if daemon does logging on its own, should I chown its log dir to his user/group or do it in some other way?
2022-06-15 12:41:08 <skarnet> Ermine: create one group for daemon+logger, one user for daemon, one user for logger
2022-06-15 12:41:26 <skarnet> all dynamic in the pre-install script, no uid/gid hardcoding
2022-06-15 12:41:49 <skarnet> no failure, it needs to be idempotent; never remove the users/groups once you've added them
2022-06-15 12:42:12 <Ermine> skarnet: it has no separate logger
2022-06-15 12:42:57 <skarnet> oh, no need for a logger user? all fine then. If the daemon logs into a dir then yeah I suppose chown the logdir to the daemon's user.
2022-06-15 12:43:44 <Ermine> ok
2022-06-15 12:49:39 <Hello71> processes should never run as the nobody user. the nobody user is reserved for nfs
2022-06-15 12:49:54 <Hello71> it doesn't make sense to run services as nobody, because then all your services can access each other
2022-06-15 13:04:05 <Ermine> Well, I added commands to post-install script to change ownership of the log dir and it didn't work. It is still root:root
2022-06-15 13:04:32 <psykose> just install it as install -d -o -g in package()
2022-06-15 13:09:25 <Ermine> it is installed by make install. Also, I'll need to create uid/gid in this function, won't I?
2022-06-15 13:09:37 <skarnet> create them in pre-install
2022-06-15 13:10:48 <ikke> Ermine: and also define them in pkgusers / pkggroups
2022-06-15 13:10:50 <skarnet> (if you create them during a build/install, they will be created on the builder machines, not on the user's machine :))
2022-06-15 13:11:22 <ikke> pkgusers/pkggroups is to make sure they are available in the package phase
2022-06-15 13:13:30 <psykose> you can run things after `make install`, worlds yer oyster
2022-06-15 13:13:53 <Ermine> ikke: thank you
2022-06-15 13:14:28 <ikke> You still need to create them in pre-install as well like skarnet said
2022-06-15 14:58:27 <ddevault> not sure I really agree with the rationale for removing minio, cc Ariadne
2022-06-15 14:59:07 <ddevault> the arguments apply to a lot of AGPL software
2022-06-15 14:59:15 <ddevault> and are generally concerns for the downstream user, not alpine
2022-06-15 14:59:16 <Ariadne> i don't have a strong opinion either way, but i am concerned that the relicensing that was done was not done properly
2022-06-15 14:59:29 <ddevault> fwiw I was present in those relicensing discussions
2022-06-15 14:59:37 <ddevault> I agree that it was executed poorly, but I do not think it was done illegally
2022-06-15 14:59:50 <Ariadne> if you want to readd it, it is fine with me
2022-06-15 14:59:54 <ddevault> aight
2022-06-15 14:59:59 <ddevault> I will do that before the next release cycle
2022-06-15 15:01:12 <Ariadne> (i do think that if minio discovers that AGPL is still not good enough to give them a business model that we should not allow SSPL software in alpine)
2022-06-15 15:02:11 <Ariadne> or commons clause
2022-06-15 15:02:29 <ddevault> I don't trust minio upstream
2022-06-15 15:02:33 <ddevault> and I think they will do just that
2022-06-15 15:02:37 <ddevault> SSPL is possibly fine
2022-06-15 15:02:41 <ddevault> commons clause is absolutely not fine
2022-06-15 15:03:10 <ddevault> correction: SSPL is probably fine after the time period elapses and it becomes GPL, assuming that security fixes are backported to GPL'd versions
2022-06-15 15:04:40 <Ariadne> i agree that minio will eventually go SSPL, but hopefully there will be a fork before that happens
2022-06-15 15:05:39 <Ariadne> at any rate, we can deal with that when it happens
2022-06-15 15:05:47 <minimal> Ariadne: I thought there might have been a fork around the time of the relicensing but unfortunately not. Seaweedfs looks a promising alternative to Minio
2022-06-15 15:07:18 <Ariadne> though, a quick glance at SSPL diff does not look *too* bad
2022-06-15 15:07:27 <Ariadne> https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf
2022-06-15 15:08:11 <ddevault> I like how it immediately violates the GPL by editing it, which is not permitted
2022-06-15 15:09:06 <Ariadne> their rewrite of section 13 does seem quite biased towards Amazon though
2022-06-15 15:09:11 <Ariadne> i can see why the OSI rejected it
2022-06-15 15:13:49 <Ariadne> at any rate, when minio was frozen, i froze it because i figured there would be a fork of minio
2022-06-15 15:14:10 <Ariadne> due to the sloppy relicensing job
2022-06-15 15:14:50 <Ariadne> but since there has not been a fork, i guess we can carry minio again :)
2022-06-15 15:15:12 <Ariadne> though, i don't think minio upstream is particularly trustworthy
2022-06-15 15:16:06 <psykose> Ariadne: have you had a look at the gcc12 upgrade recently?
2022-06-15 15:16:32 <Ariadne> psykose: yes, i am rebasing a few things to allow alpine gcc to work with glibc target again
2022-06-15 15:16:42 <psykose> hehe
2022-06-15 15:28:34 <sam_> psykose: yo
2022-06-15 15:28:37 <sam_> psykose: wrt gnome, does everything mostly just work w/ musl?
2022-06-15 15:28:37 <psykose> heya
2022-06-15 15:28:43 <psykose> to my knowledge, yes
2022-06-15 15:29:05 <psykose> not sure what we do or don't have specifically shim fixed, you can skim through the usual soup, but to my knowledge it's nothing really
2022-06-15 15:29:18 <psykose> and we do have a few gnome users that use it, so, i assume most things are fine
2022-06-15 15:32:46 <psykose> most of the patches are just systemd related or something else, only gnome-terminal/fix-W_EXITCODE.patch and gnome-builder/fix-musl.patch stand out, but i'm probably missing a few things
2022-06-15 15:38:41 <psykose> sam_: how's boost 1.79?
2022-06-15 15:48:32 <sam_> thanks re gnome; someone is trying it out but seems to get some issue in gdm, but was hoping it wasn't somehow musl related (their glibc machine is apparently okay)
2022-06-15 15:48:34 <sam_> re boost 1.79: very good as far as boost can go!
2022-06-15 15:48:37 <sam_> pulseeffects needed fixing (fixed in 4.8.7)
2022-06-15 15:48:40 <sam_> prusaslicer did too 
2022-06-15 15:48:43 <sam_> and mongodb
2022-06-15 15:48:45 <sam_> that's all
2022-06-15 15:51:21 <ericonr> amazing
2022-06-15 15:51:22 <psykose> we don't do anything special for gdm, though iirc a bunch of people had issues with rootless gdm; not sure if it's related at all though
2022-06-15 15:51:43 <ericonr> sam_: they did check to make sure their glibc machine wasn't on systemd, right?
2022-06-15 17:18:46 <pabloyoyoista> sam_: I have gdm working totally fine. There has definitely been some problems in the past with XOrg and permissions
2022-06-15 17:33:39 <sam_> ericonr: good question!
2022-06-15 17:33:41 <sam_> I'll double check
2022-06-15 17:33:48 <sam_> psykose, pabloyoyoista: thanks a bunch, that's helped a lot with routes to go down
2022-06-15 17:34:10 <psykose> :)
2022-06-15 19:46:35 <sam_> ok we're getting somewhere
2022-06-15 19:46:39 <sam_> it.. looks like lots of stack depth in librsvg and then a crash
2022-06-15 20:17:47 <ericonr> Is librsvg built with the correct LDFLAGS?
2022-06-15 20:18:50 <ericonr> We force a stack size flag in the DSO so musl knows to increase the default. Their SVG parser is recursive and can blow past musl's default thread stack size 
2022-06-15 20:22:43 <psykose> huh, maybe we should do that
2022-06-15 20:28:04 <ericonr> hm
2022-06-15 20:28:11 <ericonr> it seems void nor alpine do that anymore
2022-06-15 20:34:28 <ericonr> psykose: sam_: I got confused, it seems both distros set stack size in pixman instead
2022-06-15 20:35:06 <psykose> ah
2022-06-15 20:36:53 <sam_> huh
2022-06-15 20:36:59 <sam_> does librsvg use pixman or are they just like 
2022-06-15 20:37:01 <sam_> somehow related
2022-06-15 20:39:01 <psykose> bound by magic
2022-06-15 20:40:16 <ericonr> I once had the reason why in my head
2022-06-15 20:41:25 <ericonr> pixman appears in the ldd chain for librsvg, at leat
2022-06-15 20:41:27 <ericonr> least
2022-06-16 03:00:26 <eschwartz> ericonr: the ldd chain is sorta irrelevant, in this case it just means that rsvg depends on cairo, and cairo happens to depend on pixman
2022-06-16 03:01:18 <ericonr> eschwartz: I am aware, but it's the only explanation I can find for us setting stack size in pixman instead of rsvg (I don't want to try reading through the issues again)
2022-06-16 03:02:03 <ericonr> ftr the dynamic linker uses the largest value from all dynamic libraries, so it's "okay" to depend on it transitively 
2022-06-16 03:06:54 <eschwartz> until and unless cairo decides one day to stop using pixman, which is unlikely but stranger things have happened
2022-06-16 03:10:39 <ericonr> cairo rust rewrite (:
2022-06-16 11:39:27 <skarnet> hey everyone! Small MR that should be consensual because no systems are touched: !35391
2022-06-16 11:39:53 <skarnet> (once that is merged we can start talking about the Big Things)
2022-06-16 11:40:20 <skarnet> (this is not a threat, don't let it prevent you from merging)
2022-06-16 15:37:43 <omni> and now we're not close to a release
2022-06-16 16:23:39 <skarnet> exactly
2022-06-16 16:59:19 <psykose> you have to fix the sssd tests it seems
2022-06-16 17:00:09 <sam_> sssd is one of the "bad redhat" projs
2022-06-16 17:00:11 <sam_> something about it just smells icky
2022-06-16 17:00:13 <sam_> i have nothing but trouble with it
2022-06-16 17:11:21 <PureTryOut> psykose: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35405 was needed to fix boost1.79 installing over boost1.78
2022-06-16 17:12:24 <sam_> 
ACTION raises eyebrow

2022-06-16 17:12:42 <sam_> oh we just do boost-build
2022-06-16 17:12:48 <sam_> it.. looks like you guys do too?
2022-06-16 17:49:15 <psykose> PureTryOut: seems i always miss one
2022-06-16 17:51:22 <psykose> sam_: haha, no, boost-build only has the jamfiles in /usr/share, actual b2/bjam is in boost itself
2022-06-16 17:58:11 <sam_> o
2022-06-16 17:58:42 <psykose> and afaik we don't pull in boost-build anywhere in aports
2022-06-16 17:58:46 <psykose> not sure why it's even there
2022-06-16 18:54:19 <sam_> psykose: and if anything does want it
2022-06-16 18:54:20 <sam_> dump it
2022-06-16 18:54:23 <sam_> piece of junk
2022-06-16 18:54:38 <psykose> :p
2022-06-16 18:54:57 <skarnet> <sam_> sssd is one of the "bad redhat" projs
2022-06-16 18:55:09 <skarnet> in other words: sssd is a redhat project
2022-06-16 19:41:50 <skarnet> community/mingetty fails to build, not sure why
2022-06-16 19:42:13 <psykose> also just realised i called nsss- sssd
2022-06-16 19:42:14 <psykose> haha
2022-06-16 19:43:44 <psykose> skarnet: it seems to build fine? only nsss fails check in that ci
2022-06-16 19:48:24 <skarnet> I got "pipeline failed" reports, maybe it was just temporary and kicking the builders made it pass
2022-06-16 19:48:39 <psykose> no, it's the same ci failure as always
2022-06-16 19:48:42 <psykose> https://gitlab.alpinelinux.org/skarnet/aports/-/jobs/746660
2022-06-16 19:49:25 <skarnet> also nsss should not fail checks, but maybe the builders don't take LD_LIBRARY_PATH as lightly as my local machine does
2022-06-16 19:49:36 <psykose> based on the diff, it includes the passwd of the host
2022-06-16 19:50:03 <skarnet> yeah it does. Is there no /etc/passwd on the builders?
2022-06-16 19:50:20 <psykose> there is, that diff includes stuff from the builder
2022-06-16 19:51:35 <psykose> what i mean is whatever `-` is is missing stuff from `./test-switch.expected`, and that missing stuff includes the entire passwd from the ci host container; i don't know whether the expected file should not have that, or whether the - should pick up the passwd too, your tests :)
2022-06-16 19:51:49 <skarnet> ah, s6-ipcserver not found. My makedepends are incomplete (build w/o tests doesn't depend on it to avoid cycles, build w/tests does)
2022-06-16 19:51:52 <skarnet> hmmm
2022-06-16 19:52:35 <skarnet> yeah I remember, I had disabled the tests to avoid cycles. Will disable them again.
2022-06-16 19:52:50 <skarnet> (not like s6 is built with nsss atm, but it may be in the future)
2022-06-16 20:19:07 <skarnet> fixed, pipeline passes
2022-06-16 20:23:59 <psykose> :)
2022-06-16 20:24:53 <psykose> now to watch busybox hang on every builder again
2022-06-16 20:25:18 <psykose> ikke: did you have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35286
2022-06-16 20:26:03 <ikke> Not yet
2022-06-16 21:03:53 <skarnet> psykose: thanks for the merge!
2022-06-16 21:04:20 <psykose> of course everyone has to wait for busybox again to get the new version :p
2022-06-16 21:05:25 <skarnet> is there a legendary busybox brittleness that makes it break or hangs the builders if you sneeze too hard?
2022-06-16 21:06:55 <psykose> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10758 https://github.com/eclipse/mosquitto/issues/2564 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35286 https://github.com/ncopa/mqtt-exec/pull/7
2022-06-16 21:07:11 <psykose> (and having SIGPIPE in SIGIGN breaks the bb testsuite and makes it hang)
2022-06-16 21:09:00 <skarnet> okay, that's a mosquitto bug, if nmeum got it fixed things should go swimmingly now, right? ... right?
2022-06-16 21:09:43 <psykose> well the other fix isn't merged
2022-06-16 21:10:39 <psykose> and both fixes are just shim fixes after the c library to delete the ignored thing, haha, hopefully they change it in mosquitto itself
2022-06-16 21:11:08 <skarnet> I would say "disable the bb test suite until the mosquitto bug is fixed", but that would actually be a terrible idea :P
2022-06-16 21:12:26 <psykose> it was disabled for years, and only enabled some time months after 3.15 release
2022-06-16 21:12:55 <skarnet> "ohey now I remember why we disabled it"
2022-06-16 21:13:03 <psykose> :p
2022-06-16 22:01:04 <Ermine> skarnet: is sssd an abbreviation?
2022-06-16 22:13:07 <skarnet> no idea tbh
2022-06-16 22:15:56 <psykose> system security services daemon
2022-06-16 22:19:11 <Ermine> Ah
2022-06-16 22:43:20 <skarnet> that's frightening
2022-06-17 02:23:55 <ericonr> psykose: left a suggestion on the mosquitto issues 
2022-06-17 02:24:05 <ericonr> s/issues/issue/
2022-06-17 02:24:05 <alpine-meetbot> ericonr meant to say: psykose: left a suggestion on the mosquitto issue 
2022-06-17 02:26:08 <psykose> those look good to me :) sadly i know nothing about signals
2022-06-17 05:09:38 <nmeum> re bb test suite hangs: i would just suggest that we merge !35286, I am relatively sure that it should be a suitable workaround
2022-06-17 05:10:28 <nmeum> disabling the bb test suite does not "solve" this, there are other test suites which also require SIGINT to not be ignored (e.g. m4 test suite)
2022-06-17 05:10:41 <nmeum> s/SIGINT/SIGPIPE/
2022-06-17 05:10:41 <alpine-meetbot> nmeum meant to say: disabling the bb test suite does not "solve" this, there are other test suites which also require SIGPIPE to not be ignored (e.g. m4 test suite)
2022-06-17 05:11:24 <psykose> sure, feel free to merge
2022-06-17 05:11:31 <psykose> though it still needs a manual purge
2022-06-17 07:16:29 <ikke> How so? 
2022-06-17 07:18:24 <psykose> ..all the builders have been stuck for 10 hours?
2022-06-17 08:14:21 <nmeum> ikke: I took the liberty of merging !35286 let me know if issues persist
2022-06-17 08:16:13 <ikke> 👍
2022-06-17 09:39:32 <ikke> ncopa: https://gitlab.alpinelinux.org/kdaudt/apkgquery/-/merge_requests/1
2022-06-17 09:43:37 <ikke> nmeum: lua-mqtt-publish is not even installed on the builders..
2022-06-17 09:46:41 <psykose> is lua5.1-mqtt-publish or the like, though
2022-06-17 09:47:40 <psykose> aports build depends on the 5.2 one
2022-06-17 09:48:07 <ikke> ah ofcourse
2022-06-17 09:48:25 <ikke> new one is not installed yet
2022-06-17 09:48:34 <psykose> yeah, no self-upgrade until end
2022-06-17 09:48:38 <ikke> ahuh
2022-06-17 09:48:56 <psykose> s390x did pass though for some reason
2022-06-17 09:49:05 <ikke> but it's not even built yet
2022-06-17 09:49:23 <psykose> no, but busybox itself passed
2022-06-17 09:55:14 <ikke> strange
2022-06-17 10:02:57 <ncopa> nmeum: have you reported 'ash: Fix use-after-free on idx variable' upstream? and sent patch upstream?
2022-06-17 10:03:37 <psykose> http://lists.busybox.net/pipermail/busybox/2022-June/089749.html
2022-06-17 10:03:39 <ncopa> I think I finally got a proper fix for busybox awk use-after-free CVE-2022-30065
2022-06-17 10:03:44 <psykose> http://lists.busybox.net/pipermail/busybox/2022-June/089750.html v2
2022-06-17 10:04:26 <ncopa> awesome. thanks!
2022-06-17 10:05:36 <ncopa> I believe this fixes awk: https://bugs.busybox.net/show_bug.cgi?id=14781#c7
2022-06-17 10:20:20 <ddevault> wow the latest release really fucks up the install process
2022-06-17 10:20:26 <ddevault> this was poorly tested
2022-06-17 10:21:46 <ikke> -+
2022-06-17 10:26:03 <psykose> the 3.16 setup scripts?
2022-06-17 10:26:06 <psykose> what specifically
2022-06-17 10:29:56 <ikke> busybox now continued on x86 without me restart mqtt-exec
2022-06-17 10:32:34 <ddevault> networking and user management issues
2022-06-17 10:32:44 <ddevault> someone next to me was doing the install and ran into issues, unsure of the specifics
2022-06-17 10:32:49 <ddevault> had to manually fix up a bunch of stuff
2022-06-17 10:33:02 <ikke> This release had more tests than ever
2022-06-17 10:35:12 <psykose> the latter didn't even exist before, as for the former all that comes to mind first is the broken setup-proxy..
2022-06-17 11:02:46 <ncopa> ddevault: can you please report the specifics and I'll try fix them for the 3.16.1 (next week hopefully)
2022-06-17 11:08:05 <ddevault> I'll have to see when I have time to reproduce
2022-06-17 11:08:10 <ddevault> it was a colleague who hit these issues, not me
2022-06-17 11:08:51 <psykose> ncopa: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/69 for the setup-proxy case
2022-06-17 14:41:09 <ncopa> yeah, i saw there were a handful reports. will try get them all fixed for 3.16.1
2022-06-17 14:41:30 <ncopa> just attended a funeral. not in the mood right now
2022-06-17 14:41:42 <psykose> yeah, understandable
2022-06-17 14:41:57 <psykose> hope you're doing alright
2022-06-17 14:45:25 <ncopa> i am. thanks
2022-06-17 18:43:26 <eddsalkield> just received some mail from devel-announce@lists.fedoraproject.org in which they're planning to extract runtime utilities from gettext to save space. apparently their gettext package is ~4.7MB, but alpine's has an installed size of 1636KiB, yet they appear to contain the same binaries
2022-06-17 18:43:33 <eddsalkield> anyone have an idea as to what gives?
2022-06-17 18:44:53 <ikke> eddsalkield: not sure if that makes all the difference, but we compile with -Os by default
2022-06-17 18:45:46 <psykose> things linked against glibc are just bigger, and then there's -Os (though i don't think that really matters; above that smallish threshold O2+lto usually comes pretty close anyway, maybe an exception here)
2022-06-17 18:46:07 <psykose> also they might have glib added
2022-06-17 18:46:40 <psykose> you should check all the deps/options and the full package filelist of where you get the size
2022-06-17 18:49:46 <eddsalkield> thanks
2022-06-17 20:00:50 <Hello71> fedora gettext seems to come with all the messages
2022-06-17 20:00:55 <Hello71> https://pkgs.alpinelinux.org/package/edge/main/x86_64/gettext-lang
2022-06-17 20:01:25 <Hello71> also the man and info pages
2022-06-17 20:02:17 <psykose> aye
2022-06-18 17:57:18 <vkrishn> hi, in community/bsm-simple-themes/APKBUILD, computed file name string in $source does not match in sha512sums=
2022-06-18 19:12:56 <panekj> vkrishn: how so? just checked and it is fine
2022-06-18 19:14:01 <psykose> it was broken until i fixed it
2022-06-18 19:14:22 <psykose> i would guess the dev.a.o distfiles server changed and returns slightly different filenames for the same thing, given that % spam
2022-06-18 19:14:38 <panekj> smh
2022-06-18 19:14:39 <psykose> and now it's the same as the uri, before some % was missing, or something
2022-06-18 19:14:52 <psykose> check the diff i guess
2022-06-18 19:36:46 <vkrishn> why not use 121685-BSM-Simple-theme-$_ver.tar.gz:: ?
2022-06-18 19:37:52 <vkrishn> or maybe just BSM-Simple-theme-$_ver.tar.gz::
2022-06-18 19:39:36 <vkrishn> probably this was the reason comment '# Fails to fetch source' was added
2022-06-18 19:46:08 <handlerug> psykose: found your libebur128 package, how do you feel about moving it into community?
2022-06-18 19:46:43 <handlerug> would be neat to have it in the next release to be able to depend on it
2022-06-18 19:47:00 <psykose> vkrishn: that also works, yeah
2022-06-18 19:47:04 <psykose> handlerug: sure, if you want me to
2022-06-18 19:47:11 <handlerug> thanks :)
2022-06-18 19:48:24 <psykose> done
2022-06-20 05:31:10 <rbq> psykose: Hello, just wondering how an aport is fixed if pkgusers/pkggroups is different from the pre-install script
2022-06-20 05:33:07 <psykose> probably changing it in the install script
2022-06-20 05:35:58 <rbq> There's...mimedefang, that has "mimedfang" as pkgusers and "mimefang" is created with addgroup in the pre-install script...
2022-06-20 05:36:45 <rbq> I mean, both probably should be "mimedefang" instead?
2022-06-20 05:37:51 <psykose> haha
2022-06-20 05:37:56 <psykose> yeah, i would change both
2022-06-20 06:02:44 <rbq> a16bitsysop: Maybe you can look into this
2022-06-20 08:40:05 <rbq> @a16bitsysop: By the way, "v3.0" is also hardcoded in mimedefang's source url
2022-06-20 16:29:20 <a16bitsysop> missed the second 3.0 in the url, will fix the user as well
2022-06-20 17:21:38 <a16bitsysop> I created !35524 but after installing the directories in /var/spool they are owned by defang:root and /var/log/mimedefang is not created
2022-06-20 17:25:28 <psykose> you forgot $pkgdir to the install
2022-06-20 17:25:53 <a16bitsysop> thanks will try that
2022-06-20 17:33:11 <a16bitsysop> that worked, it's own install script must create the /var/spool directories as still there if remove install for them
2022-06-20 17:37:58 <psykose> and you need to quote pkgdir :p
2022-06-20 17:38:22 <a16bitsysop> okay
2022-06-21 00:19:05 <Newbyte> Is it deliberate that Alpine's installation does not create a home directory for the non-root user you optionally can create?
2022-06-21 00:22:58 <psykose> it does, it's just not added to lbu with diskless so it's not persisted, which should be fixed
2022-06-21 00:23:09 <psykose> unless somehow the adduser in setup-user does not make a directory at all (though i did just test it)
2022-06-21 00:26:09 <Newbyte> I did a "sys" installation of 3.16 today, and /home was empty. Maybe I did something weird when installing.
2022-06-21 00:26:21 <Newbyte> To be clewra
2022-06-21 00:26:26 <Newbyte> * To be clear, I was able to resolve it
2022-06-21 00:30:13 <psykose> with setup-alpine it runs before setup-disk, not sure what would move anything
2022-06-21 06:41:17 <ncopa1> aha
2022-06-21 06:41:53 <ncopa1> i know what happens
2022-06-21 07:21:12 <panekj> Good morning
2022-06-21 07:22:42 <panekj> Ariadne: interesting email re: alpine glibc just dropped on devel ml :)
2022-06-21 07:28:16 <psykose> @broadcom
2022-06-21 07:28:44 <clandmeter> interesting
2022-06-21 07:30:56 <boomanaiden154> The confidentiality notice at the end of the email on a public mailing list is quite humorous.
2022-06-21 07:31:41 <skarnet> sounds to me like the real issue here is the lock performance in musl and that's what the work should be focused on
2022-06-21 07:32:15 <clandmeter> skarnet: yeah, he prefers to work around the issue instead of trying to fix it.
2022-06-21 07:33:05 <ncopa> skarnet: that was exactly my thoughts as well
2022-06-21 07:35:23 <clandmeter> but its cool that ppl are actually debugging stuff instead of just switching to something different.
2022-06-21 08:00:14 <Daanct12> alpine with glibc sounds a bit cursed
2022-06-21 08:20:42 <ikke> It's being done already 
2022-06-21 08:20:49 <ikke> Though, not by us 
2022-06-21 09:52:53 <nmeum> i don't understand why a big company, like broadcom, doesn't just invest some financial resources into improving the musl pthread lock implementation (i.e. instead of asking for an alpine glibc port)
2022-06-21 10:11:00 <panekj> they probably ported one app out of hundreds to musl, tested performance and said it's not good enough
2022-06-21 11:50:53 <fcolista> +100000 nmeum 
2022-06-21 12:34:06 <Cogitri> nmeum: Probably because it’s easier (in the short term) to port to glibc 
2022-06-21 12:34:47 <Cogitri> As in a developer needs more time to get to know the musl pthread implementation and how to improve it instead of just monkey patching things to get glibc on alpine to work
2022-06-21 12:42:57 <markand> o/
2022-06-21 13:43:19 <HRio> anybody here with go packaging experiance that can have a look at !35342 to see if I have not done anything wrong in it?
2022-06-21 16:20:39 <Ariadne> nmeum: the issue is that glibc has features such as lock elision which are... kinda sketchy :)
2022-06-21 16:21:24 <Ariadne> musl's lock implementation is equally efficient to glibc's, the difference is that glibc's lock implementation does not always lock
2022-06-21 16:21:59 <Ariadne> i think features like lock elision are better done at the language level rather than in libc but :)
2022-06-21 16:22:17 <panekj> HRio: we generally don't use $pkgname in package()
2022-06-21 16:24:30 <Ermine> Ariadne: so glibc may decide that you don't actually need a lock when you ask to take one?
2022-06-21 16:24:51 <Ariadne> Ermine: yes, correct
2022-06-21 16:25:12 <ikke> I get a very spectre/meltdown like feeling of that
2022-06-21 16:27:08 <panekj> HRio: src can be changed to https://github.com/nats-io/nats-server/archive/v$pkgver/nats-server-$pkgver.tar.gz
2022-06-21 16:27:20 <Ariadne> you can go fast, or you can go safe, yes
2022-06-21 16:27:20 <panekj> so you don't need to assign name for it
2022-06-21 16:28:36 <ikke> Ariadne: exactly
2022-06-21 16:29:00 <Ariadne> Ermine: in fairness, a lot of cases where locking happens, you don't actually need the lock.  so, glibc does crimes to provide "eventually consistent locks"
2022-06-21 16:29:41 <Ariadne> one of the things it does is postpone the use of futexes until there is actually contention
2022-06-21 16:30:08 <Ariadne> which is "safe" most of the time, but can lead to interesting behavior on glibc
2022-06-21 16:30:27 <Ariadne> on musl, a lock is a lock, period
2022-06-21 16:30:51 <Ermine> mrincredible.jpg
2022-06-21 16:30:56 <HRio> panekj: thanks, fixing both
2022-06-21 16:35:39 <Ermine> Ariadne: thank you for explanation
2022-06-21 16:38:00 <panekj> you can also disable some tests if you think they are false-positive or that application works fine on those arches
2022-06-21 16:39:58 <HRio> yes, was planning to work on finding stable tests to run post merge, but would like it in edge for proper testing on target as well
2022-06-21 16:40:18 <panekj> I don't see any problems then :)
2022-06-21 16:41:36 <HRio> great thanks
2022-06-21 16:42:25 <Hello71> 08:56 <zhasha> With Java it seems much more likely that it's musl's malloc that's bottlenecking
2022-06-21 16:42:32 <Hello71> seems like a plausible guess to me
2022-06-21 16:49:02 <Ariadne> doesn't java use its own malloc
2022-06-21 17:00:35 <jvoisin> wouldn't be surprised
2022-06-21 18:48:22 <nmeum> Ariadne: do you know any rustc developers which are interested in musl? if so: could you point them to https://github.com/rust-lang/rust/issues/96876 unfourtunatly there hasn't been any response from rust developers and I don't know enough rustc internals to fix rustc on riscv64 musl on my own
2022-06-21 18:49:30 <Ariadne> nmeum: i can start a thread on zulip
2022-06-21 18:50:09 <nmeum> if it isn't too much hassle for you that would be great :)
2022-06-21 18:51:34 <psykose> it would also be nice if someone that actually knows anything about ppc fixed binutils so we can upgrade rust afterward
2022-06-21 18:55:30 <ikke> psykose: I sent a message in slack
2022-06-21 18:56:08 <Habbie> lol, i came here to see if there was any related conversation, keep forgetting that that's you :D
2022-06-21 18:56:45 <ikke> :-)
2022-06-21 18:58:07 <psykose> in 'slack'? i thought you needed to be 'formal' to talk to the ibm mainframe lads, that's not going to work
2022-06-21 18:58:31 <ikke> Someone already respondend :P
2022-06-21 18:59:13 <psykose> also, i think s390x is ready for rust bootstrap, who is going to do it by hand :p
2022-06-21 19:00:21 <ikke> I could
2022-06-21 19:21:55 <ikke> psykose: how do we bootstrap it?
2022-06-21 19:22:22 <psykose> i've no clue to that part, but the actual patches should be sorted
2022-06-21 19:23:15 <ikke> nmeum had some plan for rv64, but there he bootstrapped it
2022-06-21 19:24:56 <nmeum> I think you should just be able to use bootstrap.sh to bootstrap rust on s390x after applying the patches proposed in the MR
2022-06-21 19:25:24 <ikke> ah right, forgot that bootstrap.sh did the bootstrapping :)
2022-06-21 19:25:57 <ikke> And it should be intially done from x86_64 (iirc)?
2022-06-21 19:26:34 <psykose> and afaik the bootstrap should be fine if you remove openrc from the list (which isn't needed anyway)
2022-06-21 19:26:41 <psykose> still have to figure out the meson mess
2022-06-21 19:30:27 <ikke> psykose: They have asked someone who has experience with the linker to take a look at it (re binutils issue on ppc64le)
2022-06-21 19:30:36 <psykose> at last!
2022-06-21 19:31:46 <psykose> funnily, there is a patch in binutils to 'disable an assert' for mips bfd... could totally just comment out the exact same assert in ppc bfd :D
2022-06-21 19:33:46 <ikke> "What bug? I have not seen any bug.."
2022-06-21 19:35:21 <psykose> `-fuse-ld=lld` bugs? where?
2022-06-21 22:52:54 <omni> PureTryOut: hey! are we supposed to be at qt5 5.15.5 now? qt5-qtwebengine is at "5.15.3"
2022-06-22 01:34:25 <rbq> Is https://gitlab.alpinelinux.org/explore/snippets collecting spam?
2022-06-22 01:57:47 <boomanaiden154> Has been for a while.
2022-06-22 03:24:02 <ptrc> arlecchino[m]: forgive me for taking this here instead of ML (i cannot into emails), but you do realize that "gogs database is world-readable" and "post-install unlocks a user that root might have deliberately created before" are two unrelated things, of which only one is an actual security issue?
2022-06-22 03:27:34 <ptrc> especially that your initial email and half the thread mentions only the latter, while the former is only glossed over in one of the emails and not much else
2022-06-22 03:32:08 <ptrc> also, i would argue it's an issue with gogs - merged with one that's still open since 2016 :) https://github.com/gogs/gogs/issues/3070
2022-06-22 03:37:07 <arlecchino[m]> @ptrc no you can't unlock existing users. it is unsafe. this could be a normal user called george ogson with account gogs, who got fired and was locked with password/ssh key. The package installation unlocks it in pre-install and not post-install. there is no post-install. One of my mails got cced on user list, the start and most of it is on devel. No it is an issue of installation permissions and QA of the development cycle. I'm
2022-06-22 03:37:07 <arlecchino[m]> done with talking about this.
2022-06-22 03:43:11 <ptrc> my point is, Ariadne pointed out that the user unlocking is not an issue and in response you call her "not qualified" while pointing out an unrelated issue
2022-06-22 03:46:59 <ptrc> and while yes, the post-install script *could* check if the user exists and error out when it does, the database permissions thing is fundamentally an issue Gogs needs to fix, not Alpine add workarounds for - one of their intended ways of distribution is just a single binary without any init system, so it's vulnerable out of the box anyway
2022-06-22 04:16:34 <Ariadne> i already explained what our plans are to improve the situation anyway
2022-06-22 05:52:52 <ikke> rbq: I cleaned up the spam
2022-06-22 06:10:02 <PureTryOut> omni:  qt5-qtwebengine follows it's own release really (read: none). We can update it's version to be in sync but it doesn't matter much
2022-06-22 06:23:33 <rbq> ikke: Thanks :)
2022-06-22 06:43:04 <nmeum> ikke: yes, bootstrap for rustc on s390x should be done from x86_64
2022-06-22 06:49:09 <nmeum> psykose: re cross compiling with meson: void uses the following meson crossfile config https://github.com/void-linux/void-packages/blob/master/common/build-style/meson.sh#L43-L78 I don't think/hope that we need all of that but maybe we can just have abuild-meson create a similar appropriate crossfile to fix boostrap of openrc etc.?
2022-06-22 09:03:59 <omni> PureTryOut: ok, because I never really got why it was kept at "5.15.3"...
2022-06-22 09:05:03 <omni> I could bump it to "5.15.5" for aesthetics then ;)
2022-06-22 09:05:13 <omni> next time I need to touch it for other reasons
2022-06-22 09:13:46 <skarnet> oh boy
2022-06-22 09:13:51 <skarnet> that was a wild ride
2022-06-22 09:15:18 <skarnet> Ariadne_, you're officially unqualified for not wanting to solve a nonexistent user management problem because the gogs database has incorrect permissions
2022-06-22 09:16:07 <skarnet> well at least we now know what the real issue is.
2022-06-22 09:19:13 <PureTryOut> omni: yeah that's fine
2022-06-22 09:22:01 <donoban> lol
2022-06-22 09:25:52 <donoban> skarnet: so gogs db is readable from any user?
2022-06-22 09:27:07 <skarnet> if the exploit is real (and I believe it is), yeah it looks like it
2022-06-22 09:27:56 <donoban> but it seems unrelated with apk user management
2022-06-22 09:28:06 <skarnet> that's the impressive part
2022-06-22 09:28:38 <skarnet> it was a long and scenic route to get down to the root problem
2022-06-22 09:28:59 <donoban> "Painless self-hosted Git service"
2022-06-22 09:29:16 <ncopa> so, the real tricky part in situations like this is
2022-06-22 09:29:30 <donoban> good project description
2022-06-22 09:29:53 <ncopa> to help the reporter see that there is no problem, without making them feel like idiot
2022-06-22 09:34:14 <ncopa> I admire people who have that skill
2022-06-22 09:34:16 <skarnet> ncopa: the reporter insisted that there was a problem in A, he was right that there was a problem but the problem was in B, and he kept mentioning A and not B until challenged to provide an exploit, which showcased B and had nothing to do in A... in this situation I'd have the decency to feel like an idiot myself no matter what the package maintainers say :P
2022-06-22 09:34:49 <skarnet> nothing to do with*
2022-06-22 09:38:34 <ncopa> yes, that is how I understand the situation too. my point here is that there are people who manages to explain that to the reporter - without making reporter feel like an idiot. And I highly admire people who manages to do that, because it is difficult but not impossible
2022-06-22 09:40:21 <skarnet> diplomacy is a wonderful skill.
2022-06-22 09:59:21 <ncopa> its a skill I've learned to appreciate more and more the older I get
2022-06-22 10:10:52 <staceee> I got an issue with murmur (!13948). I am trying to rebuild murmur but stuck on "unable to select package" (icu-libs-71.1-r2 and icu-libs-69.1-r1)
2022-06-22 10:11:06 <staceee> #13948 sorry
2022-06-22 10:11:33 <skarnet> murmurdered
2022-06-22 10:12:26 <staceee> :D
2022-06-22 10:18:02 <staceee> why does so many of my package still depend on icu-libs-69.1-r1 ? where some of them needs icu-libs-71.1-r2
2022-06-22 10:19:27 <staceee> is there issues with the icu package split ?
2022-06-22 10:20:16 <staceee> (okay first it looks like I have to upgrade php7)
2022-06-22 10:20:50 <skarnet> are you declaring icu-libs>=71 in your depends in the APKBUILD? sometimes you need to kick the builder into doing things in the proper order
2022-06-22 10:23:01 <staceee> okay. Now that I have upgraded php8 I now can rebuild mumble
2022-06-22 10:23:30 <staceee> and it looks like murmur actually start without needing rebuild
2022-06-22 10:36:14 <staceee> okay so related question. What should I have in my world concerning php ? Marking php8 and php8-related is the good thing to have ?
2022-06-22 11:10:40 <panekj> Not sure I understand the question(?). I don't see mumble/murmur depend on php at all so why you want php8{,-related} in world?
2022-06-22 11:15:01 <nmeum> you can also use `abuild rootbld` to build aports in a "clean" chroot environment
2022-06-22 11:15:36 <panekj> unless you speak purely about php upgrade then you can just upgrade all php7* packages you have in world to php8
2022-06-22 13:43:45 <rbq> durrendal: Hello, can you give !35538 and !35547 your approvals? Thanks :)
2022-06-22 13:45:56 <ncopa> any volunteer to review my kyua refactoring of abuild tests? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/147
2022-06-22 13:48:28 <rbq> durrendal: Just in case you missed my message due to the ping timeout: can you give !35538 and !35547 your approvals? Thanks :)
2022-06-22 13:50:32 <rbq> durrendal: It seems sbcl switched to zstd for core compression, so we'll have to remember to use that for 2.2.6 when it's released
2022-06-22 13:51:00 <durrendal> thanks for resending that, I didn't see it. Will happily approve those :)
2022-06-22 13:51:35 <durrendal> I'm actually excited for that change, it should mean the sbcl core compression options will result in much smaller binaries!
2022-06-22 13:52:23 <rbq> That's good :)
2022-06-22 13:57:45 <durrendal> It's also nice that it feels like the next sbcl update won't be an uphill battle
2022-06-22 13:58:54 <rbq> Have you had another look at that "add back thread support" merge request? I added a comment after it was merged
2022-06-22 14:00:02 <rbq> I think I found the first commit that has the memory fault problem on x86
2022-06-22 14:01:09 <durrendal> I haven't yet unfortunately, I just got back from a trip to Monhegan. Haven't had access to a computer until this morning
2022-06-22 14:01:24 <durrendal> but my evening is actually free so I'm hoping to take a look after work tonight
2022-06-22 14:01:24 <rbq> Oh, ok, no rush about that
2022-06-22 14:04:19 <rbq> I tried it again last week (a week after my comment), and now I'm less convinced that the problem is time64...it may be something else that changed from musl 1.1 to 1.2
2022-06-22 14:08:32 <durrendal> I have some suspicions of that as well, Daewok alludes to it as well in his SBCL container builds
2022-06-22 14:08:34 <durrendal> https://github.com/cl-docker-images/sbcl/blob/master/2.2.4/alpine3.15/Dockerfile#L17
2022-06-22 14:09:05 <durrendal> He's the one who wrote the patches that allowed sbcl to build on musl about a year back
2022-06-22 14:10:55 <rbq> Hmm, so he uses sbcl to build sbcl on Alpine
2022-06-22 14:14:22 <durrendal> Yes indeed, I believe he did it that way because at the time the containers were being built the sbcl package was in testing, and only available on an arch or two
2022-06-22 14:16:13 <rbq> I think he's using the sbcl from edge on Alpine 3.12, and I went in the opposite direction (using sbcl from Alpine 3.12 to build sbcl on edge) :)
2022-06-22 15:19:25 <dhruvin> I'd like to use guile bindings to gnutls in one of my packages. APKBUILD of gnutls has them disabled. What should I do?
2022-06-22 15:19:50 <dhruvin> Enable guile bindings in gnutls and make a separate package for it, i.e. gnutls-guile?
2022-06-22 15:23:06 <dhruvin> IIUC, this will add guile to the makedependencies of gnutls package
2022-06-22 16:09:47 <psykose> omni: the actual version os qt5-qtwebengine is like 5.15.10 or .9 by now. and they have an actual number with no _git, so you can change it to that if you want.. the reason for it was that you do have to update the config file and change the actual version to .3 or .4 or whatever as the patch does, so things still work with it
2022-06-22 16:10:12 <psykose> nmeum: ah, yeah, that's what i was thinking of already. if that's enough then it's easy- originally i thought i'd have to fill out machine settings per target..
2022-06-22 16:11:03 <psykose> nmeum: since i don't feel too confident in really testing it, shall i send you a modified abuild-meson you can try in a cross configuration for building openrc only?
2022-06-22 16:13:40 <psykose> dhruvin: you can probably enable them, look at the diff, and decide from there
2022-06-22 16:16:17 <psykose> this whole email thread stuff reminded me why i never use email for anything
2022-06-22 16:16:19 <Ariadne> donoban: if the gogs instance is using sqlite, it seems to be true, but i don't think you should use these types of services on multiuser systems anyway
2022-06-22 16:16:43 <psykose> somehow in the archives the thread is split into three, and also one of my replies did get sent but isn't anywhere in the archive
2022-06-22 16:16:45 <psykose> amazing software
2022-06-22 16:17:02 <Ariadne> so, yes, that issue should be fixed, but it is not the issue the reporter was asserting was a "CVE worthy issue"
2022-06-22 16:17:19 <Ariadne> and yes, i had to put my foot down on that one.  i didn't like it, but that was just absurd and needed to stop.
2022-06-22 16:17:37 <Ariadne> something something doctor it hurts when i do this
2022-06-22 16:19:49 <Ariadne> the underlying issue of user management is being solved in apk-tools 3 anyway so...
2022-06-22 16:22:14 <donoban> nice that you found it Ariadne, so does it only happen with sqlite backend? does it create a world readable sqlite file? if it's created by gog itself it looks an upstream bug
2022-06-22 16:22:25 <Ariadne> yes, upstream bug
2022-06-22 16:22:35 <Ariadne> i don't really care about this tbh
2022-06-22 16:22:47 <psykose> https://github.com/gogs/gogs/issues/3070 it's been one for forever
2022-06-22 16:23:05 <Ariadne> you should not run gogs/gitea/gitlab on a system which is multiuser
2022-06-22 16:23:08 <psykose> or https://github.com/gogs/gogs/issues/2950 for more words
2022-06-22 16:23:09 <Ariadne> it is just a bad idea
2022-06-22 16:23:30 <donoban> "I don't think gogs should mess with parent directory rights, that's administrators responsibility."
2022-06-22 16:49:15 <skarnet> they couldn't fix a mkdir() umask in 7 years?
2022-06-22 16:49:35 <skarnet> ah, more like 6
2022-06-22 16:51:41 <ptrc> yeah, despite someone explicitly telling them how they could fix it
2022-06-22 16:52:33 <ptrc> and the label "priority: low" on a security issue is just a cherry on top
2022-06-22 16:59:06 <psykose> i don't even see what it would break
2022-06-22 16:59:21 <psykose> clearly it's not intended to be o+r, so..
2022-06-22 17:15:08 <minimal> from memory wasn't one of the reasons for the gogs->gitea fork that the single maintainer for gogs was unresponsive both to bugfixes but also to (some) new functionality...
2022-06-22 19:20:00 <genkitj> Are there any single-board computers with usb 3+ that could boot a kernel from Alpine repos and cost less than 100$?
2022-06-22 19:22:08 <wej> there are some cheap mini pcs that should boot alpine just fine
2022-06-22 19:22:26 <wej> usually with some slightly older intel atom based cpu
2022-06-22 19:22:38 <wej> or do you specifically want something ARM BASED?
2022-06-22 19:29:00 <genkitj> arm would be preferable, but really hard to find given the conditions above I guess
2022-06-22 19:30:03 <genkitj> I would look at atom-based one also, what should I searx for?
2022-06-22 19:32:20 <a16bitsysop> Pi Compute module 4 with carrier board? https://thepihut.com/products/dual-gigabit-ethernet-base-board-for-raspberry-pi-compute-module-4
2022-06-22 19:34:30 <wej> genkitj: as for the mini pcs, you could for example check out one of those gigabyte brix systems
2022-06-22 19:34:54 <wej> the Brix GB-BACE-3000 can be bought new for 70 € for example
2022-06-22 19:35:38 <wej> you'll need a stick of ram in addition, but even with that you'd be still under 100 bucks
2022-06-22 19:37:25 <psykose> that looks like it comes with no storage either, but pretty close
2022-06-22 19:37:38 <psykose> storage itself is pretty expensive
2022-06-22 19:38:59 <wej> psykose: true, storage isn't included, but you wouldn't get storage with a raspberry pi or similar either
2022-06-22 19:39:05 <minimal> wej: I have a similar older Brix barebones model
2022-06-22 19:39:37 <wej> also, if you don't need massive amounts of storage, a 128 GB ssd would cost less than $20
2022-06-22 19:39:52 <wej> minimal: neat, is it working okay for you?
2022-06-22 19:40:53 <minimal> its a J1900, does the job. Also have similar Asrock and Zotac boxes as well
2022-06-22 19:42:10 <wej> ah yes, zotac also has those systems, usually a bit more expensive
2022-06-22 19:45:35 <wej> when going with that brix model i mentioned and adding a stick of 4 GB RAM and a 128 GB ssd, it would end up just under 100. that's not too bad
2022-06-22 19:45:38 <Saijin_Naib> The ZOTAC units are really nicely made in my experience.
2022-06-22 19:46:30 <wej> yeah
2022-06-22 19:47:03 <wej> i have an older zotac itx mainboard, build quality is great, although the bios is somewhat questionable
2022-06-22 19:47:16 <minimal> I've used a Zotac and a Asrock as Openelec media centres for some time
2022-06-22 19:48:16 <wej> of course there are also the intel NUCs. the lower end one are also quite cheap, although usually a bit over $100, plus you need ram and storage
2022-06-22 19:51:09 <genkitj> gb-bace-3000 specs/price looks great, the performance is a bit worse than lets say pi4b, right?
2022-06-22 19:53:18 <wej> probably depends on the usecase, but single threaded performance should be better than a pi 4
2022-06-22 19:53:30 <wej> disk i/o should also be way better than a pi 4
2022-06-22 19:53:55 <wej> heavily multithreaded things might be slower, not entirely sure
2022-06-22 19:59:20 <genkitj> my usecase is experimenting with router-like device that runs Alpine with kernel from repos
2022-06-22 20:00:48 <psykose> you probably want two eth ports then
2022-06-22 20:01:38 <wej> it should be fine for that from a performance standpoint, but yeah, two ethernet ports would be helpful.
2022-06-22 20:02:04 <wej> of course you could go with a usb ethernet adaptor, or use a single port and a managed switch with vlans
2022-06-22 20:02:47 <genkitj> 2 eth would be ideal, but considering the constraints above (price), too ideal
2022-06-22 20:03:08 <wej> yeah
2022-06-22 20:03:35 <genkitj> yea, the plan was to use eth-usb3.0 adapter
2022-06-22 20:04:57 <genkitj> actually, pi4b would do, but it costs a bit above 120 eur from scalpers now
2022-06-22 20:05:23 <wej> yeah, hard to get those pis at the moment
2022-06-22 20:06:10 <wej> maybe a used mini pc would be an option as well. then you could perhaps even get one with two nics for relatively cheap
2022-06-22 20:06:30 <wej> some of those zotac mini pcs have two nics
2022-06-22 20:07:05 <psykose> it's less effort to get a cm4 with a board with 2 eths on it than a pi4b and some way of getting an extra port
2022-06-22 20:07:05 <wej> or an odroid-h2 if you can find one
2022-06-22 20:07:10 <psykose> but yeah all of them are scalped to hell
2022-06-22 20:07:44 <wej> yeah, there are some nice router boards for the cm4 with two or three nics
2022-06-22 20:08:09 <wej> i was considering getting one myself, but since it is quite difficult to get the cm4 i didn't
2022-06-22 20:10:17 <a16bitsysop> pi 400 is availiable with different keyboard layouts https://shop.pimoroni.com/products/raspberry-pi-400?variant=32280738070611
2022-06-22 20:11:47 <wej> yeah, if you don't mind the form factor, that could be an option
2022-06-22 20:12:33 <a16bitsysop> I think thats why its still available
2022-06-22 20:13:00 <wej> yeah, kind of, all the industrial users have no interest in the pi 400
2022-06-22 20:15:26 <genkitj> odroid would boot alpine nicely?
2022-06-22 20:15:52 <genkitj> or I would need pmos repos?
2022-06-22 20:15:54 <wej> the H2 is basically a singe board computer that's a x86 pc, so yes, it does
2022-06-22 20:16:05 <wej> and it has two ethernet ports
2022-06-22 20:16:25 <wej> the H2+ has even 2.5 GBe ports
2022-06-22 20:27:39 <genkitj> https://ameridroid.com/products/odroid-h2 the red font reads like a starved deadman's journal
2022-06-22 20:37:27 <wej> :/
2022-06-22 23:33:31 <rbq> durrendal: Hello, have you taken a look at sbcl? (Not rushing you, just letting you know I'm also free right now)
2022-06-22 23:40:11 <psykose> but are you really experiencing freedom at the present moment?
2022-06-22 23:41:59 <rbq> Hello, psykose
2022-06-22 23:42:09 <psykose> greetings :3
2022-06-22 23:43:15 <rbq> Is there a way to check if a package that's already been upgraded was flagged out of date before?
2022-06-22 23:46:08 <psykose> mm
2022-06-22 23:46:09 <psykose> don't think so
2022-06-22 23:51:56 <rbq> Ok...moving on, is there anything else that needs to be done with !28511 before it can be closed?
2022-06-22 23:53:45 <psykose> nope, i just never keep track of the stale ones
2022-06-22 23:53:45 <psykose> haha
2022-06-22 23:54:40 <rbq> I guess you have the default sort order as "created date" instead of "updated date"? :)
2022-06-22 23:59:34 <psykose> no, updated
2022-06-23 00:00:20 <rbq> Anyway, what's the process like for changing maintainership (for maintainers that only have 1 aport, and haven't been active in a few years)?
2022-06-23 00:02:10 <psykose> officially? email them and ask and cc: the devel ml
2022-06-23 00:02:15 <psykose> realistically, just email them
2022-06-23 00:07:16 <rbq> Is that always done? (Just wondering, because the aports I'm looking at had maintainers who were active only once...which was when they added/updated the aport)
2022-06-23 00:07:56 <psykose> not really, no
2022-06-23 00:08:00 <rbq> and at least according to git history, that's the only aport the maintainers have worked on
2022-06-23 00:10:21 <rbq> Oh wait, for one of them, the maintainer did some other things, but that was like...7 years ago
2022-06-23 00:12:33 <psykose> if it's actually 3+ years then personally i don't care too much about just moving stuff
2022-06-23 00:31:43 <durrendal> rbq: no not yet, I'm fighting a broken apk-tools on my main system right now unfortunately. 
2022-06-23 00:39:42 <psykose> `apk version -l '?'` contents could have a clue
2022-06-23 00:41:54 <durrendal> that's what I've been looking at, but I've removed everything in there and haven't made any progress insodoing. 
2022-06-23 00:42:36 <durrendal> ifupdown-ng-openrc is listed in there though, which if-installed shows it adds ifupdown-ng and openrc, but even removing those doesn't make much of a difference
2022-06-23 00:43:55 <durrendal> and oddly, my apk doesn't actually list any sort of package conflicts at all, it just jumps right to the Huh? error when I try to do any sort of add/del/upgrade command, which seems slightly different from the issue, but I may be wrong in that assumption
2022-06-23 00:45:03 <psykose> could you send me the entire world
2022-06-23 00:47:10 <rbq> I guess it should be more widely "publicized" that anyone who encounters such issues lately should save their world for a bug report
2022-06-23 00:47:47 <durrendal> yeah hang on, I'll put it and the version -l '?' on ttm
2022-06-23 00:51:20 <durrendal> http://ttm.sh/wGl.txt
2022-06-23 00:51:59 <durrendal> not sure if it's important but the system is armv7
2022-06-23 00:52:19 <psykose> xf86-input-mouse/keyboard doesn't exist at all, though i doubt it breaks it
2022-06-23 00:52:45 <psykose> the xorg/xf packages have ><hashes on the end which pin them to a locally installed version
2022-06-23 00:52:58 <durrendal> it's a pretty old install ~2-3 years old I think
2022-06-23 00:53:14 <psykose> delete every ><hash ending
2022-06-23 00:53:47 <durrendal> yeah that's correct, I have a patched xorg package for the system, it's a motorola Droid4, so the patches are specific to that
2022-06-23 00:54:01 <psykose> aha
2022-06-23 00:54:07 <psykose> everything except for the ones you know then
2022-06-23 00:54:40 <psykose> everything in '?' doesn't exist anymore either, a few things have new names
2022-06-23 00:56:14 <psykose> but also if i copy everything, and remove the xf86-video-omap, and the >< hash things, it installs
2022-06-23 00:57:21 <durrendal> see that's where my confusion came from, I thought all of those packages were ancient history
2022-06-23 00:58:15 <durrendal> hmm removing all the hashes ans the omap video package didn't work, but I left the hashes on my xorg package.
2022-06-23 00:58:36 <durrendal> maybe it's my xorg package 
2022-06-23 00:59:08 <psykose> my attempt didn't have any of the '?' either, just the list below it
2022-06-23 00:59:59 <durrendal> is there anything else I should do for those old packages other than removing them from world?
2022-06-23 01:00:22 <durrendal> gut reaction would be to apk del them, but I can't 
2022-06-23 01:01:48 <psykose> next transaction would remove them anyway
2022-06-23 01:01:56 <psykose> and they are counted as not part of world, that's fine
2022-06-23 01:05:09 <durrendal> hmm okay, I'm still not having any luck, but let me make sure I havent missed something obvious
2022-06-23 01:06:44 <psykose> play the gladiator game :p
2022-06-23 01:06:50 <psykose> backup world somewhere, delete half of it at a time
2022-06-23 01:07:04 <psykose> dangerous, yes
2022-06-23 01:07:59 <durrendal> I can't break the system any worse than it already is hahaha
2022-06-23 01:08:14 <psykose> :3
2022-06-23 01:08:27 <rbq> Hmm, so your main system is a Motorola Droid4?
2022-06-23 01:08:32 <durrendal> I think that's probably what I'll have to so, just chop up world until I can get an ish
2022-06-23 01:09:28 <durrendal> rbq: yep! Runs Alpine edge even. It's strange but really functional honestly
2022-06-23 01:09:54 <durrendal> http://lambdacreate.com/ <- if you're curious about it
2022-06-23 01:10:51 <rbq> Oh right
2022-06-23 01:11:14 <rbq> Now that you've mentioned it, I've seen the picture of your Droid4
2022-06-23 01:11:43 <rbq> that you posted on your site
2022-06-23 01:13:01 <durrendal> psykose: looks like the issue is somewhere between lime 200-300
2022-06-23 01:13:20 <psykose> getting closer
2022-06-23 01:13:38 <durrendal> :) it is somewhat infamous it seems, everyone finds it interestingb
2022-06-23 01:14:08 <durrendal> i probably should have tested with an apk add/del instead of an upgrade
2022-06-23 01:27:05 <rbq> I just realized...how are you going to test sbcl x86 on a Droid4?
2022-06-23 01:31:13 <psykose> with ssh into an x86 machine, of course
2022-06-23 01:34:36 <rbq> :)
2022-06-23 01:36:21 <durrendal> yeah I've got a little lxd cluster with an x86 machine in it fortunately
2022-06-23 01:36:30 <durrendal> heavier processes get passed off into the homelab
2022-06-23 01:36:46 <durrendal> also, the culprit appears to have been lua5.3-ossl
2022-06-23 01:37:17 <rbq> Speaking of Lua, are we really still keeping lua5.1 around?
2022-06-23 01:38:26 <durrendal> lapis depends on it, and I believe luajit is based off 5.1, which means to use luarocks and luajit you need 5.1 support
2022-06-23 01:38:55 <rbq> Ok
2022-06-23 01:39:51 <psykose> everything that uses luajit uses 5.1 code.. can't speak to module loading
2022-06-23 01:39:59 <psykose> i assume 5.1-compiled .so lua modules load into luajit?
2022-06-23 01:44:17 <durrendal> I believe they do, but don't quote me on it, I only use luajit/5.1 in lapis
2022-06-23 01:45:52 <psykose> then probably yes, because we build nothing for luajit
2022-06-23 01:56:33 <rbq> psykose: I see chromium has been merged...so good night?
2022-06-23 01:56:43 <psykose> why good night?
2022-06-23 01:56:53 <rbq> Isn't it like 4am?
2022-06-23 01:56:56 <psykose> it is
2022-06-23 01:56:58 <psykose> how come?
2022-06-23 01:57:12 <psykose> yesterday i was awake for 39 hours and then slept for 16
2022-06-23 01:57:20 <rbq> Wow
2022-06-23 01:58:23 <rbq> I thought it was chromium keeping you awake, now I see it's probably the 16 hours :)
2022-06-23 01:58:41 <psykose> i practically never go to bed at a normal time :p
2022-06-23 03:15:48 <durrendal> psykose: thanks for the assist tonight, finally got most of what I broke unbroken again
2022-06-23 03:15:57 <psykose> that's great :)
2022-06-23 08:12:42 <rbq> dhruvin: I think order matters in subpackages=, so maybe your problem with objcopy in default_dbg could be solved by placing $pkgname-guile before $pkgname-dbg
2022-06-23 08:15:53 <psykose> -dbg runs on pkgbasedir (pkg/) not pkgdir (pkg/$pkgname)
2022-06-23 08:16:32 <rbq> Oh ok
2022-06-23 08:16:49 <psykose> there's merely no abuild integration for guile objects; it's why we have none of them (except for something like aisleriot, which is *only* guile, where it's easy to add !strip and call it a day)
2022-06-23 08:16:54 <psykose> but overall, yeah, can't really mix this
2022-06-23 08:17:23 <handlerug> can I blacklist a package from being installed? I want to test zfs-src so I want to install the zfs package, but zfs-lts is also going to be pulled in which is unwanted
2022-06-23 08:17:34 <rbq> So, I guess gnutls-guile would need to be its own package so it can use !strip?
2022-06-23 08:17:41 <psykose> yeah, was about to say that
2022-06-23 08:18:03 <psykose> handlerug: `apk add !pkg`
2022-06-23 08:18:25 <handlerug> worked, tyvm!
2022-06-23 08:18:33 <psykose> but also zfs-src doesn't pull in zfs-lts, so not sure why you see that
2022-06-23 08:18:49 <handlerug> I'm on linux-lts
2022-06-23 08:19:15 <handlerug> and zfs-lts basically gets installed when you have zfs and linux-lts if I'm not mistaken
2022-06-23 08:19:46 <psykose> ah, yeah
2022-06-23 16:03:39 <xordspar0> I maintain community/cni-plugins-dnsname, an optional plugin for Podman. In Podman 4.0, the CNI network stack is no longer default, which makes this an optional plugin to a non-default stack. I'm thinking of giving up maintainership of the package. I sort of doubt anyone but me used it in the first place.
2022-06-23 16:05:44 <ikke> You could even move it to unmaintened
2022-06-23 16:08:23 <xordspar0> Sure, I can move it to unmaintained and continue to maintain the stable branch for the remainder of its support cycle. If anyone out there is actually using it, let me know and I can maintain it for another cycle or transfer maintainership.
2022-06-23 18:02:22 <dhruvin> trace_apk_deps (of abuild) can't trace guile objects. Should I add so:<some-lib>.so.<version> to depends manually? Or can we fix abuild to handle this?
2022-06-23 18:03:18 <ikke> How would you trace this for guile objects?
2022-06-23 18:03:59 <dhruvin> Sorry, I don't know enough guile. If you know it's doable, I can explore more.
2022-06-23 18:04:38 <ikke> I don't
2022-06-23 18:05:26 <dhruvin> I am packagin guile-git, which depends on libgit2 in runtime. Which doesn't get traced by abuild. If I add so:libgit2.so.1.4, it's able to generate proper symlink using which guile-git works.
2022-06-23 18:05:32 <dhruvin> context: ^
2022-06-23 18:06:50 <dhruvin> Is there a way I can specify libgit2 as dependency besides tracing. Consider this a very beginner question.
2022-06-23 18:07:42 <ikke> Just add libgit2 to depends?
2022-06-23 18:08:16 <dhruvin> libgit2 doesn't have a symlink /usr/lib/libgit2.so (only .1 and .1.4)
2022-06-23 18:08:49 <dhruvin> Using so:libgit2.so.1.4 causes it to create that symlink. And I have no idea how it happens.
2022-06-23 18:08:51 <ikke> Normally that's only used duing building
2022-06-23 18:08:57 <ikke> during*
2022-06-23 18:09:09 <ikke> so you add libgit2-dev to makedepends
2022-06-23 18:09:34 <ikke> That symlink is usually created by the build system
2022-06-23 18:10:28 <dhruvin> yes, I do have libgit2-dev in makedepends, and libgit2 in depends. but it does not create that symlink (/usr/lib/libgit2.so -> /usr/lib/libgit2.so.1.4) for runtime.
2022-06-23 18:11:01 <dhruvin> Let me check it once again (before wasting your time)
2022-06-23 18:11:03 <ikke> dhruvin: why does it need it at runtime? Usually the dependency is directly on the .so.1.4 file
2022-06-23 18:12:09 <dhruvin> So ideally it should look for .1.4 right? I can probably `./configure --something`. I'll get back with my findings. Thanks
2022-06-23 18:12:18 <ikke> yes
2022-06-23 18:12:31 <ikke> that's why the .so is in the -dev package, as it's not used during run-time
2022-06-23 18:16:01 <dhruvin> umm.. libgit2 does have that .so file in its contents
2022-06-23 18:16:25 <ikke> https://pkgs.alpinelinux.org/contents?file=&path=&name=libgit2&branch=edge&repo=community&arch=armhf
2022-06-23 18:16:44 <ikke> No .so there, only .so.1.4
2022-06-23 18:16:58 <ikke> The .so is here: https://pkgs.alpinelinux.org/contents?file=*.so*&path=&name=libgit2-dev&branch=edge&repo=community&arch=x86_64
2022-06-23 18:17:07 <dhruvin> Oh I misunderstood you
2022-06-23 18:17:35 <dhruvin> I thought <something>.so meant <something>.so.* My bad
2022-06-23 19:24:13 <lmarz> is anyone knowledgeable in arm neon? I need some help with build failures on aarch64 in !35616
2022-06-23 20:02:32 <sam_> is the assembly for arm64 or arm32?
2022-06-23 20:02:37 <sam_> anyway, I'd report such a thing upstream
2022-06-23 20:39:01 <Ermine> Do i need to backport fix for #13953 to 3.16?
2022-06-23 22:45:08 <psykose> lmarz: fixed with clang :)
2022-06-23 22:45:22 <psykose> also doesn't have to be -j4 anymore since clang uses like a fifth of the memory
2022-06-23 22:45:40 <psykose> but you should report it upstream for gcc anyway
2022-06-23 22:54:46 <psykose> i wonder what the real benchmarks are for gcc/clang these days.. in my experience everything that is a 'huge' program takes at least 50% less memory with clang and doesn't have me cry for my computer
2022-06-23 22:55:53 <psykose> and gcc is at least 2x fast at configure tests..
2022-06-23 22:56:13 <psykose> i guess one for the small things and one for the big things :p
2022-06-24 07:21:33 <dhruvin> Most guile libraries try to open "@LIBDIR@/libname" at run time. Should this value be just "libname" (letting linker provide appropriate library) or should it be "@LIBDIR@/libname.so.@LIBVERSION@" (specifying exact version of library to depend on)?
2022-06-24 07:22:08 <dhruvin> ikke suggested that the libraries should know exact version of their dependencies. In that case latter should be employed. Is this correct?
2022-06-24 07:22:47 <dhruvin> *most guile libraries that I am packaging currently
2022-06-24 07:34:24 <psykose> do you mean "@LIBDIR@/libname.so"
2022-06-24 07:36:18 <psykose> depends, i assume the bindings don't explicitly link either way.. so it's a bit hard to track in either case, to rebuild things when the version changes
2022-06-24 07:36:54 <psykose> but just .so is hard to use because then you need to depend on -dev, or every wanted lib needs to be updated to keep the .so in the main package instead, so eh
2022-06-24 07:37:16 <psykose> you do want @LIBVERSION@, but i can't think of a good way to track it without explicit linking
2022-06-24 07:38:16 <psykose> and also @LIBVERSION@ is not necessarily consistent- some things have for instance .8 -> .8.2, on upgrade .8 -> .8.3, in this case you want it to be "8" and not the full string
2022-06-24 07:38:33 <psykose> some thing have just .8.2 and then become .8.3.. there you want the full string
2022-06-24 07:38:33 <psykose> etc
2022-06-24 07:58:43 <lmarz> psykose: thank you very much :)
2022-06-24 07:59:03 <psykose> :)
2022-06-24 07:59:38 <psykose> you should open an upstream issue for it
2022-06-24 08:02:00 <lmarz> i'm on it
2022-06-24 09:54:08 <dhruvin> psykose: no, it indeed is "@LIBDIR@/libname" (no .so at the end)
2022-06-24 09:54:16 <dhruvin> for example: https://notabug.org/guile-sqlite3/guile-sqlite3/src/master/sqlite3.scm.in#L128
2022-06-24 09:55:11 <psykose> what does that load
2022-06-24 09:56:01 <psykose> ah
2022-06-24 09:56:14 <psykose> it looks like.. actual linking? then there is nothing to change
2022-06-24 09:56:22 <dhruvin> While with sqlite3-dev it loads available libsqlite3.so.<version> (following the symlinks), but with just sqlite3-libs it can't do that.
2022-06-24 09:57:16 <dhruvin> I need to name it just "libsqlite3" or "/path/to/libsqlite3.so.<version>"
2022-06-24 09:57:18 <dhruvin> Right?
2022-06-24 09:58:34 <psykose> i don't have the slightest idea how guile works
2022-06-24 09:59:12 <psykose> it's an actual shared elf object, but it has no DT_NEEDED (just built guile-sqlite3)
2022-06-24 09:59:51 <psykose> https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Low-level-dynamic-linking.html
2022-06-24 10:00:03 <psykose> why do they call it dynamic-link when the actual thing probably just dlopens() at runtime?
2022-06-24 10:01:00 <dhruvin> I don't know about it either.
2022-06-24 10:01:25 <dhruvin> I'll ask guile community about what's best can be done
2022-06-24 10:05:18 <dhruvin> Setting guile aside, lets say if python or some other language were to dlopen a "libname" (without path or version number) would that be wrong somehow? Since at the time of building the package, one would know if the linked lib is failing or not in check step.
2022-06-24 10:10:24 <psykose> i don't think pure-c dlopen() can open `lib` instead of `lib.so` at least, i don't think it does fuzzy lookups
2022-06-24 10:10:28 <psykose> i could be completely wrong though
2022-06-24 10:11:07 <psykose> i'm just assuming the guile `lib` gets translated into .so/.dylib whatever dependent on platform, auto-appended, if you don't specify, of course i'm just guessing but, it would make sense
2022-06-24 10:13:30 <psykose> and then if you manually rewrite it to the full string, it would load that. that would be fine, but the issue is there isn't a good way of tracking that for rebuilds
2022-06-24 10:13:44 <psykose> you can add the same so:libxyz.so.1 into depends=, then it gets caught by the usual way of checking revdeps
2022-06-24 10:15:08 <psykose> but it has to be manually edited aside from a rebuild each time, and iirc if you upgrade some library that changes soname, and then forget to bump that, then even in ci it would pass because it would just install the old one that also still exists as a package (unless again, i'm wrong and it was actually purged, but most likely not). so it's quite easy to miss
2022-06-24 10:15:16 <psykose> but tl;dr just do whatever, i guess it's fine
2022-06-24 10:16:06 <dhruvin> Wow tl;dr was too different from what you said :)
2022-06-24 10:16:23 <dhruvin> thank you so much for your inputs
2022-06-24 10:17:57 <psykose> and i think even on the builders, until the cycle is done, both old and new lib will exist.. so it will rebuild successfully against the old one, then the old one will vanish and it will become uninstallable. funny :p
2022-06-24 10:22:51 <dhruvin> i think i'll submit all guile packages with one fixed way of specifying system dependencies. if later we discover that what I did was bad, I can change them all at once.
2022-06-24 10:23:14 <dhruvin> I see nyxt has similar so:libname.so issue
2022-06-24 10:23:32 <dhruvin> Not sure if it's because sbcl that it uses
2022-06-24 10:24:45 <psykose> ah, yeah, nyxt does it exactly like how we're discussing here
2022-06-24 10:24:48 <psykose> that's fine
2022-06-24 10:27:15 <dhruvin> alright, I'll go with your suggestion and follow nyxt's suite
2022-06-24 18:35:29 <nmeum> dhruvin psykose: regarding guile I opened https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49232 last year. no response from upstream though
2022-06-24 18:35:45 <nmeum> might be related
2022-06-24 18:36:18 <psykose> yeah, it's the exact issue :) completely related
2022-06-24 18:36:26 <psykose> and yeah, sadly we just have to manually patch things
2022-06-24 18:38:29 <nmeum> I think we can just patch guile's load-foreign-library to also perform a fuzzy search like python does
2022-06-24 18:42:22 <psykose> i suppose that works, but doesn't that technically just load anything
2022-06-24 18:42:41 <psykose> as in, it's not much different than having the bare .so's be there for it
2022-06-24 18:43:58 <nmeum> I just want it to also load libfoo.so.23.42 (i.e. versioned sonames) instead of just libfoo.so
2022-06-25 00:15:53 <timlegge> getting error on PR : fatal: unsafe repository ('/builds/timlegge/aports' is owned by someone else)
2022-06-25 00:16:23 <timlegge> !35655
2022-06-25 00:53:07 <psykose> your branch is like 10k commits behind
2022-06-25 00:53:12 <psykose> update it and it'll be fixed :)
2022-06-25 00:53:59 <psykose> there was a specific git fix in the runner template, but the template is based on the actual history of the branch that is being built
2022-06-25 14:12:31 <dhruvin> nmeum: this also applies to guile extensions as they don't load versioned .so too.
2022-06-25 14:13:17 <dhruvin> e.g. guile-avahi needs this version fix.
2022-06-25 14:15:37 <Sheila> Thinking about dropping perl-io-async to unmaintained/ because it's been A While and there's been no movement on the perl-future-io issue that's preventing me from bumping it…and nobody seems to be using it anyway.
2022-06-25 14:18:01 <ikke> perl-net-async-http uses it as a dependency
2022-06-25 14:18:12 <ikke> Also maintained by you
2022-06-25 14:19:14 <Sheila> yup, would be dropping it as well.
2022-06-25 14:19:50 <ikke> If you think it's not used, go ahead and move it
2022-06-25 14:22:55 <Sheila> tbh the only reason it's in Alpine is because I wanted it for my bot…which just uses CPAN directly these days thanks to local::lib :)
2022-06-26 00:25:25 <timlegge> psykose: thanks, not sure how I missed that
2022-06-26 13:50:58 <elibrokeit> psykose: if there was ever a valid use case for dlopen() loading "xyz" instead of "libxyz.so.1" then it could just load "libxyz.so" :) of course then it would require the -dev package. There is some software that does this for ctypes loading (which doesn't need rebuilding)
2022-06-26 14:57:46 <tomalok> I've probably asked this question a couple years ago -- but could someone remind me why DNOTIFY is disabled in the kernels?
2022-06-26 15:02:46 <psykose> superseded by inotify?
2022-06-26 15:07:41 <tomalok> that has been the story for a while -- but unfortunately the official cachefilesd requires dnotify.  i've forked cachefilesd-inotify some time ago, but i'm wondering if my dnotify->inotify conversion works as expected and is at least as performant as the dnotify version
2022-06-26 15:10:46 <tomalok> the patch, fwiw: https://gitlab.com/tomalok/cachefilesd-inotify/-/commit/d1800571cbe5a079aa5793117a4f7328684e1595
2022-06-27 07:44:40 <ncopa> tomalok: the thing is that inotify replaced dnotify like a decade ago. We actually never enabled dnotify, because we didnt have any packages using it.
2022-06-27 07:45:02 <ncopa> well, actually there was one, and it was nfs-utils
2022-06-27 07:45:12 <ncopa> but it has been fixed now to use inotify
2022-06-27 07:46:01 <ncopa> using inotify is likely the proper fix
2022-06-27 07:46:10 <ncopa> iirc, dnotify is problematic
2022-06-27 11:17:16 <Wyk72> hello 
2022-06-27 11:18:09 <Wyk72> I have a problem bootstrapping the cross compiler (from aports) for the armhf architecture (from x86_64)
2022-06-27 11:18:45 <Wyk72> the script gives out an error while relinking:
2022-06-27 11:18:48 <Wyk72> libtool: install: warning: relinking `libopcodes.la' libtool: install: (cd /home/builder/aports/main/binutils/src/binutils-2.38/opcodes; /bin/sh /home/builder/aports/main/binutils/src/binutils-2.38/opcodes/libtool  --silent --tag CC --mode=relink armv6-alpine-linux-musleabihf-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 --sysroot=/home/builder/sysroot-armhf -Os -fomit-frame-pointer -release 2.38 --sysroot=/home/
2022-06-27 11:19:10 <Wyk72> this error:
2022-06-27 11:19:20 <Wyk72>  "/usr/lib/libgcc_s.so.1: file not recognized: file format not recognized"
2022-06-27 11:19:39 <Wyk72> has soemthing to do with 64bit/32bit gcc ?
2022-06-27 11:33:01 <Wyk72> should I use qemu instead for cross-compiling ?
2022-06-27 11:45:41 <ncopa> a bug in boostrap.sh script is not unlikely
2022-06-27 11:58:44 <ikke> Wyk72: yes, we do not provide a general purpose cross-compiler 
2022-06-27 11:59:01 <Wyk72> ncopa : thanks
2022-06-27 11:59:16 <Wyk72> ikke: thanks, I'll go for qemu-arm then
2022-06-27 12:56:16 <Cogitri> ikke: Can I somehow get Gitlab‘s CI to always pull an image? I‘ve updated my CI image but it doesn’t like to download the new version and keeps using the old one
2022-06-27 12:57:02 <Hello71> possibly if you press "clear runner caches"
2022-06-27 12:58:24 <ikke> Cogitri: the runners pull-policy defines that 
2022-06-27 12:58:36 <Cogitri> Hello71: Let me try that
2022-06-27 12:59:04 <ikke> We set it to if-not-exists due to dockers rate limiting 
2022-06-27 13:46:36 <bl4ckb0ne> anybody tried to build valve proton on alpine?
2022-06-27 14:04:49 <Cogitri> Hello71: Unfortunately clearing the cache doesn’t fix it
2022-06-27 14:05:11 <Cogitri> ikke: Hm, I need to give the new tag a different name then?
2022-06-27 15:17:10 <orbea> bl4ckb0ne: proton didn't build on gentoo last time I tried either
2022-06-27 15:17:51 <bl4ckb0ne> seems to be requiring a container to build
2022-06-27 15:17:59 <bl4ckb0ne> i smell libc errors
2022-06-27 15:25:51 <orbea> i would not be surprised if valve has a lot of questionable code changes
2022-06-27 15:32:54 <bl4ckb0ne> seems to derive debian
2022-06-27 15:33:04 <bl4ckb0ne> smells like a no go for alpine
2022-06-27 15:35:37 <orbea> i was under the impression they switched to arch, but not 100% on that
2022-06-27 15:36:54 <bl4ckb0ne> i think it's just to build one thing but i don't have the time to investigate right now 
2022-06-27 15:36:56 <bl4ckb0ne> https://github.com/ValveSoftware/Proton/blob/75231818302bdf746d79ddf76e241363b9e2b5e8/docker/Makefile#L10
2022-06-27 15:38:07 <orbea> oh...
2022-06-27 15:38:13 <orbea> so ubuntu docker on arch? :P
2022-06-27 15:39:01 <bl4ckb0ne> looks like it
2022-06-28 04:11:56 <tomalok> ncopa: https://pkgs.alpinelinux.org/packages?name=cachefilesd*&branch=edge&repo=community&arch=x86_64 is the the latest non-patched cachefilesd which does depend on dnotify -- but maybe no one apart from me ever tried to use it (or is rolling their own kernel with it enabled)...
2022-06-28 07:50:58 <PureTryOut> What is the best way to replace the last occurance of a . for a -? For a `$pkgver` variable
2022-06-28 07:53:36 <psykose> 's/\(.*\)\./\1-/'
2022-06-28 07:54:08 <psykose> but if you are calling sed that would be top-level and an exec
2022-06-28 07:54:09 <psykose> hmm
2022-06-28 07:56:13 <psykose> ${_pkgver%.*}-${pkgver##*.}
2022-06-28 07:59:53 <PureTryOut> Oh that one works, nice!
2022-06-28 09:19:26 <ncopa> tomalok: it will not work on our kernel, but maybe it works on rpi kernel and maybe it is used in a docker container on host with non-alpine kernel?
2022-06-28 11:05:46 <Cogitri> ikke: Is it problematic to run glibc containers on the Alpine gitlab runners? I’m getting some really odd „file not found“ errors
2022-06-28 11:06:46 <psykose> shouldn't be.. what are the errors and what are you running
2022-06-28 11:12:18 <Cogitri> I’m trying to run a binary built in a debian container in CI and it fails with „No such file or directory“, as if I was trying to run a glibc binary on a musl system
2022-06-28 11:13:49 <psykose> can you link the ci job shell block thing
2022-06-28 11:14:26 <psykose> the definition for it, whatever it's called
2022-06-28 11:18:43 <Cogitri> Ah, it's a meson test, so I can't link to the shell comman directly
2022-06-28 11:19:00 <Cogitri> Let me try using my debian virtual server for the test
2022-06-28 11:23:41 <psykose> i mean the entire ci running definition thing, which would also have what you're invoking
2022-06-28 11:23:46 <psykose> then i can perhaps also try random stuff
2022-06-28 11:30:41 <Cogitri> Seems like the same error happens on a Debian CI runner so it’s probably me doing something wrong - odd though since it works on my local machine with docker
2022-06-28 11:30:50 <Cogitri> psykose: Thanks for the help though :)
2022-06-28 11:30:59 <psykose> you could also post it and i'd give it a sanity check reee
2022-06-28 11:31:01 <psykose> :)
2022-06-28 11:32:32 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/apk-polkit-rs/-/blob/d7cbfc9a117b12354d3018aadacd3c96c9fbcd31/.gitlab-ci.yml :)
2022-06-28 11:37:31 <psykose> the first error i see is that it can't find the xml file, unless that log is printed wrong and it means appstream-util is the real failure
2022-06-28 11:56:32 <Cogitri> <psykose> "the first error i see is that it..." <- The file does exist - the „No such file or directory“ error refers to appstream-util not being found for some reason
2022-06-28 11:56:37 <Cogitri> Ah whoops, sorry for quoting
2022-06-28 11:57:25 <psykose> ah
2022-06-28 11:58:05 <psykose> if you `file` the appstream-util what do you get
2022-06-28 12:00:22 <psykose> if i pull cogitri/apk-polkit-rs-ci:debian-161 appstream-glib is not there
2022-06-28 12:00:30 <psykose> er
2022-06-28 12:00:38 <psykose> mistyped it lol
2022-06-28 12:00:43 <psykose> but yeah seems to work
2022-06-28 12:00:43 <psykose> hm
2022-06-28 12:05:19 <Cogitri> Yeah, it’s really odd
2022-06-28 12:11:07 <psykose> i started the container, cloned it and ran it by hand
2022-06-28 12:11:11 <psykose> as i guessed, the xml is not there
2022-06-28 12:11:45 <psykose> you run `meson build`, that doesn't build the project
2022-06-28 12:12:19 <psykose> then when you run the test after, it starts building it, but i guess the test that depends on the .xml being generated in the build, hasn't had it be generated yet
2022-06-28 12:12:33 <psykose> this is either a dependency order issues, or just.. needing to build it first
2022-06-28 12:12:39 <psykose> but i would guess it's the latter
2022-06-28 12:13:14 <psykose> replace `meson build` with `meson setup build && env LD_LIBRARY_PATH=/usr/local/lib/x86_64-linux-gnu ninja -C build && ..`
2022-06-28 12:14:19 <psykose> that would fix the order issue regardless of it being the dependency fault or not, but it's not terribly.. expected? to test in the same invocation anyway, so it would be fine
2022-06-28 12:14:52 <psykose> Cogitri: ^ :)
2022-06-28 12:15:49 <psykose> then the tests fails for entirely unrelated reasons, so i guess then you can work on those
2022-06-28 12:17:19 <psykose> and to be more clear (in case you didn't know) `build` is not a meson command, and unknown commands get implicitly rewritten to `meson setup $thing`, which sets up the build dir and configures it
2022-06-28 12:25:00 <psykose> or, you can use: https://img.ayaya.dev/we1la7q4nYYJ . that also fixes it, but you should really split the build step anyway
2022-06-28 12:36:02 <Cogitri> psykose: Oh huh, how did that ever work :D
2022-06-28 12:36:14 <Cogitri> Thanks,let’s see if that fixes it already :)
2022-06-28 12:36:27 <psykose> test implicitly builds and tests at the same time, but of course that needs deps to be right.. i don't think i've ever seen anyone add depends: for tests, haha
2022-06-28 12:54:39 <Cogitri> Yeah I guess that was just broken since forever and some internal change in meson bricked it entirely
2022-06-28 12:56:30 <Cogitri> Somehow I didn’t consider that at all :D
2022-06-28 16:13:23 <Ermine> psykose: may I ask you to review !35144 ?
2022-06-28 16:16:14 <psykose> success
2022-06-28 16:16:48 <Ermine> Yay, thank you!
2022-06-28 18:20:28 <tomalok> ncopa: mounting NFS with fscache enabled and running cachefilesd (either original dnotify or the inotify version in testing) in a container doesn't exactly seem like the thing one would do...  but who am i to judge?  ;)
2022-06-28 19:11:12 <PureTryOut> psykose: so, trying to de-vendor some stuff in testing/organicmaps like you suggested, but my C++ knowledge is lacking bad. In https://github.com/organicmaps/organicmaps/blob/master/editor/xml_feature.cpp#L372 it does a call to `set_value()`but fails as it can't convert whatever `key.data()` kind of type is to double/float. It suggests dereferencing it which I did (`set_value(*(key.data()), key.size())`) but then it complains that the
2022-06-28 19:11:12 <PureTryOut> function fall is ambiguous, as the same function can accept both a double and a float, and it doesn't know which one to take
2022-06-28 19:11:25 <PureTryOut> I don't think it matters really but I'm unsure how to tell it to convert to either one of them
2022-06-28 19:11:50 <PureTryOut> Strangely the vendored version of pugixml (which is the package I'm de-vendoring currently) is the same version as we have in Alpine, so I'm unsure why it complains about this stuff at all
2022-06-28 19:19:05 <PureTryOut> `no known conversion from 'std::basic_string_view<char>::const_pointer' (aka 'const char *') to 'double' for 1st argument; dereference the argument with *`
2022-06-28 19:20:04 <Habbie> a dereference is not going to fix that
2022-06-28 19:20:58 <Habbie> it's weird that double/float even come up here
2022-06-28 19:31:19 <PureTryOut> yeah I'm unsure what's happening here
2022-06-28 19:32:54 <Hello71> PureTryOut: just because they say it's the same version doesn't mean it is
2022-06-28 19:33:25 <PureTryOut> true, but then again it is. It's a git submodule, they're not actually vendoring in the sense of having copied the code into their tree
2022-06-28 19:33:50 <Hello71> https://github.com/organicmaps/organicmaps/tree/master/3party/pugixml  pugixml @ effc46f 
2022-06-28 19:33:59 <Hello71> https://github.com/organicmaps/pugixml/commits/effc46f0ed35a70a53db7f56e37141ae3cb3a92a "Added bool set_value(const char_t* rhs, size_t sz)."
2022-06-28 19:35:13 <PureTryOut> oh wait nvm, you are right, they just moved to a fork in their own org
2022-06-28 19:35:25 <Habbie> hidden vendoring ;)
2022-06-28 19:36:26 <PureTryOut> yup...
2022-06-28 19:37:08 <PureTryOut> at least they're upstreaming that change, https://github.com/zeux/pugixml/pull/490
2022-06-28 19:40:05 <PureTryOut> good find, thanks!
2022-06-28 19:43:51 <Hello71> :)
2022-06-28 19:52:20 <PureTryOut> different question, seems rootbld refuses to use a package from community (locally built) in a package from testing. It just keeps using the Alpine package rather than my local one. `abuild -r` however works fine. How can I make rootbld pick up my local repos?
2022-06-28 19:52:46 <panekj> edit .rootbld-repositories 
2022-06-28 19:53:09 <panekj> in aports/{main,community,testing}/.rootbld-repositories
2022-06-28 19:54:10 <PureTryOut> ah thanks. Bit annoying that I have to remember to undo the change before committing though...
2022-06-28 19:54:32 <PureTryOut> (or well, not stage that particular file)
2022-06-28 19:55:43 <panekj> you can add it to your local git exclude config
2022-06-28 19:56:22 <PureTryOut> TIL that's a thing, will look it up
2022-06-28 19:59:56 <panekj> it's just .gitignore but in $GIT_DIR/info/exclude and it's not version controlled
2022-06-28 20:05:38 <PureTryOut> Yeah found it, exactly what I need thanks
2022-06-29 09:17:53 <PureTryOut> I have trouble convincing a developer of an upstream project to support linking to system-provided libraries rather than vendoring their own 😅 Could anyone help out by any chance? https://github.com/organicmaps/organicmaps/pull/2863
2022-06-29 09:20:09 <sam_> i like to use the portability argument: if a bug gets found in a library when porting to a new platform, you don't have to then patch 100s of individual packages. but tbh it looks like they're not going to budge
2022-06-29 09:20:13 <sam_> they could very easily just take your PR but say it's not preferred 
2022-06-29 09:26:02 <PureTryOut> Yeah I'm not sure what would convince them. I don't like this mindset developers are getting more and more nowadays
2022-06-29 09:27:18 <PureTryOut> if they don't accept this PR I'll have to ship the patch downstream forever 😢
2022-06-29 10:05:06 <panekj> I just patch out the libs, if they are arguing about why it's better, you are not going to convince them since they do not try to understand your point of view
2022-06-29 10:05:24 <panekj> just another jwz situation
2022-06-29 10:09:08 <PureTryOut> jwz?
2022-06-29 10:09:23 <panekj> https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
2022-06-29 10:09:55 <panekj> unfortunately it's something that influences devs to distrust/work against distributions
2022-06-29 10:11:17 <skarnet> if you're going to argue for distributions, choose another example, because jwz is right more often than not, and in this case, he is
2022-06-29 10:12:37 <skarnet> vendoring dependencies is a whole other matter than packaging decently up-to-date software
2022-06-29 10:13:08 <panekj> I'm just saying that post is influencing people in wrong way
2022-06-29 10:14:59 <skarnet> then it's on people who misinterpret what he's saying, not on jwz
2022-06-29 10:15:11 <skarnet> the post is pretty clear
2022-06-29 10:17:53 <PureTryOut> Ah yeah I know that blog post, and I do agree with that author of it lol. Shipping a 6 year old version while plenty new versions have been made is wrong imo
2022-06-29 10:18:42 <PureTryOut> Both sides have to work together on this
2022-06-29 10:19:45 <skarnet> PureTryOut: you definitely have a difference of pov and nobody's wrong, writing a post in the gh issues atm
2022-06-29 10:23:51 <panekj> I would say, stop trying to convince them what they ship, say that we cannot use prebuilt binaries by them and that we have to link to system libs. end of story.
2022-06-29 10:27:36 <PureTryOut> skarnet: yeah that's the pain of arguing there, they are not wrong and I get why they wouldn't like changing their approach. But from my side their approach is not workable 😅
2022-06-29 10:28:20 <PureTryOut> panekj: I was going towards that. In my last comment I already told them that it's fine for them to not accept the change, and I'll deal with it downstream (either by not shipping the application or patching it)
2022-06-29 10:34:08 <skarnet> there, posted something, now everyone can get mad at me for pontifying without solving the problem
2022-06-29 11:25:19 <skarnet> small bugfix MR: !35759
2022-06-29 11:31:06 <PureTryOut> skarnet: nah it's a good answer. We'll see what happens, I'll ship the patch downstream if need be
2022-06-29 11:47:23 <Ermine> skarnet: jwz was talking about that outdated version of his software makes him waste time while working with bug reports. But isn't this what bootles developers were talking about in their open letter?
2022-06-29 11:50:31 <skarnet> Ermine: bootles? open letter? I'm afraid I don't know that story
2022-06-29 11:51:24 <panekj> s/bootles/bottles ?
2022-06-29 11:51:37 <panekj> https://usebottles.com/blog/an-open-letter/
2022-06-29 11:52:01 <Ermine> panekj: yeah, thank you
2022-06-29 11:56:54 <skarnet> well I understand where they're coming from, but I have little sympathy for them because pinning versions of your dependencies is terrible engineering
2022-06-29 11:57:43 <skarnet> basically they're saying "we bit more than we could chew, pinning stuff and doing it our way is the only way we can kinda control things, please don't make it more difficult for us"
2022-06-29 11:58:01 <skarnet> which, yeah, but also, get good son
2022-06-29 11:59:21 <skarnet> complaining about not being able to keep up with updated deps != complaining because distros package 3-years-old versions of your software
2022-06-29 12:41:22 <elibrokeit> it's a lot worse, they are complaining that some distros are building bottles against "too old" versions of their deps.
2022-06-29 12:41:33 <elibrokeit> they don't want pinned deps, they want *minimum* deps
2022-06-29 12:41:49 <elibrokeit> so... just specify a gosh-darned minimum version in the build system???
2022-06-29 12:42:01 <elibrokeit> and remove the ability to disable features???
2022-06-29 12:42:52 <skarnet> elibrokeit: that's not what I read in the open letter, they make no mention of versions
2022-06-29 12:43:07 <sam_> they did though
2022-06-29 12:43:18 <sam_> they specifically said missing or incorrect dependencies wrt older versions
2022-06-29 12:43:45 <skarnet> "Bottles is a complex software that receives frequent updates and requires several dependencies at a minimum specific version to properly work." indeed
2022-06-29 12:43:51 <skarnet> but that's still vage enough
2022-06-29 12:44:00 <skarnet> vague, even
2022-06-29 12:44:01 <rbq> ncopa: Hello, just wondering if you've seen https://github.com/vim/vim/issues/10512
2022-06-29 12:44:14 <elibrokeit> > Unfortunately, many of these unofficial packages behave abnormally due to the nature of distribution models. [...] Bottles is a complex software that receives frequent updates and requires several dependencies at a minimum specific version to properly work. For a long time, we have included workarounds in the codebase to disable features or change their behavior when dependencies are missing or incorrect. This requires extra work on ou
2022-06-29 12:45:01 <rbq> It should be related to !32894
2022-06-29 12:45:40 <elibrokeit> they are literally complaining that they are no longer willing to include workarounds for "disable features" if dependencies are missing or not "a minimum specific version"
2022-06-29 12:46:20 <elibrokeit> which okay, I absolutely agree with them, it's horrible to hack your software into little bits just to make it build using whichever deps debian oldstale has packaged
2022-06-29 12:46:37 <skarnet> oldstale :D
2022-06-29 12:46:39 <skarnet> love it
2022-06-29 13:22:40 <Ermine> Well...
2022-06-29 14:44:33 <elibrokeit> psykose, Cogitri: `ninja test` runs the "all" target first, then runs `meson test --no-rebuild`. meson test without --no-rebuild, will rebuild explicit deps of the requested tests.
2022-06-29 14:44:54 <elibrokeit> meson test is a bit more low-level and flexible :)
2022-06-29 14:59:06 <Cogitri> elibrokeit: Oh, makes sense, thanks :)
2022-06-29 15:26:58 <ncopa> rbq: no i havent
2022-06-30 10:03:03 <psykose> sam_: it has been (n + 1) amount of time and they still have not made a openssl 3.0.5 and i am astounded
2022-06-30 10:03:08 <psykose> also lol at that aliasing issue
2022-06-30 12:26:54 <sam_> psykose: seriously
2022-06-30 12:26:56 <sam_> what a joke
2022-06-30 12:27:00 <sam_> i'm still not really sure they get the point re aliasing either
2022-06-30 12:28:53 <psykose> : )))))
2022-06-30 12:45:04 <staceee> craftyguy: Hey there ! On sxmo, superd is stoped while in low battery. Didnt remember the logs I had at this point but do you knows about this ?
2022-06-30 12:45:33 <staceee> maybe some kind of critical level actions that only superd is following
2022-06-30 12:47:02 <staceee> not really the good channel sorry. Feels free to dm me directly :S
2022-06-30 12:49:28 <sam_> psykose: do u wanna join the which hunt
2022-06-30 12:49:34 <sam_> it's a lot of busywork^Wfun
2022-06-30 12:50:11 <psykose> sure love it when my process supervisor just stops working at low battery.. curious
2022-06-30 12:50:22 <psykose> sam_: which which^Wwitch hunt :p
2022-06-30 13:09:16 <skarnet> "which hunt" is "sh: which: not found" "ah shit. /usr/bin/witch" "sh: /usr/bin/which: not found" "gaaaah, is it in /bin?..." ...
2022-06-30 13:09:48 <skarnet> you'd normally do "which which" but...
2022-06-30 13:16:55 <elibrokeit> sam_: oh, are people doing that again?
2022-06-30 13:17:21 <durrendal> rbq: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35797 <- got an MR going for 2.2.6, with the x86 changes as well
2022-06-30 13:17:54 <elibrokeit> I wonder if xdg-utils will finally merge my several years old PR to fix their uses of which
2022-06-30 13:18:31 <rbq> durrendal: zstd-dev ;)
2022-06-30 13:18:54 <durrendal> and checksums lol, I'm making all the mistakes this morning
2022-06-30 13:18:54 <rbq> and of course, the sha512sum
2022-06-30 13:20:16 <durrendal> there we go, hopefully now it'll work
2022-06-30 13:20:26 <durrendal> I should have a cup of coffee before I go packaging things
2022-06-30 13:21:23 <rbq> hehe
2022-06-30 13:23:34 <rbq> Hmm, Erlang 25 also has a MR now...just a few days after I fixed something in ejabberd
2022-06-30 13:25:44 <durrendal> is the erlang package any more gnarly than the sbcl one?
2022-06-30 13:28:51 <psykose> did you mean to remove zlib for zstd entirely instead of having both
2022-06-30 13:29:09 <rbq> It was recently replicated into testing/erlang22 for something that depended on that particular version
2022-06-30 13:30:31 <rbq> psykose: Any idea what has happened to erlang's maintainer?
2022-06-30 13:30:47 <psykose> your guess is better than mine
2022-06-30 13:30:59 <durrendal> psykose: yes, I think they've moved over to zstd for core compression entirely, that's what the announce makes it seem like at least
2022-06-30 13:31:22 <durrendal> whether or not it'll build, I leave that up to the fickle whims of sbcl's build process to determine
2022-06-30 13:32:18 <durrendal> https://sourceforge.net/p/sbcl/mailman/sbcl-announce/ <- here's the announce for it
2022-06-30 13:33:31 <rbq> psykose: Just wondering, because I thought he's part of the Alpine dev team (his Gitlab.a.o profile lists a @alpinelinux.org email address)
2022-06-30 13:39:02 <rbq> OA
2022-06-30 13:39:05 <rbq> Oops
2022-06-30 13:44:22 <psykose> durrendal: makes sense, just checking
2022-06-30 13:45:16 <durrendal> I appreciate it :) I mean, I forgot to checksum before I made the MR, I'm obviously not awake yet haha
2022-06-30 14:02:19 <durrendal> rbq: https://gitlab.alpinelinux.org/durrendal/aports/-/jobs/755885#L6440 <- looks like zstb reduced the packaged by 1mb, nothing crazy, but I'll take my megabyte saving happily
2022-06-30 14:02:51 <rbq> :)
2022-06-30 14:02:59 <durrendal> https://gitlab.alpinelinux.org/durrendal/aports/-/jobs/755880#L7094 <- on x86_64 it's 10mb though, now that's more like it
2022-06-30 14:03:35 <psykose> +10MB
2022-06-30 14:03:36 <psykose> hehe
2022-06-30 14:04:12 <durrendal> oh geez, I read that wrong
2022-06-30 14:25:21 <Piraty> >< for apk-world is undocumented
2022-06-30 15:16:14 <ikke> rbq: danieli (Daniel Isaksen) is around from time to time, but does not do a lot of work on Alpine anymore
2022-06-30 15:17:35 <danieli> yeah, my focus shifted quite a while ago - I don't mind checking the MR but dropping my maintainership would also be a good idea
2022-06-30 17:30:54 <Ariadne> Piraty: it is the package unique id
2022-06-30 17:31:03 <Ariadne> (which in apkv2 is the hash)
2022-06-30 18:47:37 <sam_> elibrokeit: yes!
2022-06-30 18:47:41 <sam_> elibrokeit: i am anyway lol
2022-06-30 18:49:06 <eschwartz> sam_: sounds like fantastic fun
2022-06-30 18:49:34 <eschwartz> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=28a7e597de0d5584f65e36f9588ff9041936e617
2022-06-30 18:49:35 <sam_> so much fun
2022-06-30 18:50:13 <eschwartz> https://github.com/nodejs/node/commit/b21556d28b7be3921fa99089c61a7938811e25d1
2022-06-30 18:50:34 <eschwartz> Sadly https://gitlab.freedesktop.org/xdg/xdg-utils/-/merge_requests/24 will probably never be merged
2022-06-30 18:50:56 <eschwartz> https://github.com/emscripten-core/emscripten/commit/9d630330a6783840ecaac3d3248f1d85240c84d5
2022-06-30 19:37:17 <nmeum> Ariadne: btw: let me know if you plan to rebase the gcc patches soonish, a lot of the gcc-go patches have been merged upstream (many with some modifications) and I would like to update our patchset based on the upstreamed versions
2022-06-30 19:37:28 <Ariadne> nmeum: i already did it
2022-06-30 19:37:40 <Ariadne> nmeum: see alpine/12.1 branch
2022-06-30 19:37:59 <Ariadne> now the issue is some D bullshit :D
2022-06-30 19:38:03 <Ariadne> can we just drop D
2022-06-30 19:38:31 <nmeum> cool, I can update the gcc-go patches later then
2022-06-30 19:38:51 <nmeum> I think we actually have a few packages in aports which use D
2022-06-30 19:38:59 <Ariadne> can we drop those too :D
2022-06-30 19:39:21 <Ariadne> i think libgphobos is underlinked
2022-06-30 19:39:26 <Ariadne> i'm working on it
2022-06-30 19:39:38 <Ariadne> but dropping D would also be great
2022-06-30 19:44:10 <ikke> cogitri was using that, but I suppose he moved away from it
2022-06-30 19:47:39 <Cogitri> Yeah :/
2022-06-30 20:38:14 <BobbyTheBuilder> Hello :) `apk --no-progress --progress-fd 3 add ccache-cross-symlinks gcc-aarch64 g++-aarch64` fails with with the following errors:
2022-06-30 20:38:14 <BobbyTheBuilder> ERROR: unable to select packages: libstdc++-11.2.1_git20220219-r3: breaks: g++-aarch64-11.2.1_git20220219-r2[libstdc++=11.2.1_git20220219-r2]
2022-06-30 20:38:14 <BobbyTheBuilder> gcc-11.2.1_git20220219-r3: breaks: g++-aarch64-11.2.1_git20220219-r2[gcc=11.2.1_git20220219-r2]
2022-06-30 20:45:45 <nmeum> I don't see those packages in our repositories
2022-06-30 20:46:28 <panekj> that looks like cross-compilation things which we don't do
2022-06-30 20:46:47 <nmeum> looks like those packages are provided by postmarketos
2022-06-30 21:03:00 <BobbyTheBuilder> Ahhh, thanks for the feedback and sorry for bothering. I'll go knock on pmOS doors then.
2022-06-30 23:44:22 <rbq> ikke: Sorry for the the late reply. Thanks for looking into my question :)
2022-06-30 23:52:33 <rbq> danieli: I maintain a few Erlang-related aports (ejabberd, lfe, gleam), and was wondering if I could maintain Erlang too...but now someone else has been faster with opening an Erlang 25 MR, so maybe that must be taken into consideration