2023-06-01 04:19:12 <psykose> ncopa: i hunted down and fixed both of the rootbld issues, one of which caused the issue in your case, so that riscv thing should work again :)
2023-06-01 08:46:59 <Newbyte> would you sort "aaa" before "a-a" in depends?
2023-06-01 08:47:09 <psykose> no
2023-06-01 08:47:16 <Newbyte> why not?
2023-06-01 08:47:37 <psykose> because that is not the sort order
2023-06-01 08:47:45 <Newbyte> what is the sort order?
2023-06-01 08:47:51 <psykose> vim :sort
2023-06-01 08:48:36 <psykose> which has - before all letters because of ascii order
2023-06-01 08:48:38 <psykose> not very fancy
2023-06-01 08:48:42 <Newbyte> nice, thank you
2023-06-01 08:48:43 <Newbyte> gnome builder even supports emulating that commands
2023-06-01 08:48:46 <Newbyte> didn't know about it
2023-06-01 08:48:52 <psykose> ok but who uses gnome builder
2023-06-01 08:49:02 <psykose> (laugh track plays)
2023-06-01 08:49:50 <psykose> similarly numbers go first too, it's really just ascii order afaik
2023-06-01 08:51:34 <Newbyte> I will keep using gnome builder and no one can stop me
2023-06-01 08:51:55 <Newbyte> (except pj if he makes Lapce good enough)
2023-06-01 08:52:29 <pj> inb4 fonts borked and some tiny teeny issue only psykose has
2023-06-01 08:54:37 <pj> Anyway I will be stepping down from everything I contribute to
2023-06-01 08:55:22 <psykose> one of those years eh
2023-06-01 08:57:23 <pj> yeah, kinda tired of the opensource bullshit
2023-06-01 08:58:09 <pj> From what I see I'll be having much more fun making some stuff privately and/or in very small groups of people
2023-06-01 09:04:12 <psykose> same tbh
2023-06-01 09:50:53 <omni> I noticed that curl doesn't do .onion lookups anymore, which I'm sure is a good thing in most cases but I'd like to be able to
2023-06-01 09:51:53 <omni> https://github.com/curl/curl/commit/0ae0abbe72514a75c10bfc4108d9f254f594c086 and https://github.com/c-ares/c-ares/commit/955df983d7f643d1b00aa433f31ca3ec7f86b4bd (since we now build curl with --enable-ares)
2023-06-01 09:52:48 <psykose> there's an extremely long discussion linked from that that says why and what you're supposed to do
2023-06-01 09:54:18 <psykose> https://github.com/curl/curl/issues/11111 to be specific i guess
2023-06-01 09:55:11 <psykose> since 2018 it would fail with --enable-ares yes, since 8.1 it fails regardless due to former commit as you noticed
2023-06-01 09:55:24 <pj> nice issue number
2023-06-01 09:56:10 <psykose> i see you commented in it even, so i'm not sure why you're bringing it up here, you can't turn this behaviour off since 8.1
2023-06-01 10:18:49 <omni> I know, just to make others with similar requirements aware I guess
2023-06-01 10:19:41 <omni> I'm not trying to get anyone to revert this anywhere
2023-06-01 10:26:50 <psykose> it is slightly unlucky it's not a toggle i suppose
2023-06-01 10:27:48 <psykose> that said curl supports like every socks type so idk why that's exactly difficult to do it correctly
2023-06-01 10:48:57 <psykose> >* strtok() and strtok_r() are banned in this codebase.
2023-06-01 10:51:00 <skarnet> <pj> From what I see I'll be having much more fun making some stuff privately and/or in very small groups of people
2023-06-01 10:51:10 <skarnet> I mean, duh?
2023-06-01 10:51:16 <skarnet> lightbulb moment here?
2023-06-01 10:51:43 <skarnet> that open source / free software
2023-06-01 10:51:56 <skarnet> oh, thanks keyboard
2023-06-01 10:52:31 <skarnet> that's orthogonal to open source / free software though, you *can* do opensource on your own or with very small groups of people :)
2023-06-01 10:52:44 <skarnet> and that's where it *thrives*
2023-06-01 10:53:11 <skarnet> so I'd encourage you to keep contributing to open source, in ways that work better for you.
2023-06-01 10:53:19 <pj> https://xkcd.com/1053/
2023-06-01 10:53:35 <skarnet> fair enough
2023-06-01 10:54:01 <psykose> parental moment
2023-06-01 10:54:04 <skarnet> (it has always been obvious to me, but not everyone can have my incrediblt insight)
2023-06-01 10:54:23 <pj> but I specifically have issue with "contributing" because that's the root of all evil
2023-06-01 10:54:24 <skarnet> (and not everyone can have my incrediblt typing skills either)
2023-06-01 10:55:21 <skarnet> then create your own stuff if you prefer, but it will take a while before you get something other people will want to use
2023-06-01 10:57:48 <pj> I actually prefer if people don't use my stuff :) it may not expand in functionality and other things but I have fun clicking buttons, compiler goes brr and I have fun stuff on screen
2023-06-01 10:59:24 <pj> psykose, mum of aports
2023-06-01 10:59:33 <skarnet> well yeah, that's the eternal problem with free software - people are in it for the fun, but we want to pretend it's actually useful and can replace proprietary
2023-06-01 11:00:01 <skarnet> so there's a tension between "I'm having fun doing this" and "I'm making it actually usable for others"
2023-06-01 11:00:32 <skarnet> case in point: I'm ranting here because I'm procrastinating on writing documentation, which I don't care about, but others do
2023-06-01 11:00:51 <ikke> part of the fun may be building something that is usefull for more than yourself
2023-06-01 11:00:57 <skarnet> exactly
2023-06-01 11:01:07 <skarnet> that's how the tension is solved sometimes
2023-06-01 11:01:54 <pj> I'm replying here because I'm procrastinating on writing documentation for work
2023-06-01 11:02:25 <skarnet> ^5
2023-06-01 11:04:09 <pj> I have fun stuff that I would like people to use and I contribute to such stuff but it always brings me down whenever I have to do "workaround X" because "historical reasons" or "design reasons" of other software
2023-06-01 11:04:41 <ikke> software rarely lives in a vacuum
2023-06-01 11:05:51 <pj> ikke: yeah but by limiting how many people know about it you can protect it from spreading
2023-06-01 11:06:12 <pj> e.g. I can have my project on GitHub or my private git instance, and that's a factor
2023-06-01 11:07:37 <ikke> yes, if your are just building it for yourself, you can do whatever you like
2023-06-01 11:08:05 <skarnet> yeah, having to jump through hoops to accommodate broken stuff designed and written by monkeys on crack is the most frustrating part of writing/integrating software, but that's not specific to open source
2023-06-01 11:08:19 <skarnet> it's *worse* in enterprise software
2023-06-01 11:08:30 <pj> it's equal in my experience
2023-06-01 11:09:45 <pj> the problem with open source is that when you have proprietary software, it's "old man shouts at corporation", with open source it's whole matrix/venn diagram/whatever of who did what when why and how
2023-06-01 11:10:46 <skarnet> a corporation is the same matrix/Venn diagram, you just don't see it because they erase individual contributions and stamp the Corporation logo all over it
2023-06-01 11:10:58 <skarnet> so you can't even *tell* who wrote what
2023-06-01 11:11:02 <pj> yes
2023-06-01 11:11:48 <pj> the blame is put on corporation, not specific people
2023-06-01 11:25:56 <psykose> it gets put on specific people all the time inside the corporation
2023-06-01 11:26:39 <psykose> from the outside sure
2023-06-01 11:33:14 <skarnet> that was true at some point, nowadays, when problems are spotted, the person responsible has long left for greener (or not) pastures :)
2023-06-01 12:57:44 <Habbie> psykose, what's the old-genned autoconf / python 3.1 story?
2023-06-01 12:57:58 <Habbie> psykose, is it taking 3.1x as 3.1?
2023-06-01 12:57:58 <psykose> old autoconf macro for python doesn't detect double digit python
2023-06-01 12:58:01 <psykose> yeah
2023-06-01 12:58:01 <Habbie> ack
2023-06-01 12:58:06 <psykose> well
2023-06-01 12:58:07 <psykose> 'old'
2023-06-01 12:58:14 <psykose> current release autoconf does that
2023-06-01 12:58:18 <Habbie> oh fun
2023-06-01 12:58:20 <psykose> every distro has it patched
2023-06-01 12:58:35 <psykose> that 'current release' is from multiple years ago
2023-06-01 12:58:38 <Habbie> FROM alpine:3.10 as pdns-authoritative
2023-06-01 12:58:40 <Habbie> oops
2023-06-01 12:58:42 <psykose> haha
2023-06-01 12:58:44 <Habbie> this is where we make tarballs
2023-06-01 12:58:51 <psykose> yeah might wanna bump that to 3.17 or higher
2023-06-01 12:58:54 <Habbie> yes
2023-06-01 12:58:55 <psykose> maybe 3.16 also had it patched
2023-06-01 12:58:56 <psykose> let me check
2023-06-01 12:59:12 <Habbie> any reason not to go for 3.18?
2023-06-01 12:59:19 <psykose> none i can think of
2023-06-01 12:59:22 <Habbie> wonderful
2023-06-01 12:59:29 <psykose> give it a try and find out
2023-06-01 12:59:33 <Habbie> will do, thanks for the pointer
2023-06-01 12:59:35 <psykose> let me know if you have any issues
2023-06-01 12:59:37 <Habbie> (and the merge)
2023-06-01 12:59:48 <psykose> actually doesn't seem to be directly in autoconf, maybe the macro was in python itself..
2023-06-01 13:00:22 <psykose> ah, autoconf-archiev
2023-06-01 13:00:25 <psykose> archive*
2023-06-01 13:00:30 <psykose> and it is in release, that one is more updated
2023-06-01 13:01:43 <psykose> that was fixed in v2022.09.03 which is in 3.17
2023-06-01 13:01:52 <Habbie> ok cool
2023-06-01 13:02:04 <psykose> https://github.com/autoconf-archive/autoconf-archive/commit/9b604b6ddeab75ad2ca53e686dc956298e2c5751 specifically
2023-06-01 13:02:22 <Habbie> ah
2023-06-01 13:02:33 <psykose> but yeah you generally want to make sure to use latest distro (or your own) autoconf with all the patches etc, because there is more stuff there
2023-06-01 13:02:39 <Habbie> definitely
2023-06-01 13:02:43 <psykose> like all the compile tests are invalid c23 and fail on clang16 and the like
2023-06-01 13:02:57 <Habbie> i've seen a few of those, in things we already copied from autoconf-archive
2023-06-01 13:08:51 <Habbie> i see we bumped from 3.6 to 3.10 in 2019, also for autoconf reasons :)
2023-06-01 13:09:03 <psykose> hehe
2023-06-01 13:13:57 <Habbie> 'nothing works' because this one script starts with #!/bin/bash - but how did it work on 3.10 then
2023-06-01 13:14:26 <psykose> transitive dep pulled bash
2023-06-01 13:14:31 <Habbie> good call
2023-06-01 13:15:53 <Habbie> it was libtool
2023-06-01 13:16:10 <psykose> yep
2023-06-01 13:16:12 <psykose> i was about to say that
2023-06-01 13:16:13 <psykose> :D
2023-06-01 13:16:45 <Habbie> hehe
2023-06-01 13:39:28 <Habbie> the tarball changed a bit more than i expected - because i forgot about bison, flex and ragel ;)
2023-06-01 17:30:16 <Newbyte> https://paste.centos.org/view/a1391ec3
2023-06-01 17:30:29 <Newbyte> Do you have any idea what frame #2 is supposed to mean?
2023-06-01 20:57:01 <Arnavion> Your stack seems to be busted. The fact that it says the syscall number is 0 in #1 is also bogus
2023-06-01 22:53:01 <Hello71> or your debug symbols don't match
2023-06-02 01:32:32 <litany> greetings, any maintainers lurking?
2023-06-02 01:32:50 <elly> there certainly are
2023-06-02 01:33:18 <litany> I see that xf86-video-freedreno is no longer being compiled for arm or armhf
2023-06-02 01:33:25 <litany> armv7 or armhf*
2023-06-02 01:34:04 <psykose> xf86-video-freedreno is not a thing
2023-06-02 01:34:21 <psykose> or rather has never been packaged that i know of
2023-06-02 01:34:41 <psykose> which makes sense as it was abandoned almost a decade ago
2023-06-02 01:34:49 <psykose> not sure what the "no longer" is about though :)
2023-06-02 01:35:24 <psykose> mesa itself has freedreno support if that's what you're thinking of?
2023-06-02 01:35:48 <litany> well, I am a bit confused about it
2023-06-02 01:35:51 <psykose> about what
2023-06-02 01:36:16 <litany> Since I am trying to get hardware acceleration on a APQ8084 board which uses the adreno 420 driver
2023-06-02 01:36:44 <psykose> sure, that's freedreno 420 or so
2023-06-02 01:36:47 <psykose> mesa has it enabled afaik
2023-06-02 01:36:58 <psykose> that's just mesa-dri-gallium, same as the rest
2023-06-02 01:37:02 <litany> mesa has support, they have turnip but the driver for anything below a6xx gpus sits in xf86-video-freedreno
2023-06-02 01:37:09 <litany> This is what I have read in the documentation
2023-06-02 01:37:13 <psykose> which documentation
2023-06-02 01:37:38 <psykose> mesa defines the gpus in src/freedreno/common/freedreno_devices.py
2023-06-02 01:37:49 <psykose> you can see GPUId(420) in there
2023-06-02 01:38:11 <litany> okay, let me check mesa-dri-gallium again as I remember the last time I investigated this months ago, the freedreno component wasn't compiled for it. Thanks for jogging my memory
2023-06-02 01:40:25 <psykose> freedreno vulkan was enabled around 3.16
2023-06-02 01:40:37 <psykose> freedreno opengl.. 3.7 6 years ago?
2023-06-02 01:40:55 <psykose> that said, that is just ""freedreno"" and not specifics of what gpuid was supported when
2023-06-02 01:41:56 <psykose> afaict it's been there for years
2023-06-02 01:42:03 <psykose> you probably had an issue unrelated to mesa support or not
2023-06-02 01:42:50 <psykose> xf86-video-freedreno (not something you would even want, to be clear) is also only 3xx and lower, not 420
2023-06-02 01:43:06 <psykose> by their own 10 year old manpage anyway
2023-06-02 01:43:23 <psykose> ie not APQ8084 but rather 8x74
2023-06-02 01:43:36 <psykose> but that's separate and for xorg gl regardless
2023-06-02 01:47:00 <litany> I am sure I read it has 420 support
2023-06-02 01:47:48 <litany> https://gitlab.freedesktop.org/freedreno/freedreno/-/wikis/Status
2023-06-02 01:49:10 <psykose> that's not xf86-video-freedreno
2023-06-02 01:49:28 <psykose> i actually have no idea what that is tbh
2023-06-02 01:54:06 <psykose> ah
2023-06-02 01:54:15 <psykose> it's a standalone part of freedreno split out from mesa or whatever
2023-06-02 01:55:20 <psykose> yeah all these docs are extremely ancient
2023-06-02 01:56:02 <psykose> and seem to contradict themselves with the package they link to
2023-06-02 01:56:17 <psykose> that said you should probably focus on your actual issue and not old history
2023-06-02 01:56:42 <litany> **blind and feeling around for some code to compile**
2023-06-02 01:57:17 <litany> just trying to find a way to restore basic 3D acceleration
2023-06-02 01:57:47 <litany> I agree, it still serves as a good reference point for figuring it out
2023-06-02 01:57:54 <psykose> 'restore' needs more context, as here nothing changed for it, and the xf86 thing never existed
2023-06-02 01:57:59 <psykose> that said i have no idea what it needs or not
2023-06-02 01:58:08 <psykose> you can ask pmos since they work with these arm gpus all the time
2023-06-02 01:58:28 <litany> I remember finding the issue before but not following through due to more pressing matters, I think it was just that one of the dri.so files for it was not compiled
2023-06-02 01:59:03 <psykose> no, all of those are enabled
2023-06-02 01:59:10 <psykose> unless you remember the name for me to check to make sure
2023-06-02 01:59:58 <litany> I say 'restore' because it use to be working when I was using the driver years ago for a short stint 
2023-06-02 02:01:12 <litany_> apologies, dc
2023-06-02 02:01:58 <litany_> thank you very much for the clarification
2023-06-02 02:03:32 <litany_> this narrows it down
2023-06-02 02:46:59 <litany> might be this, https://gitlab.freedesktop.org/mesa/mesa/-/issues/8856
2023-06-02 02:48:18 <psykose> aha
2023-06-02 02:48:34 <psykose> so that would imply it was just never functional, though perhaps pmos may or may not have had something special
2023-06-02 02:48:44 <psykose> hm
2023-06-02 02:48:51 <psykose> vulkan turnip works? interesting
2023-06-02 02:49:03 <psykose> assuming that is supported ok you could also use zink with it :D
2023-06-02 02:50:32 <litany> pmos, does not. It is where I am coming from, swimming upstream
2023-06-02 02:51:56 <litany> There are some special work arounds but I rather add my efforts where it can mend this bridge in one place
2023-06-02 02:52:40 <litany> and those workarounds are probably just vendor binaries
2023-06-02 02:53:16 <litany> vulkan turnip only works for A6xx and up
2023-06-02 02:54:55 <psykose> then you have nothing to do i guess until the finish the above
2023-06-02 02:57:29 <litany> well, I shall use the solution provided that and verify it works for this hardware
2023-06-02 02:57:34 <litany> provided there*
2023-06-02 03:10:59 <litany> okay, I see the naming is all under the umbrella of msm for mainline
2023-06-02 03:11:24 <litany> qualcomms umbrella
2023-06-02 03:50:58 <litany> bbl
2023-06-02 09:27:32 <adhawkins> Just spotted one of my python packages doesn't install correctly due to a missing dependency. Is there any way in the 'check' function to check the built package has pulled in the correct dependencies? I guess running the built 'binary' would do it, but looking at the directory structure it only ends up in the 'pkg' directory.
2023-06-02 09:27:46 <adhawkins> Any way to refer to that in the APKBUILD check function? 
2023-06-02 09:28:31 <adhawkins> Can I assume that something like '$pkgdir/usr/bin/borg_space' will work?
2023-06-02 09:31:23 <adhawkins> Ah, looks like the pkgdir might have been removed by the time 'check' is called? Or perhaps not been created yet?
2023-06-02 09:38:17 <adhawkins> Ok, seems I can run the 'main' function from the apps module from the command line, but sadly that exits with an error as it can't find config files and the like. Oh well, I'll just be more careful with monitoring dependencies in future.
2023-06-02 11:56:50 <dzilvys> So I have a GCC question maybe y'all can give me some place to look at. Using g++ (Alpine 8.3.0) 8.3.0, the https://github.com/open-source-parsers/jsoncpp lib compiles correctly. However, on g++ (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924, it fails to compile with the following error
2023-06-02 11:56:50 <dzilvys> inlined from 'bool Json::Reader::readValue()' at /home/build_agent/work/7dda5c4a5af7ded9/thirdparty/jsoncpp/jsoncpp.cpp:435:31:
2023-06-02 11:56:50 <dzilvys>   /usr/include/c++/12.2.1/bits/move.h:205:7: error: 'v' may be used uninitialized [-Werror=maybe-uninitialized]
2023-06-02 11:56:50 <dzilvys> 11:34:50 
2023-06-02 13:30:04 <orbea> dzilvys: remove -Werror
2023-06-02 13:32:54 <dzilvys> orbea: Is there any other alternative?
2023-06-02 13:54:57 <orbea> dzilvys: make sure v is initialized, but given its in gcc idk how easy that would be
2023-06-02 13:55:50 <orbea> removing -Werror is much easier and projects shouldn't be settig -Werror by default anyways, its like saying "this is only supported on my compiler"
2023-06-02 14:01:32 <MSER> hlo a bug in acf how can I submit it?
2023-06-02 14:02:51 <MSER> Fri Jun  2 15:13:53 2023: Exception: attempt to use a closed file
2023-06-02 14:02:51 <MSER>         [C]: in ?
2023-06-02 14:02:51 <MSER> stack traceback:
2023-06-02 14:02:51 <MSER>         [C]: in function 'call_capture'
2023-06-02 14:02:54 <MSER>         (...tail calls...)
2023-06-02 14:02:56 <MSER>         [C]: in function 'xpcall'
2023-06-02 14:02:58 <MSER>         [string "acf"]:18: in main chunk
2023-06-02 14:06:07 <MSER> alpine release 3.18
2023-06-02 14:06:22 <MSER> but exist also in 3.17
2023-06-02 14:06:48 <MSER> seems linked to stdout but unable to find it
2023-06-02 14:07:03 <MSER> thanks for your help
2023-06-02 14:14:26 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/14986
2023-06-02 14:22:04 <MSER> Thanks a lot, seems this problem.
2023-06-02 19:14:59 <psykose> orbea: that's not "in gcc", it's an expanding thing from the code afaik (the code is wrong and the final error looks like it's "in gcc")
2023-06-02 19:15:27 <psykose> ikke: if it's also in 3.17 then it's not that, funnily
2023-06-02 19:15:48 <ikke> OH, I missed that
2023-06-02 19:19:01 <psykose> annoyingly the arm builders being dead means that is broken until they're back on 3.18
2023-06-02 20:13:14 <dalias> is there no linux-edge for arm ?
2023-06-02 20:13:34 <dalias> or rather aarch64
2023-06-02 20:14:06 <dalias> i found the eth doesn't work on my potato in 6.1 (but i have a dongle i can use instead anyway) and 6.3 supposedly has the fix :-p
2023-06-02 20:14:23 <dalias> well not supposedly. based on my reading of the git log, i believe the changes would fix it :)
2023-06-02 20:36:18 <psykose> there is
2023-06-02 20:36:44 <psykose> that's maintained by mps though so i'm not touching anything in the config there
2023-06-02 20:36:48 <psykose> you'd have to open an issue and ask
2023-06-02 20:37:16 <sam_> lol
2023-06-02 22:20:30 <dalias> psykose, i don't even see the apk file
2023-06-02 22:20:42 <psykose> how are you looking
2023-06-02 22:21:11 <dalias> i was browsing edge on dl-cdn via web, and also apk search linux-edge after adding @edge repo
2023-06-02 22:21:14 <Habbie> dalias, echo $potato (just curious, no intention of being a useful debugging help)
2023-06-02 22:21:25 <psykose> apk --print-arch
2023-06-02 22:21:44 <dalias> # apk --print-arch
2023-06-02 22:21:44 <dalias> aarch64
2023-06-02 22:21:51 <psykose> well
2023-06-02 22:22:05 <psykose> idk what 'added @edge' means but it's in 3.18/community and edge/community
2023-06-02 22:22:16 <dalias> ohh community not main
2023-06-02 22:22:17 <dalias> ok
2023-06-02 22:22:51 <dalias> but if it doesn't yet have the meson platform stuff it won't be useful anyway
2023-06-02 22:22:59 <dalias> i'll just wait and use dongle for now
2023-06-02 22:24:21 <psykose> afaict it's already enabled
2023-06-02 22:24:27 <psykose> someone asked before and tested it
2023-06-02 22:28:43 <dalias> ohhh ok
2023-06-02 22:28:46 <dalias> then i should use it
2023-06-02 22:29:35 <dalias> i'll give it a try
2023-06-02 22:29:56 <dalias> by @edge i mean i added a tagged repo for edge to my apk repositories file so i could grab kernel only without moving to edge
2023-06-02 22:30:21 <Habbie> psykose, and the cookies fortune
2023-06-02 22:31:05 <Habbie> ( https://duckduckgo.com/?q=dude+where%27s+my+car+and+then+quotes&t=ftsa&ia=web )
2023-06-02 22:32:13 <psykose> so true
2023-06-02 22:32:17 <Habbie> :)
2023-06-02 22:38:33 <Habbie> psykose, i suppose that glibc thing can be made to work besides musl for entirely distinct things? (it's clear to me that php extensions are not "entirely disticnt" from eachother) :)
2023-06-02 22:39:58 <psykose> emphasis on entirely distinct
2023-06-02 22:40:16 <Habbie> indeed
2023-06-02 22:40:21 <psykose> so distinct that it's functionally equivalent to putting it in a chroot, just on the same /
2023-06-02 22:40:28 <psykose> i.e. there's no point
2023-06-02 22:40:31 <psykose> idk why anyone does it
2023-06-02 22:40:33 <Habbie> i remember debian shipping two libcurl versions in 10 or something, so much pain
2023-06-02 22:40:55 <Habbie> or was it two openssls.. one i got via curl, one via mysql, something like that
2023-06-02 22:42:33 <Habbie> meanwhile, here's a fun thing to know, haiku's libc (that they call libroot) is in fact a combination of glibc and musl :D
2023-06-02 22:43:03 <Habbie> (plus some other stuff)
2023-06-02 22:56:30 <dalias> i think putting isolated things in a chroot type install with glibc might make sense
2023-06-02 22:56:35 <Habbie> yes
2023-06-02 22:56:39 <dalias> if your goal is to have a simple system taking care of system-level stuff
2023-06-02 22:56:51 <dalias> but you need to run some very glibc-ism applications
2023-06-02 23:04:48 <psykose> these days flatpak solves that niche pretty well as a low effort solution
2023-06-02 23:04:58 <psykose> since most of the 'very glibc' applications made a flatpak
2023-06-02 23:05:00 <dalias> to me, the value of having alpine or a system with musl & no systemd isn't "everything is using musl" or "there's no glibc". it's "i know the core stuff managing the system isn't glibc+systemd"
2023-06-02 23:05:38 <dalias> i need to figure out how flatpak works and whether it's okay as-is or needs better containerization
2023-06-02 23:06:03 <psykose> the security aspect is mostly "lmao"
2023-06-02 23:06:18 <psykose> it's just easy application containerisation in the sense of you get to run "that glibc using thing"
2023-06-02 23:06:28 <Habbie> i recently found out appimage cares about glibc version, is all i know
2023-06-02 23:06:33 <Habbie> (appimage is not flatpak, of course)
2023-06-02 23:06:37 <psykose> the obvious usecase for me is running steam for instance
2023-06-02 23:06:42 <dalias> psykose, does it need root? :-p
2023-06-02 23:06:45 <psykose> never had any issues with the flatpak part of it specifically
2023-06-02 23:06:49 <psykose> dalias: no, it's userns
2023-06-02 23:06:52 <psykose> via bwrap
2023-06-02 23:06:58 <dalias> doesn't bwrap need root?
2023-06-02 23:07:03 <psykose> no, it's userns
2023-06-02 23:07:14 <dalias> iirc it did because it wanted multi users or something
2023-06-02 23:07:17 <psykose> there's a suid bwrap mode to not use userns in general if that's what you mean
2023-06-02 23:07:28 <psykose> but it uses userns with no suid anywhere just fine
2023-06-02 23:08:07 <psykose> yeah, multi-users stuff can't be done with userns but i don't remember when bwrap needed that (hasn't for as long as i remember in my use)
2023-06-02 23:08:21 <psykose> through flatpak that is
2023-06-02 23:09:15 <psykose> ah, right, it's not bwrap inherently that needs that, just things that might need it would need it to be suid, yes
2023-06-02 23:09:31 <psykose> (not flatpak)
2023-06-02 23:11:07 <psykose> there's actually an abuild issue related to that, because in the same vein you can't have multiple groups without suid mode
2023-06-02 23:11:33 <psykose> so abuild rootbld with pkggroups=/pkgusers= doesn't work as the bldroot can't have multiple groups/users added to it, etc
2023-06-02 23:11:44 <psykose> unless you suid'd the executable (we don't_
2023-06-03 00:48:32 <Hello71> isn't that bedrock linux
2023-06-03 07:51:57 <Newbyte> would apk's functionality be affected in any way if you disable apk's cache?
2023-06-03 07:52:54 <ikke> you mean /etc/apk/cache, correct?
2023-06-03 07:53:09 <ikke> (given your poll on masto)
2023-06-03 07:53:18 <Newbyte> yes
2023-06-03 07:53:24 <ikke> It's perfectly fine to have it disabled
2023-06-03 07:53:47 <Newbyte> ikke: I assume you meant /var/cache/apk?
2023-06-03 07:53:58 <Newbyte> or … is this some flag to disable it?
2023-06-03 07:54:11 <ikke> There is the apkindex cache, and the package cache
2023-06-03 07:54:24 <ikke> I assume you meant the latter
2023-06-03 07:54:55 <Newbyte> Isn't /var/cache/apk where the apks are stored?
2023-06-03 07:55:11 <ikke> Newbyte: that's controlled by where /etc/apk/cache is pointing to
2023-06-03 07:55:19 <Newbyte> oh, I see now. thanks
2023-06-03 07:55:26 <psykose> the default is disabled
2023-06-03 07:55:27 <ikke> and by removing that symlink, you disable it
2023-06-03 07:55:41 <psykose> effectively all it does is readlink /etc/apk/cache and write to it
2023-06-03 07:55:51 <Newbyte> psykose: really? 🤔guess pmOS must be enabling it by default somehow
2023-06-03 07:55:55 <psykose> yeah, you do
2023-06-03 07:56:15 <psykose> tbf you always want it generally for most long-life usecases, just needs a bit of pruning
2023-06-03 07:56:31 <Newbyte> but why do you want it? what's the use-case?
2023-06-03 07:56:37 <qaqland[m]> default apk update is not use
2023-06-03 07:56:46 <ikke> qaqland[m]: this is not about apk update
2023-06-03 07:56:47 <Newbyte> is it just to downgrade apks if they have problems?
2023-06-03 07:57:11 <ikke> that's one usecase, the other (most making sense for builders) is to speed up installing dependencies
2023-06-03 07:57:18 <psykose> you can add a .apk directly from it to downgrade, it speeds up any transactions that add/remove stuff that would've been in cache for a little disk
2023-06-03 07:57:37 <Newbyte> I mean, it's nice to have I guess, but it's not so nice when it eats up multiple gigabytes of disk space
2023-06-03 07:57:38 <psykose> i guess it's not super common since most people don't add/remove stuff perpetually when using it
2023-06-03 07:57:50 <Newbyte> so I think it at least needs to be better managed
2023-06-03 07:57:55 <ikke> setup-alpine does not enable it by default
2023-06-03 07:57:57 <Newbyte> not for Alpine generally, but pmOS
2023-06-03 07:58:00 <psykose> the management tools are fine
2023-06-03 07:58:12 <ikke> (except for run-from-ram systems, where it's necessary)
2023-06-03 07:58:36 <Newbyte> psykose: is there any tool that automatically cleans it up on a regular basis?
2023-06-03 07:58:53 <ikke> Newbyte: cron + apk cache clean
2023-06-03 07:59:08 <psykose> you already know the answer i think
2023-06-03 07:59:17 <Newbyte> psykose: is the answer cron?
2023-06-03 07:59:57 <psykose> the answer is anything that does stuff 'on a regular basis'
2023-06-03 08:00:01 <Newbyte> the problem with just running a cache clean command via cron is that it doesn't consider how old the apks are. ideally you would only remove ones older than a month or something like that
2023-06-03 08:00:33 <psykose> cache clean only removes things not in index
2023-06-03 08:00:33 <Newbyte> since otherwise the cache is very unpredictable
2023-06-03 08:01:00 <Newbyte> but that doesn't consider the "I want to downgrade some apk" use-case
2023-06-03 08:01:14 <Newbyte> right?
2023-06-03 08:01:40 <ikke> there is nothing in apk for that usecase
2023-06-03 08:01:41 <psykose> it's not a possible usecase to consider in this context
2023-06-03 08:01:45 <ikke> so if you want that, you have to build something
2023-06-03 08:01:54 <Newbyte> psykose: why do you say that?
2023-06-03 08:02:07 <psykose> how would it know? the information doesn't exist
2023-06-03 08:02:20 <Newbyte> psykose: file creation timestamp?
2023-06-03 08:02:56 <psykose> that's not useful for the downgrade usecase at all?
2023-06-03 08:03:10 <psykose> i think you haven't really thought about it
2023-06-03 08:03:23 <Newbyte> that's possible. but why do you say that?
2023-06-03 08:03:51 <psykose> there's no way to have a magic cache that has exactly the things you want and none of the things you don't want
2023-06-03 08:03:55 <Newbyte> my thinking is that if the apk is more than one month old, your "downgrade window" has elapsed
2023-06-03 08:04:12 <psykose> you can do that in cron
2023-06-03 08:04:18 <psykose> file older than one month -> delete
2023-06-03 08:04:43 <Newbyte> yeah, that's what I was thinking. a daily cron job that deletes files older than one month
2023-06-03 08:04:58 <Newbyte> feels like the best compromise to me
2023-06-03 08:05:55 <Newbyte> of course, this has the issue of potentially removing apks that still are in the index, but I don't think that's a big deal?
2023-06-03 08:06:04 <ikke> no
2023-06-03 08:06:14 <psykose> none of the files in the cache matter really
2023-06-03 08:37:19 <Newbyte> so something like find /etc/apk/cache/*.apk -mtime +31 -exec rm {} \; run on a daily basis would probably be fine?
2023-06-03 08:37:53 <Newbyte> or, am I missing something? should I be doing something with the cached indices too?
2023-06-03 08:37:58 <psykose> \+
2023-06-03 08:38:01 <ikke> find /etc/apk/cache -name '*.apk' -mtime +31 -exec rm {} \;
2023-06-03 08:38:04 <ikke> oh yeah
2023-06-03 08:38:07 <ikke> find /etc/apk/cache -name '*.apk' -mtime +31 -exec rm {} +
2023-06-03 08:38:15 <Newbyte> why the +?
2023-06-03 08:38:22 <psykose> batches args on same exec
2023-06-03 08:38:27 <abby> so it execs rm once
2023-06-03 08:38:30 <Newbyte> oh I see. nice
2023-06-03 08:38:36 <psykose> or twice if it's extra spicy
2023-06-03 08:38:40 <psykose> up to arglimit
2023-06-03 08:40:51 <psykose> also that doesn't work pretty sure (-mtime +31)
2023-06-03 08:41:28 <Newbyte> psykose: why is that?
2023-06-03 08:41:36 <psykose> you tell me
2023-06-03 08:42:09 <Newbyte> no, I don't know anyhting
2023-06-03 08:42:14 <psykose> ah, you need /etc/apk/cache/
2023-06-03 08:42:26 <psykose> otherwise it doesn't read the symlink at all
2023-06-03 08:44:49 <psykose> also i think the times aren't necessarily local
2023-06-03 08:45:50 <psykose> you want ctime i think?
2023-06-03 08:46:18 <psykose> https://img.ayaya.dev/IQxg038Cweob
2023-06-03 08:46:19 <psykose> (just added)
2023-06-03 08:46:27 <psykose> otherwise you're getting the mirror times
2023-06-03 08:47:15 <psykose> hmm
2023-06-03 08:47:29 <psykose> not that either
2023-06-03 08:48:53 <psykose> not sure how to actually find that magic time
2023-06-03 08:49:14 <Newbyte> psykose: what's the issue with changed time?
2023-06-03 08:50:11 <psykose> you're getting the mirror dates and local ones, idk
2023-06-03 08:50:21 <psykose> i.e. i can delete something from the cache
2023-06-03 08:50:23 <psykose> install it again
2023-06-03 08:50:30 <psykose>  -mtime +900 
2023-06-03 08:50:32 <psykose> it still matches
2023-06-03 08:51:02 <psykose> i don't remember how to get 'older than xyz but local fs time only' time
2023-06-03 08:54:04 <Newbyte> that's annoying, but thanks
2023-06-03 09:02:12 <psykose> it's not just annoying, rather it makes this idea not work
2023-06-03 09:02:20 <psykose> but it's possible somehow, i just don't remember the specifics
2023-06-03 09:02:25 <psykose> someone else probably knows
2023-06-03 11:08:21 <lotheac> psykose: you might be thinking of file creation time aka crtime, which is not that commonly even recorded (depends on fs) and pretty unportable
2023-06-03 11:08:46 <psykose> yeah, something like that
2023-06-03 11:08:57 <lotheac> mtime is usually the best you can do, but as you noticed it's kinda unreliable because things like rsync will modify it :)
2023-06-03 11:09:08 <psykose> yeah
2023-06-03 11:09:17 <psykose> which leads to my next question:
2023-06-03 11:09:39 <psykose> this seems like a really basic thing, and not having a crtime makes it entirely impossible for anything non-purely-local
2023-06-03 11:09:55 <psykose> why computers bad?
2023-06-03 11:10:21 <lotheac> ultimately, because people bad
2023-06-03 11:10:34 <psykose> tangentially it reminds me of stat 'file birth' which needs statx or something
2023-06-03 11:10:46 <psykose> separate to the fs recording it or not
2023-06-03 11:10:51 <lotheac> that might be another name for the same-ish thing
2023-06-03 11:10:55 <psykose> yea
2023-06-03 11:11:20 <psykose> and musl still don't got a statx implementation in 2023
2023-06-03 11:11:33 <psykose> maybe next year we'll get em
2023-06-03 11:26:17 <Hello71> -atime is probably better for cache pruning anyways?
2023-06-03 11:26:48 <ikke> then you have to enable atime on the fs
2023-06-03 11:27:19 <psykose> 'noatime' is such a commonly used option that sadly isn't really a portable thing at this point tbh :p
2023-06-03 11:35:29 <Hello71> I guess use -ctime then
2023-06-03 11:37:03 <Hello71> if you use noatime then it's deleted 30 days after download, otherwise it's deleted 30 days after last use
2023-06-03 11:37:58 <Hello71> also is there any case where noatime has any advantage over relatime
2023-06-03 11:38:24 <psykose> even less random writes? idk
2023-06-03 11:38:35 <psykose> also when i just tried ctime it didn't work pretty sure
2023-06-03 11:38:37 <psykose> on btrfs anyway
2023-06-03 11:43:47 <lotheac> ctime is pretty useless
2023-06-03 11:45:02 <lotheac> essentially it's just last chmod() time
2023-06-03 11:48:44 <psykose> the easy test i was doing is to just delete a file and reget it from http cache
2023-06-03 11:48:56 <psykose> and it kept still getting picked up by -ctime +500 or anything else
2023-06-03 12:01:04 <Hello71> hm, I thought ctime was updated when atime is updated, but I think it's only updated when mtime is updated
2023-06-03 16:58:33 <Habbie> Hello71, if atime updated ctime, we wouldn't need atime ;)
2023-06-03 17:01:44 <Hello71> hm...
2023-06-03 17:02:53 <Habbie> actually maybe i'm thinking too narrowly about usecases
2023-06-03 17:20:35 <Hello71> ctime could be newer than atime
2023-06-03 17:20:54 <Hello71> i don't know if that's how it actually works though
2023-06-03 17:35:57 <Habbie> atime could certainly be newer than ctime
2023-06-05 03:42:12 <psykose> nmeum: what do you think about https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6f0eb99c9bda726f953bdbe06dd3489a26af2823 ? not entirely sure what we have to undo from that for the riscv multilib fix
2023-06-05 03:53:59 <vhns> Hi. Is there any reason for dnstap to be disabled in the `unbound` package? If not, can I submit a patch to enable it?
2023-06-05 07:53:24 <ncopa> good morning
2023-06-05 12:59:53 <ducktype> andypost[m]: hi andy, i've found something strange in the php82 package, seems that the executable has RPATH set to [/lib:/usr/lib/x86_64-linux-gnu] so i'm using patchelf to remove it for now ... i've searched a bit on how to modify the package build scripts to remove it but i was not able to find a solution
2023-06-05 13:09:25 <ncopa> seems like php81 also has it
2023-06-05 13:09:56 <ncopa> ducktype: can you please report an issue for it?
2023-06-05 13:10:04 <ncopa> create an issue I mean
2023-06-05 13:10:29 <psykose> already fixed https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47801
2023-06-05 13:10:59 <ncopa> awesome
2023-06-05 13:11:01 <ncopa> thanks!
2023-06-05 13:15:48 <ducktype> psykose: cool thank you, forget my merge request then https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47802/diffs?commit_id=f0a97a1507abe3ec0afa1150dcb6f44ca83df71b
2023-06-05 13:16:32 <psykose> indeed, you missed the other half of the changes
2023-06-05 13:16:37 <psykose> that's why you generally open issues instead :p
2023-06-05 13:17:02 <ducktype> psykose: sorry :9 i was trying to be smart
2023-06-05 15:48:32 <andypost[m]> ducktype, psykose: thank you merged
2023-06-05 16:21:13 <Arnavion> We don't want to update even master to gtk4.0 to v4.$odd releases, right?
2023-06-05 16:21:46 <Arnavion> s/master to/master's/
2023-06-05 16:23:11 <psykose> yes
2023-06-05 16:23:34 <psykose> edge is edge but not something like an other-distro 'unstable'
2023-06-05 16:24:02 <psykose> so the usual odd-version stuff is 'no' without some requisite reason
2023-06-05 16:24:22 <psykose> e.g. during the libsoup3 mess one thing had to be to work at all
2023-06-05 16:25:01 <Arnavion> Aye aye
2023-06-05 17:38:13 <Ariadne> is it a known issue that aarch64 still has openssl 3.1.0-r5?
2023-06-05 17:38:28 <ikke> Ariadne: it is a known issue that the builders unreachable
2023-06-05 17:38:40 <Ariadne> ouch
2023-06-05 17:40:47 <ikke> ETA we've been given is aroun wednesday
2023-06-05 18:02:58 <Ariadne> ouch
2023-06-05 22:33:12 <craftyguy> did someone already explain somewhere about what happened to the aarch64 builders (why they are unreachable)? If not, no big deal. I'm just curious
2023-06-05 22:33:27 <pj> thingy not worky
2023-06-05 22:34:38 <craftyguy> no shit :P
2023-06-05 22:34:51 <pj> does it matter why
2023-06-05 22:35:44 <craftyguy> it matters to someone, probably. but as I said, I'm just curious. Ideally this wouldn't happen.
2023-06-05 22:35:48 <psykose> craftyguy: the networking went poof at the host for the way it's set up for us
2023-06-05 22:36:12 <psykose> iirc some loop thing but i don't think there's more details
2023-06-05 22:36:17 <craftyguy> ah ok, bummer.
2023-06-05 22:36:31 <pj> psykose: why did you break dl-5
2023-06-05 22:36:34 <psykose> might be back in 1.5 days
2023-06-05 22:40:29 <craftyguy> np, good luck getting things running again. 
2023-06-05 22:41:04 <psykose> it has indeed been a week
2023-06-05 22:41:05 <psykose> annoying
2023-06-05 22:44:36 <pj> building go with meson, cursed...
2023-06-06 13:12:22 <dalias> should the "configuring networking" wiki be updated to include instructions on how to fix nuking of resolv.conf?
2023-06-06 13:12:52 <dalias> it seems like there are 3+ different approaches you have to do depending on which dhcp client you're using, whether you have resolvconf installed, etc.
2023-06-06 13:12:58 <dalias> and the behaviors are all inconsistent :-p
2023-06-06 13:13:30 <dalias> i mean ideal would be making it consistent (consistently using ::1 :) but short of that it should be documented
2023-06-06 13:49:48 <dalias> any idea why package for newlib is explicitly building for a broken abi?
2023-06-06 13:51:08 <ncopa> d
2023-06-06 13:51:26 <ncopa> dalias: its a wiki, feel free to help fix it
2023-06-06 13:51:34 <dalias> :)
2023-06-06 13:51:56 <ncopa> no idea why newlib is buildin broken abi
2023-06-06 13:52:54 <ncopa> i wonder if we should have an "official" documentation for network config, but I'm not sure how that should be
2023-06-07 16:25:30 <ikke> Upgrading gitlab in 5 minutes, it will be briefly unavailable
2023-06-07 16:33:32 <ikke> gitlab is available again
2023-06-07 21:34:05 <psykose> sam_: how does the gentoo iptables(+nftables) thing work? the iptables.initd service doesn't seem to actually function with nftables unless i missed something
2023-06-07 21:34:53 <psykose> for reference https://gitlab.alpinelinux.org/alpine/aports/-/issues/15002
2023-06-08 12:57:13 <sam_> lemme wake up then will look
2023-06-08 14:57:52 <psykose> i just got woken up by a fire alarm, highly recommended
2023-06-08 14:58:41 <skarnet> yeah that one's up there
2023-06-08 14:58:55 <skarnet> drills and hammers are still better, I think
2023-06-08 14:59:47 <skarnet> (was it a real alarm? was it actually useful in that you escaped a fire?)
2023-06-08 15:04:01 <psykose> i've never had a real fire alarm no
2023-06-08 15:04:11 <psykose> 50/50 between "random people smoked weed indoors" and "drill"
2023-06-08 15:04:35 <psykose> drill as in a fake alarm not like.. drilling
2023-06-08 15:05:50 <skarnet> yeah, it's a mixed blessing
2023-06-08 15:06:00 <minimal> psykose: https://www.redbubble.com/i/t-shirt/THIS-IS-NOT-A-DRILL-1-by-HAUNTERSDEPOT/39876151.IJ6L0
2023-06-08 15:06:03 <skarnet> between "I got woken up for nothing" and "yay, no fire"
2023-06-08 15:20:06 <psykose> minimal: lol
2023-06-08 15:20:14 <psykose> skarnet: yeah, but i had a cute dream :(
2023-06-08 15:22:55 <skarnet> oh it definitely sucks
2023-06-08 15:49:53 <bl4ckb0ne> did it involved romance with the arm builder
2023-06-08 15:52:04 <psykose> nope
2023-06-08 17:53:32 <skarnet> "I'm more into arm breakers"
2023-06-08 21:43:38 <ptrc> <
2023-06-08 21:43:38 <ptrc> $ apk version -t '1' '1.0'
2023-06-08 21:44:03 <ptrc> ..is 1 less than 1.0 in terms of apk versioning?
2023-06-08 21:46:16 <psykose> yes
2023-06-08 21:46:31 <psykose> (you answered that yourself)
2023-06-08 21:47:57 <ptrc> no, like
2023-06-08 21:48:02 <ptrc> in the implementation, yes
2023-06-08 21:48:07 <ptrc> but i'm asking about the specification
2023-06-08 21:48:45 <ptrc> ( surely, it's not a case of "whatever the implementation says is correct", right? ....right? )
2023-06-08 21:49:13 <psykose> what specification
2023-06-08 21:53:19 <ptrc> oh no
2023-06-08 21:55:10 <ptrc> as a side note, it's always lovely to find stuff like this: https://medium.com/@devalias/i-dont-believe-they-delete-the-old-versions-so-much-as-the-newer-version-of-alpine-eg-63d18daae710
2023-06-08 21:56:58 <abby> 🤦‍♀️
2023-06-09 00:34:33 <andypost[m]> How to add secfix which looks like GHSA-76gg-c692-v2mw or better to wait for CVE?
2023-06-09 00:35:38 <psykose> don't have to
2023-06-09 00:36:42 <psykose> especially if it's version-fixed (everything tracked like that normally correctly marks fixed versions so just upgrading works, because the cve data will later have <=x.y.z affected, and our db will have it fixed even with no marking)
2023-06-09 00:37:08 <psykose> i haven't seen many ghsa-* that didn't mark a fixed version, so it's only relevant if you're manually patching
2023-06-09 00:48:00 <andypost[m]> thank you, good to know! just faced first time in current php releases (announced as security release) but no CVE yet
2023-06-09 00:50:49 <psykose> yeah that's definitely going to be marked as fixed in X so there's no need to add anything
2023-06-09 08:23:41 <omni> weird, now localmount fail to mount the first of two zvol snapshots in my fstab at boot but I can mount it after logging in no problem
2023-06-09 08:30:12 <psykose> how recent? (i.e. compared to upgrades)
2023-06-09 08:30:29 <psykose> my guess would be zfs or new util-linux mount stuff
2023-06-09 08:57:39 <adhawkins> I'm updating one of my packages, which has a new check dependency. I've added a commit to add this new dependency package, but when I run either dabuild or the alpine CI stuff on the upgraded package, it can't find the new one. Am I doing something wrong?
2023-06-09 08:57:53 <adhawkins> Or does the new package have to be merged before I can sort out the upgrade?
2023-06-09 09:00:08 <adhawkins> The CI stuff is realising it has to build both packages, but is building the upgraded package before the new one.
2023-06-09 09:00:47 <ikke> adhawkins: is the new package in testing?
2023-06-09 09:01:15 <ikke> If the package that needs it is in community or main, it has to be directly added in the same repository 
2023-06-09 09:01:45 <adhawkins> No. I think I've spotted the issue, there is no 'arch' line in the new package. So when the CI stuff tries to build it, it says there is no package for x86.
2023-06-09 09:02:26 <psykose> that just means it gets skipped entirely
2023-06-09 09:02:34 <adhawkins> Yes, I realise that now :)
2023-06-09 09:35:47 <adhawkins> I'm adding a new python package that's using setup.py. The 'build' line I'm using is '	python3 -m build --wheel', and the package is 'python3 -m installer -d "$pkgdir" dist/re_assert-$pkgver*.py3-none-any.whl'
2023-06-09 09:36:03 <adhawkins> However, it's failing to generate the pyc sub package. What's needed to make this work?
2023-06-09 09:36:13 <psykose> just open the mr and i'll fix it
2023-06-09 09:36:49 <adhawkins> Not quite ready for that yet psykose, as I'm only adding this package to support the next version of a package it depends on.
2023-06-09 09:36:59 <adhawkins> Would like to understand what's needed to fix it for future reference if possible.
2023-06-09 09:37:19 <psykose> i can't tell you because i don't see the apkbuild
2023-06-09 09:37:27 <psykose> answering the questions needs me to ask another 10 questions
2023-06-09 09:37:47 <adhawkins> Heh, Ok. This is the apkbuild if it helps: https://gist.github.com/adhawkins/8df9b0e0b8391588ecdd2c08c72138fe
2023-06-09 09:38:28 <psykose> this is already packaged
2023-06-09 09:38:43 <adhawkins> It is? I had a look and couldn't see it. One sec.
2023-06-09 09:39:09 <adhawkins> Ah, it's in 'testing'...my packages are in 'community'.
2023-06-09 09:40:54 <adhawkins> In order for this to work, does the package need to be moved to 'community'?
2023-06-09 09:41:25 <psykose> to add as a dependency of something tyhere, yes
2023-06-09 09:41:46 <adhawkins> Is it acceptable for me to move it from testing to community? Is there a process for that?
2023-06-09 09:41:59 <adhawkins> Looks like it's been in testing for over a year.
2023-06-09 14:34:01 <psykose> ye, just an mr
2023-06-09 15:08:08 <omni> psykose: dunno, it's gone now
2023-06-09 15:08:34 <omni> tried downgrading util-linux stuff to -r6 and that didn't fix it
2023-06-09 15:08:59 <omni> then I upgraded all the packages to latest and now I don't see it anymore...
2023-06-09 22:56:54 <omni> https://git.sr.ht/~graywolf/acme-client-portable is lagging a few commits of https://github.com/openbsd/src/commits/master/usr.sbin/acme-client not sure if anything important
2023-06-09 22:57:03 <omni> sent an email to wolf
2023-06-09 22:58:42 <psykose> half the commit history is 'merge xyz branch' so i have no idea where it is
2023-06-09 22:58:48 <psykose> looks completely detached and 100 behind
2023-06-09 22:59:41 <psykose> ok, since e6cfdc77312d7e3a3ff6f2fe4716d6d939ce1bee
2023-06-10 16:11:08 <Arnavion> ARM builders are back, nice
2023-06-10 16:13:57 <psykose> i wouldn't celebrate until they actually build some stuff
2023-06-10 16:26:49 <skarnet> well if you like celebrations it's safer to celebrate now
2023-06-11 09:49:44 <omni> wrt zvol snapshot localmount issues, probably due to me having a lot of snapshots, removed a bunch
2023-06-11 09:52:31 <psykose> could also be some magic race condition
2023-06-11 11:10:34 <omni> yeah, there is some magic around the house.. or maybe it's just advanced technology, hard to tell
2023-06-11 13:55:37 <PabloCorreaGomez[m]> psykose: regarding https://gitlab.alpinelinux.org/alpine/aports/-/issues/14844 The problem we have is that GLib will look for things under the prefix provided by TZDIR. So if someone does g_time_zone_new_identifier with any identifier that doesn't exist in /etc/zoneinfo, it will totally fail. That will be 100% the case if we run setup-timezone -i
2023-06-11 13:57:46 <psykose> seems so
2023-06-11 13:58:01 <psykose> i can't think of a way to solve it
2023-06-11 13:58:09 <PabloCorreaGomez[m]> The easiest thing to avoid a pile of hacks somewhere else would be to have flatpak depend on tzdata
2023-06-11 13:58:09 <psykose> i don't even understand why we make a /etc/zoneinfo/ at all
2023-06-11 13:58:14 <psykose> that does not fix it!
2023-06-11 13:58:17 <psykose> it does not do anything
2023-06-11 13:58:45 <psykose> if you do setup-timezone with something links into /etc/zoneinfo/, it will always fail without TZDIR
2023-06-11 13:58:54 <psykose> i showed that in the issue already
2023-06-11 13:59:23 <psykose> my thought (you can think of the code)- just patch the resolution so it works with that case too
2023-06-11 13:59:23 <PabloCorreaGomez[m]> Oh yeah, there I'm under the assumption that localtime would point to /usr/share/zoneinfo
2023-06-11 13:59:33 <psykose> it doesn't actually depend on anything from the system
2023-06-11 13:59:37 <psykose> it just.. reads the link name
2023-06-11 13:59:39 <psykose> and converts it
2023-06-11 14:00:02 <psykose> so you can add a case to convert /etc/zoneinfo/$x -> $x
2023-06-11 14:00:13 <psykose> and then drop the tzdir env
2023-06-11 14:00:16 <psykose> and everything works
2023-06-11 14:00:51 <PabloCorreaGomez[m]> Before this, I was actually thinking of patching setup-timezone to not use /etc/zoneinfo if tzdata exists
2023-06-11 14:01:06 <psykose> i see what you're going for but i don't think that does anything
2023-06-11 14:01:15 <psykose> because there will still be a case where /etc/zoneinfo would get made, etc
2023-06-11 14:01:27 <psykose> from the other perspective it's "cases to handle", it doesn't remove one
2023-06-11 14:03:08 <psykose> from the perspective of flatpak i don't quite understand their behaviour either i guess
2023-06-11 14:03:39 <psykose> well, hmm
2023-06-11 14:03:46 <PabloCorreaGomez[m]> Well, it's the same behavior as GLib, that we discussed in the openrc-settingsd discussion
2023-06-11 14:04:14 <psykose> is it? they reimplemented their own function
2023-06-11 14:04:19 <psykose> they don't just call the glib one
2023-06-11 14:04:33 <PabloCorreaGomez[m]> The  thing is, nobody seems to expect /etc/zoneinfo to be a directory, but instead a file that might contain the zoneinfo, e.g: "Europe/Berlin"
2023-06-11 14:04:58 <PabloCorreaGomez[m]> Well, the logic described in the issue is basically the same that I'm reading in GLib code
2023-06-11 14:05:20 <PabloCorreaGomez[m]> A bit simpler, but the same overall concept
2023-06-11 14:05:50 <psykose> i don't think anyone expects /etc/zoneinfo to be a thing at all
2023-06-11 14:05:54 <psykose> i don't think i've seen it?
2023-06-11 14:06:04 <psykose> it's /etc/timezone that is a file with the string, and localtime the symlink
2023-06-11 14:06:15 <psykose> zoneinfo is a dir like the usr/share one just in /etc for some reason
2023-06-11 14:06:49 <psykose> the easiest solution is to take https://github.com/flatpak/flatpak/blob/c392e5adf63ea2817a6f05081365fdd7acdfc04e/common/flatpak-utils-base.c#L58
2023-06-11 14:06:56 <PabloCorreaGomez[m]> Ups, sorry, I read wrong, you're right
2023-06-11 14:07:02 <psykose> and copy the block and add g_str_has_prefix (canonical, "/etc/zoneinfo")
2023-06-11 14:07:07 <psykose> just as a dumb hack
2023-06-11 14:07:11 <psykose> but it does solve every issue :p
2023-06-11 14:07:47 <psykose> i have no good ideas sadly
2023-06-11 14:08:14 <PabloCorreaGomez[m]> Maybe one option would be to add the TZDIR variable as part of setup-timezone if tzdata does not exist?
2023-06-11 14:08:44 <psykose> i don't think that helps because things can always change and people will just forget to remove it or not
2023-06-11 14:08:46 <PabloCorreaGomez[m]> And if tzdata does exist, or is requested to install, completely ignore /etc/zoneinfo?
2023-06-11 14:09:07 <psykose> you should think from the flatpak perspective, not what setup-timezone may or may not do in the future
2023-06-11 14:09:23 <psykose> even if we change it it doesn't fix anything currently
2023-06-11 14:10:23 <psykose> for flatpak.sh, we could do if [ -d /etc/zoneinfo]; then export TZDIR
2023-06-11 14:10:34 <psykose> and that also works, as a less intrusive hack
2023-06-11 14:10:37 <psykose> sounds ok?
2023-06-11 14:11:02 <PabloCorreaGomez[m]> That's another option, yes
2023-06-11 14:11:31 <PabloCorreaGomez[m]> But I think that will also affect any other GLib app, so might not be flatpak specific, although I don't mind where does it live
2023-06-11 14:12:05 <PabloCorreaGomez[m]> I'm going to fix pmOS to use setup-timezone -i, since that's the sane thing to do for user graphical UIs
2023-06-11 14:14:06 <psykose> aye
2023-06-11 14:14:15 <psykose> for other apps as long as it 'exists' i think it would work, right
2023-06-11 14:14:32 <psykose> i.e. things do glib_something_tz, TZDIR=/etc/zoneinfo, and it does actually exist with the one timezone
2023-06-11 14:15:47 <PabloCorreaGomez[m]> It works if you request the current timezone, that exists in zoneinfo. It doesn't if you request any other timezone, right? Since that would not be persisted in /etc/zoneinfo
2023-06-11 14:17:38 <PabloCorreaGomez[m]> But to be fair, I don't think that's something we can fix
2023-06-11 14:18:07 <PabloCorreaGomez[m]> Targeting both minimal installation size and sensible defaults for UI apps is hard. I'm fine adapting things downstream
2023-06-11 14:26:10 <PabloCorreaGomez[m]> psykose: although for the [ -d /etc/zoneinfo ] logic to work, https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/157 this needed, as otherwise it's created by default, even if empty
2023-06-11 14:26:52 <psykose> annoying, annoying..
2023-06-11 16:57:45 <Arnavion> <@psykose> i wouldn't celebrate until they actually build some stuff   < I guess the thing where every build gets stuck at "Signing the index..." for hours still exists, assuming the logs on build.alpinelinux.org are telling the truth
2023-06-11 17:01:29 <psykose> nah, it's something else
2023-06-11 17:01:51 <psykose> when the internet drops in the middle of a build it hangs somewhere in buildrepo
2023-06-11 17:01:54 <psykose> but it's after that
2023-06-11 17:03:25 <bl4ckb0ne> whos hosting the arm infra?
2023-06-12 01:20:30 <agris> test
2023-06-12 03:48:48 <bl4ckb0ne> s390x runner looks dead
2023-06-12 03:48:55 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1047963
2023-06-12 04:53:02 <ikke> bl4ckb0ne: where do you think that runner is running on (which is giving that output)
2023-06-12 04:53:21 <bl4ckb0ne> the cloud!
2023-06-12 04:53:49 <ikke> It's running on docker
2023-06-12 05:23:02 <ikke> bl4ckb0ne: works after retry: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1047969
2023-06-12 11:30:03 <bl4ckb0ne> welp thanks
2023-06-12 12:42:28 <raspbeguy> hello, I am working on adding lvm2-lockd subpackage to lvm2. The LVM2 locking daemon ideally has an OpenRC service file, so it that possible to make a sub-subpackage? (lvm2-lockd-openrc)
2023-06-12 13:29:05 <ncopa> should be possible yes
2023-06-12 13:29:24 <ncopa> or we can maybe ship it with lvm2-openrc?
2023-06-12 13:34:19 <raspbeguy> well, I guess you might not want to install lockd and still have lvm other service files
2023-06-12 13:37:09 <raspbeguy> but yes for me that would be easier of course
2023-06-12 14:00:09 <ncopa> is lockd in its own subpackage?
2023-06-12 14:25:42 <adhawkins> Upstream for one of my packages is asking me to test his current 'master' branch using the Alpine CI on gitlab. Is there any way to do this other than by creating an MR?
2023-06-12 14:29:14 <ikke> No
2023-06-12 14:29:35 <adhawkins> Ok, thanks ikke. I'll create a temporary MR and make it obvious that it shouldn't be merged.
2023-06-12 14:29:40 <adhawkins> Assuming there are no objections to that?
2023-06-12 14:30:32 <ikke> No, just make it a draft 
2023-06-12 14:30:56 <adhawkins> Yeah, will do.
2023-06-12 14:33:09 <raspbeguy> ncopa, that's what I'm working on
2023-06-12 14:33:48 <raspbeguy> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47980
2023-06-12 14:34:22 <raspbeguy> this is WIP, it lacks a dependancy (sanlock which is still in testing)
2023-06-12 22:17:26 <bl4ckb0ne> psykose: thanks for the revdep cue
2023-06-12 22:17:52 <bl4ckb0ne> apparenty hare packages are fine because everything is statically linked
2023-06-12 22:18:21 <bl4ckb0ne> i guess ill wait for patch from upstrean
2023-06-12 22:21:50 <psykose> they are fine yes, they just can't rebuild
2023-06-13 05:30:33 <PureTryOut> psykose: uh please at least notify me when you add a new aport and set me as maintainer off... 🤔
2023-06-13 05:30:48 <psykose> it's a qt module like all of them
2023-06-13 05:31:02 <PureTryOut> I get that, I'd still like a notification
2023-06-13 05:32:08 <PureTryOut> Not sure what Qt needs a LSP for though, it being all C++. I suppose for QML?
2023-06-13 05:34:44 <psykose> it is named qmlls
2023-06-13 05:35:02 <psykose> indeed for qml
2023-06-13 05:44:45 <PureTryOut> ah ok good
2023-06-13 06:05:50 <raspbeguy> ptrc: hello, could you give your opinion about !47978 please?
2023-06-13 08:39:05 <adhawkins> Just double checking, are there still issues with the arm CI builders?
2023-06-13 08:40:01 <ikke> adhawkins: the network is still unstable, so yes
2023-06-13 08:44:04 <adhawkins> Ok, no worries. I'll ignore the errors. Thanks ikke.
2023-06-13 18:33:40 <Newbyte> What's the preferred commit message when removing maintainership of a package?
2023-06-13 18:35:57 <psykose> drop maintainership
2023-06-13 18:36:25 <Newbyte> wouldn't "remove maintainership" be more consitent with how commitstyle.md specifies removing packages?
2023-06-13 18:37:08 <Newbyte> but it seems drop maintainership is actually being used unlike remove maintainership, so I'll go with that. thanks
2023-06-13 18:37:51 <ikke> 113 vs 0 times used
2023-06-13 18:43:56 <psykose> i love democracy
2023-06-13 19:10:07 <Newbyte> democracy is great but how about consistency
2023-06-13 19:10:40 <ikke> Sounds pretty consistent 
2023-06-13 19:10:53 <Newbyte> ikke: there is also "orphan"
2023-06-13 19:21:32 <sam_> i used to know someone who hated the word "maintainership"
2023-06-13 19:21:35 <sam_> because "it's not a real word"
2023-06-13 19:30:32 <Newbyte> <sam_> "because "it's not a real word"" <- What word did he prefer?
2023-06-13 19:31:46 <psykose> sam isn't a real word either
2023-06-13 19:36:22 <raspbeguy> I thought that you could made up as many words as you want in English
2023-06-13 19:38:11 <ptrc> all words are made up
2023-06-13 19:38:19 <ptrc> also raspbeguy: i'll look at the mr in a few seconds :p
2023-06-13 19:38:42 <raspbeguy> Great
2023-06-13 19:46:05 <raspbeguy> ptrc: I said I fixed that newline but forgot to include it in the new commit. Whatever, I'll fix that when I'll move this package into main
2023-06-13 19:46:34 <raspbeguy> (I need it into main to enable a LVM2 feature)
2023-06-13 19:47:41 <psykose> not necessarily
2023-06-13 19:47:59 <ptrc> oh, if you want to move it to main, could you also take over maintainership? i don't really use it on a daily basis, so while it's fine in testing, i don't think i'd be able to properly maintain it in stable
2023-06-13 19:48:47 <raspbeguy> ptrc: sure
2023-06-13 19:50:04 <raspbeguy> psykose: well I have to enable a build option in the LVM package that needs libsanlock as dependency. Already checked with ncopa
2023-06-13 19:54:34 <psykose> ah, you forgot the sanlock-dev
2023-06-13 20:02:57 <raspbeguy> In the LVM MR yes
2023-06-13 20:12:41 <raspbeguy> !48007 is ready
2023-06-14 02:13:30 <gnu-only-way> Nobody knows anything, and no info on internet. why im asking here,  just want yes or no. 
2023-06-14 02:14:12 <gnu-only-way> Does alpine linux contain closed source code at all (such as binary blobs, proprietary firmware/drivers)? the mainstream linux kernel contains such.
2023-06-14 02:14:24 <gnu-only-way> thank you
2023-06-14 02:28:23 <psykose> yes
2023-06-14 02:30:53 <sam_> heaps of it unfortunately
2023-06-14 02:30:59 <gnu-only-way> yikes, thank you for answering
2023-06-14 02:31:00 <sam_> in fact you may be alarmed to learn musl isn't even gpl
2023-06-14 02:31:11 <gnu-only-way> honestly i may just avoid alpine going forward
2023-06-14 02:31:16 <abby> alpine doesn't even use gnu coreutils
2023-06-14 02:31:39 <gnu-only-way> any way to avoid closed source binary when installing, or remove post-install?
2023-06-14 02:31:46 <psykose> no
2023-06-14 02:32:22 <psykose> we don't ship linux-libre and there is no interest in it
2023-06-14 02:32:29 <psykose> find another distro i guess
2023-06-14 02:34:45 <gnu-only-way> good to know
2023-06-14 02:35:34 <gnu-only-way> can it really be called "secure" if it is not open source though?
2023-06-14 02:35:51 <gnu-only-way> on website it claims "security-oriented". I'd argue not.
2023-06-14 04:01:09 <boomanaiden154> Is anything really secure?
2023-06-14 04:01:27 <psykose> you can just ignore the troll
2023-06-14 04:02:47 <boomanaiden154> True. I need to get better at that.
2023-06-14 04:35:17 <agris> lol
2023-06-14 04:35:38 <agris> how often does that happen?
2023-06-14 04:37:51 <ikke> rarely
2023-06-14 08:30:37 <ncopa>                          -- Performing Test HAVE_MKSTEMP - Failed
2023-06-14 08:30:37 <ncopa>                            Cannot find mkstemps nor mkstemp on this platform.
2023-06-14 08:30:37 <ncopa>                          Call Stack (most recent call first):
2023-06-14 08:30:37 <ncopa>                          CMake Error at /home/buildozer/aports/community/dotnet7-build/src/dotnet-v7.0.107/src/runtime/artifacts/source-build/self/src/src/native/libs/configure.cmake:783 (message):
2023-06-14 08:30:50 <ncopa> weird error for dotnet7 on armv7
2023-06-14 10:17:18 <ikke> ayakael: ^
2023-06-14 10:30:39 <ncopa> i just discovered v lang. really promising language! simple and similar to go, significantly smaller binaries. still has pretty nice features. seems simple to bootstrap (v can generate C soruce)
2023-06-14 10:34:32 <ikke> there is also hare
2023-06-14 10:45:22 <ncopa> i think v supports all our architectures
2023-06-14 12:16:00 <ayakael> ncopa: noted, I've slated this for investigation in a couple of hours.
2023-06-14 12:17:17 <ncopa> 👍
2023-06-14 13:56:28 <ncopa> syncthing does not build on armhf. maybe we simply disable it there?
2023-06-14 14:06:20 <ikke> Out of memory?
2023-06-14 14:06:43 <ikke> Needs more the 4GB?
2023-06-14 14:06:48 <ikke> than*
2023-06-14 14:27:33 <ncopa> im tagging releases now
2023-06-14 15:57:20 <Arnavion> Funny thing discovered while running my own hacked-up arm builder: If community/fossil's is built in an interactive session, one of the tests blocks and waits for the user to enter a password to some server
2023-06-14 16:09:20 <psykose> what was the way to deal with that
2023-06-14 16:09:23 <psykose> aside from echo | test
2023-06-14 16:09:35 <psykose> 0<&- ?
2023-06-14 16:10:01 <ikke> setsid?
2023-06-14 16:10:44 <psykose> setsid has the side effect of then not dying if stuck and parent killed or w/e doesn't it
2023-06-14 16:10:46 <psykose> i forgot
2023-06-14 16:12:57 <ikke> I thought that was nohup
2023-06-14 16:16:59 <Arnavion> Ah, went back and found the logs and it's just a local test server:   https://paste.rs/WTIbx   I guess it expects the human to copy-paste the password printed a few lines above, heh
2023-06-14 16:31:54 <skarnet> very normal testing suite
2023-06-15 07:01:41 <staceee> I need help: why there is no this module on the package pipewire? /usr/lib/pipewire-0.3/libpipewire-module-switch-on-connect.so
2023-06-15 07:01:56 <staceee> I really struggle to understand how/why this isn't installed o_O
2023-06-15 07:02:36 <psykose> well it's not part of the package at all
2023-06-15 07:03:37 <staceee> psykose: wdym? we just run meson build from the apkbuild
2023-06-15 07:03:45 <staceee> an option is missing?
2023-06-15 07:03:56 <psykose> i mean that /usr/lib/pipewire-0.3/libpipewire-module-switch-on-connect.so is not part of any package anywhere
2023-06-15 07:04:19 <psykose> i don't see anyone else having that either
2023-06-15 07:04:49 <psykose> the source file module-switch-on-connect.c is part of libpipewire-module-protocol-pulse.so
2023-06-15 07:04:53 <psykose> i.e. embedded
2023-06-15 07:05:18 <psykose> it's normally a pulseaudio module (https://pkgs.alpinelinux.org/contents?file=module-switch-on-connect.so&path=&name=&branch=edge&arch=x86_64)
2023-06-15 07:05:25 <psykose> but all of those are just part of pulse.so in pipewire
2023-06-15 07:05:41 <psykose> (or pulse-tunnel, depending)`
2023-06-15 07:06:07 <psykose> this sounds like an a-b problem unless you see that module on some other distro
2023-06-15 07:06:09 <psykose> i don't think it exists
2023-06-15 07:06:27 <staceee> mhhh
2023-06-15 07:06:35 <psykose> if you look at 0.3.33 changelog you can see it was added as part of protocol-pulse.so
2023-06-15 07:06:45 <psykose> just like the other classical ones
2023-06-15 07:07:57 <psykose> checkl /usr/share/pipewire/pipewire-pulse.conf:63
2023-06-15 07:08:04 <psykose> you can see how that works
2023-06-15 07:08:15 <staceee> yes I'm trying to enable this
2023-06-15 07:08:42 <staceee> but I get Error: "Could not load module"
2023-06-15 07:08:46 <staceee> with pw-cli
2023-06-15 07:08:50 <psykose> what did you type
2023-06-15 07:08:52 <psykose> $ pactl load-module module-switch-on-connect
2023-06-15 07:08:53 <psykose> works
2023-06-15 07:09:02 <staceee> omg
2023-06-15 07:09:30 <psykose> afaik all the pulse modules and pulse emulation layer is meant to be used with the same old pa* tools
2023-06-15 07:09:36 <psykose> i'm not sure if pw-cli exposes that or not
2023-06-15 07:09:40 <psykose> maybe it's more contrived
2023-06-15 07:10:07 <staceee> I'm tried to add a .config/pipewire/pipewire-pulse.conf.d/switch-on-connect.conf
2023-06-15 07:10:28 <psykose> that should work if it's something like the /usr/share example of pulse.cmd
2023-06-15 07:10:35 <psykose> (which just runs that command effectively)
2023-06-15 07:17:42 <staceee> thanks psykose ! \o/ my config file was just wrong 
2023-06-15 07:18:32 <abby> \o/
2023-06-15 07:18:50 <abby> algitbot: dance
2023-06-15 07:19:02 <psykose> how will u recover
2023-06-15 07:19:05 <abby> aw
2023-06-15 07:19:15 <abby> i'll go ask void-builder to do it
2023-06-15 07:19:20 <abby> instead
2023-06-15 07:20:12 <abby> :D https://p.qrm.cat/5jhzdO.png
2023-06-15 07:20:13 <psykose> algitbot: what the
2023-06-15 07:21:03 <abby> lol
2023-06-15 07:21:36 <staceee> x]
2023-06-15 07:22:20 <psykose> algitbot: hello there
2023-06-15 07:22:23 <psykose> i see that's still there
2023-06-15 07:22:52 <staceee> I see we got the same refs
2023-06-15 07:23:16 <abby> void-robot is grumpy <abby> void-robot: hello?
2023-06-15 07:23:16 <abby> <void-robot> abby: go away, I'm busy
2023-06-15 07:24:34 <psykose> is abby grumpy
2023-06-15 07:24:56 <abby> more tired
2023-06-15 07:27:01 <psykose> why be tired when can into be
2023-06-15 07:27:01 <psykose> d
2023-06-15 08:25:54 <staceee> question about openrc-run and supervise-daemon, if my daemon fails to start, is it restarted? I would like so.. 
2023-06-15 08:26:04 <staceee> I got a problem with openvpn + nfsmount
2023-06-15 08:26:35 <staceee> rc_need="net.tun2" works, but rc_use="net.tun2" doesn't. But I don't want for nfsmount to be restarted on openvpn restart
2023-06-15 08:28:17 <staceee> either (1) the nfsmount get restarted if it fails to launch, or (2) I found a way to telle openrc to wait for tun2 to be ready before starting nfsmount, while not make nfsmount "dependent" on openvpn
2023-06-15 08:28:55 <staceee> (context is: I get soft locks if openvpn restart and wait for nfsmount to stop before doing so, on connection lost)
2023-06-15 08:32:33 <staceee> I would like for openrc "use" to behave like "need" for ifaces
2023-06-15 08:32:50 <staceee> (or a "need" without restarts)
2023-06-15 09:04:33 <nmeum> does auto-assining of merge requests with algibot no longer work? :(
2023-06-15 09:08:32 <psykose> nope
2023-06-15 09:10:06 <psykose> broke like 2 releases ago
2023-06-15 09:10:45 <nmeum> gitlab api changes or what's the reason for that?
2023-06-15 09:11:34 <psykose> something like that yeah
2023-06-15 09:11:36 <psykose> some api thing broke
2023-06-15 09:11:48 <psykose> nobody had time to look at it i suppose
2023-06-15 09:12:15 <nmeum> where can I find the algibot source code again?
2023-06-15 09:12:28 <nmeum> I can at least add looking into it to my endless to-do list
2023-06-15 09:13:27 <psykose> https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot
2023-06-15 09:14:25 <nmeum> thanks
2023-06-15 15:39:11 <ikke> ncopa: with the debug symbols enabled, the ppc64le kernel is way to large for our host
2023-06-15 15:39:17 <ikke> So we could never upgrade
2023-06-15 15:39:33 <ncopa> hm
2023-06-15 15:39:39 <psykose> that is already fixed
2023-06-15 15:39:41 <ikke> ah ok
2023-06-15 15:39:42 <psykose> next upgrade should be fine
2023-06-15 15:40:07 <ncopa> i saw it got disabled, which means that BPF programs will stop to wrok
2023-06-15 15:40:52 <ikke> hmm, armhf is missing linux-lts? https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=edge&repo=&arch=&maintainer=
2023-06-15 15:40:56 <psykose> always was
2023-06-15 15:41:24 <psykose> was rpi only
2023-06-15 15:41:27 <psykose> more or less
2023-06-15 15:41:32 <ikke> ah ok
2023-06-15 15:42:03 <ikke> Just noticed the list was one entry too short :)
2023-06-15 15:42:16 <ikke> although, rv64 is also missing
2023-06-15 15:42:23 <ikke> but that has a dedicated kernel I suppose
2023-06-15 15:42:30 <ikke> for dedicated boards
2023-06-15 18:46:03 <rcpage> how long does it take gitlab.alpinelinux.org/aports merges to replicate to mirrors?
2023-06-15 18:46:17 <ptrc> https://build.alpinelinux.org/
2023-06-15 18:47:06 <ptrc> builders get poked on every commit to master, then just a few minutes after building to upload files and propagate
2023-06-15 18:47:20 <psykose> the actual answer is 'aarch64 rly behind so will take a while'
2023-06-15 18:47:21 <ptrc> ah, that too
2023-06-15 18:48:44 <rcpage> so this covers builds, but what about time for sync (rsync?) from nl.alpinelinux.org to mirrors like na.kernel.org?
2023-06-15 18:49:28 <psykose> neither of those are actual mirrors
2023-06-15 18:49:34 <psykose> depends on when the mirror syncs specifically
2023-06-15 18:49:50 <ptrc> some mirrors mention how often they get synced
2023-06-15 18:49:59 <ptrc> some are connected to the mqtt server and sync whenever there's something new
2023-06-15 18:50:01 <psykose> actual dl-cdn is 15 minute interval
2023-06-15 18:50:10 <ptrc> but some have a fixed interval for syncing
2023-06-15 18:58:58 <rcpage> thanks for the details!
2023-06-15 19:00:18 <rcpage> @psykose https://nl.alpinelinux.org/alpine/ and https://na.edge.kernel.org/alpine/ both show as mirrors
2023-06-15 19:00:36 <psykose> the only actual mirrors are on https://mirrors.alpinelinux.org/
2023-06-15 19:00:58 <psykose> na.edge.kernel is one (misread it initially)
2023-06-15 19:01:05 <psykose> the other one is an alias and not guaranteed to be anything
2023-06-15 19:01:07 <rcpage> I mistyped it originally
2023-06-15 19:02:13 <psykose> i.e. presently it's a cname to t1. but in the past names like that can go poof at any time
2023-06-15 19:02:26 <psykose> generally though just use dl-cdn
2023-06-15 19:02:37 <psykose> it's a global fastly cdn and always the easiest and usually fastest option
2023-06-15 19:04:29 <rcpage> I prefer region guarantees from na.edge.kernel.org
2023-06-15 20:06:10 <sam_> nmeum: got a phab link for https://git.alpinelinux.org/aports/commit/?id=5ecc3adbbc5ecd614199aa0ff9ece5fe4b43a097?
2023-06-15 20:06:15 <sam_> i'd started on it but didn't finish it
2023-06-15 20:07:46 <nmeum> didn't submit it to their phabricator but created https://github.com/llvm/llvm-project/issues/63325
2023-06-15 20:33:47 <skarnet> there was a recent change to docker that broke docker build (or buildx): I apk upgraded earlier this week (or late last week) and now on ADD instructions I get this:
2023-06-15 20:33:57 <skarnet> ERROR: failed to solve: failed to load cache key: invalid not-modified ETag:
2023-06-15 20:34:12 <skarnet> with --log-level=debug I get this:
2023-06-15 20:34:21 <skarnet> ERROR: failed to solve: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount4056700304/Dockerfile.etag: no such file or directory
2023-06-15 20:35:09 <skarnet> is this known? a web search shows that it happened several times in the past for different reasons and solutions appear to vary every time
2023-06-15 20:35:26 <skarnet> (everyone loves that kind of bug)
2023-06-15 20:36:00 <ikke> last upgrade to docker was may 27th
2023-06-15 20:36:03 <ikke> on edge
2023-06-15 20:36:35 <skarnet> yeah that checks out, I hadn't apk upgraded before that date
2023-06-15 20:36:57 <skarnet> well it's borked now, it seems :(
2023-06-15 20:40:52 <ikke> skarnet: Just to be sure, last time I got "ERROR: failed to solve: failed to load cache key", it meant I referred to a non-existing file / directory
2023-06-15 20:41:10 <ikke> (I can't recall any additional error info)
2023-06-15 20:43:19 <skarnet> it seems it's exactly what's happening, but in some internal Docker thing I have no control over
2023-06-15 20:45:32 <ikke> Are you adding a remote file over http?
2023-06-15 20:45:37 <skarnet> yes
2023-06-15 20:46:03 <ikke> what does curl -I <url> return?
2023-06-15 20:46:30 <ikke> skarnet: did you find this issue? https://github.com/moby/buildkit/issues/784
2023-06-15 20:46:55 <skarnet> the file is there, has always been there, and the server has not changed
2023-06-15 20:47:07 <skarnet> I also did turn it off and on again
2023-06-15 20:47:11 <ikke> Yes, but interested in the etag value
2023-06-15 20:47:27 <skarnet> ETag: "64899ece-18ac"
2023-06-15 20:48:04 <skarnet> it's bb httpd, I don't think it supports if-not-modified or anything of the kind
2023-06-15 20:48:34 <skarnet> but since they're optional part of the spec, docker should not fail in this case (and it worked previously)
2023-06-15 21:06:16 <ikke> skarnet: trying to reproduce it, but works without issue for me
2023-06-15 21:06:58 <skarnet> thanks. Can you try with ADD https://skarnet.org/tmp/docker/s6-overlay-noarch.tar.xz ?
2023-06-15 21:07:22 <skarnet> I suspect it's the interaction between bb httpd and something that changed in docker
2023-06-15 21:07:55 <skarnet> but I assume it's a regression in Docker since it has always worked for me previously
2023-06-15 21:08:45 <ikke> skarnet: works fine as well
2023-06-15 21:08:54 <ikke> https://tpaste.us/vNEM
2023-06-15 21:09:33 <skarnet> well that's weird, but kinda reassuring at the same time. Is there something I can do to clear the docker cache or anything of the kind?
2023-06-15 21:09:46 <skarnet> seems to be my local data that's corrupt
2023-06-15 21:09:52 <ikke> add --no-cache to the build command?
2023-06-15 21:09:54 <Arnavion> `docker system prune -af && docker volume prune -f` is the usual nuclear option
2023-06-15 21:10:00 <skarnet> thanks
2023-06-15 21:10:34 <Arnavion> Or wipe `/var/lib/docker` (or whatever it is on alpine) and restart dockerd
2023-06-15 21:10:52 <ikke> docker builder prune probably suffices
2023-06-15 21:11:03 <skarnet> --no-cache failed, but system prune && volume prune worked
2023-06-15 21:11:05 <skarnet> thanks a lot :)
2023-06-15 21:11:17 <ikke> fun
2023-06-16 04:56:46 <nmeum> psykose: would you be ok with backporting the msan compiler-rt fix to -stable?
2023-06-16 06:10:29 <nmeum> looks like the gitlab was hit by a spam wave, received >600 new emails from the gitlab today
2023-06-16 08:25:58 <ikke> Yes
2023-06-16 08:26:21 <ikke> I already removed some of it, let me know if there is more left
2023-06-16 12:58:22 <MeMeMe> Hello, does anybody know if there is a way to compile 3rd party modules for nginx provided by alpine itself?
2023-06-16 12:59:09 <MeMeMe> On debian/ubuntu i can just use apt-get source to fetch the sources and build the module
2023-06-16 12:59:30 <MeMeMe> but i cannot find any sort of information on alpine website (nor on google) on how to do this
2023-06-16 13:27:58 <ncopa> i suppose you'd need git clone the aports tree and edit main/nginx/APKBUILD
2023-06-16 13:28:58 <MeMeMe> i hoped that would not be the solution
2023-06-16 15:18:21 <psykose> nmeum: done
2023-06-16 15:18:45 <nmeum> ty
2023-06-16 15:48:47 <Arnavion> Hurrah, edge/community is finally caught up
2023-06-16 20:54:29 <eletrotupi> is the mailing list integration still down?
2023-06-16 20:55:13 <psykose> ye
2023-06-16 20:56:24 <eletrotupi> bleh
2023-06-16 20:56:29 <eletrotupi> 
ACTION forks aports

2023-06-16 21:45:18 <psykose> nmeum: for some reason getcap -r on /usr/bin can "return nothing" but while in fakeroot for suid executables it returns cap_setuid=ep, etc
2023-06-16 21:45:32 <psykose> which is somewhat funny but means anything with =suid needs =setcap too i guess
2023-06-16 21:45:57 <psykose> well, maybe it's something else, just being in fakeroot makes it return nothing ever
2023-06-16 21:46:01 <psykose> but in package() it does
2023-06-17 09:48:44 <nmeum> psykose: I suppose we could exclude suid binaries in the loop that iterates over the getcap -r results?
2023-06-17 09:49:30 <psykose> maybe, could also just ignore it though
2023-06-17 12:25:20 <ikke> nmeum: we need to allow setcap as option in apkbuild-lint as well
2023-06-18 18:55:50 <Newbyte> could someone create a pipeline in `!47743?
2023-06-18 18:56:57 <Newbyte> also would be great if someone could look into merging !47651
2023-06-18 19:00:33 <andypost[m]> Newbyte: jobs started
2023-06-18 19:01:04 <Newbyte> thank you!
2023-06-18 19:14:34 <bl4ckb0ne> why does it has its own wlroots fork?
2023-06-18 19:25:45 <Newbyte> <bl4ckb0ne> "why does it has its own wlroots..." <- because it doesn't work otherwise
2023-06-18 20:17:13 <psykose> bl4ckb0ne: mobile dev moment
2023-06-18 20:17:21 <psykose> /s
2023-06-18 20:17:48 <Newbyte> we are just too fast for wlroots upstream 😎 (never mind that the needed patch is a revert)
2023-06-18 20:20:10 <psykose> perpetual upstream that is behind every release and then just reverts 1 patch
2023-06-18 20:20:18 <psykose> 😎
2023-06-18 20:20:21 <psykose> love2code
2023-06-18 20:20:46 <psykose> i bet bl4ckb0ne is frothing at the mouth at the thought of it
2023-06-18 20:27:41 <Arnavion> psykose: You forgot to `git rm rootlibexecdir.patch`
2023-06-18 20:28:13 <Arnavion> Also this means elogind is broken by default right? Crazy
2023-06-18 20:32:58 <psykose> classic
2023-06-18 20:33:00 <psykose> and yeah
2023-06-18 20:33:46 <Newbyte> <Arnavion> "Also this means elogind is..." <- what exactly means elogind is broken?
2023-06-18 20:33:53 <psykose> i imagine the person testing it might've been on a system where libexecdir=libdir
2023-06-18 20:34:04 <psykose> then it looks like it works
2023-06-18 20:34:16 <psykose> Newbyte: the build is just broken to the rpaths are wrong
2023-06-18 20:35:01 <Arnavion> Yeah, if someone uses default elogind source then elogind and loginctl binaries won't run
2023-06-18 20:35:22 <Arnavion> And yeah, only testing with libexecdir=libdir would hide it
2023-06-18 20:36:30 <Arnavion> (   https://gitlab.alpinelinux.org/alpine/aports/-/issues/15036   )
2023-06-18 21:10:44 <bl4ckb0ne> psykose: dead wrong
2023-06-18 21:10:51 <bl4ckb0ne> i softly chuckled
2023-06-18 21:11:03 <psykose> counterpoint: alive
2023-06-18 21:29:57 <bl4ckb0ne> whats the patch?
2023-06-18 21:34:02 <psykose> actually not sure if the revert is there anymore
2023-06-18 21:34:03 <psykose> https://source.puri.sm/Librem5/wlroots/-/commits/pureos/byzantium
2023-06-18 21:34:07 <psykose> it's just 0.15.1 with 3 patches
2023-06-18 21:34:17 <psykose> or 2
2023-06-18 21:34:27 <psykose> ah, no
2023-06-18 21:34:34 <psykose> look at debian/patches/series
2023-06-18 21:34:38 <psykose> has the revert list
2023-06-18 21:56:34 <bl4ckb0ne> lovely
2023-06-20 18:32:10 <singham> I need help
2023-06-20 18:32:51 <singham> I have an issue on lime2 where my core partition gets mounted in /media/ directory. I want it mounted as root
2023-06-20 18:33:20 <singham> When I changed /media/xyz in fstab to / , alpine stopped booting
2023-06-20 18:34:00 <singham> I also need help on setting up busybox httpd with tls and cgi
2023-06-20 18:56:48 <singham> Please post the answers. I'll check the logs
2023-06-20 19:15:45 <skarnet> what kind of answer do you want to "I need help"
2023-06-20 19:16:56 <abby> all of them
2023-06-20 19:17:10 <Habbie> other than "don't mount things on /, you need your current / because that's where Alpine is"
2023-06-20 20:26:50 <eletrotupi> why is docker-compose cli installed on /usr/share/libexec/docker? any rationale?
2023-06-20 20:27:03 <ikke> eletrotupi: as it's a plugin to docker
2023-06-20 20:27:09 <ikke> and you execute it as docker compose
2023-06-20 20:27:45 <eletrotupi> really?
2023-06-20 20:27:49 <ikke> yes
2023-06-20 20:27:53 <eletrotupi> wait when that changed though?
2023-06-20 20:28:04 <eletrotupi> I mean, I was *literally* using this as docker-compose
2023-06-20 20:28:10 <eletrotupi> yesterday ahahha
2023-06-20 20:28:28 <abby> it changed a while back
2023-06-20 20:28:49 <eletrotupi> damn
2023-06-20 20:29:17 <ikke> docker deprecated compose v1
2023-06-20 20:29:26 <abby> looks like they EOL'd it this month https://docs.docker.com/compose/install/linux/
2023-06-20 20:30:08 <psykose> compose v2 was always 'docker compose' for years
2023-06-20 20:30:20 <ikke> it was since it was created
2023-06-20 20:30:21 <psykose> 'docker-compose' was finally removed like just now and alpine 3.18
2023-06-20 20:30:25 <psykose> yea
2023-06-20 20:30:45 <psykose> not much of a docker user but i never had any issues with just changing the invocation
2023-06-20 20:30:56 <psykose> i guess the env file quoting changed?
2023-06-20 20:31:07 <psykose> aside from that it's the same shit but faster
2023-06-20 20:31:25 <abby> is it webscale now
2023-06-20 20:31:33 <psykose> better, it's abbyscale
2023-06-20 20:31:43 <eletrotupi> kek
2023-06-20 20:31:58 <eletrotupi> yeah, but I think it doesn't looks for the nearest config file anymore?
2023-06-20 20:32:04 <ikke> Note that you can still execute v2 as docker-compose 
2023-06-20 20:32:24 <ikke> container names changed as well
2023-06-20 20:32:36 <eletrotupi> I mean, at least locally I could invoke 'docker-compose xxx' from a subfolder 
2023-06-20 20:33:17 <psykose> ikke: does it? could add a symlink then
2023-06-20 20:33:19 <psykose> didn't know
2023-06-20 20:34:00 <ikke> on my non-alpine system: "/usr/bin/docker-compose: symbolic link to /usr/lib/docker/cli-plugins/docker-compose"
2023-06-20 20:34:50 <abby> same on void docker-compose-2.18.1_1      /usr/bin/docker-compose -> /usr/libexec/docker/cli-plugins/docker-compose
2023-06-20 20:37:52 <psykose> sure, i'll add it
2023-06-20 23:31:43 <omni> can I fetch our cached sources somewhere? I forget
2023-06-20 23:32:12 <psykose> https://distfiles.alpinelinux.org/distfiles/edge/
2023-06-20 23:32:26 <omni> <3
2023-06-20 23:32:59 <omni> I'll ask you tomorrow again
2023-06-20 23:33:14 <omni> now, what was it I was doing?
2023-06-20 23:36:32 <psykose> seeking divine comfort
2023-06-20 23:39:20 <omni> yes, that was it, thank you
2023-06-22 14:37:06 <nmeum> did abuild-addgroup stop working recently within abuild rootbld or did it never really work inside a rootbld?
2023-06-22 14:37:16 <psykose> not for a long time
2023-06-22 14:37:35 <psykose> can't have multiple groups in user namespace sandbox
2023-06-22 14:37:40 <nmeum> yes
2023-06-22 14:37:49 <nmeum> not sure how to best resolve this
2023-06-22 14:37:49 <psykose> it worked when bwrap was suid as it then did 'something else'
2023-06-22 14:37:59 <psykose> that might still work if you chmod u+s bwrap
2023-06-22 14:38:27 <psykose> there was a bunch of discussion in https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094
2023-06-22 14:38:35 <psykose> overall it's not solvable with namespaces afaict
2023-06-22 14:39:28 <nmeum> we could install a custom version of abuild-sudo in rootblds
2023-06-22 14:39:32 <nmeum> which doesn't do the sanitycheck
2023-06-22 14:40:04 <psykose> isn't the group used for some magic install -g thing
2023-06-22 14:40:13 <psykose> which is what pkggroups/pkgusers is for
2023-06-22 14:41:01 <psykose> we could skip the sanitycheck but then using the actual group in package() is just going to fail later
2023-06-22 14:44:05 <nmeum> hmhm
2023-06-22 14:46:56 <nmeum> I mean we can just create the groups/users on the host, which is what we used to do but then ofc pollutes the host
2023-06-22 14:47:41 <psykose> i never really understood how the existing group management works
2023-06-22 14:48:09 <nmeum> which part of it?
2023-06-22 14:48:31 <psykose> if you do pkggroups=something and install a file as something which on host ended up being 412, then someone installs the apk with pre-install addgroup something, and that file, how does it match?
2023-06-22 14:48:59 <psykose> does apk also keep the name and check?
2023-06-22 14:49:16 <psykose> i don't think there's any guarantee the numbers will ever end up being the same
2023-06-22 14:49:33 <ikke> it matches by name
2023-06-22 14:49:37 <nmeum> yea it matches by name
2023-06-22 14:49:42 <psykose> i guess that works
2023-06-22 14:49:49 <nmeum> I think tar itself does it the same way
2023-06-22 14:49:50 <ikke> it's tar that does that
2023-06-22 14:49:56 <nmeum> *nod*
2023-06-22 14:51:13 <ikke> tar --numeric-owner overrides that
2023-06-22 14:52:39 <psykose> wonder how other tar-generatting pipelines work with it then
2023-06-22 14:52:51 <psykose> inside a namespace that can't have >1 group, but they want >1 group in the tar
2023-06-22 14:52:59 <psykose> aside from the obvious 'just dont do it lol'
2023-06-22 14:57:10 <nmeum> is the tarball even created in the rootbld?
2023-06-22 14:57:17 <nmeum> nvm, it is indeed part of rootbld_actions
2023-06-22 14:57:41 <nmeum> but: it is created in a fakeroot within the bwrap so idk how that affects things in this regard
2023-06-22 14:59:43 <nmeum> anyways reverting https://gitlab.alpinelinux.org/alpine/abuild/-/commit/84d7b7693d44a95d4aba4ea44bd768e2512d92cb does indeed make abuild-addgroup work again inside the rootbld
2023-06-22 15:00:21 <nmeum> maybe it's better to pollute the host instead of not having rootbld work for APKBUILDs with $pkguser/$pkggroups? could also print a warning if rootbld created a group or something as a workaround
2023-06-22 15:04:26 <psykose> we could revert it but i'm just not sure if it works or not
2023-06-22 15:04:42 <psykose> if you revert it and doing install -g works inside package in rootbld then go for it
2023-06-22 15:04:50 <psykose> if not then idk, it's broken anyway
2023-06-22 15:07:12 <nmeum> alright, will double check and revert it if it works
2023-06-22 15:55:37 <psykose> it's not a bwrap peculiarity but a kernel limitation
2023-06-22 15:55:49 <psykose> though there is the new uidmap stuff https://github.com/containers/bubblewrap/issues/468
2023-06-22 15:56:27 <psykose> seems https://github.com/containers/bubblewrap/blob/main/demos/userns-block-fd.py shows how to do it already with the shadow utils
2023-06-22 15:56:31 <psykose> another day
2023-06-22 17:11:43 <nmeum> psykose: yes, i was just handwaving that part
2023-06-22 19:31:04 <eletrotupi> psykose: you've mentioned that we should create a branch before opening a PR to aports, any specific conventions regarding that?
2023-06-22 19:31:24 <psykose> you run git branch
2023-06-22 19:31:32 <eletrotupi> also, can't find anything related to that in the wiki neither on docs.a.o
2023-06-22 19:31:48 <ikke> eletrotupi: it's a common git workflow
2023-06-22 19:31:50 <psykose> idk why the wiki would tell you how to use git
2023-06-22 19:31:56 <Habbie> eletrotupi, likely because all projects work like this
2023-06-22 19:32:05 <Habbie> eletrotupi, which is, i've noticed, a thing that's hard for people to discover
2023-06-22 19:32:09 <psykose> (this might sound stupid but it's literally git 101)
2023-06-22 19:32:14 <eletrotupi> psykose: don't be condescending
2023-06-22 19:32:15 <Habbie> eletrotupi, "yes everybody does that" "ok how would i have known"
2023-06-22 19:32:34 <eletrotupi> I know how to create a branch, I'm asking if there's a specific convention to follow
2023-06-22 19:32:45 <ikke> By reading https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows :P
2023-06-22 19:32:47 <psykose> there is not
2023-06-22 19:33:09 <ikke> branches are short-lived
2023-06-22 19:33:16 <ikke> they are only relevant to you
2023-06-22 19:33:29 <ikke> (topic branches, that is)
2023-06-22 19:36:56 <eletrotupi> thanks
2023-06-22 19:38:10 <psykose> the only conventions regarding aports is master/the branches and commitstyle.md
2023-06-22 19:38:42 <psykose> commitstyle already says all of that
2023-06-23 06:50:13 <PureTryOut> are BAD signatures still resolved by rebuilding the package through a pkgrel bump?
2023-06-23 06:50:42 <Newbyte> PureTryOut: alpine-repo-tools can't resolve it?
2023-06-23 06:50:49 <PureTryOut> idk what that is
2023-06-23 06:50:55 <Newbyte> PureTryOut: apk add alpine-repo-tools´
2023-06-23 06:51:05 <PureTryOut> That I understand lol
2023-06-23 06:51:29 <Newbyte> e.g. repo-tools fastly purge pkg --origin=vim --release=v3.18
2023-06-23 06:52:58 <PureTryOut> ah it did the trick, awesome thanks
2023-06-23 16:39:26 <psykose> what did you get a bad signature on
2023-06-23 17:20:20 <dhruvin> I get one on libbz2-1.0.8-r5 from 3.18 aarch64
2023-06-23 17:28:48 <ikke> I don't see anything that would warant that, but perhaps an interrupted download
2023-06-23 17:30:50 <psykose> can't reproduce
2023-06-23 17:30:59 <psykose> from dl-cdn
2023-06-23 17:32:06 <dhruvin> I tried to reinstall it a few times (don't have a cache enabled either). I'll investigate more and let you know if I can find anything.
2023-06-23 17:32:25 <psykose> if you just `apk fetch libbz2` and sha1sum it what do you get
2023-06-23 17:32:40 <ikke> dhruvin: do you use dl-cdn as mirror?
2023-06-23 17:33:11 <dhruvin> yes, dl-cdn
2023-06-23 17:34:05 <dhruvin> 9ddc71d1a06bd38570b0683cb0794065dbc8211b  libbz2-1.0.8-r5.apk
2023-06-23 17:35:52 <psykose> i get 6fa7b3545cc1408111987faaf6d78fb992bad4fe
2023-06-23 17:36:15 <psykose> hm
2023-06-23 17:36:22 <psykose> could compare the contents i guess
2023-06-23 17:36:34 <dhruvin> I changed latest-stable -> v3.18 and it worked
2023-06-23 17:36:54 <psykose> that doesn't make much sense
2023-06-23 17:37:20 <psykose> strange
2023-06-23 17:37:39 <dhruvin> Trying to reproduce it with latest-stable
2023-06-23 17:38:10 <dhruvin> Yes, can reproduce
2023-06-23 17:39:14 <ikke> I can purge latest-stable
2023-06-23 17:39:47 <psykose> did that on release though and it was never rebuilt
2023-06-23 17:39:53 <psykose> also -r5 is only in 3.18 to begin with
2023-06-23 17:40:03 <ikke> latest-stable == 3.18
2023-06-23 17:40:20 <psykose> the only way that would go wrong is if it fetched some old edge -r5 instead
2023-06-23 17:40:27 <psykose> there's no other -r5's that would exist
2023-06-23 17:40:38 <psykose> so i'm confused :p
2023-06-23 17:41:01 <dhruvin> I never changed latest-stable to edge or something else
2023-06-23 17:41:27 <dhruvin> I just setup this pi 2-3 days ago, from 3.18.2
2023-06-23 17:41:42 <dhruvin> Do you want me to share the libbz2 that's incorrect?
2023-06-23 17:41:54 <ikke> switching to edge does not cause this
2023-06-23 17:42:25 <ikke> What usually causes this is if the package gets updated with the same name. The apkindex has the new hash, but the cached version is still the old one
2023-06-23 17:43:47 <dhruvin> Makes sense
2023-06-23 17:46:56 <dhruvin> Here's what I got with latest-stable: https://0x0.st/HQqr.8-r5.apk
2023-06-23 17:56:48 <ikke> dhruvin: I purged it, can you verify it now?
2023-06-23 17:58:13 <dhruvin> It works. Thanks!
2023-06-23 17:59:02 <dhruvin> Before reporting this issue, I did try repo-tools on v3.18 but it did not work. Did you do something else?
2023-06-23 18:00:36 <ikke> latest-stable is a separate path, but as latest-stable is not an official release (it's just a symlink), repo-tools does not allow you to select it
2023-06-23 18:00:44 <ikke> I've manually purged it
2023-06-23 18:01:26 <dhruvin> Okay
2023-06-23 18:01:59 <dhruvin> Is it unadvised to use latest-stable in /etc/apk/repositories?
2023-06-23 18:03:18 <ikke> Should generally be fine
2023-06-23 18:03:26 <ikke> at release time, we do a mass purge of the cache
2023-06-23 18:04:29 <dhruvin> TIL: unadvised != advised against :(
2023-06-23 18:05:15 <dhruvin> I'll keep latest-stable and see if I get any errors (while setting up the pi). Thanks for quickly fixing it :)
2023-06-24 23:48:00 <tarahb> Is this the right place to talk about apk-tools?
2023-06-24 23:53:46 <tarahb> Hello people, is this the place to talk about apk-tools?
2023-06-24 23:54:58 <Ellenor> tarahb, is that related to working with alpine packages?
2023-06-24 23:55:11 <Ellenor> If so, it might be on-topic, if apk-tools is first-party from Alpine
2023-06-25 00:19:25 <tarahb> apk-tools has the 'apk' binary. So I guess it's first party?
2023-06-25 00:23:45 <tarahb> I'm trying to setup apk with a single repository that hosts all my apk packages. Searching for a way to download the packages in that repository into a local folder rather than installing it globally. I'm doing this for setting up c++ development.
2023-06-25 01:47:42 <pj> tarahb: apk fetch
2023-06-25 01:48:08 <pj> or just wget/rsync the mirror
2023-06-25 03:46:41 <tarahb> wener: Didn't know about `apk fetch` before. Going to try it out.
2023-06-25 03:53:07 <tarahb> pj: I'm trying to use 'apk' alongside pacman. Does it work like that? I'm trying move some of my suckless forks to a repo and add that to my mirrorlist. But freshly installed apk cannot find the database directory it seems. I tried `apk add --initdb`.
2023-06-25 11:51:47 <Ellenor> oh, right. so like me wanting to run xbps on freebsd.
2023-06-25 12:40:24 <pj> tarahb: i have no idea what are you trying to do, but every package manager works the same way, they manage packages on the host filesystem, if you want to use other package managers you usually have to give them specific place to not conflict with OS package manager
2023-06-25 12:41:06 <pj> apk add --initdb doesn't do anything unless you give it packages to install and root path
2023-06-26 01:53:38 <tarahb> I'm trying to use 'apk' alongside pacman. Does it work like that? I'm trying move some of my suckless forks to a repo and add that to my mirrorlist. But freshly installed apk cannot find the database directory it seems. I tried `apk add --initdb`.
2023-06-26 01:56:45 <psykose> no
2023-06-26 01:57:04 <psykose> you can't have two package managers manage the same / in a way that makes sense
2023-06-26 02:03:40 <sam_> lol
2023-06-26 02:04:45 <tarahb> I don't want to use the '/' for installing the packages. I'm curious to see if I can install it to any user path like ~/.local/
2023-06-26 02:05:07 <psykose> sure, that would work
2023-06-26 02:06:13 <tarahb> I compiled a version of apk-tools for windows the other day using mingw-w64. There is a busybox port for windows, so I'm trying to make `apk` my cross-platform package installer.
2023-06-26 02:07:35 <tarahb> psykose: Is it possible to run apk without root permission? pacman has no way of running without root. If I'm going to install packages to .local does apk still require root?
2023-06-26 02:08:43 <tarahb> psykose: Do you know what are the necessary files to pass to apk to run it? For example apk complains that it can't find database and log file in root.
2023-06-26 02:09:13 <psykose> you have to paste a log of what you did
2023-06-26 02:10:24 <psykose> generally though you have to init the root with the set of repositories and the keys
2023-06-26 02:10:30 <psykose> use https://github.com/alpinelinux/alpine-chroot-install/blob/master/alpine-chroot-install as a reference
2023-06-26 02:11:34 <psykose> --root has to be used when not /
2023-06-26 02:13:27 <tarahb> psykose: https://txtclipboard.com/5049 This is basically what I tried after installing apk-tools in arch.
2023-06-26 02:19:18 <tarahb> Okay, the alpine-chroot-install is pretty awesome.
2023-06-26 02:23:53 <tarahb> Instructions unclear, I deleted the alpine folder and now my /dev/null file is missing. What does the alpine-chroot-install actually do?
2023-06-26 02:24:27 <tarahb> hahahha, did I delete my some of my / files?
2023-06-26 02:25:21 <abby> if it's just /dev and /sys and such, rebooting should fix it
2023-06-26 02:25:34 <tarahb> I'm scared to reboot
2023-06-26 02:26:27 <tarahb> abby: Okay my home files are there, so it must be what you think
2023-06-26 02:28:44 <psykose> that link is just empty
2023-06-26 02:34:25 <tarahb> I'
2023-06-26 02:36:58 <tarahb> I'm back! /dev/null is present again. I'm facing something really weird. I have my files in home but dot files are missing. I checked out my dotfiles and git says the file is there, but .config folder is empty. Really weird.
2023-06-26 03:20:31 <tarahb> Thanks for the alpine-chroot-script. I removed the mount parts and kept only the key part and the initdb part. Works well than I expected! Really neat. https://pastebin.com/9RU5Pixa
2023-06-26 03:21:28 <tarahb> I'm getting an warning though, `ERROR: 4 errors updating directory permissions`. I'm assuming it's trying to update the files in /. Can we make apk not do that?
2023-06-26 03:25:15 <psykose> and how did you verify that assumption?
2023-06-26 03:25:17 <psykose> :p
2023-06-26 03:25:41 <psykose> it's not from /
2023-06-26 03:28:13 <tarahb> psykose: The alpine folder I gave to -d is just inside my home folder. So I thought `apk` must be trying to change the files in /. It's still an assumption.
2023-06-26 03:56:21 <tarahb> The error is causing me no trouble really, so going to ignore it for now. Thanks people. Finally got it working.
2023-06-26 03:57:54 <psykose> it's probably apk --root as a user and the things it installs are suid so it can't make them suid since you need to be root to do that
2023-06-26 03:58:56 <psykose> that, and any ownership (can't create root-owned files as a user)
2023-06-26 03:59:01 <psykose> etc
2023-06-26 04:00:06 <tarahb> psykose: Can I make the installs as non suid?
2023-06-26 04:00:16 <psykose> it already is?
2023-06-26 04:01:02 <tarahb> Oh got it. So you mean the packages are like that?
2023-06-26 04:07:54 <tarahb> The other day I compiled apk for windows(mingw-w64) and mac. The meson.build fails to find the openssl libs for some reason even if I set the correct PKG_CONFIG_PATH. Also there is an issue with libfetch, it doesn't compile before apk. I had simplified the Makefile a bit, and using the pkg-config and simple rules apk-tools compiles with help doc. I saw in the README that the
2023-06-26 04:07:57 <tarahb> Makefile will be deleted after 3 release. It's really hard to port to new platforms with meson. Can we keep the Makefile around?
2023-06-26 04:11:13 <abby> meson supports mingw already doesn't it?
2023-06-26 04:17:37 <psykose> that's a lot of words that doesn't include a log of what you typed, what environment you ran it in, and the output log
2023-06-26 04:18:14 <psykose> abby: ye
2023-06-26 04:19:13 <tarahb> abby: It does? didn't know about it. Compiler support is not the problem though. meson fails to find the openssl in both windows and mac even if the correct PKG_CONIFG_PATH is set. Also Makefile bootstrapping is really easy - `make` vs three line commands.
2023-06-26 04:22:32 <tarahb> psykose: I'm currently trying this on arch linux. I tried the `tree | grep log` in the folder given to --root. Can't find the logfile. I can't find it in /var/ folder either. Do we have to enable it explicitly?
2023-06-26 04:22:57 <psykose> logfile of what? you tried to build something and the output is on your screen
2023-06-26 04:40:27 <tarahb> psykose: logfile of apk
2023-06-26 04:40:43 <psykose> not sure how that is relevant but it doesn't have on on 2.x
2023-06-26 04:40:49 <psykose> master branch has one to somewhere
2023-06-26 04:41:01 <tarahb> ooooh got it thanks
2023-06-26 04:45:16 <psykose> i think the default is just /var/log/apk* ish
2023-06-26 04:45:21 <psykose> you can find the commit with a grep
2023-06-26 04:45:27 <psykose> but 2.x won't have it so
2023-06-26 04:58:24 <tarahb> Yeah archlinux has only 2.12 version currently. I guess I have to recompile.
2023-06-26 05:32:56 <pj> or just paste output from whatever you run
2023-06-26 05:35:30 <ikke> master branch is apkv3, which is quite different from v2
2023-06-26 05:51:53 <tarahb> pj: This is pretty much what I ran, https://pastebin.com/9RU5Pixa. Not able to figure out why the ERROR occurs(it's just a warning).
2023-06-26 05:53:07 <psykose> i already told you why
2023-06-26 08:19:33 <tarahb> psykose: Yes. Was just responding to pj since he asked for the output of commands.
2023-06-26 14:57:48 <elibrokeit> tarahb: since meson just runs pkg-config, I find it strange to imagine that you could not detect openssl with meson but could detect openssl with Makefiles
2023-06-26 14:58:28 <elibrokeit> but perhaps if you post the meson logfile that is printed out to the console on failures (specifically: builddir/meson-logs/meson-log.txt) we could help debug the problem
2023-06-27 17:20:37 <tarahb> eleksir: I'm just seeing your message, if you are still interested in helping me debug here is the full commands I ran, https://pastebin.com/DBdSDPwg. And here is the meson error log, https://pastebin.com/0VwmYs3K
2023-06-27 17:21:24 <tarahb> It seems that meson is not failing at configure stage but ninja doesn't have the include flags for some reason
2023-06-27 17:28:19 <psykose> that's probably because libfetch doesn't depend on openssl anywhere
2023-06-27 17:29:10 <psykose> can you try https://img.ayaya.dev/TeGxlNb0rTOp as a hack
2023-06-27 17:32:48 <tarahb> psykose: Yes this works perfectly! thanks.
2023-06-27 17:33:01 <psykose> these meson files are quite busted
2023-06-27 17:33:05 <psykose> also you tagged the wrong person
2023-06-27 17:33:24 <tarahb> okay cool
2023-06-27 17:39:24 <tarahb> I'm seeing some portability efforft in apk-tools to run it on mac in the repo. But the abuild command is not working in mac with it's default bsd commands. tar, date and stat seems to slightly vary on these platforms. 
2023-06-27 17:40:29 <psykose> the two projects have nothing to do with eachother
2023-06-27 17:41:15 <psykose> there are zero users of abuild on macos so that doesn't make sense
2023-06-27 17:44:40 <tarahb> Got disconnected for some reason. As I was saying, apk-tools with mac support is not really useful on it's own. Is there any port of the abuild that works on bsds?
2023-06-27 17:45:16 <psykose> <psykose> there are zero users of abuild on macos so that doesn't make sense
2023-06-27 17:45:16 <psykose> <psykose> the two projects have nothing to do with eachother
2023-06-27 17:45:35 <psykose> i have no idea who wants to use alpine's build intended for alpine on a different OS but i don't care
2023-06-27 17:45:39 <psykose> fork it and add whatever you want
2023-06-27 17:48:32 <psykose> you can 'try' to make the use of tar/date/stat portable but the common subset of that is complete trash for tar/date and there is no subset for stat (it's not a portable util)
2023-06-27 17:48:35 <psykose> so idk what the point is
2023-06-27 17:52:42 <tarahb> psykose: I am not interested in macos myself, but it is the closest BSD I could find for now. Usually whatever works on mac, works on BSD. But I do understand your sentiment regarding other OSes and having to maintain them.
2023-06-27 17:55:32 <psykose> it's not about maintaining it, it's just not what the tool is
2023-06-27 17:58:35 <psykose> so what you're asking is something akin 'can abuild support my usecase of building a specific apk2 repository from multiple operating systems to maintain a dependency tree for stuff i work on at work'
2023-06-27 17:58:41 <psykose> and the answer to that is very simple- 'no'
2023-06-27 17:58:53 <psykose> if you like where it starts, you can fork it and add whatever functionality you want
2023-06-27 17:59:57 <psykose> abuild itself doesn't maintain a repository either, that would be buildrepo from lua-aports that invokes abuild, ...
2023-06-27 18:14:53 <tarahb> psykose: I don't care about the stuff I do on work as much as I can get my suckless tools working on multiple platforms as possible, so your gist of my thought was partially right. I was just curious why apk-tools had support for bsd and abuild's was missing. If it indeed was missing I thought I could help write a part of it. I didn't know they were two separate projects.
2023-06-28 03:38:47 <smcavoy6> Hello.. I am about to attempt to compile a kernel for a Rock pi 4b and was wondering if any major advances have happened for crosscompiling kernels... 
2023-06-28 04:45:28 <ikke> smcavoy: easier to use qemu-user
2023-06-28 04:48:27 <ikke> smcavoy: apk add qemu-aarch64 qemu-openrc; rc-service start qemu-binfmt
2023-06-28 05:20:04 <smcavoy> ikke cool, thanks!
2023-06-28 15:06:23 <z4w3p> test\
2023-06-29 02:44:47 <smcavoy> is there a quick way to re-sign a package? I'd rather that then rebuild (2hr build time) with the new key...
2023-06-29 04:42:18 <ikke> abuild sign
2023-06-29 04:43:25 <ikke> sorry, ignore that
2023-06-29 04:47:26 <ikke> You'd have to unpack the apk, resign the control.tar.gz with abuild-sign, and then repack it
2023-06-29 04:48:14 <ikke> And it's even more complicated, as an apk is 2 gz streams
2023-06-29 04:56:02 <psykose> you'd have to write a tool to get back the two streams and then abuild-sign control.tar.gz again
2023-06-29 04:56:41 <psykose> it would basically be `magic-tool some.apk && abuild-sign control.tar.gz && cat control.tar.gz data.tar.gz > some.apk`
2023-06-29 04:56:52 <psykose> and then you have to recreate+resign the apkindex of the repo after too
2023-06-29 04:57:27 <psykose> this as one example https://unix.stackexchange.com/a/688412
2023-06-29 08:52:35 <ncopa> i think we need a tool to resign packages
2023-06-29 20:12:09 <smcavoy> thanks! I ended up scaling up to a 8 core arm64 to compile the kernel, 32min. not that bad :)
2023-06-30 06:25:26 <clandmeter> goodmorning
2023-06-30 06:25:29 <clandmeter> ncopa: we already have it
2023-06-30 06:25:40 <clandmeter> regarding resign
2023-06-30 06:25:53 <clandmeter> but im not sure if i still have a copy...
2023-06-30 06:55:38 <tarahb> I'm getting an 'ERROR: emsdk: found textrels' error while packaging with abuild. Is it possible to disable the textrels check for this?
2023-06-30 07:14:50 <tarahb> I tried, options="textrels" and that seems to resolve it.
2023-06-30 09:16:50 <psykose> no, it should not have textrels
2023-06-30 09:20:43 <psykose> 'emsdk' is also not a compiler
2023-06-30 09:22:18 <psykose> rather it's a huge mess of a bunch of vendored stuff that doesn't accomplish anything interesting
2023-06-30 09:22:21 <psykose> please don't package that at all
2023-06-30 09:22:21 <psykose> thanks
2023-06-30 09:24:09 <Arnavion> I'm almost afraid to ask, but what's wrong with the edge ARM builders this time? :D
2023-06-30 09:25:18 <psykose> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10800/
2023-06-30 09:25:21 <psykose> same thing as last time
2023-06-30 09:25:30 <Arnavion> rip
2023-06-30 09:25:32 <ikke> Still network issues, but ee received a different server for the time being which I'm setting up
2023-06-30 09:44:21 <tarahb> psykose: I don't know what textrels is, have to read up on it. You are right about emsdk though, it is a web of madness.
2023-06-30 09:44:38 <psykose> i mean it's just a shell script that downloads a precompiled version of a few things
2023-06-30 09:44:53 <psykose> it's not really a thing at all :p
2023-06-30 09:49:24 <tarahb> psykose: Actually there is compatability layer for converting existing gl projects by providing ready js versions of sdl and glfw but I've always considered it as bloat.
2023-06-30 22:07:08 <Ermine> Have gitlab stopped sending mails to package maintainers if there are merge requests related to their packages?
2023-06-30 22:44:38 <psykose> ye