2023-01-01 22:05:25 <psykose> ikke: the bot is going in a loop :) !42815
2023-01-01 22:05:42 <ikke> lol
2023-01-02 08:18:08 <clandmeter> wow
2023-01-02 08:18:17 <clandmeter> that most active MR off all time
2023-01-02 08:18:36 <clandmeter> i hope it doesnt send emails for every change :)
2023-01-02 08:27:24 <ikke> clandmeter: You haven't seen the last one yet
2023-01-02 08:44:45 <ikke> !40787
2023-01-02 09:39:54 <donoban> lol
2023-01-02 09:41:31 <ikke> Hard part is figuring out what is triggering it
2023-01-02 15:41:03 <clandmeter> for anyone using docker-abuild, the images should be weekly updated again. the images are now hosted on our own registry so you need an update dabuild.
2023-01-02 15:47:33 <ikke> pj: ^
2023-01-02 16:05:45 <vkrishn> d
2023-01-02 18:18:02 <PureTryOut> Cogitri: any chance you could look at https://github.com/Cogitri/gnome-software-plugin-apk/pull/61?
2023-01-02 19:15:48 <Cogitri> PureTryOut (matrix.org): Will do, thanks for the ping
2023-01-02 19:16:31 <ikke> Cogitri: We had some fun with the new aports-qa-bot btw :)
2023-01-02 19:17:01 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/42815
2023-01-02 19:23:20 <Cogitri> ikke: Oh wow :D
2023-01-02 19:23:41 <ikke> There was one even worse
2023-01-02 19:23:58 <ikke> It appears that setting a label triggers another webhook
2023-01-02 19:24:04 <ikke> but not entirely sure what's the cause
2023-01-02 20:48:19 <omni> I hope it also makes a sound when it does a thing
2023-01-02 20:49:04 <ikke> ding ding ding ding ding ding ding
2023-01-02 20:49:16 <minimal> omni: it goes "ping!"? (Monty Python ref)
2023-01-02 20:52:56 <omni> yes
2023-01-02 21:34:35 <pj[m]> <ikke> "pj: ^" <- that's great but are they fixed or are they just "we un-borked the cron"
2023-01-02 21:37:35 <pj[m]> yeah, it's just minor cron unborking + scripts
2023-01-02 21:37:43 <pj[m]> doas/sudo is most likely still broken
2023-01-02 21:39:52 <clandmeter> pj[m]: things are still broken
2023-01-02 21:40:09 <clandmeter> i am trying to find out whats wrong
2023-01-02 21:40:35 <pj> clandmeter: which thing
2023-01-02 21:40:44 <pj> I fixed the images long time ago so maybe I can help
2023-01-02 21:41:12 <pj> https://gitlab.alpinelinux.org/pj/docker-abuild/-/commit/f33a93231f33b820cf4ff1a83b9b97896f840318
2023-01-02 21:42:14 <clandmeter> there is something wrong in the ci steps
2023-01-02 21:42:19 <pj> it still probably needs to be fixed because of all the shenanigans in alpine-baselayout
2023-01-02 21:42:27 <pj> erm alpine-base
2023-01-02 21:43:08 <pj> wrong how where
2023-01-02 21:43:38 <clandmeter> i dont know yet
2023-01-02 21:43:44 <clandmeter> the logic is from ikke
2023-01-02 21:43:45 <pj> *confusion*
2023-01-02 21:44:03 <pj> ok, so what is the thing you know that is wrong or not wrong?
2023-01-02 21:44:06 <clandmeter> but i think he alraedy went to bed
2023-01-02 21:44:23 <pj> mh
2023-01-02 21:44:36 <clandmeter> the images are all based on 3.14
2023-01-02 21:44:45 <pj> oh lol
2023-01-02 21:45:29 <clandmeter> https://gitlab.alpinelinux.org/alpine/docker-abuild/-/pipelines/148415
2023-01-02 21:46:04 <pj> I'm already looking at the build logs
2023-01-02 21:46:26 <pj> why is it pulling ci-{hash}-{arch}
2023-01-02 21:46:37 <clandmeter> this is where things go wrong
2023-01-02 21:46:47 <clandmeter> its an intermediate image
2023-01-02 21:47:11 <clandmeter> to be used by manifest
2023-01-02 21:47:35 <clandmeter> normally it would be an artifact 
2023-01-02 21:47:48 <clandmeter> but ikke chose to do it via the registry
2023-01-02 21:48:47 <pj> gimme a sec
2023-01-02 21:49:18 <clandmeter> i think the name of that image should be job depended, not only commit hash.
2023-01-02 21:50:48 <pj> it pulls correct image
2023-01-02 21:50:49 <pj> for build
2023-01-02 21:52:34 <clandmeter> yes but publish does not
2023-01-02 21:53:41 <pj> because it always pulls?
2023-01-02 21:53:49 <pj> what's with the pulling and the image
2023-01-02 21:54:14 <pj> why it has to be pulled for build|publish
2023-01-02 21:58:21 <pj> well, it's late and I've been in constant pain for past 12h trying to setup gitlab via terraform, so ikke can ping me later if it won't be fixed until I wake up :) goodnight
2023-01-03 12:51:59 <Ermine> What is $MOCK variable for in alpine-conf scripts?
2023-01-03 13:00:12 <ikke> preventing actually calling certain programs during testing
2023-01-03 14:02:07 <pj> ikke: hi
2023-01-03 17:00:52 <dancesWithCycles> Hi, anyone mind sharing with me how I build a C programm for Alpine --arch aacrh64 on my Debian host so that I can run it on my PostmarketOS host?
2023-01-03 17:01:45 <dancesWithCycles> I have also a Alpine host if it makes the build procedure more easy.
2023-01-03 17:02:01 <Ermine> Of course cross-compilation is harder.
2023-01-03 17:02:39 <skarnet> dancesWithCycles: the host isn't very important, the main point is that you'll need a cross-toolchain targeting your postmarketOS machine.
2023-01-03 17:02:44 <Ermine> dancesWithCycles: I guess you need to get musl built for aarch64 and its headers and aarch64-linux-musl compiler or something like this
2023-01-03 17:03:19 <skarnet> there are musl toolchains for aarch64 on https://skarnet.org/toolchains/ as well as https://musl.cc/
2023-01-03 17:04:07 <skarnet> but the real question is, do these toolchains address the target exactly? because especially with arm, there are a lot of options and quirks and not all targets are equal
2023-01-03 17:04:23 <skarnet> less so with armv8 (aarch64) than with armv7, but still
2023-01-03 17:04:54 <ikke> The recommendation seems to be using something like qemu-user-static + binfmt
2023-01-03 17:05:07 <skarnet> that's cute
2023-01-03 17:05:56 <q66> abuild can't crosscompile
2023-01-03 17:06:23 <skarnet> dancesWithCycles asked how to build a C program, not a package
2023-01-03 17:06:39 <skarnet> now if they need to build packages... that's another layer of complexity indeed
2023-01-03 17:07:24 <ikke> We build rv64 that way
2023-01-03 17:08:17 <skarnet> qemu probably works reasonably well for rv64 because there aren't too many rv64 machines in the wild playing fast and loose with specs and variants
2023-01-03 17:08:26 <skarnet> arm is much more of a gamble
2023-01-03 17:08:51 <q66> it works the same as for anything else
2023-01-03 17:09:05 <q66> the main problem is that if you want to natively build rv64, qemu-user is *by far* the fastest way to do it
2023-01-03 17:09:15 <q66> provided the machine that does the emulation is good enough
2023-01-03 17:09:40 <q66> i tested this a while back https://gist.github.com/q66/ec52e90c53e54eb293ebd6de8d58c435
2023-01-03 17:12:15 <dancesWithCycles> Is building a C program different from  building an *.apk? I am wondering how the other *.apk's are build for Alpine and PostmarketOS? Can't I just follow the same way?
2023-01-03 17:13:11 <ikke> dancesWithCycles: please do not cross-post
2023-01-03 17:13:26 <skarnet> ... yeah, building a package for a distro isn't the same as building a single binary :) and if you want to build an .apk then ikke's right
2023-01-03 17:14:37 <skarnet> q66: so qemu-user is 10 times slower than x86... and native rv is 75+ times slower? really? o.O
2023-01-03 17:15:02 <dancesWithCycles> Sorry. Is there a guide on building a .apk for people that did not do it before?
2023-01-03 17:15:05 <q66> skarnet: native rv64 with the fastest hardware currently available, no less
2023-01-03 17:15:33 <Ermine> dancesWithCycles: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2023-01-03 17:15:37 <skarnet> that's boding well for the future of the platform
2023-01-03 17:15:39 <q66> in fact, emulated full qemu-system is still faster than native hw
2023-01-03 17:15:48 <q66> (though per-core is a bit slower)
2023-01-03 17:15:52 <q66> (but not by much)
2023-01-03 17:16:01 <skarnet> yeah I can see that
2023-01-03 17:16:45 <q66> qemu-system is probably a bit more robust, because you don't have to worry about syscall translation like with qemu-user (which is imperfect and some of them are missing, which occasionally results in e.g. testsuite failures)
2023-01-03 17:17:11 <q66> but it's a lot slower because non-native i/o and it has to emulate a lot more
2023-01-03 17:17:21 <q66> plus qemu-user just scales with all your cores
2023-01-03 17:17:32 <q66> as every process runs through an independent emulator
2023-01-03 17:17:47 <skarnet> how was the architecture not laughed out of the room? how did this even pass meetings? how did it go all the way to shipping? don't people do benchmarks?
2023-01-03 17:18:09 <q66> better hw will probably ship this year, but it still won't be great
2023-01-03 17:18:15 <q66> i expect it to beat raspberry pi 4 at least
2023-01-03 17:18:29 <q66> hifive unmatched performs similarly to raspberry pi 3
2023-01-03 17:18:33 <q66> you'd see similar perf on that
2023-01-03 17:18:58 <q66> maybe a bit slower because shittier i/o (hifive unmatched can use nvme root)
2023-01-03 17:19:08 <q66> but cpu should be a wash
2023-01-03 17:19:19 <ikke> skarnet: apparently all the technologies that make cpus fast are proprietary 
2023-01-03 17:19:21 <ikke> :)
2023-01-03 17:20:03 <skarnet> ikke: something something speculative execution spectre something something
2023-01-03 17:20:17 <q66> yeah the cpu in the unmatched is a "simple" in-order soc
2023-01-03 17:20:30 <q66> in any case i also build chimera for riscv with qemu-user
2023-01-03 17:20:57 <q66> unlike abuild cbuild supports transparent crosscompiling, but crosscompiling still has jankier results than a native (but imperfect) build
2023-01-03 17:21:07 <q66> plus you can't make *everything* crosscompile
2023-01-03 17:21:22 <q66> at least not in a way that outputs artifacts that are identical to ones that are built natively
2023-01-03 17:21:39 <skarnet> don't get me started with autotools fkn *guessing* target sysdeps
2023-01-03 17:21:56 <ikke> q66: probably a distinction without meaning, but abuild does support cross-compiling, we just don't support a general purpose cross-compile toolchain
2023-01-03 17:22:59 <q66> i mean that cbuild supports proper cross-compiling, including a general-purpose toolchain, helpers for common build systems that handle cross configure etc for you, as well as proper separation of host/sysroot makedepends, etc
2023-01-03 17:23:05 <q66> abuild doesn't take care of *any* of that
2023-01-03 17:23:33 <q66> with cbuild you just tell it the architecture and it can crossbuild most packages transparently with the template mostly only having to say which deps are for host and which deps are for sysroot
2023-01-03 17:24:07 <ikke> there is makedepends_host and makedepends_build
2023-01-03 17:24:19 <q66> apkbuilds don't typically follow it
2023-01-03 17:24:36 <ikke> only the ones we care about for cross-compiling
2023-01-03 17:25:26 <q66> i make cross-compilability the default, then packages which cannot crosscompile explicitly mark themselves as such
2023-01-03 17:25:35 <ikke> yes, different goals
2023-01-03 17:25:41 <q66> with apkbuild to make stuff cross compile you typically have to explicitly handle the cross cases in the template
2023-01-03 17:25:43 <ikke> Our goal is to build native
2023-01-03 17:25:48 <q66> mine is too
2023-01-03 17:25:58 <q66> all the prod packages are built native
2023-01-03 17:26:20 <q66> but i think having crosscompilation handled as well as possible is a worthy goal
2023-01-03 17:26:27 <q66> with as little work in the build template as possible
2023-01-03 17:26:31 <ikke> -
2023-01-03 17:26:53 <ikke> (sorry, accidentally sent that)
2023-01-03 17:29:06 <q66> i mainly want to give people a best-effort way to build packages for their crappy sbc's and so on when they don't care about shipping them
2023-01-03 17:29:16 <q66> plus the obvious bootstrap case that abuild handles too
2023-01-03 17:29:28 <q66> (though my cross-bootstrap works rather differently in practice)
2023-01-03 17:36:24 <q66> anyway the next board from sifive+intel will have 4 out-of-order cores
2023-01-03 17:36:33 <q66> it should be multiple times faster than what is currently available
2023-01-03 17:36:38 <q66> still won't be great though
2023-01-03 17:37:05 <q66> probably won't beat my emulated arrangement
2023-01-03 17:37:46 <q66> might be just good enough to sacrifice a bit of speed for the sake of not having to burn tons of power just to simulate a still-potato computer though
2023-01-03 17:38:33 <q66> being a lot faster at running stuff like configure scripts (which are largely bound to a single "core") might even it out a bit too
2023-01-03 17:38:41 <clandmeter> q66: have you tried qemu-user on arm64?
2023-01-03 17:38:56 <clandmeter> to emulate rv64
2023-01-03 17:39:02 <q66> no, but there is little point
2023-01-03 17:39:29 <q66> it won't be faster with equivalent hw, and the aarch64 hw i have access to are all a fair amount slower than the x86 i'm emulating on
2023-01-03 17:40:05 <clandmeter> we have decent arm64 hardware
2023-01-03 17:40:19 <q66> i'd expect it to be slower even if you had aarch64 host that had otherwise equivalent performance, because tcg is still a jit of a sort, and x86 is the most common host
2023-01-03 17:40:39 <q66> is it as decent as ryzen 5950x
2023-01-03 17:40:42 <q66> i doubt it is
2023-01-03 17:40:57 <clandmeter> im not sure
2023-01-03 17:41:04 <clandmeter> it has 80 cores
2023-01-03 17:41:19 <q66> probably an altra
2023-01-03 17:41:25 <q66> which means potato individual cores
2023-01-03 17:41:25 <clandmeter> ofc
2023-01-03 17:41:29 <q66> which will hurt you in emulation
2023-01-03 17:42:44 <q66> altra are neoverse n1 cores, which is in practice similar to cortex-a76
2023-01-03 17:42:49 <q66> nothing to call home about
2023-01-03 17:43:47 <q66> they'll probably perform similarly per-thread to my power9 boxes
2023-01-03 17:43:55 <q66> which is about half the speed of the ryzen?
2023-01-03 17:43:56 <q66> roughly
2023-01-03 17:44:34 <clandmeter> ill try it and see how it performs when i have some free time.
2023-01-03 17:44:41 <clandmeter> probably 2024 :)
2023-01-03 17:45:08 <q66> i think you'll find the results to be similar to what i said
2023-01-03 17:45:57 <q66> i haven't benchmarked these specifically,but i have a lot of hardware of different kinds a good idea of how they perform relatively to each other
2023-01-03 17:46:11 <q66> *and a
2023-01-03 17:46:44 <clandmeter> i believe you, but its fun to try anyways. the boxes are idle atm.
2023-01-03 17:50:14 <q66> it sucks these horse creek boards are only gonna have 4 cores
2023-01-03 17:50:27 <q66> if it was 8 cores or more they'd probably perform pretty well in builds
2023-01-04 08:52:33 <raspbeguy> Hello, I'm currently working on a port of the linux kernel with patches for Microsoft Surface hardware
2023-01-04 08:53:28 <raspbeguy> see here https://github.com/linux-surface/linux-surface
2023-01-04 08:54:02 <raspbeguy> I'm starting to have something that compile
2023-01-04 08:55:19 <raspbeguy> unfortunately my only Surface at home is in use and I cannot test it on it right now, so if someone here have a Surface and is willing to test it, that would be awesome
2023-01-04 12:27:38 <chereskata> Hey there, i noticed that hid-playstation module seems to be missing in the kernel
2023-01-04 12:32:24 <chereskata> Hey there, i noticed that hid-playstation module seems to be missing in the kernel
2023-01-04 12:32:37 <chereskata> linux-lts at least
2023-01-04 12:48:10 <ikke> chereskata: You can open an issue on https://gitlab.alpinelinux.org/alpine/aports
2023-01-04 12:53:25 <chereskata> Thanks
2023-01-04 14:29:49 <lmarz> i know the email isn't out yet, but i'd like to volunteer for the license policy team as discussed in tsc#6
2023-01-04 14:30:45 <ikke> lmarz: good to know
2023-01-04 14:31:12 <ikke> Feel free to leave a comment on that issue as well
2023-01-04 14:31:51 <lmarz> alright
2023-01-04 14:32:23 <ncopa> lmarz: awesome!
2023-01-04 15:20:34 <vkrishn> ikke: wiki.a.o is still being quoted to new users or outdated ?
2023-01-04 15:21:20 <vkrishn> thinking of starting a simple Q&A page 
2023-01-04 15:21:39 <ikke> It's a low priority to us
2023-01-04 15:21:43 <vkrishn> that can grow to individual page
2023-01-04 15:21:47 <vkrishn> ok
2023-01-04 16:57:52 <Ermine> minimal: you may want to add py3-pyserial to cloud-init deps
2023-01-04 17:09:10 <minimal> Ermine: nope, I specifically did nto add it - the README.Alpine talks about it
2023-01-04 17:09:18 <minimal> s/nto/not/
2023-01-04 17:09:18 <alpine-meetbot> minimal meant to say: Ermine: nope, I specifically did not add it - the README.Alpine talks about it
2023-01-04 17:10:27 <Ermine> minimal: oic
2023-01-04 17:16:47 <minimal> Ermine: cloud-init isn't really a package that you simply install, there's a degree of work to tailor things for your particular situation
2023-01-04 21:52:24 <elly> psykose: I came back to my chromium-musl work and I think there may be more patches in aports than when I started :(
2023-01-04 21:52:40 <psykose> i'm pretty sure there's less
2023-01-04 21:52:47 <psykose> also the upstreamed ones aren't in 108 yet
2023-01-04 21:52:52 <psykose> so it would be future removed
2023-01-04 21:52:53 <psykose> hah
2023-01-04 21:52:55 <elly> ah okay
2023-01-04 21:53:02 <elly> yeah I didn't bother merging them to 108
2023-01-04 21:54:00 <psykose> 109 is $soon so that was a few iirc
2023-01-04 21:54:27 <elly> 109 stable release is in a week yeah
2023-01-04 22:09:27 <elly> oh man uClibc defines __GLIBC__?
2023-01-04 22:09:29 <elly> that's deranged
2023-01-04 22:18:58 <psykose> yes, because of that the formal glibc check is #if defined(__GLIBC__) && !defined(__UCLIBC__)
2023-01-04 22:19:01 <psykose> or something along those lines
2023-01-04 22:20:03 <psykose> can you imagine how fun these ifdef chains would get if musl actually caved into some $demand somewhere to add __MUSL__? it would be so much joy
2023-01-04 22:23:08 <elly> dislike
2023-01-04 22:23:30 <elly> and macos libc has execinfo.h and backtrace() despite not being __GLIBC__
2023-01-04 22:23:32 <elly> oh no
2023-01-04 22:24:15 <psykose> don't suppose gn has a HAS_EXECINFO_H or similar
2023-01-04 22:24:24 <psykose> that one you have to test for
2023-01-04 22:24:41 <elly> not yet it doesn't
2023-01-04 22:24:59 <psykose> there's no way to do configure checks in gn in a generic way? (i.e. compile some code)
2023-01-04 22:25:22 <psykose> in any case musl is really the exception here wrt execinfo- every other platform in the chromium codebase probably has it
2023-01-04 22:25:32 <psykose> actually, does bionic?
2023-01-04 22:25:38 <psykose> yep
2023-01-04 22:25:49 <psykose> :-)
2023-01-04 22:25:56 <elly> gn is really expressly not designed for that kind of thing
2023-01-04 22:26:03 <psykose> TIL i  guess
2023-01-04 22:26:05 <elly> it is intended to be used to build self-contained and pretty hermetic projects
2023-01-04 22:26:15 <elly> (ie "adapt to the surrounding system" is a non-goal)
2023-01-04 22:26:21 <psykose> i'd have expected at least.. something :p
2023-01-04 22:26:35 <psykose> it's very hard to write portable projects without configure checks
2023-01-04 22:26:45 <elly> https://gn.googlesource.com/gn/#what-gn-is-for
2023-01-04 22:26:51 <psykose> no wonder there's so much ifdef stuff and they came up with BUILDFLAG()
2023-01-04 22:26:58 <elly> most gn projects do this by simply vendoring all dependencies
2023-01-04 22:27:05 <psykose> aye
2023-01-04 22:27:06 <elly> and then assuming a uniform surrounding system
2023-01-04 22:27:15 <elly> which then is why every linux distro's chromium package has a lot of hacks :P
2023-01-04 22:28:01 <psykose> tbh i wish we could have some level of uniformity that didn't require "checking for stdint.h" in every damn project
2023-01-04 22:28:10 <psykose> but chromium goes quite far :p
2023-01-04 22:28:53 <psykose> i think you had a blog post alluding to that standard
2023-01-04 22:29:08 <elly> to stdint.h?
2023-01-04 22:29:11 <elly> I forget
2023-01-04 22:29:37 <elly> it was a couple months ago that I removed some code from angband that was checking for const support in cc!
2023-01-04 22:31:40 <psykose> some level of standard, but maybe i'm misremembering
2023-01-04 22:31:48 <psykose> it's kind of what whence-autoconf refers to by the end
2023-01-04 22:33:49 <elly> oh yes
2023-01-04 22:35:30 <elly> yeah, I am glad we are mostly no longer in our HAVE_FCNTL_H era
2023-01-04 22:35:37 <elly> collectively
2023-01-04 22:39:29 <psykose> yep :)
2023-01-04 22:39:49 <psykose> i think the autoconf cache is quite useful time-wise for a lot of that too (iirc), sadly we don't keep one around for abuild
2023-01-04 22:40:36 <psykose> (to be fair, it is a bit of a maintenance pain if something is broken or new autoconf requires changing some stuff, and it's a huge env list per architecture..)
2023-01-04 22:46:25 <elly> hm, the thing with stat vs stat64 is a bit of a mess
2023-01-04 22:46:50 <elly> on 32-bit platforms, with glibc, you need to use struct stat64 & stat64() to get correct sizes, but on 64-bit you need to use struct stat instead
2023-01-04 22:47:06 <elly> and in musl the size is always 64 bits regardless
2023-01-04 22:47:42 <skarnet> "It has a focus on correctness"
2023-01-04 22:48:01 <skarnet> if only someone at Google would take a bet on that
2023-01-04 22:48:55 <skarnet> because I'm preeeeetty sure, without looking, that if I took the time to dive into it I could find something it's not doing correctly
2023-01-04 22:49:31 <elly> hm?
2023-01-04 22:49:35 <elly> oh, gn you mean
2023-01-04 22:49:40 <skarnet> yes
2023-01-04 22:49:48 <elly> bug reports are definitely appreciated
2023-01-04 22:50:03 <skarnet> are you working on this?
2023-01-04 22:50:36 <elly> I do not work directly on gn but I know who does
2023-01-04 22:50:46 <elly> and I think I have committed to it before
2023-01-04 22:51:56 <skarnet> well at least you are interacting with this channel, which is more outside of the well-trodden path than Google usually likes to care about, so thank you for this :)
2023-01-04 22:53:07 <elly> lol
2023-01-04 22:53:12 <elly> thanks I guess :P
2023-01-04 22:54:00 <skarnet> about standards, yeah, depending on your OS targets, you can't afford to demand a high level of standardization unfortunately, because even mainstream BSDs take serious liberties with Single Unix
2023-01-04 22:54:19 <elly> yeah
2023-01-04 22:54:48 <skarnet> and the more ancient you want to support, the harder it is
2023-01-04 22:54:58 <elly> I also constantly have Android in mind, which both has its own libc, is a very weird system, and is "linux-ish" and "posix-ish" in a lot of ways
2023-01-04 22:55:24 <skarnet> calling Android posix-ish is pushing it :P
2023-01-04 22:55:41 <skarnet> it's technically Linux, I guess
2023-01-04 22:55:51 <skarnet> so it's as close to posix as Linux gets
2023-01-04 22:56:00 <elly> indeed
2023-01-04 22:56:33 <Ermine> at least nobody expected to build chromium for android in a way one would do that for any linux distro
2023-01-04 22:56:41 <psykose> elly: no
2023-01-04 22:57:19 <psykose> on 32-bit platforms, you have to pass -D_FILE_OFFSET_BITS=64
2023-01-04 22:57:25 <psykose> and fstat() becomes 64
2023-01-04 22:57:45 <psykose> there is never a reason to use *64 (except the like 2 functions that are defines as the 64 variants but those have no issue)
2023-01-04 22:58:00 <skarnet> I now rely on stdint.h and similar stuff unconditionally but it wasn't long ago that you needed to include sys/types.h first or headers like socket.h would fail, and it even happened on GNU at some point
2023-01-04 22:58:20 <skarnet> also psykose is right about never using *64() extensions
2023-01-04 22:58:31 <psykose> and/or there is also a -DLARGEFILE_WhATEVER_SOURCE stuff, but iirc it's mostly that one
2023-01-04 23:00:53 <psykose> ah ok
2023-01-04 23:00:53 <elly> https://android.googlesource.com/platform/bionic/+/refs/heads/master/docs/32-bit-abi.md#32_bit-and ew
2023-01-04 23:01:02 <elly> lol, thanks algitbot, you tried
2023-01-04 23:01:05 <psykose> _LARGEFILE64_SOURCE is the transitional api define
2023-01-04 23:01:12 <psykose> and exposes the *64 (?) symbols
2023-01-04 23:01:19 <psykose> just the offset one is enough for anything modern
2023-01-04 23:01:45 <psykose> tl;dr anything on linux is fine with just -D_FILE_OFFSET_BITS=64 and then using fstat() assuming 64, nothing more to do
2023-01-04 23:01:55 <psykose> if you go back 15 years, no idea
2023-01-04 23:02:25 <psykose> it can also be unconditional, musl won't care about the define, so no ifdefs needed either
2023-01-04 23:02:28 <elly> yeah, the section I linked is about how, on Android < 15, _FILE_OFFSET_BITS=64 did nothing
2023-01-04 23:02:34 <psykose> :)
2023-01-04 23:04:13 <psykose> that whole page is unfortunate
2023-01-04 23:04:15 <psykose> time_t included
2023-01-04 23:04:21 <psykose> :/
2023-01-04 23:08:18 <elly> hmm, maybe I can rip our stat64 use out entirely
2023-01-04 23:08:20 <elly> that would be rad
2023-01-04 23:11:13 <psykose> it would be helpful as musl 1.2.4 will now have https://github.com/bminor/musl/commit/25e6fee27f4a293728dd15b659170e7b9c7db9bc
2023-01-04 23:11:31 <psykose> (no implicit 64 for gnu anymore)
2023-01-04 23:11:31 <skarnet> the more I hear about details of Android and bionic, the less I want to hear :P
2023-01-04 23:11:49 <psykose> and then by 1.2.5 most likely all the 64 things will be removed :p
2023-01-04 23:13:18 <psykose> that reminds me to perhaps implement the missing  *_l symbols, but every time i touch anything it's an infinite bikeshed so i'm not too heartened
2023-01-04 23:16:36 <skarnet> that's your experience with musl? you should try... er...
2023-01-04 23:16:39 <skarnet> ... Alpine
2023-01-04 23:17:19 <elly> hm... if this change works, I'll have dropped all our uses of stat64
2023-01-04 23:17:38 <bl4ckb0ne> i heard void is better for a musl based distro
2023-01-04 23:17:52 <bl4ckb0ne> alpine is just for docker tbh
2023-01-04 23:24:25 <psykose> yeah i heard mesa was just for glxgears, real users need nvidia.ko
2023-01-04 23:24:32 <psykose> elly: that's great :D
2023-01-04 23:25:37 <minimal> bl4ckb0ne: says who? Alpine existed long before Docker existed
2023-01-04 23:25:51 <psykose> you fell for the bait :D
2023-01-04 23:26:35 <minimal> it's just that "meme" is getting tired
2023-01-04 23:26:40 <omni> what's a docker?
2023-01-04 23:27:21 <psykose> i think it's the thing with the security vulnerabilities
2023-01-04 23:28:45 <omni> like a web browser?
2023-01-04 23:28:50 <elly> rude
2023-01-04 23:28:53 <bl4ckb0ne> yes
2023-01-04 23:30:56 <bl4ckb0ne> omni: docker is the security vulnterability that webdev use to ship their computers
2023-01-04 23:34:41 <elly> https://chromium-review.googlesource.com/c/chromium/src/+/4134763 fingers crossed
2023-01-04 23:37:48 <psykose> it's flyin
2023-01-04 23:38:41 <elly> it ain't over until the android-x86 bot sings
2023-01-04 23:38:59 <psykose> why even is there just a top level `struct stat;` anyway
2023-01-04 23:39:10 <psykose> from what i can tell the existing patch i have is to not have it so it's not redefined
2023-01-04 23:43:08 <elly> so that it can be immediately aliased to stat_wrapper_t
2023-01-04 23:43:24 <psykose> i forget if that will work or not
2023-01-04 23:43:49 <psykose> there's also the fstatat-32bit.patch trainwreck but that one is unfixable from what i can tell
2023-01-04 23:43:52 <psykose> (and somewhat funny)
2023-01-04 23:45:30 <elly> the existing alpine patch just causes base/files/file.h to forward-declare struct stat and alias stat_wrapper_t to it
2023-01-04 23:45:40 <elly> instead of forward-declaring struct stat64 and aliasing stat_wrapper_t to that
2023-01-04 23:46:39 <psykose> aha, right
2023-01-04 23:48:45 <elly> oh hm fstatat-32bit.patch is a bit dubious indeed
2023-01-04 23:50:04 <elly> the entire lss thing that it's a patch against may be unnecessary tbqh
2023-01-04 23:50:38 <psykose> maybe, not sure why there is a syscall wrapper like that either
2023-01-04 23:50:51 <psykose> someone just really wanted armv7 chromium and as always i had to get it to work
2023-01-04 23:51:41 <psykose> and believe it or not, that patch and the clang target were all that was needed
2023-01-04 23:51:44 <psykose> for once i was surprised
2023-01-04 23:51:56 <elly> oh, distressing, we use that lss thing a bunch in crashpad to avoid disturbing libc internals more
2023-01-04 23:51:59 <elly> which is kinda fine
2023-01-04 23:52:10 <psykose> ah, right
2023-01-04 23:52:14 <elly> but also in partitionalloc for getrandom() with some really shady comment about "libc being too old"
2023-01-04 23:52:18 <elly> deeply sus
2023-01-04 23:52:25 <psykose> now that needs a harmer
2023-01-04 23:52:29 <psykose> hammer, even
2023-01-04 23:52:30 <elly> well, problem for another day
2023-01-04 23:54:02 <psykose> many days in the year, they say
2023-01-04 23:54:24 <psykose> and yet the years still roll by
2023-01-04 23:54:26 <psykose> what's up with that
2023-01-04 23:54:50 <elly> science can't explain
2023-01-05 00:07:11 <sam_> psykose, elly: praying for u
2023-01-05 00:07:20 <sam_> i hate all the lfs crap
2023-01-05 00:07:52 <psykose> what did linux from scratch ever do to you : (
2023-01-05 00:22:14 <elly> I am believing in the zero patch dream
2023-01-05 00:23:16 <psykose> if i was next to you i would give you a quizzical eyes look at such a grandiose dream
2023-01-05 00:23:29 <psykose> (but maybe one day!)
2023-01-05 00:24:06 <elly> well, in parallel with my upstreaming efforts, I am convincing people we should just officially support linux+musl as a build config
2023-01-05 00:24:13 <elly> which would hopefully lead to the zero patch dream
2023-01-05 00:24:41 <psykose> would probably be closer to a hover 1-2 patch given the occassional libc++ difference
2023-01-05 00:24:52 <elly> well, yeah
2023-01-05 00:24:56 <elly> and also system libraries vs not
2023-01-05 00:24:59 <elly> but still! a vast improvement
2023-01-05 00:25:11 <psykose> funnily the system part is rarely an issue
2023-01-05 00:25:22 <psykose> mostly because i guess we keep everything current
2023-01-05 00:50:47 <psykose> whoa android passed
2023-01-05 00:50:48 <psykose> amazing
2023-01-05 00:52:01 <elly> mind blown
2023-01-05 00:56:04 <elly> yeah, mailed it to my usual //base reviewer, we'll see what they make of it
2023-01-05 00:56:07 <elly> cheers :)
2023-01-05 02:51:15 <elly> are APKINDEX files signed? if so, how?
2023-01-05 02:54:44 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-sign.in
2023-01-05 02:55:23 <elly> aha, I was looking in apk-tools
2023-01-05 02:55:34 <elly> thanks
2023-01-05 02:56:34 <psykose> should probably not be sha1 :p
2023-01-05 03:00:04 <elly> so we take the unsigned APKINDEX.tar.gz, generate a signature for it, stash that signature by itself in a new .tar.gz, then cat the two gzipped tar files together?
2023-01-05 03:00:12 <elly> that explains why file(1) is so confused about it
2023-01-05 03:07:02 <psykose> apparently
2023-01-05 03:07:15 <psykose> file just claims it's gzip data
2023-01-05 03:07:21 <elly> ya
2023-01-05 03:07:43 <psykose> but yeah i guess it's the implementation
2023-01-05 03:08:32 <elly> cool, thank you :)
2023-01-05 03:09:17 <elly> I wonder how apk knows what data to check the signature over, then
2023-01-05 03:10:24 <bl4ckb0ne> i just use --allow-untrusted for local packages
2023-01-05 03:11:03 <psykose> the default behavior of abuild is to put them in ~/packages and it's a mere /etc/apk/repositories away to not do that smh
2023-01-05 03:11:28 <psykose> sam_: don't suppose you know who to ping to somehow debug this argument-list-too-long make nonsense for libreoffice
2023-01-05 03:11:41 <psykose> it is still the case on latest git so nothing for me to fix via bisect or whatever
2023-01-05 03:11:52 <psykose> and i don't fancy going to the bug tracker like a pleb :(
2023-01-05 03:13:46 <elly> what I don't understand is, apk_sign_ctx_mpart_cb() appears to compute a hash over the uncompressed data
2023-01-05 03:14:29 <psykose> i have no idea if it really works or not :p
2023-01-05 03:15:33 <elly> it must
2023-01-05 03:15:58 <elly> ohhh, it passes the compressed data to the callback
2023-01-05 03:16:03 <elly> okay
2023-01-05 03:17:19 <psykose> is someone doing some black magic? :)
2023-01-05 03:17:57 <elly> I don't think so
2023-01-05 03:18:22 <elly> it's not really how I would have done it but it looks legit
2023-01-05 03:41:27 <elly> ok, I think I now understand how v2 and v3 apks work
2023-01-05 03:44:51 <psykose> :3
2023-01-05 05:30:49 <elly> psykose: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/120
2023-01-05 05:30:53 <elly> the fruits of my labors
2023-01-05 05:31:48 <psykose> holy
2023-01-05 05:31:50 <psykose> someone finally did it
2023-01-05 05:32:07 <psykose> i tried figuring out v3 before and got lost in the source (read: got distracted after 5 minutes)
2023-01-05 05:32:10 <psykose> thanks <3
2023-01-05 05:33:27 <ikke> Yeah, awesome work
2023-01-05 05:37:36 <psykose> i'm not sure if abuild is necessarily a good source for .PKGINFO
2023-01-05 05:38:41 <psykose> there is a limited number of keys in the end, and apk is strictly distinct from abuild (to the point that issues in alpine packaging are frequently abuild issues specifically, and thrown out of apk)
2023-01-05 05:39:06 <psykose> it should be filled out and documented as part of apk in the documentation there, not link to abuild's implementation
2023-01-05 05:39:55 <psykose> of course, a full table for it is another large slice of work indeed
2023-01-05 05:40:13 <psykose> and the versioning scheme is another deep dive
2023-01-05 05:40:51 <sam_> psykose: you'll have to go begging on the libreoffice ML (they scream at you if you file a bug for build issues)
2023-01-05 05:40:55 <sam_>  rene@debian.org has merged a few of my things before
2023-01-05 05:41:02 <sam_> but theyre probably watching the ML anyway
2023-01-05 05:41:26 <psykose> hmm
2023-01-05 05:41:58 <psykose> curious, can you gimme `getconf ARG_MAX`
2023-01-05 05:42:34 <sam_> the one time ive emailed the list it did actually work tbf
2023-01-05 05:42:36 <sam_> but i do not blame ur skepticism
2023-01-05 05:42:40 <sam_> $ getconf ARG_MAX # glibc
2023-01-05 05:42:42 <sam_> 2097152
2023-01-05 05:42:45 <sam_> $ getconf ARG_MAX # musl
2023-01-05 05:42:47 <sam_> 131072
2023-01-05 05:43:05 <psykose> : )
2023-01-05 05:43:32 <psykose> i've stared at this make spaghetti for so long i hate zero idea where anything is or how to unroll any argument list
2023-01-05 05:43:33 <psykose> urgh
2023-01-05 05:43:45 <psykose> have*
2023-01-05 05:44:41 <sam_> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208154
2023-01-05 05:44:45 <sam_> interesting
2023-01-05 05:46:35 <sam_> mergelibs still exists as a noption
2023-01-05 05:46:37 <sam_> option
2023-01-05 05:47:10 <sam_> meh, but you're not setting it, and it's default off, so that's not helpfu
2023-01-05 05:48:24 <psykose> what if i just
2023-01-05 05:48:38 <psykose> meow really loudly until someone ports this whole thing to meson
2023-01-05 05:48:42 <psykose> i think that would really solve the issue
2023-01-05 05:53:18 <psykose> yeah no difference for mergelibs
2023-01-05 05:53:24 <psykose> tbf not sure if that is even the failing part
2023-01-05 05:53:42 <psykose> the first one was easy to find by name and i found a commit that just deletes it all
2023-01-05 05:53:57 <psykose> `[CFG] registry` is just completely meaningless though
2023-01-05 05:54:05 <psykose> and the make error lines don't say anything
2023-01-05 05:54:19 <psykose> maybe i just need to output 10 million lines to my terminal with some debugging
2023-01-05 05:54:21 <psykose> of course
2023-01-05 05:55:50 <psykose> sometimes i wonder how stupid i must be to debug something for hours and forget to just add some verbosity
2023-01-05 05:56:35 <elibrokeit> libreoffice ported to meson?
2023-01-05 05:56:39 <elibrokeit> more likely than you think!
2023-01-05 05:57:03 <psykose> is it now :)
2023-01-05 05:57:10 <psykose> https://img.ayaya.dev/Ii6L84rHzXfv
2023-01-05 05:57:12 <psykose> yeesh
2023-01-05 05:57:15 <psykose> that is a l a r g e boi
2023-01-05 05:57:38 <psykose> 811k
2023-01-05 05:57:45 <psykose> so, of course, nowhere near glibc limits
2023-01-05 05:58:50 <elibrokeit> https://wiki.documentfoundation.org/Development/GSoC/Ideas#Feasibility_study:_building_LibreOffice_using_meson
2023-01-05 05:58:58 <elibrokeit> and https://nibblestew.blogspot.com/2022/02/compiling-libreoffice-with-meson-even.html
2023-01-05 06:01:06 <elibrokeit> it will take tremendous effort to actually get that near the finish line, but it's certainly crossed people's minds
2023-01-05 06:01:33 <elibrokeit> and they're generally receptive to the suggestion, if they consider that a valid GSOC project... :)
2023-01-05 06:02:51 <sam_> can you do the @arg thing with make
2023-01-05 06:02:55 <sam_> but just report it on the ML
2023-01-05 06:02:56 <sam_> and pray
2023-01-05 06:03:10 <psykose> sob
2023-01-05 06:03:44 <elibrokeit> @arg as in a response file?
2023-01-05 06:04:18 <psykose> sam_: which one specifically?
2023-01-05 06:05:09 <elibrokeit> it looks to me like this isn't about arguments to make?
2023-01-05 06:06:12 <psykose> not /to/ make, no
2023-01-05 06:06:14 <elibrokeit> I guess make runs a target via $(SHELL) -c so the entire length of an embedded shellscript causes issues
2023-01-05 06:06:33 <sam_> libreoffice@lists.freedesktop.org
2023-01-05 06:06:35 <sam_> (from https://wiki.documentfoundation.org/QA/BugReport)
2023-01-05 06:06:37 <sam_> it always feels weird
2023-01-05 06:06:38 <elibrokeit> would be safer if it wrote out a tempfile and executed it
2023-01-05 06:06:58 <elibrokeit> but that isn't @arg related :p
2023-01-05 06:08:48 <psykose> but saaaam
2023-01-05 06:08:55 <psykose> it explicitly says to not report bugs there....
2023-01-05 06:09:01 <sam_> where
2023-01-05 06:09:09 <psykose> https://img.ayaya.dev/araqB4oB7qYV
2023-01-05 06:09:10 <elibrokeit> the mailing lost
2023-01-05 06:09:18 <psykose> i will get shanked..
2023-01-05 06:09:19 <sam_> they don't count "build issues" as bugs
2023-01-05 06:09:21 <sam_> trust me pls
2023-01-05 06:09:25 <psykose> okaay
2023-01-05 06:09:26 <sam_> let me show you PROOF
2023-01-05 06:10:35 <sam_> https://bugs.documentfoundation.org/show_bug.cgi?id=152569#c2
2023-01-05 06:10:37 <sam_> i agree it is very odd
2023-01-05 06:10:44 <sam_> but https://wiki.documentfoundation.org/QA/BugReport lists it as the right place too for bugs involving "building libreoffice"
2023-01-05 06:11:13 <elibrokeit> for user errors involving building libreoffice, duh
2023-01-05 06:11:29 <sam_> 
ACTION twitches

2023-01-05 06:11:37 <sam_> in any case nobody shouted at me 2 months ago or whenever it was
2023-01-05 06:12:35 <sam_> i have no idea why this rule exists though
2023-01-05 06:12:56 <elibrokeit> honestly it would be nice if people learned to componentize more
2023-01-05 06:13:12 <elibrokeit> libreoffice could use splitting into chunks :p
2023-01-05 06:20:03 <psykose> in what sense
2023-01-05 06:20:07 <psykose> it's already chunks internally
2023-01-05 06:20:36 <psykose> and personally i'm not a huge fan of ecosystem packaging for libraries used by one project in the universe as it just takes more time for no difference
2023-01-05 06:21:34 <psykose> for things that would actually get reused, sure, but then it's quite hard for the project to not end up depending on latest master all the time :/
2023-01-05 06:23:49 <psykose> sam_: https://lists.freedesktop.org/archives/libreoffice/2023-January/089777.html success
2023-01-05 06:24:35 <sam_> yay!
2023-01-05 06:25:15 <psykose> getting over Posting anxiety one email at a time
2023-01-05 06:25:19 <psykose> 
ACTION crawls into a hole

2023-01-05 06:27:51 <ikke> psykose: good job :)
2023-01-05 06:29:35 <psykose> the sound-insulated hole of shame deflects all attempts of praise
2023-01-05 06:31:54 <elibrokeit> 
ACTION carefully covers psykose's hole with a tarp

2023-01-05 10:44:36 <sam_> psykose: https://git.alpinelinux.org/aports/commit/?id=d4a749ddb14d8df389b9d9409eaf393e845b57b7
2023-01-05 10:44:38 <sam_> ???
2023-01-05 10:44:40 <sam_> werent we all shitting on this earlier
2023-01-05 11:33:37 <indy> hi all, is there any reason why some busybox config are disabled? i'm interested in crond - CONFIG_FEATURE_CROND_SPECIAL_TIMES having enabled and CONFIG_INOTIFYD
2023-01-05 11:52:24 <pj[m]> <algitbot> "testing/apx: new aport: http://..." <- why was this merged
2023-01-05 12:39:54 <skarnet> indy: the options you want are enabled in the default busybox config, it appears? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/busybox/busyboxconfig#L778 and https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/busybox/busyboxconfig#L805
2023-01-05 12:44:33 <indy> good to know, that those configs are 'overlapping'
2023-01-05 12:44:54 <indy> :)
2023-01-05 12:48:56 <ikke> pj[m]: developers can push things on their on volition
2023-01-05 19:32:22 <nmeum> hm, busybox 1.36.0 segfaults only on x86 with any command-line input directly in musl's dynamic loader. the statically linked x86 busybox 1.36.0 executable works fine though (so does busybox 1.35.0) https://tpaste.us/QNOr <-- dalias do you happen to have any idea what might be causing this from the top of your head and why it only happens on x86?
2023-01-05 19:32:44 <nmeum> otherwise I will resort to git bisect to narrow it down
2023-01-05 19:33:32 <psykose> real long shot if you don't mind a quick test- rebuild musl loader without the 4 relr patches there and test again
2023-01-05 19:34:26 <psykose> juust in case i broke it with those because x86 is quite special all the time
2023-01-05 19:34:28 <nmeum> I also considered that but busybox 1.35.0 works fine on x86 with the 4 relr patches so I don't think its related
2023-01-05 19:34:36 <psykose> it can be a niche case still
2023-01-05 19:34:50 <nmeum> hmhm, true…
2023-01-05 19:34:54 <psykose> that and, quick test, you know
2023-01-05 19:35:00 <psykose> few minutes and something meaningless ruled out
2023-01-05 19:35:01 <nmeum> yea, good point
2023-01-05 19:35:53 <psykose> (if it was those it would imply a bug in the implementation that should get fixed for 1.2.4, but probably not)
2023-01-05 19:39:24 <nmeum> nope, it also segfaults without the relr patches 😌
2023-01-05 19:39:28 <nmeum> git bisect it is then
2023-01-05 19:43:59 <psykose> okie :3 thanks for checkin
2023-01-05 19:44:22 <psykose> it's going to be something cursed for sure
2023-01-05 20:03:04 <nmeum> ok. the first bad commit is https://git.busybox.net/busybox/commit/?id=a96ccbefe417aaac6a2ce59c788e01fc0f83902f
2023-01-05 20:08:25 <psykose> going to guess something is invalid in that asm
2023-01-05 20:09:00 <psykose> oh huh, they added sha512 accel right
2023-01-05 20:09:12 <psykose> i kinda wanna bench that for a chromium tarball checksum
2023-01-05 20:09:30 <psykose> this is quite the speedup for abuild because everything uses the sha512 verification
2023-01-05 20:09:35 <nmeum> yes!
2023-01-05 20:09:37 <psykose> even if it's only on like one arch
2023-01-05 20:09:46 <nmeum> it's very handy
2023-01-05 20:09:50 <psykose> mhm!
2023-01-05 20:10:47 <psykose> i had a bad idea a long time ago to write a wrapper to use openssl hash for sha512 to speed it up locally (and it was fast) but there was some startup costs and edge cases and in the end it was not worth the pain
2023-01-05 20:10:52 <psykose> glad to see it simply became free
2023-01-05 20:10:57 <psykose> brb, have to run the numbers
2023-01-05 20:15:19 <nmeum> hm, if there is a bug in the assembly why would it only crash in the dynamic but not in the static build then? 🤔
2023-01-05 20:15:35 <nmeum> anyway, if I disable hw acceleration on x86 then the tests pass
2023-01-05 20:26:52 <z3ntu> ERROR: Metadata for package util-linux-dev-2.38.1-r2 is too long. getting this error on edge. Needs a rebuild or something?
2023-01-05 20:29:59 <psykose> nmeum: should ash_sleep not be =y?
2023-01-05 20:30:07 <psykose> z3ntu: your apk is too old
2023-01-05 20:30:34 <psykose> has to be either .9-r7 or .10-r1
2023-01-05 20:31:08 <nmeum> psykose: we can do that, previously it was not a builtin. but I didn't do my final touch of the config yet, the MR is still wip
2023-01-05 20:31:29 <psykose> yeah, just seems new and before it wasn't even an option; i assume the builtins are a slight improvement :)
2023-01-05 20:31:38 <psykose> tree is nice in main busybox too imo
2023-01-05 20:31:41 <psykose> rest looks good to me
2023-01-05 20:32:58 <nmeum> *nod*
2023-01-05 20:38:41 <psykose> ugh, nvm
2023-01-05 20:38:53 <psykose> misread
2023-01-05 20:39:03 <psykose> they didn't impl sha512, just 1/256
2023-01-05 20:39:03 <psykose> :(
2023-01-05 20:39:12 <psykose> but for 256, the difference is huge
2023-01-05 20:39:54 <psykose> https://img.ayaya.dev/tlNrAbJvwLPs
2023-01-05 20:40:21 <psykose> interestingly 256sum is slower than 512sum normally before these opts
2023-01-05 20:40:31 <psykose> hyperfine for numbering
2023-01-05 20:42:14 <psykose> nmeum: i wonder if you feel like adding --with-build-config=bootstrap-lto for gcc :p
2023-01-05 20:42:18 <psykose> just a few percentile points..
2023-01-05 20:46:59 <nmeum> I don't have strong opinions on that option
2023-01-05 20:47:25 <nmeum> ah, they indeed didn't implement hw accl for sha512, unfourtunate
2023-01-05 20:47:47 <nmeum> I guess that shouldn't be too hard to add though, it seems the assembly was mostly copied from the linux kernel anyhow
2023-01-05 21:27:56 <hjaekel> @psykose in the build script for GDAL 3.6.1 they have a check "do not use Armadillo if it lacks LAPACK support (such as on Alpine)" (see https://github.com/OSGeo/gdal/blob/v3.6.1/NEWS.md). Thats why I have to fix !42902
2023-01-05 21:29:18 <hjaekel> I don't know anything about OpenBLAS, and it takes forever to build 
2023-01-05 21:31:40 <psykose> yeah it looks like somethin alright
2023-01-05 21:31:55 <psykose> i'll clean it up a bit after merging that to at least split the libraries a bit
2023-01-05 21:36:41 <hjaekel> Thank you. Unfortunately the OpenBLAS package is orphaned
2023-01-05 21:38:16 <psykose> also wonder why it's NO_LAPACKE=1 (disabled?) then builds it and installs it
2023-01-05 21:38:17 <psykose> funny
2023-01-05 21:40:52 <elibrokeit> blas really is such a communal mess
2023-01-05 21:42:35 <psykose> wonder if this cmake implementation is less of a mess
2023-01-05 21:42:42 <elibrokeit> no :p
2023-01-05 21:42:45 <psykose> :)
2023-01-05 21:43:40 <elibrokeit> its also a mess both in terms of building and also just you know, in general, everything to do with the many blas implementations and how they vendor each other
2023-01-05 21:45:11 <hjaekel> I also tried NO_LAPACKE=0, then the build fails
2023-01-05 22:10:08 <psykose> sam_: do you recall how to get sourceforge to spit out a .diff
2023-01-05 22:18:16 <elibrokeit> I would not assume sourceforge *could* do that, huh
2023-01-05 22:19:58 <psykose> probably can't
2023-01-05 22:20:03 <psykose> but ya never know
2023-01-05 22:20:25 <psykose> wanna fix this tiff garbage, have to backport the hylafax change, but it's... sourceforge
2023-01-05 22:20:37 <psykose> and there's no mirrors to get a diff and i don't feel like typing this nonsense
2023-01-05 22:20:43 <psykose> i guess i'll just clone it myself
2023-01-05 23:48:36 <sam_> psykose: i'm pretty sure you can't but if you find a way, pls pls pls tell me
2023-01-05 23:48:41 <psykose> sure sure
2023-01-05 23:48:50 <sam_> i normally clone it and try *or* copy the .diffs for each individual file lol
2023-01-05 23:48:54 <psykose> let me masochismexplore this little website everyone seems to be stuck on
2023-01-05 23:49:46 <sam_> https://sourceforge.net/p/forge/feature-requests/614/ hm
2023-01-05 23:54:06 <psykose> top dog BRAD BIZX is on the case
2023-01-05 23:54:08 <psykose> any day now
2023-01-05 23:57:54 <psykose> 😭 there's a "sync github into sourceforge" button at the top
2023-01-05 23:59:11 <sam_> cracking up
2023-01-06 00:01:32 <elibrokeit> I love it...
2023-01-06 02:19:54 <sam_> psykose_: tell me when you have a patch i can steal from you
2023-01-06 02:20:03 <psykose_> what for
2023-01-06 02:20:11 <sam_> hylafax
2023-01-06 02:20:14 <psykose_> hahahah
2023-01-06 02:20:14 <sam_> i wanna use the upstream one but cba to clone
2023-01-06 02:20:20 <psykose_> ok i will go make that for you
2023-01-06 02:20:26 <psykose_> i had a much worse workaround
2023-01-06 02:20:44 <psykose_> -Dld-version-script=OFF to tiff cmake keeps the vars..
2023-01-06 02:21:40 <psykose_> but now that there's a patch, i guess i'll try port it to 6.0 and 7.0
2023-01-06 02:25:52 <sam_> ❤️
2023-01-06 02:32:34 <psykose_> 3475ff5353d5efab9955fd8da6d1282ba524d1ef
2023-01-06 02:32:36 <psykose_> sam_: 
2023-01-06 02:33:14 <psykose_> same for 6.0 in main/hylafax if you need it
2023-01-06 02:33:35 <psykose_> well, same thing applies so no difference
2023-01-06 08:17:18 <sam_> psykose_: thank you!
2023-01-06 08:34:37 <psykose_> go back to bed sam
2023-01-06 08:41:24 <sam_> oops
2023-01-06 09:12:56 <hjaekel> @psykose_ Thank you for cleaning up OpenBLAS. When I now install Armadillo, apk installs lapack (which also provides liblapack.so.3), although Armadillo was build against liblapack.so.3 from liblapack. How can this be solved?
2023-01-06 12:07:03 <vkrishn> is multiuser login fully supported in al ?
2023-01-06 12:11:06 <ncopa> depends on what you mean with "multiuser login" and "fully supported"
2023-01-06 12:11:37 <ncopa> there is nothing preventing different users log in at the same time via ssh
2023-01-06 12:11:54 <ncopa> that is fully supported
2023-01-06 12:13:06 <skarnet> I suspect they're asking about multiseat (which nobody in their right mind does anyway XD)
2023-01-06 12:16:22 <Ermine> There's also seatd
2023-01-06 12:39:51 <vkrishn> like when adduser ...
2023-01-06 12:40:33 <vkrishn> ok, thanks
2023-01-06 12:48:17 <PureTryOut> psykose: when updating Qt6, could you at least make a MR so I know about it?
2023-01-06 17:01:47 <f_> Hi all. I'm making a package for Alpine and am wondering if I can use the Git repo URL in the `source` variable in the APKBUILD.
2023-01-06 17:02:35 <ikke> f_: abuild will not clone a repo
2023-01-06 17:02:47 <ikke> It needs to be a url to a .tar.gz or other accepted archive
2023-01-06 17:03:03 <f_> Okay. Thanks
2023-01-06 17:04:24 <f_> Nevermind. I can download the latest Git repo as a .tar.gz using Cgit.
2023-01-06 17:04:38 <elibrokeit> f_: in general, git sources aren't quite so nice because they might do a different thing every time you build 
2023-01-06 17:04:54 <elibrokeit> some package ecosystems, like the archlinux one, support a grammar for pinning commits
2023-01-06 17:04:59 <elibrokeit> this is not trivial
2023-01-06 17:05:21 <f_> But what if I'm the maintainer of the Git repo?
2023-01-06 17:05:28 <f_> (Which I am)
2023-01-06 17:05:45 <ikke> Providing stable tags is a good thing
2023-01-06 17:05:58 <ikke> And most hosting sites automatically provide archives for tags
2023-01-06 17:06:26 <f_> I haven't yet made a release.
2023-01-06 17:06:42 <f_> So I can't provide stable tags for now.
2023-01-06 17:06:57 <elibrokeit> maybe it's not stable enough to package it, then 
2023-01-06 17:07:19 <f_> Is it fine if I package it in testing?
2023-01-06 17:07:37 <ikke> f_: make sure you at least pin it to a commit
2023-01-06 17:07:45 <f_> Sure.
2023-01-06 17:07:53 <elibrokeit> speaking as someone who's done a lot of package manager development, working on git sources, I don't blame Alpine for not implementing it.
2023-01-06 17:08:17 <f_> I'll pin it to the latest commit as of today and will update regularily.
2023-01-06 17:08:20 <elibrokeit> automatically generated tarballs are fine, most of the time 
2023-01-06 17:08:30 <f_> They're all generated though.
2023-01-06 17:08:35 <elibrokeit> (and Alpine doesn't support -git packages like the Arch AUR does)
2023-01-06 17:12:24 <f_> Anyways, thanks!
2023-01-06 17:13:04 <ikke> f_: in case you didn't know, the version would become something like 0_git<date>
2023-01-06 17:13:30 <f_> ikke: I absolutely didn't know that. Thanks a lot!
2023-01-06 17:13:45 <f_> What's the format of the date though?
2023-01-06 17:13:52 <ikke> YYYYMMDD
2023-01-06 17:13:55 <f_> Thanks!
2023-01-06 17:14:20 <ikke> It's just a number, but this format makes sure later versions are considered newer
2023-01-06 17:14:35 <f_> Ok
2023-01-06 18:12:06 <f_> Actually, is it possible to build Alpine Linux packages from a GNU+Linux distribution?
2023-01-06 18:14:49 <ikke> You mean from some other distribution than alpinelinux itself?
2023-01-06 18:15:10 <f_> Yup. Artix Linux to be specific.
2023-01-06 18:15:25 <ikke> We have docker images that can be used
2023-01-06 18:15:43 <ikke> but any chroot will do
2023-01-06 18:15:48 <f_> I have `abuild` and `apk` on my system but `apk`'s ...... borked.
2023-01-06 18:16:18 <ikke> Yeah, is not really a good idea to do it that way
2023-01-06 18:16:19 <f_> (Even though it's being packaged in the official repos)
2023-01-06 18:16:32 <f_> Oh.
2023-01-06 18:17:38 <ikke> it needs to be able to install dependencies that might conflict / interfere with your system
2023-01-06 18:18:35 <f_> I'll use the "only" Alpine Linux system I have though (technically it's running pmOS but that should be fine)
2023-01-06 18:18:41 <f_> s/though/then
2023-01-06 18:18:41 <alpine-meetbot> f_ meant to say: I'll use the "only" Alpine Linux system I have then (technically it's running pmOS but that should be fine)
2023-01-06 18:18:48 <f_> Nice bot.
2023-01-06 18:31:12 <elibrokeit> ikke: by the way, Alpine's date versioning format is wrong and does not make sure later versions are considered newer, but I suppose if Alpine doesn't have an ecosystem like "*-git" the edge cases aren't encountered often enough to highlight the issues.
2023-01-06 18:32:36 <ikke> elibrokeit: multiple commits on the same date, or something else?
2023-01-06 18:32:46 <elibrokeit> that is one edge cases.
2023-01-06 18:33:07 <f_> elibrokeit: In that case you could use pkgrel?
2023-01-06 18:33:17 <ikke> that's not what pkgrel is for
2023-01-06 18:33:24 <f_> Oh well.
2023-01-06 18:33:25 <elibrokeit> another is a commit on a later date committed by a maintainer with a borked clock that appears to be from the previous day instead.
2023-01-06 18:33:45 <elibrokeit> pkgrel will not help there even if you try to use it
2023-01-06 18:33:50 <f_> The maintainer should fix their clock.
2023-01-06 18:33:56 <f_> Then
2023-01-06 18:34:19 <elibrokeit> that doesn't actually have any relevance to the discussion at hand -- Alpine still ends up with a monotonically decreasing version
2023-01-06 18:35:08 <elibrokeit> Gentoo live ebuilds "solve" this by just calling the version 9999 regardless of when you build it
2023-01-06 18:35:30 <elibrokeit> arch *-git packages solve this by using monotonically increasing commit counts
2023-01-06 18:36:02 <f_> Also, in https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2023-01-06 18:36:03 <elibrokeit> the number of commits since the root commit -- or the number since the most recent tag -- does monotonically increase, always
2023-01-06 18:36:32 <f_> "Beware that some git services (gitweg, cgit, …?) doesn’t provide stable tarballs, so when you point source to an tarball like http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz, then you will run into issues because the checksum changes when downloading on the build system"
2023-01-06 18:36:35 <elibrokeit> except when upstream force pushes, but that is not solvable and breaks all versioning schemes invented anywhere, ever
2023-01-06 18:36:51 <ikke> though technically there could be more then one commit with the same amount of commits since any other commit
2023-01-06 18:36:54 <f_> That doesn't seem to happen in Cgit. 
2023-01-06 18:37:08 <elibrokeit> ikke: that is possible when switching branches, yes
2023-01-06 18:37:36 <elibrokeit> but in that case the pkgname should change too
2023-01-06 18:38:21 <elibrokeit> since it's presumably a development-focused soft fork and should be named based on the wip feature 
2023-01-06 18:39:51 <elibrokeit> anyway most of this is a bit academic in an ecosystem where git based packages are uncommon or rare 
2023-01-06 18:39:57 <ikke> yes
2023-01-06 18:40:49 <elibrokeit> it unquestionably happens in general, but when you rarely do it, you don't do it often enough to probabilistically encounter it.
2023-01-06 18:41:27 <elibrokeit> (and if you don't do it via unattended automation you can always manually fix it somehow)
2023-01-06 18:44:39 <ikke> Yeah, so in practice, it's rarely going to be an issue for us
2023-01-06 19:24:18 <psykose_> hjaekel: why are there like two lapacks at all?
2023-01-06 19:25:10 <psykose_> just like there's two blas's, and they're all named the same
2023-01-06 19:25:11 <psykose_> nice
2023-01-06 20:57:08 <psykose_> hjaekel: i split them via an sonameprefix on openblas- things built against openblas-dev will link to so:openblas:liblapack.so.3 and specifically get that one
2023-01-06 20:57:11 <psykose_> should be fine
2023-01-06 20:57:24 <psykose_> i'd like to revisit why there are two lapacks and two blas's but another day :)
2023-01-06 20:58:03 <elibrokeit> are they both the same development project implementing BLAS?
2023-01-06 20:58:47 <elibrokeit> 
ACTION has no idea if Alpine offers multiple variants, netlib blas, openblas, blis, mkl...

2023-01-06 20:59:27 <psykose_> one is netlib, the other is openblas
2023-01-06 20:59:51 <psykose_> up until yesterday openblas was just blas (didn't build lapack), former had them all
2023-01-06 20:59:55 <psykose_> bit random what uses what
2023-01-06 21:00:30 <psykose_> are you perhaps a linalg connosseur and can differentiate which goes more zoom zoom faster and should be preferred :p
2023-01-06 21:00:37 <hjaekel> @psykose_ sounds good, I will test the sonameprefix later
2023-01-06 21:01:02 <elibrokeit> not really but I have discussed it with people 
2023-01-06 21:01:03 <psykose_> hjaekel: i rebuilt everything using it for you, so should already be ok, can carry on with what you wanted to do :)
2023-01-06 21:01:25 <psykose_> (well, pending the rebuild finishing in a bit)
2023-01-06 21:01:38 <elibrokeit> there's a general idea that you should build for reference blas (netlib) but allow people to install whichever one they want and provide those sonames as drop-in library replacements
2023-01-06 21:02:32 <psykose_> ah, the worst solution possible for packaging
2023-01-06 21:03:31 <elibrokeit> basically the official blas is netlib and everything else is an alternatives system
2023-01-06 21:03:39 <psykose_> weh
2023-01-06 21:03:48 <psykose_> well, what benefits this open stuff got
2023-01-06 21:03:52 <elibrokeit> but most people will never use netlib they will just use openblas because it's faster
2023-01-06 21:03:58 <psykose_> nice nice
2023-01-06 21:04:13 <psykose_> and then the mkl is some intel stuff right
2023-01-06 21:04:16 <psykose_> okay, i get it now
2023-01-06 21:04:20 <elibrokeit> or mkl because it's not free
2023-01-06 21:04:29 <psykose_> yep
2023-01-06 21:04:49 <psykose_> thanks friend, always a help :)
2023-01-06 21:05:27 <elibrokeit> you still do want to make sure that they can be easily replaced by any of the billion variants that people use for exotic obscure reasons
2023-01-06 21:06:50 <elibrokeit> including because some of them are very tuned for one specific hardware and nothing else or even for just a GPU
2023-01-06 21:09:32 <elibrokeit> they all build towards the same ABI so that's usually fine
2023-01-07 06:51:27 <psykose_> god i love these rustup issues every time
2023-01-07 06:51:39 <psykose_> try to reproduce, build fails, no errors
2023-01-07 06:51:44 <psykose_> apk add cargo, everything works
2023-01-07 06:51:45 <psykose_> nice
2023-01-07 08:43:22 <hjaekel> @psykose do you know why brunsli was not build for several architectures? It's only available for ppc64le and s390x.
2023-01-07 08:43:31 <psykose> the builders have been blocked for a while
2023-01-07 08:43:44 <psykose> apologies :)
2023-01-07 08:44:02 <psykose> i did fix the root cause now but they still have to be restarted and i don't have the access
2023-01-07 08:44:10 <hjaekel> OK, no problem. Then I will wait
2023-01-07 11:53:28 <hjaekel> builders are alive again :)
2023-01-07 11:54:20 <psykose> :)
2023-01-07 12:09:14 <ikke> You're welcome ;-) 
2023-01-07 12:09:26 <ikke> And psykose as well
2023-01-08 03:57:13 <ajhalili2006_> I'm currently authoring a APKBUILD for deno (https://deno.land) and I also checking the PKGBUILD in AUR too. Should I also use the same makedepends on main/nodejs just in case?
2023-01-08 04:44:49 <psykose> oh god no
2023-01-08 11:44:50 <ikke> ajhalili2006_: deno officially only supports glibc: https://github.com/denoland/deno/issues/3711
2023-01-08 11:46:48 <ikke> and: https://github.com/void-linux/void-packages/pull/22043#issuecomment-629819836
2023-01-08 11:48:45 <Ermine> > muslc library
2023-01-08 11:49:29 <ikke> heh
2023-01-08 11:49:45 <Ermine> Isn't libgcc shipped with, hm, gcc regardless of libc?
2023-01-08 11:51:33 <psykose> that issue is unrelated
2023-01-08 11:51:45 <psykose> just your usual rustup musl target meme
2023-01-08 13:06:25 <ajhalili2006_> ikke: Maybe I should hold a bit until I found some workarounds.
2023-01-08 13:07:13 <psykose> pls just no
2023-01-08 13:12:02 <bl4ckb0ne> no workarounds, only real fixes
2023-01-08 13:17:38 <ajhalili2006> Sorry for the confusion, just authentication mess in chat.sr.ht on my side
2023-01-08 13:17:49 <ajhalili2006> (nickname side)
2023-01-08 13:33:28 <lmarz> here's the first draft of the license policy. feel free to criticize https://gitlab.alpinelinux.org/lmarz/license-policy/-/blob/main/policy.md
2023-01-08 13:41:53 <orbea> are there any licenses that even infringe on 5 or 6? seems pointless
2023-01-08 13:42:40 <lmarz> there actually are some
2023-01-08 13:43:10 <orbea> 9 seems problematic, there are many free software licenses that cant be mixed, or am I misunderstanding?
2023-01-08 13:43:13 <lmarz> some people don't want the military to use their stuff
2023-01-08 13:44:56 <lmarz> 9 is more in the sense, that it shouldn't be "my software may be only used on an os, where every other software uses my exact license"
2023-01-08 13:45:18 <orbea> ah, makes more sense now
2023-01-08 13:45:20 <psykose> huh, what case is that guarding
2023-01-08 13:45:31 <psykose> i've never seen that before
2023-01-08 13:45:34 <orbea> but yea, never seen it in practice either
2023-01-08 13:48:22 <psykose> 4) is incompatible with agpl
2023-01-08 13:48:39 <psykose> though agpl is such a shitshow i'm pretty sure anything in aports that has a patch on it that is agpl is breaking the licence
2023-01-08 13:49:27 <orbea> damn, didn't know agpl was that bad...
2023-01-08 13:50:12 <psykose> in practice it's not since nobody cares
2023-01-08 13:51:17 <lmarz> how do you modify 4 that it is compatible with agpl?
2023-01-08 13:51:20 <psykose> i would add a clause to Firmware that the licence must allow redistribution
2023-01-08 13:51:34 <psykose> there is firmware that you are not allowed to host yourself but it doesn't clarify that
2023-01-08 13:51:56 <psykose> not sure
2023-01-08 13:52:09 <psykose> i'm also not a lawyer and not sure if 4 'actually' is agpl incompatible, it just seems that way
2023-01-08 13:53:20 <lmarz> the OSI, where i copied these paragraphs from, thinks it is compatible
2023-01-08 13:53:28 <lmarz> at least AGPL-3.0
2023-01-08 13:53:32 <psykose> ah
2023-01-08 13:53:33 <psykose> sure, then
2023-01-08 13:53:49 <psykose> i'm not looking at it from a lawyer eye so unsurprised it's wrong :)
2023-01-08 13:54:09 <lmarz> i'm not a lawyer either
2023-01-08 13:54:22 <psykose> hmm, why are gfdl/cc listed as an extra below for docs
2023-01-08 13:54:44 <psykose> i've seen code under cc (funny but it's true), are they somehow incompatible with the paragraphs
2023-01-08 13:54:45 <mercenary> Firmware is generally executable. Maybe not on the host cpu, but on some DSP, or as microcode.
2023-01-08 13:55:28 <orbea> code under cc is not even that rare
2023-01-08 13:55:40 <lmarz> GFDL is technically non free. Thats why the gcc man page is not in main debian
2023-01-08 13:55:47 <psykose> ah
2023-01-08 13:56:12 <vkrishn> 9 is more like honoring other license to extent of it applicability ?
2023-01-08 13:56:13 <lmarz> CC does not meet the requirements according to fedora
2023-01-08 13:56:34 <lmarz> but i haven't seen it anywhere else
2023-01-08 13:56:39 <orbea> so cc code is not allowed in fedora?
2023-01-08 13:56:56 <lmarz> ...yes
2023-01-08 13:57:03 <orbea> ouch
2023-01-08 13:57:09 <lmarz> i don't know if its enforced though
2023-01-08 13:58:04 <lmarz> vkrishn: you could say that
2023-01-08 13:59:10 <valerius> "Intermediate forms such as the output of a preprocessor or translator are not allowed."
2023-01-08 13:59:31 <valerius> can I assume that this doesn't cover the output of a "code generator", aka a python script that generates C?
2023-01-08 13:59:42 <lmarz> mercenary: it was the thought that firmware should be classified as a binary blob that can't run without anything else. i will specify that more
2023-01-08 14:00:47 <valerius> like, let's say I made a code generator in Python but only want to include the C in some program I distrubute, not the generator, but the C is still readable/modifiable by humans
2023-01-08 14:01:51 <lmarz> valerius: as long as the c code isn't obfuscated, it should be fine. That's a light grey area
2023-01-08 14:02:04 <vkrishn> if the final code, generated or not, is valid code in itself is a CODE
2023-01-08 14:02:05 <lmarz> the generator should be also available though
2023-01-08 14:02:49 <vkrishn> humans are code generator too, inteligence, AI, etc comes later
2023-01-08 14:04:21 <orbea> i would think if the generator is required to actually compile/use/distribute the program it would be problematic then
2023-01-08 14:04:51 <vkrishn> for instance, I currently beleive .patch files are not code in itself
2023-01-08 14:04:56 <orbea> but a generator could be a one time tool that is not part of the normal development process
2023-01-08 14:05:38 <mercenary> valerius: taking that line of thought ad infinitem, one could hold back the C code, and ship cc -S output. Or even a binary, as that is also the output of a translator.
2023-01-08 14:05:57 <orbea> but that is not code
2023-01-08 14:06:09 <vkrishn> then if gcc becomes proprietory, all OS.codes become defunct ?
2023-01-08 14:07:18 <vkrishn> if compiler is not provided, the code viablibity is in question, therefore not a code 
2023-01-08 14:09:08 <lmarz> vkrishn: sorry i can't follow your argument. which guideline/problem are you talking about?
2023-01-08 14:09:21 <valerius> very specifically, I use one of these: https://github.com/floooh/chips/tree/master/chips
2023-01-08 14:09:39 <valerius> CPU emulators generated by code generators written in Python
2023-01-08 14:10:06 <vkrishn> lmarz: none its just expanding python-C statement
2023-01-08 14:10:15 <lmarz> ah ok
2023-01-08 14:12:32 <vkrishn> avoid putting "obfuscated" word, more like non human readable
2023-01-08 14:13:21 <psykose> what
2023-01-08 14:13:59 <valerius> lol, I'd call all C++ obfuscated :p
2023-01-08 14:14:00 <lmarz> valerius: that project is completely fine, since they got the original source in the codegen folder
2023-01-08 14:14:24 <valerius> lmarz, but I don't want to include the Python in a project that just uses one of those .h files... seems silly to do that in this case
2023-01-08 14:15:55 <valerius> so basically what I am saying is that maybe there should be wording around such a "light grey" area in the policy
2023-01-08 14:16:23 <lmarz> vkrishn: i think obfuscated is the right word here. Someone shouldn't be punished for not knowing how to write good looking code
2023-01-08 14:16:28 <valerius> since in such a case, the generated code is still human readable... there are other examples I can think of like this too, such as including miniz or miniaudio
2023-01-08 14:16:52 <valerius> both are meant to be vendored using a .c/.h combination, and are both generated
2023-01-08 14:17:20 <valerius> really in all cases they are just mashing up a bunch of other source files to make distribution and reuse easier
2023-01-08 14:17:28 <orbea> miniz is more of an amalgation than generated
2023-01-08 14:17:54 <valerius> well, I would say all of my examples are technically "amalgamations"
2023-01-08 14:19:07 <orbea> i was thinking of something like cryptography that is largely developed in python and compiled in C/rust
2023-01-08 14:19:14 <orbea> but they ship the python
2023-01-08 14:19:40 <lmarz> valerius: i think your use case is already specified in this guideline: "Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code"
2023-01-08 14:19:51 <lmarz> so just link to the repository
2023-01-08 14:19:58 <valerius> works for me
2023-01-08 14:23:04 <vkrishn> lmarz: ok, that word is arguable for me, as I can put it in quatifiable/qualitative paradigm correctly yet
2023-01-08 14:23:12 <vkrishn> I cannot^
2023-01-08 14:39:32 <vkrishn> sad, there is no "blackhole" emoji yet, would be fun to point a 'loop hole' statement in any policy stuffs
2023-01-08 14:43:06 <elly> it isn't even a loophole really, it is intended that you can ship generated code as long as the generator is also available
2023-01-08 14:43:21 <elly> people routinely ship generated configure scripts which are only barely human readable ;P
2023-01-08 14:48:42 <valerius> yeah... never thought about that, it is true
2023-01-08 14:53:47 <vkrishn> elly: I wasn't refering to anything per se, just pointing a missing thing for irc/chat to denote
2023-01-08 14:54:43 <vkrishn> there are emojiis for practically everything these days
2023-01-08 15:00:34 <vkrishn> but its kinda cool to see policy things moving to git though
2023-01-08 15:01:12 <elly> ahh
2023-01-08 15:02:39 <lmarz> vkrishn: the current repository is just temporary though. i don't know where the finalized version will go
2023-01-08 15:53:58 <elibrokeit> psykose: why would agpl software be a license violation if it has patches applied in aports?
2023-01-08 15:54:48 <elibrokeit> also
2023-01-08 15:54:50 <elibrokeit> > though agpl is such a shitshow
2023-01-08 15:55:22 <elibrokeit> why is agpl problematic *at all*, more than gpl, except to people like google who want to run it as a SaaS?
2023-01-08 15:58:41 <ikke> elibrokeit: there is a clause saying that if you have modifications, users should be made aware of that prominently together with where to find the source
2023-01-08 15:58:43 <psykose> the extra clause says that modifications must offer everyone interacting with it over a network the Corresponding Source
2023-01-08 15:58:59 <psykose> for a start that could mean you have to also patch a link into the software to the source
2023-01-08 15:59:04 <ikke> Many AGLP software does not accomodate for that
2023-01-08 15:59:12 <psykose> but not even that, the patches applied do not come next to Corresponding Source
2023-01-08 15:59:20 <psykose> it's a directory in aports with an apkbuild and patch files
2023-01-08 15:59:24 <psykose> not the Corresponding Source
2023-01-08 16:00:02 <psykose> even without the first part to comply with this you need to have a fork somewhere with the patches applied afaict, it does not make sense otherwise
2023-01-08 16:00:17 <elibrokeit> So how does Alpine generally fulfill the GPL requirements
2023-01-08 16:00:22 <elibrokeit> no "A"
2023-01-08 16:00:40 <psykose> it doesn't do anything there either
2023-01-08 16:00:45 <psykose> i'm not talking about alpine
2023-01-08 16:00:49 <psykose> restrictions are cringe and a waste of time
2023-01-08 16:01:07 <psykose> i'm the sort of person that would like if it was possible to write code without having a LICENCE file
2023-01-08 16:01:08 <psykose> it is not
2023-01-08 16:01:14 <psykose> so i hate every second of it
2023-01-08 16:01:40 <elibrokeit> it may or may not be cringe, but AFAICT you were suggesting more than that -- that it violates Alpine's license requirements?
2023-01-08 16:01:57 <psykose> alpine does not have licence requirements
2023-01-08 16:02:09 <psykose> not formal ones anyway
2023-01-08 16:02:17 <ikke> yes
2023-01-08 16:02:19 <ikke> yet*
2023-01-08 16:02:23 <elibrokeit> it's not really difficult to fulfill, anyway. File it under "cringe", write a tool that automatically produces source tarballs combining a) the aport, b) the source tarball
2023-01-08 16:02:31 <elibrokeit> and then you're done
2023-01-08 16:02:38 <psykose> wow! sure love that productive spend of time
2023-01-08 16:02:40 <ikke> But the user also needs to be made aware of it
2023-01-08 16:02:46 <psykose> writing useless tools to do absolutely nothing useful at all
2023-01-08 16:02:58 <ikke> it's not enough to just have some website where the user can download it if they find it
2023-01-08 16:03:28 <elibrokeit> psykose: again, "whether it's cringe or not, why does this stop Alpine from shipping such software"?
2023-01-08 16:03:40 <psykose> again, "im not talking about alpine"
2023-01-08 16:03:57 <ikke> "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of
2023-01-08 16:03:59 <psykose> i never said it stopped anything from being shipped eeither
2023-01-08 16:03:59 <ikke> software."
2023-01-08 16:04:14 <psykose> we have agpl software in aports
2023-01-08 16:04:18 <psykose> not sure where that came frome
2023-01-08 16:05:04 <elibrokeit> > i'm pretty sure anything in aports that has a patch on it that is agpl is breaking the licence
2023-01-08 16:05:12 <psykose> yeah
2023-01-08 16:05:14 <psykose> and i don't give a fuck
2023-01-08 16:05:15 <psykose> like at all
2023-01-08 16:05:43 <psykose> it's still shipped regardless of whether i think it's breaking it or not
2023-01-08 16:05:48 <elibrokeit> but it's not true, anything in aports that has a patch on it that is gpl is indistinguishable from agpl
2023-01-08 16:06:04 <ikke> "If your software can interact with users remotely through a computer network, you should also make sure that it provides a way for users to get its source. For example, if your program is a web application, its interface could display a "Source" link that leads users to an archive of the code. "
2023-01-08 16:06:13 <elibrokeit> and you seem to be blaming this on the "a"?
2023-01-08 16:06:57 <elibrokeit> ikke: if you ship them the compiled program, e.g. in an apk, you must provide the source in whatever gpl-fulfilling way is relevant
2023-01-08 16:07:42 <elibrokeit> the "a" in agpl, simply means that you cannot claim you don't ship the compiled program, you run it on their behalf, and thereby avoid what would otherwise be your gpl obligations
2023-01-08 16:08:00 <psykose> sure, you got me
2023-01-08 16:08:04 <psykose> *gpl is a shitshow
2023-01-08 16:08:09 <psykose> statement amended
2023-01-08 16:08:14 <elibrokeit> so this distinction between gpl and agpl is totally irrelevant to alpine, though it might be relevant to someone running alpine on their website
2023-01-08 16:08:37 <ikke> "The work must carry prominent notices stating that you modified it, and giving a relevant date." (GPL)
2023-01-08 16:08:39 <psykose> it shall hereby read "we break the licence for everything gpl in aports"
2023-01-08 16:08:49 <psykose> sound better? :)
2023-01-08 16:08:57 <elibrokeit> psykose: yes :)
2023-01-08 21:12:50 <Ermine> psykose: what's about !42501 and !42375 ?
2023-01-08 21:13:04 <Ermine> not these
2023-01-08 21:13:25 <Ermine> !42051 and !42735
2023-01-08 21:13:40 <Ermine> sorry for the flood
2023-01-08 21:18:58 <Ermine> thank you!
2023-01-08 21:21:55 <psykose> grats on MR 43k
2023-01-08 21:22:21 <Ermine> :)
2023-01-08 21:23:48 <ikke> goes so fast
2023-01-08 21:27:29 <Ermine> That's good. Gears are spinning
2023-01-08 21:29:43 <psykose> or are they squeaking?
2023-01-08 21:30:40 <Ermine> Depends on your perspective I guess?
2023-01-08 21:35:58 <psykose> just humor :)
2023-01-08 21:37:44 <Ermine> Each joke has a grain of the truth :)
2023-01-08 21:38:23 <ikke> basically one gear that keeps most of it running :p
2023-01-08 21:41:04 <psykose> is it? which one
2023-01-08 21:41:28 <ikke> https://gitlab.alpinelinux.org/alpine/aports/activity
2023-01-08 21:41:52 <psykose> ooh yeah this Peter Shkenev guy
2023-01-08 21:41:53 <psykose> big fan
2023-01-08 22:09:19 <Ermine> I see ikke and psykose and list :D
2023-01-08 22:09:28 <Ermine> in this list
2023-01-09 11:27:20 <ncopa> nmeum: re busybox issue on x86. I believe the issue is the clobbering of ebx registry. Which is used for position independent code (PIC) to be able to do text relocation
2023-01-09 11:28:52 <ncopa> not sure how to fix the inline assembly though, but the idea is to make sure ebx is not clobbered
2023-01-09 11:29:10 <ncopa> GNU assembly syntax is cryptic and complicated
2023-01-09 11:29:41 <nmeum> hm, not sure. my understanding of i386 assembler is too limited to really debug this in-depth. but based on the discussion in #musl I think this due to a text relocation in the assembly file, this seems to be confirmed by the fact that removing the non-relative load from the assembly file fixes the issue
2023-01-09 11:30:01 <nmeum> but idk I really don't know enough i386 assembler
2023-01-09 11:30:42 <nmeum> in the busybox upgrade MR i just went ahead and disabled HW accelleration for the checksum algorithms on i386 for now, that fixes the segfault. maybe denys will be able to fix it
2023-01-09 11:33:46 <ncopa> -fPIC on 32 bit x86 uses ebx. if ebx is used by something, gcc will create textrels
2023-01-09 11:33:50 <ncopa> see https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
2023-01-09 11:35:26 <ncopa> there is actually an example with cpuid there
2023-01-09 12:42:15 <ncopa> im about to do 3.17.1 release. Anything else we should include there?
2023-01-09 16:02:25 <indy> hi all, where to find database with files owned by package?
2023-01-09 16:03:23 <indy> as /var/cache/apk and /var/lib/apk is empty
2023-01-09 16:13:21 <elly> indy: there's no centralized database of that afaik, but you can use `apk info -L $pkg`
2023-01-09 16:23:45 <ncopa> indy: /lib/apk/db/installed
2023-01-09 16:46:08 <elly> til /lib/apk/db
2023-01-09 16:58:16 <lmarz> alright. new round of feedback. i added onto the firmware section and described that CC and GFDL are not compatible with the guidelines and code must not use them
2023-01-09 16:58:20 <lmarz> https://gitlab.alpinelinux.org/lmarz/license-policy/-/blob/main/policy.md
2023-01-09 17:02:02 <elly> is there a reason to have an Alpine-specific version of this, rather than "code must meet the OSI open source definition" or something?
2023-01-09 17:02:07 <elly> I maybe missed some context
2023-01-09 17:03:24 <lmarz> it is actually not the full definition. there is a number 10
2023-01-09 17:04:13 <lmarz> also giving away the control of the requirements is a bit of a risk
2023-01-09 17:04:42 <elly> hmm
2023-01-09 17:04:44 <elly> how's that?
2023-01-09 17:05:15 <lmarz> a malicious actor could infiltrate the OSI and change the definition. Unlikely but possible
2023-01-09 17:05:53 <elly> that could happen, but in that case we could then grab their previous version and say "this is now the alpine policy"?
2023-01-09 17:05:58 <elly> the switching cost is not very high :P
2023-01-09 17:07:20 <lmarz> yes, but we can also do that earlier
2023-01-09 17:07:33 <lmarz> in fact i've already done the work
2023-01-09 17:08:28 <elly> I see
2023-01-09 17:09:33 <elly> hm, do you have ideas for how we might enforce this?
2023-01-09 17:11:12 <lmarz> scripts and manual checking. there is a tool called licensecheck, but it doesn't give the output format i want :(
2023-01-09 17:12:05 <elly> gotcha
2023-01-09 21:43:47 <elly> wait a moment, lua5.4-luastatic is dynamically linked
2023-01-09 21:43:50 <elly> shenanigans!
2023-01-09 21:46:22 <elly> oh, I am being silly
2023-01-09 21:46:24 <elly> disregard that
2023-01-10 00:59:18 <q66> ncopa: some stuff to backport to 6.1: https://github.com/torvalds/linux/commit/58ddbecb14c792b7fe0d92ae5e25c9179d62ff25 , https://gist.github.com/q66/257759e89193d56cfe3047eb5ea6b416
2023-01-10 00:59:32 <q66> i'll probably get upstream to do it, so it will *probably* make it into some 6.1 release
2023-01-10 00:59:35 <q66> but in the meantime
2023-01-10 00:59:49 <q66> context in https://gist.github.com/q66/f67d71b1a5138978cda353499fdd4277
2023-01-10 01:00:18 <q66> things have been broken since 5.19, only got to figure this out now
2023-01-10 07:08:21 <indy> ncopa, elly thanks
2023-01-10 07:10:48 <sam_> psykose: it's fine to not optimise Python modules in packages, but it's often desirable to because then you don't incur startup cost on first run, as well as minimising # of orphaned files on system
2023-01-10 07:10:53 <sam_> (because the .pyc would be owned by the package)
2023-01-10 07:10:55 <sam_> there's some interesting PEP about this too (which we don't utilise in gentoo)
2023-01-10 07:10:59 <sam_> you can make it assume the .pyc is always valid if it exists, and not rehash it
2023-01-10 07:11:09 <sam_> but it means you can't edit random .py on your system and have it work 
2023-01-10 07:11:20 <psykose> pycache and optimise are separate
2023-01-10 07:11:40 <psykose> our python packages do get shipped with .pyc
2023-01-10 07:12:49 <sam_> it invalidates the pyc if you change it though right
2023-01-10 07:12:53 <sam_> but i guess the idea is most people won't bother setting it
2023-01-10 07:13:08 <sam_> https://peps.python.org/pep-0552/ is what i was thinking of 
2023-01-10 07:13:32 <psykose> change what specifically
2023-01-10 07:13:40 <psykose> the -O/PYTHONOPTIMISE pyc is separate
2023-01-10 07:13:50 <psykose> those are named .opt-1 .opt-2 .pyc or whatever
2023-01-10 07:14:45 <psykose> so, if you install a package with the default .pyc, then merely import it, it's already cached. if you python3 -O and import it, it's not and you have to build the opt version first, yada yada
2023-01-10 07:14:48 <sam_> oh right
2023-01-10 07:14:52 <sam_> why did I think they're the same file
2023-01-10 07:14:56 <sam_> got it
2023-01-10 07:14:59 <sam_> followup
2023-01-10 07:15:04 <sam_> does anyone even use asserts in python
2023-01-10 07:15:08 <psykose> that's the main reason i removed it, cause it's literally duplicate files
2023-01-10 07:15:11 <psykose> uhh yeah
2023-01-10 07:15:19 <psykose> i see them.. sometimes
2023-01-10 07:15:27 <psykose> also like
2023-01-10 07:15:39 <psykose> the speed gain is.. nonexistent? idk
2023-01-10 07:15:55 <psykose> and the other thing it removes (docstrings) do break a few packages, i'm not sure why python really even has this option
2023-01-10 07:16:07 <psykose> it's irritating more than anything because people assume it makes stuff go fast
2023-01-10 07:16:34 <psykose> might as well just throw a minifier at your code at that point for the same savings
2023-01-10 07:16:50 <sam_> ive never heard of anyone playing with this and gaining anything from it
2023-01-10 07:17:25 <psykose> the base python stdlib ships with all three caches (opt1, opt2, opt0 pyc's)
2023-01-10 07:17:33 <sam_> -O     : remove assert and __debug__-dependent statements; add .opt-1 before\n\
2023-01-10 07:17:33 <sam_>          .pyc extension; also PYTHONOPTIMIZE=x\n\
2023-01-10 07:17:33 <sam_>          .pyc extension\n\
2023-01-10 07:17:33 <sam_> -OO    : do -O changes and also discard docstrings; add .opt-2 before\n\
2023-01-10 07:17:34 <sam_> this is so lame
2023-01-10 07:17:52 <psykose> there was a proposal somewhere to either split those or remove them, and perhaps add a trigger on /usr/lib/python* to compile on install
2023-01-10 07:18:02 <psykose> but idk this is just a major bikeshed
2023-01-10 07:18:28 <psykose> i think just .pyc is fine
2023-01-10 07:18:37 <psykose> in general, and keeping the python3 default
2023-01-10 07:19:05 <psykose> the python3 installer default of installing wheels with both opt0 and opt1 by default is funny :)
2023-01-10 07:19:17 <psykose> i patched that out some time ago
2023-01-10 07:21:14 <sam_> i can't believe how lame this is
2023-01-10 07:21:44 <sam_> i'd never used it but i didn't know it was so actively pointless
2023-01-10 07:22:26 <psykose> :)
2023-01-10 07:22:38 <psykose> so yeah that's why i got rid of those
2023-01-10 07:22:53 <sam_> btw have libre folks replied
2023-01-10 07:23:01 <psykose> no, but
2023-01-10 07:23:02 <psykose> for some reason
2023-01-10 07:23:05 <psykose> it works in CI
2023-01-10 07:23:06 <psykose> ...
2023-01-10 07:23:21 <psykose> it fails on any terminal i run it in on any machine
2023-01-10 07:23:52 <psykose> merely building it though works, so upgraded fine
2023-01-10 07:24:02 <psykose> just can't build it myself, wtf
2023-01-10 07:26:50 <sam_> huh
2023-01-10 07:28:13 <indy> all: "C:" field i assume is checksum, but of which content?
2023-01-10 07:28:29 <indy> in /lib/apk/db/installed
2023-01-10 07:28:31 <psykose> data subtar iirc
2023-01-10 07:28:47 <psykose> since it's two tars put together
2023-01-10 07:38:25 <indy> i was poking at idea to inject files to virtual '-t' package, let say when you generate some 'delta' config file file in dockerfile during 'run' without creation of apk file
2023-01-10 07:39:11 <psykose> i have no idea what that means
2023-01-10 07:41:26 <sam_> nor do i but that doesn't mean much
2023-01-10 07:41:46 <sam_> i have no idea s about lo but glad it works in CI
2023-01-10 07:41:50 <sam_> i don't even have a guess
2023-01-10 07:42:38 <indy> psykose, something like "apk add -t my-config-generated-in-dockerfile=1.2.3-r0 -f /etc/my.cnf.d/something.conf -f /etc/periodic/15min/do-somedb-check" 
2023-01-10 07:43:34 <psykose> sam_: i tried various setsid and shell stuff and closing fds and it didn't change anything lol, truly cursed
2023-01-10 07:51:30 <nmeum> ncopa: re busybox segfault: even if I entirely remove the busybox cpuid inline assembly code it still segfaults
2023-01-10 08:06:17 <psykose> sam_: i commented on a random google repo and they fixed a regression in like an hour, the pigs are flying
2023-01-10 08:08:57 <sam_> what
2023-01-10 08:09:19 <sam_> total fake news
2023-01-10 08:13:23 <psykose> to be fair it's a 5 char change, but still pleasantly surprised
2023-01-10 09:00:01 <pj[m]> indy: https://wiki.alpinelinux.org/wiki/Apk_spec#APKINDEX_Format
2023-01-10 09:34:35 <donoban> sam_: psykose your conversation reminded me a problem that I saw trying to speed up qutebrowser opening, it seem that it tries to recreate a lot of pyc files causing "Permission denied" errors
2023-01-10 09:35:44 <donoban> uhM, it seems only a python module https://tpaste.us/m6Qx
2023-01-10 09:36:08 <donoban> and PyQt5...
2023-01-10 09:36:19 <psykose> that would be the staleing issue that was linked :)
2023-01-10 09:36:22 <psykose> the bytecode is there
2023-01-10 09:36:25 <psykose> it's invalid for some reason
2023-01-10 09:37:25 <donoban> I see..
2023-01-10 09:37:26 <psykose> hm
2023-01-10 09:37:30 <psykose> ok, i reproduced
2023-01-10 09:37:33 <psykose> lemme look
2023-01-10 09:37:42 <psykose> ah
2023-01-10 09:37:45 <psykose> qt5 ships no bytecode
2023-01-10 09:39:12 <sam_> we have a QA check for something-which-installs-none, it's not just a problem because of ^, but also because it might happen in other packages as well
2023-01-10 09:39:20 <sam_> oh actually
2023-01-10 09:39:22 <sam_> we use gpep517 for that
2023-01-10 09:39:33 <sam_> (gpep517 verify-pyc)
2023-01-10 09:39:34 <psykose> what's something-which-installs-none
2023-01-10 09:39:38 <sam_> sorry
2023-01-10 09:39:46 <sam_> "a package which installs .py but no .pyc"
2023-01-10 09:39:50 <psykose> we use gpep517 but there's no wrappers so i don't use the extras
2023-01-10 09:40:11 <psykose> just build-wheel
2023-01-10 09:44:12 <psykose> this damned pyqt5 build system lol
2023-01-10 09:44:49 <sam_> every time
2023-01-10 09:44:51 <sam_> complete hell
2023-01-10 09:44:53 <sam_> its better than uh
2023-01-10 09:44:55 <sam_> there's some pyqt stuff with a stupid name i can never remember
2023-01-10 09:44:59 <sam_> and it never works
2023-01-10 09:45:28 <psykose> pyqt-sip pyqt-builder?
2023-01-10 09:45:36 <psykose> this sip-build thing is slow as hell and just 1 thread
2023-01-10 09:53:38 <donoban> [397368.204761] zsh[26998]: segfault at 7f4fdab37b2b ip 000055ecc5145b8f sp 00007ffc5e4c69b0 error 4 in zsh[55ecc511c000+6b000] likely on CPU 2 (core 2, socket 0)
2023-01-10 09:53:47 <donoban> lol
2023-01-10 09:54:06 <donoban> it looks reproducible
2023-01-10 09:54:17 <donoban>  M0#M0[397410.510543] zsh[29184]: segfault at 7fce05597b16 ip 0000561a6afd0b8f sp 00007ffefea5cf90 error 4 in zsh[561a6afa7000+6b000] likely on CPU 3 (core 3, socket 0)
2023-01-10 09:59:07 <psykose> how do you reproduce it
2023-01-10 10:00:33 <psykose> yeah doing anything to jinja2 still makes it fail the cache
2023-01-10 10:00:34 <psykose> epic
2023-01-10 10:02:43 <psykose> why does it even try to access some random hash suffix in the dir
2023-01-10 10:03:38 <psykose> in any case it's just a few files
2023-01-10 10:04:36 <donoban> well I've already commented on #zsh, I just expandend 'sudo rm *' on /var/cache/apk, I failed the root password and when retry the command it crashed
2023-01-10 10:05:20 <donoban> probably it passes a too much long string somewhere
2023-01-10 10:06:18 <ncopa> nmeum: seems like busybox segfaults when invoked
2023-01-10 10:07:09 <nmeum> *nod*
2023-01-10 10:07:09 <psykose> yeah, it segfaults on load because of the textrels, no?
2023-01-10 10:07:29 <ncopa> thats what im suspecting
2023-01-10 10:08:17 <nmeum> right. me too
2023-01-10 10:08:20 <psykose> we already confirmed that at the start :) and it fails to link with -Wl,-z,text
2023-01-10 10:08:28 <psykose> (and then tried to fix the asm textrels)
2023-01-10 10:08:58 <psykose> though most of this discussion was in #musl so i think you missed it
2023-01-10 10:09:18 <nmeum> I would suggest that we just ship busybox 1.36.0 without hw acceleration for checksum algorithms on x86 (it wasn't supported before anyhow)
2023-01-10 10:09:43 <nmeum> and then we can backport a fix for it later if denys (or someone else) gets around to fixing it at some point
2023-01-10 10:09:54 <ncopa> sounds good to me
2023-01-10 10:09:58 <ncopa> im looking at it now
2023-01-10 10:10:40 <nmeum> great, I have been running 1.36.0 locally on all of my systems for the past few days and haven't encountered any issues so far. if it stays that way I will merge the upgrade soonish
2023-01-10 10:10:53 <psykose> i've ran 1.36 on my desktop for that long too
2023-01-10 10:10:56 <psykose> no failuures
2023-01-10 10:11:45 <psykose> and yeah +1 from me too, i reviewed all of it, asm is fine for that reason (wasn't there before either)
2023-01-10 10:11:46 <psykose> :)
2023-01-10 10:13:57 <ncopa> $ scanelf --textrels busybox_unstripped | tpaste
2023-01-10 10:13:58 <ncopa> https://tpaste.us/nVKp
2023-01-10 10:15:31 <psykose> dalias commented on it too, saying https://git.busybox.net/busybox/tree/libbb/hash_md5_sha_x86-32_shaNI.S?id=a96ccbefe417aaac6a2ce59c788e01fc0f83902f#n67 is invalid
2023-01-10 10:16:37 <psykose> >it neeeds to be replaced wit ha pc relative load or better the constant should just be constructed some way that doesn't need a memory load
2023-01-10 10:16:49 <sam_> i tend to avoid all the "unstable" busybox ones
2023-01-10 10:16:53 <sam_> but im glad someone tests them
2023-01-10 10:16:55 <sam_> definitely slap --enable-textrel-check=error into binutils though
2023-01-10 10:18:24 <psykose> it would break riscv64
2023-01-10 10:18:34 <psykose> aside from that i would have already done it
2023-01-10 10:18:40 <psykose> hm, or would t
2023-01-10 10:19:24 <psykose> quick test brb
2023-01-10 10:20:02 <nmeum> we could also enable on all arches other then riscv64
2023-01-10 10:20:18 <nmeum> I also don't understand why we ran into all of these textrel issues on riscv64, has someone investigated this further?
2023-01-10 10:20:31 <psykose> i concluded it's bogus but aside from that i don't know what causes it
2023-01-10 10:21:13 <psykose> they get a uhh
2023-01-10 10:21:14 <psykose>  0x0000000000000016 (TEXTREL)            0x0
2023-01-10 10:22:39 <psykose> and yeah that fails with -z text
2023-01-10 10:23:38 <nmeum> is this a binutils bug? https://sourceware.org/bugzilla/show_bug.cgi?id=25694
2023-01-10 10:23:47 <sam_> I remember asking a riscv person and I got an explanation
2023-01-10 10:23:59 <donoban> any clue why x86 failed here? https://gitlab.alpinelinux.org/WhyNotHugo/aports/-/pipelines/149088
2023-01-10 10:24:29 <psykose> yeah it looks like that one
2023-01-10 10:24:50 <sam_> let me find them and ask again
2023-01-10 10:24:52 <sam_> oh, it could easily have been that bug at its core
2023-01-10 10:24:59 <psykose> there is another very annoying binutils riscv bug
2023-01-10 10:25:12 <psykose> objdump/strip fails on ld.lld output for riscv
2023-01-10 10:26:28 <psykose> and yeah, using lld on riscv64 (it actually defaults to -z text) passes something that normally needs a textrel exception
2023-01-10 10:26:47 <psykose> regardless, i can go add the default -z text if you're fine with it (non-riscv)
2023-01-10 10:33:04 <psykose> elly: iirc you fixed narrowing-cast right? it's still technically broken just in a different way
2023-01-10 10:33:23 <psykose> elly: patch for you https://gitlab.alpinelinux.org/alpine/aports/-/blob/c4bfc4834c1fc8538a8adb52081155f2a05c45e2/community/chromium/narrowing-cast.patch
2023-01-10 10:36:04 <psykose> nmeum: y/n for non-riscv --enable-textrel-check=error ? :)
2023-01-10 10:50:40 <ncopa> ok, i found all the textrels in busybox
2023-01-10 10:51:35 <ncopa> i think i have a fix for sha1 but not for sha256 (yet)
2023-01-10 10:57:05 <psykose> donoban: it would be nice to figure out the cause of the segfault :)
2023-01-10 10:57:35 <donoban> on zsh? I get this with debug symbols https://tpaste.us/zQkv
2023-01-10 10:58:43 <donoban> now it crashes in the first attempt, maybe because the looong string is already on the history
2023-01-10 11:00:31 <psykose> 1578 is chline[chwords[chwordpos-2]]
2023-01-10 11:00:42 <psykose> gonna guess something there is out of bounds
2023-01-10 11:04:36 <donoban> well I've already pinged it to #zsh
2023-01-10 11:14:14 <donoban> I would need to rebuild without optimization for inspect chwords/chwordpos
2023-01-10 11:27:05 <psykose> i can reproduce it too
2023-01-10 11:27:30 <donoban> :)
2023-01-10 11:37:33 <psykose> and now i can't, gr
2023-01-10 11:37:38 <psykose> it's very specific on this arg size
2023-01-10 11:39:36 <donoban> https://tpaste.us/X0Vj
2023-01-10 11:40:33 <donoban> chwords is the count of words on the history?
2023-01-10 11:41:02 <psykose> it's a list of something, no idea
2023-01-10 11:41:46 <donoban> (gdb) p chwords[chwordpos-2]
2023-01-10 11:41:48 <donoban> $5 = -5151
2023-01-10 11:41:54 <psykose> :)
2023-01-10 11:42:08 <psykose> what about -3 -4 etc
2023-01-10 11:42:41 <donoban> hmm:.
2023-01-10 11:42:52 <donoban> https://tpaste.us/Lepl
2023-01-10 11:42:58 <donoban> I feel that I'm doing somethiwng wrong
2023-01-10 11:43:11 <psykose> don't think so
2023-01-10 11:45:08 <donoban> ah yes, maybe chwords is overflowed?
2023-01-10 11:45:23 <psykose> yeah the index is wrong somehow
2023-01-10 11:45:24 <psykose> shrug
2023-01-10 11:47:46 <donoban> until chwords[1880] it returns a positive value
2023-01-10 11:58:24 <donoban> psykose: zsh-guy encouraged me to build with --enabme-zsh-mem and other debug options
2023-01-10 11:58:30 <donoban> but now a test fails
2023-01-10 11:58:35 <donoban>  mem.c:1326: MEM: allocation error at sbrk, size 20480.
2023-01-10 12:00:14 <PureTryOut> Where are translated man files supposed to be installed?
2023-01-10 12:01:57 <psykose> same place
2023-01-10 12:02:52 <PureTryOut> just named differently or something?
2023-01-10 12:03:16 <psykose> ah, you mean the build system doesn't install them for you?
2023-01-10 12:03:23 <PureTryOut> yes
2023-01-10 12:03:25 <donoban> has 'abuild rootbld' some kind of memory limit?
2023-01-10 12:03:26 <PureTryOut> I have to do it manually here
2023-01-10 12:04:18 <donoban> Mikachu | ah, musl unconditionally fails on sbrk()
2023-01-10 12:04:41 <psykose> /usr/share/man/$lang/man1/
2023-01-10 12:04:42 <psykose> etc
2023-01-10 12:04:47 <PureTryOut> Ah ok thanks
2023-01-10 12:04:49 <psykose> lang is 2-letter code
2023-01-10 12:05:15 <psykose> we don't auto split those or anything so it's just regular doc
2023-01-10 12:06:05 <dalias> why isnt the rv thing fixed?
2023-01-10 12:06:13 <dalias> whats causibg it?
2023-01-10 12:06:16 <PureTryOut> 👍️
2023-01-10 12:07:45 <psykose> dalias: probably https://sourceware.org/bugzilla/show_bug.cgi?id=25694
2023-01-10 12:13:29 <psykose> PureTryOut: that install location is wrong
2023-01-10 12:14:00 <PureTryOut> Oh no
2023-01-10 12:14:24 <PureTryOut> How so?
2023-01-10 12:15:07 <psykose> man1
2023-01-10 12:15:19 <PureTryOut> It has man1 inside
2023-01-10 12:15:35 <PureTryOut> oh wait nvm
2023-01-10 12:15:40 <PureTryOut> I thought it did, but it doesn't...
2023-01-10 13:27:25 <donoban> psykose: uhm...
2023-01-10 13:27:29 <donoban> it's just a short overlflow
2023-01-10 13:27:35 <donoban> (gdb) p chwords[1880]
2023-01-10 13:27:36 <donoban> $60 = 32731
2023-01-10 13:27:39 <donoban> (gdb) p chwords[1881]
2023-01-10 13:27:41 <donoban> $61 = -32758
2023-01-10 13:27:45 <psykose> :)
2023-01-10 13:27:45 <ncopa> im giving up this assembly stuff. i cannot get it work as expected
2023-01-10 14:08:50 <ddevault> hrm, the qemu group should probably be called kvm
2023-01-10 19:08:54 <Ermine> Can abuild rootbld build with 3.17 repos?
2023-01-10 19:10:06 <psykose> yeah if you're on 3.17-stable
2023-01-10 19:10:10 <psykose> but local repos still override
2023-01-10 19:10:13 <psykose> no idea how it works
2023-01-10 19:12:17 <Ermine> I'm on edge, so edge repos kicked in
2023-01-10 19:13:34 <psykose> no, the checkout
2023-01-10 19:15:17 <Ermine> I'm on branch originated from 3.17-stable
2023-01-10 19:25:21 <psykose> has to start with 3.17 in the name probably
2023-01-10 19:40:01 <Ermine> Ok, will do this way next time
2023-01-10 22:36:07 <omni> psykose: py3-botocore: depends="py3-dateutil<3.0 py3-docutils py3-jmespath<1.0.0 py3-urllib3<1.27"
2023-01-10 22:37:21 <psykose> somehow missed those
2023-01-11 02:00:31 <wcf> hello
2023-01-11 02:06:05 <psykose> what's up
2023-01-11 14:46:28 <elly> should the standard installer contain wpa_supplicant?
2023-01-11 14:46:42 <elly> or standard image, rather
2023-01-11 14:47:04 <elly> and/or: should the words on https://www.alpinelinux.org/downloads/ mention that laptop users probably want "extended" instead?
2023-01-11 14:48:51 <elly> also psykose chromium 109! I think a few patches can go
2023-01-11 15:07:00 <ptrc> elly: it's already there :p see commit c2b2073721
2023-01-11 15:07:09 <ptrc> ( aw, algitbot, come on )
2023-01-11 15:07:24 <ptrc> gitlab.alpinelinux.org/alpine/aports/-/commit/c2b2073721
2023-01-11 15:07:59 <elly> heck yeah
2023-01-12 03:12:07 <psykose> elly: did you see my ping about a specific patch? :)
2023-01-12 03:41:52 <elly> I didn't
2023-01-12 03:41:55 <elly> where was it?
2023-01-12 03:42:06 <elly> oh, wait, there it is
2023-01-12 03:42:18 <elly> I thought I did fix narrowing-cast! I deleted the involved code
2023-01-12 03:42:22 <elly> I'll check tomorrow
2023-01-12 04:08:49 <psykose> it's just in another file now :p
2023-01-12 04:09:07 <psykose> but the new patch looks directly upstreamable anyway
2023-01-12 04:12:04 <elly> ugh okay, I will chase that code down and actually get rid of it
2023-01-12 04:12:06 <elly> it is bad code
2023-01-12 08:05:37 <boomanaiden154> psykose: !43118
2023-01-12 08:05:47 <boomanaiden154> Will hopefully fix the x86_64 builder.
2023-01-12 08:06:04 <boomanaiden154> Can't tell currently if the test is just flaky or if it's just broken on the actual builder for some reason.
2023-01-12 08:06:07 <psykose> thanks
2023-01-12 08:06:22 <psykose> yeah idk, passed on ci
2023-01-12 08:06:50 <ikke> images not close (rms)
2023-01-12 08:06:52 <ikke> hmm
2023-01-12 08:08:12 <boomanaiden154> The specific RMS value there doesn't look too big but I'm not super familiar with those values to be able to say for certain.
2023-01-12 08:08:20 <boomanaiden154> I'm guessing it's just flaky for whatever reason.
2023-01-12 08:09:01 <boomanaiden154> Also seems like recent LLVM bumps have a version typo (15.0.7->15.0.2). :b
2023-01-12 08:09:13 <boomanaiden154> Not a big deal and a little bit too late to fix it now.
2023-01-12 08:10:16 <psykose> yeah
2023-01-12 08:10:21 <psykose> i typod the commit
2023-01-12 08:10:42 <psykose> and it's in all 8 messages because i did it in a loop :p
2023-01-12 08:11:13 <ikke> devoops
2023-01-12 08:11:56 <psykose> annoyingly there is a fix in there that fixes something that was broken in rust
2023-01-12 08:12:01 <psykose> and i somehow didn't see it for hours
2023-01-12 08:12:10 <psykose> i was like.. this is totally in .6...
2023-01-12 08:12:19 <psykose> i was looking at like the completely wrong commit i guess
2023-01-12 08:12:24 <psykose> would have backported it ages ago
2023-01-12 08:12:50 <psykose> (https://github.com/llvm/llvm-project/commit/67fd0d2af4bf9e939ebcccb2b66552a31789af94)
2023-01-12 08:19:57 <boomanaiden154> Interesting. It's always interesting to see the compiler bugs that make it into the wild.
2023-01-12 08:22:32 <psykose> yeah, it's a niche error hit with lto = "fat" only in rust on aarch64 and only for a single crate (img iirc) in combination with the way it was used in a binary (a refactor that didn't touch the deps also removes the failure)
2023-01-12 08:23:18 <psykose> there's also some broken codegen for armv7/v6 in some cases still i think, not sure if anyone has reported it
2023-01-12 08:23:57 <psykose> judging by the lack of google hits for the message i'll got with no
2023-01-12 08:25:34 <boomanaiden154> Yeah. If it's not on the mailing list (discourse now) or issue tracker, no one has probably seen it.
2023-01-12 08:26:07 <boomanaiden154> Reporting compiler bugs can take quite a bit of work though since a minimal example is incredibly helpful
2023-01-12 08:26:54 <boomanaiden154> I'm also guessing that there's a lot less work going into armv6/armv7 compiler stuff at this point due to the age of those cores.
2023-01-12 08:26:55 <psykose> yeah, that's why i haven't done it yet :)
2023-01-12 08:27:27 <psykose> i like getting a nice reproduction down if possible
2023-01-12 08:29:51 <boomanaiden154> Yep. Makes everything a lot nicer. If you can get everything into a single preprocessed source file (or IR), you should be able to use a tool like bugpoint to automatically minimze the example.
2023-01-12 10:12:31 <indy> hi all, is there way to set parts of apkbuild conditional? to be precise, i have package which is failing on openssl-dev, which in 3.17 is version 3
2023-01-12 10:17:26 <ikke> yes, but limited
2023-01-12 10:27:08 <psykose> what is the condition?
2023-01-12 10:27:19 <psykose> the question doesn't make much sense like that
2023-01-12 10:27:26 <psykose> it's just a shell script, you can use `if` for anything
2023-01-12 10:27:40 <ikke> Yes, but you should not fork in the global scope
2023-01-12 10:27:51 <psykose> if doesn't fork
2023-01-12 10:28:14 <ikke> Sure, but I mean for intance invoking apk
2023-01-12 10:28:34 <psykose> that doesn't have much point since you put what you want in makedepends
2023-01-12 10:28:45 <psykose> (see, the question doesn't make sense without knowing what the point is)
2023-01-12 10:29:27 <indy> i'm building https://github.com/open62541/open62541
2023-01-12 10:30:05 <psykose> post what you've done so far, the error logs, ..
2023-01-12 10:30:07 <indy> i have apkbuild, which is passing on 3.16 (openssl-dev < 3.0) but failing on 3.17
2023-01-12 10:30:53 <ikke> Those are on different branches though, or are you trying to use the same APKBUILD for different stable releases?
2023-01-12 10:32:27 <indy> https://dpaste.org/nTR4K
2023-01-12 10:32:40 <psykose> upgrade to 1.3.4 which supports openssl3 too
2023-01-12 10:32:42 <psykose> issue fixed
2023-01-12 10:32:47 <psykose> i can build it fine :)
2023-01-12 10:34:11 <indy> ha :)
2023-01-12 10:34:33 <indy> thanks for pointing to new release
2023-01-12 10:37:42 <psykose> but for future reference to answer your question in this case.. i don't think there's a conditional on current release version. for aports this doesn't have much use since we know the branch ourselves
2023-01-12 10:37:45 <psykose> but for downstream.. hm
2023-01-12 10:38:36 <psykose> if you don't mind the top-level subshell fork slowness bad practice (easy solution) you can get the current version from /etc/os-release and use that as a conditional, then set makedepends based on that
2023-01-12 10:38:58 <psykose> obviously that sucks but for a workaround it should work
2023-01-12 10:40:36 <psykose> i.e. _isnew=$(grep -q 3.17 /etc/os-release && echo yes || echo no); if [ "$_isnew" = "yes" ]; makedepends="$makedepends openssl1.1-compat-dev" ...
2023-01-12 10:42:08 <indy> at work i have one branch for all and from same APKBUILD i build same versions for all supported alpine releases
2023-01-12 10:42:20 <psykose> there are a lot of makedepend conditionals in aports but only with case/if/pattern-substitution which doesn't need a subshell or program invocation, so there are no forks on sourcing all of aports, so you are limited to a pretty small list of data
2023-01-12 10:42:31 <psykose> yeah, that makes it a bit harder, there's a lot of changes between versions
2023-01-12 10:43:04 <psykose> it would probably be harmless to add a alpine_release= variable to abuild, but you would have to query ncopa for it
2023-01-12 10:43:18 <psykose> then you can just have one case block using it, in a hypothetical future
2023-01-12 10:44:14 <psykose> and given that it's not useful for us it would be a harder sell since it's purely downstream :) but that's the approach i would go for
2023-01-12 10:44:21 <ncopa> wouldnt it make more sense to have a git_branch variable set by abuild?
2023-01-12 10:44:28 <psykose> sure, same thing
2023-01-12 10:44:34 <psykose> er
2023-01-12 10:44:37 <psykose> actually, is it
2023-01-12 10:44:49 <psykose> the point in the above is it's the same branch
2023-01-12 10:44:59 <psykose> nothing changes except the os-release version and repositories
2023-01-12 10:45:08 <psykose> it's just a repo with one branch that builds for all versions
2023-01-12 10:45:16 <ncopa> right
2023-01-12 10:45:58 <psykose> so if we added a alpine_release that added a single source of os-release on startup (the cost of doing that), it gives the wanted metadata
2023-01-12 10:46:45 <ncopa> actually, i dont think we need to
2023-01-12 10:47:03 <psykose> is it there already somehow
2023-01-12 10:47:29 <ncopa> building for multiple alpine releases using same branch is not really supported
2023-01-12 10:47:31 <ncopa> however
2023-01-12 10:47:47 <ncopa> you can do it yourself by adding those lines to /etc/abuild.conf:
2023-01-12 10:48:06 <ncopa> . /etc/os-release ; export VERSION_ID
2023-01-12 10:48:14 <ncopa> and in your APKBUILD do:
2023-01-12 10:48:16 <psykose> aha, right
2023-01-12 10:48:23 <psykose> abuild.conf has a single source
2023-01-12 10:48:24 <ncopa> case "$VERSION_ID"
2023-01-12 10:48:27 <psykose> yeah
2023-01-12 10:48:32 <psykose> you can do anything with that then :)
2023-01-12 10:48:39 <psykose> lets you set everything up
2023-01-12 10:48:41 <psykose> forgot about that
2023-01-12 10:48:57 <ncopa> so we dont need to add anything to abuild
2023-01-12 10:49:00 <psykose> yep
2023-01-12 10:49:28 <ncopa> re abuild, there are a couple of things I'd like to do
2023-01-12 10:49:43 <ncopa> one is change the ~/.abuild config location to ~/.local/abuild
2023-01-12 10:49:55 <psykose> you mean ~/.config/abuild ?
2023-01-12 10:50:10 <ncopa> yeah, 
2023-01-12 10:50:37 <ikke> not .config/abuild?
2023-01-12 10:50:41 <ikke> oh
2023-01-12 10:50:43 <ikke> :P
2023-01-12 10:50:45 <ikke> I'm slow
2023-01-12 10:50:55 <ncopa> $XDG_CONFIG_HOME/abuild
2023-01-12 10:51:14 <ncopa> but im afraid of breaking backwards compat
2023-01-12 10:51:40 <ikke> Most of the time, there is a fall-back
2023-01-12 10:51:57 <ikke> if $XDG_CONFIG_HOME/abuild exists, use that, otherwise fall back to ~/.abuild
2023-01-12 10:52:04 <ncopa> maybe we should have abuild move ~/.abuild -> ~/.config/abuild?
2023-01-12 10:52:13 <ikke> Not sure
2023-01-12 10:52:21 <ncopa> and create symlink
2023-01-12 10:52:58 <ikke> I prefer fall-back honestly
2023-01-12 10:53:22 <ikke> Same approach as git does, no need to touch files in users $HOME
2023-01-12 10:54:18 <psykose> yeah migration scripts are not a great idea
2023-01-12 10:54:26 <mercenary> isn't the canonical way fallback plus deprecation warning?
2023-01-12 10:55:09 <ncopa> fallback + deprecation warning sounds good
2023-01-12 10:55:17 <psykose> also has to be ${XDG_CONFIG_HOME:-$HOME/.config}
2023-01-12 10:56:17 <ncopa> what happens if both ~/.config/abuild and ~/.abuild exists?
2023-01-12 10:56:57 <mercenary> ~/.abuild gets ignored, possibly with warning
2023-01-12 10:58:10 <mercenary> (or if you want maximum confusion, the one with the highest timestamp gets used)
2023-01-12 10:59:39 <ncopa> :)
2023-01-12 11:01:32 <ikke> on even months, on odd months the one with the oldest timestamps gets used
2023-01-12 11:03:14 <ncopa> i summarized it here: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10090
2023-01-12 11:07:47 <ncopa> i woudl also like to move the ~/packages directory
2023-01-12 11:08:09 <ncopa> probably to ~/.local/share/abuild or similar
2023-01-12 11:09:22 <ncopa> maybe something like $XDG_DATA_HOME/abuild/$(git_branch)/$repodir/$arch
2023-01-12 11:12:37 <mercenary> hmm. $(git_branch)? That will probably fail on my local packages, where there is no such thing as git.
2023-01-12 11:15:54 <psykose> git_branch would require people to edit/addstuff to /etc/apk/repositories constantly for various reasons
2023-01-12 11:16:08 <psykose> don't think that should be in there really
2023-01-12 11:19:10 <ncopa> the probem i'd like to solve is being able to do git checkout of stable branch, and build things without mixing it with edge builds
2023-01-12 11:19:34 <ncopa> so i could work on edge pacakges, doing rebuilds
2023-01-12 11:19:47 <ncopa> and then deal with an emergency security fix for stable branches
2023-01-12 11:20:01 <ncopa> just checkout 3.17-stable, do the build, and then switch back
2023-01-12 11:20:14 <ncopa> without mixing the deps from edge
2023-01-12 11:20:28 <ncopa> which means containerized builds as default
2023-01-12 11:20:39 <psykose> that would fix abuild rootbld pulling local edge-linked packages too yeah
2023-01-12 11:21:01 <psykose> it's just annoying for /etc/apk/repositories management for quite a few cases i think :/
2023-01-12 11:27:34 <ncopa> we should probably not use /etc/apk/repositories at all
2023-01-12 11:27:50 <ncopa> at least not for containerized builds
2023-01-12 11:48:00 <donoban> ey psykose , did you discovered something about pyqt and pyc files?
2023-01-12 11:48:46 <psykose> they're there now
2023-01-12 11:48:57 <donoban> ohh, great
2023-01-12 11:48:59 <psykose> didn't figure out the jinja ones but that's like 6 files and not very relevant :p
2023-01-12 11:49:24 <psykose> i don't think it will make it start any faster anyway
2023-01-12 11:49:33 <psykose> most of it is just the slowness of python starting qt stuff i guess
2023-01-12 11:49:38 <donoban> ouch, I'm gonna test
2023-01-12 11:51:55 <donoban> meh.. it tooks several seconds
2023-01-12 12:14:42 <psykose> for me it's like 1
2023-01-12 12:15:39 <donoban> I suppose that something happens on my setup
2023-01-12 12:24:56 <donoban> psykose: do you use wayland?
2023-01-12 12:25:01 <psykose> ye
2023-01-12 12:25:59 <donoban> it tooks here near 2seconds before try to connect wayland socket
2023-01-12 12:26:31 <donoban> and like 3 to get a window, is not a huge deal but I would like to see it faster
2023-01-12 12:26:57 <psykose> strace? or
2023-01-12 12:27:03 <psykose> how did you time that
2023-01-12 12:27:23 <donoban> yes, I saw 12:24:11 connect(3, {sa_family=AF_UNIX, sun_path="/tmp/runtime/wayland-1"}, 25) = 0 <0.000013>
2023-01-12 12:27:44 <donoban> it started on 12:24:09 execve("/usr/bin/qutebrowser", ["qutebrowser", "/"], 0x7ffe635fd3b0 /* 11 vars */) = 0 <0.000664>
2023-01-12 12:30:49 <psykose> yeah for me it's 1
2023-01-12 12:30:51 <psykose> dunno
2023-01-12 12:30:57 <psykose> all the web browsers take that long for me
2023-01-12 12:31:32 <donoban> maybe it's just hardware difference
2023-01-12 12:32:26 <psykose> well yeah mine is probably faster, but idk why it takes any amount of time here :)
2023-01-12 12:32:33 <psykose> i profiled it a bit and all the time is just python importing
2023-01-12 12:32:50 <psykose> (py-spy record)
2023-01-12 12:36:42 <donoban> uhM, can't run it without root permission?
2023-01-12 12:47:08 <ndh> Hi, Can I bother one of the devs to have a quick peak at: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43125 ? I'm just wondering if I managed to create a proper merge request this time :D Tnx!
2023-01-12 12:49:00 <ikke> Yeah, MR itself is fine this time
2023-01-12 12:49:12 <ikke> did't look at the details
2023-01-12 12:53:17 <ndh> Good to know - Thanks!
2023-01-12 12:56:11 <donoban> psykose: I get this but qutebrowser crashed because it can't run as root https://share.riseup.net/#CANHIpCLIT2Hi1sQLwEHew
2023-01-12 12:56:23 <psykose> you don't need root to run that
2023-01-12 12:56:24 <donoban> at least it connected to wayland
2023-01-12 12:56:40 <donoban> uhM
2023-01-12 12:57:00 <donoban> lol
2023-01-12 12:57:03 <donoban> now works :\
2023-01-12 12:57:08 <donoban> but it complained about not being root
2023-01-12 12:57:20 <donoban> maybe as due SYS_PTRACE caps
2023-01-12 12:57:24 <donoban> ok
2023-01-12 12:57:46 <donoban> let's generate a full profile
2023-01-12 12:58:08 <donoban> I see this message 'Permission Denied: Try running again with elevated permissions by going 'sudo env "PATH=$PATH" !!''
2023-01-12 12:58:18 <donoban> but it seems that worked
2023-01-12 12:59:49 <donoban> https://share.riseup.net/#9lk1WH_xanK0uZf2K0WGqQ
2023-01-12 13:01:40 <donoban> i don't understand very deep the output
2023-01-12 13:10:54 <donoban> lol, I was uploading the same file, the permisison error was writting the result
2023-01-12 13:10:55 <donoban> :D
2023-01-12 15:08:29 <nmeum> just pushed busybox 1.36.0 let me know if anything breaks 🤞
2023-01-12 15:09:01 <skarnet> did it push back?
2023-01-12 16:14:48 <ikke> apparently, we didn't hear back from nmeum
2023-01-12 16:19:05 <psykose> rip nmeum :-(
2023-01-12 16:19:22 <psykose> exhausted by phd work, slain by a lv36 busybox
2023-01-12 16:19:28 <psykose> may he rest in peace
2023-01-12 16:19:41 <Ermine> F
2023-01-12 16:23:35 <donoban> :\
2023-01-12 16:29:53 <minimal> could someone consider merging !43022 and !43023 please
2023-01-12 16:35:26 <psykose> i've seen it but i've been waiting for what upstream thinks
2023-01-12 16:37:19 <psykose> sure though i guess it's kind of benign
2023-01-12 16:48:18 <minimal> its introducing the same behaviour as the ifupdown package has had for some time
2023-01-12 16:48:24 <minimal> psykose: thanks for the merge
2023-01-12 16:50:32 <psykose> yeah
2023-01-12 17:43:13 <nmeum> psykose: haha
2023-01-12 17:49:37 <elly> who needs to review https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/120 for it to get merged?
2023-01-12 17:50:32 <ikke> fabled 
2023-01-12 17:51:09 <ikke> He's busy, works on apk-tools from time to time
2023-01-12 17:51:20 <elly> ah, okay
2023-01-12 19:06:15 <elly> oh i missed that there is a feedback
2023-01-12 19:08:28 <psykose> i would like to purchase a feedback
2023-01-12 19:08:39 <elly> 
ACTION offers psykose one (1) feedback

2023-01-12 19:09:23 <psykose> how much?
2023-01-12 19:10:31 <Ermine> feedback(1)
2023-01-12 19:10:40 <elly> you can have it for free
2023-01-12 19:10:45 <elly> feedback is a gift, as they say
2023-01-12 19:32:56 <JanJ[m]> unless its feedback in the primary warp exhaust controll conduit.. then its a disaster
2023-01-12 19:35:41 <psykose> nobody owns one of those
2023-01-12 20:32:23 <elly> psykose: I don't understand why chromium narrowing-cast.patch became newly required; that is a separate instance of unsafe narrowing that I didn't address & that code in base/system/sys_info_posix.cc has been there for many releases
2023-01-12 20:32:44 <psykose> idk either but it did fail there now :p
2023-01-12 20:33:14 <psykose> my only immediate guess is that _MAGIC does not come from libc somehow and that changed
2023-01-12 20:33:18 <psykose> you could remove it, then build
2023-01-12 20:33:27 <psykose> and you would see, or see a lack of error
2023-01-12 20:34:14 <elly> yeah
2023-01-12 20:34:32 <elly> or perhaps the compiler options changed
2023-01-12 20:35:14 <psykose> ah yeah
2023-01-12 20:36:51 <elly> wait, where does HUGETLBFS_MAGIC come from in musl?
2023-01-12 20:37:23 <elly> glibc defines it, but my copy of the musl source does not
2023-01-12 20:39:00 <psykose> uapi linux/magic.hh
2023-01-12 20:39:03 <psykose> h
2023-01-12 20:39:17 <psykose> hugetlb is kernel so it's not from libc
2023-01-12 20:39:21 <elly> oh right
2023-01-12 20:39:28 <psykose> well
2023-01-12 20:39:32 <psykose> i guess all of them are kernel
2023-01-12 20:39:52 <elly> hm
2023-01-12 20:43:09 <elly> in glibc __fsword_t is a signed long, in musl those fields (f_type, etc) are unsigned long
2023-01-12 20:43:12 <elly> deeply unfortunate
2023-01-12 20:44:12 <psykose> i don't really understand why the cast is even there
2023-01-12 20:44:54 <psykose> in C you can do switch (whatever) { case 5:
2023-01-12 20:45:04 <psykose> what is the static_cast<int>(5) accomplishing
2023-01-12 20:48:28 <elly> psykose: if f_fsid was an int, then clang would warn that 0x958458f6 cannot be narrowed to int
2023-01-12 20:49:49 <psykose> ah right different types
2023-01-12 20:49:54 <elly> right
2023-01-12 20:49:58 <psykose> sure, cast to unsigned long and call it a day
2023-01-12 20:49:59 <elly> and HUGETLBFS_MAGIC is > INT_MAX
2023-01-12 20:50:13 <psykose> or rather
2023-01-12 20:50:22 <elly> if I cast it to unsigned long I think it will complain under *glibc* because there f_fsid is signed
2023-01-12 20:50:23 <psykose> static_cast<__fsword_t>
2023-01-12 20:50:25 <elly> I may need to cast both
2023-01-12 20:50:45 <elly> musl does not define __fsword_t :(
2023-01-12 20:51:08 <psykose> :p
2023-01-12 20:51:46 <elly> I'll figure something out
2023-01-12 20:52:06 <elly> it would be very cool if musl and glibc did not disagree about the signedness of this type, although that is obviously glibc's fault
2023-01-12 20:52:22 <elly> for literally using a signed type and then saying in its own man page to use an unsigned type
2023-01-12 21:05:08 <elly> psykose: well, the good news is that I asked some C++ knowers and both static_cast<int> and static_cast<unsigned int> are equally wrong
2023-01-12 21:05:12 <elly> but I think I have a real fix :)
2023-01-12 21:05:24 <psykose> sure, just the other way around
2023-01-13 00:24:26 <elly> psykose: I just saw you tagged me on https://gitlab.alpinelinux.org/alpine/aports/-/issues/14533 - I've seen this bug myself as well but never caught it in a debugger before
2023-01-13 00:24:49 <elly> that's exciting
2023-01-13 00:24:52 <psykose> :)
2023-01-13 00:24:59 <psykose> tbh i didn't think anyone used the media panel
2023-01-13 00:25:19 <psykose> i clicked it once cause i saw it and crashed it then bookmarked it in my head for another day
2023-01-13 00:25:58 <psykose> (i have my media keys in my keyboard finger cache)
2023-01-13 00:26:07 <elly> yeah, I do not usually try to use it
2023-01-13 00:26:11 <elly> I think the Cast UI crashes the same way
2023-01-13 00:26:16 <psykose> ah!
2023-01-13 00:26:18 <psykose> yeah
2023-01-13 00:26:23 <psykose> the crash is windowing related
2023-01-13 00:26:29 <psykose> since it goes all the way to the dawn wm
2023-01-13 00:26:46 <psykose> are there other subsystems that spawn such a 'sub window'? they probably all crash
2023-01-13 00:27:07 <psykose> regular like screensharing ui window is not the same type iirc
2023-01-13 00:27:41 <psykose> given the weird pointer stuff i'm not sure where the issue lies
2023-01-13 00:33:16 <elly> hum
2023-01-13 00:33:25 <elly> I'll file an upstream bug & take a look during work tomorrow
2023-01-13 00:33:45 <elly> the object lifetimes are pretty tangled
2023-01-13 00:34:26 <elly> psykose: do you have a debug build available locally?
2023-01-13 00:34:42 <psykose> i did but not anymore
2023-01-13 00:34:45 <elly> ah okay
2023-01-13 00:34:47 <elly> maybe I can make one
2023-01-13 00:34:48 <psykose> i can build another i guess
2023-01-13 00:34:58 <elly> because I bet if we change this DCHECK: https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ui/media_router/media_router_ui.h;l=287;bpv=1;bpt=1 to a CHECK, it'll crash there
2023-01-13 00:35:10 <psykose> it crashes lldb to open the damn thing
2023-01-13 00:35:12 <elly> and reveal that ownership of the MediaStartRouter was handed off with the dialog still open
2023-01-13 00:35:15 <psykose> (which is yet another thing for be to debug)
2023-01-13 00:35:18 <elly> heh
2023-01-13 00:35:29 <elly> what's the nicest way to get a debug build? do you use abuild for that?
2023-01-13 00:35:32 <psykose> the lldb bt crashes at 250k frames so it's an infinite something somewhere
2023-01-13 00:35:44 <elly> yeah, the stack is probably not trustworthy at that point
2023-01-13 00:36:27 <psykose> i change symbol_level to =1 or =2, then add use_thin_lto=false and then just abuild deps prepare build, C-c and go into the tree and use ninja manually for the rest
2023-01-13 00:36:36 <elly> great, ok
2023-01-13 00:36:40 <psykose> i'm very used to building stuff so everything takes me a few seconds, doesn't really matter
2023-01-13 00:36:54 <elly> haha, it will absolutely not take me a few seconds
2023-01-13 00:36:56 <elly> laptop gang
2023-01-13 00:37:08 <psykose> i mean the actions themselves :) but yeah
2023-01-13 00:37:12 <elly> ah yes
2023-01-13 00:37:20 <psykose> build will be maybe 5-8 hours
2023-01-13 00:37:22 <psykose> for a laptop
2023-01-13 00:37:23 <elly> ya
2023-01-13 00:37:25 <psykose> i'd wager
2023-01-13 00:37:42 <psykose> distcc kinda works (though a lot of chromium is java/node/python scripts for devtools)
2023-01-13 00:37:57 <elly> I *suspect* that what's going on here is, official builds have some component that takes ownership of that MediaStartRouter and kills the original dialog, but chromium builds do not have that component and they hand ownership off into oblivion with the dialog still open
2023-01-13 00:38:22 <psykose> maybe, but wouldn't that crash any chromium
2023-01-13 00:38:27 <psykose> i doubt this is broken on arch
2023-01-13 00:38:33 <elly> it quite possibly does crash any chromium
2023-01-13 00:38:38 <psykose> :)
2023-01-13 00:38:51 <elly> the overlap between chromium users and people who try to use the media router UI is probably like, 0
2023-01-13 00:38:56 <psykose> i'll spinny another build and try the dcheck for fun
2023-01-13 00:39:24 <psykose> in sad news llvm was just upgraded today so no ccache for me
2023-01-13 07:11:54 <sam_> > not using ccache for everything
2023-01-13 07:15:06 <psykose> the version change invalidates the cache
2023-01-13 07:15:15 <psykose> yes i know you're a zoomer that passes ignore version check
2023-01-13 07:54:26 <sam_> i actually started to and stopped
2023-01-13 07:55:14 <psykose> too spicy?
2023-01-13 07:56:43 <sam_> so I started doing it in gcc-config, then I realised very quickly that you can't get away with that because it'll affect when users are setting clang
2023-01-13 07:56:44 <sam_> butttt
2023-01-13 07:56:50 <sam_> compiler_check = %compiler% -dumpversion
2023-01-13 07:56:51 <sam_> is good enough
2023-01-13 07:56:57 <sam_> because it'll only include major versions
2023-01-13 07:58:14 <psykose> clang -dumpversion # 15.0.7
2023-01-13 07:58:27 <psykose> afaik it just does equality to numbering, no?
2023-01-13 07:58:29 <psykose> i didn't check
2023-01-13 07:58:32 <sam_> fuckers
2023-01-13 07:58:39 <sam_> gcc does just 12/11/etc for me
2023-01-13 07:58:43 <psykose> haha
2023-01-13 07:58:50 <psykose> well sure, plus gcc seldom gets any minors
2023-01-13 07:59:04 <psykose> just a '12.1' then maybe a '12.2' and then a year passes
2023-01-13 07:59:15 <psykose> the rest is distro backports
2023-01-13 07:59:33 <sam_> the problem was that gcc -v or whatever or --version always includs all the backports
2023-01-13 07:59:44 <psykose> yeah ours is like
2023-01-13 07:59:52 <psykose> gcc (Alpine 12.2.1_git20220924-r8) 12.2.1 20220924
2023-01-13 07:59:55 <psykose> you sneeze at it wrong..
2023-01-13 08:00:05 <psykose> dumpversion is 12.2.1
2023-01-13 08:00:32 <sam_> but damn
2023-01-13 08:00:34 <sam_> i'm gutted now
2023-01-13 08:00:44 <sam_> we started doing --with-major-version-only a few months ago to match the slotting because otherwise you end up with issues on upgrades when they mismatch
2023-01-13 08:00:48 <sam_> so that explains that
2023-01-13 08:04:31 <sam_> ok compiler_check = %compiler% -dumpversion | head -1 | cut -d '.' -f1
2023-01-13 08:04:33 <sam_> 
ACTION prays

2023-01-13 08:05:01 <psykose> 500 second compiler check
2023-01-13 08:05:08 <psykose> doesn't that run on every job lol
2023-01-13 08:06:29 <sam_> STOP IT
2023-01-13 10:42:16 <donoban> hi, could someone take a look on !42949? it seems ready for merge
2023-01-13 11:05:50 <ndh> pimd-dense should be ok now - has one licence warning that I think is incorrect. Please let me know if there are other things that I missed (mr: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43155)
2023-01-13 15:05:15 <elly> psykose: I got the media controls crash to repro locally, and I think the cast crash I mentioned is maybe the same, because the cast dialog tries to show the media controls dialog when you start casting
2023-01-13 16:04:23 <elly> upstream bug https://crbug.com/1407202 now
2023-01-13 16:48:54 <elly> (the upstream bug is now private because I am unsure if there are security implications :\)
2023-01-13 16:54:12 <sam_> :(
2023-01-13 17:00:18 <omni> "test building"?
2023-01-13 17:02:37 <omni> I mean the vault commits that landed in master
2023-01-13 17:05:15 <minimal> I guess he forgot to make it a draft MR
2023-01-13 17:07:31 <omni> I didn't find any corresponding MR
2023-01-13 17:07:46 <omni> but may have missed something
2023-01-13 17:08:24 <minimal> ah, I think he has direct commit access
2023-01-13 17:13:11 <mcrute> omni: that was a direct commit, the package has been failing to build UI on multiple builders... this change enables UI for all architectures to test that fix but it's otherwise 1.12.2, once armhf finishes (it's backlogged by a kernel build) I'll push a r3 with the final changes
2023-01-13 17:13:59 <mcrute> the only effect of this being released is that ui is enabled for more architectures
2023-01-13 17:14:05 <alpine-meetbot> mcrute meant to say: the only effect of this being released is that ui is available for more architectures
2023-01-13 17:14:05 <mcrute> s/enabled/available/
2023-01-13 17:19:53 <elly> psykose: I figured it out, and figured out why it doesn't crash official chrome builds on linux
2023-01-13 17:20:00 <elly> unfortunately the answer is horrible
2023-01-13 17:22:07 <omni> mcrute: did you try it on the CI builders first?
2023-01-13 17:23:33 <omni> or you mean that this was a test to see if it built on the main builders?
2023-01-13 17:24:31 <mcrute> I didn't run it through the CI builders, that would have been easier
2023-01-13 17:25:22 <mcrute> but IIRC it worked on the CI builders in the past but failed on main so I wanted to see it succeed on main builders
2023-01-13 17:30:54 <omni> I think it's ideal to have changes go through CI builders first to catch things before they go to the package builders
2023-01-13 17:31:18 <omni> 1.12.1 failed for aarch64 in !40176 for example
2023-01-13 17:35:47 <mcrute> yeah I guess that would have probably caught the issue then
2023-01-13 17:41:54 <omni> the CI builders are a great tool for this =)
2023-01-13 17:43:00 <mcrute> yup, great point :-D
2023-01-13 17:43:01 <omni> I also try to have the habbit to at least look at the end of one or two logs, even when checks are green, to see that files aren't added or removed that shouldn't be
2023-01-13 17:44:45 <omni> and then things may still break on the package builders, even when they pass the CI builders, because they're slightly different, but you catch most things going through them
2023-01-13 17:45:57 <ikke> Hmm, one error in the log also indicates it tries to use bundled binaries?
2023-01-13 17:47:50 <mcrute> ikke: you mean the binding.node message?
2023-01-13 17:50:09 <elly> psykose: figured it out: https://bugs.chromium.org/p/chromium/issues/detail?id=1407202#c4
2023-01-13 17:50:17 <elly> and de-restricted the bug since it only affects libstdc++ builds
2023-01-13 17:50:29 <elly> in fact this problem is likely responsible for *most* "alpine-specific" crashes
2023-01-13 17:51:05 <ikke> mcrute: yes
2023-01-13 17:51:39 <mcrute> ikke: seems a side effect of running yarn as part of the build process. I do not see that in the upstream repo but I'm taking a pass over the entire repo to see if there are any binaries
2023-01-13 17:51:51 <ikke> alright
2023-01-13 17:55:20 <mcrute> ikke: verified, upstream has no binaries in their repo, also they do not ship a node_modules so this is definitely yarn doing build setup
2023-01-13 17:57:02 <mcrute> although it does look like node-sass ships some binaries in their npm package, though I'm not seeing that one specific one https://www.npmjs.com/package/node-sass?activeTab=explore
2023-01-13 18:57:05 <telmich> Good evening
2023-01-13 18:58:02 <telmich> I was wondering what is the right process for making prometheus blackbox exporter finally available in a release? The 3.17 community repo does not contain, afaics, and thus one has to switch to edge for it
2023-01-13 18:58:51 <ikke> telmich: the next release would have it
2023-01-13 18:59:21 <telmich> perfect, thanks ikke 
2023-01-13 19:00:11 <telmich> (background: i was today building a docker image with wireguard + blackbox exporter to monitor hosts from k8s inside other VPNs and noticed that the blackbox exporter was not available in the default package repositories in 3.17)
2023-01-13 19:01:26 <ikke> I think it got moved to community just after the 3.17 release
2023-01-13 20:00:04 <Ariadne> is it a known issue that busybox sha512sum is failing due to what appears to be a fortify violation on x86_64?
2023-01-13 20:01:28 <ikke> No
2023-01-13 20:01:37 <ikke> bb 1.36?
2023-01-14 02:24:33 <psykose> doesn't fail for me
2023-01-14 02:24:46 <psykose> so i guess it's a specific case and probably also new
2023-01-14 02:25:04 <elly> also doesn't fail for me
2023-01-14 02:25:19 <psykose> elly: that was quite a ride :)
2023-01-14 02:26:25 <elly> haha
2023-01-14 02:26:28 <elly> well, there's a fix now
2023-01-14 02:26:49 <psykose> half tempted to custom libcxx it too :D
2023-01-14 02:27:05 <elly> that would I suspect probably fix some of the other mysterious crashes
2023-01-14 02:27:15 <elly> however, each of those crashes is actually a "real" chromium bug that libcxx happens to avoid
2023-01-14 02:31:17 <psykose> yep
2023-01-14 02:34:53 <mcrute> psykose: hey could you hold off on vault changes? I'm waiting for the armv7 to finish then I have a r3 (well now r4)
2023-01-14 02:35:08 <psykose> i don't have any changes
2023-01-14 02:35:08 <mcrute> but it's been backlogged behind a kernel build all day long
2023-01-14 02:35:15 <psykose> that build is stuck
2023-01-14 02:35:44 <mcrute> this? https://gitlab.alpinelinux.org/alpine/aports/-/commit/a289b2f2a1bf5a358dfea117e55a2c5a0fc2c8b3
2023-01-14 02:36:01 <psykose> yeah
2023-01-14 02:36:28 <mcrute> it's actually not broken on x86 it's just the ui, but armv7 may (or may not) also be broken which is why I was waiting to push the change
2023-01-14 02:36:51 <mcrute> was that build blocking the x86 builder?
2023-01-14 02:37:28 <psykose> it's been failing in a loop for 9 hours
2023-01-14 02:39:12 <mcrute> yeah :-(. I'll push a revision that fixes x86 and continue to wait for armv7... I don't want to completely retract the x86 build :-)
2023-01-14 02:39:48 <psykose> sure, though this is one of those packages that nobody is running on x86 for sure :p
2023-01-14 02:40:30 <mcrute> almost certainly true :-D
2023-01-14 02:41:07 <mcrute> psykose: what's your opinion on me grabbing ownership of that btw? original maintainer seems to have abandoned it
2023-01-14 02:44:39 <psykose> same maintainer is fine with it given the similar hashicorp packages being handed over
2023-01-14 02:44:41 <psykose> go for it :)
2023-01-14 02:45:40 <mcrute> cool, I'll swap myself in then
2023-01-14 06:17:35 <craftyguy> fyi looks like the armv7 edge builder is stuck, has been for quite some time: https://build.alpinelinux.org/
2023-01-14 07:23:32 <ikke> mcrute: at least give the original maintainer a heads-up
2023-01-14 07:24:32 <mcrute> ikke: I've emailed them twice, 7 days ago and then again 3 days ago
2023-01-14 07:24:42 <ikke> ok
2023-01-14 07:26:47 <mcrute> next time I do an update I'll swap myself in... happy to give it back if they show back up and really want it :-)
2023-01-14 08:58:17 <psykose> for those that like testing mesa rc's, there's artifacts in !43183 for convenience
2023-01-14 19:16:14 <omni> anyone else who has lagrange segfault on them?
2023-01-14 19:18:31 <ikke> I've never used it :)
2023-01-14 19:20:07 <Ermine> Hopefully Euler and Kauchi do not segfault
2023-01-14 19:22:27 <psykose> seen at least one report
2023-01-14 19:22:40 <Ermine> s/Kauchi/Cauchy/
2023-01-14 19:22:40 <alpine-meetbot> Ermine meant to say: Hopefully Euler and Cauchy do not segfault
2023-01-14 19:24:01 <psykose> nice meme
2023-01-14 19:28:38 <psykose> read some stuff and it seems to not segfault
2023-01-14 19:31:18 <omni> for me it segfaults when moving the rodent pointer over it
2023-01-14 19:31:45 <psykose> the what
2023-01-14 19:32:41 <omni> the tilted arrow that moves around as you finger the pad, or whatever your device is for moving it about
2023-01-14 19:32:58 <psykose> oh
2023-01-14 19:33:00 <psykose> right yes
2023-01-14 19:33:04 <psykose> uhh yeah works fine for me
2023-01-14 19:33:19 <psykose> time to get some backtraces for ya i guess
2023-01-15 00:42:38 <omni> yeah.. I ran strace with it and saved a log, then I didn't really know what to look for and got distracted
2023-01-15 00:43:15 <omni> I /would/ like to get better at debuggnign
2023-01-15 00:43:37 <omni> (and spellenign?)
2023-01-15 00:48:23 <elly> I have used lagrange before and it does not crash for me - you don't want an strace for a crash though, you want a core dump
2023-01-15 00:48:30 <elly> or to crash it with gdb attached
2023-01-15 00:49:10 <omni> another thing, I looked earlier at https://github.com/qt/qtwebengine-chromium/commit/97a1254923022e66fa75245c3ace64f58112cba6 (the latest commit in the 87-based branch that we use for chromium qt5-qtwebengine)
2023-01-15 00:49:24 <elly> 87!?
2023-01-15 00:49:45 <elly> gosh
2023-01-15 00:50:08 <omni> it contain an upgrade of chromium/third_party/libxml from 2.9.12 to 2.9.13, should CVE-2022-23308 be listed in the APKBUILD then?
2023-01-15 00:50:14 <omni> https://download.gnome.org/sources/libxml2/2.9/libxml2-2.9.13.news
2023-01-15 00:51:06 <omni> and... there are also more recent releases of libxml2, as we have packaged in main, with additional security fixes
2023-01-15 00:51:28 <elly> not to mention all the security fixes in chromiums 88 through 109 :P
2023-01-15 00:53:40 <omni> yes, I cannot say why qt5-qtwebengine is on 87-based, I just try to update it with the security fixes that are backported to the branch
2023-01-15 00:56:35 <omni> elly: I don't mean to ignore you wrt the lagrange debbing comments, I'm just slow
2023-01-15 00:59:01 <elly> no problem
2023-01-15 00:59:20 <elly> if you run lagrange under gdb and it crashes, type 'bt' and pastebin the output somewhere
2023-01-15 01:13:47 <omni> I ran `ulimit -c unlimited` to be able to get a core dump and then `gdb $(which lagrange) -c core`, am I on the right track? =)
2023-01-15 01:21:57 <elly> you can do that if you want
2023-01-15 01:22:00 <omni> https://gitlab.alpinelinux.org/-/snippets/661
2023-01-15 01:22:05 <elly> I would run lagrange in gdb directly
2023-01-15 01:22:37 <elly> you don't have debug symbols for lagrange :(
2023-01-15 01:23:08 <elly> you may need to build it yourself to get them, there doesn't seem to be a -dbg apk
2023-01-15 01:24:09 <omni> right
2023-01-15 01:40:25 <omni> elly: https://gitlab.alpinelinux.org/-/snippets/662
2023-01-15 02:00:38 <omni> https://gitlab.alpinelinux.org/-/snippets/663
2023-01-15 03:13:32 <elly> omni: hm, if you build trunk lagrange do you still get a crash?
2023-01-15 03:13:40 <elly> there have been many recent changes to the involved code
2023-01-15 10:33:48 <psykose> binutils is 2.40 in edge, take note of any breakage
2023-01-15 10:34:02 <psykose> also linux-tools is 6.1 which i think brings some perf goodies
2023-01-15 12:06:14 <omni> elly: https://gitlab.alpinelinux.org/-/snippets/664
2023-01-15 12:06:33 <omni> I'll write about findings to upstream
2023-01-15 12:07:14 <psykose> hmm
2023-01-15 12:07:18 <psykose> wait first
2023-01-15 12:08:07 <psykose> juust out of curiosity
2023-01-15 12:08:16 <psykose> upgrade to libx11 1.8.3 with this on top https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/eb1c272ab5230d548077b9f59aca4b3457c3a8f8
2023-01-15 12:51:32 <omni> before I read this I opened https://github.com/skyjake/lagrange/issues/567
2023-01-15 12:52:13 <omni> I don't think I have time to pursue this right now
2023-01-15 14:35:24 <sam_> libx11 is a mess rn
2023-01-15 14:35:26 <sam_> my hope is 1.8.3 + that commit sorts most of it out
2023-01-15 15:42:48 <psykose> ye
2023-01-15 15:42:54 <psykose> kinda just waiting for 1.8.4 though
2023-01-15 15:43:13 <psykose> ikke: i had missed a few py3.11 rebuilds, see to all be done now except apenwarr-redo that fails tests with new make
2023-01-15 16:02:30 <ikke> what fails?
2023-01-15 16:03:55 <psykose> you can look :) just some jobserver expectation i guess
2023-01-15 17:08:30 <ikke> I see
2023-01-15 17:14:31 <ikke> 2 jobserver related changes in make 4.4
2023-01-15 17:21:46 <ikke> psykose: apprently the new fifo feature has a different syntax
2023-01-15 17:21:57 <psykose> ye
2023-01-15 17:22:12 <ikke> flags='  -j --jobserver-auth=100,101 --jobserver-fds=100,101 '
2023-01-15 17:22:15 <ikke> vs
2023-01-15 17:22:26 <ikke> flags='  -j10 --jobserver-auth=fifo:/tmp/GMfifo37793 '
2023-01-15 17:23:00 <ikke> psykose: do you know if it's possible to disable fifo?
2023-01-15 17:23:30 <psykose> there is but it's testing it
2023-01-15 17:23:39 <psykose> i.e. you want to update to new syntax specifically i guess
2023-01-15 17:24:27 <psykose> --jobserver-style=pipe is old type but the format will still probably be the new one? idk
2023-01-15 17:39:30 <ikke> It's testing make compattibility I suppose, and that's where it fails
2023-01-15 17:40:20 <ikke> as make provides different arguments in MAKEFLAGS
2023-01-15 17:51:01 <ikke> psykose: I suppose we could just skip that test for now
2023-01-15 17:51:11 <ikke> even the test itself says it's not that important :P
2023-01-15 17:51:16 <ikke> # No make installed?  That's okay, this test
2023-01-15 17:51:19 <ikke> # isn't *that* important.
2023-01-15 17:52:14 <psykose> haha
2023-01-15 17:52:19 <psykose> yeah, no issue with me
2023-01-15 17:52:30 <psykose> just the last py311 rebuild so i thought i'd throw you one :p
2023-01-15 17:52:39 <ikke> I'll do that and push the rebuild
2023-01-15 18:03:17 <ikke> done
2023-01-15 18:11:24 <psykose> thanks!
2023-01-15 19:23:21 <mcrute> ikke: is the actual buildserver code open somewhere on gitlab? I can't seem to find it
2023-01-15 19:24:48 <psykose> lua-aports has ap which runs the builds on triggeer
2023-01-15 19:24:58 <ikke> mcrute: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/aports-build
2023-01-15 19:25:20 <ikke> mqtt-exec -> aports-build -> buildrepo
2023-01-15 19:25:34 <ikke> (buildrepo is from lua-aports like psykose mentioned)
2023-01-15 19:25:37 <psykose> another layer hehe
2023-01-15 19:25:53 <mcrute> thanks! I would have never found that
2023-01-15 19:33:11 <mcrute> psykose: I'm probably missing something but I don't see how ap fits in? seems like it would be mostly useful for inspecting the dependency graph
2023-01-15 19:33:16 <psykose> it doesn't
2023-01-15 19:33:30 <psykose> i typod it to buildrepo in my head
2023-01-15 19:33:41 <mcrute> ahh, now it all fits together :-D
2023-01-16 14:37:22 <maribu> Hi :) I'm experiencing segfaults in firefox when scaling the output (e.g. swaymsg output DP-1 scale 2) or moving the firefox window from an output with scale 1 to one with scale 2. Has anyone seen the same behavior?
2023-01-16 14:37:53 <psykose> i don't have multiple displays to test that with
2023-01-16 14:37:57 <psykose> also haven't heard of that before
2023-01-16 14:38:03 <psykose> sounds like a fancy segfault
2023-01-16 14:38:11 <maribu> Furthermore, building firefox with debugging symbols enabled results in interesting compilations errors :/ Has anyone build it recently?
2023-01-16 14:38:42 <maribu> I can also get it crashing with just one screen by enabling scaling on that.
2023-01-16 14:38:50 <psykose> you need like --enable-debug and !strip or something, don't remember
2023-01-16 14:38:51 <psykose> hmm
2023-01-16 14:39:04 <psykose> i just ran that and it didn't crash
2023-01-16 14:39:25 <psykose> but i am using 109 that just came out
2023-01-16 14:39:28 <psykose> so maybe it's just fixed?
2023-01-16 14:40:02 <maribu> That would be awesome :)
2023-01-16 14:41:17 <psykose> hmm, even in 108 it doesn't for me
2023-01-16 14:41:45 <psykose> everything looks so big and sharp in scale 2
2023-01-16 14:41:46 <psykose> fancy
2023-01-16 14:41:52 <maribu> Do you have firefox already running while scaling? If you run in GDB, do you have ASLR re-enabled?
2023-01-16 14:42:10 <psykose> yeah i have it already running
2023-01-16 14:42:11 <psykose> no gdb
2023-01-16 14:42:35 <maribu> Do you have and AMD GPU? Maybe that is one secret ingredient of the crash...
2023-01-16 14:43:08 <psykose> yep, rx6600
2023-01-16 14:43:26 <psykose> but i am using 23.0-rc1 of mesa
2023-01-16 14:43:28 <psykose> even more layers
2023-01-16 14:43:35 <maribu> Regarding sharp on scale 2: Start something in Xwayland. After that the proper scaling of Wayland will look even better when directly compared to the blocky mess of X
2023-01-16 14:43:59 <maribu> OK, I'm still running 22.3.3-r0
2023-01-16 14:44:13 <maribu> (And firefox 108.0.2-r0)
2023-01-16 14:44:32 <psykose> seems to not crash on 22 either
2023-01-16 14:44:33 <psykose> weh
2023-01-16 14:44:38 <psykose> not sure what it could be then
2023-01-16 14:45:47 <maribu> https://gist.github.com/maribu/f5aa3c3dd2c951797ae4513c633d43b9 is the backtrace, btw
2023-01-16 14:46:59 <psykose> yeah most of them look like that
2023-01-16 14:47:01 <psykose> something in libxul
2023-01-16 16:03:08 <hjaekel> Does anyone have time to review merge request !42943? I would really appreciate that.
2023-01-16 16:05:22 <psykose> should probably have an soname
2023-01-16 16:06:51 <hjaekel> OK, I will update the MR
2023-01-16 16:07:27 <hjaekel> and thank you for the quick review psykose 
2023-01-16 16:08:18 <psykose> i forgot to mention it when i saw it a week ago
2023-01-16 16:08:22 <psykose> if anything that's a slow review
2023-01-16 16:08:23 <psykose> :p
2023-01-16 16:21:53 <elly> psykose: I am not sure my busybox bug report is going to be acted on
2023-01-16 16:22:52 <psykose> idk how that bug tracker works
2023-01-16 16:23:09 <psykose> most things i see is via the ML so i assume it's a bit of a dual system
2023-01-16 16:23:53 <psykose> i would guess more people see the ML (given the ping and all)
2023-01-16 16:23:55 <elly> are you already a poster on the ML?
2023-01-16 16:24:10 <elly> busybox.net seems to just be down anyway
2023-01-16 16:24:13 <elly> rip
2023-01-16 16:24:18 <psykose> yeah seems to be down
2023-01-16 16:24:20 <psykose> i never post anything
2023-01-16 16:24:22 <psykose> just subscribed
2023-01-16 16:24:40 <psykose> me?? posting??
2023-01-16 16:24:46 <elly> someone has to
2023-01-16 16:24:54 <psykose> :)
2023-01-16 16:25:04 <psykose> two kinds of people in the world, those who post,
2023-01-16 16:25:23 <elly> and those who think about posting but are too nervous to hit send?
2023-01-16 16:25:34 <psykose> stop calling me out like this smh
2023-01-16 16:33:30 <skarnet> elly: I never look at the bb bug tracker, but if the modus operandi is the same as the ML's, vda scans everything once every 2-3 months and applies a lot of stuff :)
2023-01-16 16:33:40 <elly> haha okay
2023-01-16 16:33:42 <skarnet> so, it's probably going to be applied, but, be patient
2023-01-16 16:34:04 <psykose> it's not a patch but a report
2023-01-16 16:34:08 <skarnet> however, maybe it's only the ML and the bug tracker is 100% ignored, idk
2023-01-16 16:34:20 <psykose> in any case you would probably have fun fixing it
2023-01-16 16:35:35 <skarnet> with reports, vda sometimes suggests fixes (if it's easy), or once in a blue moon someone else steps in and submits a patch, but if it's too hard it basically gets ignored
2023-01-16 16:35:59 <psykose> p much
2023-01-16 16:36:13 <psykose> maybe skarnet would even fix it :p
2023-01-16 16:36:27 <psykose> i am sure skarnet loves terminals right
2023-01-16 16:36:29 <skarnet> I wouldn't know, I haven't read the bug and the site is down :P
2023-01-16 16:36:29 <elly> I'm not too bothered about how long it takes really but I'm a little surprised it hasn't been acked
2023-01-16 16:36:52 <psykose> skarnet: bb 1.36 open ash in a terminal, send sigwinch to it, it newlines :P
2023-01-16 16:36:55 <psykose> there you go, entire report
2023-01-16 16:37:12 <elly> I *could* figure it out how to fix it probably, I think I know the commit that introduced it
2023-01-16 16:37:24 <elly> but I am not sure how I would develop confidence that I hadn't regressed something else
2023-01-16 16:37:28 <skarnet> yeah I'm totally going to dive into shell terminal code, that's what I love to do before breakfast
2023-01-16 16:37:30 <elly> busybox's code is not very easy to understand
2023-01-16 16:37:43 <psykose> exactly, it's your favorite
2023-01-16 16:37:51 <psykose> it's basically jumping from pre-breakfast to dessert
2023-01-16 16:37:54 <elly> what if *you* fixed it psykose
2023-01-16 16:38:01 <psykose> i can't write code
2023-01-16 16:38:05 <elly> yet
2023-01-16 16:38:06 <elly> get in there
2023-01-16 16:38:11 <psykose> tsk
2023-01-16 16:38:28 <skarnet> elly: well we're complementary here because I don't have too much trouble with the bb code in general, it's just I don't like shell and terminals, so if you work on a fix I can probably proofread it
2023-01-16 16:38:48 <elly> skarnet: ugh maybe
2023-01-16 16:38:54 <psykose> anime power duo
2023-01-16 16:38:54 <elly> I don't really want to touch it :P
2023-01-16 16:38:58 <skarnet> don't show too much enthusiasm
2023-01-16 16:39:04 <elly> haha
2023-01-16 16:39:18 <elly> I already have a long queue of Stuff To Fix and I am hesitant to add more things to it!
2023-01-16 16:39:30 <skarnet> welcome to my world
2023-01-16 16:39:39 <psykose> the queue stops existing if the new things go to front of queue
2023-01-16 16:39:44 <psykose> taps forehead
2023-01-16 16:39:54 <elly> that is not how it works I'm afraid
2023-01-16 16:39:57 <skarnet> a long fifo of Stuff To Fix
2023-01-16 16:40:07 <psykose> lifo you mean
2023-01-16 16:40:09 <skarnet> turning into a lifo
2023-01-16 16:40:10 <skarnet> yeah
2023-01-16 16:40:14 <elly> most of the items in my Stuff To Fix queue are my actual paid job so they get to be at the front :P
2023-01-16 16:40:34 <psykose> 6 month busybox sabbatical time
2023-01-16 16:40:54 <skarnet> my actual paid job is Stuff To Write and I haven't been doing a very good job >.>
2023-01-16 16:41:09 <elly> oh no
2023-01-16 16:41:16 <psykose> the offer is still open you know
2023-01-16 16:41:17 <psykose> smh
2023-01-16 16:41:27 <skarnet> psykose: will definitely take you up on it this year
2023-01-16 16:41:31 <psykose> :)
2023-01-16 16:42:50 <skarnet> it's looking better now that the new year release is done, now I just have to get out the Big Web Thing and then we're on
2023-01-16 16:43:18 <psykose> aye aye
2023-01-16 16:43:41 <psykose> i've slacked on getting some s6 fundamentals down on my laptop too
2023-01-16 16:43:46 <psykose> maybe i should get that sorted
2023-01-16 16:43:59 <skarnet> take your time
2023-01-16 17:06:45 <WhyNotHugo_> maribu: Is it maybe this https://bugzilla.mozilla.org/show_bug.cgi?id=1795851 ?
2023-01-16 17:07:59 <psykose> if it's that it's fixed in 109
2023-01-16 17:09:02 <psykose> ah i see you have typed an essay in there
2023-01-16 17:09:17 <WhyNotHugo_> Merely trying to explain the issue.
2023-01-16 17:09:23 <psykose> yeah
2023-01-16 17:09:25 <psykose> well written
2023-01-16 17:09:26 <psykose> thanks
2023-01-16 17:09:57 <psykose> 109 is available now and built so test again i suppose
2023-01-16 17:15:12 <maribu> Yep! It fixed also an issue with xdp-desktop-portal-wlr screen sharing :)
2023-01-16 17:16:00 <psykose> o
2023-01-16 17:16:24 <psykose> wait it dxid
2023-01-16 17:16:27 <psykose> it works again
2023-01-16 17:16:56 <psykose> chromium is still broken but eh
2023-01-16 17:17:13 <elly> under wayland?
2023-01-16 17:17:22 <elly> is there a filed bug?
2023-01-16 17:18:43 <psykose> something something me filing bugs
2023-01-16 17:18:51 <psykose> yeah it broke some time ago but i filed it under pipewire issues
2023-01-16 17:18:51 <elly> like an alpine one I mean
2023-01-16 17:18:59 <psykose> uhh two dupes without any real info
2023-01-16 17:19:02 <psykose> basically just
2023-01-16 17:19:05 <psykose> go to meet.jit.si
2023-01-16 17:19:10 <psykose> create a call with yourself
2023-01-16 17:19:11 <psykose> try share screen
2023-01-16 17:19:12 <psykose> i guess
2023-01-16 17:19:13 <elly> hm okay, can you point me at it? chromium is supposed to at least sort of work under wayland
2023-01-16 17:19:30 <elly> oh, wait, do you specifically mean when screen sharing?
2023-01-16 17:19:37 <elly> if so I think I know about this already
2023-01-16 17:19:43 <psykose> #14422 #14421
2023-01-16 17:19:47 <psykose> yeah it's screensharing only
2023-01-16 17:20:08 <psykose> these things are really fragile
2023-01-16 17:20:11 <elly> the wayland folks sent us a proposal for how to change the screensharing flow in wayland to fix some deficiencies but we rejected it because it makes the UI significantly worse for even non-wayland users
2023-01-16 17:20:19 <elly> and the whole bug is basically just idle right now
2023-01-16 17:20:28 <psykose> touching basically anything in portals/pipewire/wireplumber/browser upgrades break it all the time
2023-01-16 17:20:34 <elly> yes
2023-01-16 17:20:42 <psykose> nice to see firefox works again i guess
2023-01-16 17:20:47 <psykose> what sucks is it's never one place
2023-01-16 17:20:52 <elly> I don't want to even try to fix the pipewire thing tbh
2023-01-16 17:21:11 <psykose> i'd understand if i.e. the web browser broke all the time, since at least it would be consistent and would point to a solid implementation elsewhere
2023-01-16 17:21:16 <psykose> but it's literally every component
2023-01-16 17:22:37 <elly> ya, I don't want to work on it because a) I don't understand wayland and b) even if I did I would have low confidence that I had not broken something else or some other version of it
2023-01-16 17:23:58 <psykose> it'll come with time
2023-01-16 17:24:32 <psykose> the enzoomerification of elly
2023-01-16 17:25:02 <elly> https://crbug.com/1281200 is a related upstream bug
2023-01-16 17:26:49 <psykose> aye
2023-01-16 17:33:40 <elly> tbh I don't understand X either but it tends to change less
2023-01-16 17:35:33 <psykose> wayland (working) -> wayland (broken) -> wayland (working)
2023-01-16 17:35:45 <psykose> X (broken) -> X (broken) -> X (broken)
2023-01-16 17:35:52 <psykose> agree /s
2023-01-16 17:36:43 <nmeum> is the maintainer assignment feature of algibot broken?
2023-01-16 17:37:01 <nmeum> somehow I wasn't auto-assigned to some MRs for package I maintain
2023-01-16 17:39:30 <psykose> does your email match
2023-01-16 17:39:40 <psykose> it does work generall
2023-01-16 17:39:41 <psykose> y
2023-01-16 17:40:10 <psykose> maybe it's a regression with multiple emails
2023-01-16 17:41:15 <nmeum> hmhm
2023-01-16 18:16:01 <ikke> nmeum: example MRs?
2023-01-16 18:16:19 <psykose> !42994
2023-01-16 18:19:35 <ikke> error="no users found with email address \"soeren@soeren-tempel.net\""
2023-01-16 18:20:19 <psykose> it chokes on the +?
2023-01-16 18:20:42 <psykose> :)
2023-01-16 18:20:54 <psykose> that explains a lot of them i've seen not assigned
2023-01-16 18:21:11 <ikke> I suppose it should fall back to checking it with the label
2023-01-16 18:21:21 <psykose> idk why it would do any fallbacks
2023-01-16 18:21:29 <psykose> just check it verbatim as written
2023-01-16 18:23:57 <ikke> https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/15
2023-01-16 18:25:31 <ikke> The commit that adds it has no motivation sadly
2023-01-16 18:26:11 <psykose> just remove it i guess
2023-01-16 18:26:28 <ikke> Why not try both?
2023-01-16 18:26:38 <ikke> I guess there was a reason Leo added it
2023-01-16 18:26:46 <psykose> i have no idea what the point would be
2023-01-16 18:26:49 <psykose> they're transparent
2023-01-16 18:27:04 <psykose> i.e. people signup with x+y addresses, have x+y in primary, ..
2023-01-16 18:27:22 <psykose> what is the point of removing the +y? it doesn't let you do anything you couldn't have with the full address
2023-01-16 18:27:43 <psykose> the only thing i can think of that it allows is uh
2023-01-16 18:27:44 <ikke> match users with different +tags in the maintainer field and their gitlab user
2023-01-16 18:27:44 <nmeum> ok, but if I just add soeren@soeren-tempel.net to my gitlab account then it will work?
2023-01-16 18:27:50 <psykose> someone has x@addr but x+y@ in email field
2023-01-16 18:27:57 <ikke> or visa-versa
2023-01-16 18:28:03 <psykose> in which case they should just.. not? idk
2023-01-16 18:28:05 <psykose> that is their own issue
2023-01-16 18:28:20 <psykose> as long as this checks more than one email on the account it's fine
2023-01-16 18:29:16 <nmeum> I just went ahead and also added the other mail to my account
2023-01-16 18:29:33 <nmeum> though it worked with the mail address containing the + in the past
2023-01-16 18:29:34 <ikke> It queries directly for an account with the specific e-mail address
2023-01-16 18:30:00 <ikke> nmeum: I deployed a new aports-qa-bot with quite some changes that were not deployed yet
2023-01-16 18:30:08 <ikke> that MR is one of them
2023-01-16 18:30:10 <nmeum> ah, thanks!
2023-01-16 21:07:35 <ikke> psykose: ah, you already opened an issue
2023-01-16 21:07:57 <ikke> I was just looking for open issues
2023-01-16 21:08:28 <psykose> :)
2023-01-16 21:09:46 <ikke> fixing it would I suppose require an API change to AsUint16
2023-01-16 21:12:47 <psykose> nah, the function is fine
2023-01-16 21:13:24 <psykose> the test doesn't have to pass uint32 max, could just be int32max and it's the same test and then passes
2023-01-16 21:13:59 <psykose> or it can pass uint16max + 1
2023-01-16 21:16:36 <ikke> right, as it expects an int, you would not pass a int64 I suppose
2023-01-16 21:24:36 <ikke> thanks
2023-01-16 21:27:59 <psykose> :)
2023-01-17 00:34:47 <elly> the state of readdir(3) / fts(3) / ftw(3) / etc is quite frustrating
2023-01-17 00:35:19 <elly> readdir(3) is close to useful... but the directory type values are behind _BSD_SOURCE
2023-01-17 00:35:54 <elly> fts(3) is 4.4bsd, not present in musl at all
2023-01-17 00:36:15 <psykose> fts is in musl-fts for a standalone version
2023-01-17 00:36:22 <psykose> _BSD_SOURCE is easy to define
2023-01-17 00:36:32 <elly> ftw(3) is deprecated and has a pretty bad API (imo), and in particular no way to pass state into the callback function
2023-01-17 00:36:41 <elly> yeah, I know I *can* define _BSD_SOURCE, it's just the principle of the thing that irritates me
2023-01-17 00:37:05 <elly> it should be possible, in pure POSIX C, to traverse a directory tree usefully :P
2023-01-17 00:37:38 <psykose> askin for a dream there
2023-01-17 00:38:04 <lotheac> there are so many things that aren't in posix, i wouldn't hold my breath
2023-01-17 00:38:12 <lotheac> standars by committee don't exactly evolve quickly
2023-01-17 00:38:24 <elly> my breath is not being held
2023-01-17 00:38:31 <elly> in practice I will define _BSD_SOURCE and move on with my life
2023-01-17 00:38:32 <elly> but still :P
2023-01-17 00:39:21 <psykose> -D_THE_YEAR_IS_2023
2023-01-17 00:39:26 <psykose> new api just dropped
2023-01-17 00:39:36 <lotheac> i think i've seen some people open bugs at https://www.austingroupbugs.net/ -- if you really really wanted to have stuff in posix, i guess you could try to make it happen :p
2023-01-17 00:39:44 <elly> gets(3) now super mega ultra deprecated absolutely do not use ever
2023-01-17 00:41:39 <psykose> musl doesn't even implement it 
2023-01-17 00:41:52 <psykose> oh, or does it
2023-01-17 00:42:06 <psykose> noooo
2023-01-17 00:42:07 <psykose> it does
2023-01-17 00:42:36 <psykose> if i was making a new distro i would delete that for sure
2023-01-17 00:43:13 <psykose> is there like any way to call gets without immediately breaking your program
2023-01-17 00:43:32 <elly> sure, just don't type too many letters :P
2023-01-17 00:43:45 <psykose> ^_^
2023-01-17 00:50:56 <skarnet> elly: what are you talking about, readdir(3) is as posix as it gets. https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
2023-01-17 00:51:02 <skarnet> no guarding macro or anything.
2023-01-17 00:51:33 <skarnet> fts, ftw and friends are indeed terrible though
2023-01-17 00:51:35 <psykose> it only defines 3 errors though
2023-01-17 00:51:40 <psykose> not webscale
2023-01-17 00:51:57 <skarnet> wait what
2023-01-17 00:53:06 <psykose> (shitepost)
2023-01-17 00:53:22 <skarnet> and yes if you want to know the type of the entry you need to stat() it
2023-01-17 00:53:53 <psykose> what if we added a new linux syscall to get it in one
2023-01-17 00:54:15 <skarnet> you could, but it wouldn't be worth the effort
2023-01-17 00:54:38 <skarnet> in-kernel you'd still need to access both the dnode and the inode
2023-01-17 00:54:49 <psykose> it would speed up my webscale dir reading in one context switch
2023-01-17 00:55:28 <skarnet> I have some ideas about what you can do with your webscale dir reading in one context switch but I'm not sure you'd like them
2023-01-17 00:57:07 <psykose> but i can't afford a mips cpu which means i can only do kips and my distributed routers need to be fast so i can sell my customers a functional directory scanning application so it has to be fast
2023-01-17 01:03:01 <elly> skarnet: readdir(3) is posix... but the DT_* constants you need to tell what type the results are aren't :(
2023-01-17 01:03:19 <elly> I could call stat(2) for each one, it's true
2023-01-17 01:03:26 <elly> it does seem wasteful given that the info is already there
2023-01-17 01:06:51 <lotheac> it's not just the constants, posix does not require struct dirent to contain d_type at all
2023-01-17 01:07:29 <lotheac> looks like it just requires d_ino and d_name :)
2023-01-17 01:09:37 <elly> 
ACTION . o O strchr(basename(de->d_name), '.')

2023-01-17 01:09:40 <elly> horrible idea
2023-01-17 01:13:12 <lotheac> urgh i got solaris ptsd, i knew i struggled with this before -- seems like illumos _didn't even have d_type in 2018_ https://twitter.com/thatcks/status/1032709984168103936
2023-01-17 01:16:38 <lotheac> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/dirent.h#L44-L49 oh hey it still doesn't :-) so if you wanna be "portable" you have to handle that case and be prepared to stat everything
2023-01-17 01:17:39 <skarnet> elly is a premature optimizator :P
2023-01-17 01:18:40 <lotheac> nah, their position does make sense, if the system is already returning the information it makes sense to not have to stat()
2023-01-17 01:19:19 <lotheac> it's also dumb to unconditionally stat() everything if you don't have to, just because some handwaving about portability to systems nobody cares about :p
2023-01-17 01:19:35 <skarnet> ah yes, call me nobody again
2023-01-17 01:19:44 <skarnet> and dumb, too, I love it
2023-01-17 01:20:21 <lotheac> i apologize for my tone, but it's your choice to interpret what i said that way. i am not calling you anything
2023-01-17 01:20:30 <skarnet> I know ;)
2023-01-17 01:21:14 <skarnet> my point is that portability is important, and respecting standards as well, and you *are* supposed to stat everything, and in 90% of the cases it won't make a noticeable difference in speed
2023-01-17 01:22:48 <lotheac> i used to hold the same view, but i've changed my mind. portability is not a virtue in and of itself, especially not if you do it in a way that forces you to only use features available as the lowest common denominator
2023-01-17 01:23:06 <lotheac> just because posix is terrible doesn't mean all applications have to be
2023-01-17 01:23:32 <skarnet> what's even more terrible than posix is software made of a forest of #ifdefs
2023-01-17 01:23:42 <lotheac> those are not the only two options, you know
2023-01-17 01:25:19 <lotheac> if all systems you as an application developer care about support a feature you want to use, there is very little reason to not be selfish. if someone wants to run it on a system that doesn't, patches accepted
2023-01-17 01:27:11 <lotheac> but i get there are differing views on this subject (:
2023-01-17 01:28:42 <skarnet> you know just as well as I do that it's more complicated than that - when designs map from one OS to the next, sure, it's easy. When designs are removed from one another, it's another story.
2023-01-17 01:36:38 <lotheac> sure. i'm just trying to say that i completely understand choosing features over programming to only what standards specify.
2023-01-17 01:37:00 <lotheac> frankly, i make that tradeoff myself gladly these days
2023-01-17 10:43:40 <chereskata> hey there
2023-01-17 10:44:31 <chereskata> for a few days now i notice a strange thing: my kgx (ash) prompt is double when launching a new kgx process
2023-01-17 10:44:49 <chereskata> (like someone hit Enter once)
2023-01-17 10:45:40 <chereskata> removing .profile and .ashrc did not change a thing
2023-01-17 10:55:43 <psykose> yeah it's a busybox 1.36 bug
2023-01-17 10:59:06 <chereskata> thank you!
2023-01-17 11:05:06 <chereskata> after installing kvm related packages as per wiki, this happened: * If you use KVM for hardware-assisted virtualization, then you may
2023-01-17 11:05:08 <chereskata>  also need
2023-01-17 11:05:10 <chereskata> -ash: *: not found
2023-01-17 11:05:23 <chereskata> after apk finished its work
2023-01-17 11:06:11 <chereskata> so after apk finished an output string is used as command
2023-01-17 11:07:41 <psykose> can't reproduce
2023-01-17 11:18:29 <chereskata> thanks for trying
2023-01-17 11:23:10 <chereskata> noticed that installing kvm as per wiki pulls in iptables: https://paste.gnome.org/ma0ycDW8x
2023-01-17 11:24:23 <chereskata> i have used kvm with nftables without problems
2023-01-17 11:24:57 <chereskata> is there a possibility to remove the hard dependency on it?
2023-01-17 11:25:39 <ikke> what package
2023-01-17 11:25:43 <ikke> pulls it in
2023-01-17 11:26:08 <chereskata> have to check
2023-01-17 11:26:11 <chereskata> 1m
2023-01-17 11:26:30 <chereskata> libvirt-daemon
2023-01-17 11:29:04 <ikke> No, not without rebuilding the package to remove it
2023-01-17 11:30:25 <ikke> commit message says that ip(6)tables is needed
2023-01-17 11:30:40 <chereskata> interesting
2023-01-17 11:30:49 <ikke> but that was 7 years ago
2023-01-17 11:31:28 <ikke> Do you think it's no longer required?
2023-01-17 11:32:51 <chereskata> for me personally no. I use nftables. Even if the firewall rule generator uses iptables syntax (doubt it, but unsure), iptables-nft could be used instead
2023-01-17 11:41:49 <chereskata> as per wiki i need the unprivileged user to be in the libvirt group
2023-01-17 11:42:12 <chereskata> but qemu post-install recommends putting the user in qemu and kvm groups
2023-01-17 11:42:42 <chereskata> is this information in post-install old, or for a different usecase?
2023-01-17 11:42:46 <chereskata> https://paste.gnome.org/93IUP3Z8D
2023-01-17 15:10:16 <fabled> ncopa: I'm thinking of tagging and pushing new apk-tools 2.12.x stable release. Maybe you want to review the changes in the branch first? Especially https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/22cc01645d93b6cf97e8d154f04c7ce3c5d74597 is potentially an issue? The other fixes should be more safe.
2023-01-17 15:17:30 <ncopa> hi! i'll have a look
2023-01-17 15:28:11 <ncopa> fabled: while I have you here. `apk version --update` does not seem to update the index
2023-01-17 15:33:02 <fabled> ncopa: i think --update-cache works only when using command that opens database in write mode
2023-01-17 15:36:34 <fabled> somehwat also same issue why --update does not work with --simulate
2023-01-17 15:39:58 <ncopa> i wonder if apk version should open it in write mode when --update-cache was specified. its kinda convenient to do: `apk version --update-cache` instead of  `apk update && apk version`
2023-01-17 15:40:32 <ncopa> i think this is a bit stupid request https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10848
2023-01-17 15:41:30 <ncopa> they should fix the linter imho instead of adding workarounds in apk-tools
2023-01-17 15:41:39 <ncopa> but the workaround does not hurt i suppose
2023-01-17 15:41:54 <fabled> ignoring empty strings might be useful in other use cases too
2023-01-17 15:42:07 <ncopa> for example?
2023-01-17 15:43:23 <fabled> well, all the examples i can think of involve stupid linter/shellcheck
2023-01-17 15:43:40 <ncopa> im thinking of catching typos: `PACKAGE=foo;  apk add "$PAKCAGE"`
2023-01-17 15:44:02 <ncopa> but otoh, i think its unusual to apk add "$PACKAGE"
2023-01-17 15:44:03 <fabled> add "$PACKAGE" when PACKAGE is set optionally is one thing
2023-01-17 15:44:42 <ncopa> its usually more than a single package, so its almost always `apk add $PACKAGES`
2023-01-17 15:44:47 <ncopa> anyway
2023-01-17 15:44:58 <ncopa> feature is already implemented
2023-01-17 15:45:29 <fabled> hope it didn't break anything ;)
2023-01-17 15:46:41 <fabled> re: --update forcing open in write-mode as it is now is not a good idea. because it'll write databases etc... but adding some sort of open cache in write-mode would probably ok
2023-01-17 15:49:12 <fabled> though, "apk version" works as regular user. doing "apk version --update-cache" needing write-access requires to be run as root on normal systems
2023-01-17 15:50:00 <fabled> perhaps making it work with 'version' is sensible
2023-01-17 15:50:32 <fabled> but allowing --simulate --update to work is a can of worms, because --update has potentially state alterting side effects.
2023-01-17 15:51:16 <ncopa> right
2023-01-17 15:51:26 <ncopa> the changes looks ok to me
2023-01-17 15:52:16 <ncopa> but i wonder if we should do 2.13.0 instead of 2.12.11 due to change in behavior
2023-01-17 15:52:34 <ncopa> solver behavior
2023-01-17 15:55:12 <ncopa> maybe we can do a -rc1 release at least?
2023-01-17 15:55:15 <fabled> i'd consider solver issues as bugfixes
2023-01-17 15:55:17 <ncopa> so we can test it in edge
2023-01-17 15:55:22 <ncopa> ok
2023-01-17 15:55:49 <fabled> but the fail-if-url-fails-to-update-or-load change is somewhat more behaviour change and could warrant a bigger bump
2023-01-17 15:56:14 <fabled> i'm planning to add one or two applets for 2.12.x in near future too
2023-01-17 15:56:34 <fabled> to help repository mirroring
2023-01-17 15:58:18 <fabled> reminds me... i'm hoping to add applet that dumps the package names from given index. i can then add support for the aports-lua code to use that listing to see which packages need rebuild. eventually allowing builder to use http repository as the old incremental copy; and having a sepate upload hook; instead of requiring packages on filesystem
2023-01-17 15:59:23 <ncopa> oh... yeah! thats a great idea
2023-01-17 16:18:47 <Ariadne> ping re: sha256sum failing sporadically in alpine edge
2023-01-17 16:19:23 <psykose> do you have a reproduction for it
2023-01-17 16:19:59 <Ariadne> any invocation of sha256sum has a 1 in 16 chance of failure
2023-01-17 16:20:57 <Newbyte> on what architecture?
2023-01-17 16:22:05 <psykose> i just sha256sum'd a few hundred files and got 0 failures
2023-01-17 16:25:04 <psykose> few thousand things from distfiles don't fail either
2023-01-17 16:25:05 <psykose> hmm
2023-01-17 16:25:55 <psykose> are you sure it doesn't depend on the input
2023-01-17 16:28:05 <ncopa> Ariadne: i think busybox changed to assembly optimized shasum recently
2023-01-17 16:28:12 <ncopa> i bet its the assembly code that does it
2023-01-17 16:28:36 <ncopa> is it x86_64?
2023-01-17 16:28:39 <Ariadne> yes
2023-01-17 16:29:09 <ncopa> does same file fail 1 of 16?
2023-01-17 16:29:23 <Ariadne> psykose: yes, i am sure.  for example, if you build the gnu-hello example in melange, which uses alpine edge, it will fail 1 in 16 times with "illegal instruction"
2023-01-17 16:29:56 <ncopa> if you re-run sha256sum on same file?
2023-01-17 16:30:24 <Ariadne> yes
2023-01-17 16:30:33 <ncopa> sounds bad
2023-01-17 16:30:54 <elly> Ariadne: can you get it to happen in a debugger?
2023-01-17 16:32:35 <ncopa> i bet it is the assembly stuff that they introduced
2023-01-17 16:32:42 <Ariadne> i mean, i already know the issue, it is the assembly stuff
2023-01-17 16:32:50 <Ariadne> i just do not wish to do an NMU to rip it out :)
2023-01-17 16:33:27 <ncopa> would be good to have a reliable reproducible test case
2023-01-17 16:33:31 <ncopa> so we can report it upstream
2023-01-17 16:35:44 <elly> hm, I can't get it to happen with busybox master on my x86-64 machine either
2023-01-17 16:36:59 <psykose> i've ran this melange build example like 30 times now and still can't get it to fail
2023-01-17 16:37:23 <elly> Ariadne could you post the binary you are hashing somewhere so we can see if our sha256sum crashes on it?
2023-01-17 16:37:52 <psykose> https://ftp.gnu.org/gnu/hello/hello-2.12.tar.gz
2023-01-17 16:37:59 <psykose> expected-sha256:·cf04af86dc085268c5f4470fbae49b18afbc221b78096aab842d934a76bad0ab
2023-01-17 16:38:04 <Ariadne> psykose: fails reliably on github actions.  might be related to CPU features available
2023-01-17 16:40:21 <psykose> yeah, sounds like it
2023-01-17 16:40:39 <psykose> documented as "if possible", so either the fallback to no-sha is broken or some specific scenario crashes even when it is
2023-01-17 16:41:02 <elly> well
2023-01-17 16:41:25 <elly> the intel documentation for shaNI says to check (ebx >> 29) & 1
2023-01-17 16:41:35 <elly> busybox's code actually checks: ((ebx >> 29) << 1) - 1
2023-01-17 16:41:45 <psykose> nice
2023-01-17 16:41:51 <elly> which is a bit puzzling
2023-01-17 16:42:22 <elly> since I think (?) it will falsely detect shaNI on CPUs that have AVX-512
2023-01-17 16:43:05 <elly> someone who has this crash, does /proc/cpuinfo list avx512bw but not sha_ni for flags?
2023-01-17 16:43:16 <psykose> wish these gha logs said what the machine cpu is
2023-01-17 16:43:24 <Ariadne> that makes a lot of sense.
2023-01-17 16:43:51 <Ariadne> unfortunately, i now have Astound Broadband, which does not have a full routing table, and so I cannot reach git.busybox.net :))))
2023-01-17 16:43:59 <elly> no, git.busybox.net is just down
2023-01-17 16:44:03 <elly> unreachable from here also
2023-01-17 16:44:21 <psykose> yeah the whole site is down :)
2023-01-17 16:44:29 <psykose> but the gh mirror for it works of course
2023-01-17 16:44:31 <Ariadne> oh ok :)
2023-01-17 16:44:42 <Ariadne> well, due to my crappy ISP, i just assume it is my crappy ISP anymore :D
2023-01-17 16:44:50 <elly> I think the smart play is for alpine to turn off this hwaccel or to fix the detection logic for shaNI
2023-01-17 16:44:53 <ncopa> i cannot reproduce it on my i9
2023-01-17 16:45:05 <psykose> know that feeling
2023-01-17 16:45:14 <psykose> think one of us needs to start a qemu with shani disabled
2023-01-17 16:45:20 <ncopa> aha
2023-01-17 16:45:20 <elly> ncopa can you check for avx512bw but not sha_ni in cpuinfo?
2023-01-17 16:45:52 <ncopa>  grep sha_ni /proc/cpuinfo
2023-01-17 16:45:54 <ncopa> empty
2023-01-17 16:46:23 <ncopa> grep avx512bw /proc/cpuinfo
2023-01-17 16:46:26 <ncopa> also empty?
2023-01-17 16:46:38 <elly> avx512vl?
2023-01-17 16:46:56 <elly> if my reading is right, the bug should trigger when: !sha_ni && (avx512bw || avx512vl)
2023-01-17 16:47:22 <ncopa> i have only avx and avx2
2023-01-17 16:47:46 <elly> yeah, then it won't try to use the hwaccel
2023-01-17 16:48:13 <elly> is there a bug filed somewhere? I know the busybox tracker is dead
2023-01-17 16:48:21 <psykose> don't think so
2023-01-17 16:48:24 <psykose> this is quite a rare combo
2023-01-17 16:48:33 <psykose> i'm surprised gha runner would have avx512 at all
2023-01-17 16:48:42 <elly> apparently not rare if you are Ariadne or github
2023-01-17 16:48:56 <elly> I somewhat wonder if they are returning a bogus cpuid on gha and confusing busybox
2023-01-17 16:49:10 <Ariadne> well, i only see the problem on gha :)
2023-01-17 16:49:14 <elly> oh okay
2023-01-17 16:49:23 <Ariadne> all of my development anymore is done on arm
2023-01-17 16:49:28 <elly> gotcha
2023-01-17 16:51:02 <ncopa> https://github.com/ncopa/lddtree/actions/runs/3941433634/jobs/6743832949#step:4:38
2023-01-17 16:51:12 <ncopa> i had a test workflow handy
2023-01-17 16:51:46 <elly> I'm curious for the result, but not signed into github
2023-01-17 16:51:54 <psykose> wow
2023-01-17 16:52:08 <psykose> actual avx512bw+cd+vl
2023-01-17 16:52:10 <psykose> but no sha_ni
2023-01-17 16:52:11 <ncopa> lots of avx512 stuff
2023-01-17 16:52:15 <ncopa> but no sha_ni
2023-01-17 16:52:19 <elly> how fun
2023-01-17 16:53:04 <ncopa> so i think elly is right, and should be crowned
2023-01-17 16:53:47 <psykose> i disabled them
2023-01-17 16:53:57 <psykose> someone can follow up on the mailing list
2023-01-17 16:53:59 <Ariadne> https://ark.intel.com/content/www/us/en/ark/products/192482/intel-xeon-platinum-8270-processor-35-75m-cache-2-70-ghz.html
2023-01-17 16:54:09 <Ariadne> yeah no sha-ni
2023-01-17 16:54:17 <psykose> ah i see the play
2023-01-17 16:54:32 <psykose> they intentionally didn't implement sha-ni so people would implement sha with avx512 on their platform
2023-01-17 16:54:35 <psykose> genius intel once again
2023-01-17 16:54:59 <psykose> Ariadne: should be fine in a moment on -r1 :)
2023-01-17 16:56:07 <elly> I'm a little bit boggled that busybox wrote the test in a more complicated, slower way that is also wrong
2023-01-17 16:56:23 <ncopa> lol
2023-01-17 16:58:39 <elly> friendship ended with busybox, now toybox is my best friend
2023-01-17 16:59:44 <ncopa> i suppose this is the fix? https://tpaste.us/lVxw
2023-01-17 17:00:28 <psykose> probably
2023-01-17 17:00:30 <elly> I would guess that fixes it
2023-01-17 17:00:36 <psykose> gotta test it on that same gh action you just did
2023-01-17 17:00:44 <psykose> sha256sum fail it, apply that, try again
2023-01-17 17:00:47 <elly> don't have the hardware to test or understand why it was written that way in the first place though so I'd be hesitatnt to just commit it
2023-01-17 17:01:02 <psykose> qemu doesn't have avx512 either so i can't test it
2023-01-17 17:04:49 <psykose> nmeum: ah and a ping for all of the above ^ :)
2023-01-17 17:20:50 <skarnet> elly: indeed toybox will likely get these sorts of tests right, it has other problems though ^^'
2023-01-17 17:23:10 <elly> what are they? I've never actually used toybox, I just know it exists
2023-01-17 17:24:58 <sam_> psykose: you can use intel SDE
2023-01-17 17:25:13 <sam_> it's slow as hell but useful for this sort of thing
2023-01-17 17:26:09 <skarnet> toybox's good and bad sides all stem from its author, landley. He pays attention to portability across arches and cpu, so it's likely that hwaccel, if any, is used right. On the other hand, let's say that his conception of well-engineered code is personal and not shared by many people.
2023-01-17 17:26:19 <skarnet> (but then again you could say the same of me, so, eh.)
2023-01-17 17:26:59 <psykose> sam_: this looks closed source
2023-01-17 17:27:08 <sam_> it is, it's intel
2023-01-17 17:27:31 <psykose> how would i run it smh
2023-01-17 17:27:54 <skarnet> very carefully
2023-01-17 17:37:45 <elly> skarnet: or indeed of busybox sometimes
2023-01-17 17:41:15 <skarnet> it's unfair to say that of busybox because it has grown organically
2023-01-17 17:41:56 <skarnet> it's more natural evolution than intelligent design :P
2023-01-17 18:03:27 <psykose> https://github.com/landley/toybox/blob/c3608db6ddce4a9c96bdcc304299f198488d1974/lib/portability.h#L305
2023-01-17 18:03:31 <psykose> :-)
2023-01-17 18:04:44 <sam_> sorry i forgot you're cringe psykose 
2023-01-17 18:04:46 <sam_> do you want me to run commands for u
2023-01-17 18:04:48 <sam_> or are you goopd
2023-01-17 18:06:29 <psykose> such a nice lovely offer :3
2023-01-17 18:06:41 <psykose> nah i'm good, you can test the above busybox stuff if you want
2023-01-17 18:06:47 <psykose> pretty sure the guess is correct though
2023-01-17 18:12:52 <skarnet> psykose: "This must come before any #include!", he writes, 8 lines after #include <regex.h> :D
2023-01-17 18:13:53 <psykose> `// For musl` was just that important
2023-01-17 18:14:27 <skarnet> I get it, _DARWIN_C_SOURCE won't impact regex.h, but it was still funny :P
2023-01-17 18:15:05 <psykose> :)
2023-01-17 18:15:24 <psykose> rob landley kinda cute tho
2023-01-17 18:15:44 <skarnet> in a "smol and angy" way?
2023-01-17 18:15:56 <psykose> if i say any more i am in big trouble
2023-01-17 18:17:50 <nmeum> so…I guess we just disable hardware checksum accelleration in busybox for all architectures?
2023-01-17 18:18:11 <psykose> i toggled it off already yeah
2023-01-17 18:18:16 <nmeum> thanks
2023-01-17 18:18:23 <psykose> if you have a good way to test it given the above, there's a sample patch by ncopa
2023-01-17 18:18:28 <psykose> and i guess it should be reported either way
2023-01-17 18:18:58 <psykose> there was also the ash bug if you want to try code a fix for something :-)
2023-01-17 18:19:09 <nmeum> which ash bug?
2023-01-17 18:19:19 <psykose> if you send sigwinch to it it prints a newline
2023-01-17 18:19:37 <nmeum> oh indeed
2023-01-17 18:19:37 <nmeum> fun
2023-01-17 18:19:49 <nmeum> do we have an issue for that already?
2023-01-17 18:19:55 <psykose> there was a narrowed-down commit but the tracker is  down
2023-01-17 18:19:58 <psykose> uhh not in aports
2023-01-17 18:20:01 <psykose> but in busybox bugzilla
2023-01-17 18:20:04 <elly> I filed a busybox one somewhere
2023-01-17 18:20:08 <psykose> domain is down still
2023-01-17 18:20:24 <psykose> elly: do you remember the sha
2023-01-17 18:20:52 <elly> the specific bad commit? let me see
2023-01-17 18:20:53 <nmeum> I can search the bugzilla later
2023-01-17 18:21:12 <elly> ah boo the bugzilla did not mail me my own report
2023-01-17 18:21:23 <elly> maybe in the backlog for this channel
2023-01-17 18:21:53 <psykose> or the -linux one
2023-01-17 18:23:04 <psykose> nmeum: 12566e7f9b5e5c5d445bc4d36991d134b431dc6c
2023-01-17 18:23:14 <psykose> (probably)
2023-01-17 18:23:30 <psykose> https://github.com/mirror/busybox/commit/12566e7f9b5e5c5d445bc4d36991d134b431dc6c fancy view
2023-01-17 18:26:09 <nmeum> that's the commit that introduced the regression?
2023-01-17 18:26:34 <Ariadne> elly: heh this is why $dayjob want to replace busybox with a rust replacement (that does not use `std` crate like uutils)
2023-01-17 18:27:54 <elly> Ariadne: yeah, indeed
2023-01-17 18:28:09 <elly> busybox also has some licensing unpleasantness, from a corporate pov
2023-01-17 18:28:19 <Ariadne> meh, GPLv2-only is fine :)
2023-01-17 18:29:29 <orbea> 
ACTION nods :)

2023-01-17 18:30:18 <psykose> nmeum: think so
2023-01-17 18:30:44 <Ariadne> though, i think busybox is scary because the dev team went lawsuit-crazy
2023-01-17 18:30:54 <Ariadne> which did not really benefit the project in any real way
2023-01-17 18:31:17 <psykose> nmeum: checking it out still fails, one commit up doesn't
2023-01-17 18:31:28 <psykose> lazy bisect
2023-01-17 18:32:46 <ikke> fast bisect
2023-01-17 18:35:43 <elly> Ariadne: indeed, that's more what I meant - in terms of risk vs reward it makes busybox a lot less appealing
2023-01-17 18:42:13 <orbea> who did they sue?
2023-01-17 18:42:41 <Ariadne> a bunch of companies in the early 2000s
2023-01-17 18:42:57 <Ariadne> which were not complying with GPL
2023-01-17 18:43:04 <Ariadne> but they got no useful code out of it
2023-01-17 18:43:09 <Ariadne> and a lot of bad press
2023-01-17 18:43:20 <orbea> did they set any precedents via court?
2023-01-17 18:43:26 <Ariadne> not really
2023-01-17 18:43:29 <elly> yeah, they sued a ton of random smaller companies: https://arstechnica.com/information-technology/2010/08/court-rules-gpl-part-of-a-well-pleaded-case/
2023-01-17 18:44:06 <Ariadne> it is kind of why the SFC moved away from litigation to enforce GPL
2023-01-17 18:44:06 <elly> the intent was "force those comapnies to comply with the GPL" but as Ariadne said what actually happened is, those companies complied by releasing some horribly hacked versions of busybox and/or by going bankrupt, and busybox became basically radioactive
2023-01-17 18:45:39 <orbea> i get why someone would do that, but it does seem to have worked out poorly :\
2023-01-17 18:46:28 <elly> the law is not really a great mechanism for culture change sometimes
2023-01-17 18:46:38 <elly> or, well, it's a blunt instrument
2023-01-17 18:47:05 <Ariadne> a larger problem is that a lot of busybox GPL violators are effectively unsueable anyway
2023-01-17 18:47:12 <Ariadne> because they are
2023-01-17 18:47:20 <Ariadne> - based out of shanghai
2023-01-17 18:47:37 <Ariadne> - the company making the firmware closes shop as soon as the product is released
2023-01-17 18:47:53 <elly> also, even if you could get their code, it would have no value to you
2023-01-17 18:47:57 <Ariadne> yeah
2023-01-17 18:48:08 <elly> because manufacturer hacks are pretty much all not just worthless but actively awful :P
2023-01-17 18:48:30 <Ariadne> anyway toybox is also awful
2023-01-17 18:48:40 <sam_> naomi wu's video(s) about the gpl stuff was interesting
2023-01-17 18:49:00 <psykose> any umidigi enjoyers
2023-01-17 18:49:36 <Ariadne> sam_: in most cases it's not malicious, no.  they just don't have anyone who has read the license
2023-01-17 18:51:17 <Ariadne> but china has these "throwaway companies" where a company will be incorporated for a project, and then dissolved once the contract is finished
2023-01-17 18:51:25 <skarnet> I don't think I've ever seen a single piece of corporate code that would bring value to the community if it were to be free licensed
2023-01-17 18:51:33 <elly> not just china tbh Ariadne
2023-01-17 18:51:44 <Ariadne> well yes
2023-01-17 18:52:05 <Ariadne> but china was/is the largest area of concern for gpl enforcement in busybox
2023-01-17 18:52:22 <minimal> from memory the reason Rob left busybox and started on toybox was due to a SFLC action against Cisco (re: Linksys) when at the time he had convinced Cisco to use Linux and be more "open" - the SFLC action killed that change in attitide inside Cisco and they switched to using another OS instead (from memory)
2023-01-17 18:52:42 <elly> I have definitely seen corporate code that would benefit other people if open-sourced, but it's quite rare
2023-01-17 18:52:43 <skarnet> that was part of the reason
2023-01-17 18:52:45 <Ariadne> yes, vxworks
2023-01-17 18:52:59 <elly> because these days most of the good code is written at companies that habitually open-source stuff regardless :P
2023-01-17 18:53:16 <Ariadne> tbh a lot of google open sourced code is not very good :p
2023-01-17 18:53:27 <elly> true!
2023-01-17 18:53:27 <skarnet> elly: that's right
2023-01-17 18:53:36 <elly> but some of it is decent
2023-01-17 18:54:05 <Ariadne> i used to have some imposter syndrome going on before interacting with google staff software engineers
2023-01-17 18:54:10 <Ariadne> and then i was like
2023-01-17 18:54:11 <Ariadne> wow
2023-01-17 18:54:12 <elly> haha
2023-01-17 18:54:15 <Ariadne> i am better than these guys
2023-01-17 18:54:29 <elly> like most large companies, we have a pretty wide range of ability
2023-01-17 18:55:02 <skarnet> Ariadne: my stint at Google had mixed results, because I was technically better than these guys, but they were much, much better than me at working as a team and managing large projects
2023-01-17 18:55:32 <elly> I am specifically an eng manager instead of an engineer so I have many thoughts about that
2023-01-17 18:55:37 <elly> but maybe they belong better in -offtopic
2023-01-17 18:55:45 <skarnet> -offtopic works
2023-01-17 19:13:23 <bl4ckb0ne> psykose: did anything changed in foot/vim/ncurses? garbage paste issue seems gone
2023-01-17 19:13:39 <psykose> yeah it was fixed in 20230114 ncurses
2023-01-17 19:14:05 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/commit/ff488996f317cf1f9eb76aa6b2e25c4cb3a274d0 neat
2023-01-17 19:14:11 <bl4ckb0ne> so it was a ncurses issue
2023-01-17 19:14:16 <psykose> it was an everything issue
2023-01-17 19:14:29 <bl4ckb0ne> software eh
2023-01-17 19:14:36 <psykose> (but yes just another case of ncurses and the old tale of terminfo)
2023-01-17 19:16:55 <bl4ckb0ne> lovely
2023-01-17 19:17:12 <bl4ckb0ne> now I can use del on vim
2023-01-17 19:18:04 <minimal> do you not mean use vim on Dell? ;-)
2023-01-17 19:23:59 <psykose> groaning sound
2023-01-17 19:45:28 <bl4ckb0ne> ^
2023-01-17 20:49:59 <vkrishn> https://lwn.net/Articles/914031/ is this(blksnap) available in newer kernel ?
2023-01-17 20:51:27 <vkrishn> maybe not mature enough
2023-01-17 20:52:16 <psykose> still an out of tree module like it always was, i guess
2023-01-17 21:35:49 <elly> there are two git CVEs that affect 2.39.0 (our current)
2023-01-17 21:35:56 <elly> we should probably get 2.39.1 asap
2023-01-17 21:36:04 <elly> https://github.com/git/git/security/advisories/GHSA-c738-c5qq-xg89 & https://github.com/git/git/security/advisories/GHSA-475x-2q3q-hvwq
2023-01-17 21:36:20 <ikke> elly: psykose already pushed it to all stable branches
2023-01-17 21:36:29 <ikke> (and edge ofcourse)
2023-01-17 21:36:46 <psykose> 2 hours ago
2023-01-17 21:36:53 <ikke> :)
2023-01-17 21:37:00 <psykose> got the email and sorted it
2023-01-17 21:37:12 <elly> oh, lol
2023-01-17 21:37:16 <elly> well1
2023-01-17 21:37:20 <elly> good work then :)
2023-01-17 21:37:36 <psykose> sometimes it pays to have a million mailing lists :p
2023-01-17 21:40:34 <elly> apparently!
2023-01-17 21:44:44 <sam_> even faster than me 
2023-01-17 21:44:46 <sam_> ://
2023-01-17 21:45:55 <psykose> aw darling
2023-01-17 21:45:59 <psykose> you'll get em next time
2023-01-17 21:48:53 <sam_> 🥺
2023-01-17 21:51:03 <psykose> 🥺👉🥺
2023-01-17 21:58:47 <q66> yeah this is the kind of issue that makes me think my "ubsan overflow checks everywhere" initiative is actually worth it
2023-01-17 21:59:05 <q66> because it would render this issue benign
2023-01-17 21:59:13 <q66> or rather, it would just crash git
2023-01-17 22:07:10 <q66> now if only people would stop relying on signed integers wrapping around in real world code, that would be great
2023-01-17 22:07:37 <q66> the number of things that fail this is pretty disappointing
2023-01-17 22:07:46 <q66> for instance every single multimedia codec ever
2023-01-17 22:10:35 <psykose> just -fwrapv
2023-01-17 22:11:42 <q66> that does not actually solve the problem :p
2023-01-17 22:12:20 <psykose> it makes it not ub
2023-01-17 22:12:21 <psykose> i guess
2023-01-17 22:12:31 <q66> yeah but the ub-ness of overflow is not the problem
2023-01-17 22:12:45 <q66> the fact that you go into negatives is
2023-01-17 22:13:34 <q66> if you use it as an expected behavior when you have no way to find out when it's unexpected
2023-01-17 22:13:39 <q66> *then
2023-01-17 22:14:48 <psykose> if it's expected then it's never unexpected :p
2023-01-17 22:17:19 <q66> it can be unexpected even if it's defined
2023-01-17 22:19:25 <q66> fwiw if something uses fwrapv that will also disable the ubsan check, they do not conflict
2023-01-18 02:21:08 <bl4ckb0ne> ugh vim del issue is back
2023-01-18 02:21:36 <bl4ckb0ne> why cant we have nice things
2023-01-18 06:57:39 <pj[m]> <Ariadne> "elly: heh this is why $dayjob..." <- handcraft asm in rust for each platform
2023-01-18 09:38:17 <ncopa> bl4ckb0ne: vim del issue?
2023-01-18 10:27:35 <psykose> it was an ncurses/foot terminfo thing
2023-01-18 10:27:38 <psykose> though i think that was fixed
2023-01-18 10:32:59 <ncopa> hum fixing shaNI detection in busybox does not solve it.
2023-01-18 10:33:30 <ncopa> https://github.com/ncopa/busybox/commit/e4ad5e7f2fed8e36d0779d918052169fe9a0bb95
2023-01-18 10:38:36 <psykose> maybe we were wrong
2023-01-18 10:46:34 <ncopa> running the unstripped fixes it though
2023-01-18 10:47:37 <ncopa> no, maybe I was wrong. seems like test passes now
2023-01-18 10:50:52 <psykose> doesn't sound conclusive if you didn't change anything but just retried
2023-01-18 10:53:11 <ncopa> so i wanted to add gdb stuff, so I executed the unstripped binary, and it didnt crash
2023-01-18 10:53:28 <ncopa> so i swapped back to execute the stripped binary, and this time it didnt crash
2023-01-18 10:53:49 <ncopa> makes me think that maybe I didnt push the cpuid check fix in the first place?
2023-01-18 10:55:31 <donoban> fun: [996829.038483] sway[5854]: segfault at 10 ip 00007f19c9e378b8 sp 00007fffe4316658 error 4 in libwlroots.so.11 (deleted)[7f19c9dfb000+60000] likely on CPU 7 (core 3, socket 0)
2023-01-18 10:59:15 <donoban> I can't reproduce :(
2023-01-18 11:03:14 <ncopa> huh.... running the unstripped version in github makes it pass
2023-01-18 11:03:16 <ncopa> this is weird
2023-01-18 11:04:43 <ncopa> i think we just leave the hwaccel off for a while
2023-01-18 11:09:12 <psykose> donoban: how do you keep running into these :D
2023-01-18 11:09:15 <psykose> more debugging for you
2023-01-18 11:15:54 <ncopa> meh. no idea where i find the core dumps on github. i think i give up
2023-01-18 11:28:01 <donoban> psykose: (deleted) means that that file was deleted? so probably I didn't restarted it after upgrading
2023-01-18 11:28:41 <ikke> yes, that library is no longer available on disk
2023-01-18 11:46:20 <ncopa> ok, im pretty sure its the cpuid thing that is borked somehow.
2023-01-18 11:46:32 <ncopa> I added some printf debugging: https://github.com/ncopa/busybox/actions/runs/3948518291/jobs/6758600595
2023-01-18 11:47:19 <ncopa> and it looks like it returns different results when it detects shaNI
2023-01-18 11:48:52 <ncopa> note that in first test with sha256 it returns -1. on second run it returns 11?
2023-01-18 12:08:49 <psykose> donoban: yes
2023-01-18 12:09:21 <ikke> I suppose the bug can be triggered by users downloading archives from gitlab
2023-01-18 12:10:03 <psykose> which one
2023-01-18 12:10:18 <ikke> oh, meant for #-infra
2023-01-18 12:10:31 <ikke> CVE-2022-41903
2023-01-18 12:16:14 <psykose> ah
2023-01-18 12:16:18 <psykose> yeah
2023-01-18 13:46:26 <elly> I'm a bit surprised that avahi doesn't depend on dbus but only on libdbus, since avahi-daemon declares a dep on dbus in /etc/init.d/avahi-daemon - my system has libdbus but no dbus it seems, so openrc complains at every boot that avahi depends on a nonexistent service
2023-01-18 13:50:09 <psykose> does it actually require dbus i wonder
2023-01-18 13:50:48 <psykose> it sure does
2023-01-18 13:51:16 <psykose> .oO(does avahi even do anything without nss-mdns)
2023-01-18 13:53:56 <elly> I only have avahi installed in the first place because it is a chromium makedepend apparently
2023-01-18 13:54:56 <psykose> ah yes
2023-01-18 13:57:35 <elly> it seems like avahi should depend on dbus or avahi should have a separate -openrc package for its openrc services
2023-01-18 14:02:26 <psykose> did both
2023-01-18 14:03:32 <bl4ckb0ne> ncopa: del uppercases the rest of the line on vim
2023-01-18 14:03:43 <bl4ckb0ne> thought it was link to the foot-terminfo-ncurses thingy
2023-01-18 14:03:46 <bl4ckb0ne> but seems not
2023-01-18 14:04:52 <bl4ckb0ne> https://stackoverflow.com/questions/3230722/delete-key-is-changing-letter-case-in-vim oh well
2023-01-18 14:05:56 <psykose> works for me
2023-01-18 14:15:22 <elly> psykose: both = you made avahi depend on dbus and split its service out? ok
2023-01-18 14:15:35 <elly> I might just use a buildroot for chromium anyway because it seriously has like 150 makedepends
2023-01-18 14:17:20 <skarnet> avahi stands for avahistory of bad ideas
2023-01-18 14:19:30 <elly> gottem
2023-01-18 14:20:58 <psykose> elly: split and the -openrc depends on dbus, ye
2023-01-18 15:13:09 <elly> cool okay
2023-01-18 18:40:58 <bl4ckb0ne> > collect2: fatal error: cannot find 'ld'
2023-01-18 18:41:04 <bl4ckb0ne> why cant we have good software
2023-01-18 18:44:26 <bl4ckb0ne> seems to have fix it, cmake was looking for gold and finding it even if its not installed
2023-01-18 18:50:58 <psykose> link 2 cmake repo
2023-01-18 18:52:32 <bl4ckb0ne> no
2023-01-18 18:52:49 <bl4ckb0ne> https://github.com/OpenXRay/xray-16
2023-01-18 18:54:30 <bl4ckb0ne> https://github.com/OpenXRay/xray-16/blob/53a8ecd2fab0a5d6f8c55ba70f9a8bed4e65ade0/CMakeLists.txt#L205 that probably
2023-01-18 18:55:34 <psykose> -DXRAY_USE_DEFAULT_LINKER=ON
2023-01-18 18:55:37 <psykose> fixed your issue
2023-01-18 18:55:40 <psykose> you're welcome
2023-01-18 18:55:51 <psykose> :3
2023-01-18 18:56:08 <bl4ckb0ne> i just installed gold
2023-01-18 18:56:16 <bl4ckb0ne> 2fast4you
2023-01-18 19:02:38 <psykose> lld is better
2023-01-18 19:02:49 <psykose> tangentially though this stuff really annoys me
2023-01-18 19:02:57 <psykose> i really don't like people that write this stuff into build systems
2023-01-18 19:03:31 <psykose> i mean, i'm biased because i find them more intuitive and easy, i guess not everyone does so they expect a holding hand
2023-01-18 19:04:04 <psykose> but in general why would the build system autopick compilers/linkers/... from the environment they are instead of just expecting a LDFLAGS=-fuse-ld=lld ? it takes just 3 seconds to write that and have it use it..
2023-01-18 19:04:26 <Ermine> what about mold?
2023-01-18 19:04:47 <psykose> don't like that people write*
2023-01-18 19:04:50 <psykose> Ermine: is fast :)
2023-01-18 19:05:00 <bl4ckb0ne> 100% agreeing on this
2023-01-18 19:05:09 <bl4ckb0ne> half tempted to send them a patch out of spite
2023-01-18 19:05:14 <bl4ckb0ne> but i have other software to botch
2023-01-18 19:05:33 <psykose> i didn't measure too deeply but i think lld is still probably better at the generic linker optimisations (icf etc) and is more mature
2023-01-18 19:05:45 <psykose> also speed is mostly not relevant for lto links (99% of the time is in lto passes)
2023-01-18 19:06:01 <elly> me, sobbing, turning off thin lto
2023-01-18 19:06:02 <psykose> so it's great for development as intended, not really for building production artifacts
2023-01-18 19:06:30 <psykose> not that it's bad at it either, but if i had to pick.. i'd pick the mature one with a decade of use, you know
2023-01-18 19:06:57 <psykose> also that maskray lld maintainer has at least 4 trillion iq points
2023-01-18 19:07:22 <psykose> elly: :) yeah gotta always do that for the big stuff for debugging
2023-01-18 19:08:02 <elly> chromium has a special build mode (component mode) that makes it a bunch of dynamic libraries instead of one big static one, which brings link time down hugely
2023-01-18 19:08:19 <elly> specifically because doing the full link while you are working sucks too much
2023-01-18 19:08:25 <psykose> because it gets rid of the link time since there's nothing to link :p
2023-01-18 19:08:33 <Ermine> XD
2023-01-18 19:08:52 <psykose> but with fast enough disk and mold (and no lto ofc) i think even a full chrome link is under 15 seconds or something
2023-01-18 19:08:53 <elly> oh, there's still link time :P
2023-01-18 19:09:20 <Ermine> Enough to get yourself a cup of tea
2023-01-18 19:09:35 <psykose> https://github.com/rui314/mold/blob/main/docs/comparison.png
2023-01-18 19:09:54 <psykose> (in practice i'm not sure how you get these numbers without hot cache in memory, so disk speed indeed)
2023-01-18 19:10:11 <elly> yeah, mold is very fast, but chromium isn't likely to switch to it any time soon
2023-01-18 19:10:31 <psykose> doesn't have to as you can hack it in there for fun
2023-01-18 19:10:48 <psykose> (this is of course not upstream advice)
2023-01-18 19:10:56 <elly> yeah
2023-01-18 19:11:03 <psykose> smh can't even joke about chromium anymore without the developers assuming i'm serious
2023-01-18 19:11:04 <psykose> smh smh
2023-01-18 19:11:18 <psykose> it used to be a scapegoat in here!
2023-01-18 19:12:19 <elly> you still can if you want to
2023-01-18 19:12:35 <elly> I have a lot of practice at not taking people trash-talking chromium personally :P
2023-01-18 19:16:21 <bl4ckb0ne> yay xray-16 builds without issue
2023-01-18 19:17:12 <skarnet> as anyone who left sliced bread in a plastic bag for 3 days can tell you
2023-01-18 19:17:16 <skarnet> mold is indeed very fast
2023-01-18 19:17:35 <psykose> the hell kind of bread you got in france
2023-01-18 19:17:45 <psykose> ours don't take just three days
2023-01-18 19:18:11 <skarnet> that's the kind of bread we don't eat
2023-01-18 19:18:34 <psykose> bl4ckb0ne: wait, did someone reverse engineer the stalker engine..?
2023-01-18 19:18:37 <psykose> what's going on here
2023-01-18 19:18:39 <bl4ckb0ne> yeah
2023-01-18 19:18:41 <bl4ckb0ne> its been a while
2023-01-18 19:18:46 <psykose> it has
2023-01-18 19:18:48 <psykose> just surprises me
2023-01-18 19:18:51 <psykose> that game owned
2023-01-18 19:19:03 <bl4ckb0ne> they did one for shadow of chernobyl, one for clear sky
2023-01-18 19:19:04 <psykose> well games, but
2023-01-18 19:19:09 <bl4ckb0ne> and that one kinds does all 3
2023-01-18 19:19:12 <psykose> :)
2023-01-18 19:19:43 <bl4ckb0ne> call of pripyat runs, clear sky in beta and shadow of chernobyl in wip
2023-01-18 19:19:59 <bl4ckb0ne> they even support elbrus 2000 cpu
2023-01-18 19:20:29 <Ermine> who supports?
2023-01-18 19:20:45 <bl4ckb0ne> xray-16
2023-01-18 19:20:54 <Ermine> Ah
2023-01-18 19:21:22 <sam_> nobody has it except for russians w/ govt ties
2023-01-18 19:21:33 <bl4ckb0ne> and xray-16 devs it seems
2023-01-18 19:21:50 <psykose> what
2023-01-18 19:22:02 <psykose> there is no way the game runs on that at above 5fps
2023-01-18 19:22:09 <Ermine> We have a small community of enthusiast who port various games to Elbrus
2023-01-18 19:22:24 <psykose> ah
2023-01-18 19:22:28 <psykose> it has some insane ipc
2023-01-18 19:22:28 <psykose> nvm
2023-01-18 19:22:48 <psykose> i guess it actually is an average 10 year old cpu so good enough
2023-01-18 19:22:54 <bl4ckb0ne> ugh now i have to resetup a chroot to install steam to grab the files
2023-01-18 19:23:05 <Ermine> They even make streams with those games, and they work fine
2023-01-18 19:23:24 <psykose> do you have like downstream linux forks for it or something
2023-01-18 19:24:01 <psykose> damn, a 2018 elbrus with ddr4..
2023-01-18 19:24:06 <psykose> they really did keep developing it
2023-01-18 19:24:29 <Ermine> Vendor maintains a special Linux distro for it, but Alt Linux and Astra Linux support it too
2023-01-18 19:24:53 <psykose> how interesting :)
2023-01-18 19:25:35 <Ermine> Idk how, because many stuff is considered commercial secret and there's no gcc and clang but some proprietary compiler with gcc interface
2023-01-18 19:26:16 <bl4ckb0ne> lovely
2023-01-18 19:26:20 <bl4ckb0ne> is the isa public?
2023-01-18 19:26:23 <Ermine> But I think we should go to -offtopic if one wants to discuss further
2023-01-18 19:28:39 <psykose> bl4ckb0ne: https://github.com/nrdmn/elbrus-docs
2023-01-18 19:29:20 <bl4ckb0ne> https://github.com/OpenE2K/qemu-e2k hey theres even a qemu target
2023-01-18 19:29:52 <Ermine> There's also a repo with patches to various softwares
2023-01-18 19:33:14 <Ermine> Also different generations are not compatible with each other
2023-01-18 20:34:53 <Hello71> is std::atomic<bool> not defined on riscv? https://gitlab.alpinelinux.org/alxu/aports/-/jobs/953000#L466
2023-01-18 20:36:42 <psykose> it is
2023-01-18 20:39:16 <Hello71> i guess there's an implicit include... somewhere
2023-01-18 20:39:47 <Hello71> https://github.com/google/highway/blob/master/hwy/targets.h#L32-L34 :thinking:
2023-01-18 20:40:16 <ikke> HWY_ARCH_RVV
2023-01-18 20:40:22 <ikke> is that referring to riscv?
2023-01-18 20:40:32 <psykose> it explicitly doesn't include <atomic>
2023-01-18 20:40:38 <psykose> so.. std::atomic is not defined
2023-01-18 20:40:39 <psykose> genius
2023-01-18 20:41:20 <psykose> https://github.com/google/highway/pull/621/files
2023-01-18 20:41:26 <psykose> // TODO(janwas): remove #if once <atomic> is available
2023-01-18 20:41:27 <psykose> well
2023-01-18 20:41:31 <psykose> i guess it do be current year
2023-01-18 20:41:49 <elly> rare
2023-01-18 20:41:56 <ikke> #ifdef __riscv
2023-01-18 20:41:59 <ikke> #define HWY_ARCH_RVV 1
2023-01-18 20:44:19 <psykose> i added #include <atomic> and it builds
2023-01-18 20:44:26 <psykose> also some fun stuff in the logs
2023-01-18 20:44:28 <psykose> -DHWY_DISABLED_TARGETS="(HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128|HWY_RVV)"
2023-01-18 20:44:32 <psykose> rvv disabled on riscv, yes
2023-01-18 20:45:13 <ikke> makes total sense
2023-01-18 20:45:40 <psykose> anyway, i would patch highway to remove that check and always import atomic
2023-01-18 20:50:04 <bl4ckb0ne> or reimplement atomic
2023-01-18 20:55:24 <elly> what's highway, anyway?
2023-01-18 20:58:53 <psykose> google simd library that abstracts simd stuff
2023-01-18 20:59:13 <psykose> dependency of libjxl, the google library for jxl that they now killed
2023-01-18 21:00:26 <psykose> highway itself looks interesting, it's something i've thought about a bit before in the sense of being curious what a good way to make a generic library for that sort of things would be
2023-01-18 21:00:43 <psykose> some largeish google c++ thing probably won't be it but it would be nice to get a standard that is not gnu ifunc for runtime simd dispatch
2023-01-18 21:01:55 <elly> google and large c++ libraries go together like, uh, apache and inexplicable use of java
2023-01-18 21:02:10 <psykose> tbf that's google and just most large things
2023-01-18 21:02:14 <psykose> lots of language teams in there
2023-01-18 21:26:20 <elly> speaking of large c++ codebases, once this change lands: https://chromium-review.googlesource.com/c/chromium/src/+/4165967 it will fix that MediaRouter / Cast crash, we'll probably want to pull it downstream since I won't back merge this past 111
2023-01-18 21:28:29 <psykose> yes
2023-01-18 21:29:13 <psykose> urg
2023-01-18 21:29:22 <psykose> wish i could subscribe to some of these chromium bugs
2023-01-18 21:29:22 <elly> does it not apply?
2023-01-18 21:29:26 <elly> you can, star them
2023-01-18 21:29:39 <psykose> google account :p
2023-01-18 21:29:52 <elly> most bug trackers require an account to use :P
2023-01-18 21:29:58 <psykose> indeed
2023-01-18 21:30:02 <elly> if there are specific ones you want me to keep an eye on for you I can
2023-01-18 21:30:06 <tbodt> i don't really understand the difference between stars and ccs
2023-01-18 21:30:14 <psykose> you already do :)
2023-01-18 21:30:21 <psykose> you've talked about every issue/patch really
2023-01-18 21:30:38 <elly> tbodt: they are very similar - the only difference (afaik) is for visibility-restricted bugs
2023-01-18 21:30:52 <elly> where CCs let you see bugs even if you wouldn't normally be able to, and stars do not, but still tell you when a bug is fixed
2023-01-18 21:31:15 <elly> stars are also "votes" for a bug metaphorically, and we do sometimes sort by star count and look at high-starred bugs
2023-01-18 21:31:18 <elly> but we don't count CCs
2023-01-18 21:31:25 <tbodt> aha
2023-01-18 21:31:41 <tbodt> i assumed for the longest time that stars were just for counting and didn't have any other effect
2023-01-18 21:32:01 <tbodt> they work the same in gerrit and monorail right?
2023-01-18 21:33:10 <elly> not sure
2023-01-18 21:48:38 <skarnet> psykose: can you please merge !43353 if the pipeline passes? thanks :)
2023-01-18 21:49:10 <omni> tbodt: I first thought you meant space stars before I read above
2023-01-18 21:52:53 <skarnet> psykose: 6.5 seconds. thanks :D
2023-01-18 21:53:01 <psykose> hah
2023-01-18 21:57:13 <bratkartoffel> openjdk11 for 3.15 on s390x failed, can someone please restart the build? should be fine, haven't found the cause for the sporadic "Could not connect to server" yet
2023-01-18 21:59:46 <psykose> done
2023-01-19 08:08:17 <maribu> Hi, I have a strange problem in combination with busybox ash and a tiling window manager. If I have virtual terminal emulators open on a virtual desktop and I open a new window (it doesn't match which program / window I open), the terminal gets resized. And on any resize (may this be the result of opening a new window to make space for it, or a manual resize) ash will open a new promt. (Like giving in now command in the prompt and just
2023-01-19 08:08:17 <maribu> pressing enter.)
2023-01-19 08:09:22 <maribu> I think this is intentional behavior to e.g. redraw, if the $PS1 is extremely long. However, it annoys me a lot. Does someone know how to disable this?
2023-01-19 08:13:00 <psykose> https://bugs.busybox.net/show_bug.cgi?id=15256
2023-01-19 08:13:17 <psykose> nah just a new bug in .36
2023-01-19 09:01:25 <psykose> elly: seems that the electron22 segfaults for wayland windowing also go away with custom_libcxx
2023-01-19 09:01:42 <psykose> even more stuff there i guess, and impacted by whatever electron is doing in their patching
2023-01-19 09:01:48 <psykose> the fun never ends :)
2023-01-19 09:26:34 <maribu> psykose Thx for the pointer :)
2023-01-19 09:27:55 <psykose> it is indeed annoying :p
2023-01-19 09:56:56 <maribu> I bisected it to 1e825acf8d715fe49af040cb02f9e96c26955832. Let's see if this is simple to fix.
2023-01-19 10:03:57 <maribu> Hmm, reverting that doesn't fix the issue. Let's try another bisect...
2023-01-19 10:07:28 <psykose> 12566e7f9b5e5c5d445bc4d36991d134b431dc6c
2023-01-19 10:07:36 <psykose> as noted in there
2023-01-19 10:07:43 <psykose> of course, it's not a simple change
2023-01-19 10:16:29 <maribu> Yep, this time I got to the same one. Likely I forgot to exit a good ash and ran a bad ash inside of that the first time
2023-01-19 10:18:24 <ikke> Ashception 
2023-01-19 10:19:13 <psykose> this does surprise me though how many people truly use ash though :)
2023-01-19 10:19:22 <psykose> i think half the regulars i see around here have now reported this issue :p
2023-01-19 10:20:24 <ikke> Power of defaults 
2023-01-19 10:20:30 <psykose> indeed
2023-01-19 13:12:07 <fabled> heads up: just tagged apk 2.12.12 with the recent fixes. will be pushing it to edge soon. there was one commit changing behaviour. apk upgrade will fail if a network repository index is not available. hope it does not cause issues - and it should fix some issues with install_if and other corner cases.
2023-01-19 13:12:54 <ikke> so if one of the repositories in /etc/apk/repositories that uses http(s) is not available?
2023-01-19 13:13:20 <fabled> and there is no local cached index
2023-01-19 13:13:24 <ikke> ok
2023-01-19 13:13:32 <ikke> but you can just remove that repo and try again?
2023-01-19 13:13:37 <fabled> yes
2023-01-19 13:13:38 <ikke> ok
2023-01-19 13:14:06 <fabled> but if the index fails to load, you could not likely install anything from it. so aborting upgrade early makes sense.
2023-01-19 13:14:37 <psykose> there's been a few cases where some 3rd party repo i had timed out but the rest worked and the upgrade went through, so i guess now it aborts instead
2023-01-19 13:14:40 <psykose> but imo i guess that's fine
2023-01-19 13:17:33 <fabled> please file an issue if the change causes anything unexpected that seems unreasonable to workaround otherwise
2023-01-19 13:17:46 <ikke> Will sure do :)
2023-01-19 13:17:52 <ncopa> awesome! thanks!
2023-01-19 13:18:08 <psykose> thanks for the release :)
2023-01-19 13:18:47 <fabled> was long due. i'm still having some fixes/new stuff in pipeline for 2.12 too. but i'm getting distracted too much by $ work, so need to start releasing more often
2023-01-19 13:19:00 <fabled> should probably tag 3.0_pre1 or something similar also
2023-01-19 13:19:21 <ikke> good to see the static build pipeline still works :)
2023-01-19 13:19:46 <fabled> :)
2023-01-19 13:53:33 <ikke> Upgrading gitlab now (forgot to do it 20 minutes ago 🤐)
2023-01-19 13:54:56 <psykose> :)
2023-01-19 14:31:56 <elly> oh I need to go back to that MR for those man pages in apk-tools
2023-01-19 15:15:44 <dzilvys> Hi all. There is a weird behavior I have observed where, when having a USB drive plugged in and I try to boot my device. It hangs for 30 seconds after the grub screen. I have tried enabling verbose mode from grub however, after you select an option from grub and it starts to boot, it hangs for 30 seconds displaying just a black screen then it proceeds with the boot up sequence and starts outputting to the screen.
2023-01-19 15:16:13 <dzilvys> This is only observable with a USB drive plugged in. If there is no USB drive plugged in, then it boots fine. 
2023-01-19 15:16:22 <dzilvys> Could this be a BIOS thing or a grub thing?
2023-01-19 15:16:53 <elly> if you see the grub screen first, it's a grub thing for sure
2023-01-19 15:17:11 <elly> does the USB drive have anything bootable on it?
2023-01-19 15:18:34 <minimal> dzilvys: you mean the black screen is AFTER the Grub menu of boot options? Then press "e" on the relevant boot option and remove "quiet" from the cmdline to see more detail on what is occurring during boot
2023-01-19 15:20:19 <dzilvys> elly: It has nothing bootable on it, its a formatted clean drive
2023-01-19 15:20:57 <dzilvys> minimal: It is after the grub menu, and as mentioned I have already removed quiet to see what is happening. But the wait happens before anything is shown. So I would edit grub, press boot, 30 seconds wait, verbose messages start
2023-01-19 15:21:26 <elly> O_o
2023-01-19 15:21:31 <dzilvys> ;D
2023-01-19 15:21:40 <elly> can you edit your on-disk grub config instead?
2023-01-19 15:21:47 <dzilvys> I can
2023-01-19 15:21:54 <dzilvys> but change what exactly?
2023-01-19 15:22:05 <dzilvys> if you are referncing the quiet, I have already tried that 
2023-01-19 15:22:22 <elly> something like: nosplash debug
2023-01-19 15:22:28 <elly> not quite sure though
2023-01-19 15:23:45 <dzilvys> This is the default grub if anyone was curious
2023-01-19 15:23:46 <dzilvys> GRUB_CMDLINE_LINUX_DEFAULT="modules=sd-mod,usb-storage,ext4 nomodeset pax_nouderef quiet rootfstype=ext4
2023-01-19 15:28:43 <dzilvys> Ok, so I even added nosplash debug and it still displayed nothing
2023-01-19 15:31:46 <minimal> dzilvys: then look at "dmesg" output after it boots to see what occurs (i.e. look at the time offsets to see any noticeable delays)
2023-01-19 15:32:16 <dzilvys> minimal: Thank you I will take a look
2023-01-19 15:33:31 <minimal> dzilvys: you may need to add "log_buf_len=32768" to the cmdline in order to capture the full set of boot messages in dmesg
2023-01-19 15:34:32 <minimal> basically in the dmesg output you'll see how long it took the kernel itself to load and be ready, then how long the initramfs took to do some things before it then mounted rootfs and started OpenRC etc
2023-01-19 15:35:12 <dzilvys> dmesg logs get saved to /var/log/dmesg correct? or is there a saparate one?
2023-01-19 15:37:30 <minimal> yes, only one set is kept unless you edit "previous_dmesg" in /etc/conf.d/bootmisc
2023-01-19 15:38:08 <dzilvys> No I would not have made that change
2023-01-19 15:47:58 <dzilvys> minimal: So dmesg does not show any major changes, there are definitely no 30seconds delay
2023-01-19 15:50:48 <dzilvys> The only thing from dmesg that is missing when a USB is plugged in on boot is the following
2023-01-19 15:51:05 <dzilvys> https://hastebin.com/axedepuzik.yaml
2023-01-19 15:51:24 <dzilvys> That is the only difference between the two, however, as mentioned there is no delay
2023-01-19 15:52:22 <minimal> dzilvys: could you use a non-javascript requiring paste site?
2023-01-19 15:53:08 <dzilvys> minimal: Sure just tell me which one, I only know of hastebin
2023-01-19 15:54:40 <minimal> tpaste.us and pastebin from memory
2023-01-19 15:54:49 <minimal> there's a tpaste package for Alpine
2023-01-19 15:55:22 <dzilvys> https://pastebin.com/raw/XCQHFtLK
2023-01-19 15:55:27 <dzilvys> hopefully thats good
2023-01-19 15:58:06 <minimal> the dmesg log only shows initial messages whereas the "dmesg" command also shows additional stuff (i.e. if a init.d service triggers module loads)
2023-01-19 15:59:22 <minimal> a line like "Alpine Init 3.7.0-r1" will show how long before initramfs' init is started
2023-01-19 15:59:48 <dzilvys> oh
2023-01-19 16:00:04 <minimal> a line like "Mounting root: ok" shows time to actually find and mount the rootfs
2023-01-19 16:01:53 <minimal> then lines after that will reflect things like loading additional modules etc from rootfs
2023-01-19 16:03:37 <dzilvys> minimal: https://tpaste.us/5XjE
2023-01-19 16:03:44 <dzilvys> Anything from there look suspicious? 
2023-01-19 16:10:13 <elly> 30 seconds is such a suspiciously round amount of time that it almost has to be a grub-internal timeout but I can't think what it would be
2023-01-19 16:11:10 <dzilvys> Exactly, and I personally can't see anything suspicious with the logs
2023-01-19 16:13:41 <elly> I am kind of at a loss
2023-01-19 16:14:03 <elly> I would guess something like, "grub is trying to wait 30 seconds for your boot partition to become available on that device, not finding it, then falling back to the proper one"
2023-01-19 16:14:41 <dzilvys> But surely when I select the grub option it goes to the boot parition assigned to that grub location. 
2023-01-19 16:14:51 <dzilvys> So I don't know why it would be searching on a new drive
2023-01-19 16:15:21 <elly> I don't either, but grub is kind of a cave of wonders in that respect
2023-01-19 16:15:25 <elly> it does a lot of stuff on its own
2023-01-19 16:15:36 <dzilvys> ;D
2023-01-19 16:16:08 <minimal> dzilvys: hang on a minute - which Alpine version are you using? "Linux version 4.19.176-0-vanilla" !!!!
2023-01-19 16:16:37 <dzilvys> Yeah its an old build. Moving onto a new one is not something we are doing as of right now, its planned in the upcomming months
2023-01-19 16:17:12 <minimal> old? more like prehistoric
2023-01-19 16:17:16 <dzilvys> XD
2023-01-19 16:17:24 <elly> I'm somewhat curious what your grub version is now
2023-01-19 16:18:03 <minimal> dzilvys: plus that dmesg output is incomplete, no sign of Alpine's init being loaded etc
2023-01-19 16:21:26 <minimal> and doesn't the use of "usb-storage" introduce a slight delay on purpose in order to give USB devices time to be ready?
2023-01-19 16:22:09 <elly> yeah, but it shouldn't be 30 seconds
2023-01-19 16:22:30 <minimal> also as this is a Supermicro server is your console via IPMI?
2023-01-19 16:23:11 <minimal> elly: well we don't have full dmesg output to see what's going on
2023-01-19 16:23:32 <dzilvys> That dmesg output is by running dmesg command
2023-01-19 16:23:38 <dzilvys> I don't know how else to get more of it
2023-01-19 16:23:59 <dzilvys> I can try removing usb-storage module and see if it still happens
2023-01-19 16:24:20 <elly> that would be an interesting experiment at least
2023-01-19 16:25:39 <minimal> dzilvys: I'd mentioned the log_buf_len= cmdline parameter to change its size
2023-01-19 16:26:15 <minimal> you'd need to look at what LOG_BUF is currently set to in your kernel config
2023-01-19 16:26:37 <dzilvys> I set it to 10M
2023-01-19 16:26:49 <minimal> for a server I'd expect a lot more output than from a desktop
2023-01-19 16:26:57 <dzilvys> also removing usb-storage has had no affect :/
2023-01-19 16:27:48 <dzilvys> so is 10M too little?
2023-01-19 16:28:33 <minimal> shouldn't be, but you're running a very old kernel and one with PAX and other security stuff on it so perhaps that is impacting on the log buffer
2023-01-19 16:30:39 <dzilvys> also to answer your IPMI question, I don't think so. I am accessing it directly through the server
2023-01-19 16:31:43 <minimal> dzilvys: why is a 30 second delay in booting an issue for a server? ;-)
2023-01-19 16:32:10 <dzilvys> minimal: XD, because we don't want it
2023-01-19 16:33:16 <minimal> try moving to a modern/supported Alpine release then? ;-)
2023-01-19 16:33:52 <dzilvys> XD
2023-01-19 16:34:22 <minimal> so you're on Alpine v3.10.x?
2023-01-19 16:34:34 <dzilvys> Yes
2023-01-19 16:34:54 <dzilvys> grub 2.02
2023-01-19 16:35:00 <minimal> end of support for "main": 1st May 2021
2023-01-19 16:36:00 <dzilvys> We are aware
2023-01-19 16:36:34 <minimal> well without full dmesg output I think it's going to be hard to diagnose where the delay occurs
2023-01-19 16:37:44 <dzilvys> and the issue is, I can't seem to get more of a dmesg output :/
2023-01-19 16:38:55 <dzilvys> Other interesting thing to note, this only happens on supermicro servers
2023-01-19 16:39:02 <dzilvys> Other hardware we run alpine on, works fine
2023-01-19 16:40:43 <minimal> e.g. from looking at dmesg on a VM here I can see that from when the kernel started it took 0.821746 seconds for the initramfs' init to start, 1.185772 seconds for it to start mounting rootfs, and 3.025948 seconds for the mount to complete, and then over the next 6 seconds various kernel modules were loaded, and after 9.486723 seconds the rootfs was remounted read-write
2023-01-19 16:41:38 <minimal> dzilvys: well you'd have to dig into the kernel settings and kernel docs for that 4.x release to see how it handles setting log buffer
2023-01-19 16:43:37 <dzilvys> hmm alright thank you btw
2023-01-19 16:45:58 <maribu> psykose: Looks like someone (*cough* *cough*) proposed a fix for https://bugs.busybox.net/show_bug.cgi?id=15256
2023-01-19 16:46:27 <elly> but not for bugs.busybox.net being down apparently
2023-01-19 16:46:39 <elly> aha! it's up, just very slow
2023-01-19 16:49:55 <minimal> dzilvys: actually this is vanilla kernel, forgot what I said about PAX etc (was distracted seeing "pax_nouderef" in your cmdline)
2023-01-19 16:50:02 <minimal> s/forgot/forget/
2023-01-19 16:50:02 <alpine-meetbot> minimal meant to say: dzilvys: actually this is vanilla kernel, forget what I said about PAX etc (was distracted seeing "pax_nouderef" in your cmdline)
2023-01-19 16:50:30 <dzilvys> ohh
2023-01-20 02:05:22 <psykose> maribu: the ashocalypse comes for us all
2023-01-20 02:05:30 <psykose> thanks! i can't review it but it's appreciated :)
2023-01-20 02:38:36 <elly> hm
2023-01-20 02:39:02 <elly> psykose I'm going to send you an MR for the mediarouter crash as soon as I figure out gitlab's ui
2023-01-20 02:41:00 <psykose> git checkout -b mybranch; < git commit stuff >; git push -u origin <branchname>; <click the url it gives you>
2023-01-20 02:41:03 <psykose> that's all
2023-01-20 02:41:18 <psykose> last part makes it easy :p
2023-01-20 02:41:40 <elly> aha, useful :)
2023-01-20 02:46:24 <elly> last time I tried this, I accidentally created an MR against my own fork of aports instead of the real one
2023-01-20 02:47:05 <elly> yeah, I am not allowed to push to the real aports repo
2023-01-20 02:47:35 <elly> which I guess makes sense
2023-01-20 02:47:52 <elly> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43380 there we go
2023-01-20 02:50:16 <psykose> all correct
2023-01-20 02:50:29 <psykose> i'll let it pass a build just to make sure
2023-01-20 02:50:30 <psykose> thanks!
2023-01-20 02:54:36 <elly> I think https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/120 (documentation for apkv2 & apkv3) is good to go also but I am unsure who needs to merge it
2023-01-20 02:58:25 <psykose> big apk bossman maintainer
2023-01-20 02:58:33 <psykose> when he sees it
2023-01-20 02:58:35 <psykose> :-)
2023-01-20 02:58:39 <elly> alright, cool
2023-01-20 02:59:00 <psykose> <10 months later spongebob voice>
2023-01-20 02:59:33 <elly> no real hurry on it
2023-01-20 03:00:06 <psykose> yeah of course
2023-01-20 03:00:12 <psykose> oh, is it meant to be .5
2023-01-20 03:00:41 <psykose> i guess it is
2023-01-20 03:00:49 <psykose> i'm so used to 5 just being configuration formats
2023-01-20 03:00:55 <elly> yeah, .5 includes all file formats afaik
2023-01-20 03:01:16 <psykose> .4 because the files are very special
2023-01-20 03:03:28 <elly> I'm about halfway through the total list of alpine patches
2023-01-20 03:03:34 <elly> a lot of the remaining ones are hard though
2023-01-20 03:12:31 <psykose> yep
2023-01-20 03:12:40 <psykose> the sandbox stuff is quite fun
2023-01-20 03:13:55 <elly> I have a todo list I've been keeping of all of them and I think like 5-6 are marked "don't upstream"
2023-01-20 03:14:07 <psykose> which ones
2023-01-20 03:14:09 <psykose> dns is also a mess
2023-01-20 03:17:02 <elly> I can't remember offhand, it's on my work laptop, but I think: the two ffmpeg ones, the sandbox one, the tid caching one, and the partition-atfork one
2023-01-20 03:17:05 <elly> :q
2023-01-20 03:17:07 <elly> oops
2023-01-20 03:17:22 <psykose> ffmpegs are just reverts of something upstream due to some api stuff
2023-01-20 03:17:45 <psykose> atfork is fixed in musl 1.2.4 though it's more of a workaround, realistically it's not really allowed to call atfork there
2023-01-20 03:17:52 <elly> I don't understand why those are necessary really (the ffmpeg ones)
2023-01-20 03:18:47 <psykose> tid caching is due to.. well, internal libc stuff i guess needed for whatever it's doing, not sure if that's possible to make generic
2023-01-20 03:18:51 <psykose> lemme look at the ffmpeg reverts
2023-01-20 03:19:35 <elly> the atfork thing, the upstream code is known to be not legit: https://source.chromium.org/chromium/chromium/src/+/main:base/allocator/partition_allocator/partition_root.cc;l=261?q=base%2Fallocator%2Fpartition_allocator%2Fpartition_root.cc&ss=chromium
2023-01-20 03:19:39 <elly> but it works in practice
2023-01-20 03:20:04 <elly> if anyone has a better idea for how it should work upstream I am all ears though
2023-01-20 03:20:54 <psykose> cute ears
2023-01-20 03:20:57 <psykose> (i don't have a clue)
2023-01-20 03:21:05 <elly> heh :)
2023-01-20 03:21:05 <psykose> i looked at one part of the 102 revert
2023-01-20 03:21:09 <elly> I think nobody does, is the problem
2023-01-20 03:21:09 <psykose> and found a
2023-01-20 03:21:18 <psykose> @deprecated use ch_layout.nb_channels
2023-01-20 03:21:26 <psykose> on one of the reverted things that change from that
2023-01-20 03:21:27 <psykose> smh
2023-01-20 03:21:41 <psykose> i guess maybe it is not actually relevant anymore but i have to test
2023-01-20 03:26:28 <psykose> the second one is changing pkt_duration to duration
2023-01-20 03:27:12 <psykose> but that is a master ffmpeg thing
2023-01-20 03:27:13 <psykose> https://github.com/FFmpeg/FFmpeg/commit/4397f9a5a09d82846bf787295c60f1104cf7de9e
2023-01-20 03:27:22 <psykose> so it's keeping the old name since 5.1 doesn't have it
2023-01-20 03:29:03 <elly> I see
2023-01-20 03:30:20 <elly> so basically as soon as we're on ffmpeg >5.1 that patch can go
2023-01-20 03:30:29 <elly> chromium must really be tracking trunk ffmpeg heavily, wow
2023-01-20 03:32:15 <psykose> ye
2023-01-20 03:32:17 <psykose> p much
2023-01-20 03:33:28 <psykose> there's a patch in ffmpeg itself purely for chromium
2023-01-20 03:33:32 <psykose> and that one is not even in ffmpeg afaik
2023-01-20 03:34:50 <elly> wild
2023-01-20 03:38:07 <psykose> the first one is https://bugs.chromium.org/p/chromium/issues/detail?id=1325301 but i think 5.1 has this now
2023-01-20 03:40:31 <psykose> README.chromium -> every change must be upstreamed
2023-01-20 03:41:17 <psykose> Add av_stream_get_first_dts for Chromium -> Date:   Wed Jul 7 19:01:22 2021 -0700
2023-01-20 03:41:18 <psykose> smh
2023-01-20 03:41:51 <elly> looks like it was upstreamed to me
2023-01-20 03:41:57 <elly> :)
2023-01-20 03:43:39 <psykose> was it? i can't find av_stream_get_first_dts in ffmpeg
2023-01-20 03:49:23 <elly> oh, I don't know
2023-01-20 03:49:38 <elly> I didn't actually check upstream
2023-01-20 05:41:18 <fabled> elly: thanks for working on the man pages. I have had very limited time for APK recently. I'll have more during this year. And reviewing the man pages PR is next on Todo.
2023-01-20 06:23:17 <elly> there is no urgency
2023-01-20 08:45:43 <psykose> elly: verified again, indeed it fixes the media ui crash <3
2023-01-20 09:53:01 <consus[m]> psykose: Hi! I've submitted a multipath-tools fix that you've merged. If I want it fixed in 3.17, should I create an additional PR for 3.17-stable or backports are handled differently?
2023-01-20 09:53:39 <psykose> exactly that, though i already backported it
2023-01-20 09:54:08 <psykose> for future reference you have to bump the pkgrel when modifying the package
2023-01-20 10:04:23 <consus[m]> Yeah, sorry, missed that
2023-01-20 11:04:43 <hcs> I have two questions: 1. Is there a reason why openrc's checkpath command doesn't do `mkdir -p` instead of complaining about parent directories not existing? 2. Does anyone know if supervise-daemon understands SIGHUP from logrotate?
2023-01-20 11:13:03 <psykose> pretty sure it doesn't understand sighup
2023-01-20 11:13:29 <psykose> there's no way to rotate s-d logs that i know of
2023-01-20 11:13:34 <psykose> the former isn't a shell utility
2023-01-20 11:13:38 <psykose> in any case you should ask https://github.com/OpenRC/openrc
2023-01-20 11:14:15 <psykose> both sound changeable (the latter especially)
2023-01-20 11:17:21 <hcs> I'll go ask the OpenRC guys, but thanks for answering anyway. I'm thinking of just copy+truncating the logs that s-d produces to avoid the need to update file handle.
2023-01-20 11:17:52 <psykose> yeah i guess with enough shell it's fixable like that, though certainly not convenient..
2023-01-20 11:18:15 <psykose> but yeah, maybe if you ask it would be a new feature :)
2023-01-20 11:42:34 <skarnet> who uses supervise-daemon anyway :P
2023-01-20 11:44:31 <hcs> Do you have a better alternative? I need it to support putting stderr+stdout somewhere useful and keeping the daemon alive.
2023-01-20 11:50:25 <skarnet> s6 :)
2023-01-20 11:50:47 <skarnet> aka the thing that the people who wrote supervise-daemon tried to recreate, badly
2023-01-20 11:51:55 <hcs> `apk info s6` reveals that s6 is from skarnet.org. I'm sensing some bias here
2023-01-20 11:52:27 <skarnet> don't take my word for it
2023-01-20 11:52:35 <skarnet> try it for yourself
2023-01-20 11:53:11 <skarnet> but if you're looking for a supervisor that works and keeps your logs where you want them...
2023-01-20 11:53:20 <skarnet> *shrug*
2023-01-20 11:54:15 <hcs> Does s6 support logrotate in a way that doesn't require restarting the supervised process?
2023-01-20 11:54:54 <skarnet> it doesn't support logrotate because logrotate has inherent race conditions. It comes with its own logger that performs rotation itself.
2023-01-20 11:55:14 <skarnet> depending on the parameters you give it.
2023-01-20 11:56:55 <skarnet> basically your service writes to its stdout/stderr, and behind it you have a supervised logger that reads what it writes and logs it to a directory, automatically rotating the file under conditions you define.
2023-01-20 11:57:48 <hcs> s6-log mentions something about a logging script. Can it either output svc.log.lz4 directly, or rotate to lz4-compressed files? If so, that would solve basically all my concerns
2023-01-20 11:58:16 <skarnet> it can rotate to lz4-compressed files, yes
2023-01-20 11:58:41 <hcs> Wonderful, thanks for the recommendation. I'll take a look.
2023-01-20 11:59:21 <skarnet> np, that's what it's for :) We have a community on #s6 if you have any questions!
2023-01-20 12:00:18 <hcs> Lol if #s6 will spoonfeed me a complete setup that'd be great. I think I'm good for now though, I'll scroll through the docs and slap a test build together with s6 instead of supervise-daemon
2023-01-20 12:00:28 <psykose> it's quite challenging to set up given there is no base support for it at all, compared to "just adding an init.d script"
2023-01-20 12:01:13 <skarnet> psykose: writing a run script is actually simpler than writing an init.d script, and you know it
2023-01-20 12:01:20 <psykose> it is
2023-01-20 12:01:30 <hcs> Wait... I cant just set supervisor="s6"?
2023-01-20 12:01:42 <psykose> the surrounding machinery to get openrc to start svscan and a dir though.. not obvious or very documented :p
2023-01-20 12:01:49 <psykose> maybe there was a gentoo page though
2023-01-20 12:01:54 <skarnet> ugh
2023-01-20 12:02:15 <skarnet> supervisor=s6 is the half-assed openrc way of doing it
2023-01-20 12:02:22 <psykose> does that even work
2023-01-20 12:02:39 <skarnet> on Alpine, I'm not sure
2023-01-20 12:02:44 <hcs> Oh I'm not about to do a bunch of integration stuff just for this. I'm looking for the half-assed openrc way.
2023-01-20 12:02:56 <hcs> skarnet you're on the alpine dev irc
2023-01-20 12:03:06 <skarnet> yup
2023-01-20 12:04:02 <skarnet> and with the Alpine s6 package, you have a supervision tree started at boot time, and you put your services under it
2023-01-20 12:04:37 <skarnet> it's the way that works all the time
2023-01-20 12:48:08 <WhyNotHugo> So in the "Extended" ISO, /lib/firmware is a symlink to /lib/modules/firmware and /lib/modules is a symlink to /.modloop/modules, which is mounted readonly.
2023-01-20 12:48:18 <WhyNotHugo> So installing linux-firmware-* fails due to this path being RO.
2023-01-20 12:48:31 <WhyNotHugo> I think this can be fixed by replacing one symlnk with an overlayfs mount.
2023-01-20 12:48:33 <WhyNotHugo> Any thoughs on this?
2023-01-20 12:48:52 <WhyNotHugo> (I did work around it for myself, but would like to address the root of the issue)
2023-01-20 13:02:37 <ikke> The modloop service should already create an overlayfs mount 
2023-01-20 13:02:56 <ikke> But it depends on the overlayfs module being loaded already 
2023-01-20 13:05:47 <psykose> yeah with modules=overlay it should work
2023-01-20 13:06:01 <psykose> of course, nobody is going to edit that in the extended .iso boot sequence
2023-01-20 13:06:19 <psykose> perhaps it should be edited into the default cmdline?
2023-01-20 13:07:21 <WhyNotHugo> psykose: In which repo is this hosted?
2023-01-20 13:08:25 <psykose> scripts/mkimg.standard.sh in aports has.. stuff
2023-01-20 13:10:04 <psykose> mkimg.base.sh has the default initfs_cmdline
2023-01-20 13:19:10 <WhyNotHugo> mkimg.standard.sh seems to override it for three architectures, but has a copy-paste of the defaults, rather than extending the original.
2023-01-20 13:20:26 <vkrishn> skarnet: is switching to s6 easy ? it there a wiki.a.o page outlining atleast basic install ?
2023-01-20 13:23:29 <hcs> There is some mentions of s6 on the wiki, but not much. https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts#Services_supervised_by_s6
2023-01-20 13:45:41 <skarnet> at the moment it's not so much "switching to s6", it's "deciding to use s6 to supervise your service instead of having openrc launch it"
2023-01-20 13:45:49 <skarnet> they coexist
2023-01-20 13:47:03 <skarnet> if you write a service directory for your service, link it to /run/service at boot time (you can even write an openrc service to do that!), and tell s6-svscan that there's something new, then  your service will be picked up, started, and supervised by s6
2023-01-20 13:47:32 <skarnet> in the future there will be more integration but it's still some ways away
2023-01-20 13:58:17 <vkrishn> thanks, was thinking of trying, as I have 2old mobiles to play with
2023-01-20 15:42:49 <ikke> Is ruby / gems broken for others? Seems like it has problems locating gems / files. Installing ruby on edge and running irb for example does not seem to work. 
2023-01-20 15:43:55 <ikke> OK, that issue is fixed by installing ruby-rdoc, but I'm having other issues 
2023-01-20 15:44:07 <psykose> reproduced the same without rdoc
2023-01-20 15:44:09 <psykose> what others
2023-01-20 15:44:32 <ikke> ruby-xdg 
2023-01-20 15:45:13 <ikke> irb -> require 'xdg' reproduces it
2023-01-20 15:45:42 <psykose>  uninitialized constant XDG::Data ?
2023-01-20 15:48:58 <psykose> Data.define is ruby 3.2
2023-01-20 15:50:14 <psykose> i.e. ruby-xdg requires ruby 3.2
2023-01-20 15:50:32 <psykose> https://github.com/bkuhlmann/xdg/commit/d0b005a729b1c33f5a03b3d5322fb84ef791bc48 https://github.com/bkuhlmann/xdg/commit/55aa782ee62bb9ba352e27e980cda873a91a74eb
2023-01-20 15:50:41 <psykose> they don't explicitly define it but it only exists in 3.2
2023-01-20 15:51:57 <psykose> https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/ "Data" in 3.2 only :p
2023-01-20 15:57:40 <ikke> Hmm I checked the release notes but didn't saw anything 
2023-01-20 15:57:51 <ikke> Then it's my fault 
2023-01-20 15:57:54 <ikke> Thanks 
2023-01-20 15:58:28 <ikke> And of course now I see it
2023-01-20 15:59:23 <ikke> I'll probably have to downgrade ruby-xdg for now 
2023-01-20 16:01:00 <bl4ckb0ne> removing unrar broke innoextract
2023-01-20 16:02:05 <bl4ckb0ne> https://github.com/dscharrer/innoextract/blob/660546ad796bb7619ff0e99a6cd61c4e01e4e241/src/cli/gog.cpp#L110 dumb runtime dep
2023-01-20 16:02:11 <psykose> tragic
2023-01-20 16:02:57 <psykose> hmm
2023-01-20 16:03:01 <bl4ckb0ne> yep
2023-01-20 16:03:17 <bl4ckb0ne> i wonder if I could just alias it to bsdtar
2023-01-20 16:03:22 <psykose> is that doing anything at all other than calling unrar or am i misreading
2023-01-20 16:03:28 <psykose> uhh no you can't cause of the options
2023-01-20 16:03:50 <bl4ckb0ne> tragic
2023-01-20 16:03:56 <bl4ckb0ne> its just calling unrar
2023-01-20 16:04:01 <psykose> but like, is the whole thing not just a rar
2023-01-20 16:04:03 <bl4ckb0ne> expects the bin to be there
2023-01-20 16:04:22 <psykose> i.e. instead of innoextract something you can just bsdtar xf something
2023-01-20 16:04:39 <psykose> or is it a custom format and part of it is a rar
2023-01-20 16:04:52 <bl4ckb0ne> > setup_stalker_cop_2.1.0.17-1.bin: RAR archive data, v4, os: Win32, flags: ArchiveVolume NewVolumeNaming FirstVolume
2023-01-20 16:04:58 <bl4ckb0ne> its windows shit
2023-01-20 16:05:14 <psykose> says rar tho
2023-01-20 16:05:20 <psykose> shrug try it
2023-01-20 16:06:16 <bl4ckb0ne> wont work, bsdtar uses -x to extract
2023-01-20 16:06:18 <bl4ckb0ne> rar just `x`
2023-01-20 16:06:59 <ikke> What confused me is that ruby-xdg also defines a Data classa
2023-01-20 16:07:14 <bl4ckb0ne> imagine writing a tool that pull the whole of boost just to have it depend on a runtime dep to extract a rar file
2023-01-20 16:10:41 <bl4ckb0ne> got it
2023-01-20 16:11:06 <bl4ckb0ne> curl'd the apk from 3.14
2023-01-20 16:14:35 <psykose> no, i meant like
2023-01-20 16:14:39 <psykose> without innosetup
2023-01-20 16:14:46 <psykose> just literally bsdtar the file
2023-01-20 16:14:50 <bl4ckb0ne> yeah bsdtar extracts it
2023-01-20 16:15:02 <psykose> what's the point of innoextract then
2023-01-20 16:15:49 <bl4ckb0ne> extracts the whole gog stuff in one go nicely and well organised
2023-01-20 16:18:06 <psykose> hmm
2023-01-20 16:18:14 <psykose> well, you can definitely write code
2023-01-20 16:18:32 <psykose> so you could write.. uhh.. something alternative to use bsdtar :p
2023-01-20 16:19:07 <bl4ckb0ne> i could and i should
2023-01-20 16:19:10 <psykose> afaik calling libarchive functions for rar extraction is fine, so you can do it in code without runtime utils
2023-01-20 16:19:16 <bl4ckb0ne> but i wont and ill keep complaining on irc
2023-01-20 16:19:25 <psykose> of course, that's more effort than rewriting those lines to just call bsdtar with equiv args
2023-01-20 16:19:36 <psykose> and is also a downgrade prolly cause i bet it fails in some cases
2023-01-20 16:19:50 <bl4ckb0ne> i could just shave the whole yak and add rar extraction to whatever boost archive lib there is
2023-01-20 16:19:59 <psykose> i doubt you can
2023-01-20 16:20:09 <psykose> the reason nothing exists is cause of the awful rar licencing
2023-01-20 16:20:16 <bl4ckb0ne> or i can just start xray-16 and play instead of doing my work
2023-01-20 16:20:29 <psykose> hmmmmm
2023-01-20 16:20:39 <psykose> i wish i played more games
2023-01-20 16:20:50 <bl4ckb0ne> believe in yourself
2023-01-20 16:20:58 <bl4ckb0ne> those gitlab PR can wait
2023-01-20 16:21:01 <elly> be the gamer you want to see in the world
2023-01-20 16:22:43 <psykose> playing stuff is hard though
2023-01-20 16:22:49 <psykose> i just open it and close it after 10 minutes
2023-01-20 16:22:56 <bl4ckb0ne> git gud
2023-01-20 16:22:58 <psykose> or get distracted by gitlab prs
2023-01-20 16:23:01 <skarnet> no joy in life allowed
2023-01-20 16:33:35 <bl4ckb0ne> nice xray-16 fails to start
2023-01-20 16:38:44 <psykose> nice
2023-01-20 16:45:01 <bl4ckb0ne> aha segfault
2023-01-20 16:45:08 <bl4ckb0ne> maybe i should read their wiki
2023-01-20 16:57:22 <psykose> shrug
2023-01-20 16:57:25 <psykose> could also be some ub
2023-01-20 16:59:08 <bl4ckb0ne> perhaps
2023-01-20 16:59:20 <bl4ckb0ne> but i rebooted and tmpfs nuked the folder
2023-01-20 16:59:22 <bl4ckb0ne> oh well
2023-01-20 16:59:24 <bl4ckb0ne> another day
2023-01-20 19:23:05 <maribu> I just installed updates and now my machine fails to boot :-( I still can boot from USB, though, so at least not an hardware issue
2023-01-20 19:24:15 <ikke> maribu: do you get an error?
2023-01-20 19:24:56 <maribu> no, it just gets stuck after or during loading the initrd
2023-01-20 19:25:42 <maribu> Downgrading linux-lts doesn't solve the issue. I fail to recall how I can access the log of apk :-(
2023-01-20 19:26:22 <ikke> there is no log in v2
2023-01-20 19:26:27 <ikke> v3 will have it
2023-01-20 19:27:31 <psykose> what hardware do you have
2023-01-20 19:27:34 <maribu> OK. I recall that something triggered rebuilding the initrd. I assumed it was a kernel update.
2023-01-20 19:27:52 <psykose> making sure that completed and has firmware in it is the first thing i'd check
2023-01-20 19:29:03 <psykose> aside from that you can try pass nomodeset, iirc it would not require the drivers to be loaded so it should get past at least that i guess
2023-01-20 19:29:05 <psykose> no promises
2023-01-20 19:30:05 <maribu> Downgrading the linux-lts triggered regeneration of the initrd.
2023-01-20 19:30:27 <maribu> Maybe amd-ucode was the issue. The version number looks like a recent update
2023-01-20 19:31:37 <psykose> it's just from linux-firmware
2023-01-20 19:31:44 <psykose> indeed there was a new version a few days ago
2023-01-20 19:31:53 <psykose> it just only changed things for some amd cards though really
2023-01-20 19:33:42 <psykose> you should still try get the old version, but usually the issue here is "firmware not in the initrd for drm load"
2023-01-20 19:39:23 <maribu> it wasn't the ucode
2023-01-20 19:49:49 <maribu> How can I figure out which pkgs have received updates in the last 12 hours in the edge repos?
2023-01-20 19:50:44 <ptrc> you can look at the `t:` property in the APKINDEX for each repo
2023-01-20 19:56:21 <ptrc> something like this maybe? tar xOf APKINDEX.tar.gz APKINDEX | grep -e '^P:' -e '^t:' | cut -d: -f2 | while read -n name; read -n timestamp; do if [ "$timestamp" -gt $(( $(date '+%s') - 12 * 60 * 60 )) ]; then echo "$name"; fi; done
2023-01-20 19:56:31 <ptrc> ( i only tested it in zsh, it might be broken in ash )
2023-01-20 19:58:56 <elly> you can also check git log for aports
2023-01-20 20:00:40 <psykose> gitte logge
2023-01-20 20:00:58 <ptrc> a commit doesn't always rebuild the package; though now i notice that the question doesn't specify that
2023-01-20 21:30:54 <maribu> That's super strange. The only updates in the last 48 hours that affect critical packages are linux-lts and apk-tools. I even did an apk fix $(apk info) to make sure that nothing got corrupted or so
2023-01-20 21:31:46 <maribu> Maybe the issue is some tool used in the generation of the initrd
2023-01-20 21:32:23 <maribu> And it only got triggered by installing linux-lts, so I didn't notice before
2023-01-20 21:32:29 <psykose> it can be the kernel itself, i guess
2023-01-20 21:42:28 <maribu> I downgraded it to multiple different versions that previously booted, including the one that I cam boot from USB
2023-01-20 21:43:27 <psykose> you did regenerate the initrd correctly each time right
2023-01-20 21:43:34 <psykose> it needs a full chroot with the mounts and stuff
2023-01-20 21:45:37 <maribu> I mounted the root partition to /mnt, the boot partition to /mnt/boot, and I bind-mounted /dev, /sys and /proc into the corresponding folders in /mnt before the chroot
2023-01-20 21:45:51 <ikke> sounds good
2023-01-20 21:46:01 <psykose> indeed
2023-01-20 21:46:44 <psykose> i can't think of anything that changed aside from firmware, apk itself (which doesn't do anything here), the kernel, and you downgraded both so..
2023-01-20 22:26:22 <maribu> OK, it should have been /mnt/boot/efi iny case :/
2023-01-20 22:30:37 <psykose> :D
2023-01-20 22:37:38 <maribu> I still cannot get it booting again from the internal nvme
2023-01-20 22:39:13 <maribu> I think I should have switched to BIOS compat mode and syslinux. I kind of have the feeling that grub having to many knobs to fiddle with makes it too easy for me to end up with something that doesn't boot
2023-01-20 22:45:59 <psykose> if you're not using encryption or whatever you can try just efibootmgr the kernel directly and pass some args for initrd
2023-01-20 22:46:27 <psykose> of course that does not get you any answers
2023-01-20 23:34:36 <psykose> hmm, is this expected set -e behaviour https://img.ayaya.dev/jx0SsWCmzs4A
2023-01-20 23:35:06 <psykose> (doesn't fail in &&)
2023-01-20 23:35:26 <psykose> ah
2023-01-20 23:35:41 <psykose> it subshells
2023-01-20 23:35:42 <psykose> yes
2023-01-20 23:38:11 <psykose> ah, https://stackoverflow.com/questions/25794905/why-does-set-e-true-false-true-not-exit
2023-01-20 23:39:53 <skarnet> surrealism in one url
2023-01-20 23:41:15 <psykose> yeah i'm having some fun
2023-01-20 23:41:28 <psykose> context: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10872
2023-01-20 23:41:34 <psykose> i'm about to retire early at this rate
2023-01-20 23:42:53 <skarnet> I see the alpine gitlab is just as bad as the s6-overlay github :D
2023-01-20 23:47:17 <psykose> tbh usually it's worse
2023-01-21 00:49:44 <orbea> psykose: this is why to use || rather than &&
2023-01-21 07:15:05 <ikke> set -o pipefail
2023-01-21 07:15:29 <ikke> psykose: ^
2023-01-21 11:59:05 <nmeum> what's the reasoning behind abuild's "redundant /usr/lib in rpath"-warning? is there any technical downside to a redundant rpath entry or is it just a cosmetic thing?
2023-01-21 12:04:51 <maribu> My boot issue is the initramfs. Copying over the one from the USB results in the kernel booting until the point it fails to mount the nvme drive (which is expected). Rebuilding an initramfs with the exact same setting (even without nvme to rule out a crash from one if that modules) results in the system no longer booting. mkinitfs is in the same version. Some of its dependencies have been updated
2023-01-21 12:08:22 <ikke> maribu: maybe you can compare the contents of the initramfs?
2023-01-21 12:10:20 <ikke> nmeum: "abuild: error or warn if bad rpaths are found"
2023-01-21 12:10:27 <ikke> not much explenation sadlty
2023-01-21 12:10:30 <ikke> sadly
2023-01-21 12:11:15 <ikke> on the other hand, it's just a warning
2023-01-21 12:11:21 <nmeum> the commit is also a decade old
2023-01-21 12:11:23 <ikke> so probably cosmetic?
2023-01-21 12:28:42 <maribu> ikke: There are a number of differences. Pretty much all libs and binaries differ. The symlink /bin/sh to busybox is only present in the working initramfs and /sbin/modprobe differs significantly in the size of the .text section. I have the same version of kmod installed in both, though
2023-01-21 12:33:08 <maribu> The kmod binary also did differ, but reinstalling the kmod package "fixed the issued"
2023-01-21 12:41:10 <ikke> fyi, I did upgrade my laptop on edge yesterday, and it booted fine
2023-01-21 13:13:58 <maribu> How can I do an apk fix for packages that are not in the cache? I know for certain that the files of kmod-libs and zlib are corrupted for some reason on my NVMe. Likely more files are corrupted as well :/
2023-01-21 13:14:41 <ikke> You don't have a network connection?
2023-01-21 13:14:50 <ikke> apk fix would fetch packages from the repo
2023-01-21 13:15:55 <psykose> ikke: heh, does pipefail work on those logic chains? wouldn't have called them pipes
2023-01-21 13:16:07 <ikke> psykose: good question, maybe not
2023-01-21 13:16:10 <ikke> let me check
2023-01-21 13:17:22 <maribu> I  do have a network connection and apk update succeeded. Still, apk fix zlib yields: (1/1) [APK unavailable, skipped] Reinstalling zlib (1.2.13-r0)
2023-01-21 13:18:03 <ikke> and the repo is pointing to edge?
2023-01-21 13:18:15 <ikke> although 3.17 should also have it
2023-01-21 13:22:40 <maribu> apk fix seems to only use the cache (if available). If there is no cache, it will download the apk again. If there is a cache but a given apk is missing, it will skip fixing that one
2023-01-21 13:22:57 <ikke> psykose: it does not work, I believe that's on purpose
2023-01-21 13:23:03 <maribu> Can I for apk to update my cache by downloading apks I have installed that are not in the cache?
2023-01-21 13:23:10 <ikke> I mean, that faill && pass does not exit
2023-01-21 13:23:27 <ikke> maribu: apk cache download
2023-01-21 13:24:43 <maribu> That didn't do anything. I wonder how badly the files on the NVMe are corrupted. fsck has not found anything to complain about, though
2023-01-21 13:26:50 <ikke> apk audit --system?
2023-01-21 13:28:28 <ikke> maribu: does /etc/apk/cache point to something?
2023-01-21 13:28:50 <maribu> I now did an `apk fix $(apk info)` with the cache disabled. That worked. However, it replaced /bin/sh --> /bin/busybox with /bin/sh --> /usr/bin/dash for some reason
2023-01-21 13:33:17 <psykose> that should not happen
2023-01-21 13:46:36 <maribu> apk add busybox-binsh fixed the issue
2023-01-21 13:47:32 <maribu> And after downloading zlib and kmod-libs with wget and installing them by hand it builds again an initramfs that I can boot from. Now also apk fix works for those packages
2023-01-21 13:51:06 <maribu> Note that apk audit --system also didn't detect any issue with zlib and kmod-libs...
2023-01-21 13:51:54 <maribu> Is there a way to list installed packages for which no apk is available anymore (assuming that those may also be correupted and cannot be found with apk audit --system)?
2023-01-21 13:55:42 <psykose> not sure, though no apk being available just implies they're not in the cache, no?
2023-01-21 13:56:50 <maribu> OK, indeed. I assumed set setup-apkcache would wipe the cache if I picked none (and there has been one before).
2023-01-21 13:57:53 <maribu> The issue with dash-binsh was due to me testing the busybox version with the fixed ash. That conflicted with the installed busybox-binsh (which I never explicitly installed), so apk instalied dash-binsh as alternative.
2023-01-21 14:03:12 <psykose> uhh
2023-01-21 14:03:31 <psykose> that doesn't sound correct since they all conflict
2023-01-21 14:03:41 <psykose> hm
2023-01-21 14:05:46 <maribu> I never had busybox-binsh installed explicitly and I have no dependency on it. But I have a lot of things depending on /bin/sh, which was provided by busybox-binsh, but could also (from apk's point of view) be equally well provided by dash-binsh. So it just replaced busybox-binsh with dash-binsh.
2023-01-21 14:07:37 <maribu> I just check rebuilding initramfs with busybox-binsh and the patched busybox from !43365 and it still boots. So it was not a strange side-effect from that patch.
2023-01-21 14:08:25 <Ermine> Lmao MR name
2023-01-21 14:18:17 <psykose> what i mean is that busybox-binsh has the highest priority so the others shouldn't get auto picked when you don't have it added
2023-01-21 14:18:22 <psykose> sounds weird
2023-01-21 14:19:12 <psykose> they all just provide the same thing and the same symlink, so the only thing i can think of is that the priority doesn't matter because of the dependency tree size (dash has the smallest)
2023-01-21 14:19:46 <psykose> i forgot how that worked but if that's the reason i'm not sure how to work around it
2023-01-21 14:39:51 <maribu> I think it takes the explicitly requested packages as hard requirements and tries to resolve them conflict free. If then multiple options remain, the priority is taken into account.
2023-01-21 14:39:51 <maribu> There was no busybox-binsh compatible with the busybox I wantend to install (due to the bumped pkgrel), so it found another way to satisfy the dependencies.
2023-01-21 14:47:44 <psykose> it's a subpackage of busybox so even if you changed anything the new one would exist
2023-01-21 14:48:29 <psykose> unless you removed all the subpackages in that pkgrel bump i suppose
2023-01-21 15:01:24 <maribu> Yes, but I only installed the busybox pkg by path and kept the other subpkgs as they were
2023-01-21 15:24:19 <psykose> ahhhh
2023-01-21 15:24:26 <psykose> okay, think we got that sorted then
2023-01-21 15:24:29 <psykose> you scared me
2023-01-21 15:24:33 <psykose> tbh that could be the other issue
2023-01-21 15:24:43 <psykose> i am not sure if mkinitfs is sh compliant enough for dash
2023-01-21 15:24:51 <psykose> or the init it makes
2023-01-21 15:25:28 <ikke> it uses local
2023-01-21 15:25:33 <ikke> I don't think dash allows that
2023-01-21 15:25:37 <psykose> ye
2023-01-21 15:25:56 <psykose> so.. installing these is guaranteed to break your system if you use mkinitfs init
2023-01-21 15:26:22 <psykose> i should probably add a post-install hook with a really big warning
2023-01-21 15:26:51 <skarnet> dash doesn't implement local? interesting
2023-01-21 15:27:02 <ikke> afaik, dash is strict posix
2023-01-21 15:27:28 <psykose> it has like +1 extension or something and some differing rare semantic
2023-01-21 15:27:43 <psykose> nowhere near the ash extensions of course
2023-01-21 15:28:26 <psykose> i am of course just oh so very slightly regretting implementing the binsh thing :p
2023-01-21 15:28:56 <psykose> if only because it lost maribu here like 10 hours of doing anything more fun like videogames
2023-01-21 15:29:56 <minimal> a quick "shellcheck -s dash" on the init script gave at least one red/error
2023-01-21 15:30:19 <ikke> for what?
2023-01-21 15:30:58 <minimal> In initramfs-init.in line 756:
2023-01-21 15:30:58 <minimal>         ^-- SC2144: -f doesn't work with globs. Use a for loop.
2023-01-21 15:30:58 <minimal> if [ -f /var/cache/misc/*modloop*.SIGN.RSA.*.pub ]; then
2023-01-21 15:32:11 <psykose> el classic one iteration for loop
2023-01-21 15:32:32 <psykose> would probably rather ls | grep that shit or something
2023-01-21 15:32:34 <orbea> ikke: ikke fwiw removing rpath helps for reproducible builds (although some things will break without it)
2023-01-21 15:32:57 <psykose> an rpath of /usr/lib being /usr/lib is reproducible every time
2023-01-21 15:33:07 <ikke> orbea: this is specifically regarding /usr/lib in rpath
2023-01-21 15:33:11 <orbea> ah
2023-01-21 15:33:29 <orbea> i suppose since you dont have lib and lib64
2023-01-21 15:34:42 <minimal> there's also other stuff like:
2023-01-21 15:34:42 <minimal> In initramfs-init.in line 618:
2023-01-21 15:34:42 <minimal> 	url="${url/{UUID\}/$MACHINE_UUID}"
2023-01-21 15:34:42 <minimal>              ^-- SC2169: In dash, string replacement is not supported.
2023-01-21 15:34:58 <ikke> but it allows local?
2023-01-21 15:36:13 <minimal> ikke: the only complaints I see on lines using local are of this type:
2023-01-21 15:36:14 <minimal> In initramfs-init.in line 75:
2023-01-21 15:36:14 <minimal> 	local search_maj_min=$(stat -L -c '%t,%T' $search_dev)
2023-01-21 15:36:14 <minimal>               ^-- SC2155: Declare and assign separately to avoid masking return values.
2023-01-21 15:36:35 <psykose> guess it might nowadays
2023-01-21 15:50:05 <minimal> realised I was using an older version of shellcheck (on a non-Alpine box), more recent version also shows SC2169 ("string replacement" above) as an error, so 2 types of error, total of 3 errors
2023-01-21 16:01:27 <maribu> psykose: No need to worry. The zlib, kmod and kmod-libs package really was corrupted on my NVMe install. I tested replacing /bin/sh with a symlink to busybox by hand and it didn't fix the issue. So there were actually two issues affecting me.
2023-01-21 16:03:24 <psykose> yeah, super unlucky
2023-01-21 16:03:30 <psykose> i haven't had data corruption in a long time
2023-01-21 16:03:31 <maribu> What really gives me shivers is that file corruptions is something that (except for cheap Android devices) I have barely ever have seen file corruptions. And now within the first month of use of my new machine it bite me.
2023-01-21 16:03:57 <ikke> ouch
2023-01-21 16:04:58 <elly> does smartctl have anything to say?
2023-01-21 16:07:57 <minimal> maribu: ext4 or some other fs type?
2023-01-21 16:09:43 <maribu> ext4. I'm afk, but smartctl is indeed a good idea :)
2023-01-21 16:12:32 <minimal> also with nvme-cli installed try "nvme smart-log /dev/nvme0"
2023-01-21 16:18:29 <psykose>  unsafe_shutdowns : 102
2023-01-21 16:18:34 <psykose> it appears i'm playing with fire
2023-01-21 16:21:06 <elly> every night when psykose is done with her computer she just rips the power cable out of the wall
2023-01-21 16:21:09 <elly> no fear
2023-01-21 16:22:00 <psykose> haters will say it's fake
2023-01-21 16:22:11 <psykose> tbf, it is a second hand drive
2023-01-21 16:22:16 <psykose> even if i did like 30 of those
2023-01-21 16:25:43 <minimal> second hand NVME? lol, having flashbacks on trying to help a guy on a different channel with SSDs problems and eventually he changed from saying the drives were "new" to instead saying they were "new to him", turned out the SMART data showed large Power On Hours and Total Data Written figures lol. He'd bought them in a market in Pakistan ;-)
2023-01-21 16:25:50 <elly> my secondhand laptop also has 34 unsafe shutdowns
2023-01-21 16:25:57 <elly> hmm :)
2023-01-21 16:26:54 <elly> power on hours 495 though
2023-01-21 16:26:58 <psykose> power_cycles				: 1157
2023-01-21 16:26:58 <psykose> power_on_hours				: 13398
2023-01-21 16:27:10 <psykose> :)
2023-01-21 16:28:09 <psykose> poor starving alpine developers need to use locally sourced nvme drives purchased FOR CASH with over 1k power cycles smh
2023-01-21 16:28:46 <minimal> you'd see unsafe shutdowns if, for example, a machine locked up and you had to "press and hold down the power button" for it to switch off
2023-01-21 16:30:35 <elly> ya, those are likely all my fault
2023-01-21 16:30:52 <elly> this one is secondhand but was bought from a friend who booted it perhaps twice ever
2023-01-21 16:31:16 <maribu> The NVMe actually came with the new notebook and was bought directly from the HP web store. I'm pretty sure if the NVMe is failing, it is a quality issue rather than a fake drive. But let's see. Maybe it was just a glitch that hopefully never occurs again.
2023-01-21 16:35:10 <maribu> After my experience with HP printers I was quite certain to never buy HP again. But at that discount it was an offer I just couldn't refuse :)
2023-01-21 16:42:22 <psykose> :)
2023-01-21 16:42:31 <psykose> hopefully it's not as bad as it sounds
2023-01-21 16:56:09 <minimal> psykose: well its a SSD, it won't make grinding sounds like a HDD ;-)
2023-01-21 16:57:02 <psykose> :)
2023-01-21 17:18:03 <maribu> 28 power_on_hours and 206 power cycles and percentage_used is 0%. But 79 unsafe_shutdowns and 121 num_err_log_entries is not what I expected. I cannot recall a single unsafe shutdown.
2023-01-21 17:18:32 <psykose> maybe the numbers are drunk, or mean something else, or factory affects it
2023-01-21 17:18:32 <psykose> idk
2023-01-21 17:28:33 <minimal> maribu: have you tried running Smart tests?
2023-01-21 17:42:13 <maribu> nvme device-self-test /dev/nvme0 yields for me: NVMe status: Invalid Field in Command: A reserved coded value or an unsupported value in a defined field(0x2)
2023-01-21 17:43:31 <elly> intriguing
2023-01-21 17:47:13 <psykose> i get the same
2023-01-21 17:47:38 <psykose> but that's not smart tests afaik
2023-01-21 17:52:49 <Saklad5> Would it be possible to add SSHFP records for the GitLab instance?
2023-01-21 17:53:03 <Saklad5> It would save a lot of hassle.
2023-01-21 17:53:43 <Saklad5> This obviously would require using DNSSEC as well, but this is hardly the only reason to do that.
2023-01-21 17:54:14 <minimal> maribu: smartctl -t short /dev/nvme0n1  or smartctl -t long /dev/nvme0n1
2023-01-21 17:55:12 <minimal> then after they finish "smartctl -a /dev/nvme0n1" will show the results toward the end of its output
2023-01-21 17:55:30 <ikke> Saklad5: our dns provider does not support dnssec
2023-01-21 17:55:56 <minimal> also if you run smartd daemon the the system logs will show changes in SMART attribute values
2023-01-21 17:56:18 <Saklad5> ikke: That sounds like an extremely solid reason to change providers, but I'm guessing there's a reason you haven't
2023-01-21 17:56:43 <psykose> mostly that dnssec is boring and a lot of work for little benefit
2023-01-21 17:57:56 <Saklad5> I strongly disagree on all counts, but I won't argue it here. Just keep in mind that it would save the trouble of managing SSH host keys
2023-01-21 17:58:30 <psykose> in what way would it do that
2023-01-21 17:58:57 <Saklad5> SSHFP records
2023-01-21 17:59:13 <psykose> and how do those save the trouble of managing host keys
2023-01-21 17:59:28 <Saklad5> SSH clients check for them when connecting, and use them to verify that the host key is correct for the address
2023-01-21 17:59:34 <Saklad5> Most Git hosting platforms I know of either use SSHFP, are GitHub, or are GitLab.com
2023-01-21 17:59:37 <psykose> i know how they work
2023-01-21 17:59:48 <Saklad5> Then what's your question?
2023-01-21 17:59:57 <psykose> where does the «save the trouble» part come in
2023-01-21 18:00:01 <psykose> currently:
2023-01-21 18:00:04 <psykose> there is a host with sshd
2023-01-21 18:00:06 <psykose> it has host keys
2023-01-21 18:00:08 <psykose> <end>
2023-01-21 18:00:18 <psykose> with all of the above:
2023-01-21 18:00:23 <psykose> there is still a host with sshd
2023-01-21 18:00:26 <psykose> it still has host keys
2023-01-21 18:00:33 <psykose> you now also have dns records to manage
2023-01-21 18:00:36 <psykose> +- move stuff
2023-01-21 18:00:37 <psykose> <end>
2023-01-21 18:00:46 <psykose> so, where is the "trouble saving"
2023-01-21 18:00:50 <ikke> psykose: Saklad5 is mostly talking about clients
2023-01-21 18:00:56 <psykose> ah
2023-01-21 18:01:03 <psykose> sure, for clients it has some benefit
2023-01-21 18:01:10 <minimal> In the past I'd looked into automation of creating/publishing SSHFP DNS entries in my local (home network) DNS when VMs are created
2023-01-21 18:01:13 <Saklad5> Because clients have to go track down where GitLab keeps SSH host keys and manually confirm they have the right server
2023-01-21 18:01:36 <Saklad5> SSHFP records are an implementation of DANE
2023-01-21 18:01:52 <psykose> i've met like three people that do that instead of just connecting, you are number three
2023-01-21 18:01:59 <psykose> :p
2023-01-21 18:02:03 <Saklad5> Who verify host keys?
2023-01-21 18:02:10 <psykose> more or less
2023-01-21 18:02:29 <Saklad5> I feel like that's also a good reason to make it automatic, since people can't be trusted to do it manually
2023-01-21 18:02:30 <minimal> TOFU
2023-01-21 18:03:11 <psykose> i don't think it's any more automatic really, even with the client sshfp support
2023-01-21 18:03:22 <Saklad5> It automates checking
2023-01-21 18:03:42 <minimal> Saklad5: in my local situation I was using cloud-init's phone_home module which does a HTTP/HTTPS POST at end of 1st boot of VMs to then trigger things like SSHFP entries
2023-01-21 18:03:45 <Saklad5> And also uses the DNSSEC root anchor instead of whatever certificate authority is being used for the HTTPS interface
2023-01-21 18:04:33 <Saklad5> Assuming TLSA records aren't used, which is more or less certain right now
2023-01-21 18:05:43 <Saklad5> I actually have SSH configured to call GitHub's API to get the host keys. It's sort of stupid, but so is GitHub not using SSHFP
2023-01-21 18:06:19 <psykose> your threat model includes some scary people i assume
2023-01-21 18:07:31 <psykose> in any case, maybe someday
2023-01-21 18:07:44 <psykose> i'm not the one that manages it and it would require moving from the linode dns to something else i'd guess
2023-01-21 18:07:49 <psykose> unless it was a more varied setup
2023-01-21 18:08:06 <Saklad5> I run my own DNS, it's actually way easier to manage than a web interface
2023-01-21 18:08:19 <ikke> We use terraform to manage DNS
2023-01-21 18:08:52 <Saklad5> Anyway, DNSSEC also increases performance by allowing caches to be much more aggressive without fear of poisoning
2023-01-21 18:09:08 <Saklad5> https://www.rfc-editor.org/rfc/rfc8198
2023-01-21 18:10:47 <psykose> ikke: it does make it easier yeah
2023-01-21 18:12:52 <psykose> Saklad5: anyway, sorry if i sound a bit negative :) the idea is pretty cool, someone will just to find time on it and so on, so most likely it would take a while
2023-01-21 18:13:18 <Saklad5> That's fine, just keep it in mind.
2023-01-21 18:14:17 <ikke> If it was something easy to add, I would do it, but completely switch dns provider is something else
2023-01-21 18:15:12 <Saklad5> …Actually, no, this is a bigger problem: https://gitlab.alpinelinux.org/help/instance_configuration#ssh-host-keys-fingerprints
2023-01-21 18:15:27 <Saklad5> I don't think I've ever actually seen that on a GitLab instance before
2023-01-21 18:16:18 <ikke> We build it from source on alpine linux, so we probably need to set it somewhere
2023-01-21 18:16:34 <psykose> probably just need the openssh utilities in the same place
2023-01-21 18:16:43 <ikke> You are the first to mention it
2023-01-21 18:16:54 <Saklad5> That is depressing
2023-01-21 18:17:09 <psykose> i did mean it by 3rd person :p
2023-01-21 18:17:28 <psykose> the 2nd is some other person here, and the 1st is the musl maintainer
2023-01-21 18:20:17 <Saklad5> It's one thing to make people manually verify keys, but it is another thing entirely to make it impossible
2023-01-21 18:21:06 <ikke> Need to figure out where to configure it
2023-01-21 18:22:35 <psykose> ikke: is the keyscan in question already there
2023-01-21 18:23:50 <ikke> psykose: isn't that instruction meant for the user
2023-01-21 18:23:57 <psykose> ah
2023-01-21 18:24:03 <psykose> i am real bad at reading
2023-01-21 18:24:03 <ikke> "No keys available, use ssh-keyscan yourself to find them"
2023-01-21 18:24:22 <Saklad5> The keyscan is TOFU, and TOFU is a waste of time
2023-01-21 18:39:13 <maribu> minimal: Thx for the pointer. I see no indication of success or error, or of any activity after triggering the test :/
2023-01-21 18:39:57 <skarnet> I agree that tofu is a waste of time, if you don't want meat there are excellent vegan dishes
2023-01-21 18:40:08 <psykose> tofu is pretty good
2023-01-21 18:40:21 <psykose> i will say preparing that shit is annoyingly fiddly though
2023-01-21 18:40:54 <minimal> maribu: when you start a SMART test the output tells you how long it will take (i.e. a short test might take seconds/a couple of minutes, a long test might take far longer)
2023-01-21 18:41:45 <minimal> I prefer fondue to tofu ;-)
2023-01-21 18:41:48 <ikke> I cannot find anything on where to set it or how gitlab finds it
2023-01-21 18:42:53 <psykose> me either
2023-01-21 18:43:13 <ikke> The page gets it from ssh_info = @instance_configuration.settings[:ssh_algorithms_hashes]
2023-01-21 18:43:28 <ikke> which comes from app/models/instance_configuration.rb
2023-01-21 18:45:17 <ikke>     File.join(SSH_ALGORITHMS_PATH, "ssh_host_#{algorithm.downcase}_key.pub")
2023-01-21 18:45:34 <psykose> well well
2023-01-21 18:45:48 <psykose> SSH_ALGORITHMS_PATH = '/etc/ssh/'
2023-01-21 18:45:50 <ikke> yes
2023-01-21 18:45:55 <ikke> So need to make the keys available there
2023-01-21 18:46:00 <ikke> sshd runs in a different container
2023-01-21 18:46:11 <psykose> yep
2023-01-21 18:50:56 <maribu> minimal: Just to be sure I'm not stupid: I would run `sudo smartctl -t short /dev/nvme0` and that tool should print more than the copyright, "NVMe device successfully opened", and a pointer that I should use "'smartctl -a' (or '-x')" to get more info?
2023-01-21 18:51:52 <maribu> (The exit code is 0.)
2023-01-21 18:54:44 <maribu> In any case: git fsck on all my small and larger repositories did not find any issue. Maybe I really forgot to plug in the notebook in time some time ago after updating zlib, kmod and kmod-libs. Only yesterday when rebuilding the initramfs that started to bite me.
2023-01-21 18:58:03 <psykose> -t short starts the test, then -a will give you info after
2023-01-21 18:59:19 <psykose> idk why there's no foreground "just test it and show stuff" option, would be nice
2023-01-21 18:59:56 <minimal> psykose: I guess because extended offline tests would take quite some time
2023-01-21 19:00:10 <psykose> idk, i ran -t long and it finished instantly
2023-01-21 19:00:54 <minimal> maribu: if you run (as root) smartctl -a /dev/nvme0 then in the output towards the end is a section "SMART Self-test log", that shows the history of any tests run in the past
2023-01-21 19:01:27 <psykose> nvm this log is quite nonexistent
2023-01-21 19:02:29 <minimal> maribu: if I run "smartctl --test=short /dev/sda" then the output says "Please wait 1 minutes for the test to complete." as well as "Test will complete after Sat Jan 21 19:02:13 2023 GMT"
2023-01-21 19:03:46 <minimal> a long test is more involved and will take some time (and could also be aborted if the machine is doing other significant disk activity)
2023-01-21 19:04:22 <minimal> psykose: you did a long test and the output said it would complete in seconds?
2023-01-21 19:04:22 <maribu> I guess then the NVMe doesn't self testing. I also see no history of conducted tests in smartctl -a
2023-01-21 19:04:45 <psykose> it didn't say anything so i guess this doesn't work on nvme
2023-01-21 19:10:58 <minimal> hmm, seems for NVME devices it would be "nvme device-self-test /dev/nvme0 -n <NUM>" where NUM is "1" for short test and "2" for extended test
2023-01-21 19:11:25 <minimal> and "nvme self-test-log /dev/nvme0" to check the log
2023-01-21 19:11:57 <minimal> I though smartctl also supported running NVME tests, apparently not though it does retrieve NVME SMART attributes and their values
2023-01-21 19:14:54 <minimal> there are also vendor-specific extensions that may be useful, "nvme --help" shows them at end, no vendor settings for Samsung however (the brand of drive I'm looking at here)
2023-01-21 19:18:27 <psykose> it displays wdc (western digital) but still fails with either 1/2
2023-01-21 19:18:45 <psykose> https://img.ayaya.dev/j2n7wRvftK45
2023-01-21 19:22:18 <minimal> to be honest I've never tried testing a NVME device (only have 1 here) but I've used smartctl tests with HDDs and SATA SSDs (from memory) often in the past
2023-01-21 19:22:40 <psykose> ok, it's device specific
2023-01-21 19:22:43 <psykose> https://github.com/linux-nvme/nvme-cli/issues/731
2023-01-21 19:22:46 <psykose> e.g.
2023-01-21 19:22:49 <psykose> > The device does not support the optional self-test command.
2023-01-21 19:23:10 <psykose> so i guess by nvme spec a ton of shit is optional, which makes sense, because the nvme-cli has like 50 commands
2023-01-21 19:23:22 <psykose> making selftests optional is.. certainly something, but i guess it is what it is
2023-01-21 19:23:31 <psykose> i built latest master libnvme+nvme-cli and it's the same
2023-01-21 19:24:09 <psykose> so i guess just gotta really read those spec sheets if one cares, when buying flash
2023-01-21 19:24:24 <psykose> and all of us are unfortunate enough to not have this (wdc drive, samsung, whatever is in that hp laptop)
2023-01-21 19:24:25 <psykose> :)
2023-01-21 19:24:41 <psykose> i'll bet "pro" drives have this
2023-01-21 19:28:12 <minimal> so I guess for maribu it is more a matter of whether the SMART attribute "Media and Data Integrity Errors" is non-zero
2023-01-21 19:28:32 <minimal> or "Error Information Log Entries" is non zero
2023-01-21 20:27:18 <maribu> media_errors is indeed zero, num_err_log_entries is 121. `nvme error-log /dev/nvme0` contains 63 instances of "Successful Completion: The command completed without error" and one instance of "Invalid Field in Command: A reserved coded value or an unsupported value in a defined field"
2023-01-21 20:28:42 <maribu> Interestingly, the error count is listed for every error log entry. It remains at 0 until the last entry (the invalid field in command entry), in which it jumps to 121. It must be fun for engineers to debug these devices :)
2023-01-21 20:32:32 <minimal> maribu: think of the film Airplane 2 when the pilot says "That's strange!" and you see a console light labelled "strange" illuminated :-)
2023-01-21 20:33:04 <maribu> :D
2023-01-21 20:34:08 <maribu> This one? https://qph.cf2.quoracdn.net/main-qimg-251e6d383de13762c775d19b1a4d053c
2023-01-21 20:34:51 <maribu> Given that the other indicators are "weird' an "bizarre", "strange" seems to be a rather mild issue :D
2023-01-21 20:34:59 <minimal> yupe ;-)
2023-01-21 20:35:05 <ikke> lol
2023-01-21 20:35:31 <psykose> ikke: have you managed to configure the /etc/ssh mounting
2023-01-21 20:35:47 <ikke> psykose: I didn't even need to mount it, just symlink it
2023-01-21 20:35:57 <ikke> it works  on gitlab-test, but I guess it's cached on gitlab
2023-01-21 20:36:01 <psykose> aye
2023-01-21 20:36:08 <psykose> prolly needs an ole reload prod
2023-01-21 20:36:11 <ikke> yes
2023-01-21 20:36:31 <psykose> also i was doing some local testing
2023-01-21 20:36:44 <psykose> ruby 3.2 with yjit is like 40+% faster
2023-01-21 20:36:58 <ikke> I had some issues when I tried latest ruby
2023-01-21 20:37:05 <maribu> OK, now I have an excuse to spin up KiCad again. I really need to design USB gadget with those indicators and place that on top of my monitor
2023-01-21 20:37:18 <psykose> 3.2 compat itself probably needs some gitlab fixes yeahg
2023-01-21 20:37:31 <ikke> there is an issue open on gitlab they are still working on it
2023-01-21 20:37:35 <psykose> mhm
2023-01-21 20:37:42 <ikke> even for 3.1
2023-01-21 20:37:45 <ikke> or 3.0
2023-01-21 20:38:01 <ikke> Maybe you saw I made the ruby version easily switchable
2023-01-21 20:38:07 <ikke> That's when I was testing
2023-01-21 20:38:48 <psykose> i forget which repo it was
2023-01-21 20:38:59 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/gitlab
2023-01-21 20:39:06 <psykose> thanksthanks
2023-01-21 20:39:24 <ikke> I'll push the symlink change I made
2023-01-21 20:40:53 <psykose> ok, checked and same images for 3.2 have it enabled
2023-01-21 20:41:09 <psykose> so, when/if gitlab reaches 3.2, you can pass --enable-yjit to the ruby opts
2023-01-21 20:41:15 <psykose> if there's a way to pass that
2023-01-21 20:41:20 <vkrishn> just in case it got missed, https://arstechnica.com/?p=1910644
2023-01-21 20:41:38 <vkrishn> they are currently no in aports
2023-01-21 20:41:43 <vkrishn> not^
2023-01-21 20:43:07 <psykose> indeed they're not
2023-01-22 03:23:35 <pj[m]> alpine clang when
2023-01-22 03:25:02 <psykose> https://pkgs.alpinelinux.org/package/edge/main/x86_64/clang15
2023-01-22 03:27:34 <pj[m]> alpine built with clang when
2023-01-22 10:21:03 <Shiz> pj[m]: 6 years ago :)
2023-01-22 10:21:18 <Shiz> https://github.com/shizmob/aports/tree/system-llvm-elftoolchain
2023-01-22 10:47:56 <pj[m]> wack
2023-01-22 11:25:02 <nmeum> someone should write a proper TSC proposal for changing the default compiler to clang
2023-01-22 11:25:19 <nmeum> I have that on my to-do list but haven't gotten around to doing so
2023-01-22 11:26:21 <nmeum> our fortify-headers implementation currently doesn't support clang but the chimera linux people have a patchset for that https://github.com/chimera-linux/fortify-headers
2023-01-22 11:26:45 <nmeum> maybe something we could also backport regardless of whether clang is the default compiler
2023-01-22 11:40:26 <nmeum> !43463 (untested though)
2023-01-22 20:10:12 <sam_> oh fortify
2023-01-22 20:51:02 <psykose> nmeum: is there a need for it?
2023-01-22 20:51:24 <psykose> it would be quite the effort to implement, especially with our amount of architecturess
2023-01-22 20:52:13 <psykose> also half the fun of it is lld and that does not support s390x
2023-01-23 07:44:48 <vkrishn> lang julia did not get traction in AL ? read its got huge support from formula1 company.
2023-01-23 07:45:54 <vkrishn> tree-sitter-julia gets build though
2023-01-23 07:50:44 <psykose> the language is a mess but aside from that it was removed 4.5 years ago
2023-01-23 08:08:37 <nmeum> psykose: a need for the fortify patch or for clang being the default compiler?
2023-01-23 08:08:42 <psykose> clang
2023-01-23 08:09:39 <nmeum> I personally think it would have some benefits (easier cross compilation, hopefully requires a smaller patchset than gcc, …) but I am aware that it is a lot of work
2023-01-23 08:10:28 <nmeum> also: had to interact with the gcc codebase a bit during my upstreaming of our gcc-go patches and the gcc code is just beyond horrible in some places and what I have seen from clang so far looks much better in this regard
2023-01-23 08:10:52 <psykose> it already works almost entirely with no patches, so yes
2023-01-23 08:11:41 <psykose> difficulty in transition is the real issue.. if it was a new distro the decision is already made
2023-01-23 08:13:38 <psykose> i've personally also had way more issues with binutils than with gcc, so lld is the real win :p
2023-01-23 08:13:58 <psykose> unless we count the 2GB compilation jobs an issue, then sure, gcc is by far the worst thing in the bunch
2023-01-23 08:54:20 <Habbie> psykose, thanks for bumping pdns-recursor!
2023-01-23 09:06:14 <ikke> Habbie: didn't check now, but I think it was not backported to 3.17 yet? 
2023-01-23 09:06:20 <Habbie> good call
2023-01-23 09:06:22 <Habbie> i will check
2023-01-23 09:06:30 <Habbie> only one, right? no 3.16?
2023-01-23 09:07:54 <ikke> For community, only 3.17 is supported 
2023-01-23 09:08:01 <Habbie> as i thought, thanks
2023-01-23 09:08:45 <Habbie> ok, the version in 3.17 is not affected
2023-01-23 09:08:47 <Habbie> it was a very new bug
2023-01-23 09:08:51 <Habbie> but thanks for the hint
2023-01-23 09:15:20 <ikke> OK good 
2023-01-23 09:21:31 <psykose> there's nothing to backport indeed
2023-01-23 09:21:48 <psykose> Habbie: np, saw the announcement a few seconds after it was made and thought i might as well :)
2023-01-23 09:22:00 <Habbie> i see that the secfixes format does not allow us to express this
2023-01-23 09:22:11 <Habbie> psykose, very good, i was mightily distracted on friday
2023-01-23 09:22:13 <psykose> it's per branch and greater than
2023-01-23 09:22:17 <Habbie> ack
2023-01-23 09:22:23 <psykose> so it doesn't need more expression given that
2023-01-23 09:22:28 <Habbie> fair
2023-01-23 09:22:36 <psykose> assuming things don't upgrade by downgrading, that is
2023-01-23 09:22:42 <psykose> then.. a bit broken
2023-01-23 09:22:46 <Habbie> sure
2023-01-23 09:28:31 <ikke> If the CPE indicates it's not culnerable, there is no need for a secfix entry 
2023-01-23 09:28:39 <ikke> vulnerable 
2023-01-23 09:29:53 <psykose> that too
2023-01-23 09:30:03 <Habbie> ah of course, those work together
2023-01-23 10:13:55 <Habbie> boost is versioned, but boost-dev is unversioned - so that builds always happen against the newest, but existing packages keep working?
2023-01-23 10:30:34 <psykose> so that during the rebuild which takes forever the old boost doesn't dissappear and render everything uninstallable until everything is rebuilt against the new one
2023-01-23 10:30:35 <psykose> i guess
2023-01-23 10:30:41 <psykose> the old one is removed right after
2023-01-23 10:31:40 <Habbie> right, just for the rebuild, got it
2023-01-23 16:31:57 <teiresias> I seem to have hit an odd bug.  On a host where I build some personal Alpine packages, abuild rootbld fails when trying to create package users and groups with the following message: "abuild-addgroup: User chris is not a member of group abuild".  I'm definitely in the abuild group though.
2023-01-23 17:31:25 <WhyNotHugo> Any comments on this update to imv? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43393
2023-01-23 17:31:31 <WhyNotHugo> Is Drew still active as maintainer?
2023-01-23 17:31:49 <WhyNotHugo> (gitlab mentions he can't actually merge this MR)
2023-01-23 18:00:35 <skarnet> WhyNotHugo: being a maintainer and having merge permissions on aports are two different things :)
2023-01-23 18:01:16 <skarnet> but you can ping him - ddevault ^ - so he looks at your MR and approves, then a developer can merge it
2023-01-23 18:01:32 <ddevault> must have missed the notice
2023-01-23 18:01:40 <ddevault> gave it my seal of approval
2023-01-23 18:01:48 <skarnet> *happy seal noises*
2023-01-23 18:11:46 <ikke> merged
2023-01-23 18:59:00 <WhyNotHugo> skarnet: Oh, I though maintainers of packages in community could merge the changes in themselves.
2023-01-23 23:50:53 <omni> it says "Approval is optional" but how can it be when it is not possible?
2023-01-23 23:51:02 <omni> (there used to be a button)
2023-01-24 05:22:22 <psykose> new gitlab broke it
2023-01-24 05:22:27 <psykose> teiresias: groups don't work in rootbld
2023-01-24 05:23:39 <teiresias> How odd.
2023-01-24 05:24:13 <teiresias> So if I wanna rootbld, I need to gain root privileges then?
2023-01-24 06:01:57 <Ariadne> no
2023-01-24 06:02:23 <Ariadne> but you will need abuild-rootbld installed
2023-01-24 06:59:24 <teiresias> I have it, and abuild rootbld works fine, except in this case where the build calls abuild-addgroup to add a new group.
2023-01-24 14:33:15 <Piraty> WhyNotHugo: similar with void-packages really
2023-01-24 14:58:27 <eddsalkield> could someone take a look at my package for liquid-dsp and help me work out what I need to do to get it merged?: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40672
2023-01-24 14:59:22 <eddsalkield> there's an upstream issue with the name of libliquid.a.1.5, but I don't know if this blocks merging
2023-01-24 15:04:51 <WhyNotHugo> Anything blocking this update? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/42949
2023-01-24 15:14:03 <psykose> eddsalkield: it's an invalid name
2023-01-24 15:14:08 <psykose> you can rename it or whatever else
2023-01-24 15:40:20 <eddsalkield> okay thanks
2023-01-24 17:02:41 <hjaekel> Thank you psykose for merging GDAL. Something is still wrong with my sub package gdal-driver-all. When I install it, I get "conflicts: gdal-driver-all-3.6.2-r0[gdal-driver-all]". What did I do wrong?
2023-01-24 17:09:13 <ikke> Hj
2023-01-24 17:09:49 <ikke> hjaekel: sounds like something provides an inversioned gdal-driver-all? 
2023-01-24 17:09:57 <ikke> Ie a virtual package? 
2023-01-24 17:10:48 <ikke> gdal-driver-all (unversioned, virtual package) conflicts with gdal-driver-all-3.6.2-r0 (concrete, versioned) package
2023-01-24 17:11:14 <ikke> (virtual packages can also be versioned, afaik that should not be a problem)
2023-01-24 17:11:20 <hjaekel> It was my intention to create a virtual package gdal-driver-all, that just depends all drivers. Seems I did it wrong
2023-01-24 17:13:59 <ikke> It's already a subpackage, so I don't think you need a provides
2023-01-24 17:14:09 <psykose> hjaekel: fixed
2023-01-24 17:14:47 <psykose> it was most likely the provides= indeed
2023-01-24 17:14:54 <ikke> psykose: d'oh
2023-01-24 17:15:00 <ikke> You confused me lol
2023-01-24 17:15:09 <psykose> aw
2023-01-24 17:15:11 <psykose> sowwy
2023-01-24 17:15:15 <ikke> I wanted to link hjaekel to the line :D
2023-01-24 17:15:41 <ikke> supprised that it was not there
2023-01-24 17:16:27 <hjaekel> thank you for your support, you are amazing :)
2023-01-24 17:17:35 <psykose> no u
2023-01-24 17:42:30 <le_dude> hello
2023-01-24 17:42:39 <le_dude> I have a question
2023-01-24 17:42:48 <le_dude> first of all thank you very much for your hard work
2023-01-24 17:43:13 <le_dude> it is very much appreciated
2023-01-24 17:43:57 <le_dude> ehm
2023-01-24 17:44:15 <le_dude> I am still new to Linux so sry when it is a stupid question my linux gods
2023-01-24 17:44:54 <le_dude> I have seen this
2023-01-24 17:44:55 <le_dude> https://github.com/rancher/k3os
2023-01-24 17:45:09 <le_dude> it is based on alpine linux
2023-01-24 17:45:23 <le_dude> wenn I would like to archive something similar
2023-01-24 17:45:38 <le_dude> only for freePBX / Raspberry Pi
2023-01-24 17:46:03 <le_dude> what would be the way with the least effort?
2023-01-24 17:46:12 <le_dude> thank you
2023-01-24 18:28:58 <psykose> ikke: smh capitalising my nickname
2023-01-24 18:29:21 <ikke> psykose: oh, sowwy
2023-01-24 18:29:31 <psykose> just jokin :)
2023-01-24 18:32:31 <ikke> fixed ;)
2023-01-25 15:49:12 <ncopa> whoaa! they finally remove gslice allocator upstream! 7 years old issue closed. ~3000 lines of code removed 
2023-01-25 15:49:25 <ncopa> in glib \o/
2023-01-25 15:51:48 <donoban> hehe "it is never too late..." :D
2023-01-25 17:18:52 <lucidiot> and meanwhile, this bug will be allowed to vote this year https://bugs.mysql.com/bug.php?id=11472
2023-01-25 17:20:33 <ikke> they grow up so fast
2023-01-25 17:51:36 <minimal> it still can't (legally) drink yet (in USA) can it? lol
2023-01-25 17:54:39 <lucidiot> nope, it will be able to in most of europe soon though
2023-01-25 17:55:29 <donoban> lol
2023-01-25 18:30:29 <q66> it can already drink in several european countries
2023-01-25 18:31:08 <q66> in austria, germany, switzerland, belgium and portugal
2023-01-25 18:31:19 <q66> also in denmark
2023-01-25 19:20:24 <omni> prost!
2023-01-26 12:17:17 <ddevault> pop open python3 and run 'from pygit2 import Repository'
2023-01-26 12:17:20 <ddevault> failing for everyone or just me?
2023-01-26 12:21:37 <lotheac> ImportError: cannot import name 'Repository' from 'pygit2' (unknown location)
2023-01-26 12:21:47 <ddevault> thanks
2023-01-26 19:04:45 <kreyren> https://gitlab.alpinelinux.org/alpine/aports/-/issues/14588 did anyone took at look at this yet?
2023-01-26 19:04:53 <kreyren> kinda breaking official port for olimex teres-1 atm @_@
2023-01-26 19:08:55 <craftyguy> kreyren: if you think it's a regression in mesa, then bisect mesa so you can blame the commit that caused the regression. then it can be reported upstream easily, etc
2023-01-26 19:11:02 <kreyren> i would if i could actually make an account on the hugging freedesktop to blame the mesa guy who submitted the regression
2023-01-26 19:17:16 <craftyguy> that's not what I mean
2023-01-26 19:17:45 <craftyguy> AFAIK, no one has actually bisected mesa to any specific patch, there's just some speculation that a patch may have caused it, right?
2023-01-26 19:39:13 <bl4ckb0ne> theres a mailing list and #dri-devel on oftc to complain
2023-01-26 19:39:38 <psykose> bl4ckb0ne: help i upgrade mesa and didn't get +100% fps
2023-01-26 19:39:51 <bl4ckb0ne> rtfm
2023-01-26 19:40:06 <craftyguy> lol
2023-01-26 19:40:47 <craftyguy> just don't complain to this Mesa, they'll probably be confused: https://www.mesaaz.gov/
2023-01-26 19:41:11 <ikke> access denied
2023-01-26 19:41:21 <craftyguy> wow really?
2023-01-26 19:41:37 <psykose> access denied
2023-01-26 19:41:40 <craftyguy> https://en.wikipedia.org/wiki/Mesa%2C_Arizona
2023-01-26 19:41:40 <alpine-meetbot> [wikipedia] Mesa, Arizona | "Mesa ( MAY-sə) is a city in Maricopa County, in the U.S. state of Arizona. It is the most populous city in the East Valley section of the Phoenix Metropolitan Area. It is bordered by Tempe on the west, the Salt River Pima-Maricopa Indian Community on the north, Chandler and Gilbert on the south along with Queen Creek, and Apache Junction on the east.Mesa is the third-largest city in Arizona after […]"
2023-01-26 19:41:51 <psykose> but only via v6, v4 works fine
2023-01-26 19:43:56 <craftyguy> well it was a bad joke, so consider yourself lucky if it didn't load :P
2023-01-26 19:45:19 <psykose> :)
2023-01-26 19:55:55 <craftyguy> psykose: congrats!
2023-01-26 19:56:34 <bl4ckb0ne> gz psykose 
2023-01-26 19:56:35 <psykose> thanks!
2023-01-26 20:00:11 <Misthios> gj
2023-01-26 21:38:09 <skarnet> psykose: grats! what's your preferred currency for corruption?
2023-01-26 21:40:26 <psykose> physical headpats
2023-01-26 21:41:22 <skarnet> can do
2023-01-26 21:48:15 <bl4ckb0ne> so how much headpat to accept glibc
2023-01-26 21:48:19 <bl4ckb0ne> and systemd
2023-01-26 21:49:06 <psykose> it's already there
2023-01-26 21:49:09 <psykose> just install docker
2023-01-26 21:51:53 <bl4ckb0ne> whats docker, is that the system made around alpinelinux?
2023-01-26 22:01:09 <Ermine> psykose: congrats!
2023-01-26 23:47:56 <sam_> psykose: i'm seeing about starting a possbile linux distros ml
2023-01-26 23:47:59 <sam_> will keep you posted
2023-01-26 23:48:06 <sam_> also i dont know what we're congratulating but congrats bestie
2023-01-26 23:48:29 <ptrc> sam_: https://lists.alpinelinux.org/~alpine/devel/%3CCA%2BcSEmMAiEPvFo37DDKVLv6_mZez23NXopwseCBvRbEtouRwqw%40mail.gmail.com%3E
2023-01-26 23:48:30 <ptrc> :p
2023-01-26 23:48:47 <sam_> very good
2023-01-26 23:48:57 <psykose> sam_: ah yes i recall you talking about that
2023-01-26 23:49:11 <psykose> still waiting for my VIP invite 😠
2023-01-26 23:49:28 <psykose> Ermine: thankies
2023-01-27 00:25:52 <bl4ckb0ne> you need to be important to get a VIP invite :p
2023-01-27 00:28:54 <psykose> true
2023-01-27 00:28:57 <psykose> rip
2023-01-27 00:31:31 <bl4ckb0ne> we should make our own cool kid chan/ml an laugh at the popular behind their backs
2023-01-27 01:13:00 <skarnet> how about inviting Very Interesting People instead of Very Important ones
2023-01-27 01:15:13 <bl4ckb0ne> or very inapropriate packagers
2023-01-27 16:53:38 <Piraty> sam_: what for?
2023-01-27 19:28:45 <ikke> Going to upgrade gitlab in a couple of minutes
2023-01-27 19:33:42 <ikke> Alright, gitlab is back
2023-01-27 19:51:21 <ikke> psykose: what's the easiest way to test rust fetch?
2023-01-27 19:51:44 <psykose> `cargo fetch` i guess after going to the folder
2023-01-27 20:10:21 <ikke> hmm, cargo fetch in a container on the same ci host returns immediately
2023-01-27 20:18:30 <psykose> sounds non hanging then
2023-01-27 20:18:43 <psykose> could just run abuild -r on apk-polkit-rs then
2023-01-27 20:44:13 <ikke> Seems to continue
2023-01-27 20:46:02 <psykose> weird
2023-01-27 20:46:09 <psykose> not sure why it hung in ci repeatedly
2023-01-27 20:50:27 <elly> for chromium I'm not sure angle-wayland-include.patch does anything
2023-01-27 20:52:02 <elly> it basically serves to add $wayland_gn_dir/include/protocol to angle-vulkan's include path, but... if that's necessary surely it's necessary upstream
2023-01-27 20:53:44 <psykose> no, upstream doesn't do the third-party unbundling
2023-01-27 20:54:18 <psykose> it's https://bugs.chromium.org/p/angleproject/issues/detail?id=7582
2023-01-27 21:00:08 <elly> so the difference is that downstream, vulkan_wayland_include_dirs is undefined?
2023-01-27 21:03:46 <psykose> you'd know gn more than me
2023-01-27 21:03:56 <psykose> but yes, some replacement doesn't include some system dir i guess
2023-01-27 21:04:21 <elly> hum
2023-01-27 21:05:09 <elly> I can probably fix that in angle itself
2023-01-27 21:14:25 <elly> reproducing it is complicated by my not having a wayland system
2023-01-27 21:18:57 <bl4ckb0ne> anybody getting the scrollwheel writing garbage in foot after opening vim
2023-01-27 21:19:05 <bl4ckb0ne> im _this_ close to switch to vscode
2023-01-27 21:20:17 <psykose> elly: it's not related to being on wayland, just building it with wayland support
2023-01-27 21:20:41 <psykose> bl4ckb0ne: not anymore since the recent ncurses upgrades
2023-01-27 21:20:47 <bl4ckb0ne> i updated
2023-01-27 21:21:23 <psykose> what was your TERM again
2023-01-27 21:23:24 <bl4ckb0ne> foot-extra
2023-01-27 21:23:32 <bl4ckb0ne> oh nice there's also a lapack-liblapack mismatch
2023-01-27 21:23:36 <bl4ckb0ne> ughhhhhhhhhhhhhhhhhhhhhhhhhhhh
2023-01-27 21:23:54 <psykose> is there
2023-01-27 21:24:02 <bl4ckb0ne> (yes)
2023-01-27 21:24:12 <bl4ckb0ne> 
ACTION goes into the wood to scream

2023-01-27 21:24:26 <psykose> show what you got
2023-01-27 21:24:32 <psykose> also try regular =foot term
2023-01-27 21:24:35 <bl4ckb0ne> 
ACTION unzips

2023-01-27 21:24:37 <bl4ckb0ne> jk 
2023-01-27 21:25:04 <bl4ckb0ne> hey it works
2023-01-27 21:25:05 <elly> oh god angle is impossible to develop on
2023-01-27 21:25:07 <bl4ckb0ne> 
ACTION yeets configs

2023-01-27 21:25:14 <elly> another gclient project
2023-01-27 21:25:21 <bl4ckb0ne> will send a fix for the liblapack stuff
2023-01-27 21:25:26 <bl4ckb0ne> libsurvive uses it
2023-01-27 21:25:32 <psykose> just show it because i prolly know more about how to fix it
2023-01-27 21:25:58 <psykose> ah i see
2023-01-27 21:26:21 <bl4ckb0ne> show what
2023-01-27 21:26:40 <psykose> it links libcblas but that only comes from netlib lapack blas
2023-01-27 21:26:46 <psykose> but then lapacke from openblas
2023-01-27 21:26:49 <psykose> sure i'll sort it
2023-01-27 21:27:47 <bl4ckb0ne> i dont mind taking care of it after sorting my shits
2023-01-27 21:32:00 <psykose> hm, how do you run into a runtime issue
2023-01-27 21:32:03 <psykose> just so i make sure
2023-01-27 21:33:51 <bl4ckb0ne> on installingh
2023-01-27 21:34:00 <bl4ckb0ne> hold on
2023-01-27 21:34:03 <psykose> show error then
2023-01-27 21:34:16 <bl4ckb0ne> yes yes gimme a sec
2023-01-27 21:34:38 <bl4ckb0ne> > ERROR: liblapack-0.3.21-r3: trying to overwrite usr/lib/liblapack.so.3 owned by lapack-3.11-r0.
2023-01-27 21:34:44 <bl4ckb0ne> when you install lapack and liblapack
2023-01-27 21:35:07 <psykose> yeah they conflict
2023-01-27 21:35:08 <psykose> but hmm
2023-01-27 21:35:14 <bl4ckb0ne> im installing libsurvive, which depends on lapack
2023-01-27 21:35:24 <psykose> it depends on either
2023-01-27 21:35:31 <psykose> ah, no
2023-01-27 21:35:32 <psykose> right
2023-01-27 21:40:44 <elly> psykose: well, good news and bad news
2023-01-27 21:40:51 <elly> good news, this patch won't be relevant any more in new chromium
2023-01-27 21:40:54 <elly> bad news, https://bugs.chromium.org/p/chromium/issues/detail?id=1385736
2023-01-27 21:41:43 <elly> will probably want to just use chromium's libwayland
2023-01-27 21:42:28 <psykose> sounds fine
2023-01-27 21:43:27 <elly> we could switch now if we wanted I think
2023-01-27 21:44:04 <bl4ckb0ne> chromium has its own libwayland?
2023-01-27 21:44:08 <elly> in tree, yeah
2023-01-27 21:44:13 <elly> chromium vendors every dependency practically
2023-01-27 21:44:19 <elly> and the APKBUILD un-vendors some of them
2023-01-27 21:44:50 <bl4ckb0ne> lovely
2023-01-27 21:45:35 <elly> ya, well
2023-01-27 21:45:43 <elly> so it goes developing programs with lots of deps on linux sometimes
2023-01-27 21:47:20 <psykose> bl4ckb0ne: should be fixed after the lapack rebuild
2023-01-27 21:47:28 <bl4ckb0ne> neat thanks
2023-01-27 21:48:10 <bl4ckb0ne> wew and a vim update
2023-01-27 21:48:31 <elly> I really wish that we more consistently tracked *why* we have these patches
2023-01-27 21:49:04 <psykose> the patch-source links usually make it pretty clear
2023-01-27 21:49:07 <bl4ckb0ne> we should just drop chromium and go raise sheeps in the highland
2023-01-27 21:49:09 <psykose> i can comment every single one if you want
2023-01-27 21:49:26 <elly> psykose: that would be pretty useful, especially if (where applicable) they were linked to chromium bugs
2023-01-27 21:49:58 <psykose> i'm rebuilding without that wayland one rn and it seems to not have failed yet
2023-01-27 21:50:02 <psykose> maybe it's actually stale
2023-01-27 21:59:39 <elly> that'd be nice because if it isn't I will be pretty puzzled about how it does anything
2023-01-27 21:59:46 <elly> it is setting those values to what I think are their defaults
2023-01-27 22:12:06 <psykose> elly: did you ever get that quiche size thing checked out
2023-01-27 22:12:12 <psykose> i remember you baited some quiche developer into it
2023-01-27 22:31:01 <skarnet> if the quiche is too big it will be burnt on the outside and soggy at the center, the only workaround is a fan oven, and even then
2023-01-27 22:33:12 <psykose> :)
2023-01-27 22:33:16 <psykose> i want food
2023-01-27 22:33:42 <ikke> fooood
2023-01-27 22:33:43 <skarnet> who doesn't tbh
2023-01-27 22:33:59 <bl4ckb0ne> im ok
2023-01-27 22:36:57 <bl4ckb0ne> skarnet: the trick is to do mini quiches and stack them
2023-01-27 22:37:06 <ptrc> does anyone know why `apk verify` checks the name of the key file with the one in /etc/apk/keys? it's literally the same key, just with a different filename
2023-01-27 22:37:28 <skarnet> bl4ckb0ne: now you understand how I write software
2023-01-27 22:37:40 <bl4ckb0ne> that explains many things
2023-01-27 22:41:55 <ikke> ptrc: it's just how it matches what key to use to check
2023-01-27 22:43:13 <ptrc> mm, i guess it makes sense.. i just wish the message was a bit more helpful than "UNTRUSTED signature"
2023-01-27 22:43:34 <ptrc> spent way too much time reading apk files with tar to realize what the issue is
2023-01-27 22:46:23 <ikke> I ran into that as well
2023-01-28 00:54:24 <psykose> 58d5c21b5e9f3c394a787344f731b6ed07427a1d
2023-01-28 00:54:26 <psykose> elly: ^
2023-01-28 00:58:25 <sam_> Piraty: coordination of some stuff like time_t for glibc, heads-up on Big Breakage, etc
2023-01-28 03:29:09 <psykose> elly: for your enjoyment as well: !43621
2023-01-28 03:41:23 <abby> sam_: i'd be interested i think
2023-01-28 03:41:40 <sam_> <3
2023-01-28 03:41:58 <sam_> i'll definitely ping all the people i know if/when it happens, i've started some steps but waiting for a reply from infray peopel
2023-01-28 04:10:07 <elly> psykose: you love to see it! thanks :)
2023-01-28 04:13:59 <[[sroracle]]> sam_: will this be a public list?
2023-01-28 04:23:23 <sam_> yes
2023-01-28 06:23:34 <psykose> elly: and merged, so have fun with more patches :p
2023-01-28 11:31:22 <psykose> they finally implemented 32-bit wine on 64-only host no multilib
2023-01-28 11:31:43 <psykose> almost nothing works with it but i found a few things that do
2023-01-28 11:31:53 <psykose> at last :)
2023-01-28 11:56:36 <Misthios> what did u find that works?
2023-01-28 15:33:46 <orbea> psykose: cant wait till its the standard
2023-01-28 16:49:07 <elly> psykose: I think temp-failure-retry and wtf-stacksize are both already fixed upstream but not in 109
2023-01-28 16:49:21 <elly> some day I will figure out what is up with scoped-file-no-close
2023-01-28 17:18:07 <bl4ckb0ne> they did that in since version 7
2023-01-28 17:38:30 <clandmeter> is there no upgrade path from 3.12 to 3.17?
2023-01-28 17:47:45 <Hello71> Misthios: hello world
2023-01-28 17:47:57 <clandmeter> ok needed to fiddle around but its ok now
2023-01-28 17:48:37 <ikke> clandmeter: via 3.14 or so
2023-01-28 18:49:01 <Misthios> Hello71 damnnnn
2023-01-28 18:53:42 <psykose> orbea: it (more or less) is an easy option now, though marked experimental etc etc. hopefully over the 8.x series it gets to a good place :) (and i enabled it in alpine fwiw)
2023-01-28 18:53:52 <psykose> Misthios: mplayer 32-bit i think
2023-01-28 18:54:01 <psykose> the 64 one draws a green square and the 32 one renders video :p
2023-01-28 18:55:15 <psykose> elly: makes sense
2023-01-28 18:56:01 <psykose> elly: as for scoped-file, you could maybe just debugger it- if you look far enough in the history you'll see the old shim for it (dlsym for close and wrapping it), it's probably just some special semantic at some layer and nothing too fancy
2023-01-28 18:56:32 <psykose> elly: well, and if you remember, setting enforce=true to enforce=false didn't fix the failure, only deleting the whole thing did. it took an if(false) codepath at runtime..
2023-01-28 20:58:42 <elly> sus
2023-01-28 20:58:55 <elly> I'll have a look at some point, that patch kind of scares me because I suspect it is papering over a worse bug
2023-01-28 21:06:06 <psykose> indeed :)
2023-01-28 21:06:25 <psykose> i hope my quick comments on all of them are somewhat helpful
2023-01-28 21:24:25 <elly> yeah, I think so
2023-01-28 21:34:03 <vkrishn> I think so too, and just wating for another world record for typing speed to happen :)
2023-01-29 15:03:20 <PureTryOut> I have a source in an APKBUILD that returns a 304. With wget it can just be ignored and retrieve the file anyway but curl (which I think abuild uses) just fails to get the file properly. Anything I can do about this?
2023-01-29 15:05:02 <ikke> hmm
2023-01-29 15:05:19 <ikke> 304 means not modified right?
2023-01-29 15:06:11 <PureTryOut> yeah. But in this case I have no cache of this file yet
2023-01-29 15:06:34 <ikke> sounds like a buggy webserver
2023-01-29 15:06:52 <ikke> If you get 304 not modified, the webserver is not providing the content 
2023-01-29 15:06:59 <PureTryOut> Probably is 🤷 Should I just rehost the file on dev.a.o?
2023-01-29 15:07:14 <ikke> Wondering why it does work with wget
2023-01-29 15:07:41 <PureTryOut> well wget ignores 304 by default, you can "break" it there as well when you do `-N`
2023-01-29 15:08:00 <ikke> How can you ignore 304?
2023-01-29 15:08:06 <PureTryOut> for 304 the client has to tell the server what it has already. wget only does that when you have -N, curl does it by default
2023-01-29 15:08:20 <PureTryOut> but I haven't found a way to let curl not do that
2023-01-29 15:08:33 <ikke> PureTryOut: What does curl tell it has then?
2023-01-29 15:08:44 <PureTryOut> yeah that's the thing I don't know lol
2023-01-29 15:08:49 <ikke> curl -v?
2023-01-29 15:08:57 <PureTryOut> it worked first time when I did abuild checksum, but never after that
2023-01-29 15:09:16 <ikke> PureTryOut: so it is already downloaded?
2023-01-29 15:09:30 <ikke> in /var/cache/distfiles?
2023-01-29 15:09:55 <PureTryOut> according to curl yes, making the server return 304. But I have no clue where, as I cleared it from /var/cache/distfiles like I said at the start
2023-01-29 15:10:11 <PureTryOut> even if I manually run curl it fails and it definitely doesn't use /var/cache/distfiles then
2023-01-29 15:10:26 <ikke> can you show the output of curl -v <url>?
2023-01-29 15:10:31 <PureTryOut> I think I'll just rehost the file on dev.a.o...
2023-01-29 15:10:36 <PureTryOut> ikke: I can but it has nothing about cache
2023-01-29 15:10:47 <ikke> something like etag?
2023-01-29 15:11:09 <PureTryOut> https://paste.sr.ht/~puretryout/411bc337f08d86c565fdde3eae2f597382d6c45e
2023-01-29 15:12:00 <ikke> There is no 304 in there
2023-01-29 15:12:47 <PureTryOut> nope but `curl -s -o /dev/null -w "%{http_code}" <url>` does show 304. And wget and stuff do as well, so it definitely is a 304
2023-01-29 15:14:21 <ikke> Seems to consistently return 200 for me
2023-01-29 15:16:42 <ikke> What version of curl?
2023-01-29 15:23:55 <PureTryOut> 7.87.0
2023-01-29 15:26:09 <ikke> For the server to reply with 304, there should be some header indicating what you have locally
2023-01-29 15:26:17 <ikke> And I can't seem to reproduce it
2023-01-29 15:28:19 <PureTryOut> 🤷
2023-01-29 15:29:19 <PureTryOut> I have no clue what's going wrong here. But abuild checksum now fails for me consistently
2023-01-29 15:29:28 <ikke> PureTryOut: can you share the APKBUILD?
2023-01-29 15:29:56 <PureTryOut> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43665/diffs?commit_id=3670ac441ba25eac66dee97bcc4881143574211c
2023-01-29 15:33:58 <ikke> nope, no issue with abuild checkum
2023-01-29 15:34:06 <ikke> even after removing from /var/cache/distfiles again
2023-01-29 15:34:34 <ikke> and the checksum does not change
2023-01-29 15:42:46 <PureTryOut> Waaatttt...
2023-01-29 15:42:49 <PureTryOut> Then what the hell is going on here
2023-01-29 15:44:42 <PureTryOut> and now abuild checksum ran fine, wth
2023-01-29 15:45:01 <PureTryOut> maybe a temporary issue with the webserver? I have no clue... 🤷
2023-01-29 15:45:18 <ikke> yeah, I'd guess so
2023-01-29 16:45:57 <PabloCorreaGomez[m]> How do I go about an aport that was introduced in 2017, only rebuilt but never updated, and that depends on a very old package that was deprecated and abandoned years ago and that I want to drop?
2023-01-29 16:47:38 <minimal> which aport?
2023-01-29 16:48:29 <PabloCorreaGomez[m]> The one I want to remove is gnome-doc-utils
2023-01-29 16:48:53 <PabloCorreaGomez[m]> The only thing that depends on it is testing/stardict
2023-01-29 16:51:34 <minimal> that's a "makedepends" on gnome-doc-utils, not a "depends"
2023-01-29 16:52:51 <PabloCorreaGomez[m]> Yes, sorry. The dependency is to build it
2023-01-29 16:53:07 <minimal> the ./configure has a "--disable-gnome-support" option, so wondering why it needs gnome-doc-utils
2023-01-29 16:53:34 <minimal> perhaps there is some other configure option that could be used to remove the builddep?
2023-01-29 16:57:15 <PabloCorreaGomez[m]> I looked into it and does not look like it. Feels like some of the build macros are used all around in the project
2023-01-29 17:32:29 <Hello71> https://github.com/archlinux/svntogit-community/blob/packages/stardict/trunk/PKGBUILD
2023-01-29 17:32:36 <Hello71> PabloCorreaGomez[m]: 
2023-01-29 20:01:25 <PureTryOut> ikke: just had the problem again and after retrying it 3 times quickly it succeeded. So it's just a buggy webserver...
2023-01-29 20:01:36 <ikke> PureTryOut: fun
2023-01-29 20:01:50 <PureTryOut> Yup...
2023-01-29 20:02:16 <ikke> maybe bad caching?
2023-01-29 20:02:19 <ikke> on their side
2023-01-29 20:03:44 <PureTryOut> That package btw, succeeds for armv7 to build locally and fails on CI. Seemingly because the CI runs armv7 on an armv8 machine. It builds a shared library and puts it in $builddir/bin/linux_armv8l on the CI, and in $builddir/bin/linux_armv7l locally. Should I patch the build system or how are these things resolved normally?
2023-01-29 20:04:36 <ikke> Not sure, but is it possible to explicitly set the target arch?
2023-01-29 20:04:41 <ikke> to $CARCH
2023-01-29 20:04:43 <ikke> or something like that
2023-01-29 20:06:00 <ikke> PureTryOut: note that CI and the build server are the same in this regard
2023-01-29 20:06:05 <ikke> both arm8l
2023-01-29 20:06:20 <ikke> One is docker, the other lxc
2023-01-29 20:06:54 <PureTryOut> I expected as much
2023-01-29 20:07:15 <ikke> It's even the exact same server atm, although ci runs in a aarch64 vm
2023-01-29 20:08:07 <PureTryOut> Fancy
2023-01-29 20:09:03 <PureTryOut> Argh I'll have to patch it, it uses uname to detect the platform and folder name
2023-01-29 20:44:26 <Quillith> Hello, I'm trying to follow the instructions here: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package but when I follow the link to the template apk 'newapkbuild' the Alpine package list says "no item found." Was it renamed or is it no longer a resource
2023-01-29 20:46:09 <Misthios> its part of the abuild package: (should be the correct link) https://pkgs.alpinelinux.org/contents?file=newapkbuild&path=&name=&branch=edge&arch=x86_64
2023-01-29 20:53:52 <Quillith> Thank you
2023-01-29 23:13:06 <Quillith> I ran abuild -r and got this error, do I run mkdir as part of my own packaging process or is thi directory something I need to integrate into the application itself? /usr/bin/abuild: cd: line 2490: can't cd to /home/quillith/aports/testing/r2modman/pkg/r2modman: No such file or directory
2023-01-29 23:19:02 <psykose> looks like you didn't install anything to $pkgdir so it doesn't exist
2023-01-29 23:21:26 <EvTheFuture> Hello, I've just implemented support for ZFS on the root filesystem for setup-disk. However, there is a problem with grub-probe that is used by the grub script 10_linux when zfs is used. The problem is that grub-probe does not seem to support encrypted zfs pools. However I've patched my 10_linux script to make it work with the zpool command if grub-probe fails. Does anyone know
2023-01-29 23:21:28 <EvTheFuture> how the GRUB project would accept such a patch that does not fix the problem inside the grub-probe binary? Could this be a patch in the Alpine aport of GRUB instead? The bug report I found upstream is from 2016 and is still open.
2023-01-29 23:21:58 <EvTheFuture> Anyhow, the patch of setup-disk works just fine if non encrypted zpool is used
2023-01-29 23:44:56 <Quillith> psykose: Thank you, I advanced further after adding some make commands. I installed quasar through yarn in my Build function, and later in that function I try to use quasar to do something with electron, but even though I successfully install quasar my build fails because 'quasar not found'
2023-01-29 23:47:38 <Quillith> 'yarn global add @quasar/cli' then later 'yarn install' and 'quasar dev -m electron'
2023-01-29 23:54:04 <psykose> the quasar it installs is probably a prebuilt binary built against glibc
2023-01-29 23:55:16 <psykose> ah, no
2023-01-29 23:55:34 <psykose> you just don't have where it's installed in PATH
2023-01-29 23:59:01 <minimal> EvTheFuture: the Grub project seems very slow to apply (some) patches
2023-01-30 00:02:56 <abby> yeah grub + zfs is not going to be a very pleasant experience
2023-01-30 00:04:06 <minimal> Grub are several months behind their next planned release already.
2023-01-30 00:08:01 <psykose> "some" haha
2023-01-30 00:09:22 <minimal> psykose: yeah there are still versions of patches floating around on their mailist list to fix LUKSv2 booting which *still* has not been committed despite that functionality supposed being added to Grub 2.06 (released in June 2021!)
2023-01-30 00:10:01 <abby> bah who needs argon anyway
2023-01-30 00:10:28 <minimal> abby: not related to argon, grub-probe does not handle/recognise LUKS v2, only v1
2023-01-30 00:10:49 <abby> ah, i thought it was the only works with some v2 algos issue
2023-01-30 00:10:53 <psykose> luks 2 has more features than just argon :p
2023-01-30 00:10:59 <minimal> and grub-probe is called when grub-mkconfig is run......so grub.cfg is still not set up correctly for LUKS v2
2023-01-30 00:11:08 <abby> wonderful
2023-01-30 00:11:42 <minimal> there's been multiple versions of patches to fix grub-probe on the list for maybe 10-12 months now :-(
2023-01-30 00:11:45 <psykose> personally i just gave up on grub and look at any other alternative at all
2023-01-30 00:11:56 <psykose> it basically feels like an abandoned corporate project at this point
2023-01-30 00:12:27 <abby> yeah on every computer i have zfs on, i use zfsbootmenu. grub only exists on my desktop, which hasn't been zfs-ified yet
2023-01-30 00:14:29 <minimal> psykose: Grub's averaging 18-24 months between release.......it's not abandoned, just working to glacial timescales
2023-01-30 00:15:01 <valerius> I miss LILO
2023-01-30 00:15:17 <valerius> I used to be able to write LILO configs from the top of my head and they would just work
2023-01-30 00:17:48 <minimal> "LI" ................. :-(
2023-01-30 00:19:08 <PabloCorreaGomez[m]> Hello71: thanks a lot for the pointer, that seems to work!
2023-01-30 00:19:10 <minimal> From rusty memory LILO printed just "LI" if it loaded but failed to boot
2023-01-30 00:19:44 <Quillith> psykose: okay, so it's not installing to the right place. I saw the note you left me one the wiki that I shouldn't mess with user path, so instead of changing path I need to change where quasar is installing. The base app says to use yarn global add, but maybe if I take out the global or specify a directory to install to, that would work. Thanks psykose
2023-01-30 00:20:41 <psykose> for what you are building i don't think you need any of that
2023-01-30 00:22:03 <psykose> just yarn install && npx quasar .. would work
2023-01-30 00:22:04 <psykose> probably
2023-01-30 00:22:22 <Quillith> yarn install && npx quasar , okay thank you
2023-01-30 00:25:56 <Quillith> npx not found unfortunately, which is weird because when I look up what npx is, shouldn't it be part of nodejs? I have that listed as a dependency
2023-01-30 00:39:26 <psykose> npm
2023-01-30 01:00:02 <Quillith> Oh okay thank you. That gets me past the quasar not found but spits out a lot of npm errors, I'm not sure whether that means I'm closer or whether I should try and specify the quasar path. I'll keep trying things, appreciate your help psykose
2023-01-30 01:10:31 <Quillith> I ran into this while yarn runs. I'm assuming it's a bad idea to put 'doas' or 'sudo' in the script? An unexpected error occurred: "EACCES: permission denied, mkdir '/node_modules'"
2023-01-30 01:12:09 <psykose> i kind of managed to build it i guess https://img.ayaya.dev/XoSZoqcuXuJS
2023-01-30 01:12:26 <psykose> my conclusion is that this should be used by nobody and is best avoided by a 500 foot pole
2023-01-30 01:12:32 <psykose> holy abandoned project batman
2023-01-30 01:12:49 <psykose> it makes the average outdated javascript project look up to date
2023-01-30 01:14:36 <Quillith> so it isn't entirely me? that makes me feel better lol
2023-01-30 01:16:59 <Quillith> This is supposed to be a mod manager, but I'm starting to think it'd be better if I just manually install the mods instead of wrangling with this
2023-01-30 01:18:25 <psykose> that's always how i've felt about mod managers
2023-01-30 01:18:59 <psykose> unless they're very good (e.g. factorio has its' own first-party support) when they don't work it's just extremely annoying, and moving around some zips/folders isn't too bad
2023-01-30 01:20:48 <Quillith> It really isn't, that's what I've been doing for the Witcher 1 and Elden Ring. I thought this would be an easy introduction to making something a native Alpine package. I might not have made the best choice haha
2023-01-30 01:23:45 <psykose> if it was not electron maybe i would be a tad more sympathetic to it :p
2023-01-30 01:35:19 <Quillith> hmm, I wonder if it would be more space and resource-efficient to instead write a bash script that checked for mod updates and replaced outdated files. That's probably the biggest benefit for me so I don't need to remember to check each mod for updates
2023-01-30 01:53:48 <Quillith> thanks for your help psykose, have a good one
2023-01-30 05:37:50 <ikke> psykose: fyi, commits with `closes #123` do not close an issue unless they are present in the default branch
2023-01-30 05:37:58 <psykose> indeed
2023-01-30 05:38:22 <psykose> i do always forget though
2023-01-30 07:14:16 <EvTheFuture> minimal: @psykos: Thanks for the info regarding grub. If no one objects I'll create one single MR with two commits then, one for setup-disk and one to fix the grub script.
2023-01-30 07:22:37 <nmeum> maribu: is it intentional that gcc-riscv-none-elf depends on binutils-arm-none-eabi, binutils-msp430-elf, … now?
2023-01-30 07:27:25 <maribu> No, :/
2023-01-30 07:29:41 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/commit/4160a8338bd059e205ea0c3dec3a84f6decc5467
2023-01-30 07:29:54 <nmeum> I think the makedepends → depends change in that commit causes this
2023-01-30 07:30:47 <psykose> indeed
2023-01-30 07:30:59 <nmeum> need to set depends="" in the subpackages then
2023-01-30 07:32:10 <psykose> cant it just be makedepends="$makedepends .."
2023-01-30 07:32:38 <psykose> if not, then https://img.ayaya.dev/b3KBdqucYo2l
2023-01-30 08:33:43 <maribu> psykose: Yes, it should just be makedepends in the root pkg and depends extended in the subpkg. And a comment so that I won't forget why it is a makedepends next time
2023-01-30 08:34:46 <psykose> if it's just makedepends then it's fixed with only that :)
2023-01-30 08:35:03 <psykose> i.e. s|depends|makedepends , since the rest looks fine
2023-01-30 08:35:11 <maribu> It is a depends, but gcc-foo depends on binutils-foo and not on binutils-bar
2023-01-30 08:35:46 <psykose> what i mean is the subpackage gcc-foo already does binutils-foo
2023-01-30 08:35:57 <psykose> so that one single line can be changed to makedepends= and the subpackages are still correct
2023-01-30 08:36:19 <maribu> Yes, that was the approach before. I just forgot why it is makedepends in the beginning and assumed it was a bug. But it was indeed intentional.
2023-01-30 08:37:47 <psykose> c9c29a58cf6a185c4530a9fa025357f6bd4417be then
2023-01-30 08:44:19 <maribu> Is it already pushed? Then I would update https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43682 to just bump the pkgver of newlib instead
2023-01-30 08:45:47 <maribu> I updated it to drop fixing the depends of GCC, but still upgrade newlib and fix the depends of newlib and g++-cross-embedded
2023-01-30 08:57:15 <psykose> ah yes, those too
2023-01-30 08:57:39 <psykose> should +pkgrel g++
2023-01-30 09:18:54 <psykose> also doesn't picolibc need a rebuild against newlib or something
2023-01-30 09:36:55 <maribu> picolibc is an alternative C library that can be used instead of newlib. E.g. the RISC-V guys seem to prefer it. (And given that is has a sane build system, a sane stdio implementation, better testing, a sane release management, support for thread local storage, etc. this is not too suprising.) It would only need a rebuild when GCC's version is bumped to also profit from the additional optimizations. And even than it is a should be
2023-01-30 09:36:55 <maribu> rebuilt, not a must be rebuild.
2023-01-30 09:37:52 <maribu> I always forget to bump pkgrel at least once :|
2023-01-30 09:51:20 <maribu> * s/even than/even then/
2023-01-30 11:37:38 <maribu> nmeum: I just realized that the split out g++ was not properly rebased on top of the getentropy fix. That patch should be in the g++ pkg, but it only got to the GCC pkg. (It doesn't hurt there, but could also be dropped there.)
2023-01-30 11:38:53 <maribu> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43682 also fixes this now
2023-01-30 11:53:05 <nmeum> maribu: yea, I also noticed that but for some reason C++ cross compilation still works even though the patch is in the gcc package and not in the g++ package
2023-01-30 11:58:37 <maribu> my mind is exploding :-O
2023-01-30 12:07:23 <nmeum> I am also confused but haven't had the time yet to investigate. my initial thought was that g++ does have a makedependency on newlib but it does so that doesn't really explain it
2023-01-30 12:07:32 <nmeum> I will try to test your MR later to see if it still works with your commit applied :)
2023-01-30 12:31:22 <EvTheFuture> I'm trying to commit to my forked version of the alpine-conf repository. However I get a pipeline error from the tests. When I run the tests locally they all pass... I have probably just missed something obvious, but would be grateful if someone could just take a quick look at: https://gitlab.alpinelinux.org/EvTheFuture/alpine-conf/-/jobs/962193
2023-01-30 12:34:30 <psykose> = not ==
2023-01-30 12:35:22 <psykose> the tests test multiple shells, that one is dash
2023-01-30 12:35:26 <psykose> dash doesn't implement ==
2023-01-30 12:35:59 <psykose> nor should it, it's just = (identical)
2023-01-30 12:38:11 <maribu> nmeum: Now both gcc and g++ have that patch included. I'm quite confident that the issue should not pop up anymore :)
2023-01-30 13:08:04 <ncopa> ikke: I got bitten by https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/148 myself today. thank you for the fix. i would been offline still without it :)
2023-01-30 13:10:25 <ikke> Aha, nice! 
2023-01-30 13:14:03 <dzilvys> does networking try to communicate on an interface multiple times before it decides to give up and move on?
2023-01-30 13:14:54 <dzilvys> Issue I am having is that if the ethernet is not plugged in under `eth0` the other port `vvi0` does not get brought up in time for a service to try and communicate on it
2023-01-30 13:15:27 <dzilvys> if I bring up the networking, then try to ping with `ping <IP> -c 1 -w 15` it fails inside a shell script
2023-01-30 13:15:53 <dzilvys> however, looping with a while loop checking the state, and instead of waiting 15 secs waiting 1, it succeeds
2023-01-30 13:23:31 <EvTheFuture> @psykose: Thank you!
2023-01-30 14:03:54 <kreyren> Piraty, were you able to fix the issue on A64?
2023-01-30 14:04:16 <EvTheFuture> MR !149 created
2023-01-30 14:04:38 <EvTheFuture> in alpine-conf that is :)
2023-01-30 14:36:51 <ncopa> EvTheFuture: a nitpick for https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/149
2023-01-30 14:37:13 <ncopa> use imperative mood in commit message. see https://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages
2023-01-30 14:37:54 <ncopa> not a big deal, but its a good best practice
2023-01-30 14:39:08 <psykose> the second answer to that says to use past tense :p
2023-01-30 14:40:00 <ncopa> heh
2023-01-30 14:40:03 <ncopa> https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/SubmittingPatches?id=HEAD#n183
2023-01-30 14:42:35 <ncopa> i guess the best is to be consistent, so follow whatever was done for the rest of the commits
2023-01-30 14:43:07 <ncopa> anyway, its not a deal breaker
2023-01-30 15:11:21 <minimal> dzilvys: are you referring to IP address configuration? If so does your /etc/network/interfaces define both eth0 and vvi0 and if so as what? i.e. static, dhcp, etc
2023-01-30 15:23:04 <bl4ckb0ne> ty for the vk bump psykose 
2023-01-30 15:24:44 <psykose> webscale
2023-01-30 15:38:03 <bl4ckb0ne> what's the process to get aports merge rights?
2023-01-30 15:46:43 <psykose> don't think there is one
2023-01-30 15:46:51 <psykose> aside from someone recommending someone i guess
2023-01-30 15:51:35 <dzilvys> minimal: eth0 is dhcp, vvi0 is static. but when running scripts it ahs a weird behavior which I mentioned that a single delay of 15 seconds would not work to then check if the interface is up. However, multiple 1 second delays that add up to 15 seconds works
2023-01-30 16:04:43 <minimal> dzilvys: check if the interface is up how exactly? "ip link show vvi0"? Also vvi0 is a strange name, what type of interface is it?
2023-01-30 16:08:58 <dzilvys> minimal: yes using `ip link show vvi0`, vvi0 is just an eth port that has been renamed
2023-01-30 16:11:11 <minimal> dzilvys: so I don't understand your script problem, running `ip link show vvi0` will either show UP or DOWN
2023-01-30 16:23:02 <Piraty> kreyren: craftyguy reported that the mesa version that works fine for me for several days was broken for him as well
2023-01-30 16:23:59 <dzilvys> minimal: right so, its a startup script placed inside /etc/local.d/ The script brings up networking and chronyd (in that order) then it checks whether the vvi0 state is up or down. If its up it tries to communicate with the device on that interface. My issue is that even if `ip link` reports that the status is up. When it tries to communicate on it, it fails. So I tried pinging the device on that interface to determine if its up or down. pinging it 
2023-01-30 16:23:59 <dzilvys> by setting `-w 15` so it waits 15 seconds, fails the ping request. However, if I loop `ping ... -w 1` for a max count of 15 loops, it works find and is able to communicate
2023-01-30 16:24:45 <Piraty> i.e. he was able to repro it with gnome-clocks just as i did, yet i'm not sure if that's *really* the case. gnome-clocks daemon remains after the clocks gui exits, thus possibly using the same broken mesa lib still
2023-01-30 16:25:50 <kreyren> Piraty, interesting
2023-01-30 16:26:03 <kreyren> did you reported it to mesa_
2023-01-30 16:30:14 <minimal> dzilvys: "up" is not the same as having an IP address though - you can "ip link set vii0 up" without it having an IP address. "tries to communicate on it" - communicate how exactly?
2023-01-30 16:40:30 <minimal> dzilvys: also "pinging the device on that interface" - pinging the vvi0 interface's IP address? or pinging some other (remote) device that is reachable (in same subnet? via default route?) via the vvi0 interface?
2023-01-30 16:56:11 <dzilvys> minimal: vvi0 has static addresses assigned to it. So the host would be 192.168.44.1 and it would try ping 192.168.44.2
2023-01-30 16:56:54 <dzilvys> to respond of tries to communicate, I mean it tries to ping it via `ping 192.168.44.2 -w 15` to try get a response within 15 seconds
2023-01-30 16:59:06 <minimal> dzilvys: but you didn't specify "-c" option to ping which specifies a "count" value
2023-01-30 17:00:14 <minimal> from the ping manpage "-w deadline    it waits either for deadline expire or until *count* probes are answered or for some error notification from network"
2023-01-30 17:17:01 <dzilvys> minimal: I tried the same with either setting the -c value to 1 or 3 but it still did not get a positive result from the ping
2023-01-30 17:35:38 <minimal> dzilvys: well there's insufficient information to help further. You're not doing anything "weird" like setting rc_parallel to YES? Also have you tried running a tcpdump on the interface before the pings - so verify that the ICMP packets actually do go out via the vvi0 interface
2023-01-30 17:35:46 <minimal> s/so ver/to ver/
2023-01-30 17:35:46 <alpine-meetbot> minimal meant to say: dzilvys: well there's insufficient information to help further. You're not doing anything "weird" like setting rc_parallel to YES? Also have you tried running a tcpdump on the interface before the pings - to verify that the ICMP packets actually do go out via the vvi0 interface
2023-01-30 18:02:41 <EvTheFuture> in alpine-conf that is :)
2023-01-30 18:30:01 <EvTheFuture> ncopa: I've added test and changed the commit message.
2023-01-30 18:45:00 <ncopa> EvTheFuture: looks good! thanks!
2023-01-30 18:45:19 <ncopa> kyua is relatively simple
2023-01-30 18:49:59 <ncopa> ikke: do you want me to add a testcase for the SSID issue?
2023-01-30 18:50:21 <ikke> ncopa: No, I'll do it, thanks for the pointers
2023-01-30 18:50:59 <ncopa> thanks!
2023-01-30 18:55:03 <ncopa> i wonder if we should replace wpa_supplicant with iwd for setup-interfaces
2023-01-30 18:58:08 <skarnet> what are the advantages of iwd?
2023-01-30 18:58:50 <ikke> ncopa: When I remove the fix, the test times out, is that expected?
2023-01-30 18:58:53 <ikke> tests/setup_interfaces_test:setup_interfaces_interactive_ssid_list  ->  broken: Test case body timed out
2023-01-30 18:59:02 <EvTheFuture> ncopa: thanks. I'll create a MR for grub later as well in order for grub to properly generate grub.cfg when root zfs is encrypted.
2023-01-30 18:59:56 <ikke> ncopa: I guess it's waiting for some input?
2023-01-30 19:01:40 <ncopa> ikke: yes its expected. it times out because it runs in interactive mode and waits for input
2023-01-30 19:01:49 <ikke> ncopa: ok
2023-01-30 19:03:08 <ncopa> skarnet: as I understand iwd uses crypto using kernel and it has a different approach to state of configured networks
2023-01-30 19:03:41 <skarnet> so far I file that under "different", not "better" :)
2023-01-30 19:03:42 <ncopa> in wpa_supplicant its treated as configuration, and config files needs to be modified
2023-01-30 19:04:05 <ncopa> iwd treats the connections as state, and store the state in a db
2023-01-30 19:04:37 <skarnet> in a db as in sqlite or equivalent? or just files?
2023-01-30 19:04:49 <ikke> ncopa: so 3 solutions, not sure which one is best
2023-01-30 19:04:50 <ncopa> skarnet: yes, i think you can file it under "different", that is why im asking
2023-01-30 19:05:02 <ncopa> not sure what kind of db
2023-01-30 19:05:30 <skarnet> it is true that separating the wanted state (only modifiable via the user) from the current state (volatile) is a good thing
2023-01-30 19:05:35 <ncopa> there are some drawbacks also. it requires kernel modules for the crypto, it has hard dependency on dbus
2023-01-30 19:06:07 <ncopa> but my general feeling is that iwd is more modern and better
2023-01-30 19:06:15 <skarnet> yeah to me a hard dependency on dbus is a deal breaker, that's why I never took any further look into iwd :/
2023-01-30 19:06:27 <ncopa> it is also more similar to how bluetooth is handled
2023-01-30 19:06:46 <ncopa> might be good to treat bluetooth and wifi in similar way
2023-01-30 19:07:00 <skarnet> probably, yes
2023-01-30 19:07:36 <psykose> i remember the good old days when using wpa supplicant gave me some 40mbit/s and swapping to iwd instantly made it my actual internet speed of 200mbit/s
2023-01-30 19:07:37 <psykose> good times
2023-01-30 19:07:51 <skarnet> but dbus is such a big con that it would take a humongous amount of pros to make me switch
2023-01-30 19:07:56 <psykose> knowing wpa development pace it's probably still true today
2023-01-30 19:08:10 <ikke> does it actually need something on dbus, or can it be shimmed somehow?
2023-01-30 19:08:19 <psykose> there is a fork without dbus (eiwd)
2023-01-30 19:08:22 <skarnet> psykose: you really got a 5x speed upgrade?
2023-01-30 19:08:28 <psykose> but illiliti maintains it so i will never use it
2023-01-30 19:08:31 <psykose> skarnet: at the time yes
2023-01-30 19:08:38 <psykose> it's better on cpu usage too because of more kernel stuff
2023-01-30 19:08:42 <ncopa> more details here: https://lwn.net/Articles/770991/
2023-01-30 19:08:42 <psykose> and it does very fast roaming
2023-01-30 19:09:39 <psykose> the dbus is afaik only for iwctl interface (as opposed to editing the files by hand), but it is hard required pretty sure
2023-01-30 19:09:41 <ncopa> iwd is a generation after wpa_supplicant, written to deal with problems in wpa_supplicant, so I kinda assume its better
2023-01-30 19:09:56 <skarnet> I totally get it
2023-01-30 19:09:59 <psykose> the iwctl interface also does some quite weird readline stuff and isn't very good
2023-01-30 19:10:07 <ikke> psykose: the article ncopa links to confirms it
2023-01-30 19:10:17 <ikke> "It would be better to optimize any inefficiencies out of D-Bus, he said, than to try to get iwd to work without it."
2023-01-30 19:10:18 <psykose> i've segfaulted it a lot of times and it constantly redraws the terminal every frame, etc
2023-01-30 19:10:45 <ncopa> iwd segfaults for me currently
2023-01-30 19:11:01 <skarnet> it was made to solve old problems, and people didn't care that it was creating new problems
2023-01-30 19:11:18 <psykose> ncopa: did you upgrade
2023-01-30 19:11:30 <ncopa> i know there are users who wants to avoid dbus, and that is why i havent already switched to iwd
2023-01-30 19:11:56 <skarnet> eiwd may be interesting, personality clashes aside
2023-01-30 19:12:01 <ncopa> and also why i am asking here
2023-01-30 19:12:29 <ncopa> psykose: not sure. seems like the wifi im currently sitting at does not work well
2023-01-30 19:12:46 <psykose> (there was an easy segfault before -r2 due to an overflow))
2023-01-30 19:12:51 <psykose> aside from that, might be something else
2023-01-30 19:12:58 <ncopa> it has a captive portal, so I was not able to connect with wpa_supplicant only
2023-01-30 19:13:20 <ncopa> but i rebooed in macos and logged in to the captive portal and rebooted to linux again
2023-01-30 19:13:38 <ncopa> i dont know if iwd handles captive portals better, but I sort of expect it does
2023-01-30 19:14:15 <ncopa> so, even if we switch to iwd as the default, users can still use wpa_suppliant I guess
2023-01-30 19:17:11 <ncopa> i find wpa_supplicant a bit complicated with captive portals etc
2023-01-30 19:18:15 <ncopa> Installed:                                Available:
2023-01-30 19:18:15 <ncopa> iwd-2.2-r1                              < 2.2-r2 
2023-01-30 19:18:24 <ncopa> so no, i havent updated yet
2023-01-30 19:19:41 <ncopa> ok, so what I hear is that we probably want support iwd from the installer
2023-01-30 19:19:47 <vkrishn> psykose: one more pkgs request pls, "mimetex"
2023-01-30 19:20:25 <vkrishn> i have my notebook all working in al, except for mimetex
2023-01-30 19:20:33 <ncopa> do we want support both wpa_supplicant and iwd from installer scripts? or can we replace wpa_supplicant with iwd?
2023-01-30 19:20:44 <vkrishn> demo, http://dev.insteps.net/demo/notebook/index.php/Notes/QMgr#/other/mimetex (on debian)
2023-01-30 19:21:11 <psykose> ncopa: both probably makes more sense
2023-01-30 19:21:19 <skarnet> my only input is: if you switch to iwd, please try using the eiwd implementation, because forcing wifi users to run dbus is ugh.
2023-01-30 19:21:43 <mercenary> +1 to that
2023-01-30 19:22:46 <psykose> <forcing> and <is an option / the default in some installer somewhere> are some continents apart
2023-01-30 19:23:55 <skarnet> psykose: sure, but if iwd becomes the new default, how long until wpa_supplicant isn't really supported anymore and iwd becomes the only realistic option?
2023-01-30 19:24:33 <psykose> probably as long as it took for wpa_supplicant to be the only realistic option after it was added superceding iwd
2023-01-30 19:24:41 <psykose> (never and it didn't happen?)
2023-01-30 19:25:17 <ncopa> i think it also depends on upstream development and new wifi standards
2023-01-30 19:25:22 <skarnet> if iwd proves to be better (which it very well might be, dbus dependency notwithstanding), it won't make much sense maintaining the alternative
2023-01-30 19:25:41 <psykose> to be a tiny bit blunt
2023-01-30 19:25:58 <psykose> i think you are severely overestimating the effort of maintaining the existence of two packages people can then choose between
2023-01-30 19:26:24 <psykose> the only way wpa_supplicant gets removed is if the upstream literally vanishes, it turns into malware, and no longer connects to anything
2023-01-30 19:26:27 <skarnet> uhhh.
2023-01-30 19:26:58 <skarnet> given my experience with trying to add alternatives to an Alpine package, I don't think I'm overestimating anything
2023-01-30 19:27:39 <psykose> this isn't even an alternatives
2023-01-30 19:27:50 <psykose> it's a daemon you install and run or not
2023-01-30 19:27:53 <skarnet> and it's not about being *removed*, it's about being, let's say, neglected
2023-01-30 19:28:07 <psykose> it's like adding nginx and complaining about apache being neglected
2023-01-30 19:28:08 <skarnet> and not working as well as the default
2023-01-30 19:28:23 <ncopa> we already have iwd package and need to support it. the question at hand is what the installer should do
2023-01-30 19:28:59 <ncopa> 1) keeping things as is, support only wpa_supplicant from installer. iwd users are on their own setting it up
2023-01-30 19:29:12 <skarnet> giving choice to the user is always a good thing
2023-01-30 19:29:33 <ncopa> 2) replace wpa_supplicant with iwd. wpa_supplicant users are on their own setting it up
2023-01-30 19:29:35 <ncopa> 3)
2023-01-30 19:29:59 <ncopa> 3)  support both alternatives from installer. user can choose at install time
2023-01-30 19:30:04 <skarnet> 3)
2023-01-30 19:30:06 <ncopa> yes 3 is best
2023-01-30 19:30:30 <ikke> Yeah, I agree as well
2023-01-30 19:30:41 <ncopa> the question is how much work it is
2023-01-30 19:31:42 <psykose> it's already config_wpa_supp, so +1 question and another function
2023-01-30 19:31:44 <psykose> /fin
2023-01-30 19:31:56 <ncopa> since we already have wpa_supplicant working, and tests for it, i think it might be doable
2023-01-30 19:32:06 <ikke> my thinking
2023-01-30 19:32:35 <ncopa> actually, i dont think we should ask the user interactively. instead we have a hidden option for the alternative
2023-01-30 19:32:47 <ncopa> eg export WIFI=iwd
2023-01-30 19:32:49 <ncopa> or similar
2023-01-30 19:33:26 <ikke> Maybe we default to wpa_supplicant for now and make iwd opt-in
2023-01-30 19:33:32 <psykose> that sounds terrible
2023-01-30 19:33:35 <ncopa> or setup-interfaces [--wifi=iwd|wpa_supplicant]
2023-01-30 19:33:46 <psykose> hidden options nobody knows about except by magic are useless
2023-01-30 19:34:03 <psykose> that's what you do for "developer options do not report bugs when used" stuff
2023-01-30 19:34:22 <Ermine> I did a little bit of an investigation about iwd, and it seems like dbus api is the primary way to configure the daemon
2023-01-30 19:34:28 <psykose> it may as well just not be there (i.e. no change) rather than implement that
2023-01-30 19:35:44 <ncopa> psykose: well, the thinking here is that many users (majority?) does not really care, as long as it works without any fuzz
2023-01-30 19:36:19 <ncopa> the people who do care and complain have the option
2023-01-30 19:36:26 <Ermine> ncopa: command-line arguments are impossible to use if you use setup-alpine script. If one wants to customize the setup this way, they would need to run setup scripts one by one by hand
2023-01-30 19:36:28 <psykose> yes, so if that is the thinking and you want to not change it, then doing nothing is the solution
2023-01-30 19:36:47 <ncopa> we do similar for default file system of disk, bootloader etc
2023-01-30 19:36:48 <psykose> people that care can just configure it themselves
2023-01-30 19:37:31 <ncopa> the setup scripts are convenience scripts
2023-01-30 19:37:34 <psykose> the disk stuff is also exactly my point
2023-01-30 19:37:44 <psykose> when i first installed alpine i couldn't figure out how to configure something else
2023-01-30 19:37:50 <psykose> and i did everything by hand and threw the scripts out
2023-01-30 19:37:55 <psykose> i didn't even know the options were there
2023-01-30 19:38:07 <ncopa> haha!
2023-01-30 19:38:20 <psykose> convenience for people that install a lot of systems, sure, and know to export magic vars
2023-01-30 19:38:48 <ncopa> well, tbh, it was a convenience for myself :)
2023-01-30 19:39:13 <psykose> my thinking is that since you are doing a testsuite for all the setups, it may as well have some sort of option flow
2023-01-30 19:39:20 <psykose> of course, that's more generic than just to this instance
2023-01-30 19:39:30 <ncopa> but i think you have a point
2023-01-30 19:39:52 <ncopa> if the features are way too hidden people will not use them
2023-01-30 19:41:25 <ncopa> the thing is that I don't want ask too many questions from the installer
2023-01-30 19:41:25 <elly> who is the audience for iwd in the setup tool? like which users want iwd
2023-01-30 19:41:34 <psykose> same as wpa_supplicant
2023-01-30 19:41:51 <elly> well, are there users whose needs a met better by iwd?
2023-01-30 19:41:59 <elly> *are met
2023-01-30 19:42:20 <ncopa> i think people using alpine as desktop are the target users
2023-01-30 19:42:28 <psykose> imo like 99%? it is strictly an upgrade unless you are in a bug edge case, or you care about dbus (so the 99% stands)
2023-01-30 19:42:47 <psykose> people in the former are the troubling part, the latter know how to do things themselves
2023-01-30 19:43:00 <psykose> ikke: https://gitlab.com/gitlab-org/cli/-/merge_requests/1152 :)
2023-01-30 19:43:00 <elly> can we somehow detect the bug edge case(s)?
2023-01-30 19:43:15 <ncopa> i think there might be some older wifi hardware that is only supported from wpa_supplicant
2023-01-30 19:43:16 <ikke> psykose: cool
2023-01-30 19:43:25 <ikke> psykose: but still getting 409s I suppose?
2023-01-30 19:43:33 <psykose> yeah, haven't reported that yet
2023-01-30 19:43:37 <psykose> maybe soon
2023-01-30 19:43:47 <ncopa> elly: that is a good question
2023-01-30 19:44:11 <elly> ncopa: hmm, if there is, but iwd is better for most users, it seems like "try to detect those cases, use wpa_supplicant if we hit them, otherwise default to wpa_supplicant and have an env var for people who are like "ew no dbus"" might be the way
2023-01-30 19:44:57 <elly> or rather otherwise default to iwd
2023-01-30 19:45:24 <ncopa> i think openbsd has a "do you plan to use Xorg?" early in the setup
2023-01-30 19:45:46 <ncopa> but i dont want to ask questions unless absolutely neccessary
2023-01-30 19:45:52 <elly> well
2023-01-30 19:46:00 <psykose> a question for which preferred wouldn't be a bad one
2023-01-30 19:46:01 <elly> you could legitimately have a PLZ_NO_DBUS environment var for experts if you wanted
2023-01-30 19:46:07 <psykose> the other issue is how to integrate it
2023-01-30 19:46:14 <Ermine> Maybe "try to run iwd, if we don't get connectivity fall back to wpa_supplicant"
2023-01-30 19:46:16 <psykose> right inside is_wifi there is some connection handling
2023-01-30 19:46:24 <psykose> i'm not sure if that specifically is easily done with iwd
2023-01-30 19:46:43 <ncopa> fallback is also a good idea
2023-01-30 19:46:50 <elly> Ermine: mm, "don't get connectivity" can happen in a lot of scenarios though
2023-01-30 19:47:03 <psykose> you can definitely reuse the scan/password and output something to /var/lib/iwd, but it's not strictly the same
2023-01-30 19:47:25 <ncopa> ok i need to go for now, thanks for good input so far
2023-01-30 19:47:54 <psykose> take care
2023-01-30 19:54:26 <Ermine> What I personally dislike about iwd also is that it also tries to manage IP addresses instead of only establishing connections
2023-01-30 19:54:44 <psykose> you can disable the network configuration with one line
2023-01-30 19:56:21 <Ermine> Of course, I mean the design point of view. "Do one thing" and such
2023-01-30 19:56:34 <psykose> it's not even enabled by default, wtf
2023-01-30 19:56:54 <elly> Ermine: the definition of "one thing" is pretty elastic, though
2023-01-30 19:57:01 <psykose> this is definitely one of the complaints of all time
2023-01-30 19:57:15 <elly> is "configures your network interfaces" one thing, or is "configures your 802.11 card" one thing, or is even "configures a broadcom bcm43xx wireless card" one thing
2023-01-30 19:58:54 <psykose> elly: if your software has user configurable options that means it does two things and it is bad
2023-01-30 19:58:57 <psykose> did i do it correctly
2023-01-30 19:59:02 <Ermine> I think "configure 802.11 card" is option I like. Configuring IP and such is a job of network manager (which can delegate establishing a link to iwd)
2023-01-30 20:02:56 <minimal> Ermine: <joke> "do one thing", consults systemd directionary, ah "everything" ;-)
2023-01-30 20:03:13 <minimal> s/directionary/dictionary/
2023-01-30 20:03:13 <alpine-meetbot> minimal meant to say: Ermine: <joke> "do one thing", consults systemd dictionary, ah "everything" ;-)
2023-01-30 20:03:54 <Ermine> they definitely need a directionary
2023-01-30 20:04:18 <psykose> ikke: hmm, do you think it would be feasible to use something like `setarch armv7l <build> ..` for builders/ci and the like
2023-01-30 20:04:23 <psykose> just to keep the name more consistent
2023-01-30 20:05:01 <ikke> I forgot to run the container with linux32
2023-01-30 20:05:18 <ikke> But I guess setarch would work as well
2023-01-30 20:05:23 <psykose> does that return armv7 or just armv8l or something
2023-01-30 20:05:27 <ikke> the latter
2023-01-30 20:05:29 <psykose> well
2023-01-30 20:05:34 <psykose> we don't want the latter is the point
2023-01-30 20:05:43 <ikke> yes, understood
2023-01-30 20:06:08 <ikke> but afaik it's just cosmetic, right?
2023-01-30 20:06:12 <psykose> hm, is `arm` or `armh` better for the v6 one
2023-01-30 20:06:14 <psykose> well
2023-01-30 20:06:18 <psykose> not for some builds
2023-01-30 20:06:31 <psykose> er
2023-01-30 20:06:32 <ikke> yeah, someone ran into this the other day
2023-01-30 20:06:35 <psykose> yes, it's just cosmetic
2023-01-30 20:06:53 <psykose> but there are builds that match uname and then do like --target $(uname -m)-..
2023-01-30 20:07:06 <psykose> or if uname -m aarch64*) <64-bit stuff>
2023-01-30 20:07:06 <psykose> etcv
2023-01-30 20:07:20 <psykose> sure, can be patched, but i don't think it breaks anything to have a uname of the actual compiler targets we have
2023-01-30 20:07:31 <psykose> and it only perhaps smooths some edge cases
2023-01-30 20:07:53 <psykose> for python, everything uses the $something from setuptools/packaging/stdlib/i forgot, that only uses uname -m for the folder name
2023-01-30 20:08:02 <ikke> we do need to add setarch to the containers then, though
2023-01-30 20:08:10 <psykose> yeah
2023-01-30 20:08:22 <psykose> i'm just wondering if there's a downside
2023-01-30 20:08:23 <ikke> which requires utils-linux-misc
2023-01-30 20:08:41 <psykose> we can subpackage it for that part
2023-01-30 20:08:41 <ikke> with some dependencies
2023-01-30 20:08:57 <psykose> the executable itself doesn't have any
2023-01-30 20:09:09 <ikke> https://tpaste.us/YYne 
2023-01-30 20:09:11 <ikke> ok
2023-01-30 20:09:22 <ikke> It would also need to be backported
2023-01-30 20:09:39 <psykose> i would say we can start it only in edge
2023-01-30 20:09:58 <psykose> perhaps some unforeseen risk i'm not seeing
2023-01-30 20:10:19 <ikke> right, the ci file in the stable branches doesn't need to change, so that would still use linux32
2023-01-30 20:10:22 <psykose> it does exec into the command fine it seems so no hanging stuff
2023-01-30 20:10:24 <ikke> so yeah, just edge would work
2023-01-30 20:11:02 <ikke> Just need to change .gitlab-ci.yml after we updated the container
2023-01-30 20:13:01 <ikke> I did look at setarch when we set this up, but I guess due to relying on util-linux (which then wasn't event split up at all), settled on linux32
2023-01-30 20:13:27 <psykose> it should also be linux32 afaik
2023-01-30 20:13:41 <psykose> i.e. at the same time
2023-01-30 20:13:48 <psykose> that does have 32-bit userspace semantics doesn't it
2023-01-30 20:13:50 <psykose> otherwise it wouldn't
2023-01-30 20:14:19 <ikke> it wouldn't what?
2023-01-30 20:14:45 <ikke> userspace is already 32-bits due to the images being used
2023-01-30 20:14:56 <ikke> not sure what linux32 does else
2023-01-30 20:15:14 <ikke> https://www.systutorials.com/docs/linux/man/1-linux32/ mentions setarch
2023-01-30 20:15:32 <ikke> "The execution domains currently only affects the output of uname -m."
2023-01-30 20:15:38 <ikke> so it should be the same
2023-01-30 20:16:02 <psykose> yes i see now `linux32` is a symlink to setarch
2023-01-30 20:16:03 <psykose> hmm
2023-01-30 20:16:11 <psykose> i guess it is just not the  name we want
2023-01-30 20:16:29 <ikke> yup
2023-01-30 20:16:32 <psykose> ah, i see, there is also a linux32 in busybox
2023-01-30 20:16:33 <ikke> and bb only has linux32
2023-01-30 20:16:35 <psykose> ok, makes sense
2023-01-30 20:16:47 <ikke> yes, that's what we've been using so far
2023-01-30 20:17:04 <psykose> yeah
2023-01-30 20:17:05 <psykose> thanks
2023-01-30 20:17:14 <psykose> well, i guess it's then the same thing but more focused
2023-01-30 20:17:16 <psykose> should be all ok
2023-01-30 20:17:22 <psykose> i split it, should work
2023-01-30 20:17:32 <psykose> do you think it's arm or armh for v6?
2023-01-30 20:17:55 <ikke> good question, I'm not sure
2023-01-30 20:18:05 <psykose> first reference to armh i found is v7
2023-01-30 20:18:18 <ikke> I still have a rpi 1b, but I need to connect it again
2023-01-30 20:18:55 <psykose> ah
2023-01-30 20:18:58 <psykose> they seem to not mean much
2023-01-30 20:19:02 <psykose> https://github.com/util-linux/util-linux/blob/master/sys-utils/setarch.c#L260
2023-01-30 20:19:38 <ikke> ok, armh
2023-01-30 20:22:16 <ikke> psykose: I can adjust it for CI, but not sure how we can use this for lxc
2023-01-30 20:22:58 <psykose> you have `buildrepo` somewhere, make it setarch buildrepo
2023-01-30 20:23:56 <ikke> the mqtt-exec command
2023-01-30 20:27:18 <psykose> mqtt-exec setarch buildrepo
2023-01-30 20:31:25 <vkrishn> psykose: orig url is gone, but stable src is here, https://packages.debian.org/bullseye/mimetex
2023-01-30 20:32:14 <psykose> >source literally gone
2023-01-30 20:32:16 <psykose> >abandoned page
2023-01-30 20:32:26 <psykose> >outputs gif, a format that has been obsolete for like 10 years
2023-01-30 20:32:30 <psykose> yeah, i definitely want to package this
2023-01-30 20:33:07 <psykose> if you want to, you can do it
2023-01-30 20:35:47 <vkrishn> altenative ?
2023-01-30 20:35:54 <EvTheFuture> Created !43697 and I see the lint fails, but it seems to be failing on existing code and not the changes made...
2023-01-30 20:37:26 <psykose> you can ignore it
2023-01-30 21:46:49 <elly> an interesting fyi, since I think we have a lot of packages that fetch github archives: https://github.com/bazel-contrib/SIG-rules-authors/issues/11#issuecomment-1029861300
2023-01-30 21:46:59 <elly> those tarballs are *not* expected to have stable checksums by github
2023-01-30 21:49:12 <ikke> elly: yes, we discussed that just in #alpine-commits :)
2023-01-30 21:57:00 <elly> oh okay, cool
2023-01-30 21:57:43 <ikke> we have 4600 packages having sources from github
2023-01-30 21:58:01 <ikke> and the 3.18 rebuild is mostly going to be affected
2023-01-30 21:58:36 <psykose> (they just regenerated everything, even the refs/tags archives)
2023-01-30 21:58:51 <ikke> Probably just cache invalidation
2023-01-30 21:59:02 <ikke> afaik things are generated on the fly and then cached
2023-01-30 22:00:39 <ikke> For both github and gitlab, these archives are backed by git archive, and dependent on zip / tar + gzip for stability
2023-01-30 22:00:51 <ikke> from time to time, upgrades will change the output
2023-01-30 22:01:43 <psykose> ye
2023-01-30 22:01:54 <psykose> million dollar idea- abuild checksum .tar not .tar.gz
2023-01-30 22:02:51 <elly> that doesn't help, right? the tar part varies
2023-01-30 22:02:59 <elly> since tar encodes a bunch of random state like uid/gid, mtime, etc
2023-01-30 22:03:06 <psykose> that would break in both cases
2023-01-30 22:03:14 <elly> (tar is not a great format for this use)
2023-01-30 22:03:15 <psykose> the compression doesn't hide it
2023-01-30 22:03:34 <psykose> change .tar -> .tar csum changes, .tar.gz csum changes
2023-01-30 22:03:41 <psykose> change compression -> only .tar.gz changes
2023-01-30 22:03:58 <psykose> >The collective amount of human effort it will take to break glass, recover broken build systems that are impacted by this change, and republish artifacts across entire software ecosystems could probably cure cancer.
2023-01-30 22:04:10 <ikke> elly: git archive should keep metadata like mtimes stable
2023-01-30 22:04:16 <psykose> certainly dramatic
2023-01-30 22:04:21 <psykose> ikke: afaik that is not guaranteed
2023-01-30 22:05:06 <psykose> nothing in this whole stack was designed with hashing stability i don't think (i.e. as a goal, long term), seems more like a consequence
2023-01-30 22:05:36 <ikke> I think what git archive provides is stable
2023-01-30 22:05:41 <ikke> but not how it is encoded
2023-01-30 22:09:37 <ikke> relevant: https://lore.kernel.org/git/20b14207-a6f2-033f-3419-271662bffba9@archlinux.org/
2023-01-30 22:13:02 <elly> ahh
2023-01-30 22:14:04 <minimal> elly: its great managing when 2 packages by the same people don't act the same, 1 provides archive/refs/tag downloads, the other provides releases/download/ downloads :-(
2023-01-30 22:17:23 <elly> rip
2023-01-30 22:20:37 <psykose> releases/download implies uploaded binary
2023-01-30 22:20:52 <psykose> i wish we got something a little better than tar, but it's like 20 years too late at this point
2023-01-30 22:21:15 <elly> tar is ok as a format but the tar tool is not quite up to the job of making reproducible archives
2023-01-30 22:22:09 <psykose> yay reverted
2023-01-30 22:22:18 <psykose> elly: i have mostly the opposite opinion
2023-01-30 22:22:28 <ikke> psykose: what is reverted?
2023-01-30 22:22:30 <psykose> tools can be hammered and get separate implementations, but the format is just insane
2023-01-30 22:22:47 <psykose> like there's 5 subtar formats with different rules and various endianness thrown in wtf
2023-01-30 22:22:49 <elly> the format is... easy to improve upon :P
2023-01-30 22:22:50 <psykose> ikke: the change, apparently
2023-01-30 22:22:54 <ikke> source?
2023-01-30 22:22:56 <psykose> https://github.com/bazel-contrib/SIG-rules-authors/issues/11#issuecomment-1409438954
2023-01-30 22:23:00 <psykose> unless this one is trolling
2023-01-30 22:23:03 <elly> psykose: oh yeah, I know :) I did a bunch of archaeology to learn about tar
2023-01-30 22:23:16 <ikke> psykose: ah, better
2023-01-30 22:23:26 <ikke> but sounds like temporary
2023-01-30 22:23:42 <psykose> elly: it certainly lives on quite well though, one doesn't really every learn about it unless digging.. so it works in the end
2023-01-30 22:29:50 <elly> yeah!
2023-01-30 22:30:16 <elly> tar is actually pretty bad for storing archives of directories if you aren't using tape tbh :P
2023-01-30 22:30:20 <elly> but maybe -> #alpine-offtopic
2023-01-31 00:21:04 <psykose> of relevance to the gitpocalypse, the meson overlord has some good words https://public-inbox.org/git/a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com/T/
2023-01-31 00:35:08 <invoked> i laughed, but i'm not sure if i'm supposed to.
2023-01-31 00:45:20 <craftyguy> Piraty: oh it does remain? hmm maybe that test isn't valid then... so yeah having a reliable way to reproduce this would be nice...
2023-01-31 00:46:23 <vkrishn> i had some idea of solving that issue, "2014-11-06 10:04:27 <vkrishn> the solution for just checksum issue is" <- https://irclogs.alpinelinux.org/%23alpine-devel-2014-11.log
2023-01-31 00:47:37 <psykose> that isn't a solution because it requires maintaining way more stuff than one tarball and it is also like, what
2023-01-31 00:47:49 <psykose> 1000x (lit) times slower to validate on any large tarball?
2023-01-31 00:48:12 <vkrishn> yes, only for large tarball
2023-01-31 00:48:32 <psykose> it is orders of magnitude slower even for the smallest of releases
2023-01-31 00:48:37 <vkrishn> buy is is a probable solution for that, fuse mount it
2023-01-31 00:48:42 <psykose> ...
2023-01-31 00:48:56 <vkrishn> but there is^
2023-01-31 00:49:08 <psykose> feel free to implement it and teset
2023-01-31 00:49:10 <psykose> test*
2023-01-31 00:49:11 <psykose> enjoy
2023-01-31 00:49:17 <vkrishn> :)
2023-01-31 00:55:32 <vkrishn> how slow ? have u tested it ?
2023-01-31 00:55:53 <vkrishn> even there is a figure to it 1000x :-)
2023-01-31 01:02:27 <psykose> the onus is on you friend
2023-01-31 01:03:08 <psykose> but sure, i ran sha256sum on rustc-1.67.0-src.tar.xz
2023-01-31 01:03:12 <psykose> 0.6s
2023-01-31 01:03:23 <psykose> i find . -type f -exec sha256sum {} \; the contents
2023-01-31 01:03:28 <psykose> 65s
2023-01-31 01:03:35 <psykose> damn only 100x! guess i got it real wrong
2023-01-31 01:04:32 <psykose> how do i get baited by this every time
2023-01-31 01:10:26 <craftyguy> oh wow, the apkbuild would be enormous if you added the checksums for all files in it. though I guess you could checksum the list of checksums and have that checksum in the apkbuild... but this is getting silly 
2023-01-31 01:11:21 <craftyguy> (I didn't read that IRC log, so I'll go wander off now)
2023-01-31 01:11:42 <psykose> you missed absolutely nothing, trust me
2023-01-31 01:14:02 <elly> craftyguy: some kind of tree of hashes :P
2023-01-31 01:15:28 <vkrishn> divide that by no. of cores if run in parellel
2023-01-31 01:15:46 <vkrishn> :)
2023-01-31 01:16:43 <psykose> ah yes
2023-01-31 01:17:14 <psykose> because instead of just hashing the one thing fast on one thread.. we want to hash it slower still and on all the threads
2023-01-31 01:17:46 <vkrishn> adding checksum sould be devs work, and in there repo
2023-01-31 01:18:11 <vkrishn> coz that needs signinng too, its kind of practice to build upon
2023-01-31 01:18:17 <vkrishn> not easy
2023-01-31 01:18:34 <vkrishn> in their repo^
2023-01-31 01:18:35 <psykose> that's nice can you talk about this awful idea in some other channel now
2023-01-31 01:18:50 <vkrishn> gone, puff
2023-01-31 02:40:48 <sam_> psykose: abby: Piraty: distributions@lists.linux.dev, please subscribe (link on lists.linux.dev / https://subspace.kernel.org/lists.linux.dev.html)
2023-01-31 02:48:54 <sam_> (please do pass on to others too, (idea is "new $X is totally broken oh god", coordination of stuff like time_t, discussing how to handle something new (the github incident would be a good example))
2023-01-31 03:24:45 <craftyguy> Piraty: i think my testing was valid, i was restarting phosh each time i tried a new mesa version. I don't think (?) that gnome-clock would survive that, right?
2023-01-31 04:11:24 <anjan> Hi, can someone please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43654 Sorry for the ping but we need to merge it in sync with pmaports to make sure some things dont break
2023-01-31 04:11:30 <anjan> cc: craftyguy 
2023-01-31 04:11:38 <craftyguy> 
ACTION standing by

2023-01-31 05:11:28 <ikke> 
ACTION is going to merge

2023-01-31 05:37:11 <ikke> craftyguy: ^
2023-01-31 05:39:20 <craftyguy> ikke: thanks!
2023-01-31 05:46:17 <ikke> New discussion around git archive stability: https://lore.kernel.org/git/a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com/T/#u
2023-01-31 09:01:55 <PureTryOut> psykose: you seem to be the maintainer of sdl2. It has a problem causing 64-bit builds of software using sdl2 using a specific include (`SDL_syswm.h`) to fail due to directfb. `/usr/include/directfb/directfb.h:4674:11: error: reference to 'u64' is ambiguous`. CC craftyguy as maintainer of directfb as well I suppose
2023-01-31 09:24:45 <Piraty> sam_: "(the github incident would be a good example)"  which github incident?
2023-01-31 09:27:42 <abby> Piraty: https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/ https://public-inbox.org/git/a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com/T/
2023-01-31 09:27:47 <Piraty> ah i see , git-archive 
2023-01-31 09:28:45 <Piraty> *sigh*
2023-01-31 09:29:46 <Piraty> in essence, build systems should verify the tarball's content checksum, not the tarball
2023-01-31 09:31:50 <Piraty> like xbps-src does (opt-in though, for upstreams that inject weird timestamps in tar header and whatnot)
2023-01-31 09:32:39 <Piraty> what can be so hard about tar -c -f - $(git ls-files | sort) 
2023-01-31 09:33:21 <Piraty> (given some tar flags for reproducibility, which unfortunately depend on the tar impl at hand
2023-01-31 09:52:48 <ikke> The issue is not git archive itself, but more relying on dynamically generated archives to remain stable 
2023-01-31 09:53:34 <ikke> And you generally want to verify the archive before you even unpack it 
2023-01-31 10:43:23 <Piraty> if you provide some pmbootstrap related code snippets and the last commit you found broken, i can continue v
2023-01-31 10:43:23 <Piraty> craftyguy: yeah probably, sorry if that might have appeared arrogant or similar. 
2023-01-31 10:43:30 <Piraty> bisecting
2023-01-31 10:48:17 <Piraty> i didn't have a single crash for nearly a week though, 
2023-01-31 10:48:19 <Piraty> ah. https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198
2023-01-31 11:14:04 <hcs> psykose: I see that you're the maintainer of the community/chromium package. Is this out of choice or necessity?
2023-01-31 11:19:15 <ikke> why not both? :)
2023-01-31 11:20:15 <hcs> That's definitely also a possibility. I was wondering if you guys were open to bringing in a few patches from the ungoogled-chromium project?
2023-01-31 11:21:05 <Newbyte> hcs: just curious, what patches
2023-01-31 11:21:06 <Newbyte> * what patches?
2023-01-31 11:23:49 <hcs> Currently I'm looking at the ones relating to the chrome_crashpad_handler executable. The Chromium maintainers has chosen to ignore the `--disable-breakpad` and `--disable-crash-reporter` options for release builds, and I just want to make them opt-in instead of permanently forced on. I also have a few more patches in mind
2023-01-31 11:24:39 <Newbyte> don't worry, they don't care about bug reports from musl users anyway
2023-01-31 11:25:00 <Newbyte> jokes aside, sounds sensible to me (but I'm not the maintainer of course)
2023-01-31 11:25:32 <ikke> elly here works on chromium
2023-01-31 11:25:54 <ikke> they are working on minimizing the amount of patches we need
2023-01-31 11:29:52 <hcs> Newbyte: sorry, I disconnected for a second there. Did you say anything in the meantime=
2023-01-31 11:30:06 <ikke> Nothing was said
2023-01-31 11:30:24 <Newbyte> hcs: what's the last message you saw before disconnecting? I don't see your disconnect
2023-01-31 11:30:55 <hcs> Last message was "jokes aside"
2023-01-31 11:30:58 <ikke> https://irclogs.alpinelinux.org/%23alpine-linux-2023-01.log
2023-01-31 11:31:04 <hcs> Ah, tyvm
2023-01-31 11:31:07 <ikke> Oh, you might have missed my messages then
2023-01-31 11:34:45 <hcs> Chromium is not my project of course, but I disagree with the decision to outright ignore the commandline switches that they themselves implement. Do you guys think that we should keep the crashpad handler, but allow it to be disabled? Unplug completely? Disable by default (opt-in)?
2023-01-31 11:35:37 <hcs> Ungoogled-chromium has of course completely unplugged it out of spite, but I don't necessarily think that's the right direction for Alpine
2023-01-31 13:00:44 <Piraty> craftyguy: the mesa bug's bisect outcome shows that is first appeared in mesa-22.3.3 which is odd
2023-01-31 13:07:01 <clandmeter> 64 core riscv64 coming
2023-01-31 13:07:38 <clandmeter> https://twitter.com/SipeedIO/status/1620011141639581698
2023-01-31 13:08:35 <ikke> Interesting 
2023-01-31 13:26:18 <Misthios> ^^
2023-01-31 15:38:50 <donoban> talking about improve setup-interfaces, it would nice to have a number selection similar to setup-apkrepos instead having to type the full name 
2023-01-31 16:28:34 <craftyguy> Piraty: ya i saw that, not sure how i screwed up the testing for that then..
2023-01-31 17:31:58 <psykose> hcs: rejected, not interested whatsoever
2023-01-31 17:32:06 <psykose> sam_: thanks!
2023-01-31 17:34:12 <psykose> PureTryOut: can you link a failing builds
2023-01-31 17:38:51 <invoked> re: ungoogled-chromium disabling crashpad, there were good reasons for that, other than spite
2023-01-31 17:45:46 <elly> hello!
2023-01-31 17:46:31 <elly> I don't think crashpad has much use unless you actually have crashes being sent somewhere, which I do not think alpine's build does
2023-01-31 17:47:51 <elly> it *can* make local crash reports for you, which can then be ingested by other tools, and those reports do manage to not be colossal even when chromium is using gigabytes of memory, as it sometimes does
2023-01-31 17:48:27 <elly> if possible I would prefer to make upstream chromium work in a way that satisfies you rather than add additional alpine patches
2023-01-31 17:53:38 <psykose> PureTryOut: i just built 5 separate things that use SDL_syswm.h and they don't fail
2023-01-31 17:53:41 <psykose> please just link what fails next time
2023-01-31 17:53:56 <psykose> i can't read your mind
2023-01-31 18:05:02 <psykose> (if i had to guess, it defines some magic stuff that breaks some of the includes in the chain)
2023-01-31 18:05:21 <psykose> the u64 is defined 10 layers down in some os/something.h and depends on Stuff i guess
2023-01-31 18:05:35 <psykose> but it does work normally, so it's specific to whatever you were building
2023-01-31 18:15:53 <ikke> 3931 packages use dynamic github archies
2023-01-31 18:15:58 <ikke> archives*
2023-01-31 18:24:26 <Habbie> which github briefly broke earlier
2023-01-31 18:24:45 <ikke> yes, which is why I was checking
2023-01-31 18:24:49 <Habbie> https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/
2023-01-31 18:24:51 <Habbie> ack
2023-01-31 18:24:54 <Habbie> do you know if they broke them before?
2023-01-31 18:25:14 <Habbie> i speak to a lot of ports/package maintainers that say "you can't rely on them" (which is github's position, i think) but my impression is that it usually goes well
2023-01-31 18:25:35 <psykose> there are precisely zero other options
2023-01-31 18:26:02 <Habbie> that's true, but if they really sucked, perhaps maintainers could be convinced to do something else
2023-01-31 18:26:32 <ikke> Habbie: a github customer was promised that these hashes are and will be stable
2023-01-31 18:26:36 <Habbie> ah
2023-01-31 18:26:40 <Habbie> well now :)
2023-01-31 18:27:06 <ikke> But this thread is worth a read: https://lore.kernel.org/git/df7b0b43-efa2-ea04-dc5b-9515e7f1d86f@gmail.com/T/#m656f88c00f1250b5b5bb7fa1ad7b3fecd3592d79
2023-01-31 18:27:30 <Habbie> thanks
2023-01-31 18:32:17 <elly> the "other option" would be to fetch github archives and repack them into some stable format
2023-01-31 18:32:43 <elly> which sucks pretty badly and you still have to validate the github archive
2023-01-31 18:43:15 <mercenary> From what I understand, the .tar part of .tar.gz remains stable. So define an alternate checksum over the unzipped contents, and validate archive |gunzip |sha256
2023-01-31 18:48:08 <donoban> there is too much difference on dependencies/cpu|network usage/etc... between checking checksums and just fetching the tag with git?
2023-01-31 18:52:47 <psykose> fetching a git tag has zero checksum validation
2023-01-31 18:53:06 <psykose> it's the same as using the existing auto tarballs and then just not verifying
2023-01-31 18:53:50 <donoban> wops, I thought it uses some internal verification
2023-01-31 18:54:03 <psykose> well, theoretically sure
2023-01-31 18:54:41 <elly> even if git did do such verification, it is really hard-stuck on sha1, which is not particularly safe these days
2023-01-31 18:54:49 <psykose> you can validate that `git rev-parse HEAD` matches if you want
2023-01-31 18:54:51 <psykose> ye
2023-01-31 18:55:13 <psykose> this is also different from authenticity/signature validation, which we don't
2023-01-31 18:55:14 <psykose> do
2023-01-31 18:55:17 <ikke> elly: not true in both cases, git already supports sha256 (though remote communication is still an issue), and for gits usecase, sha1 has not been broken yet
2023-01-31 18:55:50 <elly> I did not know git supports sha256, that is very cool
2023-01-31 18:56:19 <elly> in that case I withdraw my complaint
2023-01-31 18:56:21 <ikke> Brian M Carlson has done a terrific work on adding support for alterntive hashes in git
2023-01-31 18:57:38 <ikke> You can already create repositories that use sha256 and even communicate with remotes that use it
2023-01-31 18:59:28 <elly> I'm intrigued
2023-01-31 19:00:04 <ikke> elly: https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt
2023-01-31 19:05:01 <elly> neat! thank you
2023-01-31 19:34:33 <lmarz> is there any formal thing to make the license team and policy official?
2023-01-31 19:34:47 <ikke> lmarz: Waiting for the next tsc meeting
2023-01-31 19:35:12 <lmarz> ok thanks
2023-01-31 19:38:13 <psykose> good work so far though :)
2023-01-31 19:38:29 <lmarz> thank you very much :)
2023-01-31 19:51:44 <elly> clear licensing for aports?
2023-01-31 19:52:02 <psykose> clear?
2023-01-31 19:53:24 <elly> like "what is the license of the files in the aports repo"
2023-01-31 19:54:19 <psykose> ah
2023-01-31 19:54:31 <psykose> no idea, probably way too late to licence that now
2023-01-31 19:59:42 <pj> blessed licence
2023-01-31 21:10:16 <PabloCorreaGomez[m]> ikke: I am trying to hook up some script that reads some of the files from appstream.alpinelinux.org and only downloads them if they have been modified recently. But I am not being able to make it work. Do you have some idea if that is supposed to work with the current server config (and then the bug is on my side)? Or maybe it is not supported and is something that I could possibly change? 
2023-01-31 21:11:06 <ikke> It's nginx behind traefik
2023-01-31 21:11:37 <ikke> What mechanism are you using
2023-01-31 21:11:40 <ikke> if-modified-since? etag?
2023-01-31 21:11:53 <PabloCorreaGomez[m]> r = get(url, headers={"If-Modified-Since": if_mod_since})
2023-01-31 21:13:42 <ikke> Can you try to send a request?
2023-01-31 21:13:59 <PabloCorreaGomez[m]> If it's not supposed to work or too much of a hazard, I guess I could send two requests, first HEAD to check "Last-modified" and then conditionally download
2023-01-31 21:14:26 <ikke> I think nginx should support that out of the box, right?
2023-01-31 21:15:35 <PabloCorreaGomez[m]> What I read, if there is a proxy in between, not really
2023-01-31 21:15:47 <ikke> Default: 
2023-01-31 21:15:49 <ikke> if_modified_since exact;
2023-01-31 21:16:10 <psykose> it works depending on what the downstream replies
2023-01-31 21:16:32 <psykose> if the downstream replies 304 or some last-modified thing afaik then it would work
2023-01-31 21:16:34 <psykose> if not, then no
2023-01-31 21:16:43 <psykose> if it's only static files then nginx handles it fine too
2023-01-31 21:16:54 <ikke> they are static files
2023-01-31 21:17:10 <PabloCorreaGomez[m]> It's only static files. But then I do not know what's wrong. Let me share a reproducer
2023-01-31 21:17:52 <psykose> it should be `before` not exact then, no
2023-01-31 21:18:55 <psykose> 'exact' requires exact match, i.e. if you do if-modified-since 2005 but the file was modified in 2004 it fails and gives you a 200 and the file
2023-01-31 21:19:04 <psykose> at least by what i'm reading
2023-01-31 21:19:10 <ikke> I found that confusing
2023-01-31 21:19:24 <psykose> me too, but try making it before and see if that fixes it :)
2023-01-31 21:20:12 <ikke> done
2023-01-31 21:21:09 <PabloCorreaGomez[m]> Wow, now it works! You two are amazing!
2023-01-31 21:22:12 <PabloCorreaGomez[m]> Thanks a lot to both!!
2023-01-31 21:22:16 <ikke> yw
2023-01-31 21:26:37 <psykose> could've sworn that was default behaviour..
2023-01-31 21:27:03 <psykose> but i guess it makes sense
2023-01-31 21:27:23 <psykose> it's less about "date" "newer" by default, and more of an exact match (checksum style)
2023-01-31 21:27:34 <psykose> since things usually cache those modified dates themselves
2023-01-31 21:27:46 <psykose> and if you pass the same one you would get a 304 in that case
2023-01-31 21:28:10 <psykose> and things suddenly becoming older might actually warrant an update
2023-01-31 21:28:21 <psykose> it's the safer default, though i would not personally have picked it i think
2023-01-31 21:32:27 <ikke> It's confusing with the header name
2023-01-31 21:44:29 <psykose> oh yeah, certainly
2023-01-31 22:45:32 <psykose> PabloCorreaGomez[m]: don't suppose you'd know why the left gutter on evince can't be resized? there's no part of this that can be dragged to make bigger: https://img.ayaya.dev/EwQ0OFAos6sh