2023-08-01 02:31:17 <fluix> looks like some people (including myself, oops) say claim instead of take over
2023-08-01 02:34:26 <quinq> adopt, take on, maintain, etc.
2023-08-01 02:34:34 <zcrayfish> BDFL?
2023-08-01 02:39:07 <elibrokeit> consider the possibility that you're being yoked to it, instead
2023-08-01 02:42:23 <abby> tribute to the software deities
2023-08-01 02:53:21 <elly> you are being fed to the package
2023-08-01 04:56:44 <pj> from now on, commits should say yoink ownership
2023-08-01 04:57:27 <ikke> and yeet?
2023-08-01 04:57:30 <abby> naturally
2023-08-01 04:57:46 <pj> wow, jq upstream is alive again
2023-08-01 04:58:12 <ikke> cool
2023-08-01 05:01:02 <humm> assert ownership
2023-08-01 05:01:26 <humm> call dibs on
2023-08-01 05:10:04 <abby> be careful, that might get optimised out
2023-08-01 05:14:53 <humm> it would be disabled with NDEBUG
2023-08-01 05:15:10 <humm> that’s not optimizing out
2023-08-01 05:17:17 <abby> on python if you set higher levels of optimisation assert()s are removed
2023-08-01 05:17:25 <abby> s/()/
2023-08-01 05:21:00 <Forza> Good morning 🙏 
2023-08-01 05:21:23 <Forza> I think I made a mistake on my MR. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49369
2023-08-01 05:21:59 <Forza> It said merged blocked and that it needed rebasing
2023-08-01 05:22:36 <Forza> So I clicked it, and now it says that everyone else's changes are included? 
2023-08-01 05:24:43 <ikke> Forza: if you look at the commits tab, you see it still contains one commit
2023-08-01 05:25:22 <Forza> Oh, ok. So it's still correct? 
2023-08-01 05:25:25 <ikke> yes
2023-08-01 05:25:33 <Forza> Great. Thanks :) 
2023-08-01 05:25:37 <ikke> gitlab just shows what changes were introduced by the commits you rebased on top
2023-08-01 05:26:29 <Forza> I see. Makes sense I suppose. 
2023-08-01 05:27:02 <Forza> I'll get used to it eventually. :) 
2023-08-01 05:27:37 <ikke> fyi, it's not wrong to do, but also not necessary to rebase your own MRs. We'll do it right before merging
2023-08-01 05:28:33 <Forza> :) you merged it! 
2023-08-01 05:28:36 <ikke> yes
2023-08-01 05:29:08 <Forza> Cool. Thank you 
2023-08-01 05:29:17 <ikke> So now you are a maintainer :)
2023-08-01 05:30:38 <Forza> Haha. Hopefully i can contribute a little 
2023-08-01 07:27:09 <pj> ikke: thanks for patching procs
2023-08-01 10:07:35 <PabloCorreaGomez[m]> Newbyte and me can take maintenance over anything related to GNOME that might not have been taken by other people by the end of the week. We have a strong interest in keeping the stack up-to-date and working :)
2023-08-01 10:09:20 <PabloCorreaGomez[m]> Also ncopa I'll most likely take maintenance over glib at some point if that's fine for you. Cogitri is no longer active and the GLib maintainer upstream agreed to add support for musl to their CI, so hopefully it's very little effort to also keep the package updated in alpine
2023-08-01 10:10:37 <ncopa> sounds good to me
2023-08-01 10:10:54 <ncopa> thank you for stepping up!
2023-08-01 10:14:31 <Cogitri> Yes, thanks for taking care of it :)
2023-08-01 10:20:24 <ikke> pj: no problem
2023-08-01 10:20:32 <PabloCorreaGomez[m]> Also, if anybody else is also interested in CI, and want to help with GLib CI maintenance upstream, that'd be superb :D It's also a good showcase of the things that currently go wrong in musl, mostly locales and collation
2023-08-01 10:21:01 <PabloCorreaGomez[m]> ncopa, Cogitri: my pleasure :)
2023-08-01 10:29:29 <ikke> PabloCorreaGomez[m]: I might be able to offer some help with CI, depending on what needs to be done (and what CI system they use)
2023-08-01 10:30:21 <ncopa> https://gitlab.gnome.org/GNOME/glib/-/tree/main/.gitlab-ci
2023-08-01 10:43:26 <ncopa> more packages are orphaned: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49383
2023-08-01 10:45:14 <pj> that's a lot of packages
2023-08-01 10:45:44 <Cogitri> Oh yuck, didn’t realize Russia did that
2023-08-01 11:25:19 <PabloCorreaGomez[m]> ikke: thanks! I'll ping you then if I need any help :)
2023-08-01 12:24:56 <raspbeguy> regarding russia banning foreign org participation, wonder what's the situation on other distro
2023-08-01 12:28:13 <Newbyte> raspbeguy: "analysis" from someone I know who lives there: https://bpa.st/WRWQ
2023-08-01 12:44:47 <Ermine> Fuck
2023-08-01 12:53:51 <EvTheFuture> I will take a look when I land at home tonight and see if I can help out as well.
2023-08-01 13:03:00 <Ermine> Does Alpine have a legal entity? Foundation, or e.v. or something else?
2023-08-01 13:13:20 <andypost[m]> any idea what changed in a curl that it started to parse protocol part of URL as number? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/48961#note_325439
2023-08-01 13:16:53 <ikke> Ermine: no
2023-08-01 13:17:32 <ikke> Ermine: we did contact an organization, but nothing setup as of yet
2023-08-01 13:32:31 <Ermine> Ah ok
2023-08-01 13:38:24 <Forza> Is there a translation of those laws? 
2023-08-01 13:42:29 <elly> I think one would probably need to hear from a russian lawyer to really understand it
2023-08-01 13:43:02 <Forza> Yea. Probably 
2023-08-01 13:43:03 <Ermine> I'm going to ask one for a consultation
2023-08-01 14:42:51 <ncopa> Ariadne: do you mind if I take over binutils? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49318#note_324888
2023-08-01 16:29:17 <rootwyrm> Hey folks, could use a hand as it's been a while. I need to test a modified linux-lts for aarch64 to complete bringup. aports/scripts/bootstrap.sh aarch64 isn't working though. Starts with binutils-aarch64 and immediately errors out with 'binutils-aarch64: builddeps failed'. Host is 3.18 x86_64 with qemu, and $CBUILDROOT is set.
2023-08-01 17:02:48 <ncopa> it means it failed to install some of the dependencies for binutils-aarch64 for some reason
2023-08-01 17:07:07 <rootwyrm> Yes, but that's when it starts getting weird. Manually do the apkbuild of binutils, then it chokes "/usr/bin/abuild: line 2588: x86_64-alpine-linux-musl-strip: not found"
2023-08-01 17:10:52 <rootwyrm> Which I'm pretty sure is wrong, since $CHOST and $CTARGET are aarch64.
2023-08-01 17:25:51 <fluix> should optional dependencies be included in Python packages' depends= array?
2023-08-01 17:40:14 <minimal> they wouldn't be optional then
2023-08-01 17:42:38 <fluix> yeah, I thought maybe it would impact the pyc output but thinking again that doesn't make sense :p
2023-08-01 17:45:03 <rootwyrm> This is really making absolutely no sense. bootstrap does not work, and abuild is continually trying to mix x86_64 and aarch64.
2023-08-01 19:00:09 <Forza> Hi. If I am bumping a package to a new version, should I reset the $pkgrel to 1 in APKBUILD?
2023-08-01 19:00:16 <Ermine> to 0
2023-08-01 19:00:20 <Forza> Ah ok
2023-08-01 19:02:27 <Ermine> Forza: if bumping package version is everything you need, there's an abump command which will bump version, reset pkgrel, update checksums, check buildability and commit changes
2023-08-01 19:04:22 <Forza> Thats cool.
2023-08-01 19:05:24 <Habbie> i love abump
2023-08-01 19:05:30 <Habbie> just keep forgetting it commits and i should branch before
2023-08-01 19:07:39 <Ermine> Habbie: you can branch and then reset --hard master branch
2023-08-01 19:08:46 <Habbie> oh yes
2023-08-01 19:08:52 <Habbie> i have no trouble fixing it
2023-08-01 19:08:59 <Habbie> but i appreciate it because plenty people would get stuck there
2023-08-01 19:15:08 <humm> branches are sound and smoke
2023-08-01 19:18:05 <Forza> When I run `abuild -r`I get three warnings for "WARNING: opening /home/forza/packages//testing: No such file or directory" (testing, community, main). Is that to be expected?
2023-08-01 19:18:45 <Ermine> Yes, don't worry
2023-08-01 19:19:59 <Forza> Thanks.
2023-08-01 19:29:03 <Forza> I added "@local /home/forza/packages/testing" to /etc/apk/repositories and did `apk add package@local`, which seemed to work. Is there anything else that  should think about testing my packages before creating a MR?
2023-08-01 19:29:21 <Habbie> after apk add, start it?
2023-08-01 19:29:27 <Habbie> that's what i do for bumps
2023-08-01 19:35:02 <Forza> yes. I rebooted and checked the init.d script worked fine too
2023-08-01 19:35:27 <Habbie> in that case, nice work
2023-08-01 19:39:05 <Forza> :) Ill make the MR a bit later or maybe tomorrow. Getting late here and I need to eat some :D
2023-08-01 20:17:12 <invoked> is there a quick way (url) of seeing which packages in community don't have maintainers
2023-08-01 20:17:54 <ikke> invoked: https://pkgs.alpinelinux.org/packages?name=&branch=edge&repo=community&arch=x86_64&maintainer=None
2023-08-01 20:17:59 <invoked> thank you
2023-08-01 20:18:06 <ikke> note that it shows subpackages as well
2023-08-01 20:19:10 <invoked> oh i should have been able to answer this question myself.
2023-08-01 20:27:58 <fancsali[m]> <invoked> "is there a quick way (url) of..." <- Do a `git clone `, you'll need it anyway; and then use the good old `find` and `grep` commands...
2023-08-01 20:33:13 <invoked> fancsali[m]: it's not for me, in this case
2023-08-01 20:39:14 <fancsali[m]> <Forza> "I added "@local /home/forza/..." <- What a brilliant idea; how did I miss to do that myself? 🤦
2023-08-01 21:22:43 <Forza> To be clear on the `abump` procedure. Would this workflow be correct? I have forked aports to my personal repo, I do a `git checkout -b new-branch`, then do the abump, then a `git push -u origin new-branch` to push it up to gitlab so I can make a MR against alpine/aports there? 
2023-08-01 21:23:18 <Habbie> is origin your fork?
2023-08-01 21:25:52 <Forza> Yes 
2023-08-01 21:26:00 <Habbie> then yes
2023-08-01 21:26:10 <Forza> Great :) 
2023-08-01 21:26:22 <Habbie> :)
2023-08-01 21:26:37 <Forza> Thank you 
2023-08-01 21:27:12 <Forza> I'm not using it this time because I am also removing a patch that's no longer needed in the bumped version 
2023-08-02 06:23:05 <zcrayfish> print test
2023-08-02 06:23:17 <zcrayfish> print -buffer test
2023-08-02 12:21:51 <ichernev[m]> hello, I'm package maintainer of testing/py3-dt-schema. Recently community/py3-jsonschema was updated to 4.18 which apparently doesn't work with dt-schema (has < 4.18 in setup.py). However in here https://pkgs.alpinelinux.org/packages?name=py3-jsonschema&branch=edge&repo=&arch=&maintainer= I can only see 4.18.4-r1 and v3.18 has 4.7.2-r4 (which seems old). Is there a way to use something newer than what's in v3.18 and older than edge,
2023-08-02 12:21:51 <ichernev[m]> or edge keeps only latest?
2023-08-02 12:25:30 <ichernev[m]> this is upstream. Apparently the released jsonschema is moving in a new directions so dt-schema would need to use an old version for a while: https://github.com/devicetree-org/dt-schema/commit/188cca9ae852edf1f21906c6a2912d52dd90144b
2023-08-02 12:43:47 <ichernev[m]> is it possible to keep a single old version for the sake of dependent packages (like dt-schema). From what I understand, it uses some less popular API which has been (intentionally/by mistake) axed in a minor version. It might affect other packages, but it's hard to tell at this point.
2023-08-02 12:54:14 <pj> ichernev: it needs to be patched then or its left stale
2023-08-02 13:14:55 <ichernev[m]> pj: as far as I can tell jsonschema is already updated. That means that existing (old) dt-schema is now broken, and will remain broken until something is done...
2023-08-02 13:31:33 <ikke> ichernev[m]: in general, each branch had just a single version per package 
2023-08-02 13:37:03 <ichernev[m]> ikke: so I guess you don't make exceptions... dt-schema is useful for building the kernel (and is developed by the guy that reviews DT patches). It's not super important but it's not some random package either.
2023-08-02 13:39:56 <ikke> There may be exceptions 
2023-08-02 13:40:14 <ikke> But it means you have to duplicate the package
2023-08-02 13:45:16 <ichernev[m]> and have py3-jsonschema-4.17 package that is frozen and depend on that? So would that be OK until this thing is resolved?
2023-08-02 14:23:30 <knuxify[m]> anyone perhaps a bit more familiar with apk internals knows what might be going on here? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49435#note_325736
2023-08-02 14:24:27 <knuxify[m]> tl;dr libudev-zero gets picked instead of eudev and makes lds throw errors about libgnome-desktop-4
2023-08-02 14:24:35 <knuxify[m]> s/lds/ld
2023-08-02 14:29:51 <knuxify[m]> ...i worded this tl;dr badly
2023-08-02 14:45:07 <ncopa> i think problem is that libudev-zero claims to be ABI compatible libudev.so.1 but is not. They should have used a different ABI
2023-08-02 14:45:27 <ncopa> (which i suppose defeats the purpose of it)
2023-08-02 14:47:30 <ncopa> something like this should work around it https://tpaste.us/Vql1
2023-08-02 14:48:45 <pj> ichernev: it can be just left broken
2023-08-02 14:49:34 <pj> upstream already fixed the issue with new jsonschema but they decided to not publish it
2023-08-02 14:51:27 <ncopa> i would say that libudev-zero is harmful and should ideally be removed
2023-08-02 14:53:34 <elly> the readme for it (https://github.com/illiliti/libudev-zero/blob/master/README.md) mentions many common programs that do not work with it
2023-08-02 14:53:45 <ncopa> exactly
2023-08-02 14:53:47 <elly> at the very least that seems like an experts-only situation
2023-08-02 14:54:37 <ncopa> alpine usually dont get in the way if you want to shoot your own foot
2023-08-02 14:54:55 <ncopa> but in this case libudev-zero is shooting others foots
2023-08-02 14:55:01 <elly> sure, but we also don't usually package stuff that breaks other packages :P
2023-08-02 14:55:04 <elly> yeah
2023-08-02 14:55:46 <ncopa> i know mps (the maintainer) is using it
2023-08-02 14:55:50 <ncopa> he will not be happy
2023-08-02 14:56:34 <rootwyrm> ncopa: kernel MR question for once I finish validating; would an additional module for aarch64 be accepted for 3.18-stable or only -edge?
2023-08-02 14:57:12 <ncopa> depends a bit, but I'd say its likely to be accepted
2023-08-02 14:57:54 <ncopa> the general "rule" is that users using stable branches should be able to do apk upgrade, without risking anything to break
2023-08-02 14:58:17 <rootwyrm> OK. It's actually a really small one, just adding `CONFIG_ARM_MEDIATEK_CCI_DEVFREQ=m` and that's it.
2023-08-02 14:58:27 <rootwyrm> (At least I _hope_ that's it.)
2023-08-02 14:58:59 <ncopa> test it in edge first
2023-08-02 14:59:19 <ncopa> that looks relatively safe to backport to 3.18-stable
2023-08-02 15:00:07 <rootwyrm> should be 100% safe since it's just +1 module, but building aarch64 with qemu takes <checks watch> days.
2023-08-02 15:05:58 <ncopa> maybe create a draft MR?
2023-08-02 15:15:10 <ncopa> it will be controversial https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49437
2023-08-02 15:20:32 <ncopa> rootwyrm: I can try build arm64 kernek if you give me a patch that I can git am here
2023-08-02 15:20:52 <ncopa> eg: git format-patch -1 --stdout | tpaste
2023-08-02 15:24:48 <rootwyrm> ncopa: sure, sec, thanks!. tpaste did ... a weird.
2023-08-02 15:30:06 <ncopa> tpaste should print an url that I can `curl https://tpaste.us/... | git am`
2023-08-02 15:32:30 <rootwyrm> yeah, git branches got screwed up somehow. probably fighting with qemu.
2023-08-02 15:42:20 <rootwyrm> ncopa: https://tpaste.us/9M96
2023-08-02 15:53:25 <ncopa> what should i write as commit message?
2023-08-02 15:53:37 <ncopa> why is this needed?
2023-08-02 16:02:10 <ncopa> error: patch failed: main/linux-lts/APKBUILD:347
2023-08-02 16:02:10 <ncopa> error: main/linux-lts/APKBUILD: patch does not apply
2023-08-02 16:02:57 <ncopa> im applying it manually
2023-08-02 16:10:39 <rootwyrm> ncopa: sorry, work distracting a bit. Can write "Adds MediaTek CCI module for AMLogic s905x (aml-s905x-cc)"
2023-08-02 16:11:13 <rootwyrm> hopefully this should be the missing piece to get the mali on the s905x to init.
2023-08-02 16:16:28 <ncopa> 👍
2023-08-02 16:17:04 <rootwyrm> The good news is that if it is, I have full bringup on the Libre LePotato (aml-s905x-cc) boards. \o/
2023-08-02 16:17:35 <elly> woo!
2023-08-02 16:29:47 <Habbie> woo!
2023-08-02 16:32:34 <ikke> w00t
2023-08-02 16:39:15 <fluix> when does a CVE get added to secfixes?
2023-08-02 16:40:01 <fluix> err, meant when does a security upgrade get added to secfixes and it seems like it's when there's a CVE
2023-08-02 16:41:28 <ikke> yes
2023-08-02 16:42:45 <fluix> don't think this is really the case here, but say we're on release 1, there's a CVE fix in 2, and then 3 is released. do we upgrade to 2 with the secfix then right away to 3 or just skip to 3 (and if we skip to 3, does the secfix list 3 as the apk version the CVE is fixed in?)
2023-08-02 16:43:09 <ikke> the latter
2023-08-02 16:43:38 <ikke> The goal is not to have a separate administration what vulnerabilities were fixed in what upstream version
2023-08-02 16:43:55 <fluix> makes sense, thanks
2023-08-02 16:57:04 <minimal> ikke: you only add a secfixes entry to APKBUILD if upstream doesn't mention the CVSes in their changelog?
2023-08-02 16:57:31 <ikke> minimal: the policy so far has been to mention every CVE
2023-08-02 16:57:56 <fluix> any reason `apk info py3-flask -r` wouldn't list anything?
2023-08-02 17:00:38 <fluix> and my real question: is there some efficient way to make the commits necessary to test revdeps like those in !49275
2023-08-02 17:00:43 <ikke> fluix: I don't know why that is. `apk search -r py3-flask` works
2023-08-02 17:01:06 <fluix> thanks, maybe it's because I don't have anything _installed_ that depends on it
2023-08-02 17:01:08 <ikke> fluix: ap revdep py3-flask | xargs apkgrel -a
2023-08-02 17:01:26 <ikke> (ap is provided by lua-aports)
2023-08-02 17:01:27 <minimal> xikke: so then I don't understand the comment/changes added to this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49000
2023-08-02 17:01:47 <minimal> ikke: ^^^
2023-08-02 17:05:35 <ikke> minimal: 
2023-08-02 17:08:00 <ncopa> rootwyrm: 5b44b869206fdbdc1f013fe9c40c2aed934f35a0
2023-08-02 17:08:37 <ikke> the polich has not been changed, but psykose basically skipped them whenever the CPE doesn't match the fixed version
2023-08-02 17:08:41 <ikke> technically it's redundant  then
2023-08-02 17:09:44 <ncopa> the history of secfixes comments in APKBUILDs:
2023-08-02 17:10:23 <ncopa> at some point docker contracted a security company to scan the docker images
2023-08-02 17:10:39 <Habbie>  no good story has ever started with that sentence
2023-08-02 17:10:46 <Habbie> (but i have a few bad ones that did)
2023-08-02 17:10:48 <ncopa> they compared the version found in the image with the public CVE databases
2023-08-02 17:11:12 <ncopa> and it was actually pretty cool, IMHO. IIRC it was some antivirus company who did it
2023-08-02 17:11:26 <ncopa> they parsed the binaries
2023-08-02 17:11:45 <ncopa> and discovered issues in binaries with statically linked libs
2023-08-02 17:11:51 <ikke> fluix: tested it. Installing a revdep makes apk info -r return it
2023-08-02 17:11:52 <Habbie> oh that's neat
2023-08-02 17:11:56 <ncopa> and bundled libs
2023-08-02 17:11:59 <Habbie> doesn't match my experience with several image scanners
2023-08-02 17:12:15 <ncopa> as i said, it was actually pretty cool
2023-08-02 17:12:17 <minimal> ikke: what's CPE? in this example that 1.6.0 did fix the 3 CVEs
2023-08-02 17:12:33 <ikke> minimal: THe part of the CVE that says what versions are vulnerable
2023-08-02 17:12:51 <ncopa> but, in alpine we would ofte backport a CVE, even before the upstream had a new release
2023-08-02 17:13:08 <ncopa> and the scanner would not pick that up
2023-08-02 17:13:25 <ncopa> so it was cool, but not *that* cool
2023-08-02 17:13:42 <ncopa> and initially they would manually flag the false positives
2023-08-02 17:13:47 <ncopa> which ofc was not sustainable
2023-08-02 17:14:06 <ncopa> and we needed a way to tell the scanner(s) that we had backpoerted the fix
2023-08-02 17:14:21 <ikke> ncopa: but doesn't that mean we only have to list CVEs that we manually patch?
2023-08-02 17:14:37 <ncopa> I wanted to make it as easy as possible for the package maintainers
2023-08-02 17:14:40 <ncopa> ikke: exactly
2023-08-02 17:14:59 <ncopa> one laternative was to keep a database externally with the data
2023-08-02 17:15:16 <ikke> the questions was what CVEs we would add
2023-08-02 17:15:21 <ncopa> but it would be super easy for a package maintainer to miss that
2023-08-02 17:15:40 <ikke> the defacto practice is to list them all
2023-08-02 17:15:54 <ncopa> so we decided to add it as a comment in the APKBUILD that was parsed by a script
2023-08-02 17:16:12 <ncopa> initially, it was *only* a list of patches that got backported
2023-08-02 17:16:41 <ncopa> or a allow-list to help scanners avoid false positives
2023-08-02 17:16:56 <ncopa> it was originally not meant to be a complete database
2023-08-02 17:17:05 <ncopa> only list false positives
2023-08-02 17:17:14 <ncopa> however, many other scanners popped up
2023-08-02 17:17:17 <minimal> I remember being on a contract in 2018/2019 where I was building Alpine containers and having to deal with the output of one of the commercial security scanners (think it was Aqua) as the project in general required security audits to be passed in order to go live (and annual re-audits thereafter)
2023-08-02 17:17:30 <ncopa> and they completely missed that point
2023-08-02 17:17:33 <ncopa> and were lazy
2023-08-02 17:17:58 <ncopa> and assumed it was a complete list of all vulnerabilities in alpine
2023-08-02 17:18:03 <ikke> I think nowadays they have gotten better though
2023-08-02 17:18:08 <ncopa> and expected it to be a complete list
2023-08-02 17:18:28 <rootwyrm> ncopa: thanks!! Build will be in -edge I presume?
2023-08-02 17:18:37 <ncopa> and complained whenever it didnt match their expectations
2023-08-02 17:18:40 <fluix> ikke: thanks for the command and confirmation :)
2023-08-02 17:18:52 <ncopa> so at one point we actually did try to put everything in the secfixes comments
2023-08-02 17:19:13 <ncopa> rootwyrm: yes. should be sonnish if its not there already
2023-08-02 17:19:34 <ncopa> because that was the expectation
2023-08-02 17:19:44 <ikke> ncopa: apparently the http host header go upgrade was not done in 3.18. I suppose we need to backport the docker fix to 3.18 when we do
2023-08-02 17:20:11 <ikke> Because upstream afaik did not backport it to docker 23.x
2023-08-02 17:20:35 <ncopa> ikke: yes. we should probably do it at the "rebuild all with fixed go" stage
2023-08-02 17:20:36 <rootwyrm> ncopa: well, it takes me a bit to switch the image builder over to edge too, so it'll probably be done before I am. The aml-s905x-cc is... difficult. ;/
2023-08-02 17:21:12 <ikke> rootwyrm: are you talking about the repo or the package?
2023-08-02 17:21:27 <ncopa> (sec fixes cont....) at that time we also tracked the CVE issues manually in redmine/gitlab
2023-08-02 17:21:37 <ncopa> which also was not sustainable
2023-08-02 17:21:53 <ikke> 
ACTION still remembers someone manually creating issues for all CVEs

2023-08-02 17:22:13 <minimal> ikke: so in other words it's a policy that is not necessarily followed, so an optional policy lol
2023-08-02 17:22:22 <ncopa> it was actually pretty nice, because we got actually issues, and could mark them as fixed when they were fixed
2023-08-02 17:22:33 <ncopa> but it wasnt sustainable
2023-08-02 17:23:17 <ikke> minimal: any policy is optional if you want to
2023-08-02 17:23:20 <ncopa> so Ariadne wrote security.alpinelinux.org, which would pull in the CPE data, and compare it with our aports tree, and parsed the secixes comments and all
2023-08-02 17:23:32 <ikke> minimal: (and have the power to ignore)
2023-08-02 17:23:59 <ncopa> after that we should no longer need to note every single CVE fix in secfixes comment
2023-08-02 17:24:04 <minimal> ikke: ok, but I tend to think of a policy of being at the very least a strong recommendation
2023-08-02 17:24:34 <ncopa> but im not sure what the current defacto standard is.
2023-08-02 17:24:36 <ikke> so far we haven't received any new complaints about CVEs missing (that we actually patched)
2023-08-02 17:24:59 <ncopa> we should direct them to security.alpinelinux.org
2023-08-02 17:25:01 <ikke> ncopa: psykose has been skipping them when upgrading to a fixed version
2023-08-02 17:25:02 <ncopa> and keep that updated
2023-08-02 17:25:07 <ncopa> yeah
2023-08-02 17:25:09 <ncopa> i figured
2023-08-02 17:25:17 <ncopa> which is good, IMHO
2023-08-02 17:25:20 <ncopa> less work for us
2023-08-02 17:25:22 <ikke> yes
2023-08-02 17:25:41 <ncopa> so I say we keep doing that
2023-08-02 17:25:55 <ikke> I also have a plan to prune the existing ones that are no longer relevant
2023-08-02 17:26:04 <ikke> some packages have very long lists
2023-08-02 17:26:04 <ncopa> and if someone complains we point them to security.alpinelinux.org
2023-08-02 17:26:18 <ncopa> and make sure that site is up-to-date
2023-08-02 17:26:21 <ikke> security.a.o also needs to be improved
2023-08-02 17:26:30 <ncopa> i have a few... yes exactly
2023-08-02 17:26:40 <ncopa> there is where we should put our efforts
2023-08-02 17:26:57 <ncopa> not do more manual work in APKBUILD's secfixes comments
2023-08-02 17:26:57 <ikke> ncopa: what are your suggestions for improvmenet?
2023-08-02 17:27:28 <ikke> secfix comments still make sense when we manually patch a version 
2023-08-02 17:27:38 <ncopa> yes, ofc
2023-08-02 17:27:47 <ncopa> or if security.a.o gets things wrong
2023-08-02 17:27:48 <ikke> but otherwise, it being outside the vulnerable versions should suffice
2023-08-02 17:28:14 <ncopa> one thing i miss from the manual days, is that back then the issue would be closed immediatly
2023-08-02 17:28:33 <ncopa> there is a delay after fix is pushed til its visible on the secuerity.a.o site
2023-08-02 17:28:45 <ikke> yes, there is a cron job running every hour
2023-08-02 17:28:57 <ncopa> which means that if you spend a half day only fixing things
2023-08-02 17:29:07 <ikke> But nothing prevents something like a webhook (or listening to msg.a.o) to update it immediately
2023-08-02 17:29:10 <ncopa> its difficult to see what you recently fixed and whats still unfixed
2023-08-02 17:29:57 <ncopa> i think it would be nice to have it updated on each git push
2023-08-02 17:30:37 <ikke> I'll see if (when I have some time) I can look into setting up mqtt-exec to do that
2023-08-02 17:30:49 <ikke> or something like that
2023-08-02 17:31:25 <ikke> And we need a better way to fix package mappings
2023-08-02 17:31:42 <ikke> we tried to fix some, but for some reason it was not working
2023-08-02 17:32:15 <ncopa> second thing would be a better way to get a better report per package
2023-08-02 17:32:15 <rootwyrm> ikke: the repo I'd presume, since the image build process involves using chroot and some fakery.
2023-08-02 17:32:38 <ikke> rootwyrm: right, that's correct then
2023-08-02 17:32:56 <ikke> because you called it '-edge', it appeared you might have meant linux-edge
2023-08-02 17:33:10 <ncopa> for example: https://security.alpinelinux.org/srcpkg/samba
2023-08-02 17:33:31 <minimal> what about when there's a CVE for a package's version but the Alpine package doesn't actually enable/have the affected functionality? (e.g. say a particular util in Busybox but Alpine config doesn't enable that util? I assume still add a SecFixes entry even though no fix is actually made/required?
2023-08-02 17:33:41 <ncopa> there is a list of unfixed issues, but it would be nice to know exactly what git branches are unfixed
2023-08-02 17:33:58 <ikke> minimal: we mark that one as version 0
2023-08-02 17:34:13 <ncopa> minimal: thats a case for secfixes comment, where we mark which alpine version has it fixed
2023-08-02 17:34:23 <ncopa> and version 0 means it never ever affected us
2023-08-02 17:34:41 <ncopa> for the given branch that is
2023-08-02 17:34:50 <ikke> We also have a global secfix rejection repo
2023-08-02 17:35:17 <ncopa> which we may use for "disputed" issues
2023-08-02 17:35:31 <ncopa> where someone claims something is a security issue when it is not
2023-08-02 17:35:40 <ikke> ncopa: re samba: you mean it would be nice to group them by branch, right?
2023-08-02 17:35:46 <ncopa> because they never delete anything from CVE database, only mark it as disputed
2023-08-02 17:35:50 <ncopa> yes
2023-08-02 17:35:55 <ncopa> one way or the other
2023-08-02 17:35:55 <minimal> is this documented anywhere for those of us who have run out of freespace in their head? ;-)
2023-08-02 17:36:19 <ncopa> i doubt it is
2023-08-02 17:36:28 <ichernev[m]> <pj> "upstream already fixed the issue..." <- can you elaborate on that? You mean the port of dt-schema that uses the new `referencing` library? I asked here if it can be shared: https://github.com/devicetree-org/dt-schema/issues/109
2023-08-02 17:36:51 <ncopa> minimal: maybe you could create an issue at an appropriate place where we document those things?
2023-08-02 17:36:57 <ikke> Working on it
2023-08-02 17:37:38 <minimal> ncopa: you mean if I remember to do so? ;-)
2023-08-02 17:37:43 <ikke> https://gitlab.alpinelinux.org/alpine/docs/developer-handbook/-/issues/6
2023-08-02 17:37:44 <ncopa> lol
2023-08-02 17:38:12 <ncopa> ikke: i was wondering if it would make sense to have that on security.a.o site
2023-08-02 17:38:23 <minimal> <walks out of room and promptly forgets why he left the room>
2023-08-02 17:38:51 <ncopa> ikke: what I'd like, is the site be nicer for the ppl who fixes the issues
2023-08-02 17:38:54 <ikke> ncopa: I think it would be good to have a central place for documentation. We could link to it from security.a.o
2023-08-02 17:39:05 <ncopa> good point
2023-08-02 17:39:19 <rootwyrm> ikke: oh, yeah, no... sorry, did mean -edge repo. the way the image builder works currently is off latest-releases.yaml
2023-08-02 17:39:56 <ikke> ncopa: agreed. I think what's now on security.a.o was an MVP
2023-08-02 17:40:05 <ncopa> yeah
2023-08-02 17:40:18 <ncopa> i think we should create issues for the things we want to improve
2023-08-02 17:40:25 <ncopa> and maybe ask for help on alpine-devel
2023-08-02 17:40:37 <ikke> ncopa: you read my mind
2023-08-02 17:40:54 <ncopa> i intend to write an email and ask for help with package maintenance
2023-08-02 17:41:09 <ncopa> but now i need to call it a day
2023-08-02 17:41:18 <ncopa> i better continue tomorrow
2023-08-02 17:41:34 <ikke> Ah, I see you created https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker/-/issues/12 already
2023-08-02 17:41:43 <ikke> and some others
2023-08-02 17:41:52 <ncopa> cool. i completely forgot those
2023-08-02 17:42:56 <ncopa> no testsuite. makes me nervous
2023-08-02 17:43:08 <ncopa> oh, i forgot that I need to go. have a nice evening!
2023-08-02 17:43:15 <ikke> https://gitlab.alpinelinux.org/alpine/security
2023-08-02 18:10:52 <fancsali[m]> Anyone care to have a look at my MR, I was discussing with psykose before their departure from the project?
2023-08-02 18:10:52 <fancsali[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49265
2023-08-02 18:11:17 <fancsali[m]> Also, I am happy to pick up `gpsbabel`: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49439.
2023-08-02 18:13:44 <pj> fancsali: you need to make it build and not use precompiled jar
2023-08-02 18:20:06 <pj> this should also run tests from upstream
2023-08-02 18:23:01 <fancsali[m]> Well, what's the benefit of that? Someone has already done the heavy lifting for us on their machine...
2023-08-02 18:23:45 <ikke> fancsali[m]: better for the ecosystem if more then only them can build from source
2023-08-02 18:24:05 <fancsali[m]> pj: Okay, will check what tests are available. Although again, I assume those have been run as part of their build pipeline. 
2023-08-02 18:24:19 <pj> also it would be good to not use matrix features
2023-08-02 18:24:27 <pj> since this place is bridged to IRC
2023-08-02 18:24:54 <fancsali[m]> Ok. Got you ‐ stick to plaintext!
2023-08-02 18:24:58 <pj> as for the package: building from source ensures that you have built the code and not get a program that does completely different thing
2023-08-02 18:25:18 <pj> you also need to build from source to run tests
2023-08-02 18:27:01 <ikke> fancsali[m]: not the first time that building and running tests on alpine has found issues that upstream didn't find
2023-08-02 18:27:42 <ikke> and it also may catch issues that are specific to Alpine Linux
2023-08-02 18:27:49 <fancsali[m]> pj & ikke: okay – fair points.
2023-08-02 18:28:38 <pj> also: building from source builds with our configuration, it may not matter as much for java software but its best to align with our configuration
2023-08-02 18:30:26 <fancsali[m]> Shall we put those on the wiki somewhere? Happy to do the edits, if you van point me to the right page. Perhaps https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Code_review or https://wiki.alpinelinux.org/wiki/Package_policies?
2023-08-02 18:31:00 <ikke> fancsali[m]: they should go here: https://docs.alpinelinux.org/developer-handbook/0.1a/index.html
2023-08-02 18:31:23 <fancsali[m]> pj: Not sure what you exactly mean by that - especially not with Java...
2023-08-02 18:31:43 <ikke> https://gitlab.alpinelinux.org/alpine/docs/developer-handbook/-/issues/3
2023-08-02 18:32:32 <pj> We use specific build flags for compilers, I'm not informed about Java software and how exactly it's built but I presume there are certain build configurations which may differ with upstream
2023-08-02 18:33:06 <minimal> fancsali[m]: it is also hard to patch (when needed) software that is not built from source
2023-08-02 18:41:18 <fancsali[m]> So, I'll need a 64-bit machine to build for 32-bit: groovy needs java8, gradle java16... :D
2023-08-02 18:41:55 <fancsali[m]> And how about the issue of the java-jre virtual package? Any comments on that topic, perhaps?
2023-08-02 18:43:10 <ikke> The readme does not mention jdk8?
2023-08-02 18:46:44 <fancsali[m]> It does, I meant this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49265#note_325804
2023-08-02 18:57:37 <pj> Groovy mentions that it needs JDK16+
2023-08-02 19:04:00 <fancsali[m]> For building, yes. But on the downloads page it explains, that for runtime it's happy with 8+, it says: "Groovy 4.0 is the latest stable version of Groovy designed for JDK8+ with much improved JPMS support."
2023-08-02 19:04:38 <ikke> fancsali[m]: regarding some virtual jre package, best to open an issue. bratkartoffel primarily maintains the java packages, so he can comment on it best
2023-08-02 19:05:25 <ikke> fancsali[m]: we might be removing older jdks soon though. The only reason they are still there is because they are at the moment in the bootstrap path for openjdk
2023-08-02 19:08:12 <abby> i <3 openjdk bootstrap 😭
2023-08-02 19:08:33 <abby> (i did the 11->17 path on void)
2023-08-02 19:11:08 <ikke> how did you bootstrap openjdk11?
2023-08-02 19:13:31 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/15128
2023-08-02 19:14:15 <abby> someone else did
2023-08-02 19:14:45 <ikke> ah ok
2023-08-02 19:14:49 <abby> we have an icedtea 7 + gcc6/gcj all the way to 17
2023-08-02 19:38:06 <ikke> Oh, apparently nvd will stop the data feeds we are using for the security tracaker
2023-08-02 19:38:09 <ikke> ttps://nvd.nist.gov/vuln/data-feeds#JSON_FEED
2023-08-02 19:39:38 <ikke> https://nvd.nist.gov/vuln/data-feeds#JSON_FEED
2023-08-02 19:53:59 <fluix> is it common for pythonhosted.org to not include tests while a GitHub .tar.gz does?
2023-08-02 19:54:20 <ikke> It happens from time to time
2023-08-02 19:55:25 <fluix> is it fine to just adjust the source of the package then? there's a check() but it never did anything https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/py3-flask-migrate/py3-flask-migrate-4.0.4-r1.log
2023-08-02 19:55:41 <ikke> sure, should be fine
2023-08-02 19:55:49 <fluix> mainly doing so to fix compatibility with newer py3-flask. thanks
2023-08-02 19:55:50 <ikke> there is no requirement to get them from pythonhosted
2023-08-02 19:56:14 <fluix> yeah, just figure the checksum will change. I'll leave it to the maintainer to review that part
2023-08-02 19:56:28 <ikke> nod
2023-08-02 20:00:04 <fancsali[m]> ikke: openjdk8 is officially supported ti 2030 or so; so I'd keep it for the time being, if it were my call.
2023-08-02 20:01:27 <fancsali[m]> Also, the ticket seems worth a read. Looks like I need to talk to bratkartoffel..
2023-08-02 20:02:11 <ikke> He is here from time to time, but not at the moment
2023-08-02 20:35:43 <fluix> alright, I'm done for the day. package exists fine in pip and running the import with python -c works fine but it fails in tests
2023-08-02 20:41:31 <fluix> ikke: any reason the bot didn't auto-assign Drew for the two issues you just manually assigned him to?
2023-08-02 20:41:40 <fluix> noticed it at the time but figured it just wasn't immediate
2023-08-02 20:41:42 <ikke> No, was wondering the same
2023-08-02 20:43:24 <ikke> Interesting: "WRN too many maintainers found to assign MR=49441 component="MergeRequestJob processor" project=1 service=AutoMaintainer uuid=06a949ae-3b89-4d31-bf15-15da5a1887be"
2023-08-02 20:45:18 <fluix> swaylock-effects has a bad email (missing <)
2023-08-02 20:46:13 <fluix> nvm
2023-08-02 20:48:16 <fluix> ...I did nothing  and the tests now work, amazing
2023-08-02 20:51:47 <nmeum> what's our prefered $license string for software under public domain?
2023-08-02 20:52:36 <ikke> nmeum: spdx says there is not a single 'public domain' license
2023-08-02 20:53:27 <nmeum> yea. that's technically correct
2023-08-02 20:54:17 <nmeum> but there is a lot of upstream software which says "hey this is public domain" without any further clarification
2023-08-02 20:54:41 <ikke> I suppose Public-Domain would somewhat be in the spdx format
2023-08-02 20:57:03 <Ermine> What if something is not in SPDX list? should I set license=custom and install the license with docs?
2023-08-02 20:57:27 <ikke> Ermine: question is if we can / should even include it
2023-08-02 20:58:49 <Habbie> ikke, you mean the package, at all?
2023-08-02 20:58:51 <ikke> yes
2023-08-02 20:58:55 <Ermine> I'm about meld3. It is here so I suppose it can be included. Linter complains its license identifier is not in the list
2023-08-02 21:00:14 <ikke> repoze is not on the list indeed
2023-08-02 22:42:57 <pj> wasnt meld supposed to be removed
2023-08-02 23:27:43 <Saijin_Naib[m]> The GUI text comparison tool? I hope not. I use it constantly 
2023-08-03 01:22:07 <rootwyrm> Well, that's disappointing... still not finding the frequency governor.
2023-08-03 01:41:13 <iamthemcmaster> for MR's with new aports, is the process still to ask here for a review when they're ready? or do they just get picked up by someone in due time?
2023-08-03 01:46:25 <fluix> haven't been here too long, but I think new MRs get looked at pretty regularly
2023-08-03 01:46:46 <fluix> maybe ask here if it's been a bit or you just went from draft -> ready
2023-08-03 01:47:23 <fluix> also is $pkgname allowed in the filename of source (like $pkgname-$pkgver.tar.gz::)?
2023-08-03 01:51:54 <fluix> looks like a ton of spam on https://gitlab.alpinelinux.org/Leo/atools/-/issues
2023-08-03 02:02:03 <elly> so, I am doing my first upgrade of community/chromium, and the merge pipeline actually timed out after 1h of compiling, with only 43k of 55k targets built
2023-08-03 02:02:09 <elly> is there something special I need to do to it?
2023-08-03 02:05:43 <elly> (my MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49464)
2023-08-03 02:06:35 <elly> "Subject: Alpine aport chromium has been flagged out of date"
2023-08-03 02:06:46 <elly> "I'm sorry, I'm sorry, I'm trying to delete it", as they say :P
2023-08-03 02:07:14 <Arnavion> I was going to say to look at how the previous MRs fared, but of course psykose didn't bother with them :V
2023-08-03 02:07:51 <fluix> if Gitlab isn't lying, the CI was cancelled on them
2023-08-03 02:08:03 <fluix> might just be a thing that happens with jobs that are too old though
2023-08-03 02:08:21 <celie> You could try increasing the pipeline timeout at https://gitlab.alpinelinux.org/<your username>/aports/-/settings/ci_cd
2023-08-03 02:08:59 <celie> It's the last option under "General pipelines"
2023-08-03 02:09:32 <elly> does the setting on my fork of the aports repo apply to my MR against the alpine/aports repo?
2023-08-03 02:10:01 <Arnavion> Something about the MR CI running under the MR author's context
2023-08-03 02:10:26 <elly> ah
2023-08-03 02:10:36 <celie> I would say yes, because of what Arnavion said
2023-08-03 02:10:37 <elly> time to spend like 10 dollars of cpu time :P
2023-08-03 02:12:32 <rootwyrm> ncopa: well, this is unexpected. I see the -r1 apk. But it didn't actually package the ARM_MEDIATEK_CCI_DEVFREQ module? It should be at /lib/modules/6.1.42-1-lts-kernel/drivers/devfreq/mtk-cci-devfreq.ko
2023-08-03 02:14:28 <Arnavion> <fluix> also is $pkgname allowed in the filename of source (like $pkgname-$pkgver.tar.gz::)?   < Yes, eg   https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/libcamera/APKBUILD#L43
2023-08-03 02:17:23 <fluix> 
ACTION nods

2023-08-03 02:41:34 <celie> rootwyrm: https://cateee.net/lkddb/web-lkddb/ARM_MEDIATEK_CCI_DEVFREQ.html says that option depends on CONFIG_ARM_MEDIATEK_CPUFREQ, which is not enabled in lts.aarch64.config. Maybe that's why mtk-cci-devfreq.ko isn't built.
2023-08-03 02:52:02 <celie> Arnavion: https://gitlab.alpinelinux.org/Arnavion/aports/-/jobs/1074653#L1039 does this mean you have removed the usr/share/terminfo/f directory?
2023-08-03 02:53:27 <Arnavion> The foot package never contained /usr/share/terminfo/f . The foot-extra-terminfo package provided /usr/share/terminfo/f/foot-extra{,-direct}. It still does
2023-08-03 02:54:34 <rootwyrm> celie: that was my initial thought, but ARM_MEDIATEK_CPUFREQ is default on.
2023-08-03 02:54:53 <Arnavion> It used to be that the build produced /usr/share/terminfo/f/foot{,-direct} so the APKBUILD's extra-terminfo function had to manually rename them to foot-extra{,-direct}. I asked upstream to provide a way to have the build itself do that since every distribution is doing the rename manually, and upstream obliged in 1.15.2, so I've updated the APKBUILD to use it
2023-08-03 02:56:49 <Arnavion> (I maintain the OpenSUSE package and used the same method there when I updated it to 1.15.2)
2023-08-03 02:57:08 <fluix> I think the question is why the size difference shows -usr/share/terminfo/{f/}
2023-08-03 02:58:10 <Arnavion> Because I removed the now-unnecessary `install -D` lines, for the reason I gave
2023-08-03 02:58:14 <celie> Arnavion: Ah, ok, so it's just an empty directory. I usually see amove used with relative paths though, so you may want to check with someone else whether absolute paths do anything different.
2023-08-03 02:58:38 <Arnavion> This line   https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49466/diffs#efb7232329e1e5060ca943a17619d2260459a4b1_67_68
2023-08-03 02:58:59 <fluix> but that was always in the subpackage anyways right?
2023-08-03 02:59:20 <Arnavion> celie: There are plenty of uses of amove with a leading / in the path in aports, including one below in the themes package in that same APKBUILD
2023-08-03 02:59:34 <fluix> naive guess is meson would create those directories and then you just moved files out of them, but the directories themselves would stay?
2023-08-03 03:00:18 <Arnavion> Maybe? They aren't in the final package in any case, before and after my change
2023-08-03 03:00:40 <Arnavion> ie `apk manifest foot` doesn't list `/usr/share/terminfo` or `/usr/share/terminfo/f`
2023-08-03 03:02:08 <Arnavion> celie:   https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L83-84
2023-08-03 03:02:17 <rootwyrm> And so begins another 12+ hour abuild... :(
2023-08-03 03:02:21 <Arnavion> ie it's pointless but it doesn't hurt either
2023-08-03 03:02:51 <celie> Arnavion: Alright, i see, very sorry for the noise then
2023-08-03 03:02:53 <Arnavion> Oh, that's trailing /
2023-08-03 03:03:08 <Arnavion> But leading / also doesn't matter because the full path will just become blahblah//blahblah
2023-08-03 03:03:33 <Arnavion> mkdir, mv, etc won't care
2023-08-03 03:04:18 <fluix> re: manifest | yeah makes sense, just curious
2023-08-03 03:07:44 <celie> fluix: amove does a cleanup of the main package by remove the empty directory, if that's what you're asking
2023-08-03 03:08:45 <celie> removing*
2023-08-03 03:15:29 <fluix> yeah I figured that's why it's removed here
2023-08-03 03:43:24 <rootwyrm> What kind of hardware are people recommending these days for intermittent high-demand aarch64 compiles? still honeycomb lx2?
2023-08-03 04:13:07 <Arnavion> I just use cloud VMs, which are basically all Ampere Altras
2023-08-03 04:23:58 <rootwyrm> so they say, but AWS takes 10+ hours to build
2023-08-03 04:26:09 <ikke> to build what?
2023-08-03 04:31:36 <elly> the aarch64 and armv7 builds for chromium timed out even with a 2h timeout :( I don't want to waste even more CI time
2023-08-03 04:33:17 <rootwyrm> ikke: main/linux-lts
2023-08-03 04:35:52 <Arnavion> AWS uses its own Gravitons, which are a newer process than Ampere Altras though slightly lower-clocked IIRC
2023-08-03 04:37:00 <Arnavion> But I have no concept of how fast or slow any of them are, other than they're definitely faster than compiling on x86_64 under qemu or on a Raspberry Pi :V
2023-08-03 04:39:14 <rootwyrm> yeah... which are my other two options. and even EPYCs don't help
2023-08-03 04:44:41 <Arnavion> elly:   https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/chromium/chromium-115.0.5790.98-r0.log   >>> chromium: Build complete at Wed, 19 Jul 2023 10:22:48 +0000 elapsed time 13h 4m 35s
2023-08-03 04:44:50 <Arnavion> 13h 4m 35s   oof
2023-08-03 04:45:54 <elly> yikes
2023-08-03 04:45:57 <elly> that's a slow machine
2023-08-03 04:46:13 <elly> it takes like, 6 hours on my framework laptop :P
2023-08-03 04:46:30 <Arnavion> Yeah that must be a one-off. The previous build is   elapsed time 1h 26m 16s
2023-08-03 04:46:58 <elly> there's way too much browser in there either way
2023-08-03 04:48:21 <Arnavion> Too bad there's no timestamps for the lines in that log, so you can't extrapolate how long your CI would've taken based on how far it got...
2023-08-03 06:51:46 <pj> elly: setting higher timeout in your aports fork will fix the timeout in CI
2023-08-03 06:52:00 <pj> (if that wasn't answered definitely yet)
2023-08-03 06:52:59 <pj> iamthemcmaster: it's ok to occasionally post about MRs here but it's mostly reviewed/merged by people when they have spare time
2023-08-03 06:56:04 <ikke> I've increased it to 6h
2023-08-03 06:56:49 <pj> saijin_naib: context was meld3 which is abandoned
2023-08-03 06:57:51 <pj> tfw you're scanning backlog for if 'ikke' appears with an answer to asked questions 
2023-08-03 07:08:30 <ncopa> rootwyrm: mac with m1/m2 are good options for aarch64 build
2023-08-03 07:10:04 <ikke> I was late to the party as well, but someone already suggested it 
2023-08-03 07:14:17 <dzilvys> Hello everone, a bit confused here. I am downloading a 3.17 iso to make a bootable usb. When I boot into the bootable USB, I can `cat /etc/os-release` and see that its a 3.17 release. Once I run `setup-alpine` and go through the entire process of installing it on my `/dev/sda` drive using the `sys` option, It decides to then somehow install 3.18. When I boot into the SSD which I chose to install it on, it is 3.18 and I am confused how a version could 
2023-08-03 07:14:17 <dzilvys> change like that?
2023-08-03 07:28:20 <ikke> dzilvys: can you check what's in /etc/apk/repositories 
2023-08-03 07:29:36 <dzilvys> http://dl-cdn.alpinelinux.org/alpine/v3.17/main
2023-08-03 07:29:40 <dzilvys> http://uk.alpinelinux.org/alpine/edge/main
2023-08-03 07:29:51 <dzilvys> those are the only ones uncommented @ikke:
2023-08-03 07:33:22 <ikke> The latter one causes the problem 
2023-08-03 07:33:42 <dzilvys> How do I go about disabling it during the install?
2023-08-03 07:35:01 <ikke> The install itself should not add it. If it does, it might indicate some issue, perhaps linked to that mirror 
2023-08-03 07:37:57 <dzilvys> ah
2023-08-03 07:38:07 <dzilvys> let me see if I can just go without the mirror
2023-08-03 07:52:51 <dzilvys> ikke: So I tried it with a new install, and not selecting that odd mirror but the normal dl-cdn.alpine.... one. it still added /edge/main as a repo :/ wtf
2023-08-03 07:57:05 <ikke> That's odd
2023-08-03 07:57:36 <ikke> Is it present before you run setup-alpine?
2023-08-03 07:57:37 <dzilvys> i am trying just editing the repo file when it asks for a mirror and only putting the main
2023-08-03 07:57:52 <dzilvys> nope its only got /etc/apks/ somethign along those lines 
2023-08-03 07:57:55 <dzilvys> it doesnt even have a url
2023-08-03 07:59:41 <ikke> What does /etc/alpine-release contain?
2023-08-03 08:00:28 <dzilvys> I will check in a minute, I am seeing if setting no mirror and just doing done works
2023-08-03 08:00:53 <ikke> It uses that file to determine what release to use for the mirror 
2023-08-03 08:01:04 <dzilvys> alpine file has `3.17.3` in it
2023-08-03 08:02:40 <ikke> That's fine 
2023-08-03 08:03:06 <dzilvys> Ok, it worked out fine when I added no mirror
2023-08-03 08:03:11 <dzilvys> so thats good I think?
2023-08-03 08:15:40 <dzilvys> is it possible to automatically install grub too btw?
2023-08-03 09:13:20 <ikke> BOOTLOADER=grub setup-alpine 
2023-08-03 09:53:13 <rnalrd> ikke, do we have a local cache of downloaded sources?
2023-08-03 09:54:31 <ikke> rnalrd: distfiles.alpinelinux.org
2023-08-03 09:55:26 <rnalrd> cool thanks, the usual host :)
2023-08-03 10:17:14 <ncopa> ikke: i think we should create a test suite for secfixes-tracker. Do you have any preference wrt pytest vs unittest? https://testdriven.io/blog/flask-pytest/#pytest-vs-unittest
2023-08-03 10:18:10 <ncopa> i only have some experience with pytest. only possitive impression of pytest
2023-08-03 10:20:06 <ikke> I don't have a strong preference myself
2023-08-03 10:20:26 <ikke> we do need to adjust the way gets data from NVD though before september
2023-08-03 10:26:55 <ikke> The current feeds we are using are no longer provided after 1st of september
2023-08-03 10:37:02 <ikke> rnalrd: is there a reason why you didn't upgrade zabbix to 6.0.20 but 6.0.14 instead?
2023-08-03 12:58:27 <rnalrd> ikke, there's not. I believe I had local commit that I never pushed. I can take care of pushing 6.0.20
2023-08-03 12:58:38 <ikke> ah ok, that's fine with me
2023-08-03 13:30:00 <rootwyrm> ncopa: waaaaay cheaper to spin up AWS Graviton instances ;P
2023-08-03 13:38:38 <ncopa> yup. should work out of the box from here: https://alpinelinux.org/cloud/
2023-08-03 13:42:01 <elly> chromium 115.0.5790.170 landed, but I still see .110-r2 available as the latest package - I'm guessing .170 is waiting on some kind of CI job, but is there a place to see that job?
2023-08-03 13:43:17 <ptrc> elly: CI is separate from the builders, you can see the latter's status on https://build.alpinelinux.org/
2023-08-03 13:43:28 <elly> aha, thanks
2023-08-03 13:43:41 <elly> and there the builds are indeed, perfect
2023-08-03 13:43:50 <elly> if it succeeds I'll then land the same upgrade for 3.18
2023-08-03 13:45:41 <ikke> There is also #alpine-commits, but it anounces every commit and finished build sequence / build failures there
2023-08-03 13:47:54 <elly> that sounds high traffic
2023-08-03 13:47:59 <ikke> yes
2023-08-03 13:48:04 <ikke> so only if you really care :P
2023-08-03 13:48:42 <elly> my goal is to care about 50-60% as much as psykose
2023-08-03 13:49:14 <ikke> Hehe
2023-08-03 14:03:42 <rootwyrm> The good news is that it was CONFIG_ARM_MEDIATEK_CPUFREQ=m. The bad news is that it doesn't want to open mmcblk.
2023-08-03 14:08:31 <ncopa> was the kernel module built?
2023-08-03 14:12:17 <rootwyrm> Yeah, when I added `CONFIG_ARM_MEDIATEK_CPUFREQ=m`, that got it to build. As I mentioned, ARM_MEDIATEK_CPUFREQ is on by default, so not sure why it was off. Should be a `y` not an `m` for actual distribution though. Board's now all the way through root mount, but dies trying to read mmcblk.
2023-08-03 15:49:03 <ikke> pj: "CVE-2023-38497: Cargo does not respect umask when extracting packages
2023-08-03 15:49:05 <ikke> "
2023-08-03 15:49:11 <ikke> https://www.openwall.com/lists/oss-security/2023/08/03/2
2023-08-03 15:52:02 <pj> nice
2023-08-03 15:52:37 <elly> ah man, umasks strike once again
2023-08-03 15:52:58 <pj> will look at it in a bit
2023-08-03 15:53:13 <pj> https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2023-38497
2023-08-03 15:53:42 <ikke> right, they also mention 1.71.1 will come out soon
2023-08-03 15:53:47 <ikke> (today)
2023-08-03 16:33:08 <Forza> Hi. I am working on the init script for scsi-tgt. I am curious about supervise-daemon. If it detects a crash, will I restart by running all the normal hooks like start_pre and start_post? 
2023-08-03 16:33:23 <ikke> no
2023-08-03 16:33:36 <Forza> Oh. That's a bummer 
2023-08-03 16:33:57 <Forza> Can it call a supplementary script on restarting?
2023-08-03 16:34:42 <Forza> If not, then it is the wrong tool for scsi-tgt, as simply restarting the daemon will leave it unconfigured, causing issues for initiators 
2023-08-03 16:38:32 <ikke> Forza: I don't see any option here: https://manpages.debian.org/testing/openrc/supervise-daemon.8.en.html
2023-08-03 16:40:00 <Forza> Yea. Seems not. Ill remove it. Because it is wrong to leave the target daemon running, accepting connections without configured targets 
2023-08-03 17:44:31 <fancsali[m]> I know, it's getting boring, but I am still working on the Groovy package... ;)
2023-08-03 17:44:31 <fancsali[m]> Which on one hand makes the pipeline fail, and also means, the user would need to remember to remove it after removing groovy...
2023-08-03 17:44:31 <fancsali[m]> Can someone perhaps tell me off their top off their head, how do I make apk automatically select something for a virtual package? My package depends on `java-jre` which is provided by several packages (depending on architecture); but apk expects me to install it by hand.
2023-08-03 17:45:32 <fancsali[m]> Couldn't find anything on this on the wiki - or maybe just I wasn't looking hard enough... 
2023-08-03 17:46:28 <ikke> fancsali[m]: adding a virtual package to depends should work
2023-08-03 17:48:48 <fancsali[m]> On my armv7 machine, which only has Java 8 in the repository, it still prompts me to select one  by hand:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/MzrmXZDRhNcRxsvMbisnsdeT>)
2023-08-03 17:49:08 <fancsali[m]> This is the output of `apk add groovy`...
2023-08-03 17:50:14 <ikke> Can you please us a proper pastebin? The matrix one forces downloading the snippet (This is automatically done because you use the multi-line feature in matrix, which is not really nice for the IRC users)
2023-08-03 17:51:01 <Arnavion> I wrote an FF extension for myself which strips the content-disposition header from matrix.org/_matrix/media URLs to fix that :D 
2023-08-03 17:52:06 <fancsali[m]> ikke: This also makes `abuild -r` fail; so I expect the pipeline to fail too...
2023-08-03 17:54:42 <fancsali[m]> ikke: Sorry mate, let me fix that multi-line problem...
2023-08-03 17:57:09 <ikke> even though there is only one provider, because there is no provider_priority, and the virtual package is not versioned, apk requires you to manually select one
2023-08-03 17:57:32 <ikke> but curiously enough, it works for me on x86_64
2023-08-03 17:58:17 <fancsali[m]> ikke: so, output of `apk add groovy`: https://pastebin.com/Lr5tvn6T; output of `abuild -r`: https://pastebin.com/73xmCmiF
2023-08-03 18:01:17 <hjaekel> ikke, is there anything I could do to get !44833 merged? It is already reviewed, but I think it needs a final review
2023-08-03 18:01:58 <ikke> hjaekel: I was busy reviewing it, but starting working on other things
2023-08-03 18:02:17 <ikke> hjaekel: one thing I noticed is that there are config options that configure warns about not recognizing
2023-08-03 18:02:17 <fancsali[m]> Ikke: so, can I somehow specify the version in the depends declaration? The docs say the software works with anything starting from 8. So perhaps `depends="java-jre>=8"
2023-08-03 18:02:59 <hjaekel> OK take your time. I will look at the config options
2023-08-03 18:03:16 <ikke> hjaekel: "configure: WARNING: unrecognized options: --with-png, --with-wxwidgets"
2023-08-03 18:03:53 <ikke> fancsali[m]: The provides should also have a provider_priority. I think if that's set, it would work better
2023-08-03 18:04:01 <ikke> But that needs to be fixed on the jdk packages
2023-08-03 18:30:25 <fancsali[m]> ikke: ah, got you! Thanks! I'll look into that!
2023-08-03 19:42:48 <bratkartoffel> fancsali[m]: haven't been on IRC lately, i've been pretty busy for the last few months, exhausting work. Sure, if you have questions it's best to contact me either via a MR on gitlab or directly via mail 
2023-08-03 19:46:05 <ikke> o/
2023-08-03 20:53:56 <Forza> What is preferable to do. Have an app doing logging through syslog, or use output_log= and error_log= in the init script? 
2023-08-03 21:06:49 <humm> Forza: have programs write logs to standard error
2023-08-03 21:12:02 <Forza> Humm yes. This is tgtd (scsi-tgt), and it can be configured to output logs to stderr/console or to syslog. Seems syslog is a better choice
2023-08-03 21:12:51 <Forza> I am trying to understand why psykose did the former.
2023-08-03 21:19:14 <ikke> You can tell supervise-daemon to forward stdout to syslog 
2023-08-03 21:22:27 <Forza> I don't want to use service-daemon because it can cause issues if it restarts the daemon. So I'll just let it output to syslog instead 
2023-08-03 21:24:54 <Forza> Something like this https://bpa.st/PEJA 
2023-08-03 22:13:08 <fancsali[m]> <bratkartoffel> "fancsali: haven't been on IRC..." <- Thanks a lot! I've seen your comments, I'll drop you a mail with the key points/questions. 
2023-08-03 23:32:12 <Forza> Hi. I reworked the init scripts for scsi-tgt. As I'm new to this, I wouldn't mind if someone could have a look before I remove Draft status. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49534
2023-08-03 23:59:49 <humm> Forza: the name is supervise-daemon
2023-08-04 00:01:00 <Forza> Yes :) 
2023-08-04 00:02:16 <humm> and if scsi-tgt really doesn’t allow proper supervision, that should be fixed
2023-08-04 00:02:43 <Forza> Yes, true. 
2023-08-04 00:03:12 <Forza> Something I can ask upstream about
2023-08-04 04:29:00 <iamthemcmaster> what are the scenarios where something gets moved from community to main? not looking to suggest anything get moved, just curious
2023-08-04 04:34:27 <zcrayfish> Good chance that would happen if the package became used in the base system
2023-08-04 04:54:54 <bratkartoffel> something is wrong with gitlab.a.o, getting http 500 errors
2023-08-04 04:57:11 <bratkartoffel> ikke: the java aports should all have provider_priority set; e.g. https://git.alpinelinux.org/aports/tree/community/openjdk11/APKBUILD#n8
2023-08-04 05:02:22 <zcrayfish> it's timing out for me.
2023-08-04 05:07:43 <a16bitsysop> its started working for me now
2023-08-04 06:34:35 <ncopa> morning! i need to make new alpine releases due to openssl cve
2023-08-04 06:34:57 <ncopa> either this afternoon or monday
2023-08-04 06:35:34 <ncopa> help with fixing builder issues on stable branches is appreciated
2023-08-04 08:26:53 <pj> working on rust
2023-08-04 09:54:23 <omni> they're soon out of letters for their 1.1.1 releases
2023-08-04 09:54:34 <omni> openssl are
2023-08-04 09:56:43 <sam_> don't worry, it's EOL next month
2023-08-04 09:57:14 <Habbie> they're out of letters in ASCII ;)
2023-08-04 09:59:01 <mercenary> it'll go from 1.1.1z to 1.1.1A
2023-08-04 10:08:56 <omni> 🖒
2023-08-04 10:51:14 <eddsalkield> how do we manage packages that provide alternative programs to other packages? I'm looking to maintain the wormhole-william package, and wondering if I can get it to install a symlink to the command `wormhole`
2023-08-04 10:51:33 <eddsalkield> if so, what would be the standard way: a script that invokes `wormhole-william`, or a symlink to the binary?
2023-08-04 10:51:41 <eddsalkield> or something else
2023-08-04 10:53:12 <ikke> a symlink should suffice
2023-08-04 10:53:27 <ikke> But you should mark the package conflicting with the original
2023-08-04 10:54:44 <ovf> what's the other package?
2023-08-04 10:55:02 <eddsalkield> actually I don't think we package magic-wormhole, but it would be that one
2023-08-04 12:28:09 <pj> ikke: do you know if there are any issues with s390x CI?
2023-08-04 12:28:19 <pj> rust is stuck
2023-08-04 12:28:25 <pj> https://gitlab.alpinelinux.org/pj/aports/-/jobs/1076208
2023-08-04 12:29:12 <pj> did the bridge just broke
2023-08-04 12:35:51 <ikke> pj: I'm not aware of any issues 
2023-08-04 12:36:09 <pj> well, it seems to work
2023-08-04 12:36:13 <pj> just... slow
2023-08-04 12:37:59 <ikke> That's nothing new
2023-08-04 12:54:35 <omni> I think I was a rookie when it came to packaging and that's why I didn't package the other one when I packaged wormhole-william
2023-08-04 13:49:19 <pj> ikke: ok, but I didn't knew it would be so slow, anyway, !49560 is ready
2023-08-04 13:49:37 <pj> with minor fix for bash_comp
2023-08-04 14:05:38 <ncopa> I'm about to send an email to the alpine-devel mailing list, asking for more volunteers. does this sound ok? https://tpaste.us/MRj5
2023-08-04 14:05:57 <ncopa> I dont want to sound demanding or unthankful
2023-08-04 14:09:15 <pj> sounds good
2023-08-04 14:09:21 <ncopa> thanks!
2023-08-04 14:09:24 <pj> there are few packages I meant to take
2023-08-04 14:09:45 <ncopa> awesome
2023-08-04 14:09:59 <pj> could you look at rust mr?
2023-08-04 14:10:08 <ncopa> i will likely take a bunch myself, but want give others the opportunity
2023-08-04 14:11:27 <ncopa> will do. i took llvm packages
2023-08-04 14:11:44 <ncopa> thank you for taking care of rust
2023-08-04 14:12:25 <pj> I'm figuring out zig upgrade
2023-08-04 14:12:37 <pj> they switched to llvm16
2023-08-04 14:12:52 <ncopa> oh, cool
2023-08-04 14:13:59 <c7s> I'll take sagemath dependencies since the guy who was doing all that dropped his stuff
2023-08-04 14:14:24 <c7s> bit busy to figure out what's what right now though
2023-08-04 14:14:58 <Forza> Hi. How come the scsi-tgt package didnt update for riscv64?https://pkgs.alpinelinux.org/packages?name=scsi-tgt&branch=edge&repo=&arch=&maintainer= 
2023-08-04 14:15:10 <Forza> Did i make a mistake?
2023-08-04 14:15:41 <ncopa> i think the riscv64 builder is just busy
2023-08-04 14:15:56 <ncopa> https://build.alpinelinux.org/
2023-08-04 14:16:12 <ncopa> its the slowest buidler we have, and has a hard time to keep up
2023-08-04 14:17:13 <Forza> I understand. Ill be patient. Just thought i had done something wrong.
2023-08-04 14:17:38 <ncopa> nothing wrong, i think
2023-08-04 14:17:43 <PureTryOut> ncopa: re the mail you've just send, would it be an idea to move every package at least in testing that doesn't have a maintainer in a month from now to `unmaintained`?
2023-08-04 14:18:06 <Forza> Seems to be many merge requests. Is it common? Several hundred every day past few days it seems. 
2023-08-04 14:18:29 <pj> PureTryOut: imo all of them should be, not only testing
2023-08-04 14:18:48 <pj> unless something depends on them
2023-08-04 14:18:49 <ncopa> PureTryOut: i was thinking of clean up in a week or two
2023-08-04 14:18:57 <PureTryOut> I suppose but stuff in community probably has way more depending on it
2023-08-04 14:19:02 <ncopa> i intend to pick up what others dont
2023-08-04 14:19:04 <PureTryOut> ncopa: sounds good 👍️
2023-08-04 14:19:06 <pj> Hopefully this will also be an opportunity to remove abandoned packages by upstream
2023-08-04 14:19:26 <ncopa> i already remove at least one package that looks abandoned upstream
2023-08-04 14:19:53 <pj> I know there was py3-meld3
2023-08-04 14:20:39 <ncopa> Forza: we used to have a super active developer who kept the MR queue low. we are struggling to keep up now
2023-08-04 14:21:51 <pj> it's also because we're taking over packages as community rather than mostly devs, so more packages are handled by MRs than direct commit pushed to HEAD
2023-08-04 14:21:59 <Forza> Psykose. I heard. She helped me a lot. 
2023-08-04 14:22:36 <minimal> I'll go through the list later today but from a quick glance see at least a few that I'd be willing to maintain
2023-08-04 14:23:27 <ncopa> we need empower more devs with merge rights
2023-08-04 14:24:10 <ncopa> Help with reviewing MRs is very appreciated. like this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49495#note_326319
2023-08-04 14:24:29 <ikke> PureTryOut: unmaintained is no more 
2023-08-04 14:25:27 <ddevault> I can pick up a few packages (man-db, pacman, maybe mingw) but my maintainership is still stagnanting without commit access, gitlab is too disrputive to my workflow to do merge requests just to update packages
2023-08-04 14:26:18 <ncopa> ddevault: do you mind if I take over doas?
2023-08-04 14:26:41 <PureTryOut> ikke: oh?
2023-08-04 14:26:50 <ddevault> most of the work on the doas package was done without my approval anyway
2023-08-04 14:26:53 <ddevault> go ahead.
2023-08-04 14:27:04 <ncopa> thank you sir!
2023-08-04 14:27:06 <pj> eb615cfe36e8ace329bc1ff3012d58811ef125fc
2023-08-04 14:27:10 <ovf> ncopa: as an experiment, it's probably possible to set up gitlab in a way so that it auto-merges patchsets reviewed by k 'trusted' users (where 'trusted' is somewhat between general public and full commit access)
2023-08-04 14:27:34 <PureTryOut> I'd still like group maintainership to be a thing. Like I maintain all of KDE by myself but wouldn't mind some other people I trust also acting as maintainer of it
2023-08-04 14:27:56 <ncopa> yeah
2023-08-04 14:28:12 <ncopa> ovf: would be great if that was possible. no idea how though
2023-08-04 14:28:37 <Newbyte> PureTryOut: But it is "a thing", isn't it? Look at the GNOME packages
2023-08-04 14:29:02 <ikke> PureTryOut: that's already a thing for Gnome 
2023-08-04 14:29:18 <PureTryOut> Huh, really?
2023-08-04 14:29:28 <Newbyte> yes
2023-08-04 14:29:31 <ncopa> we should do the same for KDE if we don't already
2023-08-04 14:29:34 <ikke> ncopa: amount of open MRs has not uncreased that much yet
2023-08-04 14:29:50 <Newbyte> uncreased? 🤔
2023-08-04 14:29:52 <PureTryOut> Oh I see. We should definitely do the same for KDE then
2023-08-04 14:30:08 <PureTryOut> And then I just got to find people to help out lol
2023-08-04 14:30:12 <ikke> PureTryOut: yes
2023-08-04 14:30:14 <ovf> https://docs.gitlab.com/ee/user/project/merge_requests/approvals/ + https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html
2023-08-04 14:31:41 <ikke> ovf: auto merge requires developer access
2023-08-04 14:31:56 <ikke> At which point you already can merge 
2023-08-04 14:32:25 <ncopa> ddevault: can you please approve or give a thumbs up, so its visible for everyone? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49568
2023-08-04 14:32:31 <pj> group for rust stuff? :>
2023-08-04 14:32:45 <ncopa> that would make sense
2023-08-04 14:33:25 <ncopa> but i want wait a bit and see how gnome and kde plays out
2023-08-04 14:33:32 <pj> sure
2023-08-04 14:33:48 <ncopa> im afraid that everybody on the team things "someone else will take care" and we end up nobody does
2023-08-04 14:34:09 <ncopa> s/things/thinks/
2023-08-04 14:34:56 <ikke> Gnome team so far is doing fine
2023-08-04 14:36:35 <nmeum> speaking of package maintaince: I think we should also check maintainer comments for inactive contributors and remove those. because we have a quite a few packages which formally have a "maintainer" but that person isn't active anymore
2023-08-04 14:37:24 <pj> I think we should extend that and look at all packages that haven't been touched in long time
2023-08-04 14:38:27 <ovf> ikke: you are right. for some reason i thought gitlab definitely offered this specific 'crowd commit' thing. i guess this is possible with a custom bot listening on gitlab api?
2023-08-04 14:39:04 <pj> yeah but then you have to maintain that bot
2023-08-04 14:40:51 <durrendal> ncopa: if I wanted to adopt several packages would it be better to submit an MR per package, or one MR with several packages?
2023-08-04 14:41:02 <ikke> durrendal: single Mr is fine 
2023-08-04 14:41:18 <pj> durrendal: single MR is fine
2023-08-04 14:41:20 <ncopa> yeah, a single MR is easier
2023-08-04 14:41:22 <ncopa> :)
2023-08-04 14:41:50 <durrendal> good, wanted to do whatever caused the least friction on ya'lls end, looking through the list now :)
2023-08-04 14:42:19 <ncopa> i have also been thinking of gitlab bots recently
2023-08-04 14:43:29 <PabloCorreaGomez[m]> If I remember correctly, there is some code in the QA bot, that would automerge on a comment by the maintainer of a package, even if they don't have rights to push
2023-08-04 14:43:38 <PabloCorreaGomez[m]> That might already help, as currently that's quite annoying
2023-08-04 14:43:38 <ncopa> would be nice with some bot that could create tags, for example add "security" when there word "security" or "CVE" is found on first list in commit message
2023-08-04 14:44:00 <pj> which language is allowed for that bot
2023-08-04 14:44:03 <ikke> There is an auto labeler, but it broke 
2023-08-04 14:44:11 <ncopa> I suppose its a question for #alpine-infra
2023-08-04 14:44:23 <ikke> pj: the QA bot is in go 
2023-08-04 14:45:02 <pj> I can work with that
2023-08-04 14:45:38 <PabloCorreaGomez[m]> And regarding the team maintainership, I think Newbyte and me are working well together
2023-08-04 14:45:41 <ncopa> ikke: im thinking of posting a tweet, ask for help taking care of security-tracker
2023-08-04 14:46:42 <PabloCorreaGomez[m]> But I also have to admit that with psykose taking an immense amount of work, we did not have much time to test it out correctly. Many times she had fixed stuff before I even had time to look at them. Which was great from the project, but put me as a maintainer more aside
2023-08-04 14:47:52 <pj> ncopa: what's the issue with security-tracker? that recent feed change?
2023-08-04 14:48:25 <ikke> That's the imminent thing, but there are also some improvements that need to be made
2023-08-04 14:48:34 <pj> mmm, I see python
2023-08-04 14:48:43 <Newbyte> Yeah, I agree with Pablo. I didn't really have to do much since before I had the time to start looking psykose had already resolved it in many cases
2023-08-04 14:49:03 <nmeum> in general it would be good to have someone who would properly replace ariadne in terms of all things related to security
2023-08-04 14:49:07 <pj> KInd of annoying that we have multiple projects each using different language
2023-08-04 14:49:16 <pj> lua, python, go...
2023-08-04 14:49:32 <ikke> Different maintainers, different choices 
2023-08-04 14:50:01 <Newbyte> It's all legacy code that should be rewritten in Rust, obviously
2023-08-04 14:50:11 <pj> funny, I already did
2023-08-04 14:50:15 <Newbyte> Great
2023-08-04 14:53:11 <ncopa> lol
2023-08-04 15:10:51 <PureTryOut> so how does the group maintainership work then? As an example I looked at community/gnome-calculator and it does have team/gnome as maintainer but also lists a random persons email address in the same line
2023-08-04 15:15:59 <ikke> Atm it's still hardcoded apparently, but it recognizes the teams/gnome maintainer, and it then pings that team in a comment, but it's still assigned to the maintainer who is listed in as e-mail
2023-08-04 15:16:39 <PureTryOut> Hmm ok. Would be nice if the email could be removed really. Not sure if Gitlab groups can be assigned to MR's/issues?
2023-08-04 15:16:46 <ikke> nope
2023-08-04 15:16:48 <ikke> they cannot
2023-08-04 15:16:54 <PureTryOut> disappointing
2023-08-04 15:17:07 <Forza> Sounds like a case for group accounts? 
2023-08-04 15:17:22 <Forza> But hardly good for traceability 
2023-08-04 15:17:25 <Newbyte> That does not sound nice
2023-08-04 15:17:40 <Newbyte> Personally I think the current system with the 🏓 ping works well
2023-08-04 15:19:12 <PureTryOut> group accounts indeed don't sound great 
2023-08-04 15:20:49 <PureTryOut> abump increases pkgver, but is there also a quick easy way to bump the pkgrel by 1?
2023-08-04 15:21:05 <pj> sed?
2023-08-04 15:21:41 <PureTryOut> that's a bit less quick, as then I have to first get the number from pkgrel to increase it rather than just doing abumbrel packagename or whatever 😅
2023-08-04 15:22:59 <ikke> apkgrel -a
2023-08-04 15:23:10 <ikke> `apkgrel -a` .
2023-08-04 15:23:22 <PureTryOut> see, there you go, thanks 😄
2023-08-04 15:23:32 <pj> that code line did not work :P
2023-08-04 15:23:40 <ikke> pj: :p
2023-08-04 15:25:44 <PureTryOut> so this should do it then? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49573
2023-08-04 15:26:27 <PureTryOut> I should probably make one other change first actually, as this is not all packages yet
2023-08-04 15:27:53 <ikke> PureTryOut: the bot also need to be adjusted to recognize team/kde
2023-08-04 15:30:21 <pj> have you tried to make gitlab give you licence (premium/ultimate)?
2023-08-04 15:30:27 <pj> (via their open source program)
2023-08-04 15:30:49 <PureTryOut> ikke: sure but that's the next part
2023-08-04 15:31:57 <ikke> pj: no, we have not
2023-08-04 15:32:04 <nmeum> for the maintainer email address we could, at least in theory, have an email alias that just forwards to members of that team e.g. kde@teams.alpinelinux.org or something
2023-08-04 15:32:08 <nmeum> not sure if it is worth the effort though
2023-08-04 15:32:24 <ikke> nmeum: that would require a gitlab account (group account)
2023-08-04 15:32:28 <ikke> for that
2023-08-04 15:32:50 <nmeum> oh, really? so my nmeum@alpinelinux.org alias is also connected to my gitlab account?
2023-08-04 15:33:04 <nmeum> ahh you mean for algibot auto-assignments?
2023-08-04 15:33:24 <ikke> nmeum: yes
2023-08-04 15:33:33 <ikke> the latter
2023-08-04 15:34:22 <nmeum> but couldn't we tweak the algibot assignment logic to something along the lines of "if email address is @teams.alpinelinux.org" then assign issue to the "team lead"?
2023-08-04 15:34:29 <pj> getting ultimate licence for gitlab would be nice as it would give the option to assign multiple people to mr/issue
2023-08-04 15:34:57 <ikke> nmeum: we could
2023-08-04 15:35:02 <nmeum> gitlab sponsoring when?
2023-08-04 15:35:33 <ikke> pj: at least at the time we deployed gitlab, we felt as an opensource community, we should use the opensource / community variant that everyone can use
2023-08-04 15:37:34 <pj> I agree with the sentiment
2023-08-04 15:37:38 <nmeum> they also seem to use alpine for their CI so maybe it would actually be possible to convince them to give us the fancy gitlab version, if that's something we want
2023-08-04 15:38:09 <ikke> nmeum: Even without that, as OS project we would probably already be eligbale
2023-08-04 15:38:12 <ikke> eligible
2023-08-04 15:38:18 <nmeum> ah oh
2023-08-04 15:38:21 <pj> The only blocker I see is that they might be wary of the private projects
2023-08-04 15:39:02 <pj> They clearly state that everything has to be publicly visible with *some exceptions e.g. sensitive data
2023-08-04 15:39:36 <pj> but I think it would be worth trying
2023-08-04 15:40:21 <PureTryOut> ok https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49573 is done now, only 367 packages 🙈
2023-08-04 15:40:51 <PureTryOut> and in reality that's not all, there is some stuff out there not using easily-findable-by-scripts version numbers
2023-08-04 15:49:22 <PureTryOut> Newbyte: I see you're part of the GNOME group but not the alpine-desktop one, do you want to be? I don't believe it currently maintains packages but I kinda want stuff like elogind and pipewire to be maintained by it
2023-08-04 15:50:09 <PureTryOut> Pablo Correa Gomez: also for you, maybe let the desktop team (which includes you) maintain elogind? I'm currently not part of that team but would like to be
2023-08-04 15:50:18 <PureTryOut> Actually I am part of that group never mind, you are not however, do you want to be?
2023-08-04 15:50:44 <PureTryOut> Cogitri: do you realize you're still team leads of alpine-desktop and GNOME? Are you still ok with that?
2023-08-04 16:01:15 <Newbyte> <PureTryOut> "Newbyte: I see you're part of..." <- What is the "alpine-desktop" group?
2023-08-04 16:01:46 <PureTryOut> [The group](https://gitlab.alpinelinux.org/team/alpine-desktop)
2023-08-04 16:01:47 <ikke> https://gitlab.alpinelinux.org/team/alpine-desktop
2023-08-04 16:01:53 <PureTryOut> > Responsible for desktop-wide packaging, policy, theming and software that integrates desktop environments with Alpine Linux features.
2023-08-04 16:02:41 <ikke> ie, things that concern more than one desktop environemnt, but could affect it
2023-08-04 16:09:00 <nmeum> pj: re gitlab ultimate: would this be suitable for further discussion as a TSC issue? maybe we can collect gitlab premium features we need there to determine if it is wortwhile for us to investigate if we are eligible for a free premium version?
2023-08-04 16:09:33 <ikke> also, there are _some_ features that they enable when you register (for free)
2023-08-04 16:11:04 <ikke> What we also need to take into account is that we regularly deploy a copy of the production instance to test new features / upgrades
2023-08-04 16:40:25 <lnl> hey, looks like the pkgconf 2.0 upgrade might be breaking a lot of rust packages right now? reported on pkg-config crate upstream issues: https://github.com/rust-lang/pkg-config-rs/issues/150
2023-08-04 16:41:50 <iamthemcmaster> <ikke> "What we also need to take into..." <- its been a while but if i remember right, gitlab's licensing lets you use the same license on multiple instances as long as the second instance is the same set of users, or a subset of them
2023-08-04 16:50:11 <ptrc> lnl: that's pkgconf being broken
2023-08-04 16:50:22 <ptrc> pkg-config itself happily supports this case
2023-08-04 16:50:43 <ptrc> but pkgconf for some reason doesn't, so the claim about compatibility with pkg-config kinda falls through
2023-08-04 16:51:23 <ptrc> i was going to open an issue about it on https://github.com/pkgconf/pkgconf, but if you want to do it instead, go for it
2023-08-04 16:57:16 <ikke> iamthemcmaster: ah ok
2023-08-04 16:57:33 <pj> nmeum: sure
2023-08-04 16:59:10 <pj> I think just pinging gitlab co. laying down the situation of how gitlab.a.o operates and what's present as a first step would be nice because they could just reply "lol no" and we can close the topic
2023-08-04 17:11:25 <lnl> @ptrc this is a documented change in pkgconf 2
2023-08-04 17:20:32 <ikke> lnl: so we can expect to do a lot of bug reports / hotpatches for rust packages?
2023-08-04 17:23:37 <ikke> PureTryOut: your automation broke a few APKBUILDs
2023-08-04 17:23:57 <ikke> or at least one
2023-08-04 17:24:58 <lnl> so far there is no patch at all
2023-08-04 17:25:14 <lnl> but looking into this
2023-08-04 17:37:14 <pj> psykose mentioned that firefox build is broken because of new pkgconf
2023-08-04 17:37:37 <ikke> F.U.N.
2023-08-04 17:38:29 <pj> What it stands for? :P
2023-08-04 17:38:45 <ikke> Fairly unpleasant news
2023-08-04 17:38:59 <pj> true, true
2023-08-04 17:55:03 <ptrc> ...it would be nice to just revert https://github.com/pkgconf/pkgconf/commit/a97b75ab2c1d031982c35a4886102413e4ec8eee in aports .-.
2023-08-04 17:55:06 <lnl> ok, this works for me, submitted to upstream: https://github.com/selfisekai/pkg-config-rs/commit/4ea97bced7657de9f93b8ba151ac5029e6346ecc
2023-08-04 17:55:39 <orbea> ptrc: why not just fix firefox?
2023-08-04 17:56:07 <ptrc> that's exactly what i'm doing at this point
2023-08-04 17:56:48 <orbea> the commit in pkgconf seems to make sense to me, just saying to me it sounds like fixing firefox is a better solution than reverting a pkgconf commit
2023-08-04 17:57:25 <nmeum> it's not just firefoxt hat is affected by this though
2023-08-04 17:57:37 <orbea> what else?
2023-08-04 17:57:45 <orbea> is there a list? 
2023-08-04 17:58:12 <ikke> Not yet, it's more speculated
2023-08-04 17:58:18 <ptrc> pkg-config-rs and firefox so far, but i expect there's going to be more stuff just assuming pkg-config's interface
2023-08-04 17:58:38 <orbea> ah, i guess it depends how many things are broken
2023-08-04 17:58:42 <ptrc> and while i agree that it's *sensible*, it also makes pkgconf no longer a drop-in replacement for pkg-config
2023-08-04 17:59:16 <ikke> I think it never was a real drop-in replacement, as it always had some things that were stricted
2023-08-04 17:59:23 <ikke> stricter
2023-08-04 18:00:15 <lnl> to be fair pkgconf specifically has this section in readme: https://github.com/pkgconf/pkgconf#compatibility-with-pkg-config
2023-08-04 18:06:23 <ptrc> lnl: that's about bug-level compatibility
2023-08-04 18:06:36 <ptrc> but being able to provide multiple names to --modversion is documented in the manpage
2023-08-04 18:06:41 <ptrc> i'd argue that's different
2023-08-04 18:09:18 <ikke> One nice feature of gitlab ee is potentially merge trains
2023-08-04 18:10:45 <ikke> (I've never used them, so not sure how usefull they are in practice)
2023-08-04 18:29:54 <nmeum> 🚅
2023-08-04 18:30:13 <nmeum> so that enables us to merge multiple MRs sequentially or what does it do?
2023-08-04 18:30:52 <PureTryOut> ikke: if it's just the one then I think that's pretty good for the crudeness of the script I used 😅
2023-08-04 18:33:50 <ikke> nmeum: Just read it again, but what it mostly does is verifying the combined results of each subsequent MR (so it runs the CI job on the merged results, not on the MR branch). So maybe not that useful for us
2023-08-04 18:34:14 <ikke> What it doesn't do (but I hopeded) is that it could aumatically rebase each MR
2023-08-04 18:34:44 <ikke> or maybe it does, the documentation does not mention
2023-08-04 18:44:31 <Arnavion> Github's equivalent feature (merge queue) makes a new branch with all the MRs rebased into a linear history, so I imagine the gitlab one is similar
2023-08-04 18:45:21 <ikke> This seems to imply it's not: https://gitlab.com/groups/gitlab-org/-/epics/4911
2023-08-04 18:46:00 <Arnavion> Oof
2023-08-04 18:46:01 <ikke> but maybe I'm not interpreting what that asks for correctly
2023-08-04 18:50:49 <Arnavion> Actually I can't tell if that issue is saying "Merge trains need to be changed to support rebase+fast-forward merging" or "Merge trains will be the solution to the requirement of rebase+fast-forward merging"
2023-08-04 18:51:38 <Arnavion> https://gitlab.com/groups/gitlab-org/-/epics/4911#note_1273011234   Oh, I guess it's definitely the former
2023-08-04 18:53:07 <ikke> they say it's scheduled for 16.3
2023-08-04 18:53:14 <Arnavion> Yes, August 22
2023-08-04 18:53:30 <ikke> But still, we would need premium to be able to actually use it
2023-08-04 19:42:14 <ikke> PureTryOut: it broke kdeconnect-nftables pretty bad as well
2023-08-04 19:42:21 <ikke> "install_if = $ # The group tag is just to easily find this APKBUILD by some scripts for automation # group=kde-applications pkgname=23.04.3-r1 nftables"
2023-08-04 19:42:38 <ikke> in the .PKGDATA of the apk file
2023-08-04 19:42:46 <PureTryOut> Lol, I'll fix it
2023-08-04 19:44:26 <ikke> PureTryOut: Can you check other packages as well?
2023-08-04 19:49:22 <PureTryOut> I believe that's all
2023-08-04 19:49:25 <ikke> ok
2023-08-04 19:49:47 <ikke> Now I need to figure out how to unbreak s390x
2023-08-04 19:50:06 <Cogitri> PureTryOut: It’s still fine for me to answer questions related to GNOME - maybe I’ll return to Alpine at some point but definitely with <50 packages to maintain so I can do things other than abump :D
2023-08-04 19:50:46 <ikke> Cogitri: Do you still want to remain as coordinator of alpine-desktop?
2023-08-04 19:53:21 <Cogitri> If we have someone else who wants to take over I wouldn’t mind that either
2023-08-04 19:53:55 <ikke> PureTryOut: I have a feeling you ware willing to
2023-08-04 19:56:05 <PureTryOut> Well.... Depends on what it entailes lol
2023-08-04 19:56:21 <PureTryOut> (not sure if that is the correct word, or if I spelled it correctly)
2023-08-04 19:56:43 <ikke> I understood what you meant :)
2023-08-04 20:04:28 <ikke> thunderbird fails as well due to pkgconf 2.0
2023-08-04 20:07:45 <ikke> ptrc: ^
2023-08-04 20:08:18 <ptrc> yup, i was about to backport lnl's patch from https://github.com/rust-lang/pkg-config-rs/pull/151 onto all firefoxes and thunderbird
2023-08-04 20:08:23 <ptrc> since it's the exact same library
2023-08-04 20:08:47 <ikke> right
2023-08-04 20:08:57 <ptrc> and it's way easier, since they just vendor the source code
2023-08-04 20:09:12 <ikke> yeah, that would make it easier indeed
2023-08-04 20:29:16 <PabloCorreaGomez[m]> PureTryOut (matrix.org): regarding being part of alpine-desktop, sure, that's quite relevant to what I'm doing
2023-08-04 20:29:41 <PabloCorreaGomez[m]> And regarding teams and the QA bot, you need to modify https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/blob/master/Services/CommentPingTeam/definition.go#L19 and re-deploy for it to detect more teams
2023-08-04 20:29:50 <PureTryOut> I'd say any person in either the KDE or GNOME team would be relevant to the alpine-desktop team 😅
2023-08-04 20:30:14 <ikke> PabloCorreaGomez[m]: yeah, I looked at that code when mentioning the bot needed to be adjusted
2023-08-04 20:31:00 <PabloCorreaGomez[m]> The logic we followed when I created that: we want to have things maintained by teams, but there was still the fear that people will just rely on the others doing the work. So we fixed that by keeping a person "mainly" responsible with the package, through the email
2023-08-04 20:31:14 <PabloCorreaGomez[m]> Which is actually what is used in general to assign maintainers to MRs
2023-08-04 20:31:57 <ikke> PabloCorreaGomez[m]: I think we should change the team list to use a config file so that we do not need to redeploy the bot all the time to make changes
2023-08-04 20:32:31 <PabloCorreaGomez[m]> That also has an additional benefit, which is that people that are not officially part of the team, but interested in a certain package, can keep being responsible for it in a way, while the team is still pinged whenever anything related to the package happens
2023-08-04 20:33:35 <PabloCorreaGomez[m]> ikke: wouldn't we need to re-deploy anyway? Would you want to read the file from storage every time that the bot runs? Do you have any better idea?
2023-08-04 20:33:57 <PureTryOut> Pablo Correa Gomez: ikke https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/41
2023-08-04 20:34:03 <ikke> PabloCorreaGomez[m]: restarting it is easier than redeploying
2023-08-04 20:35:46 <PabloCorreaGomez[m]> ikke: Fair enough, that seems like an easy fix. Can you create an issue with the path of the file that you might want (and possibly an environment variable name to replace it), and assign it to me? Things keep piling up for the weekend, but hopefully I'll have time for that
2023-08-04 20:37:12 <ikke> there is also a conf.json and conf.json.override
2023-08-04 20:37:17 <ikke> conf.override.json*
2023-08-04 20:37:30 <PureTryOut> why was only GNOME done originally? 🤔
2023-08-04 20:38:52 <ikke> PureTryOut: simply because they asked for it
2023-08-04 20:39:35 <ikke> PureTryOut: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/46
2023-08-04 20:40:27 <PureTryOut> I didn't even know about it till today 😢
2023-08-04 20:42:36 <ikke> PabloCorreaGomez[m]: done
2023-08-04 20:43:32 <ptrc> hm.
2023-08-04 20:43:38 <ptrc> looks like the pkg-config thing is a bug anyway
2023-08-04 20:43:56 <ptrc> because there's no way to specify both a lower and upper bound for a version without putting multiple arguments
2023-08-04 20:46:02 <PabloCorreaGomez[m]> ikke: thanks
2023-08-04 20:46:37 <ptrc> wait, no, pkgconf 1.x doesn't handle that either
2023-08-04 21:14:18 <fluix> ikke: you mentioned "A package requiring pip usually means it tries to install missing dependencies." but am I right that this isn't the case here for instance: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49396
2023-08-04 21:15:48 <ikke> not sure how that one is relevant?
2023-08-04 21:16:19 <fluix> was the same message as py3-werkzeug I believe
2023-08-04 21:16:42 <fluix> in this case you're refering to https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1071488#L4940
2023-08-04 21:17:07 <fluix> ah, I get what you mean
2023-08-04 21:17:22 <ikke> It tries to install wheel
2023-08-04 21:17:26 <fluix> it's looking for werkzeug < 2.3 but we're updating beyond that so pip wheel (which I guess is install) fails
2023-08-04 21:18:29 <fluix> is it still fine that I update to gpep517 when fixing other things because running setup.py independently is deprecated?
2023-08-04 21:20:00 <fluix> just so I understand, is pip wheel trying to install wheel or the package at the end of the command line?
2023-08-04 21:21:52 <ikke> oh, probably werkzeug, yes
2023-08-04 21:23:01 <ikke> https://pip.pypa.io/en/stable/cli/pip_wheel/
2023-08-04 21:23:05 <fluix> yeah was looking at that
2023-08-04 21:23:25 <fluix> so the actual solution would be patching the dependencies in the project's setup.py (or whatever it uses)
2023-08-04 21:23:38 <fluix> but I guess gpep just prevents it from trying anyways
2023-08-04 21:23:47 <ikke> fluix: if it wants a version of a dependency that we don't have, most likely yes
2023-08-04 21:25:02 <fluix> yep. to be clear though, the issue in the package you commented about is the tests. the issue about not having pip is fine
2023-08-04 21:32:06 <fluix> also, in case you want to py3-connexion in your comment https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49253#note_324047 has been fixed in !49396
2023-08-04 21:32:26 <fluix> *want to check off
2023-08-05 13:41:24 <PabloCorreaGomez[m]> ikke: https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/42 It compiles, and the change is small enough that hopefully it's no issue, but last time I had the same problem. Do you have any suggestions on how to test it?
2023-08-05 13:42:09 <ikke> PabloCorreaGomez[m]: I have to enable a runner for your project, which I just did
2023-08-05 13:42:19 <ikke> If you restart the job, it should run now
2023-08-05 13:45:03 <PabloCorreaGomez[m]> ikke: cool, seems to be ready then :D Thanks a lot@
2023-08-05 13:45:41 <rootwyrm> Ugh, anyone here dealt with the AMLogic s805x/s905x in depth before?
2023-08-05 14:05:18 <PabloCorreaGomez[m]> ncopa: is there any chance that you can have a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/157? This is causing us quite some headache in GNOME calendar (mostly downstream in pmOS, but the issue also exists in alpine), when it just crashes on startup if the user has changed the timezone
2023-08-05 17:55:00 <micahrl[m]> Hello. I'm trying to build an ISO with mkimage.sh, but the images I am building keep failing to boot with "/sbin/init not found in new root". I'm building the ISO on a fresh Alpine VM, and booting it with qemu. Following instructions from https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage ... is there something I'm missing to get these to build properly?
2023-08-06 11:56:57 <ikke> micahrl[m]: sounds to me like it could not find / mount the expected rootfs
2023-08-06 13:43:19 <micahrl[m]> ikke right... when I look around in the rescue shell, /sysroot indeed does not contain an sbin/init, though it contains a few other files. What is supposed to populate /sysroot on the iso, and why might it be doing so incompletely?
2023-08-06 13:44:07 <ikke> The initramfs would normally mount the rootfs there and then switchroot to there
2023-08-06 13:44:43 <micahrl[m]> This is the live iso I'm talking about - no hard disk rootfs
2023-08-06 13:44:44 <ikke> but, I'm not sure how this works for the live iso
2023-08-06 13:44:46 <ikke> yeah'
2023-08-06 14:09:17 <minimal> micahrl[m]: for the ISO either isolinux or grub (for UEFI) is used to load the kernel and initramfs, then as usual the initramfs' init preps for the rootfs - in this case as a rootfs in memory
2023-08-06 14:09:42 <minimal> this is "typical" diskless Alpine
2023-08-06 14:24:14 <micahrl[m]> One thing I'm confused by is that when I build an image with aports/scripts/mkimage.sh --outdir ~/iso --arch x86_64 --repository http://dl-cdn.alpinelinux.org/alpine/v3.18/main --repository http://dl-cdn.alpinelinux.org/alpine/v3.18/community --profile standard, with no customizations, from a fresh Alpine VM, the one I build has this missing init. What am I doing differently from the build for the standard image on alpinelinux.org?
2023-08-06 14:26:54 <minimal> micahrl[m]: you tell us, you're the only one who knows what you're doing differently
2023-08-06 14:27:16 <minimal> oops, I misread
2023-08-06 14:28:04 <minimal> so does that give any errors? do you have missing packages when you run that so it can't add something to the ISO?
2023-08-06 14:33:15 <micahrl[m]> Nothing I see in the output of the mkimage.sh logs. xorriso completes without error.
2023-08-06 14:34:02 <minimal> well it wouldn't be a xorriso error, it would be something going wrong elsewhere
2023-08-06 14:37:35 <minimal> so what output do you see just before you get the /sbin/init error, rescue shell?
2023-08-06 14:38:07 <micahrl[m]> hmm. I don't see previous errors in this logfile I have from yesterday, going to generate a fresh one now to make sure. surprised it would try to build the iso if there was an error further up the chain.
2023-08-06 14:38:57 <minimal> micahrl[m]: focus on the output when you boot just before you see an error
2023-08-06 14:38:58 <micahrl[m]> yeah, I see "ISOLINUX 6.04 (...)" and then "boot:" and then "/sbin/init not found in new root. Launching emergency recovery shell"
2023-08-06 14:43:29 <minimal> right, so that's coming from here: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L862
2023-08-06 14:44:26 <minimal> so did you see "Installing packages to root filesystem" earlier?
2023-08-06 14:48:52 <micahrl[m]> No - before the ISOLINUX line, it is early messages from the virtualized hardware: SeaBIOS, iPXE, "Booting from DVD/CD...", etc. (I'm using qemu for the record)
2023-08-06 14:50:31 <minimal> ok, so it is "quiet" booting and you're not seeing other lines from initramfs' init
2023-08-06 14:52:09 <minimal> the point i'm getting to is for Alpine diskless the initramfs' init assembles a rootfs in memory and if something goes wrong with that then that is perhaps why there's on /sbin/init in the rootfs to switch to
2023-08-06 14:53:05 <micahrl[m]> ooh, can I tell it to boot without quiet? that sounds like what I want
2023-08-06 14:54:28 <minimal> looking at mkinit-standard.sh I don't see it setting "quiet" for x86_64 so am confused
2023-08-06 14:55:33 <micahrl[m]> I see "quiet" in "initfs_cmdline" in the profile_base definition in mkimage.base.sh
2023-08-06 14:55:57 <minimal> yeah i'm looking through that currently
2023-08-06 14:56:19 <micahrl[m]> what is mkinit-standard.sh? I don't see that in aports/scripts or my $PATH
2023-08-06 14:56:45 <minimal> typo, mkimg-standard.sh
2023-08-06 14:57:32 <minimal> not sure how you modify the isolinux cmdline during boot, so you could try removing "quiet" from initfs_cmdline in mkimg-base.sh and rebuild the ISO
2023-08-06 15:00:56 <micahrl[m]> yeah, I'll give that a shot. Will take me a bit, I'm building in qemu which is a bit slow, but will report back when I have it
2023-08-06 15:07:23 <minimal> micahrl[m]: why do you want to build your own ISO? what are you trying to achieve?
2023-08-06 15:08:33 <micahrl[m]> I want to build an iso that includes some specific packages in the cdrom apk repository and some files in the in-ram filesystem. Ran into this problem, and worked backwards trying to see if I could even build the standard one, which is where I am now.
2023-08-06 15:10:41 <micahrl[m]> ultimately I want to have an iso that runs like an appliance
2023-08-06 15:11:25 <minimal> so you'll only be booting from ISO each time?
2023-08-06 15:11:32 <micahrl[m]> yes
2023-08-06 15:11:57 <minimal> so what about package updates?
2023-08-06 15:14:01 <micahrl[m]> I plan to update packages in ram while booted. kernel updates will require rebuilding the iso of course, but I would like to automate that. the system can accept a new iso and write it to its usb disk, like a firmware update.
2023-08-06 15:15:13 <minimal> so if its booting from USB stick/disk then why use ISO? why not install diskless files onto r/w filesystem and then you can create/store lbu file with your changes?
2023-08-06 15:25:03 <micahrl[m]> that requires setting it up individually on each system. I want to have a generic USB stick that will boot properly on multiple systems at once, that will even work for a new system if I decide I need one.
2023-08-06 15:26:14 <micahrl[m]> aha. it is a problem with the apk signature. * Installing packages to root filesystem: WARNING: opening /media/cdrom/apks: UNTRUSTED signature. OK: 0 MiB in 0 packages
2023-08-06 15:28:08 <minimal> micahrl[m]: there is some work in progress using tiny-cloud to automate installations
2023-08-06 15:28:47 <micahrl[m]> I have a key I generated for apkbuild in the past, and I copied it on to my fresh builder system yesterday - so it wasn't placed there by abuild-keygen. Maybe I did something wrong? On my builder box its in ~/.abuild, it's set as PACKAGER_PRIVKEY in abuild.conf, and it exsts in /etc/apk/keys. Is there somethign else I need to do?
2023-08-06 15:29:02 <micahrl[m]> ooh yes I have seen that tiny-cloud package but haven't delved into it. going to keep my eye on it!
2023-08-06 15:29:07 <minimal> also if you only run-from-ram (with no LBU used) then what happens to any data whenever you boot? it's lost...
2023-08-06 15:30:12 <minimal> it needs to be present in the /etc/apk/keys directory of the in-memory rootfs
2023-08-06 15:30:42 <minimal> BTW I use cloud-init for configuring (both physical & virtual) machines
2023-08-06 15:30:44 <micahrl[m]> huh. well I see it there in the rescue shell.
2023-08-06 15:32:03 <minimal> inside the /etc/apk/keys directory or $sysroot/etc/apk/keys directory or both directories?
2023-08-06 15:32:23 <micahrl[m]> both directories
2023-08-06 15:32:50 <micahrl[m]> I wonder if it's being signed with a key I dont' expect, maybe I can get info on the signature used for the specific APK index in question
2023-08-06 15:42:45 <micahrl[m]> well, I can extract the APKINDEX.tar.gz, and inside it there's a file .SIGN.RSA.psyops@micahrl.com-62ca1973.rsa.pub. That matches the filename psyops@micahrl.com-62ca1973.rsa.pub that's in both /etc/apk/keys and /sysroot/etc/apk/keys. It looks like an APKINDEX from the official cdrom, just signed with my own key. 
2023-08-06 15:56:41 <minimal> that should be ok then
2023-08-06 16:02:51 <micahrl[m]> apk verify --root . /media/cdrom/apks/x86_64/APKINDEX.tar.gz failes with UNTRUSTED
2023-08-06 17:00:23 <micahrl[m]> ok it's got to be something with the way I am placing my signing key... when I generate a fresh one with abuild-keygen it works. 
2023-08-06 17:01:36 <minimal> you are "placing" your private key, right? ;-)
2023-08-06 17:02:12 <minimal> sign with your private, verify with your public
2023-08-06 17:05:05 <micahrl[m]> yes. but here's what I'm doing wrong: I copied my private key to the builder vm, and then generated the public key from that, using ssh tooling. That resulted in an ssh public key in the wrong format.
2023-08-06 17:06:17 <micahrl[m]> then of course I totally forgot that i had done it this way. only now realizing what happened when I compare the public key that abuild-keygen is creating to the one I'm creating. mine looks like ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnPCk60luDwbcmQMj7bgcl5CUy... but it should be like -----BEGIN PUBLIC KEY...
2023-08-06 17:08:09 <minimal> michahrl[m]: who said it should be a SSH key? Looking at my notes I used "openssl rsa" to create a pubkey from private key
2023-08-06 17:11:37 <micahrl[m]> bad assumption on my part I think
2023-08-06 17:23:10 <MHickford[m]1> Hi. When and how does a package move from testing to community? https://pkgs.alpinelinux.org/packages?name=git-credential-oauth
2023-08-06 17:25:20 <ikke> MHickford[m]1: the maintainer creates a merge request that does so
2023-08-06 17:25:50 <MHickford[m]1> The package maintainer? Okay I’ll do that
2023-08-06 17:25:53 <ikke> yes
2023-08-06 17:26:00 <MHickford[m]1> Thanks
2023-08-06 17:48:34 <micahrl[m]> omg. it worked. dang. I can't believe I've been banging my head against this for so long for such a dumb mistake. 
2023-08-06 17:48:39 <micahrl[m]> ty for the help today
2023-08-06 18:29:19 <MHickford[m]1> <ikke> "M Hickford: the maintainer..." <- Like this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49666
2023-08-06 18:30:34 <ikke> Yes, but could you adjust the commit message to: 'community/git-credential-oauth: move from testing'?
2023-08-06 18:35:34 <ikke> MHickford[m]1: let me know if you need help with that
2023-08-06 18:37:37 <MHickford[m]1> <ikke> "Yes, but could you adjust the..." <- done
2023-08-06 18:37:54 <ikke> 👍
2023-08-06 18:40:57 <MHickford[m]1> I added a different package to testing yesterday. Should I let that stew before proposing to move to community? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/git-credential-azure/APKBUILD
2023-08-06 18:42:51 <ikke> MHickford[m]1: If you verified yourself it's working good enough, it should not be an issue to move it to community
2023-08-06 18:45:54 <MHickford[m]1> Thanks https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49668
2023-08-07 07:05:03 <ncopa> morning
2023-08-07 07:09:31 <nmeum> hi
2023-08-07 07:11:56 <ikke> o/
2023-08-07 07:12:24 <ncopa> will try make stable releases today
2023-08-07 07:13:34 <ikke> Alright 
2023-08-07 09:55:36 <EvTheFuture> A quick question. I'm trying to build Carla in Edge but it doesn't build anymore (neither the latest nor the previous versions), it build just fine in 3.18. Is there something that has been moved regarding sys/stat.h or sys/types.h ?
2023-08-07 09:56:24 <ncopa> what is the exact build error?
2023-08-07 09:56:44 <EvTheFuture> I'll upload a log
2023-08-07 09:58:37 <EvTheFuture> @ncopa: https://valitron.se/carla.log
2023-08-07 09:59:54 <EvTheFuture> files/File.cpp:1226:20: note: forward declaration of 'struct water::{anonymous}::stat64'
2023-08-07 10:16:10 <ikke> Ah, lfs64
2023-08-07 10:17:28 <ikke> EvTheFuture: You need to fix/patch it to not use stat64, but just stat
2023-08-07 10:17:38 <ikke> same with other *64 syscalls
2023-08-07 10:38:35 <ncopa> should probably be reported upstream
2023-08-07 10:39:13 <ikke> yes, indeed
2023-08-07 11:08:56 <ncopa> my lxd containers no longer start for some reason
2023-08-07 11:09:19 <ncopa> lxc alpine-3-18 20230807110741.667 ERROR    conf - ../src/lxc/conf.c:lxc_map_ids:3701 - newuidmap failed to write mapping "newuidmap: Target process 9823 is owned by a different user: uid:0 pw_uid:0 st_uid:0, gid:113 pw_gid:0 st_gid:113": newuidmap 9823 0 1000000 1000000000
2023-08-07 11:45:53 <EvTheFuture> ikke: Thanks, I'll look into it
2023-08-07 12:33:46 <rnalrd> ncopa reading it now, why the change broke the config, sigh
2023-08-07 12:34:12 <rnalrd> didn't think of subuid maps
2023-08-07 12:35:06 <rnalrd> *subgid
2023-08-07 12:52:49 <ncopa> 👍
2023-08-07 15:11:47 <PureTryOut> Huh, abuild checksum fails due to curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
2023-08-07 15:17:45 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.15.10-3.16.7-3.17.5-3.18.3-released.html
2023-08-07 15:19:19 <ikke> ncopa: Looks fine to me
2023-08-07 15:19:42 <ncopa> i think the links to some of the CVEs are a bit confusing
2023-08-07 15:20:01 <ikke> You mean the pages?
2023-08-07 15:20:02 <ncopa> for example https://security.alpinelinux.org/vuln/CVE-2023-3446
2023-08-07 15:20:05 <ncopa> yes
2023-08-07 15:20:15 <ncopa> why is not 3.17-stable mentioned there?
2023-08-07 15:21:20 <ikke> Unclear to me
2023-08-07 15:21:26 <ncopa> here it is mentioned for every git branch https://security.alpinelinux.org/vuln/CVE-2023-3817
2023-08-07 15:21:37 <ncopa> yup, its confusing
2023-08-07 15:22:02 <ikke> I mean, even if I look at the output of the jobs that update those things, I can hardly see what is happening why
2023-08-07 15:22:33 <ikke> There are no CPE uris, so all data must come from our own indication
2023-08-07 15:46:52 <telmich> I was wondering whether we can enable CONFIG_DYNAMIC_DEBUG on linux-edge?
2023-08-07 15:47:04 <telmich> linux-lts has it and its very valuable for debugging, -edge does not have it atm
2023-08-07 15:47:48 <ikke> telmich: best way to request it is to create an issue on gitlab
2023-08-07 15:48:02 <ikke> mps maintains -edge and that's his preferred method
2023-08-07 15:48:08 <telmich> ack
2023-08-07 15:48:10 <telmich> thanks!
2023-08-07 15:56:54 <quinq> nice!
2023-08-07 16:01:17 <EvTheFuture> Now it works. MR !49641
2023-08-07 16:50:52 <Arnavion> openssh's APKBUILD has `license="BSD"` which raises a CI lint that it's not a valid SPDX identifier. The correct one seems to be   https://spdx.org/licenses/SSH-OpenSSH.html
2023-08-07 16:51:36 <Arnavion> Any objection to switching to that?
2023-08-07 17:14:47 <fluix> if that's the correct one I don't think there would be an objection
2023-08-07 17:23:44 <omni> https://lwn.net/Articles/940684/
2023-08-07 17:23:59 <omni> LXD fork Incus
2023-08-07 17:34:20 <ncopa> Arnavion: no objection if that is the correct license
2023-08-07 17:34:31 <ncopa> thanks!
2023-08-07 17:37:00 <Arnavion> Okay, I'll send out an MR for that too
2023-08-07 17:40:09 <minimal> omni: yeah I mentioned that in alpine-offtopic over the weekend.
2023-08-07 17:40:26 <minimal> it's early days yet for it
2023-08-07 17:51:11 <bl4ckb0ne> build failed for ffmpeg after placebo bump https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1079588 but it doesnt seems related 
2023-08-07 17:55:25 <sam_> that is binutils-2.41
2023-08-07 18:24:20 <bl4ckb0ne> wdym
2023-08-07 18:26:50 <sam_> that error is caused by binutils-2.41
2023-08-07 18:41:35 <bl4ckb0ne> oh right
2023-08-08 01:46:13 <bl4ckb0ne> can abump bump pkgrel?
2023-08-08 01:47:40 <fluix> yes, -a I think
2023-08-08 01:48:06 <fluix> err no, that's another tool
2023-08-08 01:48:22 <fluix> yeah, I'm thinking of apkgrel https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers#apkgrel
2023-08-08 01:51:16 <bl4ckb0ne> completely missed it, thanks!
2023-08-08 01:53:58 <bl4ckb0ne> should I bother rebuild packages in /testing after bumping a dep
2023-08-08 01:57:25 <fluix> I did to check for compatibility, not sure if it's required
2023-08-08 01:57:31 <fluix> this was for Python, mind you
2023-08-08 02:00:03 <bl4ckb0ne> i dont think its needed, its a patch rel
2023-08-08 04:05:03 <ikke> bl4ckb0ne: rebuilds are necessary after a soname change 
2023-08-08 06:56:15 <dzilvys> Morning all, has alpine removed ethernet-wol g and replaced it with pre-up /usr/sbin/ethtool -s eth0 wol g?
2023-08-08 07:01:27 <dzilvys> actually better question should be, how come eth0 is down by default?
2023-08-08 07:01:30 <dzilvys> when booting up
2023-08-08 07:14:23 <dzilvys> so I have identified what the issue is causing it to come back up. Can someone explain to me why hwaddress ether is causing it to error with it saying that the mac address is a garbage?
2023-08-08 08:20:28 <dari> dzilvys: how did you generate your mac?
2023-08-08 08:27:20 <dzilvys> the mac is a valid mac. Setting it via ip link set eth0 address xx:xx:xx:xx:xx:xx. However, having a line under my eth0 interface in interfaces file with `hwaddress ether xx:xx:xx:xx:xx:xx` fails
2023-08-08 08:28:56 <dari> dzilvys: could you try put this: hwaddress xx:xx:xx:xx:xx:xx
2023-08-08 08:30:45 <dzilvys> that worked thank you :)
2023-08-08 08:30:55 <dari> dzilvys: :)
2023-08-08 08:35:09 <dari> dzilvys: btw lets not distract people here and next time better to use #alpine-linux channel :)
2023-08-08 08:35:16 <dzilvys> ah okay 
2023-08-08 09:39:09 <PureTryOut> Any clue why curl suddenly fails to set a certificate file? It makes me unable to use abuild checksum 🤔
2023-08-08 09:39:11 <PureTryOut> curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
2023-08-08 09:39:56 <ikke> Haven't noticed it myself yet
2023-08-08 09:42:30 <PureTryOut> It started happening yesterday out of the blue. I didn't change any abuild settings
2023-08-08 09:43:15 <ovf> PureTryOut: is it happening outside of abuild? e.g. curl -I https://alpinelinux.org
2023-08-08 09:43:32 <PureTryOut> it is yes
2023-08-08 09:43:56 <ovf> apk audit /etc/ssl/certs ?
2023-08-08 09:44:57 <PureTryOut> A etc/ssl/certs/java/cacerts
2023-08-08 09:45:34 <PureTryOut> Huh, reinstalled ca-certificates-bundle and it works again
2023-08-08 09:45:45 <PureTryOut> For some reason ca-certificates.crt just wasn't present?
2023-08-08 09:46:16 <ovf> shouldn't `apk audit` have complained?
2023-08-08 09:46:36 <PureTryOut> You'd say so yes, but it didn't 🤷
2023-08-08 09:46:43 <PureTryOut> It only listed the java certificate
2023-08-08 09:54:11 <ovf> in fact i feel that ca-certificates-bundle should conflict with ca-certificates
2023-08-08 10:23:46 <ikke> ncopa: thanks for fixing gitlab-runner
2023-08-08 10:24:44 <ncopa> np. was critical so i thought I'd just push a fix
2023-08-08 12:12:31 <Ermine> skarnet: could you take a look at !49512 ?
2023-08-08 12:36:15 <skarnet> Ermine: done :)
2023-08-08 12:39:32 <Ermine> skarnet: thank you!
2023-08-08 13:01:44 <minimal> ovf: why should ca-certificates-bundle conflict with ca-certificates?
2023-08-08 13:03:48 <ovf> minimal: the latter has a trigger that overwrite the former's contents
2023-08-08 13:06:34 <minimal> ovf: correct, but if they conflicted then on a machine with any package installed that depends on ca-certificates-bundle package then you wouldn't be able to add/remove individual certs from the bundle
2023-08-08 13:07:19 <minimal> some software used the bundle, other software uses the individual certs in the certs dir
2023-08-08 13:09:14 <ovf> they should probably both provide (the virtual marker of) /etc/ssl/certs/ca-certificates.crt?
2023-08-08 13:10:00 <minimal> "virtual marker of" - I don't understand what you mean
2023-08-08 13:10:11 <minimal> you mean a virtual package?
2023-08-08 13:13:00 <minimal> I assume ca-certificates-bundle exists for "size" reasons to avoid needing space for both all individual certs and the bundle (containing all the certs)
2023-08-08 13:15:49 <ovf> both packages should provide the "bundle", so the software that cares only about that will depend on either of them; packages which need the individual certs (why?) would depend on ca-certificates, just like they do now
2023-08-08 13:16:54 <minimal> "packages which need the individual certs (why?)" - because some software is written to use them rather than a bundle
2023-08-08 13:16:56 <ovf> or simply, installing ca-certificates should remove ca-certificates-bundle
2023-08-08 13:18:15 <minimal> "installing ca-certificates should remove ca-certificates-bundle" - so you are talking about a virtual package then rather than them conflicting, and other packages would then need to dep on the virtual package
2023-08-08 13:19:28 <minimal> if you look on pkg.alpinelinux.org, 10 packages depend on the bundle package, and 49 packages depend on ca-certificates
2023-08-08 17:18:46 <nmeum> I have just pushed Go 1.21.0, toolchain downloading has been disabled. let me know if anything breaks
2023-08-08 17:19:19 <nmeum> would prefer not to rebuld all packages with Go 1.21.0 immediately
2023-08-08 17:27:50 <ikke> 👍
2023-08-08 17:28:11 <ikke> ok, testing has not been rebuilt with go 1.20.7 either
2023-08-08 17:28:15 <ikke> (yet)
2023-08-08 17:31:37 <eddsalkield> I'm trying to build a package for castxml, which is reporting `Clang_DIR or LLVM_DIR refers to a LLVM/Clang build directory:` for Clang_DIR=/usr/lib/llvm15/lib/cmake/clang and LLVM_DIR=/usr/lib/llvm15/lib/cmake/llvm
2023-08-08 17:32:00 <eddsalkield> Then it reports CastXML must be built against a LLVM/Clang install tree
2023-08-08 17:32:16 <eddsalkield> does anyone know the difference between a build directory for clang, and the install tree in this case?
2023-08-08 17:32:26 <eddsalkield> looking at packages for other distros I'd expect this to work
2023-08-08 19:05:08 <pj> what was the condition for rebuilding all packages built with specific toolchain?
2023-08-08 19:32:00 <ikke> pj: For statically built packages we do it mostly to make sure the package still build
2023-08-09 03:32:49 <rootwyrm> So, I am perplexed... u-boot-libretech provides /usr/share/u-boot/libretech-cc/u-boot.bin, which file says is a PCX. So what -is- it?
2023-08-09 12:57:28 <eddsalkield> I've tracked down the castxml build issue, it appears to be an issue with `/usr/lib/llvm15/lib/cmake/llvm/LLVMConfig.cmake` on alpine in llvm15-dev
2023-08-09 12:57:37 <eddsalkield> it contains comment `# LLVM_BUILD_* values available only from LLVM build tree.`
2023-08-09 12:57:46 <eddsalkield> but then proceeds to `set(LLVM_BUILD_BINARY_DIR "/home/buildozer/aports/main/llvm15/src/llvm-project-15.0.7.src/build")`
2023-08-09 12:58:14 <eddsalkield> so castxml sees that LLVM_BUILD_BINARY_DIR is set, and determine that it's in the LLVM build tree
2023-08-09 12:58:22 <eddsalkield> which it isn't
2023-08-09 12:58:44 <eddsalkield> does someone with some llvm knowledge know what the best way to patch this would be?
2023-08-09 14:33:35 <ncopa> eddsalkield: do you think you could create an issue in gitlab, with all the details and how to reproduce?
2023-08-09 14:33:48 <ncopa> I can have a look at it later this week, or maybe next
2023-08-09 14:44:52 <rootwyrm> So if anyone answered my question about u-boot-libretech, I missed it. What exactly is the output of that package? The meta setup doesn't make a lot of sense to me.
2023-08-09 14:49:04 <pj> rootwyrm: you should generally ask such questions in #alpine-linux
2023-08-09 14:50:47 <rootwyrm> pj: this is much more a -devel question though, because I'm trying to find out specifically what type of u-boot build it is.
2023-08-09 14:51:51 <pj> ah, it's maintained by mps
2023-08-09 14:51:58 <pj> then it should be #alpine-infra 
2023-08-09 14:52:09 <pj> (half sarcasm, half not)
2023-08-09 14:53:58 <rootwyrm> Haha, totally fair. Believe me, I KNOW how it is.
2023-08-09 14:55:05 <pj> I mean, mps is refusing to join this channel so...
2023-08-09 15:59:37 <ikke> reviewers wanted for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49781
2023-08-09 17:04:38 <eddsalkield> ncopa: sure, I'm planning to create a package for castxml which will contain a patch to hack around the issue - this should work nicely to reproduce
2023-08-09 20:07:47 <Arnavion> ncopa: Ping for your opinion on   https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49724#note_328653
2023-08-10 04:24:24 <linearcannon> trying to rebase my m68k port, and ran into an issue bootstrapping, but it looks like it's not something specific to my port
2023-08-10 04:24:47 <linearcannon> main/musl, commit 19b285aa, changed to use `cc` instead of `gcc` for portability, but this breaks bootstrap for every arch i've tried
2023-08-10 04:25:53 <linearcannon> could just revert it, but maybe the correct thing would instead be to ensure that gcc is symlinked also as cc
2023-08-10 04:29:48 <linearcannon> including for cross-compilation, which seems to be the issue here
2023-08-10 04:30:24 <linearcannon> (i.e. `cc` exists, but `x86_64-alpine-linux-musl-cc` does not)
2023-08-10 05:05:55 <linearcannon> yeah, i think i'll just do that and send a pr
2023-08-10 05:06:07 <linearcannon> i think the change is sound, there was just a faulty assumption and i can correct that assumption
2023-08-10 05:44:21 <linearcannon> ip a
2023-08-10 05:44:25 <linearcannon> wrong window 
2023-08-10 10:11:15 <ncopa> Arnavion: im trying to find the "wordsplitting" problem?
2023-08-10 15:35:53 <Arnavion> ncopa: If a filename has a space it'll be treated like two filenames
2023-08-10 15:37:05 <rootwyrm> okay, somebody please check my sanity real quick. u-boot _is_ building in the pipeline from 2023.07.02 with just 2 patches, right?
2023-08-10 15:54:55 <ncopa> Arnavion: aha
2023-08-11 08:35:45 <quinq> Hello
2023-08-11 08:36:30 <quinq> Just a quick nudge to say that xournalpp package is broken, it's missing a dependency on adwaita-icon-theme and won't start otherwise apparently
2023-08-11 08:37:40 <quinq> Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Icon 'image-missing' not present in theme Adwaita (gtk-icon-theme-error-quark, 0)
2023-08-11 09:07:44 <ncopa> I created an issue so we dont forget. thanks! https://gitlab.alpinelinux.org/alpine/aports/-/issues/15189
2023-08-11 09:16:51 <quinq> Thanks ncopa, sorry I should have done it myself, but I'm at work and didn't want to forget, so I put it here mostly as a self-reminder
2023-08-11 09:16:57 <quinq> Will try to do it directly next time
2023-08-11 09:17:41 <ncopa> no worries
2023-08-11 09:17:55 <ncopa> we help each other as good as we can :)
2023-08-11 09:46:59 <quinq> :>
2023-08-11 10:01:23 <ddevault> I have contributed to Alpine for six years
2023-08-11 10:01:28 <ddevault> I maintain a hundred packages
2023-08-11 10:01:38 <ddevault> I have patches in half the software alpine built
2023-08-11 10:01:49 <ddevault> if you have ever read an apk-tools man page, you're welcome
2023-08-11 10:01:58 <ddevault> I maintain the mailing lists and I have root access to alpine infra
2023-08-11 10:02:19 <ddevault> I need one thing to do my job effectively, and for years I have been denied it for ridiculous and poorly explained reasons
2023-08-11 10:02:25 <ddevault> call me when you give a damn about my work
2023-08-11 10:04:40 <quinq> :/
2023-08-11 10:15:14 <dhruvin> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49901
2023-08-11 10:19:27 <ncopa> seems like we are making more people angry than happy these days
2023-08-11 10:22:34 <quinq> Could we have a few hints about what's their disappointment about, or it has to stay private?
2023-08-11 10:27:54 <ncopa> i think we will share some of the details soonish
2023-08-11 10:28:38 <quinq> Allright, thank you :)
2023-08-11 11:28:52 <ncopa> so this is related: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/71
2023-08-11 11:29:36 <ncopa> he did not get enough votes to pass
2023-08-11 11:31:21 <ncopa> we wanted to see him more active on gitlab before giving him merge access
2023-08-11 11:42:34 <ncopa> I suppose https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49901 illustrates parts of the problem: Merge blocked: fast-forward merge is not possible. To merge this request, first rebase locally.
2023-08-11 11:48:39 <quinq> Well, voting on a group of people might not be the best way, shouldn't this be an individual process?
2023-08-11 11:49:41 <quinq> Ah, I take that back, I can see “+1 for @ptrcnull”
2023-08-11 11:49:50 <quinq> Still, looks a bit mixed up
2023-08-11 11:50:01 <ncopa> there was a vote for each person individually
2023-08-11 11:50:15 <quinq> Yeah, sorry
2023-08-11 11:51:32 <ncopa> but many people has left recently, so I suppose we should think of how to improve current processes
2023-08-11 11:52:54 <quinq> If that's the actual reason
2023-08-11 13:19:31 <zcrayfish> I wish people wouldn't push themselves to the point of burnout. :(
2023-08-11 13:27:16 <PureTryOut> amen
2023-08-11 13:29:04 <PureTryOut> ncopa: don't worry, there are still a lot of people happy with Alpine as well 😄
2023-08-11 13:29:28 <skarnet> oh, definitely :)
2023-08-11 13:29:34 <skarnet> but there's always room for process improvement
2023-08-11 13:30:08 <PureTryOut> Oh of course, always
2023-08-11 13:30:24 <skarnet> I mean, Drew is a smart guy, if hot-headed, so it's kind of a shame that he was pushed to blowing up :/
2023-08-11 13:31:56 <ovf> btw it might be a bit too late, but i've found 'glab' to be tolerable for avoiding then need to use gitlab ui for simple aports merge requests. i do `git push myremote && glab mr create -fy`
2023-08-11 13:32:26 <ovf> s/then/the/
2023-08-11 13:33:15 <skarnet> I'm glab it exists
2023-08-11 13:34:42 <PureTryOut> Lol
2023-08-11 13:49:17 <minimal> zcrayfish: it's not necessarily all down to burnout, there's likely frustration too
2023-08-11 14:03:28 <zcrayfish> True
2023-08-11 14:07:36 <minimal> ncopa: what's the Alpine line on Hashicorp's switch to BUSL - I don't see any packages in aports currently using BUSL, does Alpine permit BUSL-licensed packages? This affects consul, nomad, terraform, vault
2023-08-11 14:15:25 <durrendal> very curious about that as well, don't love the move, but hoping we'll keep the packages in the repos
2023-08-11 14:18:39 <fluix> I think the issue with gitlab is more about merging
2023-08-11 14:20:30 <minimal> durrendal: well I'm the nomad maintainer so wondering what to do next :-(
2023-08-11 14:29:39 <durrendal> I rely heavily on hashicorps stuff for work, and having it in Alpine means I can use my preferred distro for that. It's a selfish reason, but I don't want to switch
2023-08-11 14:29:58 <durrendal> (also thanks for maintaining nomad! hopefully it'll stay a while longer)
2023-08-11 14:30:53 <minimal> ah, just saw talk of openterraform already, an MPL fork lol
2023-08-11 14:31:41 <ncopa> minimal: i dont have the mental energy to deal with that yet
2023-08-11 14:32:15 <minimal> ncopa: ok, the base question was, in general, are BUSL-licensed packages allowed?
2023-08-11 14:32:18 <ncopa> i would guess we will try keep the stuff if we can
2023-08-11 14:32:26 <ncopa> good question, i have no idea
2023-08-11 14:32:56 <ncopa> i dont even know what a BUSL-license is, so I have some reading to first
2023-08-11 14:33:26 <ncopa> yay... what a "lovely" friday https://git.alpinelinux.org/aports/commit/?id=ada848830fe4
2023-08-11 14:34:18 <ncopa> oh...
2023-08-11 14:34:31 <ncopa> heh, i misread it as "drop maintainership"
2023-08-11 14:34:48 <rootwyrm> ncopa: the tl,dr of BUSL is 'same license as MariaDB.'
2023-08-11 14:35:10 <ncopa> so if we forbid BUSL we lose mariadb?
2023-08-11 14:35:45 <rootwyrm> ncopa: my understanding is that Hashi is taking MariaDB BUSL basically verbatim
2023-08-11 14:36:05 <minimal> actually I'd look on pkgs.alpinelinux.org yesterday at mariadb and noticed it still says GPL-2.0-or-later
2023-08-11 14:36:16 <minimal> don't know when MariaDB switched/switches
2023-08-11 14:36:23 <ncopa> i suppose it can wait til over the weekend. i think i need a break
2023-08-11 14:37:25 <minimal> if Nomad goes then I would think to switch to lxd as an alternative....except with its recent changes it now has a new fork so thing are up-in-the-air there too :-(
2023-08-11 14:37:29 <ikke> Yeah, a break is good
2023-08-11 14:37:57 <rootwyrm> MariaDB itself is GPL2, but MaxScale is BUSL
2023-08-11 14:38:24 <rootwyrm> so if MaxScale is not allowed, Hashi is out. ;/
2023-08-11 14:39:00 <ikke> BSL is not OSI approved. We would be allowed to distribute it, but it's a discriminatory license 
2023-08-11 14:39:18 <ikke> We dropped mongodb 
2023-08-11 14:40:32 <rootwyrm> yeah, if no OSI or FSF approval's the decider, everything hashi's right out.
2023-08-11 14:41:00 <skarnet> honestly that's what should happen in every free software distribution
2023-08-11 14:41:17 <skarnet> throw it out
2023-08-11 14:41:26 <skarnet> it sucks for users, but it's all on the corp
2023-08-11 14:41:29 <minimal> rootwyrm: yeah I found it confusing when I was searching about MariaDB yesterday
2023-08-11 14:42:22 <rootwyrm> minimal: basically, the core product (MariaDB) is GPL2. the fancy 'pretend mysql scales' part is BSL
2023-08-11 14:42:38 <rootwyrm> kinda like postgresql vs maxdb.
2023-08-11 14:43:00 <rootwyrm> or whatever it is this month. i forget. either way, you get the general idea.
2023-08-11 14:43:24 <minimal> it doesn't help that both BSL and BUSL are used to refer to the same license (due to another license also using BSL acronym)
2023-08-11 14:43:31 <ncopa> in any case, i don't think it is wise to rush it
2023-08-11 14:47:19 <minimal> yeah, give it the weekend for more forks to appear ;-)
2023-08-11 14:48:07 <rootwyrm> Looks like there's already coalescing around a fork. Hashi's interpretation is also a pretty ugly and blatant money grab.
2023-08-11 14:53:45 <minimal> I wouldn't exactly call it a "money grab", more a case of "the business model we assumed would work isn't and we need to find another way to remain financially viable"
2023-08-11 14:54:17 <minimal> similar to Elastic etc...
2023-08-11 14:55:46 <skarnet> yeah but it's cute they think changing the license and alienating the community will make their stuff profitable
2023-08-11 14:56:18 <minimal> skarnet: especially when a lot of the terraform providers are not written by Hashi
2023-08-11 14:57:54 <minimal> i.e. alienate the people who write many of the providers, the number of breadth of which make terraform attractive to so many people
2023-08-11 14:59:18 <minimal> though I think there reasons for change may also include Vault as it is potentially a "money spinner" for their Hashi's Enterprise sales team
2023-08-11 15:02:56 <PabloCorreaGomez[m]> Have a good rest ncopa, hope you can disconnect over the weekend
2023-08-11 19:40:59 <jfndoejdnj> Hello
2023-08-11 19:41:22 <jfndoejdnj> I need help with dm verity 
2023-08-11 19:44:56 <jfndoejdnj> Hello if anybody is available, I am having trouble with getting dm verity to work, I followed arch linux wiki but I dont use systemd. What are the specific kernel parameters for dm verity?
2023-08-11 19:47:36 <minimal> not sure what you are referring to by kernel parameters
2023-08-11 19:48:04 <minimal> I assume you've set up the device and are asking what you need to specify on cmdline to activate it on boot
2023-08-11 19:48:37 <jfndoejdnj> yes
2023-08-11 19:48:38 <minimal> and I'm assuming the answer is that Alpine's initramfs' init does not support verity
2023-08-11 19:49:30 <minimal> it is the initramfs' init plus nlplug-findfs that mount the rootfs
2023-08-11 21:52:20 <ikke> oh, pkgconf-2.0.1 dropped
2023-08-11 21:52:31 <ikke> "The behavior of --modversion was largely reverted back to the traditional pkg-config behavior, but still operates on a solved dependency graph.
2023-08-11 21:52:33 <ikke> "
2023-08-11 21:55:40 <ptrc> yeah, that allows us to drop the patches from mozilla stuff and also upgrade some other packages that were blocked otherwise
2023-08-12 08:46:51 <WhyNotHugo> 'pulseaudio' has not had a maintainer for over a year. Is it worth keeping in community, given that pipewire is "the modern replacement"?
2023-08-12 10:34:26 <Ermine> WhyNotHugo: I think many people use pulseaudio
2023-08-12 10:50:35 <Newbyte> It is still the default downstream in pmOS for every user interface apart from Sxmo, so it would be better if we could find someone willing to maintain it than moving it to testing
2023-08-12 10:50:48 <Newbyte> Oops, I replied to the wrong event …
2023-08-12 11:30:19 <pj> Newbyte: why would you move it to testing
2023-08-12 12:28:43 <Newbyte> <pj> "Newbyte: why would you move it..." <- WhyNotHugo asked if it is worth keeping it in community. I'm assuming he doesn't mean we should move it to main.
2023-08-12 12:28:44 <caskd[m]> i still use it since it's not a "replacement" yet
2023-08-12 12:28:59 <caskd[m]> it lacks a few features i rely one
2023-08-12 12:29:04 <caskd[m]> * it lacks a few features i rely one
2023-08-12 12:29:32 <WhyNotHugo> Sounds like it just needs a new maintainer then :)
2023-08-12 12:29:46 <caskd[m]> i'll bump it but i don't wanna throw myself as a maintainer for it since i can't even manage the handful of stuff i'm a maintainer on
2023-08-12 12:30:13 <WhyNotHugo> Also asking to learn a bit how things are moved around
2023-08-12 12:32:58 <Newbyte> I guess it should/could be maintained by that "Alpine Desktop" team that's been talked about (which I would be part of)
2023-08-12 12:33:04 <Newbyte> presumably
2023-08-12 12:33:23 <Newbyte> but for now PulseAudio seems very low-maintenance since it isn't really getting updated
2023-08-12 13:31:30 <caskd[m]> alpine desktop? i guess i kinda count to that
2023-08-12 17:25:01 <ptrc> every day i'm getting even more convinced we need a "type:out-of-scope" label on aports issues for all the people who open issues like "hey i use this random docker container and *thing* is not working"
2023-08-12 17:26:31 <minimal> and also for "I added testing to my 3.18 as I *really* want to use something that is only in testing"
2023-08-12 17:30:25 <ikke> ptrc: we have `triage:not-supported`
2023-08-12 17:41:55 <dari> minimal: :D
2023-08-12 17:43:38 <ptrc> ikke: oh, that sounds good
2023-08-12 17:57:19 <Misthios> :)
2023-08-12 20:00:15 <ikke> upgrading gitlab
2023-08-13 07:00:45 <ayushnix> raised a MR to improve the pounce package
2023-08-13 07:00:47 <ayushnix> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49970
2023-08-13 07:39:12 <j_v> ptrc: looking at e0632e9c for testing/nsjail. rather than patching rlimit64 to rlimit, adding -D_LARGEFILE64_SOURCE to COMMON_FLAGS in Makefile seems to work since it triggers <sys/resource> #define rlimit64 rlimit. What do you think?
2023-08-13 07:39:39 <sam_> that's only going to work for one release cycle of musl
2023-08-13 07:39:45 <sam_> please don't do that, it's not upstreamable and it won't last
2023-08-13 07:40:16 <j_v> ok, will get with upstream then... thanks for input
2023-08-13 07:40:21 <sam_> np
2023-08-13 07:43:02 <celie> Is _LARGEFILE64_SOURCE going to be removed in a future release of musl?
2023-08-13 07:44:23 <sam_> yes
2023-08-13 07:44:41 <celie> Ok
2023-08-13 08:12:58 <j_v> ptrc: btw, thanks for taking care of the build issue for nsjail... I will try to set a more effective build/test schedule that hopefully will drop these kind of issues in my lap and I can carry the burden as I am supposed to, sorry for any extra work caused to you.
2023-08-13 09:11:30 <ayushnix> ikke: thanks, I've resolved the issues in my MR
2023-08-13 13:26:17 <timlegge> looking at fixing apkbuild-cpan for the recent perl depreciation of given.  Simplest method is to use the perl-syntax-keyword-match I added to testing recently but it means moving it to main I believe.  Would this be an issue or should I look at something that does not add a dependency.
2023-08-13 14:25:12 <ptrc> j_v: i don't suppose you could have caught musl dropping some symbols used by the software, unless you'd be rebuilding it on a weekly basis :p and it's alright~
2023-08-13 14:28:07 <ikke> remember edge is meant to catch these kinds of issues. Even though we don't try to break things on edge, people should not expect everything to be 100% working all the time
2023-08-13 14:31:23 <ikke> And these kind of common issues we figure out together and help eachother solve them
2023-08-13 14:31:57 <EvTheFuture> I, looking into Issue 
2023-08-13 14:31:59 <EvTheFuture> #15194
2023-08-13 14:33:31 <EvTheFuture> I manage to get two plugin packages when i build now, but the plugin subpackages gets automatic dependency on the main package. How would I make the builder to not add this dependency so the plugin subpackages can be installed without the main app?
2023-08-13 14:33:52 <ikke> EvTheFuture: add depends="" inside the split function
2023-08-13 14:34:34 <ikke> (How funny that I already anticipated that question)
2023-08-13 14:35:50 <EvTheFuture> Yeah I'm a n00b :=)
2023-08-13 14:36:45 <ikke> EvTheFuture: No worry at all, we're here to help eachother
2023-08-13 14:37:25 <ikke> We don't expect you to understand all abuild mechanisms
2023-08-13 14:37:30 <EvTheFuture> Since it wont automatically generate depends in the main package on the two new subpackages, will this do that too or do I need to add something to solve that? I dont want upgrades to break and to be honest when installing the main package the plugins I think is expected to be installed as well
2023-08-13 14:38:12 <ikke> You can add a dependency on the subpackage
2023-08-13 14:38:12 <EvTheFuture> ikke: Yeah, I appreciate the helpfulness and is one of the reasons I contribute :)
2023-08-13 14:38:42 <EvTheFuture> ikke: on the subpackage? shouldnt it be on the main package?
2023-08-13 14:39:08 <ikke> EvTheFuture: I meant that you can make the main package depend on the subpackage(s)
2023-08-13 14:40:03 <EvTheFuture> ikke: Ok, then I've already done it correctly, thanks.
2023-08-13 14:54:02 <j_v> i was looking into setting up my own gitlab-runner(s), but the more i read about setting it up, the more i realize how little i know about any of what is involved
2023-08-13 14:54:47 <ikke> Setting up a runner should be fairly simple
2023-08-13 14:54:53 <rootwyrm> for gitlab runners? not all that much.
2023-08-13 14:55:45 <rootwyrm> it does get a fair bit weird for certain setups, but you're not likely to run into those.
2023-08-13 14:55:56 <ikke> j_v: We use this to deploy them: https://gitlab.alpinelinux.org/alpine/infra/compose/gitlab-runner-alpine-ci
2023-08-13 14:56:17 <ikke> It uses docker executors and expects the runner having access to the docker socket
2023-08-13 14:56:32 <ikke> It needs to be adjusted though since gitlab is changing the way runners are supposed to be registered
2023-08-13 14:56:46 <rootwyrm> Oh, and you absolutely cannot use containerd.
2023-08-13 14:57:15 <ikke> how so?
2023-08-13 14:57:16 <rootwyrm> (Over 4 years and still waiting for them to fix that bug...)
2023-08-13 14:57:31 <j_v> hmmm, ok, so for starters i might better get better aquainted with docker... have used lxc, bwrap and nsjail, but not docker yet
2023-08-13 14:57:35 <rootwyrm> ikke: if you remind me tomorrow, I can grab the gitlab bug for it.
2023-08-13 14:58:09 <ikke> rootwyrm: we use gitlab-runners with the default docker setup (which uses containerd-shim-runc), not sure if that's the setup you are talking about
2023-08-13 14:58:38 <ikke> j_v: in lxc, you _could_ use a shell executor, but you'd need to make sure yourself that it cleans up after itself
2023-08-13 14:59:09 <rootwyrm> ikke: it's any situation where a process may not be terminated during build for any reason.
2023-08-13 14:59:30 <ikke> rootwyrm: what would happen then?
2023-08-13 14:59:35 <j_v> ikke: thanks for links and tips, much appreciated
2023-08-13 14:59:55 <ikke> We have been using this setup for years, and not noticed any issues with terminated processes
2023-08-13 15:00:19 <rootwyrm> It was supposed to be fixed in 15, wasn't. Then 16.1 because a super-ultra-premium customer complained, that slipped, and it's still broke despite their claimed fix.
2023-08-13 15:00:45 <ikke> I'll see if I can find it
2023-08-13 15:01:02 <ikke> rootwyrm: I assume the issue is in the main gitlab project?
2023-08-13 15:01:04 <rootwyrm> ikke: runner shits the bed and permanently hangs. Bug's in work browser and I am much much stricter about not touching work stuff on weekends these days.
2023-08-13 15:01:18 <ikke> ]:D
2023-08-13 15:01:20 <rootwyrm> IIRC was in gitlab-runner specifically.
2023-08-13 15:04:33 <rootwyrm> unrelated but related: I HATE AMLOGIC SO MUCH AT THIS POINT. <grumble>
2023-08-13 15:05:29 <ikke> cannot find anything relevant in the gitlab-runner project
2023-08-13 15:17:08 <rootwyrm> So, short of an Ampere or an R152, what's the best option for native ARMv8 build hardware these days? (If it's rpi4 I'm gonna just... scream into the void more.) 
2023-08-13 15:21:04 <ikke> rootwyrm: ncopa is fan of apple M1/M2
2023-08-13 15:21:41 <rootwyrm> ikke: right out for me, I won't pay the Apple tax, especially not for a completely non-maintainable box
2023-08-13 15:25:38 <rootwyrm> I was hoping throwing more hardware at qemu might help, but even overclocked Genoa ended up about.. a whole 90 minutes better than a Zen3.
2023-08-13 15:26:19 <ikke> another suggestion would be renting graviton instances from aws, but that's paying the cloud tax
2023-08-13 15:26:41 <ikke> There is not a lot of powerful ARM hw
2023-08-13 15:27:05 <ikke> even ampere mostly depends on amount of cores 
2023-08-13 15:27:30 <rootwyrm> Yeah, and I don't necessarily need massively powerful. Just something that won't burn out SD cards.
2023-08-13 15:27:51 <rootwyrm> qemu is so slow, even a RPi4 is faster.
2023-08-13 15:28:18 <EvTheFuture> ikke: I must be lost today... I've created the subpackages $pkgname-plugins-lv2 and $pkgname-plugins-vst. inside the functions lv2() and vst2() i set depends="" is this correct or have i missed something? Because the sub packages $pkgname-plugins-vst and $pkgname-plugins-lv2 still have auto depends in them...
2023-08-13 15:30:19 <ikke> No, should be fine: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/ncurses/APKBUILD#L212
2023-08-13 15:31:22 <ikke> EvTheFuture: what does apk info -R carla-plugins-vst return?
2023-08-13 15:33:00 <EvTheFuture> ikke: Can you just glimpse on this and see if i did a typo or something else completely wrong?
2023-08-13 15:33:03 <EvTheFuture> https://tpaste.us/8ML8
2023-08-13 15:36:14 <EvTheFuture> ikke: I'm unable to install it on my build system but the .PKGINFO looks like this: https://tpaste.us/rjbL
2023-08-13 15:37:07 <ikke> Probably not an issue, but the install_if combined with depends in the main package is redundant
2023-08-13 15:37:22 <ikke> # automatically detected:
2023-08-13 15:37:24 <ikke> depend = carla=2.5.6-r1
2023-08-13 15:37:43 <ikke> That can happen if there are symlinks to files in the main package
2023-08-13 15:38:38 <EvTheFuture> ikke: Yeah I just tested with the install_if I shall remove it
2023-08-13 15:39:22 <EvTheFuture> Aha, I will investigate that, thank you (for now) :)
2023-08-13 15:40:19 <EvTheFuture> ikke: you are correct, there are a gazillion symlinks there
2023-08-13 15:40:22 <ikke> yeah
2023-08-13 15:40:27 <EvTheFuture> mystery solved, thank you
2023-08-13 15:40:30 <ikke> https://tpaste.us/PEbx
2023-08-13 15:42:04 <EvTheFuture> I'm not sure there are any plugins that will be able to run without Carla to be honest. I lean towards rejecting the Issue...
2023-08-13 15:42:44 <minimal> rootwyrm: building Arm kernels? or something else heavyweight?
2023-08-13 15:43:53 <rootwyrm> minimal: kernel's probably the heaviest weight thing, and it's very much not time sensitive.
2023-08-13 15:44:31 <EvTheFuture> Well, there seems to be a few. I will try to package them separately
2023-08-13 15:45:24 <minimal> rootwyrm: just wonder what you're doing as apart from kernel I don't find using binfmt/qemu-user to build Alpine aarch64 packages on x86_64 unacceptably slow
2023-08-13 15:49:24 <rootwyrm> minimal: the two most frequent builds clock in at over 14 hours. so, a _little_ time sensitive.
2023-08-13 15:53:15 <minimal> rootwyrm: 14 hours for a non-kernel package build?
2023-08-13 15:55:20 <rootwyrm> minimal: mmhmm. It's about as big, but mostly, it chews a lot on ugly instructions that qemu seems to just flail around with.
2023-08-13 15:56:57 <minimal> if it's something like Firefox or Chrome you're building then yeah I can see why QEMU wouldn't cut it.
2023-08-13 15:58:46 <rootwyrm> yeah, and full kernel sets clock in at 'come back tomorrow,' so no bueno. but I don't do enough arm builds even remotely justify an R152.
2023-08-13 16:37:17 <EvTheFuture> ikke: MR created: !49978
2023-08-13 18:28:09 <PabloCorreaGomez[m]> Is there any policy to move things to "unmaintained"? There are a couple of legacy things from GNOME that I'd happy push there
2023-08-13 18:28:27 <PabloCorreaGomez[m]> s/happy/happily/
2023-08-13 18:31:43 <ikke> PabloCorreaGomez[m]: there is no unmaintained directory anymore
2023-08-13 18:31:55 <ikke> either remove yourself as maintainer for other to pick up, or remove it right out
2023-08-13 18:58:48 <PabloCorreaGomez[m]> ikke: ok, thanks. Then for dropping things, it's just up to use to decide, I guess?
2023-08-13 19:00:15 <ikke> removing should only be done if there are good reasons to remove it
2023-08-13 19:00:41 <ikke> If the package is still used and maintained upstream, someone else will probably pick it up
2023-08-13 19:00:48 <PabloCorreaGomez[m]> Ok, got it. Thanks!
2023-08-14 00:03:01 <celie> timlegge: There's a precedent in perl-syntax-keyword-try being moved to main as a new dependency of po4a, but hasn't given-when been removed already in abuild 3.11.21 that was released last month?
2023-08-14 00:04:17 <timlegge> celie: maybe I am out of date :-) It has been a while since I updated my repo so likely - I will check thanks
2023-08-14 00:12:35 <celie> timlegge: There's a apkbuild-pypi (which funny enough, is written in Perl) merge request for removing given-when at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/220 if you're interested (and have free time) to review it
2023-08-14 00:14:59 <celie> As for apkbuild-cpan, since there's no more given-when or ~~, the `use feature "switch"` and `no if $] >= 5.018, warnings => "experimental::smartmatch"` pragmas can probably be removed now..
2023-08-14 00:15:26 <timlegge> celie: just updated and you are right.  It has been a while since I upgraded my repo.  I will need to put a watch on it.  I will take a look at apkbuild-pypi I believe made a bunch of updates to it awhile ago 
2023-08-14 00:15:56 <timlegge> yes exactly
2023-08-14 00:30:06 <timlegge> celie: #220 looks fine to me - commented on MR
2023-08-14 00:30:28 <timlegge> abuild#220
2023-08-14 00:31:20 <ptrc> > ERROR: Metadata for package util-linux-dev-2.39.1-r0 is too long.
2023-08-14 00:31:22 <ptrc> um
2023-08-14 00:33:07 <timlegge> out of curiosity has apkbuild-pypi been useful.  I had fixed it up a couple of years ago but have limited interest in python packages
2023-08-14 00:33:54 <timlegge> happy to fix some more things if a issue gets created and asigned my way
2023-08-14 00:43:58 <celie> timlegge: Thanks, looking forward to 220 being merged. I guess it's been helpful, otherwise we wouldn't get that merge request, I think as a first contribution from that person to boot
2023-08-14 00:44:58 <timlegge> nice
2023-08-14 10:24:59 <ikke> oh, we're over 50K merge requests
2023-08-14 10:30:39 <quinq> Big community :D
2023-08-14 17:59:20 <Ermine> What does 'Guest' access to aports mean?
2023-08-14 17:59:36 <ikke> Ermine: Basically that you can now press the `approve` button again
2023-08-14 17:59:54 <Ermine> Ah, nice, thank you
2023-08-15 02:39:24 <bl4ckb0ne> is it me or the glm package is borked
2023-08-15 02:39:47 <bl4ckb0ne> package is arch="none", x86_64 builds succeeds but x86 fails
2023-08-15 02:39:54 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1085285 armhf and armv7 too
2023-08-15 12:39:33 <eletrotupi> hm, dunno, but I've been trying to run abuild locally
2023-08-15 12:39:56 <eletrotupi> and some packages just can't build due to .makedepends no finding the packages
2023-08-15 12:40:01 <eletrotupi> running abuild -r
2023-08-15 12:40:24 <eletrotupi> for instance, bupstash errors out with satisfies: "world[.makedepends-bupstash=20230815.123855]"
2023-08-15 12:52:44 <eletrotupi> ah, figure it out
2023-08-15 18:34:43 <zcrayfish> I just added it to the wiki instructions, but it might be worthwhile for someone to add it as a depends... sddm --test-mode by default only works if xorg-server-xephyr is installed. I didn't try sddm's wayland feature. 
2023-08-15 18:34:50 <zcrayfish> s/depends/depend
2023-08-15 19:14:37 <ikke> qt5-qtwebengine fails on 32-bits arch due to address-space exhaustion (failed to set dynamic section sizes: memory exhausted)
2023-08-16 02:58:32 <linearcannon> i have an MR that i need someone to take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50114
2023-08-16 02:58:39 <linearcannon> fixes bootstrapping, which is currently broken
2023-08-16 07:57:03 <PabloCorreaGomez[m]> Any suggestion on what to do, when an MR fails a test only on s390x? Just disabling the check seems reckless, but we cannot usually troubleshoot. Asking for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50105
2023-08-16 08:08:09 <quinq> PabloCorreaGomez[m], you should report the bug upstream
2023-08-16 08:09:18 <PabloCorreaGomez[m]> quinq: upstream has very little, if no s390x users, and no dev support for what I understand. They certainly don't care unless you come with a patch
2023-08-16 08:09:47 <quinq> Quality software
2023-08-16 08:09:58 <quinq> In any case, if you don't report it, they will never know about it
2023-08-16 08:10:06 <quinq> But it's not an s390x bug
2023-08-16 08:10:12 <quinq> It's an xdg-portal bug
2023-08-16 08:10:26 <quinq> An assert should *never* be triggered in production
2023-08-16 08:10:35 <quinq> (it shouldn't even be built on releases, but heh)
2023-08-16 08:11:02 <quinq> They should be happy that somebody found a bug in their software, making it more robust
2023-08-16 08:11:18 <quinq> And they might
2023-08-16 08:11:48 <PabloCorreaGomez[m]> Sure, but if it only happens in s390x, and no developers have access to s390x hardware (including myself), then you can open a bug, but nobody will ever fix it. It only adds to the noise
2023-08-16 08:12:06 <quinq> No, they can look at the code and see why it would fail
2023-08-16 08:57:28 <ncopa> and they know the code and may have an idea why if fails on a big-endian platform
2023-08-16 08:57:40 <ncopa> reporting upstream is a good idea
2023-08-16 09:09:14 <PabloCorreaGomez[m]> Ok, I'll politely try. Until they reply, might we disable the test and go on?
2023-08-16 09:16:39 <ncopa> i'd rather disable the package for s390x
2023-08-16 09:17:56 <PabloCorreaGomez[m]> Makes sense. Let's see if upstream is in favor or against it. I'll take care of the issue in the evening
2023-08-16 09:18:31 <ncopa> i tried to reproduce it in an lxc container i have on s390x. was not able to repro
2023-08-16 09:29:53 <PureTryOut> $source can't just point to any location on the file system right? I guess the tarball either needs to be an online source or placed relatively to the APKBUILD?
2023-08-16 09:31:14 <PureTryOut> Pablo Correa Gomez: btw that package seems a good candidate to be maintained by the desktop team right?
2023-08-16 09:32:51 <PabloCorreaGomez[m]> PureTryOut (matrix.org): yes :)
2023-08-16 09:33:18 <PabloCorreaGomez[m]> Though not sure if we should do it until the qa-bot is updated
2023-08-16 09:36:35 <PureTryOut> https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/commit/0512095ae33dee0f8ee43168c7fbd097d6538fdf has been merged already, the bot just needs to be restarted I think?
2023-08-16 10:01:48 <PabloCorreaGomez[m]> What we discussed with ikke, is that the bot needs to be re-deployed because it's a code change. https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/42 will make it possible to work just being re-started
2023-08-16 10:34:42 <ncopa> anyone who uses emacs interested in taking over maintainership of community/emacs?
2023-08-16 10:35:18 <ncopa> im willing to trade maintainership of emacs with neovim ;)
2023-08-16 10:35:38 <ikke> I use it, but I don't feel adequate enough to maintain it
2023-08-16 10:56:53 <pj> I'm already a developer of one code editor so no thank you :P
2023-08-16 14:16:49 <quinq> Hello
2023-08-16 14:17:28 <quinq> Shouldn't a busybox update trigger an initrd regeneration?
2023-08-16 14:18:23 <quinq> Though not doing it doesn't prevent from booting the system
2023-08-16 14:41:07 <minimal> quinq: mkinitfs only triggers on changes in /usr/share/kernel
2023-08-16 14:41:50 <minimal> in theory it should trigger on the changing of *any* binary that the initramfs contains....but that would be hard to implement
2023-08-16 14:45:09 <eletrotupi> ncopa: regarding the bupstash pkg, I'm trying to reproduce the error with rust edge and it's indeed failing due to a 'undefined reference to `readdir64_r`'
2023-08-16 14:45:33 <eletrotupi> this is a fresh vm though, so might be missing some libs?
2023-08-16 15:09:34 <ikke> eletrotupi: you need to upgrade the libc crate to the latest version
2023-08-16 15:22:11 <eletrotupi> oh
2023-08-16 15:40:00 <ikke> eletrotupi: `cargo upgrade -p libc` and create a patch with the cargo.lock differences
2023-08-16 15:45:22 <eletrotupi> uhum, thanks ikke, will push as soon as I get back from lunch
2023-08-16 15:45:38 <ikke> eletrotupi: np
2023-08-16 15:46:04 <eletrotupi> also found a small test suite bug with the version on master, so I'll maybe send a upstream fix as well :D
2023-08-16 15:57:43 <Arnavion> (`cargo update`, not `upgrade`)
2023-08-16 15:58:19 <ikke> thanks, was recalling it from memory
2023-08-16 16:08:51 <ncopa> ikke: added CI for our secfixes tracker: https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker/-/merge_requests/16
2023-08-16 16:09:05 <ncopa> got some help from chatgpt to write the tests :)
2023-08-16 16:27:47 <fluix> is there no worry about the license on those?
2023-08-17 08:50:27 <zcrayfish> ncopa: SSE2 still required after https://git.alpinelinux.org/aports/commit/?id=11d53c979ef3  right?
2023-08-17 08:56:13 <ncopa> yes, i think so. should be CONFIG_M586TSC=y
2023-08-17 08:57:15 <zcrayfish> cool; just wanted to keep the wiki reasonable for the minimum system requirements.
2023-08-17 11:47:37 <ncopa> I'm trying to build a package of flask-accept https://github.com/di/flask-accept
2023-08-17 11:48:19 <ncopa> i have no clue how this gpep517 thingy works
2023-08-17 11:49:36 <ncopa> and i dont know if it works with an old module like that or if i should use the old style python3 setup.py builld
2023-08-17 11:56:33 <elibrokeit> they should work identically 
2023-08-17 12:00:49 <elibrokeit> ncopa: the fallback pep517 backend is already "run setup.py build"
2023-08-17 12:00:59 <elibrokeit> it's the same thing pip does 
2023-08-17 12:53:01 <indy> hi all
2023-08-17 12:53:16 <indy> ncopa, are you maintaining sysstat?
2023-08-17 12:57:37 <indy> ncopa, https://www.cve.org/CVERecord?id=CVE-2023-33204
2023-08-17 14:16:19 <ncopa> elibrokeit: i think i figured it out. thanks! i had wrong builddir so things got messy
2023-08-17 14:18:01 <ncopa> bah, i messed up more things
2023-08-17 14:18:03 <ncopa> 02602aefd2ad3ac26402d1b66051c1d2bfcee174
2023-08-17 14:19:27 <ncopa> indy: i maintain alot...
2023-08-17 14:29:36 <ncopa> indy: does not seem that we have CVE-2022-39377 fixed either? not sure
2023-08-17 14:29:54 <ncopa> and the stable branch does not seem to be pushed to github?
2023-08-17 14:53:42 <ikke> Anyone knows how we can handle qt5-qtwebengine failing on 32-bits arches (failed to set dynamic section sizes: memory exhausted
2023-08-17 14:53:44 <ikke> )
2023-08-17 14:53:58 <ikke> This is most likely address-space exhaustion, not a lack of memory on the server
2023-08-17 14:54:11 <ikke> It happens in the linking step
2023-08-17 14:54:16 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/qt5-qtwebengine/qt5-qtwebengine-5.15.14-r7.log
2023-08-17 16:48:36 <Hello71> disable debug symbols?
2023-08-17 16:49:18 <Hello71> I think the official firefox/chrome builds moved to cross compilation ages ago
2023-08-17 16:49:43 <Hello71> or maybe lld can use less memory
2023-08-17 17:08:54 <quinq> They moved to docker build “It works for us on our build machine”
2023-08-17 17:18:29 <fluix> does community being supported until the next stable release mean that security fixes should still be backported to 3.18 right now? specifically asking about https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49441
2023-08-17 17:28:11 <ikke> fluix: yes
2023-08-17 17:28:23 <ikke> Hello71: I tried to build without debug symbols, but that did not help
2023-08-17 17:31:20 <ikke> anjan: willow wants to take over maintainership over for sxml-utils, are you okay with that? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49892 
2023-08-17 17:31:23 <elibrokeit> do you build on 32-bit bare metal?
2023-08-17 17:31:44 <ikke> elibrokeit: x86_64 in 32-bits mode
2023-08-17 17:32:32 <elibrokeit> so a 64bit kernel running 32-bit binaries with chroot?
2023-08-17 17:32:45 <ikke> yes (in lxc)
2023-08-17 17:49:18 <ikke> Hmm, I noticed that the package sets `CONFIG+=force_debug_info`, which I didn't remove when testing, so testing another time without debug symobls
2023-08-17 17:49:20 <ikke> symbols
2023-08-17 18:21:58 <dalias> O_o
2023-08-17 18:23:04 <ikke> dalias: what's that a reaction to?
2023-08-17 18:34:36 <dalias> the forced debug info :-p
2023-08-17 18:35:16 <quinq> Especially on a software that the least likely to be debugable by users
2023-08-17 18:35:28 <dalias> seems like an odd choice for a package that's, for practical purposes, not debuggable, and which is notorious for using so much ram/temp space during build for debug info that it's not practical to build from source :-p
2023-08-17 18:35:40 <quinq> yep
2023-08-17 19:08:16 <ikke> yeah, removing that option makes it build
2023-08-17 19:25:54 <dalias> :)
2023-08-17 19:56:34 <skarnet> <surprised pikachu face>
2023-08-17 19:59:33 <quinq> 
ACTION drops pokeball on skarnet 

2023-08-17 20:21:44 <zcrayfish> omg pokémans
2023-08-17 20:24:18 <dalias> ^_^
2023-08-17 20:29:08 <dalias> ok namespace reserves f_* so that checks out
2023-08-17 20:45:53 <fluix> am I doing something wrong or does gitlab have very short auth sessions? I get logged out quite frequently even though I check off remember me during login
2023-08-17 20:51:44 <dalias> it has a hard limit of like a week or something dumb
2023-08-17 20:51:47 <dalias> utterly hate that
2023-08-17 20:52:11 <dalias> it trains users to get phished (re-enter credentials all the time rather than treating a request for credentials as ultra-sus)
2023-08-17 20:52:57 <dalias> and it's designed around a false premise that a gitlab account is a highly sensitive thing where compromise of your account would expose others to danger
2023-08-17 20:53:10 <dalias> which kinda makes sense if you have a dev account
2023-08-17 20:53:24 <dalias> (with push access to sensitive  repos)
2023-08-17 20:53:57 <dalias> but the normal case is that you are a bug reporter and you need to reply to issues you reported or commented on with 5-30 day intervals between actions
2023-08-17 20:54:15 <dalias> and being logged out every time you go back to reply to something is so incredibly annoying it makes folks not want to participate
2023-08-17 20:55:35 <fluix> yeah definitely not a supporter of this security model. thanks for the info though :)
2023-08-17 21:00:16 <pj> I have not been logged out for months so idk
2023-08-17 21:00:32 <pj> You have weird pc
2023-08-17 21:01:14 <dalias> if you use it regularly you don't get logged out
2023-08-17 21:01:22 <dalias> it's when you go more than N days without use
2023-08-17 21:01:40 <dalias> because it does something like issuing a new session key if the old one is going to expire
2023-08-17 21:01:57 <pj> I have definitely not used it for N days
2023-08-17 21:02:01 <dalias> instead of just ... not expiring them
2023-08-17 21:02:53 <ptrc> hm, it varies between users
2023-08-17 21:03:11 <ptrc> or maybe devices?
2023-08-17 21:03:36 <ptrc> psykose had this issue both on her desktop and phone, but for me it only happens on my phone
2023-08-17 21:03:42 <ptrc> and the sessions are still there in settings
2023-08-17 21:11:52 <fluix> oh you know what, it probably has to do with my IP changing regularly
2023-08-17 21:15:45 <quinq> dalias, regarding push access, you push with ssh credentials anyway, no?
2023-08-17 21:15:51 <quinq> Not with web auth
2023-08-17 21:16:44 <fluix> the issue is essentially having to use the web interface for MRs
2023-08-17 21:17:01 <fluix> the CLI does _somewhat_ solve this, but it's not great
2023-08-17 21:17:24 <quinq> ok
2023-08-17 21:17:44 <quinq> * rt
2023-08-17 21:17:57 <fluix> rt?
2023-08-17 21:20:11 <quinq> Sorry, right hand was shifted to the left and typed "* rt" instead of "/21" (with an added space for some reason)
2023-08-17 21:52:57 <skarnet> that's the most convoluted and implausible explanation I've ever heard
2023-08-17 21:53:34 <skarnet> "21" would be shifted to "tr", if anything, not "rt"
2023-08-17 21:55:22 <Hello71> haven't you heard of qwetry keyboard layout
2023-08-17 21:55:56 <Hello71> sorry, azetry
2023-08-17 21:56:02 <quinq> maybe that's not a qwerty layout -_-
2023-08-17 21:56:17 <quinq> or azerty
2023-08-17 21:56:41 <quinq> widen your mind horizon a bit :)
2023-08-17 21:57:01 <dalias> :)
2023-08-17 23:28:53 <skarnet> yeah, yeah, keep pretending
2023-08-17 23:29:22 <skarnet> my explanation can only be understood by people who know the dvorak layout
2023-08-17 23:29:29 <skarnet> very cool
2023-08-18 04:53:32 <anjan> ikke: im ok with that
2023-08-18 04:54:12 <anjan> ikke: willow can take over maintainership
2023-08-18 04:55:30 <ikke> anjan: great, thanks
2023-08-18 06:23:37 <indy> ncopa, i know you maintain a lot :) even master branch contains downgrade from 12.7.1 to 12.6.2
2023-08-18 11:24:43 <ncopa> I wonder how we can detect and remove the waiting-maintainer-feedback label? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50111
2023-08-18 11:52:54 <ikke> Check if the maintainer approved the MR
2023-08-18 11:53:47 <ikke> Note that I do regularly check MRs with that label to see if they have received feedback 
2023-08-18 12:55:50 <ncopa> yeah. I wonder if that could be automated some how
2023-08-18 13:28:58 <pj> Listen for approval event?
2023-08-18 13:32:33 <ikke> ncopa: can be added to aports-qa-bit
2023-08-18 13:32:36 <ikke> bot
2023-08-18 13:43:45 <PabloCorreaGomez[m]> ncopa: the question there, is what is maintainer feedback. That they just actually say something?
2023-08-18 13:44:26 <PabloCorreaGomez[m]> There was a similar attempt before with the bot: https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/blob/master/Services/CommentOnApproval, but that never worked because you need some certain level of privileges in gitlab to be able to click the "Approve" button
2023-08-18 13:45:01 <ikke> PabloCorreaGomez[m]: we have been adding maintainers  as guests 
2023-08-18 13:45:07 <ikke> They can approve 
2023-08-18 13:45:23 <PabloCorreaGomez[m]> Oh well, then that's convenient
2023-08-18 13:46:23 <PabloCorreaGomez[m]> Then the question, should that "CommentOnApproval" be extended to also remove the label if it exists?
2023-08-18 13:46:43 <PabloCorreaGomez[m]> Or you want a new service that removes the label as soon as the maintainer wrote a comment?
2023-08-18 13:47:18 <PabloCorreaGomez[m]> I'm fine implementing it if nobody else wants, should be pretty straight-forward, I believe
2023-08-18 13:47:36 <ikke> Either when they added a comment or when they approved it
2023-08-18 13:48:32 <PabloCorreaGomez[m]> So both, jajaja. Makes sense :) I'll put it on my list for next week!
2023-08-18 13:49:26 <PabloCorreaGomez[m]> Is there any way to get access to the qa-bot logs? Would be quite interesting for troubleshooting
2023-08-18 13:52:40 <ikke> PabloCorreaGomez[m]: I've been setting up Loki to collect logs 
2023-08-18 13:52:56 <ikke> Should be possible through that
2023-08-18 13:53:25 <PabloCorreaGomez[m]> Lovely :D
2023-08-18 14:34:12 <Elysia[m]> Hi I want to build an alpine application on docker. How ever I am unsure which image to use. Is there an example script on how alpine builds its applications using an docker container?
2023-08-18 14:59:42 <quinq> Those seems to be two different concerns, 1/ how to build an alpine package (abuild) 2/ how to run a docker image (refer to docker documentation)
2023-08-18 15:00:40 <quinq> https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers for 1/
2023-08-18 15:20:38 <Elysia[m]> From what I could see alpine uses gitlab ci in which it uses docker. But what I wasn't able to find is the ci config file. Where could I find it?
2023-08-18 15:30:55 <ikke> in the root of the aports directory
2023-08-18 15:32:46 <Elysia[m]> Oh. Thank you. Got lost in all the directories. Hehe.
2023-08-18 20:46:09 <EvTheFuture> I'm currently looking into if I can help out maintaining packages that currently lack a maintainer. I've started with the packages that the packages I'm currently maintaining depends on. When building py3-pyliblo locally on my build server it builds just fine and the tests only produce 4 warnings. However in MR !50241 I get one test failure. 
2023-08-18 20:46:55 <EvTheFuture> Does anyone have an idea why it fails in the container and not locally?
2023-08-18 20:47:36 <Elysia[m]> maybe a dependency is missing in the container?
2023-08-18 20:51:12 <Arnavion> The test expects binding to port 22 to fail, but that'll succeed if run as root
2023-08-18 20:51:30 <EvTheFuture> Ah, it's run as root in the container?
2023-08-18 20:51:45 <EvTheFuture> I've seen this but didn't think it was run as root...
2023-08-18 20:51:58 <EvTheFuture> AssertionError: ServerError not raised
2023-08-18 20:52:02 <Arnavion> Well, not as root, but possibly it has the cap for it anyway
2023-08-18 20:52:35 <EvTheFuture> Any idea on best way to work around it?
2023-08-18 20:55:05 <ptrc> exclude the test?
2023-08-18 20:55:50 <EvTheFuture> ptrc: yeah, just wanted to try to include it if possible
2023-08-18 21:05:55 <EvTheFuture> I ended up disabling that test. If anyone got any idea on how to prevent disabling the test I'm all ears.
2023-08-18 21:25:56 <ikke> there should be no capabilities in CI that should allow processes to listen to privileged ports
2023-08-18 21:32:13 <Arnavion> Is the container run with 22 mapped to host port > 1024 ?
2023-08-18 21:45:08 <Arnavion> Actually looks like docker sets net.ipv4.ip_unprivileged_port_start to 0 . Even regular   docker run -it --rm --user 1000 alpine nc -l -p 22   succeeds
2023-08-19 04:42:23 <lnl> not sure what's happening but, connections to sakamoto.pl seem to be broken specifically on the aarch64 gitlab runner
2023-08-19 04:48:08 <lnl> s/broken/flaky/
2023-08-19 04:48:20 <lnl> https://gitlab.alpinelinux.org/selfisekai/aports/-/jobs/1088276/raw, https://gitlab.alpinelinux.org/selfisekai/aports/-/jobs/1088499/raw
2023-08-19 04:50:02 <zcrayfish> curl: (18) transfer closed with 118746993 bytes remaining to read <-- damn, and it was almost done too.
2023-08-19 09:58:31 <EvTheFuture> Does anyone have experience in packaging applications that require OpenGL::EGL?  I'm trying to get Hyprland to build on Alpine but get a configuration error. AFAIU mesa-dev should provide an implementation, or am I totally wrong here?  build log: https://tpaste.us/lgJa
2023-08-19 09:58:52 <EvTheFuture> AFAIK*
2023-08-19 10:43:21 <j_v> EvTheFuture: I am no expert on OpenGL::EGL packaging, but it might help to get verbose cmake output to see what it is barfing on...
2023-08-19 10:44:07 <j_v> ok, sorry, not cmake, but ninja
2023-08-19 10:44:17 <j_v> not as familiar with ninja
2023-08-19 10:45:21 <j_v> ok, i see, it is both, ninja must call out to cmake (and make files are just so complicated and that isn't?)
2023-08-19 11:30:52 <ikke> EvTheFuture: apparently hyprland existed briefly in testing, but was removed due to all the brokeness
2023-08-19 11:31:02 <ikke> f11b50a422c2003d522ce1ff34265e5a08ac990d
2023-08-19 11:34:45 <Newbyte> ikke: what brokenness?
2023-08-19 11:35:18 <ikke> Newbyte: don't know, the commit message doesn't mention any details
2023-08-19 11:37:52 <bl4ckb0ne> iirc they ship their own wlroots
2023-08-19 11:38:05 <ikke> yes, that's one of the problematic things that was mentioned
2023-08-19 11:38:54 <ikke> but the package did take care of that
2023-08-19 21:28:22 <EvTheFuture> ikke: I always like a challenge :)
2023-08-19 21:28:48 <bl4ckb0ne> good luck
2023-08-19 21:29:22 <EvTheFuture> We will see if I will spend time on it or not. Maybe when I need to clear my head from some other problem...
2023-08-19 21:30:28 <bl4ckb0ne> iirc they move fast, track upstream everywhere and dont do release
2023-08-19 21:30:40 <bl4ckb0ne> and the have a half melted pottery of a build system
2023-08-19 22:20:43 <pj> I'd say don't
2023-08-19 22:21:04 <pj> Patching it to use system wlroots will probably break it a lot
2023-08-19 23:47:36 <bl4ckb0ne> yep, api chsnges between wlroots releases
2023-08-20 12:30:00 <EvTheFuture> bl4ckb0: Yeah, better spend time on something else it seems.
2023-08-20 13:40:34 <DylanVanAssche> ncopa: BlueZ obexd has gained support for the PBAP Bluetooth profile a long time ago, I had a MR to get it in Alpine but required dependencies to move to `main` which was undesirable.
2023-08-20 13:40:36 <DylanVanAssche> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29955
2023-08-20 13:40:59 <DylanVanAssche> Would it be fine to separate obexd package from main and put it in community?
2023-08-20 13:44:59 <ikke> there are some other packages in main that depend on obex
2023-08-20 13:45:02 <ikke> openobex
2023-08-20 13:45:08 <ikke> obex-data-server
2023-08-20 13:49:03 <DylanVanAssche> ikke: They depend on bluez-dev, not bluez-obexd. The latter is the same as openobex, it implements the OBEX protocol stuff
2023-08-20 20:15:02 <elly> I wish that an IRC bot would message me when my aport is out of date
2023-08-20 20:15:08 <elly> perhaps I should just read my email more :)
2023-08-20 20:15:11 <Habbie> i get emails for that
2023-08-20 20:15:15 <Habbie> yeah :)
2023-08-20 21:02:31 <elly> what I really need is for my laptop to pull the mail down for me and tell me about it
2023-08-20 21:31:37 <skarnet> one of the reasons why imap > pop
2023-08-20 21:31:49 <skarnet> leave your mua open, and voilà, notifications :D
2023-08-20 21:41:49 <Ermine> imap has its own cringe moments
2023-08-20 21:49:48 <elly> yeah, maybe I should just leave mutt open
2023-08-21 00:18:06 <fluix> how does one use just plain LUKS (without LVM, encrypted boot, any other stuff) with grub? I modify /etc/default/grub with cryptoroot=UUID=... root=/dev/mapper/root rootfstype=ext4 and I get "error: no such edvice: <annother UUID>"
2023-08-21 00:18:34 <fluix> err, non-devel is probably a better place for this
2023-08-21 00:23:51 <minimal> fluix: if you're not using encrypted boot then it is nothing to do with Grub
2023-08-21 00:24:15 <minimal> moving to other channel...
2023-08-21 16:06:34 <Newbyte> Could someone look at !45863?
2023-08-21 16:06:54 <ikke> zsure
2023-08-21 16:10:44 <Newbyte> thanks :)
2023-08-21 20:49:08 <eddsalkield> anyone know why this build is failing?: https://gitlab.alpinelinux.org/eddsalkield/aports/-/jobs/1090601
2023-08-21 20:59:21 <fluix> didn't it pass fine? https://gitlab.alpinelinux.org/eddsalkield/aports/-/jobs/1090629
2023-08-21 22:36:21 <eddsalkield> durrendal: hm yeah interesting it passed the second time
2023-08-21 22:36:34 <eddsalkield> the first time around failed, although I changed nothing
2023-08-22 06:31:22 <staceee> hey there. I noted a regression with xdg-portal .OpenURI recently. My software now can't open URI like before. I only did upgrade, nothing changed in my setups. This reproduce on multiple machine.
2023-08-22 06:31:44 <staceee> I dig into this and can't find no portal that support OpenURI, not -gtk nor -gnome
2023-08-22 06:32:08 <staceee> and nothing changed recently on this regard
2023-08-22 06:32:25 <staceee> so, how was it working before? and, why this regressed recently?
2023-08-22 06:33:08 <staceee> I noted the regression with Newsflash "Open with browser" firstly
2023-08-22 06:34:19 <staceee> I also noted the MR to add testing/flatpak-xdg-utils but this seems to only allow sandboxes to talk to the service (that will still not exists)
2023-08-22 06:45:46 <staceee> btw I am a Sway user, got XDG_CURRENT_DESKTOP=sway, got x.d.p-wlr and x.d.p-gtk
2023-08-22 07:31:54 <staceee> I found my issue, and openned a ticker on xdg-desktop-portal : https://github.com/flatpak/xdg-desktop-portal/issues/1077
2023-08-22 07:32:08 <staceee> This affect all Sway users
2023-08-22 09:53:19 <zcrayfish> staceee: I am experiencing that issue as well.
2023-08-22 12:20:37 <staceee> zcrayfish: I openned up https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50395
2023-08-22 21:14:24 <ptrc> https://ptrc.gay/sAtjGPZF
2023-08-22 21:14:55 <ptrc> somehow can't have gitlab agree on the number of assigned merge requests, lol
2023-08-22 21:15:08 <ikke> eventual consistency
2023-08-22 21:38:18 <ptrc> hm, any idea why `apk add 'java-jre-headless>=11'` conflicts with.. itself?
2023-08-22 21:38:58 <ptrc> i can reproduce it in a clean container by just running the command
2023-08-22 21:40:40 <ptrc> ..ah, because it's not a versioned provide, so i cannot specify a version .~.
2023-08-22 21:42:18 <ikke> yeah, was about to mention that
2023-08-22 21:42:42 <ptrc> i think it was versioned before though?
2023-08-22 21:43:30 <ptrc> ah
2023-08-22 21:43:31 <ptrc> da7638e9b59998cf70e14d150b2a92f3d84a6d2c
2023-08-22 21:43:36 <ptrc> that's a shame
2023-08-22 23:33:59 <craftyguy> are .trigger files from a package in aports installed in the rootfs somewhere when the package is installed?
2023-08-22 23:42:03 <minimal> craftguy: references to them are stored in /lib/apk/db/triggers
2023-08-22 23:42:50 <craftyguy> ah, is the actual trigger itself stored in the apk db then?
2023-08-22 23:43:04 <craftyguy> 
ACTION goes to grep around apk-tools

2023-08-22 23:43:05 <minimal> the actual triggers are storing inside /lib/apk/db/scripts.tar
2023-08-22 23:43:19 <craftyguy> I see, thanks
2023-08-22 23:43:43 <craftyguy> is there any mechanism for disabling execution a specific package's trigger?
2023-08-22 23:45:34 <craftyguy> the apk_package.h:apk_installed_package struct has a run_all_triggers thing, it's set to 1 but doesn't seem to be exposed in any way for being configured at runtime 
2023-08-22 23:46:09 <craftyguy> 
ACTION trying to see about how to fix this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12484

2023-08-22 23:47:24 <minimal> craftyguy: don't think so - look at secureboot-hook and mkinitfs for a "workaround" to stop the mkinitfs trigger from running
2023-08-22 23:49:59 <craftyguy> ahh ok, I'll take a look. thanks for the hint
2023-08-22 23:50:21 <minimal> craftguy: one reason for having the grub trigger is to regenerate grub.cfg when the template files for it change (i.e. on an upgrade of the grub package)
2023-08-22 23:50:43 <minimal> if you manage to disable the trigger then you won't benefit from any template changes/fixes
2023-08-22 23:50:45 <craftyguy> yeah it totally makes sense why that trigger is necessary for like, pretty much everyone else
2023-08-22 23:51:41 <craftyguy> in pmOS, we generate the grub conf files ourselves, and grub's trigger can stomp on those changes (plus, grub-mkconfig fails to run in some situations in pmOS, like when in a chroot building an OS image)
2023-08-22 23:51:55 <minimal> that becomes more important once I finish up a solution for the current lack of grub-install triggering upon Grub updates
2023-08-22 23:52:38 <minimal> grub-mkconfig runs fine when triggered inside a chroot - I use that all the time
2023-08-22 23:53:01 <craftyguy> anyways, grub-mkconfig failing isn't the point. for us, it's totally unnecessary
2023-08-23 00:00:59 <minimal> ok, I was just pointing out that grub-mkconfig can be successfully run inside a chroot, I use it that way when making disk images
2023-08-23 00:02:06 <craftyguy> yeah, I get some error from grub-probe, when it tries to find the device backing / (because it's not a full /dev in the chroot, and I think that's on purpose)
2023-08-23 00:02:29 <minimal> so if you manage to disable the grub trigger then how will you ensure that someone runs grub'mkconfig every time something in /boot changes?
2023-08-23 00:03:01 <craftyguy> a 'real' dev in the chroot would probably cause issues, since the chroot is used to build an OS image for some completely different target device than what the tooling/chroot run on
2023-08-23 00:03:38 <craftyguy> minimal: we have our own tool that triggers on that stuff. it's packaged in our repos, not aports
2023-08-23 00:04:36 <craftyguy> tbh, I really only need grub-mkimage. even having grub-mkconfig is a liability lol
2023-08-23 00:05:19 <minimal> Alpine's grub doesn't trigger grub-mkimage, that's the problem I mentioned earlier
2023-08-23 00:06:21 <craftyguy> yeah, I know. our thing does
2023-08-23 00:07:02 <minimal> I intend to add conditional calling of grub-mkimage upon grub package updates
2023-08-23 00:07:16 <craftyguy> our thing triggers grub-mkimage and generates a grub.cfg, and then grub triggers grub-mkconfig which stomps on our generated grub.cfg 
2023-08-23 00:08:03 <craftyguy> ideally, for us anyways, having grub-mkimage as a separate package would basically "fix" all of this. heh.
2023-08-23 00:08:13 <minimal> what's different about your grub.cfg contents? can't you just update the Grub packages templates so the trigger generates what you want?
2023-08-23 00:09:05 <craftyguy> yeah maybe we could spend time dealing with grub templates, but our config doesn't attempt to do any auto-detection stuff, etc. we already know where things are for each device we support. our config tends to be something like 5 lines long (give or take)
2023-08-23 00:10:30 <minimal> so modify /etc/grub.d/ files which are the templates used by grub-mkconfig to create grub.cfg
2023-08-23 00:11:32 <minimal> the idea of the trigger is that any time a kernel, or initramfs, or microcode file is add/changes/deleted in /boot then grub.cfg gets regenerated automatically
2023-08-23 00:11:53 <craftyguy> yeah that's one way. tbh I don't like dealing with grub templates. there's a ton of cruft in the generated config, and it's not very deterministic over time (templates change), so we might end up having to debug grub boot issues (which sucks, the grub console is bad)
2023-08-23 00:12:18 <craftyguy> 
ACTION knows what triggers are for, and understands their value when dealing with boot files :)

2023-08-23 00:13:17 <craftyguy> in many cases it's very difficult to get local console access to even begin to debug grub issues on boot, like if the generated cfg was bad
2023-08-23 00:13:54 <craftyguy> so, we basically opted for generating the bare minimum necessary ourselves. and it has worked well for years on many devices
2023-08-23 00:15:07 <minimal> the current situation of nothing triggering grub-mkimage means that why grub 2.11 is packaged for Alpine and people upgrade to it then grub.cfg will be rewritten but (a) the boot sector and other data in 1st 1MB of for MBR boot drive will not get updated (and so remain as Grub 2.06) and (b) for UEFI systems the grubx64.efi and bootx64.efi files will not get replaced again leaving them as Grub 2.06
2023-08-23 00:15:38 <minimal> so then there will be a fix of old Grub 2.06 stuff plus 2.11-based grub.cfg config files
2023-08-23 00:15:48 <minimal> which may create an unbootable system
2023-08-23 00:16:14 <craftyguy> I just need a way to disable the grub trigger. it can, and should(!) be enabled by default, for all the reasons you said
2023-08-23 00:16:49 <minimal> so look at the secureboot-hook/mkinitfs example I pointed you to
2023-08-23 00:17:12 <craftyguy> right, the question is if the grub maintainer would support adding that mechanism :D
2023-08-23 00:18:29 <craftyguy> and where to put such a var, since grub doesn't really have a config file in the style that mkinitfs does (grub config is specific to the upstream grub app, so injecting out-of-tree variables seems like a bad idea)
2023-08-23 00:37:09 <minimal> craftyguy: for what I was working on (re grub-mkimage) I was going to add code to the grub trigger to look for a specifically named file (and then probably source it)
2023-08-23 00:38:05 <craftyguy> minimal: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50427
2023-08-23 00:38:45 <craftyguy> might be interesting, if you wanted to have a config file. I just proposed one based on mkinitfs.conf, but I really don't care where it is or what it's called :P
2023-08-23 01:02:51 <minimal> craftyguy: my reason for a "config" file was for it to store the original grub-mkimage options as if/when grub-mkimage is run again it needs to use the same options
2023-08-23 01:04:18 <minimal> also BTW /etc/grub does not currently exist as a directory
2023-08-23 01:19:06 <craftyguy> yeah it would be made by the user or whatever external thing wants to configure it, for now
2023-08-23 01:20:07 <craftyguy> minimal: i could create it in that patch, if that's preferred, or you could do it when you actually depend on it for the mkimage stuff
2023-08-23 01:20:33 <minimal> craftguy: so for pmOS whenever you run grub-mkimage you'll give it the correct options as previously used?
2023-08-23 04:16:26 <elly> it's pretty ambitious that abump tries to build all of chromium on my laptop for me
2023-08-23 14:09:50 <omni> this doesn't look right https://pkgs.alpinelinux.org/contents?branch=edge&name=ansible-core-doc&arch=x86_64&repo=community
2023-08-23 14:18:14 <ikke> Doesn't seem to have been the last upgrade 
2023-08-23 14:18:33 <ikke> Oh, sorry, it is 
2023-08-23 14:19:34 <ikke> https://tpaste.us/KEan 
2023-08-23 14:19:48 <celie> install is missing a -t?
2023-08-23 14:23:46 <celie> Perhaps related to the fourth point under https://github.com/ansible/ansible/blob/v2.15.3/changelogs/CHANGELOG-v2.15.rst#minor-changes ?
2023-08-23 14:25:28 <celie> fourth and fifth*
2023-08-23 14:27:15 <minimal> a fix has already been merged...
2023-08-23 14:28:26 <ikke> http://dup.pw/alpine/aports/a343d4e095dc
2023-08-23 14:28:39 <celie> Ah, a343d4e0 fixes the missing -t thing, but there's still manpage generation..
2023-08-23 14:28:43 <ikke> It was a missing -t
2023-08-23 14:29:26 <ikke> Although, the man pages need to be generated as well
2023-08-24 00:12:42 <celie> omni: Hi
2023-08-24 00:28:33 <omni> hi
2023-08-24 00:33:46 <celie> omni: Just wondering what you think about !50366
2023-08-24 00:40:51 <omni> celie: I don't mind if you'd like to maintain it
2023-08-24 00:41:49 <omni> the CI pipeline succeeded https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1092482 but then it failed here anyway https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/tor/tor-0.4.8.4-r0.log
2023-08-24 01:18:20 <celie> omni: Thanks :)
2023-08-24 01:18:46 <celie> I wonder if that error has something to do with tmp files not being cleaned up again
2023-08-24 01:25:26 <omni> is it possible to do something about without bumping pkgrel?
2023-08-24 01:25:38 <omni> gotta go
2023-08-24 01:25:43 <omni> bbl
2023-08-24 01:27:00 <celie> See you next time
2023-08-24 01:31:28 <celie> Regarding the tmp files thing, i think the last time that happened, they were cleared manually, but not even sure this is the problem now..
2023-08-24 07:02:55 <ncopa> Hi. the mouse left click stopped working today for some reason in xorg
2023-08-24 07:03:19 <ncopa> i thought it was the mouse that broke but same thing happens with other mouse i have, so i believe its software issue
2023-08-24 07:08:34 <zcrayfish> bummer
2023-08-24 07:14:58 <ncopa> ok that was weird
2023-08-24 07:15:30 <ncopa> when I reboot, in the lightdm login screen, mouse(s) did work
2023-08-24 07:15:45 <ncopa> mouse leftclick that is
2023-08-24 07:15:49 <ncopa> once
2023-08-24 07:15:56 <ncopa> then it sopped working
2023-08-24 07:16:15 <ncopa> second reboot i used the other mouse
2023-08-24 07:16:21 <ncopa> and not it all works
2023-08-24 07:16:31 <ncopa> s/not/now/
2023-08-24 07:16:35 <ncopa> now it all works
2023-08-24 07:17:21 <ncopa> i wonder if it is related the bluetooth keyboard, which gets connected around the same time
2023-08-24 07:18:40 <ncopa> [   21.014843] apple 0005:004C:0267.0008: input,hidraw3: BLUETOOTH HID v0.67 Keyboard [Magic Keyboard] on 58:96:1d:xx:xx:xx
2023-08-24 07:18:40 <ncopa> [   43.192502] logitech-hidpp-device 0003:046D:4060.0007: HID++ 4.5 device connected.
2023-08-24 07:20:18 <zcrayfish> dunno, I had a funky bluetooth issue earlier myself
2023-08-24 07:20:46 <zcrayfish> when my logitech M590 connected to my system after many hours of uptime (I got tired of using the touchpad), it hard froze. jeeeeeze.
2023-08-24 09:50:07 <omni> if I disable this tor test also for x86_64 (fails on package builder but not on CI builder) but don't bump pkgrel, will it build on the x86_64 builder where it's not yet at this version?
2023-08-24 10:01:10 <omni> I'll just try
2023-08-24 10:15:56 <ikke> omni: it would
2023-08-24 10:16:04 <ikke> omni: fyi, I was debugging it on the builder
2023-08-24 10:16:10 <ikke> omni: I also removed /tmp/*, but that doesn't help
2023-08-24 10:17:30 <omni> thanks
2023-08-24 10:17:39 <omni> I noticed that it got built for 3.18
2023-08-24 10:20:16 <ikke> omni: this is the output of `ls /tmp/tor_test_48543_lnll3cul/test_glob/*/*`, the pattern that the test is executing: https://tpaste.us/j4J5
2023-08-24 10:20:38 <ikke> it uses a random dir in tmp, so it should be clean every run
2023-08-24 10:23:14 <omni> yeah, so what is going on then?
2023-08-24 10:23:41 <ikke> What I see is that results = tor_glob(pattern); returns a list with 0 results
2023-08-24 10:23:52 <ikke> p smartlist_len(results) -> 0
2023-08-24 10:24:10 <ikke> but it checks it with !results, so it expects null to be returned I assume
2023-08-24 10:37:35 <ikke> omni: https://tpaste.us/D7aa 
2023-08-24 10:37:46 <ikke> ret is GLOB_NOMATCH
2023-08-24 10:39:55 <ikke> testing in docker now to see if I can see a difference
2023-08-24 11:10:49 <quinq> hola
2023-08-24 11:11:06 <quinq> I installed openjdk17-jre and openjfx
2023-08-24 11:11:42 <quinq> When I run Java, I get the following error messages: http://ix.io/4Eoe
2023-08-24 11:12:00 <quinq> Am I missing some module, or something else?
2023-08-24 11:12:25 <ikke> what command do you execute?
2023-08-24 11:12:31 <quinq> java
2023-08-24 11:13:00 <quinq> (that's on edge/musl/amd64)
2023-08-24 11:13:39 <quinq> oh
2023-08-24 11:13:52 <quinq> --module-path /usr/lib/jvm/openjfx11/li
2023-08-24 11:13:53 <quinq> b
2023-08-24 11:14:05 <quinq> The actual path is /usr/lib/jvm/openjfx/lib
2023-08-24 11:14:16 <ikke> just running `java` works for me
2023-08-24 11:14:35 <quinq> Have you reloaded your env? (with the profile.d provided one)
2023-08-24 11:14:54 <ikke> no
2023-08-24 11:15:39 <ikke> if I do that, I do see the 'picked up' messages, but no error
2023-08-24 11:15:59 <quinq> Well
2023-08-24 11:16:07 <quinq> I apologize
2023-08-24 11:16:22 <quinq> That was coming from my own env -_- (previous other OS installation)
2023-08-24 11:16:35 <quinq> Thanks for the teddy-bear support, ikke :)
2023-08-24 11:16:36 <ikke> glad you found it :)
2023-08-24 11:18:04 <ikke> omni: in docker, it returns GLOB_ABORTED, not GLOB_NOMATCH
2023-08-24 11:53:41 <omni> ikke: thanks for looking into it
2023-08-24 11:53:56 <ikke> still trying to figure out where the difference comes from
2023-08-24 11:58:54 <ncopa> what is underlying filesystem? ext4?
2023-08-24 12:00:04 <ikke> tmpfs
2023-08-24 12:00:11 <ikke> in docker it's overlay
2023-08-24 12:01:24 <ikke> they do expect GLOB_ABORTED, given that they check if the result is null (0)
2023-08-24 12:20:05 <ikke> In the non-failing case, it does these extra syscalls: https://tpaste.us/NBak 
2023-08-24 12:21:18 <ikke> The syscall just before it writes about the test failure is:
2023-08-24 12:22:33 <ikke> open("/tmp/tor_test/test_glob/forbidden/", O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission denied) 
2023-08-24 12:22:43 <ikke> which is the same in both cases
2023-08-24 12:40:40 <ncopa> so it sounds like in the failing test, it is actually able to open and read the forbidden directory, when it should not
2023-08-24 12:41:55 <ikke> non-failing case: https://tpaste.us/yYnl
2023-08-24 12:42:13 <ikke> failing case: https://tpaste.us/YY9z
2023-08-24 12:42:26 <ikke> (I've normalized the strace to make it easier to compare)
2023-08-24 12:42:54 <ikke> directory structure: https://tpaste.us/xy6J
2023-08-24 12:46:43 <ncopa> what filesystem is it on the failing case?
2023-08-24 12:47:01 <ikke> tmpfs
2023-08-24 12:47:08 <ncopa> and in the non-failing?
2023-08-24 12:47:11 <ncopa> ext4?
2023-08-24 12:47:13 <ikke> overlayfs
2023-08-24 12:47:23 <ncopa> and under overlayfs?
2023-08-24 12:47:28 <ikke> ext4
2023-08-24 12:48:06 <ncopa> $ diff -u non-failing failing  | tpaste
2023-08-24 12:48:06 <ncopa> https://tpaste.us/5XD0
2023-08-24 12:48:21 <ncopa> notice the difference in st_size
2023-08-24 12:48:26 <ncopa> on ext its a 4k block
2023-08-24 12:48:30 <ncopa> on tmpfs its only 180 bytes
2023-08-24 12:48:43 <ikke> yes, I did notice that
2023-08-24 12:48:54 <ncopa> but I dont think that matters
2023-08-24 12:49:37 <ikke> I'm watching the diff in vimdiff, which makes it a bit more clear
2023-08-24 12:51:24 <ncopa> seems like the order is different
2023-08-24 12:51:26 <ikke> yes
2023-08-24 12:52:10 <ikke> fyi, I did reorder earlier stat calls to match them up, but they were in a different order
2023-08-24 12:53:57 <ikke> but it appears to me that in both cases, it tries to open("/tmp/tor_test/test_glob/forbidden/"
2023-08-24 12:54:05 <ikke> and it gives permission denied
2023-08-24 12:54:31 <ikke> the failing cases immediately writes  FAIL src/test/test_util.c:4647
2023-08-24 12:54:44 <ikke> some clean up happens
2023-08-24 12:54:50 <ikke> and then the final mesage of that test is shown
2023-08-24 13:02:18 <ncopa> do you have the build tree there also? can you see if HAVE_GLOB is set or not by configure script?
2023-08-24 13:02:55 <ncopa> checking for glob... yes
2023-08-24 13:03:42 <ncopa> i suspect there some code somewhere that expect a libc call (re)set errno, which does not
2023-08-24 13:04:31 <ikke> where it there?
2023-08-24 13:05:55 <ncopa> src/lib/fs/path.c
2023-08-24 13:10:08 <ikke> ./config.status:D["HAVE_GLOB"]=" 1"
2023-08-24 13:10:10 <ikke> ./config.status:D["HAVE_GLOB_H"]=" 1"
2023-08-24 13:10:20 <ncopa> yeah
2023-08-24 13:10:49 <ncopa> do you know if GLOB_ALTDIRFUNC is set?
2023-08-24 13:11:46 <ikke> grep -r GLOB_ALTDIRFUNC . returns nothing
2023-08-24 13:15:01 <ncopa> I believe this is related https://gitlab.torproject.org/tpo/core/tor/-/commit/36768b5756f05774258ca9c5db6379f74dfd6586
2023-08-24 13:17:08 <ikke> I've seen the custom error function during debugging, but the result is the same in both cases
2023-08-24 13:24:34 <ncopa> i think we should report this upstream
2023-08-24 13:24:44 <ncopa> i have not been able to reproduce it locally
2023-08-24 13:24:52 <ikke> yeah, fine with me
2023-08-24 13:24:57 <ikke> omni: do you want to report it?
2023-08-24 13:25:11 <ncopa> it expects GLOB_ABORTED, right?
2023-08-24 13:25:16 <ikke> yes
2023-08-24 13:38:11 <ncopa> i wonder if it is a bug in kernel
2023-08-24 13:45:50 <ncopa> ikke do you have an env where you can reproduce it?
2023-08-24 13:45:57 <ncopa> seems like the tests passed now
2023-08-24 13:46:32 <ikke> ncopa: because omni disabled that test
2023-08-24 13:46:54 <ncopa> so we have no reproducer anywhere?
2023-08-24 13:47:07 <ikke> We can reproduce it on the builder if you enable the test again
2023-08-24 13:47:45 <ncopa> im stopping mqtt-exec meanwhile
2023-08-24 13:48:50 <ikke> yeah, I had it stopped before, but I started it again to let the builder catch up
2023-08-24 13:49:56 <ncopa> it passes now
2023-08-24 13:50:01 <ikke> even with the test enabled?
2023-08-24 13:50:19 <ncopa> build-edge-x86_64 [~/aports/community/tor]$ abuild deps clean unpack prepare build check
2023-08-24 13:50:27 <ncopa> 1497 tests ok.  (27 skipped)
2023-08-24 13:50:28 <ikke> you need to modify the APKBUILD
2023-08-24 13:50:40 <ikke> there are some patches conditonally applied
2023-08-24 13:53:56 <ikke> ncopa: should I modify it?
2023-08-24 13:54:16 <ikke> Just remove the '*'
2023-08-24 14:28:15 <ptrc> clandmeter: can you take a look at !50219?
2023-08-24 14:35:45 <ikke> it's unfortunate that s390x is dropped
2023-08-24 14:45:07 <ncopa> i had lunch so i restarted build-edge-x86_64
2023-08-24 14:45:28 <ikke> I stopped the builder again
2023-08-24 14:45:39 <minimal> ncopa: any further thoughts on the Hashicorp license situation?
2023-08-24 14:45:58 <ncopa> minimal: i thought of asking hashicorp
2023-08-24 14:46:36 <minimal> to clarify some aspect?
2023-08-24 14:46:55 <ncopa> im not sure we are allowed to ship their software anymore, as we cannot guarantee that we dont also provide competing software
2023-08-24 14:47:13 <ncopa> i was thinking of asking what they wanted us to do
2023-08-24 14:47:19 <minimal> ok
2023-08-24 14:47:22 <ikke> We have removed other software because of the license, even if we technically were allowed to distribute it
2023-08-24 14:47:44 <ncopa> *shrug*
2023-08-24 14:47:52 <minimal> I've seen a couple of terraform forks but haven't noticed any forks of there other software so far
2023-08-24 14:48:56 <ncopa> so, we may or may note be allowed to redist terraform, but I was thinking of asking what hashicorp wanted us to do
2023-08-24 14:49:10 <ncopa> we may be allowed to redist, but they might not want us to
2023-08-24 14:50:16 <ncopa> i know we have removed software due to license, but I'd prefer not do that for political reasons
2023-08-24 14:50:56 <ikke> Well, it's mostly about the uncertainty that the license brings
2023-08-24 14:50:57 <ncopa> i mean, i dont want use alpine to push political agendas
2023-08-24 14:51:18 <ncopa> hence i'd like to ask hashicorp
2023-08-24 14:51:35 <minimal> yeah the license has built-in uncertainty
2023-08-24 14:52:02 <ikke> basically: we can revoke the license at our discretion. 
2023-08-24 14:52:22 <ikke> Which can mean we would have to retroactively remove the package from our repos
2023-08-24 14:53:13 <ncopa> thats unfortunate
2023-08-24 14:53:19 <ncopa> All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp commercial products, hosted or self-managed.
2023-08-24 14:54:05 <ncopa> "embedding software in an offering" like include the software on an iso image?
2023-08-24 14:54:33 <minimal> I'll add a note to the Nomad APKBUILD for now about "holding" any upgrades
2023-08-24 14:54:51 <ikke> yeah, that would be good
2023-08-24 14:54:54 <ikke> same for tf and vault
2023-08-24 14:55:02 <ncopa> i suppose its problematic that they can revoke permission to redist
2023-08-24 14:55:11 <ikke> yes, exactly
2023-08-24 14:56:18 <ncopa> i was thinking of asking them, because they may prefer that end users downloads the binaries directly from them instead of apk add things
2023-08-24 14:56:33 <ncopa> in that case its simple. we remove
2023-08-24 14:59:08 <ikke> Many projects would prefer that anyway
2023-08-24 15:00:42 <durrendal> Hashicorp has an FAQ up on their website, https://www.hashicorp.com/license-faq#what-is-considered-competitive, they define a competitive product as something sold for profit
2023-08-24 15:00:54 <durrendal> so if alpine isn't being sold, it isn't competitive?
2023-08-24 15:01:21 <ikke> durrendal: the question is if we can rely on a FAQ that can be rewritten at any moment
2023-08-24 15:01:27 <ikke> just like they ahve rewritten the CLA
2023-08-24 15:02:52 <durrendal> probably not. but getting further clarification on the point, in writing, seems like the right move
2023-08-24 15:15:33 <ncopa> ikke: I CC'ed you and clandmeter on the email to hashicorp
2023-08-24 15:15:39 <ikke> thanks
2023-08-24 15:16:27 <ncopa> what would it mean for alpine infra if we remove the packages?
2023-08-24 15:17:00 <durrendal> thanks for reaching out to them to get some clarity on all of this :)
2023-08-24 15:17:39 <ikke> ncopa: we use docker images, so should be fine
2023-08-24 15:18:53 <ikke> Only thing we are actively using is terraform
2023-08-24 15:20:23 <ikke> https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform/Base.gitlab-ci.yml#L12
2023-08-24 15:28:10 <ncopa> so we dont need to fight to keep those things
2023-08-24 15:28:38 <ncopa> i wonder what is most practical
2023-08-24 15:28:50 <ncopa> might be easiest to just remove them
2023-08-24 15:29:07 <ikke> Yes, that's my inclination
2023-08-24 15:29:29 <elly> since it is now nonfree software that also seems like the principled approach to take
2023-08-24 15:33:29 <minimal> as a side note minio was kept after it was relicensed to AGPL (at the time there were arguments as to whether it could be validly relicensed without consent of contributers)
2023-08-24 16:09:02 <rootwyrm> Basically HashiCorp's new "license" for everything is "trust me, bro"
2023-08-24 16:46:39 <ikke> ncopa: dalias says it a musl bug
2023-08-24 16:50:13 <ikke> omni: ^
2023-08-24 16:54:32 <dalias> proposed patch: http://ix.io/4EpO
2023-08-24 17:00:58 <dalias> or with description: http://ix.io/4EpQ
2023-08-24 17:32:12 <ikke> hashicorp did respond to the e-mail from ncop
2023-08-24 17:32:55 <skarnet> what did they say?
2023-08-24 17:33:45 <ikke> briefly: It's covered by the FAQ, and we don't see any issue in continuing providing packages
2023-08-24 17:34:46 <ikke> "We address this in the FAQ (Q12, 13). Since you are only redistributing it, this is allowed under BSL. The restriction around redistribution is covered in Q15 of the FAQ but that does not seem to be the use case here so please continue to include our products as part of your distro packages. "
2023-08-24 17:35:27 <Baroque_0bamo[m]> hey there! don't know if it's the right place to post that... https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50389  is waiting to be merged, but PureTryOut is on vacation right now, and it fixes a nasty bug with pmos/pinephone (basically calls stopped working!). can anyone else look into it and merge it? thanks a lot for the amazing work! <3
2023-08-24 17:36:33 <ikke> Baroque_0bamo[m]: will look into it, right now I'm trying to get arm* CI to work again
2023-08-24 17:37:19 <Baroque_0bamo[m]> \o/ thanks ikke !
2023-08-24 17:38:22 <skarnet> ikke: re hashicorp, that's good news for users - for now, at least
2023-08-24 17:38:40 <ikke> skarnet: yeah, but the problem for users is the uncertainty in the future
2023-08-24 17:38:52 <skarnet> exactly
2023-08-24 17:39:26 <ikke> The opentf initiative says they are going to announce something tomorrow
2023-08-24 17:40:34 <skarnet> and previously, did they announce the announcement of tomorrow's announcement?
2023-08-24 17:42:53 <minimal> they announced they were considering announcing something ;-)
2023-08-24 17:46:54 <humm> GNU Hurd^UOpenTF when?
2023-08-24 17:52:51 <minimal> how about "transmogrify"? :-)
2023-08-24 17:53:05 <ikke> instead of terraform?
2023-08-24 17:53:21 <minimal> as fork name lol
2023-08-24 17:53:27 <ikke> right, I'm in favor :P
2023-08-24 17:53:44 <minimal> or from an American perspective "remodeler"
2023-08-24 17:53:56 <ikke> colonializer
2023-08-24 17:55:00 <minimal> denaturer
2023-08-24 18:31:05 <ayakael> changerererer
2023-08-24 18:42:35 <rootwyrm> ikke: in context though, hashi is pretty desperate as a lot of module maintainers have basically already said 'bye.'
2023-08-24 18:43:03 <ikke> yeah, makes sense
2023-08-24 18:48:20 <rootwyrm> especially since their public docker images are based on alpine.
2023-08-24 19:37:13 <omni> uranuscraft
2023-08-24 19:37:39 <ikke> lol
2023-08-24 20:40:50 <chereskata> Hi, could anyoune merge clamav 1.1.1? Thanks a lot :)
2023-08-24 20:41:48 <ikke> what about s390x?
2023-08-24 21:01:02 <chereskata> It is allegedly fixed for 1.2.0
2023-08-24 21:01:28 <chereskata> Alternatively there is a possible patch to download rust-libc from crates.io
2023-08-24 21:04:00 <ikke> why does it fail on s390x?
2023-08-24 21:04:19 <chereskata> rust-libc does not compile for it
2023-08-24 21:04:36 <chereskata> a fix is in latest libc, that will be incorporated into 1.2.0
2023-08-24 21:05:33 <chereskata> in the mean time celeste and i thought, that temporarely disabeling that arch seems as a good idea
2023-08-24 21:05:40 <ikke> ah, lfs64
2023-08-24 21:05:41 <ikke> just patch it
2023-08-24 21:06:21 <ikke> You did mention the integrity part
2023-08-24 21:06:32 <ikke> but the downside is that you leave vulnerable version on s390x
2023-08-24 21:06:50 <chereskata> at the moment all arches are vulnerable
2023-08-24 21:07:59 <chereskata> is it possible to just patch s390x compilation?
2023-08-24 21:08:10 <ikke> yes
2023-08-24 21:08:24 <ikke> but the files should not end in *.patch
2023-08-24 21:09:35 <chereskata> how would you approach it?
2023-08-24 21:12:07 <chereskata> i thought of checking for arch and devendoring libc only on s390x
2023-08-24 21:12:35 <chereskata> akin to https://gitlab.alpinelinux.org/Celeste/aports/-/commit/fa56d024883d149582dbd7ba2d6a44f4aec7b67b , but with an arch check surrounding it
2023-08-24 21:12:47 <ikke> if [ $CARCH = s39x ] && patch -p1 <filename
2023-08-24 21:12:55 <ikke> without the if
2023-08-24 21:15:19 <ikke> chereskata: I'll merge the current MR now, then you can work on enabling s390x again
2023-08-24 21:15:59 <chereskata> thank you for your helping hand :)
2023-08-25 00:20:22 <celie> omni: Are you there?
2023-08-25 00:35:32 <omni> sometimes
2023-08-25 00:35:38 <omni> celie
2023-08-25 00:38:02 <celie> Can you check Gitlab?
2023-08-25 00:39:46 <omni> anything in particular?
2023-08-25 00:43:26 <celie> Uh, i was hoping my ocaml5 changes could be considered, but if they are too drastic and unacceptable then i will stop before i break anything
2023-08-25 00:49:09 <omni> ah
2023-08-25 00:49:40 <omni> please go ahead and open an MR with the changes
2023-08-25 00:50:44 <omni> I just did the low effort around when it was released and then was mostly waiting for feedback
2023-08-25 00:51:25 <omni> then I just got it in earlier to make it available in edge/testing
2023-08-25 00:51:35 <celie> Actually, they are for 5.1.0 (which is in rc now), and i've linked it in your MR
2023-08-25 00:52:43 <celie> s390x and riscv64 support will be back in 5.1.0 (and it seems power in 5.2.0)
2023-08-25 00:53:35 <omni> good news
2023-08-25 00:55:02 <omni> and 32bit arm in 5.3.0? ;)
2023-08-25 00:55:32 <omni> just hoping it could eventually replace 4.x ocaml in community
2023-08-25 00:55:33 <celie> No, 32-bit isn't coming back
2023-08-25 00:55:48 <omni> ok
2023-08-25 01:00:47 <celie> I think eventually it will have to replace ocaml 4.x, because i doubt the ocaml developers can maintain that forever. Seeing as the decision about 32-bit has been made, if i were to hazard a guess, i would say 5.2 (when power support is added) or the latest by 5.3 (if they need one more major version to stabilize things) is when they stop maintaining 4.x
2023-08-25 01:16:03 <celie> ges are too drastic, then i will keep my hands off
2023-08-25 01:16:03 <celie> So, if we are to make that transition easier, i think it would be good to install native compilers when available, bytecode otherwise, which is in the apkbuild i was preparing. When it really comes the time to replace 4.x, the few binary aports in community like unison and opam can become bytecoded instead; but as i said, may break stuff, and given ocaml's reputation as difficult to maintain if my chan
2023-08-25 01:17:43 <omni> and programs will be slower on often already constrained (32b) systems
2023-08-25 01:18:11 <omni> either way, I don't mind you coming with changes to testing/ocaml5 or even adopting it
2023-08-25 01:18:32 <omni> and then we can see how things evolve
2023-08-25 01:31:40 <omni> I've also thought of using a $CARCH case statement for choosing compiler, to build for 64bit archs with ocaml5 and 32bit with ocaml4 native compiler
2023-08-25 01:33:20 <omni> arm*|x86) makedepends="$makedepends ocaml4" ;;
2023-08-25 01:56:40 <celie> That should do the job too, but hopefully we can limit its usage to only a few aports to make things easier to maintain
2023-08-25 02:05:27 <bl4ckb0ne> does the vulkan bump round needs a rebuild?
2023-08-25 09:51:02 <Baroque_0bamo[m]> sorry if it's a naive/n00b question, also because i see some real work is happening here (thanks so much for that! <3) but once https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50389 has been marked as merged, what is missing for it to land as a package in the repos?
2023-08-25 10:06:54 <rnalrd> in <1h it should hit the mirrors. Replication latency ;)
2023-08-25 10:23:38 <ikke> I need to check the ARM builers, it's available already for other arches
2023-08-25 10:32:01 <ikke> Baroque_0bamo[m]: the packages should appear soon for arm
2023-08-25 12:03:44 <Baroque_0bamo[m]> \o/ thanks ikke
2023-08-25 14:26:42 <chereskata> Hi, the libiphonenumber MR is finally ready: I have had to add boost-dev as dependency for evolution-data-server to be buildable again. Fun fact: the previous version of libphonenumber (8.13.18) did also trigger a failed build for evolution-data-server on my local machine
2023-08-25 15:20:08 <mio> ikke: thanks for fixing the arm builders (and reviewing my MRs) 
2023-08-25 15:28:51 <ikke> mio: you're welcome
2023-08-25 15:40:03 <ikke> apparently libyang introduced breaking changes which break FRR pretty badly
2023-08-25 15:47:00 <omni> not sure if this is something we too should think of https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0020-sources-for-python-packaging.rst
2023-08-25 15:56:29 <ikke> apparently libyang made a breaking change (in a patch upgrade even), which breaks FRR pretty bad
2023-08-25 15:56:44 <ikke> I guess we should downgrade libyang for now
2023-08-25 16:18:07 <ikke> https://opentf.org/announcement
2023-08-25 17:12:06 <quinq> “four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative” does that thing really need 56 developers to continue working? oO
2023-08-25 17:12:37 <skarnet> "the equivalent of", so this means there are more than 56.
2023-08-25 17:12:46 <quinq> oh my
2023-08-25 17:14:40 <minimal> it means 632 managers (equivalent to 14 FTEs) lol
2023-08-25 17:17:54 <rootwyrm> quinq: oh, it needs a lot more than that.
2023-08-25 17:19:01 <quinq> minimal ;)
2023-08-25 17:21:38 <rootwyrm> hashi blew all their staff budget on salesdroids and 'analysts' focused on extraction
2023-08-25 17:23:27 <dalias> :-p
2023-08-25 17:25:26 <minimal> it's a pity only terraform appears to be forking
2023-08-25 17:27:12 <mercenary> probably because openvault sounds a bit redundant
2023-08-25 17:27:23 <ptrc> omni: i feel like this was kind of an unwritten rule in aports, stuff usually was being fetched from upstream ( mostly because upstream tests were not getting included in sdist tarballs, i suppose? )
2023-08-25 17:27:26 <ikke> contradictory I'd say
2023-08-25 17:27:51 <ikke> vault -> safe
2023-08-25 17:29:55 <minimal> schroedinger-vault? if you open the vault to check if your secrets are still there then they self-destruct ;-)
2023-08-25 17:30:35 <ikke> You can know either the secrets, or where they belong to, but never at the same time :D
2023-08-25 17:30:44 <ikke> heisenburg vault
2023-08-25 17:31:03 <ikke> Heisenberg*
2023-08-25 17:31:28 <mercenary> it has all the secrets except the one you need
2023-08-25 17:32:12 <quinq> haha
2023-08-25 17:32:29 <ikke> mercenary: sounds like /dev/urandom
2023-08-25 17:32:32 <rootwyrm> I don't know anybody using the other products except to go "wow this sucks."
2023-08-25 17:33:14 <minimal> rootwyrm: well for example the official Alpine cloud images are built using Packer...
2023-08-25 17:33:19 <mercenary> vault is not terrible. as is packer
2023-08-25 17:34:07 <rootwyrm> yeah, but packer is pretty niche. and vault is ridiculously expensive (and also impossible to calculate costs on.)
2023-08-25 17:34:59 <ikke> I guess that's for hosted Vault?
2023-08-25 17:35:07 <minimal> Enterprise Vault
2023-08-25 17:35:17 <rootwyrm> nope, hosted vault. costs $1.58 per hour per instance plus per client per cluster.
2023-08-25 17:35:39 <Ermine> Hm. Extended image includes linux-firmware, right? Do I understand correctly that linux-firmware-mrvl should be installed as well? For some reason it isn't installed
2023-08-25 17:36:27 <minimal> that was part of the "tension" for the (previously) Opensource Vault - Hashi wouldn't likely merge PRs that added stuff (i.e. HSM support) that would compete with their commercial offering
2023-08-25 17:36:51 <ikke>  yeah
2023-08-25 17:37:39 <minimal> Hashi's commercial support fees were apparently very high - fly.io ended up using Consul in a way it was not supposed to do be used to avoid huge support costs
2023-08-25 17:38:19 <rootwyrm> ayup, hashi would routinely reject or object to anything that competed with their indecipherable pricing. i mean, it's literally like someone took the combination of IBM PVU, HP RTE, and Oracle and said 'how can we make this even WORSE?'
2023-08-25 17:38:37 <minimal> i.e. the had a single world-wide Consul cluster (which uses the LAN, not WAN protocol) rather than per region clusters with those clusters then federated (or whatever Hashi call it)
2023-08-25 17:39:08 <minimal> and as they were using the "LAN" protocol they hit scaling/latency issues
2023-08-25 17:39:32 <ikke> Would using the want require the enterprice license?
2023-08-25 17:39:33 <rootwyrm> minimal: I was about to say.
2023-08-25 17:40:05 <minimal> ikke: ?
2023-08-25 17:40:27 <ikke> minimal: was wondering what they were trying to work around
2023-08-25 17:40:42 <ikke> I'm not familiar with the enterprise offerings
2023-08-25 17:40:47 <minimal> ikke: support fees - it was based on number of clusters (from memory)
2023-08-25 17:40:53 <ikke> ah ok
2023-08-25 17:40:55 <rootwyrm> ikke: yeah, that's how everyone 'cheats' the support fees. it's per cluster per node
2023-08-25 17:41:08 <minimal> so they went with a single world-wide cluster, let me find their blog writeup that explained this
2023-08-25 17:42:35 <rootwyrm> sorry, not per node, per service. consul is also now using the insane "per hour" pricing, and is the only option unless you wanna drop NDA'd amounts of cash.
2023-08-25 17:46:15 <Ermine> Or 
2023-08-25 17:47:24 <Ermine> ... does 'apks' variable in mkimage.*.sh scripts mean apks that will be included in the iso, but not necessarily be installed?
2023-08-25 17:47:57 <ikke> Ermine: yes
2023-08-25 17:48:09 <ikke> and firmware is part of the modloop
2023-08-25 17:48:15 <ikke> to save memory
2023-08-25 17:49:21 <pj> minimal: i love that
2023-08-25 17:53:33 <minimal> can't find a reference to that now, did find a doc where they admin doing the same for Nomad to save on Hashi support costs.
2023-08-25 17:53:39 <minimal> s/admin/admit/
2023-08-25 17:54:36 <minimal> Even if we did that work, Nomad pricing looks at us and sees Apple, Inc. More power to them! But, like, no."
2023-08-25 17:54:44 <minimal> https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator/
2023-08-25 18:00:23 <Ermine> Is modloop creation handled by update-kernel utility?
2023-08-25 18:10:20 <Ermine> Soo, do I understand correctly that I can manipulate which fw is present in modloop by modifying moodloopfw variable in mkimage profile function?
2023-08-25 18:11:38 <ikke> I think so yes
2023-08-25 18:20:01 <Ermine> ... But better solution of idefix's issue would be making /lib/firmware writeable somehow
2023-08-25 18:20:33 <ikke> Ermine: An overlay could help
2023-08-25 18:20:47 <ikke> There should already be support for that
2023-08-25 19:51:02 <omni> ptrc: maybe? 114 aports in community has pypi as source
2023-08-25 20:23:53 <ikke> PabloCorreaGomez[m]: I've deployed the latest version of aports-qa-bot
2023-08-25 23:58:07 <celie> ptrc: community/kodi has "flatbuffers-dev<23.5" in depends_dev (i looked for something upstream and got https://github.com/xbmc/xbmc/issues/23331, looking further it seems the fix (removing a forward declaration) has already been added to kodi 20.2, so maybe that version restriction is no longer needed)
2023-08-25 23:59:20 <ptrc> hm, the commit seems to be only on the 21.0a2 tag?
2023-08-25 23:59:23 <ptrc> unless i'm missing something
2023-08-25 23:59:28 <ptrc> ( also, thanks, good catch :3 )
2023-08-25 23:59:48 <celie> It was cherry picked into 20.2
2023-08-26 00:00:45 <celie> https://github.com/xbmc/xbmc/commit/07d8c98
2023-08-26 00:03:39 <ptrc> ah, right
2023-08-26 00:06:31 <ptrc> it's really annoying how github doesn't even show that the commit is included in the 20.2-Nexus tag, only the branch
2023-08-26 00:09:54 <celie> At least this change was recorded in the release notes (search for #23334 in https://github.com/xbmc/xbmc/releases/tag/20.2-Nexus)
2023-08-26 10:10:16 <ikke> Ermine: ok to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50116?
2023-08-26 10:12:08 <Ermine> Wow, it has been built successfully
2023-08-26 10:12:21 <Ermine> ikke: yes, sorry for delay
2023-08-26 10:13:32 <ikke> np
2023-08-26 12:03:53 <celie> ikke: i may be missing something, but i don't think the sodiff for !50523 is for sqlite-dev (which you used with ap revdep)
2023-08-26 12:04:54 <celie> From what i see, it's for sqlite-tcl, and Tcl will take care of loading the correct .so
2023-08-26 12:05:12 <ikke> yes, you are right
2023-08-26 12:15:34 <ikke> need to restart gitlab to fix an issue
2023-08-26 12:32:14 <ikke> Someone was not behaving
2023-08-26 14:27:15 <omni> celie: #15221
2023-08-26 18:46:42 <rootwyrm> Well, that's a new unexpected error in linux-lts. "gcc: error: unrecognized command-line option '-mlittle-endian'"
2023-08-26 19:04:16 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/issues/15220#note_332886
2023-08-26 19:04:35 <ptrc> would there be a way to make all auto-generate patch URLs hard-fail the lint stage?
2023-08-26 19:05:50 <ptrc> ah, it doesn't even throw the "volatile source" error now, because the patch is being renamed
2023-08-26 19:16:23 <ikke> ptrc: we can define specific exit codes that are allowed
2023-08-26 19:16:51 <ikke> So most linting failures would return that exit code, but if a specific one is returned, it's a hard failure
2023-08-26 19:16:58 <ikke> https://docs.gitlab.com/ee/ci/yaml/#allow_failureexit_codes
2023-08-26 19:43:51 <Habbie> ikke, thanks for the pdns-recursor bump!
2023-08-26 19:44:24 <ikke> It was celie who did the bump, I just pressed some buttons :P
2023-08-26 19:51:26 <Habbie> ah! and that's when i started getting emails
2023-08-26 19:51:29 <Habbie> celie, thanks :)
2023-08-26 19:51:51 <ikke> Habbie: I broke the bot a bit, so it didn't automatically assign MRs to maintainers
2023-08-26 19:52:06 <Habbie> ah
2023-08-26 23:29:56 <celie> Habbie: You're welcome
2023-08-27 03:41:19 <rootwyrm> So, for something like linux-lts... does anyone have a tool for comparing config diffs in a sensible fashion between distros that isn't painfully manual?
2023-08-27 07:46:34 <quinq> rootwyrm, have you tried scripts/diffconfig?
2023-08-27 11:59:47 <rootwyrm> quinq: I have not, will take a look at that. Thanks!
2023-08-27 12:00:25 <rootwyrm> Well, if I can figure out why the hell my builder isn't cross-compiling linux-lts any more. >:/
2023-08-27 14:49:44 <minimal> rootwyrm: Alpine packages aren't designed to be cross-compiled
2023-08-27 14:50:29 <ikke> _many_ packages
2023-08-27 14:50:39 <ikke> There are some that support it
2023-08-27 14:50:50 <ikke> And need to even
2023-08-27 14:50:53 <rootwyrm> Yeah, p.sure linux-lts is on the "should work" list. It worked before.  ¯\_(ツ)_/¯
2023-08-27 14:51:26 <minimal> ikke: oh? I thought the Alpine "intention" was to natively compile everything
2023-08-27 14:51:34 <rootwyrm> That builder's finicky as hell to put it mildly though. I'll probably just reimage. cache keeps breaking.
2023-08-27 14:51:38 <ikke> minimal: think about when we need to bootstrap a new arch
2023-08-27 14:51:51 <minimal> ikke: I thought emulation was used then
2023-08-27 14:51:54 <ikke> no
2023-08-27 14:51:56 <rootwyrm> minimal: nope
2023-08-27 14:51:58 <ikke> check scripts/bootstrap.sh
2023-08-27 14:52:14 <rootwyrm> ESPECIALLY cannot rely on emulation for a lot of bringup stuff.
2023-08-27 14:52:36 <ikke> But we explicitly do not support cross-compiling everything
2023-08-27 14:52:53 <rootwyrm> Yup, because a lot of it just cannot be cross-compiled because emulation sucks.
2023-08-27 14:53:08 <rootwyrm> (cries in .NET and boringtls)
2023-08-27 14:54:23 <ikke> We use emulation for riscv simply because we don't have a sufficiently powerful builder yet
2023-08-27 14:54:28 <ikke> mips64 as native
2023-08-27 14:54:37 <ikke> (some beefy router hardware)
2023-08-27 14:54:53 <rootwyrm> Yeah, though probably could pick up some sifive2's?
2023-08-27 14:54:55 <minimal> ok, to reword, I thought that (apart from bootstrapping) Alpine packages were intended to be natively compiled
2023-08-27 14:55:04 <ikke> rootwyrm: we do have sifives, they are still too slow
2023-08-27 14:55:12 <ikke> and we don't have good support for clustering builders
2023-08-27 14:55:33 <ikke> that's  why we were interested in the milkv pioneer
2023-08-27 14:55:35 <rootwyrm> minimal: the _desire_ is everything native. But for things related to bringup (e.g. linux-*) cross-compiling is an absolute requirement.
2023-08-27 14:56:08 <ikke> cross-compilation != emulation
2023-08-27 14:56:12 <minimal> rootwyrm: "bringup" as opposed to "bootstrap"? Aren't they the same thing?
2023-08-27 14:56:18 <rootwyrm> ikke: original or second version? And yeah, I have noticed that's an issue. Not that gitlab helps there.
2023-08-27 14:56:20 <ikke> bringup is for hardware
2023-08-27 14:56:27 <rootwyrm> minimal: ^^^
2023-08-27 14:56:27 <ikke> bootstrap is for software
2023-08-27 14:56:53 <ikke> rootwyrm: has little to do with gitlab
2023-08-27 14:57:06 <ikke> our builders use a custom solution
2023-08-27 14:57:30 <ikke> the gitlab-runner architecture would actually help
2023-08-27 14:57:51 <rootwyrm> ikke: I assure you, as a paying victim of gitlab, it would make things worse. A lot worse.
2023-08-27 14:58:50 <ikke> the main 'issue' is that the current architecture assumes everything is serialized through a single builder that has a complete snapshot of the repository
2023-08-27 14:59:05 <rootwyrm> maybe if I ever find any free time I can look at that problem though, because build clusters are much nicer than waiting on firefox. ;P
2023-08-27 15:00:11 <rootwyrm> ikke: ah, yeah, and of course if you instead say 'nah use the hot repo' then you have the mismatch problem, if you say 'use stable' same problem. and with shared disk, can run into X depends on Y :(
2023-08-27 15:00:12 <ikke> you can probably already setup distcc 
2023-08-27 15:00:53 <rootwyrm> ugh, no thank you, once per decade is more than enough.
2023-08-27 15:04:52 <rootwyrm> is abuild even distcc-aware?
2023-08-27 15:05:58 <ikke> Think you can make it distscc aware
2023-08-27 15:06:03 <ikke> Haven't tried it myself
2023-08-27 15:08:45 <rootwyrm> Maybe if I get some time I can look into that at least... hopefully on the last iteration of getting the stupid aml-s905x-cc's up.
2023-08-27 15:10:20 <ikke> For example, you can define CC / CXX to override the compiler that is used
2023-08-27 15:48:45 <rootwyrm> Probably could also pare down the lts.aarch64.config a fair bit... pretty sure you ain't gonna find CONFIG_SND_INTEL8X0 on any of 'em.
2023-08-27 18:07:35 <ikke> new stable kernels released
2023-08-27 18:07:48 <ikke> 6.1.48, 5.15.128, 5.10.192
2023-08-27 19:10:50 <rootwyrm> Uh.. shouldn't `abuild package` spit out the packages?
2023-08-27 19:12:01 <ikke> no
2023-08-27 19:12:13 <ikke> that's done as part of abuild rootpkg
2023-08-27 19:29:47 <rootwyrm> ikke: ah-ha, I was close. thank you :)
2023-08-27 19:31:39 <rootwyrm> of course, the provider i found for aarch64 builds has decided today's a good day to have service problems. :(
2023-08-27 19:35:33 <ikke> fun
2023-08-27 19:39:05 <Habbie> hetzner?
2023-08-27 19:39:26 <rootwyrm> Habbie: yup :(
2023-08-27 19:40:03 <Habbie> i heard more complaints, and my storage box has a weird delay on ssh login
2023-08-27 19:40:12 <Habbie> https://status.hetzner.com/ was green for a long time but is orange now
2023-08-27 19:40:20 <Habbie> however, the two items don't seem to cover the full impact i'm hearing
2023-08-27 19:40:33 <rootwyrm> yeah... really wish my usual provider would add arm64. would make life a lot easier, especially since I have a really good relationship with their support org.
2023-08-27 19:40:54 <rootwyrm> Habbie: oh yeah, their cogent peering has been flat out broke for days. >20% packet loss, 400ms+ latency
2023-08-27 19:41:15 <Habbie> amazon and oracle have arm64 too
2023-08-27 19:41:17 <Habbie> oracle is garbage, though
2023-08-27 19:41:32 <Habbie> haven't been able to log in to their portal for a year now
2023-08-27 19:41:39 <Habbie> but my (free!) arm64 VM still works fine
2023-08-27 19:42:01 <rootwyrm> they're both hot garbage, TBQH. amazon's arm64 is 100% 'crushed by noisy neighbor' unless you pony up the big bucks.
2023-08-27 19:42:09 <Habbie> ah right
2023-08-27 19:42:14 <Habbie> i haven't tried it much on amazon
2023-08-27 19:43:36 <rootwyrm> Simple linux-lts build on AWS t4g.xlarge took as long as qemu crossbuild on a Ryzen 2700X. 
2023-08-27 19:44:24 <Habbie> right
2023-08-27 22:16:52 <PabloCorreaGomez[m]> ikke, ncopa: I had a bit of a look today at the qa-bot for the removal of the "waiting for maintainer feedback" label. Two thoughts
2023-08-27 22:19:10 <PabloCorreaGomez[m]> Right now, the whole bot is only taking care of events related to merge request. The initial idea was to remove the label when maintainers approve or comment
2023-08-27 22:20:00 <PabloCorreaGomez[m]> I'm a bit worried that comment might significantly increase the load. Based on gut feelings, no science. Should I just try anyway and we see, or let's only consider the "approve" and that's it?
2023-08-27 22:32:46 <PabloCorreaGomez[m]> And if we go for the approve... I don't see much of the purpose of only removing the label. May I directly try to, if there are no threads, and the pipeline is green, rebase and merge?
2023-08-27 22:33:20 <PabloCorreaGomez[m]> Seems to be possible with "head_pipeline_id" and "blocking_discussions_resolved" from the MR properties
2023-08-28 05:41:14 <ikke> ncopa: you probably are aware, but new stable kernels were released
2023-08-28 05:41:17 <ikke> 6.1.48, 5.15.128, 5.10.192
2023-08-28 05:46:30 <ncopa> building 6.1.49 here now
2023-08-28 11:12:04 <clandmeter> ncopa: do you know why there is a 10+ second kernel boot delay when boot alpine via qemu? it happens before init kicks in.
2023-08-28 11:13:14 <ncopa> clandmeter: no idea. it does not happen here?
2023-08-28 11:14:38 <ncopa> qemu-system-x86_64 -enable-kvm -m 1024 -cdrom https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-virt-3.18.3-x86_64.iso
2023-08-28 11:14:49 <ncopa> boots in ~4 seconds here
2023-08-28 11:15:01 <zcrayfish> No issues here either. Using same args as ncopa (in different order though)
2023-08-28 11:15:11 <clandmeter> im using kernel/initfs
2023-08-28 11:15:26 <clandmeter> initrd...
2023-08-28 11:15:49 <clandmeter> you cannot modify cmdline with iso
2023-08-28 11:18:45 <ncopa> ncopa-desktop:~/tmp$ bsdtar -x -f ~/Downloads/alpine-virt-3.18.3-x86_64.iso boot/
2023-08-28 11:18:45 <ncopa> ncopa-desktop:~/tmp$ qemu-system-x86_64 -enable-kvm -m 1024 -cdrom https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-virt-3.18.3-x86_64.iso -kernel boot/vmlinuz-virt -initrd boot/initramfs-virt
2023-08-28 11:19:04 <ncopa> boots in a couple of seconds here
2023-08-28 11:20:17 <ncopa> clandmeter: do you have kvm enabled?
2023-08-28 11:20:45 <clandmeter> i think i know why
2023-08-28 11:20:51 <ncopa> 👍
2023-08-28 11:20:51 <clandmeter> when you specifiy ip=dhcp
2023-08-28 11:21:01 <clandmeter> it does some magic in the kernel
2023-08-28 11:21:09 <clandmeter> but i added it for initramfs
2023-08-28 11:21:15 <ncopa> aha
2023-08-28 11:48:55 <ncopa> zlib updates are scary
2023-08-28 11:49:01 <ncopa> bumped zlib to 1.3 now
2023-08-28 11:49:05 <ncopa> lets see what breaks
2023-08-28 11:49:25 <ptrc> did the soname change? :p
2023-08-28 11:49:45 <ncopa> no
2023-08-28 11:49:45 <ikke> Yes
2023-08-28 11:49:50 <ikke> Ih
2023-08-28 11:50:01 <ptrc> > /home/buildozer/aports/main/zlib/pkg/zlib/lib/libz.so.1.3
2023-08-28 11:50:07 <ptrc> i'd say it did change?
2023-08-28 11:50:53 <ptrc> ah, no, it's libz.so.1 :)
2023-08-28 11:51:02 <ptrc> whew
2023-08-28 11:51:06 <ncopa> yup
2023-08-28 11:51:32 <ptrc> apparently the build log didn't show the symlink, for some reason
2023-08-28 17:30:01 <bl4ckb0ne> PureTryOut: fyi https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50399
2023-08-28 17:43:32 <minimal> clandmeter: yes the approx 12 seconds delay is due to this: https://github.com/torvalds/linux/blob/v6.1/net/ipv4/ipconfig.c#L1503
2023-08-28 17:44:06 <minimal> the only way to avoid it would be to set CONFIG_IP_PNP=n in the kernel but not sure if anyone is likely to be relying on kernel IP PNP
2023-08-28 17:44:53 <clandmeter> it does not need fixing i believe, maybe the initramfs script could be changed. so they dont mix.
2023-08-28 17:45:32 <clandmeter> thx for the link btw
2023-08-28 17:45:57 <clandmeter> interesting it does not show anything on console
2023-08-28 17:46:12 <minimal> clandmeter: the initramfs script purposely does network aotoconfig itself, but that can't happen until the kernel tries to do it first
2023-08-28 17:46:39 <clandmeter> i dont see a point why they need to do it both?
2023-08-28 17:46:50 <clandmeter> i should be able to choose for one of them
2023-08-28 17:46:52 <minimal> clandmeter: try adding    dyndbg="file ipconfig.c +p" to your cmdline
2023-08-28 17:47:20 <minimal> then you'll see a single new dmesg entry: "IP-Config: Entered."
2023-08-28 17:47:42 <clandmeter> right, i believe you. the problem was i didnt know it was the ip option in the first place
2023-08-28 17:49:07 <minimal> there's a comment in mkinitfs' init code regarding this:
2023-08-28 17:49:19 <minimal> "we do this now and not by enabling kernel-mode DHCP because kernel-model DHCP appears to require that network drivers be built into the kernel rather than as modules."
2023-08-28 17:50:29 <minimal> you wouldn't want a huge kernel with every posisble network drivers compiled into it...
2023-08-28 17:53:16 <minimal> (quickly) looking at the linux-virt x86_64 config there don't seem to be any network device drivers builtin and so disabling kernel IP PNP should be safe to do.
2023-08-28 17:53:26 <minimal> haven't looked at linux-lts yet
2023-08-28 18:00:29 <minimal> just checked, IP PNP is disabled for linux-lts, so it is only a linux-virt issue]
2023-08-28 18:02:14 <minimal> clandmeter: so I suspect it would be safe to disable that in the linux-virt kernel
2023-08-28 18:05:46 <clandmeter> can you check when it was enabled?
2023-08-28 18:05:52 <clandmeter> was it by request?
2023-08-28 18:10:55 <minimal> looks like it was last changed in Nov 2019
2023-08-28 18:12:03 <minimal> well that's when linux-lts was created (after the old hardened/vanilla stuff was dropped)
2023-08-28 18:18:27 <minimal> clandmeter: I did find this which is when it appears to have been disabled in non-virt kernels: https://gitlab.alpinelinux.org/alpine/aports/-/issues/1754
2023-08-28 18:18:35 <minimal> back in 2013 :-)
2023-08-28 18:21:55 <minimal> clandmeter: the kernel default configs for x86_64, x86, and aarch64 have it enabled, so I guess it has always been enabled in general and only specifically disabled for (some? all?) physical kernels
2023-08-29 00:22:21 <celie> ayakael: Hi, you can use apkbuild-cpan to generate an APKBUILD file for Text::Markdown
2023-08-29 00:28:22 <ayakael> celis: Oh good to know!
2023-08-29 00:29:07 <celie> It should also work for the 3 other aports from CPAN needed for Ikiwiki.
2023-08-29 10:07:23 <clandmeter> ncopa: are you still using expect somewhere? 
2023-08-29 10:52:54 <ncopa> clandmeter: not really
2023-08-29 10:53:16 <clandmeter> ah ok
2023-08-29 10:53:47 <ncopa> i use pyexpect or what it is called, which is implemented in pythong
2023-08-29 10:54:00 <clandmeter> there seems to be an alternative https://empty.sourceforge.net/
2023-08-29 10:54:16 <clandmeter> but i am unable to get it to work with qemu
2023-08-29 10:55:08 <clandmeter> pythong? you have some interesting underwear :)
2023-08-29 10:55:13 <ncopa> i switched to pexpect and pytest
2023-08-29 10:55:17 <ncopa> :)
2023-08-29 10:56:35 <ncopa> I boot up alpine in qemu and use pexpect: https://github.com/ncopa/alpine-installer-testsuite
2023-08-29 10:56:58 <ncopa> clandmeter: what is your usecase?
2023-08-29 10:57:44 <clandmeter> i was thinking of ditching packer
2023-08-29 10:58:14 <ncopa> to create disk images?
2023-08-29 10:58:21 <clandmeter> yup
2023-08-29 10:59:03 <ncopa> i am not too happy with pexpect, ingeneral
2023-08-29 10:59:47 <clandmeter> empty is very small, but it does not trigger to input somehow
2023-08-29 11:00:37 <ncopa> i think that from alpine 3.18 and later, it would make more sense to use a tiny-cloud user-data script
2023-08-29 11:04:49 <ncopa> i have a terraform script somewhere where I create an armv7 disk image
2023-08-29 11:04:57 <ncopa> in qemu
2023-08-29 11:05:03 <clandmeter> i also use a script 
2023-08-29 11:05:15 <clandmeter> its mounted in the vm and then run 
2023-08-29 11:05:36 <ncopa> this is a terraform script that spawns an arm64 vm in aws, and boot alpine armv7 image
2023-08-29 11:05:46 <ncopa> and spit out a basic disk image
2023-08-29 11:09:24 <ncopa> clandmeter: https://tpaste.us/ePXz
2023-08-29 11:11:14 <ncopa> the aws stuff is probably not so interesting, but the user-data script shows how you can use setup-alpine in qemu to generate disk image
2023-08-29 11:43:02 <ptrc> mio: fyi, https://dup.pw/alpine/aports/b373c3b42a9
2023-08-29 11:43:58 <ptrc> i don't know why it was re-enabled on riscv64, janet is still unsupported
2023-08-29 12:57:22 <rootwyrm> Oh, lovely, botspam.
2023-08-29 13:00:59 <ptrc> rootwyrm: it's just a netsplit
2023-08-29 13:01:01 <ptrc> not botspam
2023-08-29 13:03:09 <rootwyrm> ptrc: yeah, didn't think anyone would mess up host presentation like that. but, eh, I'm old.
2023-08-29 14:35:07 <mio> ptrc: that's fine, thanks for letting me know
2023-08-29 14:39:51 <mio> (it wasn't so much re-enabled as not disabled if it builds. could also only enable on the main four arch until people report it working from others like riscv64, just no particular reason to? not sure what's the usual practice in cases where a maintainer doesn't have direct access to hardware to test gui apps whether they run)
2023-08-29 14:41:02 <mio> (if you were referring to janet-dev then no idea, sorry)
2023-08-29 15:27:11 <ptrc> i was referring that the package blocked the riscv64 builder after merging, because it was trying to pull janet-dev, which is not available there
2023-08-29 15:27:22 <ptrc> s/referring/referring to the fact/
2023-08-29 15:28:37 <mio> sorry about that! didn't realise it was hanging the builder
2023-08-29 15:29:50 <mio> hanging/blocking, thanks for sorting it out
2023-08-29 15:30:34 <ptrc> no worries :p for next time, the riscv64 CI is manual due to lack of resources, but in cases like enabling a package you can click on the CI pipeline and run the riscv64 job
2023-08-29 15:33:32 <mio> okay, thanks!
2023-08-29 19:23:18 <ptrc> fabled: can we get !50506 merged soon? i'm not sure how one can use plymouth without it, unless that actually works with other display drivers than amdgpu
2023-08-29 20:41:29 <fabricionaweb> hey, someone flagged a package that I maintain (pnpm) but I have no clue why, the message left is totally meaningless
2023-08-29 20:41:53 <quinq> ok
2023-08-29 20:41:58 <fabricionaweb> I tried to reach it by email asking more details, shall I wait?
2023-08-29 20:42:45 <minimal> fabricionaweb: "spam" flagging is not uncommon
2023-08-29 20:42:55 <ikke> If they don't provide any details, _can_ just ignore it
2023-08-29 20:43:02 <ikke> Nothing happens if you ignore a flagged package
2023-08-29 20:43:20 <quinq> Usually yes, someone waits for an answer after sending a message with a question
2023-08-29 20:44:05 <fabricionaweb> ah ok, thank you all, I get it
2023-08-30 08:39:43 <liske> I have a Intel Atom C3558 based system which works fine til Alpine 3.17
2023-08-30 08:40:45 <liske> on Alpine 3.18 there are kernel exceptions and it does not reach the plugin prompt https://tpaste.us/wxMb
2023-08-30 08:40:53 <liske> s/plugin/login/
2023-08-30 08:46:20 <ncopa> probably due to kernel config change that enabled PAE
2023-08-30 08:46:47 <ncopa> oh , its 64bit
2023-08-30 08:46:55 <liske> yes
2023-08-30 08:47:59 <liske> could it be a crypto issue (verify_pkcs7_* in the stack trace)?
2023-08-30 08:49:16 <ncopa> dunno. how much memory do you have?
2023-08-30 08:49:24 <liske> 8GB
2023-08-30 08:49:29 <ncopa> could also be a bug in squashfs?
2023-08-30 08:49:57 <liske> booting the usb drive on a "full featured" cpu seems to work
2023-08-30 08:51:21 <ncopa> does this happen when you boot an alpine-standard usb?
2023-08-30 08:51:25 <ncopa> with 3.18
2023-08-30 08:51:43 <liske> let me check
2023-08-30 09:04:05 <liske> it crashes, too
2023-08-30 09:04:51 <liske> https://tpaste.us/JRa7 
2023-08-30 09:38:06 <ncopa> let me build a new iso image with latest kernel
2023-08-30 09:48:47 <liske> ok
2023-08-30 09:51:02 <ncopa> can you please try this? https://dev.alpinelinux.org/~ncopa/alpine/alpine-standard-20230830-x86_64.iso
2023-08-30 09:52:46 <liske> yes
2023-08-30 09:56:49 <liske> (in the meantime I tried to boot with init=/bin/sh and run the find|sort|modprobe spell from /etc/init.d/hwdrivers and it does not crash)
2023-08-30 09:58:14 <ncopa> because the driver causing it is not in initramfs
2023-08-30 09:58:22 <ncopa> i suspect pcspkr
2023-08-30 09:59:04 <liske> https://tpaste.us/8M76 
2023-08-30 09:59:55 <liske> it is not always pcspkr, IMHO the traces are looking different every time
2023-08-30 10:00:40 <ncopa> hum
2023-08-30 10:00:44 <ncopa> yup
2023-08-30 10:00:54 <ncopa> i think this should be reported upstream
2023-08-30 10:01:17 <ncopa> i have no idea what might trigger this
2023-08-30 13:05:16 <PureTryOut> is there a good way to make a package depend on a specific version of another, but not care about the pkgrel? Right now doing `depends="<something>=$pkgver"` makes it fail to install if the version is available but not with the same pkgrel as the package it's depending on
2023-08-30 13:06:36 <ikke> Use ~
2023-08-30 13:08:18 <ikke> That allows variation in the components that you don't specify 
2023-08-30 13:08:47 <PureTryOut> So `depends="<something>~=$pkgver"`?
2023-08-30 13:10:23 <ikke> Yes, or even without the =, but both should work 
2023-08-30 13:11:06 <PureTryOut> Awesome thanks
2023-08-30 13:12:21 <celie> I remember an MR where this was discussed !49512
2023-08-30 13:15:20 <ikke> That was more related to install_if
2023-08-30 13:19:00 <celie> I was thinking more of how both ~ and >= were mentioned there, but yea, may not really be relevant here
2023-08-30 16:58:46 <omni> PureTryOut: wb =)
2023-08-30 17:08:51 <PureTryOut> Thanks 😄
2023-08-30 21:29:57 <j_v> I posted !177401 but missed that it is dup of !177246, should I cancel my MR?
2023-08-30 21:37:54 <j_v> oh, sorry, was looking at the pipelines, mine is !50761, celeste's is !50725
2023-08-30 22:03:29 <minimal> the new aport just merged, py3-docker, isn't that the same software as the existing py3-docker-py?
2023-08-30 22:20:36 <j_v> minimal: look same to me
2023-08-30 22:28:09 <omni> good eye, missed that one
2023-08-30 22:31:39 <j_v> i closed !50761 in deference to earlier 50725. do i need to do anything with/for 50725 since it was assigned to me?
2023-08-30 22:36:20 <omni> j_v: generally press the [Approve] button, if you can find it/it's available to you, or give a thumb up and/or write a comment that you approve of the change, so we know
2023-08-30 22:36:42 <omni> now I assumed and merged celie's
2023-08-30 22:45:52 <j_v> omni: thanks. will do that next time it comes up.
2023-08-30 22:46:12 <j_v> celie: thanks for bumping traceroute
2023-08-30 22:47:23 <j_v> is there an issue with gitlab notifications? i would have thought that i would get email when the MR was assigned to me
2023-08-30 22:49:16 <j_v> not a big deal, will double check next time before i submit MR
2023-08-30 23:01:03 <rootwyrm> Hunh, anyone regularly use cloud-init apk_repos?
2023-08-30 23:01:11 <ptrc> omni: j_v: i'll just add to this, a thumbs up doesn't send an email notification, so a LGTM comment would be preferred :p
2023-08-30 23:03:49 <minimal>  rootwyrm: yes I do (as author of apk support in cloud-init and maintainer of cloud-init) :-)
2023-08-30 23:04:18 <minimal> what's the issue?
2023-08-30 23:04:44 <j_v> ptrc: thanks for heads up, will do that going forward
2023-08-30 23:07:10 <rootwyrm> minimal: it should just be apk_repos: alpine_repo: community_enabled: true, yeah?
2023-08-30 23:08:17 <minimal> rootwyrm: well you need to specify "version:" also
2023-08-30 23:08:43 <minimal> https://cloudinit.readthedocs.io/en/latest/reference/modules.html#apk-configure
2023-08-30 23:09:03 <rootwyrm> minimal: yeah, omitted for brevity, but it's in there. lemme try re-running another image, seeing occasional module fails on aarch64
2023-08-30 23:09:12 <minimal> look in the "Config schema" section to see what is required or optional
2023-08-30 23:09:52 <minimal> rootwyrm: BTW I just raised a MR for the new release of cloud-init so it should be merged shortly
2023-08-30 23:11:31 <rootwyrm> minimal: sadly, provider thinks everyone should be back on 21.x because of course they should. 
2023-08-30 23:11:48 <minimal> rootwyrm: eh? which provider?
2023-08-30 23:12:54 <minimal> rootwyrm: you're using their own prepackaged Alpine image rather than your own?
2023-08-30 23:14:29 <rootwyrm> minimal: nope, had to roll my own, because Hetzner
2023-08-30 23:15:56 <omni> ptrc: 👍
2023-08-30 23:16:15 <minimal> rooteyrm: you know about my script? https://github.com/dermotbradley/create-alpine-disk-image
2023-08-30 23:16:34 <minimal> rootwyrm: ^^^
2023-08-30 23:18:14 <rootwyrm> minimal: yeah, but aarch64. hetzner doesn't allow images there, so, some hackery was employed.
2023-08-30 23:18:32 <minimal> rootwyrm: the Hetzner DataSource in cloud-init unfortunately doesn't support private network definitions.....as Hetzner haven't updated their DataSource for it
2023-08-30 23:21:53 <omni> minimal: *blush* I merged your cloud-init MR, hope that was OK! I was going through MRs that were submitted by maintainers of the aports, passing, looked ok, weren't marked as Draft...
2023-08-30 23:21:53 <rootwyrm> minimal: yeaaaah, unfortunately painfully aware of that too. And of course I need that, so, the result is going to be somewhat of an abomination. But I've built worse.
2023-08-30 23:22:57 <minimal> omni: thanks
2023-08-30 23:23:42 <minimal> rootwyrm: I raised the lack of Hetzner private networking in their cloud-init DS as an Issue on the cloud-init github several weeks ago
2023-08-30 23:23:43 <omni> *phew* just got a bit worried that you were still working on it =)
2023-08-30 23:24:35 <minimal> rootwyrm: is their aarch64 image situation a temporary one?
2023-08-30 23:24:58 <rootwyrm> minimal: they haven't said, but I'm presuming it's not, and they just don't intend to support user images other than snapshots.
2023-08-30 23:25:50 <minimal> rootwyrm: that sounds like a bummer
2023-08-30 23:25:51 <rootwyrm> Hopefully Vultr adds aarch64 at some point soon, especially since I can get those images fixed pretty quick.
2023-08-30 23:26:04 <rootwyrm> (or just roll my own again.)
2023-08-30 23:26:55 <rootwyrm> minimal: it's certainly inconvenient to an extent, but, once the snapshot's done I can just keep it forever. Don't like having to pay extra for it, but, eh.
2023-08-30 23:32:30 <rootwyrm> minimal: in module config, it should be ssh-import-id, yeah? That one's still saying it doesn't exist.
2023-08-30 23:36:26 <minimal> rootwyrm: you're referring to /etc/cloud/cloud.cfg in cloud 23.3?
2023-08-30 23:37:20 <rootwyrm> minimal: yah
2023-08-30 23:38:22 <minimal> it would be ssh_import_id in cloud_config_modules: section
2023-08-30 23:39:07 <minimal> or are you referring to during boot seeing a message that the ssh-import-id *package* is not installed? ;-)
2023-08-30 23:40:56 <rootwyrm> Nah, I had `ssh-import-id` not `ssh_import_id`
2023-08-30 23:41:41 <minimal> rootwyrm: are you overriding the packaged /etc/cloud.cfg file?
2023-08-30 23:42:06 <minimal> oops /etc/cloud/cloud.cfg
2023-08-30 23:43:25 <rootwyrm> Yeah, I have some shenanigans
2023-08-30 23:44:09 <minimal> rootwyrm: so then best to overrride stuff by creating new file(s) in /etc/cloud/cloud.cfg.d/ instead. Have a look at how my script does this
2023-08-30 23:45:52 <rootwyrm> minimal: yeah, that's what I'm doing. I had dashes instead of underscores in there
2023-08-30 23:46:31 <minimal> actually either dashes or underscores work but things have recently standardised on underscores so I didn't want to tell you bad practice lol
2023-08-30 23:58:03 <rootwyrm> minimal: nope, wasn't that... 2023-08-30 23:54:23,733 - modules.py[WARNING]: Could not find module named cc_ssh_import_id (searched ['cc_ssh_import_id', 'cloudinit.config.cc_ssh_import_id'])
2023-08-31 00:00:07 <minimal> rootwyrm: you ARE using 23.3? I don't think so as pkgs.alpinelinux.org only shows that version for armhf/armv7/ppc64le so far
2023-08-31 00:00:23 <minimal> guess the other arch packages are waiting for builder
2023-08-31 00:01:31 <minimal> ah, it's now showing also for x86 and aarch64
2023-08-31 00:01:52 <minimal> it'll probably take a little time to appear on repos
2023-08-31 00:02:40 <minimal> the cc_ssh_import_id module wasn't packaged for earlier versions of cloud-init as it only started working in 23.3
2023-08-31 00:09:47 <rootwyrm> minimal: ah, that'd explain it. I assumed it was in 23.1 since it's in the docs.
2023-08-31 00:11:27 <minimal> rootwyrm: yes ssh-import-id has been in cloud-init for some time, however *Alpine* support for it is what I added in cloud-init 23.3 which only came out at the start of this week (and I only pushed an Alpine MR for it around the time we started toalking today)
2023-08-31 00:12:23 <rootwyrm> minimal: well, since I'm not using it yet anyways, it's no big deal there.
2023-08-31 00:13:23 <minimal> rootwyrm: again, I'd recommend you create override file(s) in /etc/cloud/cloud.cfg.d/ rather than modifying /etc/cloud/cloud.cfg
2023-08-31 00:13:44 <rootwyrm> minimal: yes, as I said, that's what I am doing
2023-08-31 00:14:24 <minimal> ok, and base your override off the provided cloud.cfg contents
2023-08-31 00:16:20 <minimal> basically I don't package any cloud-init modules that don't work on Alpine and therefore have removed references to them from cloud.cfg
2023-08-31 00:17:57 <minimal> rootwyrm: you should also have a look at /usr/share/doc/cloud-init/README.Alpine in the cloud-init-doc package as it has relevant/important information
2023-08-31 00:18:15 <rootwyrm> minimal: except the part about ssh-import-id ;P
2023-08-31 00:18:32 <minimal> rootwyrm: which part?
2023-08-31 00:20:04 <rootwyrm> "install additional packages" - there is no ssh-import-id on aarch64
2023-08-31 00:20:32 <minimal> rootwyrm: there is in Alpine Edge
2023-08-31 00:21:46 <minimal> https://pkgs.alpinelinux.org/packages?name=ssh-import-id&branch=edge&repo=&arch=aarch64&maintainer=
2023-08-31 00:25:35 <minimal> rootwyrm: are you using Alpine 3.18 perchance?
2023-08-31 00:28:46 <rootwyrm> Yeah, I'm definitely not taking these to edge.
2023-08-31 00:29:25 <minimal> well cloud-init 23.3 is not packaged (yet) for 3.18
2023-08-31 00:30:30 <minimal> and so it makes assumptions.....like the availability of ssh-import-id which is available for Edge but not (yet) for 3.18 - both ssh-import-id and cloud-init 23.3 (or more recent) will end up in Alpine 3.19
2023-08-31 00:31:02 <minimal> I moved ssh-import-id today from testing to community to ensure that it would therefore appear in Alpine 3.19
2023-08-31 00:31:58 <minimal> so it is possible you may hit issues running cloud-init 23.3 on Alpine 3.18, I don't know off the top of my head
2023-08-31 00:32:43 <minimal> so best to stick with the already packaged 23.1.2 in Alpine 3.18
2023-08-31 00:36:30 <rootwyrm> which is fine, I'm not actually using ssh-import-id yet since the other deploys are ... significantly more complex.
2023-08-31 00:37:35 <minimal> rootwyrm: I mean in general, not specific to ssh-import-id, it is possible that other functionality relies on specific versions of other software that Alpine 3.18 may not have
2023-08-31 00:37:54 <rootwyrm> Nah, if there was anything else, I would've already broken it a lot.
2023-08-31 00:43:18 <minimal> rootwyrm: BTW the Hetzner private networks issue is: https://github.com/canonical/cloud-init/issues/4263
2023-08-31 00:49:58 <minimal> rootwyrm: if you've any other feedback regarding Alpine cloud-init let me know, I don't get any very often
2023-08-31 00:58:42 <rootwyrm> minimal: willdo, once I have the ansible migraines solved... most of the cloud-init on my amd64 stuff is so far from what anyone else would even _think_ about, it's not too useful. ;/
2023-08-31 09:30:57 <omni> what hardware is the riscv64 builder?
2023-08-31 09:31:18 <ikke> qemu-user
2023-08-31 09:31:27 <ikke> The host is x86_64
2023-08-31 09:32:15 <omni> also the package builder?
2023-08-31 09:32:21 <ikke> yes
2023-08-31 09:32:28 <omni> ah, thanks
2023-08-31 16:08:21 <ayakael> So upstream of dotnet are introducing support for building from source newer SDK bands starting with dotnet8. Thus, we have the option of packaging beyond dotnet8-8.0.1xx, like dotnet8-8.0.2xx. The problem is that. how they currently envision the build process breaks N+1. We would have to depend on externally sourced (i.e. from Microsoft) artifacts
2023-08-31 16:08:21 <ayakael> to bootstrap 8.0.2xx. It would always use our runtime, but would depend on externally-sourced bytecode when bootstrapping the new feature band.  Any thoughts on how much a deal breaker this is?
2023-08-31 18:31:54 <a16bitsysop> does anyone know what the difference between modet and __modet is, I think __modet is glibc specfic
2023-08-31 21:03:36 <ptrc> PureTryOut: okay to merge !50814?