2021-08-01 01:13:49 <timlegge> ncopa:  It can probably wait for an upstream release but imagemagick (specifically imagemagick-perlmagick) depends on perl-dev so should have been bumped for perl 5.34
2021-08-01 01:31:25 <Hello71> bratkartoffel: wondering if you have looked more into openj9 for alpine recently?
2021-08-01 01:37:34 <eletrotupi> heya, I wanted to write an apkbuild for some custom prometheus configuration for one of my servers, but it conflicts with the original configuration and thrown me an error
2021-08-01 01:38:01 <eletrotupi> I started to wonder if that's actually possible
2021-08-01 02:01:36 <Ariadne> use $replaces
2021-08-01 02:10:34 <eletrotupi> ah, thanks
2021-08-01 02:12:05 <eletrotupi> it was quite obvious, I skimmed over the apk reference, but for some dumb reason didn't looked at replaces 
2021-08-01 07:04:18 <fcolista> mps you are amazing! Thanks thousands!
2021-08-01 07:16:50 <mps> gracie mille amico :)
2021-08-01 07:17:32 <mps> fcolista: 
2021-08-01 07:17:32 <mps> Read some other nice and true testimonials from users.
2021-08-01 07:17:58 <mps> hmm, what's happened with my terminal
2021-08-01 07:18:13 <mps> wrong channel, sorry
2021-08-01 07:19:09 <mps> fcolista: if you noticed anything wrong on this https://arvanta.net/alpine/install-armv7-qemu/ please inform me
2021-08-01 07:19:41 <mps> or you have something to improve there
2021-08-01 07:21:13 <mps> fcolista: also have to say, your work on alpine is awesome. you helped me a lot when I started using alpine and making packages
2021-08-01 08:30:34 <fcolista> mps I'll test the armv7 script in a while..thanks for your kind words :) What I love of Alpine community is the willingess of helping each other and try to have friendly group of people working toghether
2021-08-01 08:30:45 <fcolista> *together
2021-08-01 08:50:00 <mps> fcolista: I agree and also I love more that we have people willing to help than some formal entities (councils, tsc, etc)
2021-08-01 09:00:10 <bratkartoffel> Hello71: not yet, sorry. been pretty busy lately, haven't had much time to spare for alpine. it's on my list, not on first position but also not forgotten
2021-08-01 09:38:06 <liske> could somebody please take a look at !22398 (drops another python2 depend :-) ?
2021-08-01 09:47:38 <Ariadne> liske: how will we bootstrap pypy on new architectures?
2021-08-01 09:48:53 <liske> Ariadne: it is already build on all supported archs (upstream); in case we need a pypy-bootstrap it needs to build python2+pypy from scratch
2021-08-01 09:49:11 <Ariadne> is it possible to cross-compile pypy?
2021-08-01 09:50:16 <liske> (the pypy folks stated they will keep maintaining python2 if required)
2021-08-01 09:53:08 <Ariadne> --platform=arm or whatever for cross-compile it seems
2021-08-01 09:53:23 <Ariadne> also --jit-platform=arm
2021-08-01 09:54:14 <flimsypondreed[m]> pypy isn't on py3 yet?
2021-08-01 09:55:09 <ikke> Not fully
2021-08-01 09:55:10 <liske> pypy3 is later build using pypy (MR still WIP)
2021-08-01 09:55:59 <liske> but pypy3 requires pypy to be build
2021-08-01 10:04:01 <Ariadne> its a shame
2021-08-01 10:04:09 <Ariadne> the combination of pypy3 and asyncio seems quite powerful
2021-08-01 10:17:12 <fcolista> mps, the setup and run script for armv7 works fine! Thanks :)
2021-08-01 10:17:25 <fcolista> jsut got this error during the install phase:https://tpaste.us/QrrE 
2021-08-01 10:17:52 <fcolista> anyway, it worked.
2021-08-01 10:17:52 <fcolista> elcome to Alpine Linux 3.15.0_alpha20210730 (edge)
2021-08-01 10:17:52 <fcolista> Kernel 5.13.6-0-edge-virt on an armv7l (/dev/ttyAMA0)
2021-08-01 10:17:52 <fcolista> armv7-dev login: 
2021-08-01 10:26:17 <Ariadne> :)
2021-08-01 10:26:27 <Ariadne> oh, we tagged an edge snapshot?
2021-08-01 10:26:35 <Ariadne> did it include riscv64 minirootfs?
2021-08-01 10:26:42 <Ariadne> if so, can we get docker minirootfs?
2021-08-01 10:33:20 <ikke> Ariadne: https://dl-cdn.alpinelinux.org/alpine/edge/releases/riscv64/alpine-minirootfs-3.15.0_alpha20210730-riscv64.tar.gz?
2021-08-01 10:33:32 <Ariadne> great
2021-08-01 10:33:42 <Ariadne> what do we need to do to get that into docker?
2021-08-01 10:35:00 <ikke> We already have a docker base image, but not shared yet
2021-08-01 10:35:55 <ikke> Basically just a Dockerfile with FROM SCRATCH; COPY rootfs /
2021-08-01 10:36:25 <ikke> I should make a job that pushes the image to alpinelinux/alpine
2021-08-01 10:36:29 <Ariadne> EVE and some other LF projects want to just target riscv64 like they would with any other docker image :P
2021-08-01 10:36:45 <Ariadne> also, speaking of riscv64
2021-08-01 10:36:52 <ikke> yes, but docker does not have builders
2021-08-01 10:36:56 <Ariadne> oh
2021-08-01 10:37:02 <ikke> same with mips64
2021-08-01 10:37:04 <Ariadne> okay, i will umm
2021-08-01 10:37:13 <Ariadne> ping tianon about that
2021-08-01 10:37:25 <Ariadne> tomorrowish
2021-08-01 10:37:34 <Ariadne> i think the builder problem is soon to be solved
2021-08-01 10:37:35 <ikke> reference: https://github.com/alpinelinux/docker-alpine/pull/148
2021-08-01 10:37:36 <flimsypondreed[m]> does qemu support exist for those?
2021-08-01 10:37:54 <ikke> flimsypondreed[m]: we build riscv64 with qemu-user
2021-08-01 10:38:07 <flimsypondreed[m]> very solid yes then
2021-08-01 10:38:19 <Ariadne> there is a meeting later this week to discuss buying servers from t-head (Alibaba's silicon division)
2021-08-01 10:38:26 <Ariadne> to support Alpine riscv64
2021-08-01 10:38:46 <ikke> Do we know where it's going to be hosted?
2021-08-01 10:39:03 <flimsypondreed[m]> oh interesting
2021-08-01 10:39:39 <Ariadne> right now the goal is to get the hardware, but probably where the other CNCF / LF Edge infrastructure is hosted
2021-08-01 10:39:41 <flimsypondreed[m]> cheaper than sifive then?
2021-08-01 10:39:47 <Ariadne> more like
2021-08-01 10:39:52 <Ariadne> 22 cores
2021-08-01 10:39:54 <Ariadne> at 3.5ghz
2021-08-01 10:39:59 <Ariadne> vs 4 cores
2021-08-01 10:40:02 <Ariadne> at 1.5ghz
2021-08-01 10:40:49 <flimsypondreed[m]> quite a gap
2021-08-01 10:40:59 <Ariadne> there are some Huawei server chips coming out,
2021-08-01 10:41:14 <Ariadne> but embargos against Huawei seem like they will be difficult to overcome
2021-08-01 10:49:57 <ikke> https://hub.docker.com/u/riscv64 exists, but I understood it was owned by debian
2021-08-01 10:54:03 <Ariadne> i'll ask in #docker-library
2021-08-01 11:00:45 <skarnet> ah yes, Huawei, the face of China's transparency and respect of human rights
2021-08-01 11:05:10 <mps> fcolista: thanks for report. will look what could cause this bug (I guess it is in grub install scripts somewhere)
2021-08-01 11:06:08 <Ariadne> skarnet: i didn't say the embargos weren't earned :p
2021-08-01 11:06:33 <Ariadne> (also they ripped off the entirety of their networking OS from stolen Cisco IOS source code)
2021-08-01 11:33:05 <mps> we all steal knowledge from long human history
2021-08-01 11:34:30 <mps> we steal algebra and geometry from ancient people, we steal scripts (letters and words) also
2021-08-01 11:35:32 <mps> intellectual property is 'invented' in 19 century to empower greedy corporations
2021-08-01 11:35:57 <Ariadne> sure, but you have to admit that IOS is probably the worst thing to rip off :p
2021-08-01 11:36:00 <Ariadne> its garbage :D
2021-08-01 11:36:19 <mps> Ariadne: fully agree :)
2021-08-01 11:36:46 <Ariadne> and, i don't think breaking into Cisco really earned Huawei any love from the US government
2021-08-01 11:36:52 <mps> that was I want to wrote first, i.e. huawei is not smart :)
2021-08-01 11:37:09 <Ariadne> thats basically where their problems began
2021-08-01 11:37:59 <mps> could be that, but I tend to think these are all geopolitical 'games'
2021-08-01 11:39:01 <Ariadne> i agree
2021-08-01 11:39:25 <Ariadne> unfortunately, riscv64 servers from alibaba can be acquired, but the huawei ones can't be
2021-08-01 11:39:36 <Ariadne> because of things not in any of our control ;/
2021-08-01 11:39:57 <mps> Thucydides wrote long ago 'Peloponnesian War', which looks like we are again there
2021-08-01 11:40:31 <mps> how much they cost
2021-08-01 11:40:41 <Ariadne> no idea
2021-08-01 11:40:47 <Ariadne> will know later this week :D
2021-08-01 11:40:52 <Ariadne> probably not cheap
2021-08-01 11:41:07 <Ariadne> x86 is heavily subsidized verses other archs due to market economics
2021-08-01 11:41:32 <mps> I have some spare money, thinking maybe could buy one
2021-08-01 11:43:01 <Ariadne> i would figure probably around $3000 US range
2021-08-01 11:43:18 <mps> acceptable then to me
2021-08-01 11:44:04 <ikke> oof
2021-08-01 11:44:25 <ikke> Well, it's server hardware
2021-08-01 11:45:38 <mps> though I would like there is (will be soon) riscv64 notebook (or chromebook)
2021-08-01 11:46:50 <Ariadne> i'm enthusiastic about anything non-x86
2021-08-01 11:46:51 <Ariadne> :D
2021-08-01 11:47:34 <mps> M1 ;)
2021-08-01 11:48:46 <mps> I'm quite satisfied with my chromebooks (arm32/64) for about 5 years
2021-08-01 11:49:13 <mps> except their displays which are more mirrors than displays
2021-08-01 11:51:16 <mps> I have 5 still very usable x86_64 laptops around house, they just accumulate dust
2021-08-01 11:52:44 <mps> only use one of them sometimes to work with qemu for armv7, aarch64 and riscv64 for alpine
2021-08-01 12:09:55 <PureTryOut1> Any chance someone with commit access to main could have a look at !23489?
2021-08-01 12:30:01 <ikke> merged
2021-08-01 12:31:31 <mps> why not move bluez to community
2021-08-01 12:32:33 <mps> and adding such dependencies are not good imo, what if someone use bluez with libudev-zero
2021-08-01 12:33:09 <mps> but I understand, *we* are working for pmOS
2021-08-01 12:38:58 <Sheila> reminds me, I should probably spin up a repo for APK Fission+Alpine this week, if we're not dkms-izing zfs.
2021-08-01 12:40:34 <Hello71> bratkartoffel: np, i don't need it myself, just wondering
2021-08-01 12:50:15 <wener> I don't find any riscv server on taobao, kind of interested on riscv
2021-08-01 12:58:37 <PureTryOut1> mps: no need to be so triggered. It's not a pmOS specific change and no Alpine doesn't work for pmOS
2021-08-01 12:59:07 <ikke> +1
2021-08-01 12:59:22 <ikke> I was doubting about the change, I suppose a 'after ..' would be better
2021-08-01 13:35:05 <mps> PureTryOut1: my comment about working for pmOS was intended to be joke, but now I see I forgot smile at the end, sorry
2021-08-01 13:36:21 <mps> PureTryOut1: I really don't think anything bad about pmOS, quite opposite, it is really good os for phones/tablets
2021-08-01 13:36:37 <mps> if I would use linux on phone/tablet that will be only pmOS (actually I have it on one nokia n900)
2021-08-01 13:37:16 <mps> PureTryOut1: and I really appreaciate your work for alpine (and other pmOS devs, ofc) because you did a lot of good work
2021-08-01 13:45:05 <mps> what I don't like is adding such 'deps' to alpine
2021-08-01 13:50:00 <valerius> have to keep the fat off
2021-08-01 13:50:36 <valerius> otherwise the website will need a pull request next to take the words "small" and "simple" off the main page
2021-08-01 13:51:36 <mps> valerius: looking people in about last 20-30 years on the street and elsewhere looks like 'fat' is new featurism :)
2021-08-01 13:52:26 <flimsypondreed[m]> the thiccOS does have a nice ring to it
2021-08-01 13:52:31 <mps> and that reflects on other human activities
2021-08-01 13:53:42 <valerius> yes, I have been joining the trend by mastering fried rice
2021-08-01 13:53:48 <valerius> however I still love a lean distro
2021-08-01 13:55:01 <mps> alpine is (or was) in between, not too fat and not to slim, just enough for normal use cases
2021-08-01 13:55:41 <mps> the moto is/was 'small, simple, secure'
2021-08-01 13:59:54 <flimsypondreed[m]> wow postmarketOS is cool
2021-08-01 14:01:37 <flimsypondreed[m]> how do you keep deps down but keep things working properly though?
2021-08-01 14:01:47 <Hello71> copy alpine
2021-08-01 14:02:44 <ikke> It's difficult, different users have different usecases. So you have 2 options: 1) only cater for specific users and ignore the rest
2021-08-01 14:02:54 <ikke> 2) have a system that is more flexible
2021-08-01 14:02:59 <mps> flimsypondreed[m]: metapackage could/should be solution
2021-08-01 14:03:16 <flimsypondreed[m]> yeah agreed
2021-08-01 14:04:04 <mps> 3) let users decide what s/he needs/wants
2021-08-01 14:04:32 <flimsypondreed[m]> when I install some ubuntu packages in a docker container that use qt, next minute I have an entire xorg, mesa etc installation
2021-08-01 14:04:58 <flimsypondreed[m]> no one wants to do that mps, they're too busy doing real work
2021-08-01 14:05:05 <flimsypondreed[m]> they want things to work, otherwise they go elsewhere
2021-08-01 14:05:08 <mps> flimsypondreed[m]: that is why abandoned debian after 20 years of usage
2021-08-01 14:05:35 <mps> oh, then they should use ubuntu/macos/windows
2021-08-01 14:06:50 <flimsypondreed[m]> I guess you can only compile a package a certain way
2021-08-01 14:07:28 <flimsypondreed[m]> 🤔
2021-08-01 14:08:24 <mps> we (alpine) cannot beat ubuntu/macos/windows in 'easy to use system' but by trying this we will lost our most important value
2021-08-01 14:09:03 <flimsypondreed[m]> yeah, it must be difficult
2021-08-01 14:09:40 <valerius> there is room in the world for "hardcore" distros, not all distros need to have the same goals
2021-08-01 14:10:02 <valerius> as witnessed by the success of this one, there is a significant portion of people who want a lean and powerful distro that does not get in their way
2021-08-01 14:10:19 <flimsypondreed[m]> I wouldn't say it's hardcore, from the very basic stuff I know it's easy to get it to dance and contribute to
2021-08-01 14:10:40 <flimsypondreed[m]> I run it in docker containers though not as the desktop
2021-08-01 14:10:44 <valerius> something that starts small and you can build upon, versus something that starts huge and you must play Jenga with in order to cut the stuff you don't want
2021-08-01 14:11:18 <mps> yes
2021-08-01 14:12:18 <mps> last debian server I switched to alpine took me just few minutes (5-10) while debian apt couldn't resolve needed deps for more than a half hour
2021-08-01 14:12:42 <mps> I canceled it, was nervous to wait
2021-08-01 14:12:57 <valerius> https://www.youtube.com/watch?v=I7H6wGy5zf4
2021-08-01 14:14:27 <mps> I don't understand spoken english especially slangs
2021-08-01 14:15:23 <valerius> well, the main message is that you're pulling pieces out of the foundation and trying to make the tower not collapse... this is how I feel when I deal with a Red Hat or Debian based distro that needs to do a very specific task
2021-08-01 14:16:23 <mps> valerius: right, you describe my experience
2021-08-01 15:03:36 <Thermi> Somebody please take a look at !23411, it's part of kopano
2021-08-01 15:59:45 <orbea> what's wrong with users modifying init files themselves?
2021-08-01 15:59:53 <orbea> just document it somewhere
2021-08-01 16:32:53 <link2xt> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23790 takes forever to link on ARM, probably the runner does not have enough memory
2021-08-01 16:33:19 <link2xt> it timed out after 1 hour, i clicked "rerun" but it's 50 minutes already
2021-08-01 16:34:51 <ikke> link2xt: https://tpaste.us/DXXo 
2021-08-01 16:35:47 <ikke> I agree 55G free memory is a bit on the low side 😑
2021-08-01 16:36:15 <link2xt> then i don't know why it gets stuck linking: https://gitlab.alpinelinux.org/link2xt/aports/-/jobs/451712
2021-08-01 16:37:07 <link2xt> i have succesfully compiled it on raspberry pi with 4G of ram
2021-08-01 16:37:11 <link2xt> on alpine
2021-08-01 16:37:25 <ikke> How long did it take?
2021-08-01 16:37:38 <mps> !23790
2021-08-01 16:38:09 <link2xt> can't remember, but certainly less than 30 minutes
2021-08-01 16:38:33 <link2xt> probably significatnly less
2021-08-01 16:40:53 <link2xt> i had problems with epoll on qemu in the past: https://github.com/async-rs/async-std/issues/900
2021-08-01 16:42:05 <link2xt> could be a similar bug, works on real hardware but fails under qemu
2021-08-01 16:53:11 <ikke> link2xt: I can try to strace to see what it's doing
2021-08-01 16:54:00 <link2xt> that would be nice
2021-08-01 16:54:25 <link2xt> I have an alpine virtualbox VM and can set up a qemu VM to try if the build gets stuck there
2021-08-01 16:57:38 <ikke> Seems like a deadlock
2021-08-01 16:57:57 <ikke> I see all threads waiting on a futex
2021-08-01 16:58:40 <ikke> All using a lot of CPU
2021-08-01 17:19:09 <Ariadne> the CI (except for riscv64) does not use qemu AFAIK
2021-08-01 17:19:24 <ikke> arm*/aarch64 does
2021-08-01 17:19:34 <ikke> just because we have just one host
2021-08-01 17:37:39 <afontain[m]> hi, gentle bump of https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22712
2021-08-01 17:37:39 <afontain[m]> should be ready for review
2021-08-01 17:38:00 <ikke> !22712
2021-08-01 18:19:38 <Ariadne> o
2021-08-01 20:32:48 <link2xt> ikke: deadlock seems to be resolved by compiling using a single job: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23790
2021-08-01 20:34:23 <ikke> So it is jobserver related (like in the last issue you linked to)?
2021-08-01 20:35:04 <link2xt> yes, likely
2021-08-01 20:35:23 <link2xt> probably a different issue, but anyway, this part of cargo has always been problematic
2021-08-01 20:35:27 <ikke> strange then that it only surfaces in qemu
2021-08-01 20:35:54 <ikke> Must say I have not heard it being an issue before on our infra
2021-08-01 20:37:45 <link2xt> I also had problems with async rust and netbsd under qemu (https://github.com/async-rs/async-std/issues/900), maybe something related to low-level details of how rust works with timestamps/interrupts/...
2021-08-01 20:39:22 <link2xt> not necessarily a bug in rust standard library, maybe it just triggers some race conditions that are not hit normally
2021-08-01 20:39:53 <link2xt> maybe possible to try getting the bug out of qemu with rr
2021-08-01 20:40:11 <ikke> rr?
2021-08-01 20:40:18 <ikke> I'm not that versed in rust
2021-08-01 20:40:24 <link2xt> https://rr-project.org/
2021-08-01 20:40:52 <link2xt> it's not rust-related, a debugger to make race conditions reproducible
2021-08-01 20:41:51 <link2xt> anyway, i should try running this particular build under qemu and file an issue into cargo repo if I manage to reproduce it
2021-08-01 21:55:42 <okeuday> ikke: LXC build containers would need limits.cpu config to create CPU quota info that is seen by other software using multiple CPUs like Erlang
2021-08-01 21:56:37 <okeuday> that is my understanding of the problem, if this is a deadlock when attempting to use more than one CPU on the build container
2021-08-01 21:58:22 <okeuday> (i.e., seeing CPUs > 1 and attempting to use CPUs, though the execution is never executed, so the additional CPU usage becomes super-slow causing timeouts)
2021-08-01 22:39:03 <adamplumb[m]> is it possible to test the apkbuild install_if command from just the packages i build with aports?
2021-08-01 22:40:07 <Hello71> install your repository
2021-08-01 22:41:11 <link2xt> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23790 is ready for review
2021-08-01 22:46:32 <adamplumb[m]> <Hello71 "install your repository"> sweet thanks, i added the file:// uri to my repositories file and that did the trick.  And the install_if worked
2021-08-01 22:46:46 <Hello71> you don't need to put file:// but i think it's no difference
2021-08-01 22:47:02 <danieli> iirc i just put the path of the built apks into /etc/apk/repositories
2021-08-01 22:47:15 <Hello71> maybe apk skips cache if direct path? not sure
2021-08-01 22:47:25 <adamplumb[m]> cool, wasn't sure if it needed a uri but thats what i tried first and it worked
2021-08-02 01:36:51 <Ariadne> it becomes URI internally
2021-08-02 09:39:41 <Thermi> Could somebody please review !23411 for me?
2021-08-02 10:02:21 <yyp> Thermi: updating things like fixed versions (sed s/ZPUSHVERSION/...) I suppose should be in prepare()
2021-08-02 10:04:18 <yyp> package() just copies needed files into $pkgdir with no modifications
2021-08-02 10:10:04 <Ariadne> ncopa: would it be possible to get a riscv64 docker image
2021-08-02 10:10:12 <Ariadne> in docker library
2021-08-02 10:21:34 <clandmeter> Ariadne: its not possible
2021-08-02 10:21:50 <clandmeter> at least not yet
2021-08-02 10:21:57 <clandmeter> as docker has no hw to build it
2021-08-02 10:22:30 <Ariadne> tianon told me otherwise
2021-08-02 10:22:42 <clandmeter> i tweeted about it recently, but i got no reply
2021-08-02 10:22:55 <clandmeter> then they dont update their own issues
2021-08-02 10:23:14 <Ariadne> 11:22 AM <tianon> Ariadne: probably an issue (or even a PR) at https://github.com/alpinelinux/docker-alpine, perhaps pointing to https://github.com/docker-library/official-images/pull/10502 (as proof we support it downstream now) :)
2021-08-02 10:23:20 <Ariadne> yesterday
2021-08-02 10:25:07 <clandmeter> ah 
2021-08-02 10:25:14 <clandmeter> the issue is updated
2021-08-02 10:26:02 <Ariadne> :)
2021-08-02 10:26:04 <clandmeter> https://github.com/docker-library/official-images/issues/8794
2021-08-02 10:26:33 <clandmeter> ncopa: do your magic
2021-08-02 10:26:56 <Ariadne> it would be great to get an edge snapshot so we can start doing linuxkit / eve builds on riscv64
2021-08-02 10:27:29 <ikke> We need to make a pull request here: https://github.com/alpinelinux/docker-alpine
2021-08-02 10:27:51 <Ariadne> though riscv64 hardware scene is a dumpster fire
2021-08-02 10:28:16 <Ariadne> lots of BSP kernels, little actually going upstream
2021-08-02 10:28:44 <clandmeter> Ariadne: why are you specifically interested in linuxkit/eve?
2021-08-02 10:29:09 <mps> what is linuxkit?
2021-08-02 10:29:16 <Ariadne> do you want the blunt version
2021-08-02 10:29:28 <clandmeter> any version i understand will do 
2021-08-02 10:29:42 <Ariadne> smiling face with dollar sign emoji
2021-08-02 10:29:45 <Ariadne> :))))
2021-08-02 10:29:54 <ikke> :D
2021-08-02 10:30:20 <clandmeter> i dont understand :p
2021-08-02 10:31:33 <mps> seems like 5.14 kernel will have better support for riscv64, https://lore.kernel.org/lkml/mhng-423e8bdb-977e-4b99-a1bb-b8c530664a51@palmerdabbelt-glaptop/
2021-08-02 10:32:31 <mps> sorry, riscv
2021-08-02 10:33:33 <Ariadne> anyways
2021-08-02 10:34:10 <mps> but yes, I predict riscv eccosystem will be similar to arm jungle
2021-08-02 10:34:19 <Ariadne> clandmeter: the projects i’m involved in regarding riscv64 need it basically
2021-08-02 10:34:51 <Ariadne> mps: linuxkit is a cursed way of making enterprise distributions of alpine
2021-08-02 10:34:58 <Ariadne> blame docker for that one
2021-08-02 10:37:34 <mps> aha, thanks for info where to not look :)
2021-08-02 11:10:07 <Thermi> yyp, ty
2021-08-02 11:10:39 <link2xt> can anyone review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23790 ?
2021-08-02 11:10:59 <link2xt> marked it as ready yesterday, as for me it looks good
2021-08-02 11:11:50 <yyp> Should use cmake -DCMAKE_BUILD_TYPE=None
2021-08-02 11:11:58 <link2xt> what is it for?
2021-08-02 11:12:17 <yyp> CMake ignores build CFLAGS otherwise I think
2021-08-02 11:13:17 <yyp> And there are some useful options for cross-compiling missing, try using `newapkbuild -C` which will fill everything up for a CMake project
2021-08-02 11:14:02 <link2xt> this cmake runs "cargo" internally
2021-08-02 11:15:15 <yyp> Yeah
2021-08-02 11:15:33 <yyp> Not sure why they decided to use CMake in the first place when cargo already does everything
2021-08-02 11:15:45 <yyp> disregard cross-compiling comment
2021-08-02 11:16:32 <link2xt> it's me who added this CMakeLists.txt, it's to allow using it as kdesrc-build module :)
2021-08-02 11:17:07 <link2xt> and to have a single place for running build with defaults suitable for packaging (no vendored libraries etc.)
2021-08-02 11:17:33 <link2xt> also plan to move pkgconfig generation there, currently it is generated by build.rs
2021-08-02 11:18:09 <link2xt> will add -DCMAKE_BUILD_TYPE=None, just in case it somehow propagates flags to linker
2021-08-02 11:18:48 <yyp> No need, actually
2021-08-02 11:19:06 <yyp> Because this is used only when compiling C/C++ using CMake
2021-08-02 11:19:11 <link2xt> this CMakeLists.txt places the library and deltachat.h to correct places too, cargo can't do this
2021-08-02 11:19:26 <yyp> ¯\_(ツ)_/¯
2021-08-02 11:19:38 <yyp> A simple Makefile should work just as well
2021-08-02 11:20:41 <yyp> Also, there's no need to depend on rust because cargo already depends on it
2021-08-02 11:24:11 <link2xt> a simple makefile can't be used with kdesrc-build
2021-08-02 11:25:52 <link2xt> while every package build system knows how to deal with cmake packages
2021-08-02 11:26:47 <link2xt> removed `rust`, added -DCMAKE_BUILD_TYPE=None just in case
2021-08-02 11:30:30 <yyp> Looks good now
2021-08-02 11:34:18 <yyp> I also think this package should be deltachat-core or similar because deltachat sounds like it contains the DeltaChat application, which it doesn't
2021-08-02 11:34:24 <yyp> *should be named
2021-08-02 11:37:14 <link2xt> it contains libdeltachat library, that's why it's named deltachat
2021-08-02 11:37:55 <link2xt> cargo workspace is named deltachat, library is libdeltachat, header is deltachat.h etc.
2021-08-02 11:38:25 <yyp> In which package should the deltachat application be then?
2021-08-02 11:38:28 <link2xt> apps are going to be deltachat-desktop (electron-based) and kdeltachat (kirigami/qt-based)
2021-08-02 11:38:31 <Ariadne> it should probably be named libdeltachat then
2021-08-02 11:38:42 <yyp> ^
2021-08-02 11:44:01 <yyp> I strongly dislike naming libraries by the name of an associated application
2021-08-02 11:44:18 <link2xt> it's libdeltachat then
2021-08-02 11:44:21 <yyp> Someone tries to find Alpine package for deltachat and the first result will be the library, uh
2021-08-02 11:46:41 <mps> yyp: agreed
2021-08-02 11:47:05 <mps> s/agreed/I agree/
2021-08-02 11:47:05 <alpine-meetbot> mps meant to say: yyp: I agree
2021-08-02 11:47:55 <mps> if possible always use lib{$pkgname}
2021-08-02 11:54:46 <link2xt> CI is running
2021-08-02 11:55:40 <link2xt> I don't plan to package https://git.sr.ht/~link2xt/kdeltachat yet, although it may be useful for postmarketos
2021-08-02 11:56:07 <link2xt> for now packaging just to make it easier to run bots off the raspberrypi
2021-08-02 11:56:51 <link2xt> having a package is easier than trying to create python wheels for musl-based distro
2021-08-02 11:58:20 <ikke> maxice8: please make sure you stop redundant pipelines on large merge requests
2021-08-02 11:58:57 <maxice8> noted, assumed it would automatically cancel old pipelines after a push
2021-08-02 11:59:52 <ikke> We have that option enabled, but apparently it does not work for MR pipelines
2021-08-02 12:01:46 <maxice8> detached MR pipelines have been a constant source of annoyances for aports-qa-bot too
2021-08-02 12:55:48 <Thermi> yyp, I reworked the MR somewhat. Do you have more comments about it? !23411
2021-08-02 13:25:41 <Ariadne> btw
2021-08-02 13:26:00 <Ariadne> openssl 3.0 is headed for `testing` today as `testing/openssl3.0`
2021-08-02 13:37:13 <Hello71> it's not actually released yet, right?
2021-08-02 13:37:54 <Ariadne> they are doing release candidates
2021-08-02 13:38:42 <Ariadne> i am primarily interested in it, because of the license fix
2021-08-02 13:38:43 <Ariadne> :p
2021-08-02 13:38:57 <Ariadne> the "current" openssl license is quite unfortunate
2021-08-02 13:47:03 <valerius> what is the license fix exactly?
2021-08-02 13:48:33 <orbea> old license: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1k/LICENSE new license: https://github.com/openssl/openssl/blob/master/LICENSE.txt
2021-08-02 13:51:55 <valerius> ok, a switch to Apache 2.0 license instead of tweaks to the old weird license
2021-08-02 13:52:18 <Ariadne> valerius: openssl 1.x is under a pair of custom licenses which have several advertising clauses
2021-08-02 13:52:32 <Ariadne> openssl 3.x is under apache
2021-08-02 13:53:18 <Ariadne> this is why if you want to use openssl with GPL, you have to have the "OpenSSL linking exception" rider
2021-08-02 13:53:19 <valerius> glad to see it switch to a standard license
2021-08-02 13:53:36 <Ariadne> switching to apache basically fixes that
2021-08-02 13:53:55 <ikke> (because GPL does not allow additional restrictions)
2021-08-02 13:54:48 <Hello71> imo the new license is an improvement, but the license change process is/was dubious
2021-08-02 13:54:55 <ikke> example: https://scancode-licensedb.aboutcode.org/openvpn-openssl-exception.html
2021-08-02 13:55:06 <valerius> Hello71, what percentage of license changes are not dubious? :p
2021-08-02 13:56:14 <Hello71> reminds me of canonical's "realist" legal reasoning: the logic doesn't really make sense, but they can make more money this way, and if anyone sues they have enough lawyers to defend
2021-08-02 13:57:02 <Hello71> valerius: mpv did a better job of it, first you contact people (and do a better job of it than just putting up a blog post), then if people don't respond, you remove their code
2021-08-02 13:57:12 <Hello71> you don't just say "ah, cba, fuck em"
2021-08-02 14:06:56 <Ariadne> i agree, but
2021-08-02 14:07:07 <Ariadne> i also don't really care
2021-08-02 14:07:16 <Ariadne> the real fix is to quit using openssl altogether
2021-08-02 14:07:18 <Ariadne> :p
2021-08-02 14:07:34 <danieli> if only there were any decent alternatives
2021-08-02 14:08:12 <orbea> libressl still seems somehow more decent still with some rough edges...
2021-08-02 14:09:37 <Ariadne> libressl does not solve the problem
2021-08-02 14:09:53 <Ariadne> the problem is that the openssl API is poorly designed, and is basically a footgun
2021-08-02 14:10:03 <orbea> yea...
2021-08-02 14:10:10 <link2xt> libressl will keep using old license because its maintainers don't agree with openssl 3.0 license change
2021-08-02 14:10:11 <danieli> oh yeah, but that's not a problem that can be fixed very easily
2021-08-02 14:10:25 <kunkku> openssl API is also poorly documented
2021-08-02 14:10:42 <kunkku> you have to read the code to avoid shooting yourself
2021-08-02 14:10:42 <danieli> link2xt: ... what? the new one is literally just Apache 2
2021-08-02 14:11:04 <valerius> maybe the process is what they take umbrage with
2021-08-02 14:11:46 <orbea> there aren't any good choices, openssl just seems less trustworthy the way they keep adding more potential footguns
2021-08-02 14:12:03 <orbea> and also their build system is atrocious
2021-08-02 14:12:10 <Ariadne> anyway, `apk add openssl3.0-dev` if you want to compile against openssl 3
2021-08-02 14:12:11 <Ariadne> :p
2021-08-02 14:12:11 <link2xt> libressl will not switch to apache 2.0 afaik
2021-08-02 14:12:15 <danieli> alpine used libressl for a while, but it was just sub-par when it came to features
2021-08-02 14:12:38 <ikke> And it broke compattibility
2021-08-02 14:12:38 <link2xt> Ariadne: libressl partially fixed API problem by introducing libtls API
2021-08-02 14:12:57 <Ariadne> link2xt: good for it, libressl is never happening in alpine
2021-08-02 14:13:14 <Ariadne> we have libretls if you want to use libtls api
2021-08-02 14:13:37 <Ariadne> we already tried libressl, it did not work out
2021-08-02 14:13:58 <link2xt> there is libtls port for openssl: https://git.causal.agency/libretls/
2021-08-02 14:14:11 <Ariadne> yes
2021-08-02 14:14:19 <Ariadne> you can use it: `apk add libretls-dev`
2021-08-02 14:14:28 <link2xt> 
ACTION pasted url before reading

2021-08-02 14:24:25 <Hello71> openbsd is opposed to apache license: https://www.openbsd.org/policy.html
2021-08-02 14:25:57 <danieli> Hello71: that's good for them - how is it relevant for us?
2021-08-02 14:26:10 <Hello71> 14:10 <danieli> link2xt: ... what? the new one is literally just Apache 2
2021-08-02 14:26:20 <orbea> their reasoning sounds fine to me, not that I am a lawyer
2021-08-02 14:26:21 <Hello71> i am explaining why libressl doesn't want to use apache 2
2021-08-02 14:26:44 <danieli> right, fair enough, they're free to make their choice
2021-08-02 15:15:07 <Hello71> today in "cmake sucks": Target "xea2kmt" links to target "Qt5::WebKitWidgets" but the target was not found. well, look at xea2kmt, right? https://github.com/KDE/kmymoney/blob/master/tools/CMakeLists.txt wait, it doesn't use webkitwidgets? ok ok, maybe it's related to kmm_mymoney? https://github.com/KDE/kmymoney/blob/master/kmymoney/mymoney/CMakeLists.txt#L108 but wait, that
2021-08-02 15:15:09 <Hello71> doesn't use webkitwidgets either? and ENABLE_WEBENGINE is enabled, and there are no other references to webkitwidgets in the whole source tree? well, turns out that Alkimia::alkimia is installed somewhere in /usr and requires webkitwidgets
2021-08-02 15:15:53 <Hello71> could cmake tell you that? sure, but why do that when you can instead go fuck yourself with spam errors
2021-08-02 15:16:27 <Ariadne> is there any day where cmake doesn't suck?
2021-08-02 15:24:40 <danieli> there is not
2021-08-02 16:53:15 <link2xt> what happens to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23790 next? all tests passed
2021-08-02 16:53:37 <ikke> link2xt: you have to have a bit of patience
2021-08-02 16:54:13 <ikke> There are more merge requests waiting for someone the merge it, usually someone will get to it in a reasonable amount of time
2021-08-02 16:54:50 <link2xt> ok, just checking that i'm not missing something
2021-08-02 17:37:43 <knuxify> i'm adding a new package and i get the following error when i build it (right at the end at some checksum calculations): "mktemp: failed to create file via template ‘/tmp/tmp.XXXXXXXXXX’: Permission denied". ci on the alpine gitlab says "mktemp: (null): Permission denied" at the same step. what could this be caused by?
2021-08-02 17:38:20 <knuxify> (hopefully this is the right place to ask about this - i wasn't sure if "quick support questions" for #alpine-linux included packaging efforts :p)
2021-08-02 17:41:30 <Ariadne> it is
2021-08-02 17:42:09 <Ariadne> it sounds like you have a tmpfs that abuild cannot write to btw
2021-08-02 17:47:06 <knuxify> every other package builds just fine though, this only happens for this one particular package
2021-08-02 17:47:12 <knuxify> plus it happens on CI too
2021-08-02 18:25:48 <Ariadne> so weird
2021-08-02 18:25:51 <Ariadne> do you have a CI log
2021-08-02 18:28:04 <knuxify> https://gitlab.alpinelinux.org/knuxify/aports/-/jobs/452775
2021-08-02 18:33:49 <Ariadne> very strange
2021-08-02 18:34:14 <Ariadne> my guess is that there is something in the package filesystem that abuild-sign doesn't like
2021-08-02 18:34:23 <ikke> I can try to strace it
2021-08-02 18:47:03 <danieli> that is pretty odd, clementine (iirc) doesn't do any super weird stuff during its build process
2021-08-02 18:47:33 <danieli> oh, odd, it looks like it might be an issue triggered by abuild
2021-08-02 18:47:40 <ikke> hmm
2021-08-02 18:47:44 <ikke> did you repro it?
2021-08-02 18:47:58 <danieli> no - but i can try
2021-08-02 18:48:13 <danieli> i've bulit clementine plenty of times before (in other environments, not alpine)
2021-08-02 18:48:55 <ikke> Oh, I was just about to
2021-08-02 18:59:03 <Thermi> Please somebody review !23411 for me
2021-08-02 19:22:28 <ikke> Thermi: I left feedback
2021-08-02 19:23:37 <Thermi> ikke, tyvm
2021-08-02 19:30:31 <ikke> knuxify: I can reproduce it btw
2021-08-02 19:33:43 <ikke> open("/tmp/tmp.DJhEdK", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EACCES (Permission denied)
2021-08-02 19:35:26 <Ariadne> but why
2021-08-02 19:35:57 <ikke> stat("/tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
2021-08-02 19:36:09 <ikke> At least there, the permissions seems to be still ok
2021-08-02 19:38:03 <Thermi> ikke, regarding https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23411#note_171475
2021-08-02 19:38:17 <Thermi> ikke, should I put kopano into pkggroups, too, although it's not used in the APKBUILD?
2021-08-02 19:38:23 <ikke> No
2021-08-02 19:38:26 <Thermi> Okay, ty
2021-08-02 19:40:37 <ikke> Ariadne: drwxr-xr-x    1 root     root          4096 Aug  2 18:57 /tmp
2021-08-02 19:40:45 <ikke> Doesn't seem to be a permission issue
2021-08-02 19:41:33 <knuxify> it does seem like after trying to build clementine and getting this error every other package gets the same thing now
2021-08-02 19:41:42 <ikke> seems like /tmp is affected
2021-08-02 19:41:52 <ikke> touch /tmp/foo fails
2021-08-02 19:42:07 <Hello71> is it read-only
2021-08-02 19:42:17 <Hello71> also why isn't it sticky
2021-08-02 19:42:41 <ikke> Hello71: no, it's not read-only
2021-08-02 19:42:55 <Hello71> o=r-x
2021-08-02 19:43:01 <Hello71> should be rwt
2021-08-02 19:43:01 <ikke> right
2021-08-02 19:43:04 <ikke> 0755
2021-08-02 19:43:10 <ikke> so it _is_ a permission issue
2021-08-02 19:43:19 <Hello71> 1777
2021-08-02 19:43:23 <knuxify> crossreferencing with a chroot - it does seem like it gets changed:
2021-08-02 19:43:24 <ikke> let's see what touches it
2021-08-02 19:43:26 <knuxify> drwxrwsrwt    4 root     1000          4096 Jul 29 09:42 tmp
2021-08-02 19:43:38 <knuxify> (these are the perms i found in a chroot)
2021-08-02 19:43:52 <Hello71> i think linux setgid directory is noop
2021-08-02 19:44:18 <ikke> ok, nothing in rootpkg
2021-08-02 19:44:21 <Hello71> why is your tmp group 1000, that's more ridiculous lol
2021-08-02 19:44:22 <ikke> so something in the build
2021-08-02 19:44:37 <ikke> obviously something is touching it
2021-08-02 19:45:34 <ikke> Somethign in the cmake files?
2021-08-02 19:46:44 <ikke> hmm, weird
2021-08-02 19:48:45 <ikke> so it's not clementine
2021-08-02 19:50:02 <ikke> I can build clementine, and /tmp is still fine
2021-08-02 20:09:16 <ikke> :-/
2021-08-02 20:09:29 <ikke> Just retried it: "drwxrwxrwt    1 root     root          4096 Aug  2 20:02 /tmp"
2021-08-02 20:17:50 <Thermi> ikke, install -d foo and mkdir -p foo are effectively the same, aren't they?
2021-08-02 20:18:59 <ikke> yes, but install -D and mkdir -p not
2021-08-02 20:19:40 <ikke> with install -D, you can move a file to a location, and make sure all parent directories are created at the same time
2021-08-02 20:19:52 <ikke> so you do not need to create the directories in advance
2021-08-02 20:20:07 <Thermi> that about -D is actually not true, I discovered
2021-08-02 20:20:26 <Thermi> Let me figure out the details
2021-08-02 20:23:39 <Thermi> I have two files that need to go into "$pkgdir/usr/bin/"
2021-08-02 20:23:49 <Thermi> with install -Dm 0755 /home/buildozer/aports/testing/z-push/src/z-push-admin /home/buildozer/aports/testing/z-push/src/z-push-top /home/buildozer/aports/testing/z-push/pkg/z-push/usr/bin/
2021-08-02 20:23:56 <Thermi> install: target '/home/buildozer/aports/testing/z-push/pkg/z-push/usr/bin/' is not a directory: No such file or directory
2021-08-02 20:24:02 <Thermi> with -Dmt, the same
2021-08-02 20:24:35 <Thermi> I'd expect install to create all leading directories, bin, too, because of -D and then copy the two files into there
2021-08-02 20:29:45 <Hello71> you need to give the filename for -D
2021-08-02 20:30:25 <Hello71> it doesn't make sense
2021-08-02 20:32:14 <Thermi> Even though the correct file names could be deduced from the basename of the leading arguments, and that the last argument is a directory can be deduced from the trailing /
2021-08-02 20:32:48 <Hello71> yes
2021-08-02 20:33:12 <Hello71> same problem occurs with only one source
2021-08-02 20:35:07 <Thermi> That problem can be "resolved" by resorting to mkdir -p and cp
2021-08-02 20:35:37 <Thermi> Otherwise I'd need to write a for loop over all source files and the compose directions using, for example, basename
2021-08-02 20:36:08 <ikke> Thermi: in any case, prepare() is not the right location for creating things in pkgdir
2021-08-02 20:36:31 <Thermi> ikke, Yes, I'm moving it.
2021-08-02 21:37:40 <riverdc> omni: could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23080 when you have a moment? thanks
2021-08-03 08:19:53 <donoban>  
2021-08-03 08:20:28 <donoban> (wops) good morning :)
2021-08-03 08:24:47 <wej> good morning
2021-08-03 08:45:17 <Ariadne> grrrrrrr
2021-08-03 08:45:46 <Ariadne> Thermi: your `testing/kopano-webapp` package stalls the builders :(
2021-08-03 08:46:25 <ncopa> good morning
2021-08-03 09:37:32 <Ariadne> i would like to point out that build-edge-x86_64 has been building `testing/kopano-webapp` for like 18 hours now
2021-08-03 09:37:40 <Ariadne> can we, uhh
2021-08-03 09:37:44 <Ariadne> kick it or something
2021-08-03 09:43:12 <Ariadne> :(
2021-08-03 09:45:40 <knuxify> out of curiosity - is there an auto-timeout on the build server or do misbehaving build have to be stopped manually?
2021-08-03 09:45:46 <knuxify> *misbehaving builds
2021-08-03 09:46:20 <Ariadne> manually
2021-08-03 09:48:31 <Newbyte> maybe it would be useful to automatically kill builds after a certain timeout and mark packages that are known to take long in the APKBUILD somehow?
2021-08-03 09:48:40 <Ariadne> wow
2021-08-03 09:48:47 <Ariadne> great idea
2021-08-03 09:49:11 <Ariadne> unfortunately, not architecturally possible
2021-08-03 09:49:20 <Ariadne> in the current iteration
2021-08-03 09:50:40 <Ariadne> ncopa: can you help with this `build-edge-{x86,x86_64,s390x}` issue ?
2021-08-03 10:00:59 <Newbyte> yeah, and there are also many questions I can think of, e.g. when this should be used (only on builders? also in CI? always when using abuild) and what the implications of that would be, and how you ensure all currently slow-building packages are migrated, and so on
2021-08-03 10:01:31 <Newbyte> not sure it would be worth the complexity
2021-08-03 10:05:12 <mps> don't understand why we need this kopano app in alpine
2021-08-03 10:21:46 <danieli> mps: someone else might need it :)
2021-08-03 10:25:08 <mps> danieli: not sure is it good idea to make package of such things, especially because it can be lot easier to setup in docker
2021-08-03 10:25:38 <danieli> the same can be said about a lot of software that's already in the repos though
2021-08-03 10:25:56 <Newbyte> yeah, with that reasoning we could throw out a lot of desktop software and tell people to use Flatpak
2021-08-03 10:26:42 <mps> no, your reasoning is wrong
2021-08-03 10:27:20 <Newbyte> Why?
2021-08-03 10:28:22 <mps> because desktop apps are intended to be packaged as distro pkgs
2021-08-03 10:29:49 <danieli> electron would beg to differ
2021-08-03 10:30:18 <mps> yes, electron is not needed on alpine
2021-08-03 10:30:30 <danieli> I need certain applications built on CEF, electron or otherwise
2021-08-03 10:30:46 <mps> well /o\
2021-08-03 10:45:56 <Ariadne> anyway,
2021-08-03 10:46:04 <Ariadne> i have no objection to the package being in alpine
2021-08-03 10:46:10 <Ariadne> not everyone wants to use docker
2021-08-03 10:46:18 <Ariadne> i do have objection to it messing up the builders :p
2021-08-03 10:46:36 <mps> maybe something similar to ubuntu PPA
2021-08-03 11:11:09 <danieli> if some packages are to be rejected, there should probably be some written guidelines describing which ones and why
2021-08-03 11:11:28 <danieli> but i agree with Ariadne, i don't mind including software as long as it doesn't mess things up
2021-08-03 11:11:59 <Ariadne> as long as it is legal to distribute and not a gaping security hole that is SUID :p
2021-08-03 11:12:39 <danieli> even then it should be up to users to decide if they want to shoot themselves in the foot imo
2021-08-03 11:12:48 <danieli> but there should probably be a big red warning somewhere in those cases
2021-08-03 11:18:53 <mps> there are some (maybe a lot) of pkgs in aports which are practically unmaintained
2021-08-03 11:19:43 <mps> I think 'line' should be drawn somewhere
2021-08-03 11:21:07 <mps> and I thinks TSC (or devs) should say 'no' sometimes in some cases
2021-08-03 11:22:18 <mps> do we need/want solid distro or 'trashcan' (rhetorical question)
2021-08-03 11:23:08 <danieli> your trash may be someone else's treasure
2021-08-03 11:23:19 <mps> lol
2021-08-03 11:23:24 <danieli> so it'd have to be objective and not vague
2021-08-03 11:25:09 <mps> these mindsets 'says' that everything is vague (not intended as answer to danieli)
2021-08-03 11:25:53 <mps> everything is good and everything is bad :)
2021-08-03 11:26:41 <valerius> lots of people love trash
2021-08-03 11:26:45 <danieli> philosophical questions might be a bit out of scope
2021-08-03 11:26:45 <valerius> :)
2021-08-03 11:27:23 <mps> philosophical reasoning is normal for people who thinks
2021-08-03 11:28:00 <valerius> it is difficult for a distro to accommodate everyone and that is why we have such diversity in distros
2021-08-03 11:28:09 <valerius> there is nothing wrong with creating a mission statement and sticking to it
2021-08-03 11:28:19 <valerius> lots of people will come along and say "hey, wouldn't it be cool if..."
2021-08-03 11:28:24 <mps> well, yes
2021-08-03 11:28:31 <valerius> that perhaps aligns with a different distro
2021-08-03 11:28:44 <valerius> it should not mean a change of direction to accommodate every possible fleeting idea
2021-08-03 11:28:45 <mps> I prefer pragmatic and practical
2021-08-03 11:29:23 <valerius> I say this generally, it applies to all software projects
2021-08-03 11:29:37 <mps> besides 'small, simple, secure' :)
2021-08-03 11:30:55 <valerius> it even applies to music, consider when your favourite band sold out and from that point forward their music sucked because they tried to appeal to everyone
2021-08-03 11:31:21 <mps> for example Ariadnes yesterday add of openssl3 is pragmatic, imo
2021-08-03 11:31:22 <danieli> i don't quite agree with that analogy, but i see what you¨'re getting at
2021-08-03 11:32:50 <mps> valerius: now really OT, but best music is when you sing and don't depend on any 'third party' ;)
2021-08-03 11:53:12 <Ariadne> mps: well that is how we have always done openssl, since they break the API with every new version
2021-08-03 11:53:44 <Ariadne> eventually, testing/openssl3.0 will become main/openssl
2021-08-03 11:53:53 <Ariadne> but for now, we want to test
2021-08-03 11:55:56 <Ariadne> going to do security upgrade of OpenEXR to 3.1.1
2021-08-03 11:56:08 <Ariadne> don't know yet if it will be backported to 3.14
2021-08-03 11:56:16 <Ariadne> depends on how ugly the rebuild is
2021-08-03 12:55:14 <Hello71> mps: !23041
2021-08-03 13:38:29 <minimal> is anyone actively maintaining mkinitfs code? I submitted a MR 2 weeks ago that I'm keen to get included in a new version (so hopefully it could make Alpine 3.15)
2021-08-03 13:38:50 <minimal> this is the mkinitfs repo, not the mkinitfs aports package...
2021-08-03 13:44:27 <clandmeter> minimal: normally ncopa does that, and mostly he checks those subprojects before doing a release.
2021-08-03 13:45:14 <Ariadne> i hate multimedia projects
2021-08-03 13:45:39 <Ariadne> if it is fragile code and dodgy practices like `git clone` inside `./configure`, it's probably a multimedia project
2021-08-03 13:45:58 <Hello71> or scientific
2021-08-03 13:46:44 <clandmeter> minimal: i dont see your MR's?
2021-08-03 13:46:53 <minimal> clandmeter: checking it shortly before the 3.15 release might be a bit late in the day if any substantial changes are requested for any MRs...
2021-08-03 13:47:04 <minimal> clandmeter: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/86
2021-08-03 13:47:30 <Ariadne> right now i wonder who allowed `testing/openimageio` in
2021-08-03 13:47:35 <Ariadne> there is a lot of problems :D
2021-08-03 13:48:03 <Hello71> <checks history> it was Ariadne 
2021-08-03 13:48:09 <Ariadne> ?
2021-08-03 13:48:22 <Ariadne> was it really
2021-08-03 13:48:25 <Hello71> idk :p
2021-08-03 13:48:36 <Ariadne> i dont think i would have signed off on this package
2021-08-03 13:48:47 <Ariadne> i'll let a lot of things fly, but not a circular dependency
2021-08-03 13:48:53 <Ariadne> how did it even pass CI :D
2021-08-03 13:49:24 <Hello71> ah, friggin blender
2021-08-03 14:07:10 <Ariadne> why
2021-08-03 14:07:13 <Ariadne> do we have blender
2021-08-03 14:07:20 <Ariadne> does it even work
2021-08-03 14:07:28 <Ariadne> i would figure it would want like
2021-08-03 14:07:33 <Ariadne> 100GB thread stacks
2021-08-03 14:07:36 <Ariadne> and just die on musl
2021-08-03 14:08:41 <Ariadne> make[2]: *** No rule to make target 'ext/dist//usr/lib/libHalf-2_4.a', needed by 'src/OpenColorIO/libOpenColorIO.so.2.0.1'.  Stop.
2021-08-03 14:08:44 <Ariadne> what
2021-08-03 14:09:08 <Ariadne> ok
2021-08-03 14:09:10 <Ariadne> you know what
2021-08-03 14:09:12 <Ariadne> fuck opencolorio
2021-08-03 14:10:05 <Ariadne> someone else can figure this out
2021-08-03 14:10:25 <Ariadne> if people actually want to maintain blender in alpine, all of its dependencies wouldn't be 2 years out of date
2021-08-03 14:11:27 <Ariadne> i've wasted enough time on this for now :P
2021-08-03 14:17:40 <knuxify> tbh, i'm kinda considering just dropping tests entirely in !23625. the failures seem pretty arbitrary, especially since they also happened on the previous version of the code when i just added one switch to configure which shouldn't have touched any other code
2021-08-03 14:17:54 <knuxify> could someone with an arm/ppc machine test this out?
2021-08-03 14:18:42 <knuxify> (minus the "remove --disable-static" commit)
2021-08-03 14:19:13 <Ariadne> a lot of upstream 'tests' are testing the wrong thing
2021-08-03 14:19:44 <Ariadne> its good to run the tests, but if they are testing nonsensical things, better to just skip the testsuite
2021-08-03 14:19:49 <Ariadne> quality matters :)
2021-08-03 14:20:36 <Ariadne> a great example is OpenEXR's testsuite, which assumes you are on an x86_64
2021-08-03 14:20:38 <Ariadne> :D
2021-08-03 14:20:51 <knuxify> i mean, i'm mostly just afraid i'll accidentally break some program that depends on it :p
2021-08-03 14:21:13 <knuxify> although i guess if upstream is barely maintained at this point i can get a pass /shrug
2021-08-03 14:21:58 <knuxify> i'll probably try to skip tests and try to run nm-applet and blueman tests, which (assuming they test libappindicator support) should probably tell us if the package actually works or not
2021-08-03 14:22:20 <knuxify> *skip tests on libappindicator and run nm-applet/blueman tests afterwards
2021-08-03 14:24:04 <Thermi> Ariadne, do you have a pipeline # for me?
2021-08-03 14:24:13 <Thermi> (regarding <Ariadne> Thermi: your `testing/kopano-webapp` package stalls the builders :()
2021-08-03 14:24:23 <Ariadne> Thermi: the real builders don't use gitlab CI
2021-08-03 14:24:30 <Ariadne> it died on most of them
2021-08-03 14:24:37 <Ariadne> we had to manually stop it
2021-08-03 14:24:37 <Ariadne> :D
2021-08-03 14:30:31 <knuxify> is the armhf gitlab ci builder a vm?
2021-08-03 14:30:57 <Ariadne> i think its qemu user
2021-08-03 14:31:48 <knuxify> i just tried building the original libappindicator via pmbootstrap (which uses qemu) and got this error during tests: qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
2021-08-03 14:31:50 <knuxify> Client: Exited with status 5
2021-08-03 14:32:07 <knuxify> so it could be that there's some failure that's qemu-specific
2021-08-03 14:32:23 <knuxify> ...oooor i'm doing something wrong :p
2021-08-03 14:33:26 <Ariadne> strange
2021-08-03 14:33:38 <Ariadne> maybe the testsuite is doing something idiotic
2021-08-03 14:37:05 <knuxify> wait nvm that one might've been an intended failure
2021-08-03 15:02:04 <Thermi> Ariadne, oh ffs. What exact software are they using? Do you have logs?
2021-08-03 15:02:27 <Ariadne> `buildrepo` in an LXC container
2021-08-03 15:02:31 <Ariadne> and, yes
2021-08-03 15:02:42 <Thermi> Please share them with me
2021-08-03 15:03:06 <Ariadne> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/kopano-webapp/kopano-webapp-5.2.0-r0.log
2021-08-03 15:03:11 <Ariadne> it was stuck at
2021-08-03 15:03:12 <Ariadne> "     [exec] 1895 translated messages, 25 untranslated messages."
2021-08-03 15:03:14 <Ariadne> for 18 hours
2021-08-03 15:03:17 <Ariadne> before it was killed
2021-08-03 15:03:18 <Ariadne> :)
2021-08-03 15:05:39 <Thermi> tyvm
2021-08-03 15:08:54 <ikke> CI is qemu-system-aarch64
2021-08-03 15:09:18 <Ariadne> o
2021-08-03 15:09:26 <Ariadne> under KVM, or is it emulated ?
2021-08-03 15:09:32 <ikke> kvm
2021-08-03 15:14:13 <Thermi> Ariadne, the LXC container is running code from edge, isn't it?
2021-08-03 15:15:50 <ikke> it is
2021-08-03 15:16:00 <ikke> the builder updates itself after it has built everything
2021-08-03 15:16:41 <Thermi> Can I get the same packages via the edge repos?
2021-08-03 15:17:38 <ikke> After they have been uploaded, yes
2021-08-03 15:19:42 <Thermi> So I should be able to run the same software as the builders, by upgrading from edge?
2021-08-03 15:21:22 <ikke> yes
2021-08-03 15:21:37 <ikke> At least, from what they uploaded
2021-08-03 16:01:36 <riverdc> is there a general policy for when libraries for some language may be included in aports?
2021-08-03 16:05:11 <riverdc> there are no existing haskell libraries in aports, for example, and I'd like to package some software (agda) that has build-time dependencies on many haskell libs
2021-08-03 16:06:50 <ikke> haskell is hard to package as individual libs
2021-08-03 16:07:02 <mps> hah, very nice, jirutka saved me testing/akms
2021-08-03 16:07:20 <mps> pkgdesc="Alpine Kernel Module Support"
2021-08-03 16:07:26 <mps> \o/
2021-08-03 16:07:32 <jvoisin> \o/
2021-08-03 16:07:37 <riverdc> yeah it seems pretty painful @ikke
2021-08-03 16:08:11 <nmeum> riverdc: we already have some haskell software, but we link everything statically atm
2021-08-03 16:08:14 <jvoisin> riverdc: check how pandoc is packaged
2021-08-03 16:08:18 <nmeum> not sure if we really want to continue this road
2021-08-03 16:08:23 <nmeum> but examples are pandoc and testing/idris
2021-08-03 16:08:29 <jvoisin> I tried to package matterhorn, but it was painful/garbage
2021-08-03 16:08:33 <ikke> shellcheck as well
2021-08-03 16:08:37 <nmeum> right, shellcheck too
2021-08-03 16:08:39 <riverdc> ah ok thank you, I will take a look at those
2021-08-03 16:08:42 <maxice8> no general policy, Alpine generally goes on a per-language basis, some are just unfun
2021-08-03 16:08:49 <nmeum> you should also be able to find them with `ap revdep ghc` I guess
2021-08-03 16:09:05 <ikke> The issue with haskell is that you are bound the update hte dependencies about weekly
2021-08-03 16:11:07 <mps> now I can deinstall my local dkms and remove branch branch from aports. thank you jirutka even if you don't read this
2021-08-03 16:12:01 <riverdc> looking at idris, is there a reason there's no options=net?
2021-08-03 16:12:33 <nmeum> people sometimes forget to add it, one only notices that it is missing when using `abuild rootbld` after all
2021-08-03 16:12:36 <maxice8> not technically required rn
2021-08-03 16:12:59 <maxice8> since CI/builders and the default local testing method doesn't use a sandbox that limits the net as far as I understand
2021-08-03 16:41:29 <Thermi> The builders run with -j2, don't they?
2021-08-03 16:41:37 <Thermi> Or do they use -j$(nproc) or something?
2021-08-03 16:42:01 <ikke> the latter
2021-08-03 16:42:21 <ikke> -j2 would take forever to build :)
2021-08-03 16:42:29 <Thermi> How high is it?
2021-08-03 16:42:38 <ikke> what arch?
2021-08-03 16:42:45 <Thermi> right now x86_64
2021-08-03 16:42:56 <ikke> 32
2021-08-03 16:42:58 <Thermi> I'm working on reproducing the issue with kopano-webapp
2021-08-03 16:43:00 <Thermi> Tyvm
2021-08-03 16:43:26 <Thermi> The part where it hangs uses msgfmt, which is part of gettext
2021-08-03 16:43:34 <ikke> yes, I noticed that
2021-08-03 16:47:27 <Thermi> Couldn't reproduce
2021-08-03 16:54:24 <PureTryOut> What are the plans for a riscv64 CI?
2021-08-03 16:54:49 <ikke> Me finding the motivation to do the last part :P
2021-08-03 16:55:05 <PureTryOut> Oh lol
2021-08-03 16:57:40 <Thermi> The part that hangs is just a simple for loop over all po files that executes msgfmt -c -v -o $outfile $file
2021-08-03 16:57:56 <Thermi> The particular command is msgfmt -c -v -o  /home/buildozer/aports/testing/kopano-webapp/src/kopano-webapp/server/language/sl_SI.UTF-8/LC_MESSAGES/zarafa_webapp.po /home/buildozer/aports/testing/kopano-webapp/src/kopano-webapp/server/../deploy/server/language/sl_SI.UTF-8/LC_MESSAGES/zarafa_webapp.mo
2021-08-03 17:05:41 <Ariadne> is there anything with lockfiles ?
2021-08-03 17:06:04 <ikke> I tried abuild build on the builder, seems to succeed
2021-08-03 17:06:20 <Ariadne> weird
2021-08-03 17:06:22 <Ariadne> dunno then :)
2021-08-03 17:06:40 <Ariadne> am just glad sudo is going to die
2021-08-03 17:06:40 <Ariadne> i
2021-08-03 17:06:59 <Ariadne> well, not die, but be sent to community
2021-08-03 17:07:01 <Ariadne> where it belongs ;p
2021-08-03 17:07:12 <zacksiri> hey
2021-08-03 17:07:34 <zacksiri> hope everyone is doing well, I have some questions to ask about the recent update to apk-tools
2021-08-03 17:07:40 <zacksiri> version 2.10.7 specifically
2021-08-03 17:07:53 <zacksiri> I used to have a build pipeline that builds my packages and served on a private repository
2021-08-03 17:07:58 <zacksiri> however now I get strange errors
2021-08-03 17:08:01 <zacksiri> like IO ERROR
2021-08-03 17:08:08 <zacksiri> i suspect it's permission related
2021-08-03 17:08:20 <zacksiri> do I need to do something to my APKBUILD to make this work?
2021-08-03 17:08:24 <zacksiri> did I miss something?
2021-08-03 17:08:38 <Ariadne> is the private repo being served over https?
2021-08-03 17:08:46 <zacksiri> yes it is
2021-08-03 17:08:46 <PureTryOut> Is Jakub Jirutka on IRC/Matrix?
2021-08-03 17:08:58 <ikke> PureTryOut: no
2021-08-03 17:09:07 <Ariadne> i can ping him if you want
2021-08-03 17:09:34 <Ariadne> but he prefers e-mail
2021-08-03 17:09:48 <ikke> Also generally responds on gitlab
2021-08-03 17:10:03 <PureTryOut> Oh no problem I just wonder why nodejs is on 14.17.4 still rather than 16.x.x, but maybe you guys know
2021-08-03 17:10:04 <Ariadne> zacksiri: check your certificate for validity
2021-08-03 17:10:20 <PureTryOut> 16.x.x has riscv64 support 😄
2021-08-03 17:10:38 <zacksiri> The certificate is fine, I'm able to download the package
2021-08-03 17:10:40 <Ariadne> PureTryOut: open an MR upgrading it, and assign it to him
2021-08-03 17:10:41 <zacksiri> but upon installing
2021-08-03 17:10:51 <Ariadne> zacksiri: log ?
2021-08-03 17:11:08 <zacksiri> i get something like this ERROR: archive-0.1.1-r161: IO ERROR
2021-08-03 17:11:08 <Ariadne> and what do you mean by 'download'?
2021-08-03 17:11:12 <ikke> there is nodjs-current as well
2021-08-03 17:11:12 <Ariadne> hmm
2021-08-03 17:11:16 <PureTryOut> Ariadne: ok will do
2021-08-03 17:11:25 <zacksiri> ERROR: archive-openrc-0.1.1-r161: IO ERROR
2021-08-03 17:11:34 <PureTryOut> Oh yeah nodejs-current is up to date
2021-08-03 17:11:40 <zacksiri> when i chmod the directory to 777 it works 
2021-08-03 17:11:45 <zacksiri> but openrc still fails
2021-08-03 17:11:49 <Ariadne> what directory ?
2021-08-03 17:12:13 <zacksiri> *var/lib/archive*
2021-08-03 17:12:25 <zacksiri> bascically i ran chmod -R 777 on /var/lib
2021-08-03 17:12:32 <ikke> nodejs is on the LTS branch
2021-08-03 17:12:33 <zacksiri> and the base package installed
2021-08-03 17:12:42 <Ariadne> ikke: yes, but node 16 is an LTS
2021-08-03 17:12:45 <ikke> ok
2021-08-03 17:12:47 <zacksiri> the -openrc however didn't work
2021-08-03 17:13:00 <Ariadne> zacksiri: sounds like your system's permissions are messed up
2021-08-03 17:13:13 <Ariadne> zacksiri: maybe try `apk fix --reinstall alpine-base`
2021-08-03 17:13:13 <zacksiri> it used to work fine
2021-08-03 17:13:21 <zacksiri> let me try
2021-08-03 17:13:28 <zacksiri> i'm using an LXD image
2021-08-03 17:13:36 <zacksiri> i ahve an older container that works
2021-08-03 17:13:43 <zacksiri> but the container image was updated recently
2021-08-03 17:13:45 <Ariadne> i too, am using LXD
2021-08-03 17:13:51 <zacksiri> and since then it's broken
2021-08-03 17:13:57 <zacksiri> other packages seem to install fine
2021-08-03 17:14:05 <zacksiri> it's only my packages
2021-08-03 17:15:13 <zacksiri> tried running apk fix --reinstall alpine-base
2021-08-03 17:15:21 <zacksiri> i'm getting ERROR: portal-openrc-1.0.12-r144: IO ERROR
2021-08-03 17:15:27 <zacksiri> that's another package 
2021-08-03 17:15:31 <zacksiri> but same result
2021-08-03 17:15:44 <zacksiri> this is also a package i built using custom APKBUILD file
2021-08-03 17:16:00 <zacksiri> i'm using alpine 3.11
2021-08-03 17:16:51 <PureTryOut> Ah nodejs 14.x.x is a LTS, that's probably why it isn't updated and nodejs-current is
2021-08-03 17:17:05 <Ariadne> node 16
2021-08-03 17:17:07 <Ariadne> is an LTS too
2021-08-03 17:17:08 <Ariadne> i think
2021-08-03 17:17:08 <zacksiri> https://github.com/upmaru/pakman/blob/c91e1bf59085b8fb16d396c25b641c1e046f9f1b/lib/pakman/templates/bootstrap/apkbuild.eex
2021-08-03 17:17:13 <zacksiri> link to my APKBUILD
2021-08-03 17:17:15 <zacksiri> template
2021-08-03 17:17:38 <zacksiri> Node 16 is not LTS
2021-08-03 17:17:43 <zacksiri> only Node 14 is
2021-08-03 17:17:47 <Ariadne> ah
2021-08-03 17:17:50 <Ariadne> not until october
2021-08-03 17:17:52 <PureTryOut> Yeah seems like it
2021-08-03 17:17:57 <PureTryOut> Can't wait for October then
2021-08-03 17:19:37 <Ariadne> well if it becomes LTS in this release cycle,
2021-08-03 17:19:45 <Ariadne> i think we could go ahead and bump now
2021-08-03 17:19:55 <Ariadne> so, go ahead and make an MR :)
2021-08-03 17:22:36 <PureTryOut> Uh, got some source for that "until October" then to link to in the MR?
2021-08-03 17:23:21 <Thermi> Isn't it possible to put a time limit on the separate build jobs?
2021-08-03 17:31:04 <Ariadne> PureTryOut: https://nodejs.org/en/about/releases/
2021-08-03 17:31:15 <Ariadne> Active LTS: 2021-10-26
2021-08-03 17:33:06 <Ariadne> PureTryOut: i also pinged him about it :)
2021-08-03 17:33:17 <PureTryOut> Great thanks!
2021-08-03 17:35:32 <Ariadne> PureTryOut: jirutka ACKed going to 16
2021-08-03 17:36:57 <PureTryOut> Oh nice!
2021-08-03 17:37:00 <PureTryOut> Also that was quick
2021-08-03 17:37:17 <Ariadne> the power of instant messaging
2021-08-03 17:38:03 <Ariadne> Thermi: not under the current system :(
2021-08-03 17:38:40 <PureTryOut> Building nodejs-current for riscv64 right now locally to see if it "just works"
2021-08-03 17:41:57 <ikke> Thermi: trying different methods to reproduce it outside of the builder, but not luck so far
2021-08-03 17:45:53 <riverdc> is there something like 'docdepends' analagous to checkdepends?
2021-08-03 17:46:45 <ikke> no
2021-08-03 17:46:57 <ikke> that's just counted as makedepends
2021-08-03 17:47:02 <riverdc> k thanks
2021-08-03 17:47:37 <wej> mps: would you mind merging !23725? unless of course there is still something left to be done, but i think it should be fine
2021-08-03 17:49:17 <mps> wej: yes, I keep it in minds. but have to finish some other things and clean my current messy aports to test it
2021-08-03 17:49:35 <mps> if you sure it is ok I can merge it right now
2021-08-03 17:49:56 <wej> mps: of course, no worries. thank you :)
2021-08-03 17:49:59 <mps> hmm, 'sure' is too strong word. if you think it is ok
2021-08-03 17:50:22 <wej> mps: i tested it quite comprehensively with and without supervise-daemon, so it looks fine as far as i can tell
2021-08-03 17:50:29 <mps> lets merge and see ;)
2021-08-03 17:50:36 <wej> :)
2021-08-03 17:51:48 <mps> wej: done
2021-08-03 17:51:59 <wej> thanks :)
2021-08-03 17:52:12 <mps> wej: you are welcome :)
2021-08-03 18:11:23 <Thermi> ikke, if it happens again, can we attach a debugger and get a stack trace maybe?
2021-08-03 18:11:29 <ikke> yes\
2021-08-03 18:11:42 <Thermi> A stack trace for all threads for the stuck process, of course
2021-08-03 18:52:31 <krystianch> hey, I was wondering what should I take into account when deciding if I should submit a patch for adding an aport from my private tree to testing; I have a few packages that I use every day, but is it worth to submit them to official aports?
2021-08-03 18:56:50 <Thermi> Is it useful for anyone else than you? Does it satisfy minimum quality requirements? How large is it?
2021-08-03 18:57:18 <Thermi> Is it proprietary software? Is one allowed to distribute it?
2021-08-03 18:57:59 <Thermi> Can it be built directly from sources downloadable over the Internet?
2021-08-03 19:01:34 <krystianch> thanks
2021-08-03 19:19:02 <Ariadne> does anyone care if we reenable the kopano stuff
2021-08-03 19:19:12 <Ariadne> the risk being that the builders might get stuck again
2021-08-03 19:19:43 <Ariadne> maybe the builders got hit by a cosmic ray or something
2021-08-03 19:19:53 <ikke> Ariadne: I'll try to figure out what's going on when it happens
2021-08-03 19:20:08 <Ariadne> okay
2021-08-03 19:20:15 <Ariadne> i mean, it could work this time, too
2021-08-03 19:20:25 <Ariadne> though -x86 was trying to rebuild it over and over
2021-08-03 19:20:26 <Ariadne> sooo
2021-08-03 19:20:35 <Ariadne> dunno whats gonna happen
2021-08-03 19:20:40 <Ariadne> it'll be interesting
2021-08-03 19:20:42 <Ariadne> i know that
2021-08-03 19:20:50 <ikke> ahuh
2021-08-03 19:21:12 <Thermi> Something something the architecture of society is a stealing pile of shit
2021-08-03 19:21:22 <Ariadne> lets goooooo
2021-08-03 19:21:26 <Thermi> DEJAVU
2021-08-03 19:21:33 <Ariadne> stealing?
2021-08-03 19:21:36 <Ariadne> do you mean steaming :p
2021-08-03 19:21:40 <Thermi> Yes.
2021-08-03 19:21:50 <Habbie> 'that too'
2021-08-03 19:22:32 <knuxify>  what happened to the gitlab CI runners?
2021-08-03 19:22:51 <Ariadne> they're union
2021-08-03 19:23:02 <Ariadne> mandatory paid vacation
2021-08-03 19:23:09 <Ariadne> check back later
2021-08-03 19:23:11 <Ariadne> ;p
2021-08-03 19:24:32 <ikke> I'm afraid they have everything but vacation
2021-08-03 19:25:46 <ikke> Pending: 144, running: 15
2021-08-03 19:26:50 <ikke> pending: 160
2021-08-03 19:26:52 <ikke> someone is busy
2021-08-03 19:29:38 <knuxify> i noticed one MR got stuck during tests but it had a timeout of 6h, so i assumed once that would be done that it would get everything else unstuck
2021-08-03 19:30:00 <knuxify> (to be clear - it timed out now)
2021-08-03 19:31:47 <knuxify> it did get unstuck, i just didn't notice :p
2021-08-03 19:34:58 <mps> we are nearly to get record of MR numbers, 299 now
2021-08-03 19:35:18 <ikke> It has been over 300 already
2021-08-03 19:35:28 <mps> ah, missed that
2021-08-03 19:36:25 <ikke> 313 is the record
2021-08-03 19:39:55 <riverdc> > they're union
2021-08-03 19:39:57 <riverdc> lol, was also wondering
2021-08-03 19:41:59 <adhawkins> Can someone take a quick look at !23887
2021-08-03 19:42:18 <adhawkins> Do I need to mention the licence change in the commit message at all?
2021-08-03 19:48:07 <riverdc> if anyone has any idea why !19978 is failing, help would be appreciated. seems to be missing some font file from texlive, or something, but it works fine for me locally
2021-08-03 19:49:00 <riverdc> i think the specific failure is here https://gitlab.alpinelinux.org/outerpassage/aports/-/jobs/453806#L2974
2021-08-03 19:51:59 <okeuday> ikke: the way I ran into the builder getting stuck is with the cloudi package tests, it has a configure argument to change the test timeout to what failed previously (--with-test-timeout=container_cpu_quota)
2021-08-03 20:15:45 <riverdc> ah ok it must be this https://gitlab.alpinelinux.org/alpine/aports/-/issues/12834
2021-08-03 20:43:50 <martijnbraam> I made a thing
2021-08-03 20:43:51 <martijnbraam> https://git.sr.ht/~martijnbraam/createaport
2021-08-03 20:45:38 <Ariadne> nice
2021-08-03 20:57:07 <ikke> Thermi: at least one issue was that subpackages need to be explicitly set to noarch
2021-08-03 21:09:29 <Ariadne> is there a wiki page for 3.15 release notes yet?
2021-08-03 21:09:40 <Ariadne> if not, can somebody make one and put the text on https://gitlab.alpinelinux.org/alpine/aports/-/issues/12888 in it
2021-08-03 21:09:58 <Ariadne> specifically, https://gitlab.alpinelinux.org/alpine/aports/-/issues/12888#note_171653 :)
2021-08-03 21:14:40 <ikke> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.15.0
2021-08-03 21:25:20 <Ariadne> Thermi: 
2021-08-03 21:25:23 <Ariadne> # Avoid wrong version by assigning version to each plugin
2021-08-03 21:25:42 <Ariadne> this doesn't work with our builders
2021-08-03 21:25:49 <Ariadne> do we really need it?
2021-08-03 21:26:10 <Ariadne> the $pkgver cannot be changed from the main one
2021-08-03 21:32:11 <Thermi> Ariadne, Hmh. HMMMMH. Yes.
2021-08-03 21:32:17 <Thermi> I will split the packages.
2021-08-03 21:32:29 <Thermi> It's crap to deal with, but it's needed then.
2021-08-03 21:32:37 <Ariadne> ok, great
2021-08-03 21:32:48 <Ariadne> `buildrepo` is getting confused
2021-08-03 21:32:50 <Thermi> I'll first need to see if it's possible at all, without fetching the sources
2021-08-03 21:32:57 <Ariadne> and queueing the package for rebuild
2021-08-03 21:33:06 <Thermi> *without fetching the sources for kopano-webapp
2021-08-03 21:33:37 <Ariadne> one option is to package the source itself
2021-08-03 21:33:44 <Ariadne> as a kopano-webapp-src
2021-08-03 21:43:36 <Thermi> ikke, do you have a list of issues for me?
2021-08-03 21:44:18 <ikke> I already fixed the arch issue
2021-08-03 21:44:24 <ikke> But that was not the problem
2021-08-03 21:44:53 <ikke> So I'm only aware of the version issue
2021-08-03 21:45:06 <ikke> the hangs are unexplained, but don't seem to happen atm
2021-08-03 21:47:15 <Thermi> I have to be the chosen one*
2021-08-03 21:47:20 <Thermi> *I always get to find such issues
2021-08-03 21:47:28 <Thermi> The chosen one for weird bugs
2021-08-03 21:48:44 <ikke> it's a known limitation
2021-08-03 21:48:53 <Thermi> The msgfmt thing
2021-08-03 21:49:00 <ikke> oh, right
2021-08-03 21:49:14 <ikke> Well, hangs happen all the time for some reason
2021-08-03 21:49:23 <ikke> bad assumptions, etc
2021-08-03 21:49:36 <Thermi> Also the fact that I have to use a custom unpack function
2021-08-03 21:50:24 <ikke> que "how to make package managers cry" presentation
2021-08-03 21:52:05 <Thermi> queue libmdbx
2021-08-03 21:52:34 <Ariadne> yeah
2021-08-03 21:52:36 <Ariadne> btw
2021-08-03 21:52:40 <Ariadne> whats with the custom unpack function
2021-08-03 21:52:41 <Ariadne> :P
2021-08-03 21:52:46 <Thermi> seriously?
2021-08-03 21:53:03 <Ariadne> i'm just wondering what thats about
2021-08-03 21:53:08 <Ariadne> its not a policy violation
2021-08-03 21:53:24 <Thermi> Upstream doesn't package the sources into a subdirectory, but puts it all into the root of the archive
2021-08-03 21:53:35 <Thermi> so if you then unpack it, it's not software or software-ver
2021-08-03 21:53:46 <Thermi> it's src, buildfile, README.md, ...
2021-08-03 21:53:54 <Thermi> all in the root
2021-08-03 21:54:02 <Thermi> And that goes directly into $srcdir
2021-08-03 21:54:21 <Ariadne> good god
2021-08-03 21:54:44 <Thermi> If you then have several sources to download, you are unable to differentiate the files of the different sources
2021-08-03 21:55:12 <Ariadne> yes, i get it
2021-08-03 21:55:17 <Ariadne> this is quite horrible
2021-08-03 21:55:32 <Ariadne> at some point
2021-08-03 21:55:43 <Ariadne> you're going to wonder "why didn't i just make all of this docker containers"
2021-08-03 21:55:44 <Ariadne> :D
2021-08-03 21:57:32 <Thermi> Yes.
2021-08-03 21:58:41 <Thermi> Throwback to people complaining about docker containers with Python on Alpine being large and them not cleaning up the sources of the dependencies of the build sources
2021-08-03 21:58:47 <Thermi> or the build sources.
2021-08-03 21:58:56 <Thermi> "mimimi the container is 2G in size"
2021-08-03 22:33:42 <link2xt> Thermi: Ariadne: this is shortly named "tarbomb"
2021-08-04 08:49:49 <mps> looks like protobuf in edge is buggy on aarch64, it segfaulted mosh client few times on my workstation
2021-08-04 09:48:06 <ncopa> i'd like to tag a new edge release snapshot today, and add riscv64 docker image
2021-08-04 09:51:09 <Ariadne> yes, would be good
2021-08-04 09:51:26 <Ariadne> i think tianon did some of the work already for it
2021-08-04 09:52:43 <clandmeter> i wonder if we need to be more explicit about rv64 being kind off alfa quality and incomplete
2021-08-04 09:53:10 <Ariadne> probably good to mention in readme
2021-08-04 09:53:13 <Ariadne> that's what debian did
2021-08-04 09:53:37 <clandmeter> i think they even have a list of what is working and what is not (with related bugids)
2021-08-04 09:54:00 <Ariadne> no, just a link to the riscv64 user tag in debbugs afaik
2021-08-04 09:55:16 <clandmeter> Ariadne: are you going to look into rust?
2021-08-04 09:55:26 <Ariadne> once we have real hardware
2021-08-04 09:55:37 <clandmeter> you said something like 1 month ago ;-)
2021-08-04 09:55:41 <Ariadne> rust is not high priority for my customer
2021-08-04 09:55:48 <Ariadne> :P
2021-08-04 09:56:14 <Ariadne> "working" is high priority
2021-08-04 09:56:22 <Ariadne> bootstrapped on real hw is next priority
2021-08-04 09:56:37 <Ariadne> rust requires libc crate and std crate bindings for riscv64-musl anyway
2021-08-04 09:56:51 <Ariadne> i'm working on resurrecting sircmpwn's work for that, but
2021-08-04 09:57:01 <Ariadne> rustc on qemu-user will be very slow :P
2021-08-04 09:57:43 <sircmpwn> good luck
2021-08-04 09:57:45 <sircmpwn> I gave up after a week
2021-08-04 09:58:52 <Ariadne> the problem is that the rust bootstrap process is very opaque
2021-08-04 09:59:09 <Ariadne> it will give you errors that things are missing, but it's not obvious what/where those things are
2021-08-04 09:59:15 <sircmpwn> and has a very high round-trip on debugging
2021-08-04 09:59:18 <Ariadne> yes
2021-08-04 09:59:19 <clandmeter> i tried looking into it, but i got a headache from it
2021-08-04 09:59:25 <sircmpwn> it could be 3 hours before you see the results of an attempted fix
2021-08-04 09:59:57 <clandmeter> running it from boostrap.sh was making some progress but i gave up on it.
2021-08-04 10:00:05 <sircmpwn> high latency debugging is the single worst scenario a software worker typically endures imo
2021-08-04 10:00:14 <Ariadne> clandmeter: rust cannot be bootstrapped on riscv64-musl anyway
2021-08-04 10:00:15 <mps> 
ACTION had a hope that rust will never appear on riscv :)

2021-08-04 10:00:19 <Ariadne> it is 100% guaranteed to error
2021-08-04 10:00:41 <Ariadne> code has to be written to support it
2021-08-04 10:00:54 <clandmeter> im not sure which code
2021-08-04 10:01:01 <Ariadne> code in rust itself
2021-08-04 10:01:07 <sircmpwn> I think I had some patches floating around which rigs up this code
2021-08-04 10:01:11 <Ariadne> there's libc and std crates, which need to have riscv64 stuff :D
2021-08-04 10:01:14 <sircmpwn> and I think they were considering addressing it upstream also
2021-08-04 10:01:15 <clandmeter> i did edit some patches to add the triplets or similar
2021-08-04 10:01:21 <clandmeter> but i forgot what i really did
2021-08-04 10:01:23 <Ariadne> yeah, no that's the easy part
2021-08-04 10:01:32 <Ariadne> the hard part is teaching rust about musl on riscv64
2021-08-04 10:01:35 <Ariadne> the libc crate is a mess
2021-08-04 10:01:37 <sircmpwn> https://github.com/rust-lang/libc/pull/1994
2021-08-04 10:01:47 <clandmeter> isnt rust on musl already available?
2021-08-04 10:01:58 <clandmeter> i mean for rv64
2021-08-04 10:02:00 <sircmpwn> each triple needs dedicated attention on rust
2021-08-04 10:02:06 <clandmeter> i saw some refs to it in rust
2021-08-04 10:02:15 <Ariadne> yes
2021-08-04 10:02:15 <Ariadne> and then you have to wire stuff up in std too
2021-08-04 10:02:15 <Ariadne> for some archs
2021-08-04 10:02:15 <Ariadne> but its not generic
2021-08-04 10:02:22 <sircmpwn> so rust has rv support, and musl support, but not rv+musl support
2021-08-04 10:03:17 <Ariadne> fwiw i think everything is finally there to attempt s390x again
2021-08-04 10:03:29 <Ariadne> however...
2021-08-04 10:03:41 <Ariadne> when my customer decides riscv64 is interesting
2021-08-04 10:03:44 <Ariadne> for rust
2021-08-04 10:03:52 <clandmeter> i think rv64 sounds more interesting to spend time on (my opionon)
2021-08-04 10:03:55 <Ariadne> i think they will just hire a rust core dev
2021-08-04 10:04:03 <Ariadne> to finish the bootstrap
2021-08-04 10:04:04 <Ariadne> :)
2021-08-04 10:04:16 <Ariadne> which, imo
2021-08-04 10:04:19 <Ariadne> is probably the way to go
2021-08-04 10:12:42 <mps> anyone know what is the status with llvm12 upgrade
2021-08-04 10:13:10 <mps> zig needs it
2021-08-04 10:13:36 <yyp> !20759
2021-08-04 10:14:06 <mps> and it is wip for about three months, I remember
2021-08-04 10:14:21 <yyp> I tried, but it didn't really work
2021-08-04 10:14:31 <mps> I mean is there any progress
2021-08-04 10:14:49 <yyp> A bunch of stuff like clang failed to build
2021-08-04 10:14:57 <yyp> mps: not really
2021-08-04 10:15:16 <Ariadne> clang has to be updated with llvm12 to build against it afaik
2021-08-04 10:15:29 <yyp> I did update it
2021-08-04 10:15:45 <yyp> It still broke, I don't have the build tree neither I remember the error it failed with
2021-08-04 10:15:51 <mps> last time I worked with llvm for alpine was more than 2 years, don't want to put my hands there again
2021-08-04 10:16:20 <mps> 2 years ago*
2021-08-04 10:17:06 <yyp> There were commits 2 weeks ago, I tested like a month ago iirc
2021-08-04 10:17:42 <yyp> Something may be fixed, but I don't feel like running that for 3-5 hours again
2021-08-04 10:18:51 <mps> iirc, building all these batteries takes about hour on i7 box with 8GB ram and SSD
2021-08-04 10:19:29 <mps> but that was two years ago, not sure how current llvm and rest takes
2021-08-04 10:19:43 <yyp> My system is not that good
2021-08-04 10:20:19 <yyp> First of, no SSD which will slow down FS work and LLVM has *a lot* of files that it writes
2021-08-04 10:20:29 <yyp> And second, I'm not on i7 CPU
2021-08-04 10:21:26 <mps> it's a pity I can't give you my i7 which nowadays only keeping dust
2021-08-04 10:21:46 <yyp> I remember measuring that llvm12 took around 3 hours in a chroot
2021-08-04 10:21:55 <yyp> Back when I was not using Alpine on the desktop
2021-08-04 10:22:38 <mps> if you upgrade MR I could try on devs lxc
2021-08-04 10:24:07 <mps> (and no, zig is not good lang but it is better than all others new hipsters system langs I've seen in last few years)
2021-08-04 10:24:32 <Ariadne> i still prefer C :D
2021-08-04 10:24:39 <mps> also I
2021-08-04 10:25:06 <mps> even thinking to go back to assembler when I retire (if ever I retire)
2021-08-04 10:26:03 <mps> though my work in last decade (or about 15 years) is far from C
2021-08-04 10:26:15 <yyp> Zig is not the best, but there's some cool software in it (namely, river)
2021-08-04 10:26:37 <Ariadne> C is the best, there's some crappy software in it (everything i've ever written)
2021-08-04 10:26:38 <Ariadne> :D
2021-08-04 10:26:46 <mps> I thought my C will be refreshed when I started to work with alpine but after 3 years it faded even more
2021-08-04 10:27:49 <Ariadne> see nobody disagrees :D
2021-08-04 10:27:50 <mps> yyp: well, I should write 'promising'. and ofc, C is still best
2021-08-04 10:28:14 <yyp> C is good, but not the best
2021-08-04 10:28:29 <mps> I meant to say, better than new hipster langs as is rust
2021-08-04 10:28:35 <yyp> yeah
2021-08-04 10:29:00 <yyp> Though I find Zig's approach to generics even worse than Rust's, honestly
2021-08-04 10:30:16 <Ariadne> just use
2021-08-04 10:30:17 <Ariadne> C
2021-08-04 10:30:18 <Ariadne> :D
2021-08-04 10:30:26 <yyp> I'm using C
2021-08-04 10:30:28 <yyp> right now
2021-08-04 10:30:37 <Ariadne> C is best
2021-08-04 10:30:40 <ikke> "Segmentation fault"
2021-08-04 10:30:52 <yyp> No segmentation faults today
2021-08-04 10:31:00 <Ariadne> stop using my software and you will have 100% less segfaults :D
2021-08-04 10:31:16 <mps> looks like protobuf in edge is buggy on aarch64, it segfaulted mosh client few times on my workstation
2021-08-04 10:31:46 <mps> https://tpaste.us/6WED
2021-08-04 10:31:49 <Ariadne> i'm kidding, don't worry :P
2021-08-04 10:32:12 <yyp> Everything on edge+aarch64 is buggy
2021-08-04 10:32:25 <Ariadne> edge aarch64 works fine for me
2021-08-04 10:32:28 <mps> where I read sentence 'all programmers are optimists' :)
2021-08-04 10:32:29 <Ariadne> i'm using it right now
2021-08-04 10:32:34 <yyp> huh
2021-08-04 10:32:49 <mps> Ariadne: you mean mosh?
2021-08-04 10:32:49 <yyp> I destroyed my bouncer with it
2021-08-04 10:32:57 <Ariadne> no
2021-08-04 10:33:02 <mps> ah, ok
2021-08-04 10:33:10 <Ariadne> "everything on edge+aarch64 is buggy"
2021-08-04 10:33:17 <ncopa> py3-pywal build failed on armhf/armv7 for some reason
2021-08-04 10:33:28 <mps> edge aarch64 works for me about 3 years now :)
2021-08-04 10:33:38 <ncopa> i'd like to push new edge snapshot
2021-08-04 10:34:01 <mps> Ariadne: not really all, just some 'things'
2021-08-04 10:34:26 <Ariadne> ncopa: because the testsuite does stupid things
2021-08-04 10:34:32 <Ariadne> just disable it i guess
2021-08-04 10:36:29 <yyp> Yeah
2021-08-04 10:37:16 <yyp> Where is it even trying to find images in?
2021-08-04 10:39:45 <ncopa> seems like i should pick other time for tagging edge release
2021-08-04 10:39:51 <ncopa> its a train in motion
2021-08-04 10:40:10 <ncopa> py3-pywal fails due to some tmp directory leftovers has not been cleaned
2021-08-04 10:40:55 <ncopa> the /tmp dir is 1G
2021-08-04 10:44:14 <ncopa> ugh.. and the diffutils testsuite fails on the builders
2021-08-04 10:51:38 <ikke> diff: standard output: Broken pipe
2021-08-04 10:58:53 <ncopa> does not happen in my dev env
2021-08-04 10:59:00 <ncopa> or when i run it from command line
2021-08-04 10:59:11 <ncopa> so i think it might be related an existing tty?
2021-08-04 10:59:35 <ikke> try setsid nohup abuild -r >build.log 2>&1
2021-08-04 10:59:56 <ikke> maybe setsid is enough
2021-08-04 11:06:43 <ncopa> nope. im not able to reproduce it with setsid or nohup
2021-08-04 11:08:09 <ncopa> i wonder if i should just disable that last test
2021-08-04 11:12:34 <mps> this reminds me, pipe behavior is reverted in current stable kernels, f0aa1bc37e9a9e48923a7e04dba7da2b59654ec8 https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.8, and 27aa7171fe2b00c3de01e8e3a3298a3639f37fa3 https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.56
2021-08-04 11:38:51 <Ariadne> btw https://github.com/Duncaen/OpenDoas/pull/71 :)
2021-08-04 12:43:40 <ncopa> nice!
2021-08-04 13:06:34 <g1234> Hello! how can i use xorg-cf-files as a makedepends? i am packaging x11-ssh-askpass, and command xmkmf is not working inside apkbuild fakeroot
2021-08-04 13:41:27 <Ariadne> :D
2021-08-04 16:42:07 <mps> !23782 should be closed
2021-08-04 16:42:28 <mps> ?
2021-08-04 16:42:29 <ikke> mps: You should be able to close it
2021-08-04 16:42:37 <mps> ok will do now
2021-08-04 16:43:04 <ikke> I rebased it to test if it would still announce on #-commits
2021-08-04 16:43:25 <mps> ahm, forgot to stop CI
2021-08-04 16:44:16 <ikke> oh, thanks
2021-08-04 16:44:38 <mps> ok, CI is already stopped by fail :)
2021-08-04 17:09:04 <Thermi> Wouldn't it be easier to fix buildrepo to deal with several packages with different version numbers?
2021-08-04 18:12:38 <ncopa> ugh. kopoano-webapp's split functions changes the pkgver
2021-08-04 18:12:59 <ncopa> i think we need update abuild to exit with error when that happens
2021-08-04 18:14:52 <ikke> ncopa: wasn't that fixed already?
2021-08-04 18:15:07 <ikke> (kopano-webapp, not abuild)
2021-08-04 18:15:23 <ncopa> i think not. the subpackages sets pkgver
2021-08-04 18:15:49 <ncopa> there is no way ap/buildrepo/abuild can detect if a subpackage needs to be rebuilt or not
2021-08-04 18:16:26 <ncopa> so i think it will look for subpackage with $pkgver, not find it and then always rebuild it 
2021-08-04 18:17:45 <ikke> ok, I assume it was fixed, but apparently it was just noted
2021-08-04 18:17:55 <ikke> assumed*
2021-08-04 18:38:18 <Thermi> ikke, for the kopano-webapp-src package, where should I put the files?
2021-08-04 18:38:36 <Thermi>  /usr/share/kopano-webapp/src/?
2021-08-04 19:15:24 <ncopa> Thermi: I think we need to do this: https://tpaste.us/REx4
2021-08-04 19:18:56 <Thermi> ncopa, That's too simplistic because the different plugins come from different sources but need files at build time from kopano-webapp
2021-08-04 19:19:09 <Thermi> The different plugins also have different versions and can be updated independently
2021-08-04 19:19:37 <ikke> Sounds like you need different packages
2021-08-04 19:20:44 <Thermi> Yes, that's why they were subpackages.
2021-08-04 19:21:07 <Thermi> That way you don't need a -src package, or anything, and can update everything in lock-step.
2021-08-04 19:21:37 <Hello71> seems reminiscent of nginx
2021-08-04 19:21:38 <ncopa> they are either fractions of kopano-webapp and should use the same version or they are different proejcts/packages and should go to different apkbuilds
2021-08-04 19:22:05 <Thermi> Can you help me out with a sensible location for the files of the -src package?
2021-08-04 19:22:10 <ncopa> nginx modules has same version as nginx and are considered a part of nginx
2021-08-04 19:22:43 <ncopa> i think the reason for nginx is that they need to be rebuilt every time nginx is rebuilt
2021-08-04 19:22:46 <ncopa> or updated
2021-08-04 19:22:49 <Hello71> ncopa: have you looked at nginx apkbuild recently? https://git.alpinelinux.org/aports/tree/main/nginx/APKBUILD#n131
2021-08-04 19:23:29 <ncopa> Hello71: the subpackages has all same version as nginx
2021-08-04 19:23:33 <Hello71> yes
2021-08-04 19:23:46 <Hello71> the actual modules versions are "overridden"
2021-08-04 19:23:57 <ncopa> iirc the historical reason was that they are tied to a specific build
2021-08-04 19:24:04 <ncopa> same thing with dovecot plugins
2021-08-04 19:24:06 <Hello71> i think that's half the problem, but also nginx has poorly designed separation of concerns and needs the full original source
2021-08-04 19:24:12 <ncopa> yes
2021-08-04 19:24:38 <ncopa> but the reason its acceptable from alpine's pov is that we now use same version as nginx itself
2021-08-04 19:25:35 <Hello71> i mean the upstream situation is similar, so a similar "solution" can be used: just overwrite the plugin versions with top level package
2021-08-04 19:26:21 <ncopa> re kopano-webapp, will the same version of the plugin work with a newer version of kopano-webapp itself?
2021-08-04 19:26:42 <ncopa> or will the subpackage need a rebuild if kopano-webapp is updated?
2021-08-04 19:28:12 <ncopa> so currently kopano-webapp is 5.2.0, and the kopano-webapp-smime is 2.2.2
2021-08-04 19:28:34 <ncopa> will kopano-webapp-smime need a rebuild when kopano-webapp gets updated to 5.2.1?
2021-08-04 19:29:07 <Thermi> as far as I can tell, the dependencies at build time are only because of ant XML files
2021-08-04 19:29:20 <Thermi> I don't think so, unless they change some file locations or paths
2021-08-04 19:29:47 <ncopa> so they could go to their own apkbuilds?
2021-08-04 19:29:56 <Thermi> I think so, within reason
2021-08-04 19:30:09 <Thermi> They'd still need the build files from it
2021-08-04 19:30:18 <Thermi> s/from it/of kopano-webapp/
2021-08-04 19:30:18 <alpine-meetbot> Thermi meant to say: They'd still need the build files of kopano-webapp
2021-08-04 19:30:34 <ncopa> can we ship the build files in a kopano-webapp-dev package so they can find them?
2021-08-04 19:31:19 <Thermi> No, they'd need to be moved or symlinked into the build directory
2021-08-04 19:32:09 <Thermi> I can take a look at what they need, but it's an assortment of JS, CSS, and ANT XML files
2021-08-04 19:32:54 <ncopa> current approach does not work unfortunately
2021-08-04 19:33:03 <Thermi> Please give me a de-facto standard location for the sources or the -dev package now
2021-08-04 19:33:24 <Thermi> Then I can reasonably continue writing the shared stuff for the APKBUILDs of the new packages for the plugins and spellchecker files
2021-08-04 19:33:35 <ncopa> normally C apps will install headers in /usr/include and *.so symlinks in /usr/lib/*.so
2021-08-04 19:34:00 <Thermi> Yes, and the stuff I need of kopano-webapp at build time for the plugins and spellcheckers are neither
2021-08-04 19:34:11 <Thermi> they're JS, CS, ANT XML, and potentially java related files
2021-08-04 19:34:55 <ncopa> i get the feeling that this is not really designed for traditional distro packages, but are more desined for be provisioned in docker images
2021-08-04 19:35:19 <Thermi> It is.
2021-08-04 19:35:26 <Thermi> I could of course just use the kopano-webapp sources, but then we'd have to change the kopano-webapp version in the APKBUILD of every kopano-webapp related APKBUILD for every new kopano-webapp release.
2021-08-04 19:35:31 <Thermi> (Otherwise we might run into trouble)
2021-08-04 19:36:41 <ncopa> cant you store the version in some /usr/share/kopano-webapp/version file or similar?
2021-08-04 19:36:57 <ncopa> and let the modules source that at buildtime
2021-08-04 19:37:16 <Thermi> The kopano-webapp version would need to go into the sources array
2021-08-04 19:37:42 <ncopa> the kopano-webapp version is stored in some file in the subpackages?
2021-08-04 19:37:52 <Thermi> Not as far as I know.
2021-08-04 19:38:00 <Thermi> Where are you trying to go with this?
2021-08-04 19:38:30 <ncopa> im trying to figure out if they should be in separate apkbuilds or if they should have same pkgver as kopano-webapp itself
2021-08-04 19:38:35 <Thermi> To make sure the plugins and spellcheckers work with kopano-webapp version X, kopano-webapp version X build files need to be provided at build time of the plugins and spellchecker files
2021-08-04 19:39:12 <Thermi> It'd be easiest to just have a makedepends on kopano-webapp-src, because then we don't need to put "version X" into the APKBUILD of the plugin and spellchecker APKBUILDS
2021-08-04 19:39:25 <ncopa> yeah
2021-08-04 19:39:26 <Thermi> They should not, the plugins and spellcheckers have their own version numbers.
2021-08-04 19:39:54 <ncopa> right. i was wonderning if there are some runtime check for the kopano-weapp version
2021-08-04 19:40:03 <Thermi> There are not.
2021-08-04 19:40:04 <ncopa> i think the dovecot plugins does a runtime check
2021-08-04 19:40:30 <ncopa> which is why we build them together with dovecot itself nowdays
2021-08-04 19:41:00 <Thermi> The files used at build time of the plugins and spellcheckers can be changed between versions though. So I do not know if a plugin built with an old version of kopano-webapp will work correctly with a new version of kopano-webapp.
2021-08-04 19:56:27 <ncopa> the modules can find the kopano-webapp version in usr/share/webapps/kopano-webapp/version
2021-08-04 19:57:28 <ncopa> so, my general thinking about this is that we shouldnt package this at all, but if someone still wants to do it, i don't mind as long as i dont need to deal with it
2021-08-04 19:57:33 <ncopa> and as long as it does not get in the way
2021-08-04 19:57:49 <ncopa> i think maintaining it will be an uphill battle
2021-08-04 19:58:58 <ncopa> Thermi: do you mind if I disable the package for now, til this has been sorted out? it is blocking the edge snapshot release and riscv64 docker image
2021-08-04 19:59:21 <ncopa> which is blocking the stable releases needed for the apk-tools sec fix for docker images
2021-08-04 21:54:04 <Thermi> ncopa, no, I don't mind
2021-08-05 07:23:30 <ncopa> good morning
2021-08-05 08:04:47 <ikke> o/
2021-08-05 10:16:09 <ncopa> ikke do we have an updated template of the release checklist somewhere?
2021-08-05 10:28:47 <ncopa> Ariadne: I'm looking at #12763 seems like it is fixed in 3.14?
2021-08-05 10:29:03 <ncopa> im a bit confused about e9e971672fe3192db30a7619e5e47aed9437d94a
2021-08-05 10:39:15 <Ariadne> it was a hack to unbreak the build
2021-08-05 10:39:21 <ncopa> also d2a43db62a2191609afda0bba246f0a0e9b5cf3c looks dangerous
2021-08-05 10:39:54 <Ariadne> it’s fine
2021-08-05 10:40:08 <ncopa> if future upstream version breaks abi, how do we detect it?
2021-08-05 10:40:26 <Ariadne> i check it
2021-08-05 10:40:37 <Ariadne> before updating
2021-08-05 10:41:47 <ncopa> i would feel more comfortable if there was something that checked current LIBTLS_VERSION
2021-08-05 10:41:53 <ncopa> or if a patch was used
2021-08-05 10:42:38 <ncopa> I guess I can remove the provides="so:libtls.so.20=$pkgver" now?
2021-08-05 10:42:51 <ncopa> i think it may break things
2021-08-05 10:43:59 <Ariadne> yes we can remove it
2021-08-05 10:44:10 <Ariadne> also we can change it to offset the libtls_version
2021-08-05 10:44:22 <ncopa> that would be good
2021-08-05 10:49:19 <ikke> ncopa: https://tpaste.us/Zj4d 
2021-08-05 10:49:28 <ikke> That's copied from the 3.14. release notes
2021-08-05 10:49:52 <ncopa> ok. I wonder if we should have a release doc somewhere
2021-08-05 10:49:59 <ikke> Yes, we certainly should
2021-08-05 10:50:07 <ncopa> but where?
2021-08-05 10:50:15 <ikke> That's what I was wondering as well
2021-08-05 10:54:04 <ncopa> Ariadne: what do you think: https://tpaste.us/lyVn
2021-08-05 10:54:27 <ncopa> $ find pkg/libretls | tpaste
2021-08-05 10:54:27 <ncopa> https://tpaste.us/dP4W
2021-08-05 10:55:24 <ncopa> we should probably verify that they are numbers
2021-08-05 10:56:20 <ncopa> $ git diff | tpaste
2021-08-05 10:56:20 <ncopa> https://tpaste.us/41or
2021-08-05 10:56:24 <ncopa> i think that should work
2021-08-05 10:57:49 <Ariadne> yes
2021-08-05 10:57:54 <Ariadne> it looks good
2021-08-05 10:58:08 <ncopa> ok. im pushing it
2021-08-05 10:58:16 <ncopa> thanks for help review
2021-08-05 11:13:22 <ikke> Adding TSC team: https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf/-/merge_requests/7
2021-08-05 12:25:34 <ncopa> 3.14.1 tagged
2021-08-05 13:38:45 <nmeum> has anybody booted Alpine riscv64 on the hifive unmatched yet?
2021-08-05 13:43:37 <ncopa> does this look ok? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.14.1-released.md
2021-08-05 13:45:44 <ncopa> ugh.. alpine-standard 3.14.1 ppc64le does not have any kernel
2021-08-05 13:45:57 <Hello71> i thought we fixed that
2021-08-05 13:46:14 <ncopa> i thought so too
2021-08-05 13:46:41 <ncopa> i actually tried to do a test release but my ppc64le dev env does not work
2021-08-05 13:46:49 <ncopa> basically, anything ppc64le does not seem to work anymore
2021-08-05 13:47:08 <mps> huh
2021-08-05 13:47:26 <mps> time to remove it
2021-08-05 13:48:39 <mps> if no one want/have box to give for development?
2021-08-05 13:48:59 <ncopa> they have gievn us multiple ubuntu boxes for development
2021-08-05 13:49:31 <mps> ubuntu on ppc64?
2021-08-05 13:49:37 <ncopa> yup
2021-08-05 13:49:59 <mps> aha, does lxc or qemu could help then
2021-08-05 13:50:03 <nmeum> I think we should have architecture-specific maintainers
2021-08-05 13:50:14 <nmeum> like someone we can ping if there is a problem with a specific architecture
2021-08-05 13:50:47 <mps> good idea
2021-08-05 13:51:40 <nmeum> maybe we just need one team per architecture or something along those lines
2021-08-05 13:52:28 <mps> ah, I misunderstood. I thought maintainer as admin of build boxes
2021-08-05 13:55:28 <ncopa> yeah, we should have arch teams
2021-08-05 13:57:40 <nmeum> maybe something for the next tsc meeting ;)
2021-08-05 14:14:04 <ncopa> i think i solved the ppc64le thingy
2021-08-05 14:15:57 <ncopa> the problem appears to be that there was no *.pub file in ~/.abuild/
2021-08-05 14:16:17 <ncopa> only the private key was there
2021-08-05 14:54:43 <Ariadne> regarding wget, i wonder if we should just include wget in alpine-base
2021-08-05 14:55:12 <Ariadne> the differences of the busybox version seems like something that gets discussed from time to time
2021-08-05 14:56:14 <clandmeter> ncopa: that wget commit looks like its missing a space
2021-08-05 14:56:22 <Ariadne> i think arm works well because there is a defacto arm team btw
2021-08-05 14:56:28 <Ariadne> same with riscv64
2021-08-05 14:56:42 <Ariadne> we have worked together collaboratively to tackle those issues
2021-08-05 15:02:19 <donoban> when I tried to fix #12517 I saw that busybox wget https support was pretty hacky, the author admits it deon't properly check certificates but doesn't admit complains about that, only code
2021-08-05 15:02:56 <danieli> busybox' wget is pretty janky in general
2021-08-05 15:05:42 <donoban> https://git.busybox.net/busybox/tree/networking/wget.c#n56
2021-08-05 15:06:35 <donoban> "It does not check public key's certificate:"
2021-08-05 15:07:11 <danieli> seems like it's mostly intended to download content from HTTPS-only web servers, not to be secure
2021-08-05 15:08:07 <donoban> well in apk context it could be "acceptable" but maybe it should warn the users
2021-08-05 15:08:38 <danieli> look at lines 101-102 though
2021-08-05 15:08:51 <donoban> yeah I was reading now
2021-08-05 15:08:58 <ncopa> i think we fixed the check cert thingy
2021-08-05 15:09:04 <ncopa> it has a CVE
2021-08-05 15:09:18 <ncopa> what we did was that we provide an ssl_client helper
2021-08-05 15:09:29 <donoban> ssl_client.c ?
2021-08-05 15:09:37 <ncopa> yup
2021-08-05 15:10:08 <danieli> self-rolled code nearly always leads to something funny, especially when it's related to crypto or privilege escalation/-pivoting
2021-08-05 15:10:14 <donoban> so maybe it is worth to properly fix this
2021-08-05 15:12:05 <ncopa> 1d0560a9b6b5597b191e5aff69a31c2fe0aba273
2021-08-05 15:16:11 <ncopa> i had a look at #12517 earlier today, and it did not seem trivial to fix
2021-08-05 15:16:31 <ikke> ncopa: I was thinking for the release checklist, we should do some (automated) post-checks as well to verify everything is in order
2021-08-05 15:16:40 <ncopa> yeah
2021-08-05 15:17:14 <ncopa> my signing script detected that the checksum didnt match
2021-08-05 15:33:42 <ncopa> ugh something is still broken with the ppc64le release
2021-08-05 15:33:47 <ncopa> i dont know what
2021-08-05 15:37:21 <ncopa> i think the rsync failed
2021-08-05 15:38:20 <ncopa> argh!!!! why does not rsync work from the ppc64le machine?
2021-08-05 15:40:06 <ikke> ncopa: to dl-master?
2021-08-05 15:40:10 <ncopa> yeah
2021-08-05 15:40:45 <ikke> that's the issue I've been facing against all the time
2021-08-05 15:41:07 <ikke> It hangs, right?
2021-08-05 15:41:14 <ncopa> correct
2021-08-05 15:41:21 <ncopa> smells like an mtu blackhole
2021-08-05 15:41:35 <ikke> But it's random
2021-08-05 15:41:44 <ikke> and it happens after megabytes of data have already been sent
2021-08-05 15:42:44 <ikke> Unless it's the reply back that is sudenly larger
2021-08-05 15:42:54 <ikke> but, it's too intermittent for me to be an MTU issue
2021-08-05 15:44:35 <ikke> ncopa: I tried to gbr1, and there it seems to work
2021-08-05 15:45:09 <ncopa> i thikn it finally managed to copy it all now
2021-08-05 15:45:16 <ncopa> i retried a few times
2021-08-05 15:45:20 <ikke> yeah
2021-08-05 15:45:32 <ikke> Something between the host and dl-master
2021-08-05 15:45:51 <ikke> That's also why the rsync issue appeared all the time for ppc64le
2021-08-05 15:46:01 <ncopa> right
2021-08-05 15:46:06 <ncopa> so it is not mtu?
2021-08-05 15:48:06 <Hello71> could be multipath mtu problem?
2021-08-05 15:48:14 <ikke> Hello71: perhaps
2021-08-05 15:48:23 <Hello71> i think ikke said reducing mtu at os level didn't fix it, but that was before --delay-updates fix
2021-08-05 15:48:29 <Hello71> so maybe it will fix it now?
2021-08-05 15:48:33 <ikke> these are 2 separate issues
2021-08-05 15:48:43 <Hello71> yes
2021-08-05 15:49:09 <Hello71> it wasn't clear to me whether there was some confusion between the two issues at that time
2021-08-05 15:49:17 <ikke> at least, not for me
2021-08-05 15:49:37 <Hello71> but if you're saying that the network connection still failed (not the rsync algorithm) after reducing mtu then it probably isn't that
2021-08-05 15:49:49 <ikke> yes, it did
2021-08-05 15:50:40 <Hello71> hm. have you tried tcpdump?
2021-08-05 15:50:42 <ikke> yes
2021-08-05 15:50:58 <Hello71> what does it say? did you check both sides?
2021-08-05 15:52:56 <Hello71> also does the ssh still work while the rsync is hanging? (i.e. it's definitely not the gateway crashing or something like that)
2021-08-05 15:53:29 <ikke> Yes, ssh would still work
2021-08-05 18:37:05 <Thermi> Can somebody please merge !23411?
2021-08-05 18:45:19 <ikke> Thermi: just 2 minor nits, then I'll merge it
2021-08-05 18:46:44 <Thermi> ikke, ty, I fixed and pushed it
2021-08-05 18:48:02 <Thermi> ikke, tyvm
2021-08-05 19:01:58 <Thermi> Something seems to be wrong with the armhf worker
2021-08-05 19:02:40 <Thermi> That hangs: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/456196
2021-08-05 19:04:35 <ikke> Something is using a lot of CPU
2021-08-05 19:04:47 <ikke> Load average: 297.62 284.91 189.75
2021-08-05 19:05:22 <Thermi> ty for merging
2021-08-05 19:06:42 <ikke> Not sure why rust is CPU intensive
2021-08-05 19:06:49 <ikke> The test suite here
2021-08-05 19:07:06 <Thermi> especially with that minor version upgrade, and only on armhf
2021-08-05 19:07:37 <ikke> https://tpaste.us/5nk0 
2021-08-05 19:15:28 <Thermi> Are you fine with how I split the packages and their commit messages? The packages are not strictly new, but they weren't uploaded to any repos yet.  !23966
2021-08-05 21:23:04 <Thermi> Somebody please review !23966 for me
2021-08-06 05:23:45 <Aftershock> anyone know if alpine includes vsock in the kernel?
2021-08-06 05:49:02 <ikke> CONFIG_VSOCKETS=m
2021-08-06 05:49:21 <ikke> Is that what you mean?
2021-08-06 06:52:58 <ncopa> good morning!
2021-08-06 06:53:32 <mps> good morning
2021-08-06 07:34:55 <Aftershock> all good just needed to reboot after upgrading
2021-08-06 08:35:48 <riverdc> what's the general process for taking over maintenance of packages, if the original maintainer isn't active?
2021-08-06 08:37:37 <xsteadfastx> i would see... write the current maintainer
2021-08-06 08:40:07 <ncopa> yeah, send an email to the original maintainer and ask if you can take it over. maybe CC the alpine-devel mailing list
2021-08-06 08:40:53 <riverdc> right, I've done that. it's been a few days, I'll forward it to the mailing list
2021-08-06 08:41:19 <ncopa> if you don't get any response within reasonable time (2 weeks?)  you can create an MR and in the commit message write that maintainer has not responded in X days or so
2021-08-06 08:41:32 <ncopa> which package is it?
2021-08-06 08:42:08 <riverdc> it's just a testing package, nothing important. it's testing/coq and I have !23746 open
2021-08-06 08:42:21 <riverdc> just something that I use personally quite a bit
2021-08-06 08:43:35 <ncopa> makes sense that you take over it
2021-08-06 08:45:09 <ncopa> alpine-mips-patches has not had any commits since 2019
2021-08-06 08:46:06 <ncopa> the name has 'mips' and to my understanding mips is dying
2021-08-06 08:46:45 <mps> I would give current maintainer at least one month to answer before taking maintainership
2021-08-06 08:46:59 <ncopa> so i wonder if its worth waiting another week...
2021-08-06 08:47:00 <ncopa> well
2021-08-06 08:47:16 <ncopa> if maintainer wakes and objects, its easy to give it back
2021-08-06 08:47:29 <mps> ofc, if package needs fix or upgrade it can be done 'now'
2021-08-06 08:47:31 <riverdc> oh it's not a big problem to wait, happy to wait another week or so
2021-08-06 08:47:35 <riverdc> just wanted to ask
2021-08-06 08:48:05 <riverdc> not hard to build my own version locally, which I have to do anyway since I want it compiled with some additional features
2021-08-06 08:48:45 <mps> riverdc: you can create MR and ask here someone to merge and review
2021-08-06 08:48:53 <ncopa> what happened with the coq-emacs subpackage?
2021-08-06 08:48:57 <ncopa> just curious
2021-08-06 08:49:49 <riverdc> ncopa: the MR description mentions, coq stopped shipping emacs files in 8.9
2021-08-06 08:51:32 <ncopa> oh, right
2021-08-06 08:51:43 <ncopa> that info would be nice to have in the commit message
2021-08-06 08:51:55 <riverdc> ah ok I'll add it thanks
2021-08-06 08:54:45 <ncopa> if you fix that i'll merge it
2021-08-06 09:05:57 <minecrell> Cogitri: I was trying to figure out why the libqmi build spams so many "Error: no ID for constraint linkend: "gboolean"." messages when building the gtk-docs (see: https://gitlab.alpinelinux.org/Minecrell/aports/-/jobs/456427) and it seems like this might be because main/glib does not build gtk-docs. Do you think it should be enabled there or would
2021-08-06 09:05:57 <minecrell> it be better to disable the gtk-docs in libqmi/modemmanager/...? Not sure how useful they are when packaged as apk
2021-08-06 09:17:14 <riverdc> strange... looks like aarch64 is failing after you rebased @ncopa. have no idea why, pretty sure it was passing beforehand
2021-08-06 09:17:38 <ncopa> it looks like a race in install
2021-08-06 09:17:59 <ncopa> my guess is that `make -j1 ... install` woudl solve it
2021-08-06 09:18:20 <Cogitri> minecrell: I don’t think many folks use the local development docs to be honest
2021-08-06 09:18:38 <Cogitri> And GObject libraries recently switched to something much nicer than gtk-doc anyway
2021-08-06 09:18:44 <riverdc> alright will try that
2021-08-06 09:18:46 <ncopa> the aarch64 has like 80 cores, so its higher probability to get into those cornercase issues
2021-08-06 09:18:59 <riverdc> ah i see
2021-08-06 09:19:43 <minecrell> Cogitri: Ah okay, will probably drop the --enable-gtk-doc from libqmi/modemmanager/... at some point them, it wastes a lot of build time too
2021-08-06 09:35:48 <mps> ncopa: should we remove 'quiet' option from bootloader?
2021-08-06 09:36:13 <ncopa> i think its configurable?
2021-08-06 09:36:39 <mps> last time when fcolista tried armv7 iso in qemu this reminded me 
2021-08-06 09:36:59 <mps> sorry, I mean in iso, netboot images
2021-08-06 09:37:08 <ncopa> i guess it makes sense to remove it when doing experimental stuff
2021-08-06 09:37:34 <clandmeter> no quiet is for debugging right?
2021-08-06 09:37:59 <mps> clandmeter: no, it is to see early what happens
2021-08-06 09:38:13 <clandmeter> isnt that the same?
2021-08-06 09:38:44 <mps> well, practically yes, but theoretically isn't ;)
2021-08-06 09:38:46 <clandmeter> as a regular user, you want to see what happens or just want to boot?
2021-08-06 09:39:22 <mps> I'm regular user and I want to see what happens during boot, always
2021-08-06 09:40:17 <mps> don't like to look at quiet screen for about 5-10 (sometimes a lot more) seconds and wonder 'will it'
2021-08-06 09:40:32 <clandmeter> :)
2021-08-06 09:40:42 <mps> and if the problem happens I want to see 'asap'
2021-08-06 09:40:48 <clandmeter> i agree, i want the same. but is it what everyone wants?
2021-08-06 09:41:14 <mps> well, I never used windows so I don't have 'this' mindset :)
2021-08-06 09:42:04 <ikke>  I also prefer to boot without quiet
2021-08-06 09:42:32 <clandmeter> maybe our user base prefers no quiet
2021-08-06 09:42:48 <clandmeter> something for the tsc? :)
2021-08-06 09:43:12 <clandmeter> mps: maybe you can add an issue to the tsc tracker
2021-08-06 09:43:17 <mps> no, I see council members opinion is enough :)
2021-08-06 09:43:59 <mps> I think I'm not tsc member
2021-08-06 09:47:43 <clandmeter> mps: you dont need to be a tsc member to create an issue
2021-08-06 09:48:19 <clandmeter> if you create an issue for it, it will be on the agenda next time (if its not yet decided in the issue itself).
2021-08-06 09:49:04 <mps> will do if you be my advocate there :)
2021-08-06 09:49:17 <mps> will be*
2021-08-06 09:51:19 <donoban> +1 for no quiet :D
2021-08-06 09:52:18 <mps> donoban: thanks
2021-08-06 09:53:53 <mps> 
ACTION will be afk few hours

2021-08-06 10:00:15 <ncopa> i prefer quiet :)
2021-08-06 10:00:21 <ncopa> lets ask TSC
2021-08-06 10:00:51 <ncopa> have a nice weekend everybody!
2021-08-06 10:01:09 <donoban> hehe, you too ncopa 
2021-08-06 10:02:16 <fcolista> _0/ ncopa!
2021-08-06 10:06:54 <clandmeter> mps: no problem we can overrule ncopa this time ;-)
2021-08-06 10:30:49 <mercenary> Indeed. Another +1 for no quiet
2021-08-06 11:47:30 <Hello71> mps: problem is without quiet is much slower
2021-08-06 11:48:01 <Hello71> because fbcon is designed poorly
2021-08-06 12:54:21 <skarnet> now what if, just hear me out, what if... it was an option that the user could choose?
2021-08-06 12:57:12 <Hello71> i mean, it already is? type loglevel=7 at boot: line
2021-08-06 12:57:53 <Hello71> for sys install, edit /etc/update-extlinux.conf, and for data install i don't think we have a good system for managing kernel arguments in general
2021-08-06 13:04:21 <adamplumb> Regarding merge requests for aports, whose job is it to actually merge it?  I have this one open (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23727) that seems like everyone is ok with.  But it is assigned to Nathaniel Copa who hasn't weighed in on it yet.  Does it sit until he gets to it?
2021-08-06 13:18:22 <Ariadne> if it is a change to a pre-existing package it is generally polite to wait for the maintainer to review it
2021-08-06 13:20:27 <Ariadne> however, ncopa (the maintainer) does not historically have a problem with updates to his packages if they are approved by others
2021-08-06 13:22:34 <Ariadne> given that, i will go ahead and merge it
2021-08-06 13:27:24 <Ariadne> +1 for quiet
2021-08-06 13:39:32 <adamplumb> thanks!
2021-08-06 14:06:54 <minimal> Regarding Grub package - Grub itself is installed in the MBR or to the ESP partition by setup-disk during initial install. Whenever a new version of the GRUB package is installed (i.e. via "apk upgrade") the newer version is never actually installed to the MBR / ESP partition (i.e. grub-install is never called)
2021-08-06 14:07:09 <minimal> Wondering if this is by intention or its an omission....
2021-08-06 14:31:23 <Hello71> arch and gentoo don't either
2021-08-06 14:33:03 <Ariadne> if it isn't broken, don't fix it :D
2021-08-06 14:33:29 <Hello71> the problem is the grub-install invocation isn't saved, so you don't actually know where to reinstall it
2021-08-06 14:33:40 <Hello71> update-extlinux basically just guesses
2021-08-06 14:33:49 <Hello71> (i don't like update-extlinux either)
2021-08-06 14:35:53 <minimal> Hello71: yeah I realise that - a solution would have to remember whatever options were originally passed to grub-install
2021-08-06 14:38:21 <minimal> Ariadne: as you're our resident security person - remember Grub has some CVEs a while back, so how many Alpine (Sys-mode) mode users may still be using versions with those issues despite having updated Grub apk installed?
2021-08-06 14:39:04 <Ariadne> well, i would say there is probably a lot of unpatched grub
2021-08-06 14:39:09 <Ariadne> but, you have to also consider
2021-08-06 14:39:13 <Ariadne> that grub has made releases
2021-08-06 14:39:20 <Ariadne> where the damn bootloader didn't work at all
2021-08-06 14:39:36 <Ariadne> so this isn't either/or, it's "how do you want to get screwed over" basically
2021-08-06 14:39:41 <Hello71> also how many people are using grub password for serious security
2021-08-06 14:40:09 <Ariadne> yes, also that
2021-08-06 14:40:12 <minimal> Ariadne: same could be said for any software package (i.e. sh, openrc, etc)
2021-08-06 14:40:22 <Ariadne> just because something has an unpatched CVE, does not mean it is actually a huge problem
2021-08-06 14:40:47 <Ariadne> minimal: yes, but in those cases, we would be equally conservative on making sure they don't break
2021-08-06 14:40:53 <minimal> Hello71: so what alternative for "serious security" would you suggest?
2021-08-06 14:40:59 <Hello71> fde
2021-08-06 14:41:03 <Ariadne> ^
2021-08-06 14:41:37 <Ariadne> i too, would suggest using an approach that is actually secure, rather than a keep out sign
2021-08-06 14:41:41 <minimal> Hello71: hardware drive encryption? some drive vendors have been show to have dodgy firmware thats easily bypassed
2021-08-06 14:41:55 <Hello71> vendor drive encryption is not full
2021-08-06 14:41:56 <Ariadne> clearly we mean dm-crypt
2021-08-06 14:42:43 <minimal> right, by dm-crypt doesn't cover /boot, that's what the GRUB is adding in *addition* to dm-crypt
2021-08-06 14:42:49 <minimal> as/by/but/
2021-08-06 14:42:50 <ericonr> hardware encryption is just a scam
2021-08-06 14:42:59 <Hello71> what is the threat model for protecting /boot
2021-08-06 14:43:08 <Ariadne> running an unauthorized kernel i guess
2021-08-06 14:43:18 <Hello71> just boot from external media
2021-08-06 14:44:08 <Hello71> funny thing is, every enterprise machine i've seen with password-protected bios also has password-less pxe enabled
2021-08-06 14:44:49 <Hello71> and almost always exposed ethernet ports
2021-08-06 14:46:16 <Hello71> even ignoring the well-known firmware password bypasses (particularly dell)
2021-08-06 14:46:24 <minimal> we're getting away from the original issue/point - that updated Grub MBR/ESP files are never installed. The issue about Grub broken releases equally applies to any package - the Alpine maintainer (certainly for "main") is expected to do some sanity checking before raising a MR. It won't catch everything but it should catch obviously broken releases
2021-08-06 14:47:11 <Hello71> well you still haven't answered how to discover the proper install arguments
2021-08-06 14:47:21 <Ariadne> i mean
2021-08-06 14:47:27 <Ariadne> it *should* be upgraded
2021-08-06 14:47:31 <Hello71> i agree
2021-08-06 14:47:32 <Ariadne> preferably to something not grub
2021-08-06 14:47:33 <Ariadne> :p
2021-08-06 14:47:43 <Hello71> yes, systemd-boot everywhere!
2021-08-06 14:48:02 <Ariadne> yes, systemd everywhere
2021-08-06 14:48:03 <Ariadne> :D
2021-08-06 14:48:09 <Hello71> is there a decent systemd-boot without systemd yet
2021-08-06 14:48:32 <Ariadne> somebody should make it
2021-08-06 14:48:38 <Ariadne> then we should delete grub
2021-08-06 14:48:39 <Ariadne> :D
2021-08-06 14:48:46 <minimal> Hello71: yes "we" are in a hole, I guess all that could be done going forward would be in a new version of "setup-disk" to store the settings somewhere and then a new Grub package checks for that files of settings and updated if it is present
2021-08-06 14:49:29 <Hello71> that could work, but what happens if someone runs setup-disk and then runs grub-install manually
2021-08-06 14:49:42 <Hello71> or sets up a different boot loader
2021-08-06 14:49:59 <Hello71> for example what happens if you install both syslinux and grub
2021-08-06 14:50:22 <Hello71> i think extlinux --update checks if the existing bootloader is extlinux-like
2021-08-06 14:51:15 <minimal> those are all good points relevant for how to resolve the current situation, presently I was pointing out that there is a situation
2021-08-06 14:51:42 <Hello71> afaik the only non-platform-specific efi boot managers are systemd-boot, refind, syslinux, grub, and maybe uboot?
2021-08-06 14:52:08 <Hello71> (i.e. excluding bootmgr, iboot, etc)
2021-08-06 14:52:47 <minimal> I think someone here re-awakened gummiboot (which AFAIK was the base for systemd-boot)
2021-08-06 14:53:47 <minimal> regardless of whichever is the "best" bootloader, I'm trying to focus on this issue with Grub
2021-08-06 14:54:16 <Hello71> i think we already agreed that grub should be updated
2021-08-06 14:54:51 <minimal> as for extlinux which you mentioned - there might be a similar issue there for MBR, can't remember exactly what the update-extlinux script does exactly
2021-08-06 14:55:28 <minimal> with syslinux/extlinux for UEFI there's no issue as if you want to use it with UEFI you have to setup everything manually
2021-08-06 15:02:49 <Ariadne> extlinux does update
2021-08-06 15:03:00 <Ariadne> but the extlinux installer works by probing the partitions to find itself
2021-08-06 15:15:25 <Hello71> solution: use syslinux for efi /s
2021-08-06 15:29:28 <mps> Hello71: yes, fb is slow. so by default no 'quiet' and if the user wants s/he can set it to quiet
2021-08-06 15:32:06 <mps> now it 5.14 kernels we will have simple-drm, maybe it will be faster
2021-08-06 15:32:14 <mps> s/it/in/
2021-08-06 15:32:14 <alpine-meetbot> mps meant to say: now in 5.14 kernels we will have simple-drm, maybe it will be faster
2021-08-06 15:37:07 <Hello71> hm, i didn't notice that
2021-08-06 15:37:52 <Hello71> will it be faster? last i checked fbcon on amdgpu is still pretty slow
2021-08-06 15:38:10 <Hello71> i think it should be faster than high-res vesafb but hopefully nobody uses that
2021-08-06 15:40:14 <mps> also my hopes are not high about it
2021-08-06 16:50:13 <Ariadne> Cogitri: would it be possible to have algitbot cc @teams/security on MRs about security upgrades?
2021-08-06 16:55:00 <Hello71> how should it tell which ones
2021-08-06 16:55:26 <ikke> usually there is 'security' in the title
2021-08-06 17:06:59 <Thermi> Please somebody take a look at !23966 for me, even if you just look at a single APKBUILD in it
2021-08-06 17:07:50 <ikke> Sorry, too tired atm\
2021-08-06 17:10:26 <Hello71> can anyone figure out why https://gitlab.alpinelinux.org/alxu/aports/-/jobs/456648 is failing? it works on all other archs. i tried restarting it and it failed in the same way
2021-08-06 17:10:56 <Hello71> i am guessing that libQt5DBus.so.5.15.3.debug is a broken symlink or something, but that doesn't explain why it works on other archs
2021-08-06 17:18:02 <ikke> >>> WARNING: qt5-qtbase: qt5-qtbase-dbg should be first in subpackages?
2021-08-06 17:21:54 <Hello71> i thought it is now
2021-08-06 17:24:36 <Hello71> and anyways, i think that shouldn't cause that error
2021-08-06 17:25:19 <Hello71> iirc it should just cause the debug symbols for the subpackages to be thrown out
2021-08-06 20:53:11 <ikke> Hello71: I can reproduce it in docker on armv7, anything I should look for?
2021-08-06 20:53:19 <Hello71> uh...
2021-08-06 20:53:30 <Hello71> i thought you were tired :p
2021-08-06 20:53:37 <ikke> I took a nap
2021-08-06 20:54:17 <Hello71> i guess find $srcdir $builddir $pkgdir -name libQt5DBus.so.5.15.3.debug -exec ls -l {} +
2021-08-06 20:54:34 <Hello71> wait, no, make it 'libQt5DBus.so.5.15.3*'
2021-08-06 20:55:44 <ikke> pkg/qt5-qtbase-dbg/usr/lib/debug/usr/lib/libQt5DBus.so.5.15.3.debug
2021-08-06 20:55:48 <ikke> not a symlink
2021-08-06 20:56:09 <Hello71> hm, let me check what abuild is actually doing
2021-08-06 20:56:23 <Thermi> Ariadne, thanks!
2021-08-06 20:56:42 <Ariadne> Thermi: please monitor #alpine-commits
2021-08-06 20:56:49 <Thermi> I will join.
2021-08-06 20:56:51 <ikke> spellchecker is failing
2021-08-06 20:57:35 <Hello71> oh wait, hold on, getfattr is supposed to run on the source file
2021-08-06 20:58:03 <Thermi> ikke, where?
2021-08-06 20:58:15 <Thermi> saw it
2021-08-06 20:58:57 <Thermi> Oh jesus is their stash not stable?! FFS.
2021-08-06 20:59:07 <Ariadne> :D
2021-08-06 20:59:43 <ikke> sigh\
2021-08-06 21:00:03 <Ariadne> i'll be around for a while
2021-08-06 21:00:08 <Hello71> ah, i figured it out
2021-08-06 21:00:09 <Ariadne> ping me when you have new things to push
2021-08-06 21:00:27 <Hello71> it's the same problem as https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2475
2021-08-06 21:02:54 <Hello71> it's roughly what i thought, armv7 has too many cores :p
2021-08-06 21:03:26 <Hello71> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54 should fix it but i need to figure out if it's actually ok for merge
2021-08-06 21:04:08 <Hello71> man, this rabbit hole. qtwebkit -> notepadqq -> qtbase -> qmake -> abuild
2021-08-06 21:04:24 <Hello71> next it will turn out this also triggers some rsync bug or something
2021-08-06 21:07:46 <Ariadne> just delete it
2021-08-06 21:14:24 <Hello71> ikke: it's because scanelf is scanning while objdump is dumping, so it randomly gets some temp files. the debug symbol fix triggers it because objdump will spend more time dumping so there is much higher chance of running into it
2021-08-06 21:14:46 <Hello71> thanks, i think you can delete your container if you need the space or whatever
2021-08-06 21:15:21 <Hello71> now if someone could tell me why the hell i put this cd here: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54/diffs#adc2ae0a3e467606d17056e7a9ca547d89344d3b_1911_1908
2021-08-06 21:15:50 <Hello71> i think what it does is copy all the .so files into the dbg subpackage
2021-08-06 21:16:03 <Hello71> or, wait...
2021-08-06 21:16:42 <Hello71> ah, right, it's because --add-gnu-debuglink is stupid
2021-08-06 21:17:43 <Hello71> !@#$ing binutils.
2021-08-06 21:37:49 <Thermi> Ariadne, !23993 let's try the zips instead
2021-08-06 21:38:18 <Thermi> Oh damn, I just noticed something.
2021-08-06 21:38:19 <Thermi> Oh no
2021-08-06 21:38:20 <Thermi> OH NO
2021-08-06 21:38:51 <Thermi> Thanks linter.
2021-08-06 21:47:38 <ikke> 
ACTION should work on the linter not seeing APKBUILDs as dash

2021-08-06 21:49:42 <Thermi> Fixed now
2021-08-06 21:49:45 <Thermi> (should be)
2021-08-06 21:56:14 <Hello71> so i just spent a solid 20 minutes trying to figure out why my code is creating cups-dbg/usr/lib/debug/usr/lib/debug. turns out... !23994
2021-08-06 21:57:06 <ikke> :D
2021-08-06 21:57:09 <ikke> it was there twice :D
2021-08-06 21:57:26 <ikke> It does not need to be rebuilt?
2021-08-06 21:58:15 <Hello71> uh, probably does :p
2021-08-06 21:58:21 <Hello71> keep forgetting
2021-08-06 21:58:34 <ikke> :)
2021-08-06 21:58:38 <Hello71> thanks
2021-08-06 23:41:05 <Thermi> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/111
2021-08-06 23:41:24 <Thermi> Implementing support for directly extracting into subdirectories of srcdir
2021-08-07 03:34:03 <riverdc> if someone could review/merge !23636, that'd be helpful. I have a new aport I want to MR that's blocked on this
2021-08-07 06:54:36 <ikke> riverdc: will be merged
2021-08-07 07:07:23 <riverdc> thanks
2021-08-07 09:25:04 <Cogitri> Hello71: Thanks for the pings and cleaning up the issues. I’m currently caught up in some uni project but hopefully I should be able to sort through all of that sometime next week (unless I have to do some last minute finishing touches with my GSoC student on their project :D)
2021-08-07 09:25:46 <Cogitri> Ariadne: Sure, the bot could do that. Maybe you can open an issue detailing how you want it to work at cogitri/aports-qa-bot ?
2021-08-07 09:44:50 <nmeum> Ariadne: do we want to rebuild all go packages for CVE-2021-36221 and CVE-2021-34558? Both don't seem extremly critical to me but iirc we have not rebuild statically linked go packages since go 1.16.5
2021-08-07 10:05:17 <ikke> Maybe we can create an index of go dependencies per package
2021-08-07 10:05:24 <ikke> then we can do more targetted rebuilds
2021-08-07 10:14:13 <nmeum> maybe but will be a lot of work and hard to get right I think
2021-08-07 10:14:19 <ikke> fun that one project has 20 versions of grpc as transitive dpendencies
2021-08-07 10:14:47 <ikke> nmeum: should be feasible for projects that use go modules
2021-08-07 10:14:56 <ikke> but, just rebuilding is not always enough
2021-08-07 10:15:18 <nmeum> are we talking standard library or external dependencies?
2021-08-07 10:15:30 <nmeum> because the aforedmentioned CVE's are in the standard library
2021-08-07 10:18:29 <ikke> right
2021-08-07 10:18:48 <ikke> standard library is more difficult
2021-08-07 10:23:50 <nmeum> just a different kind of difficult I think :)
2021-08-07 10:23:51 <nmeum> at least you don't need to deal with pinned/vendored dependencies where you have to update the pinned version first and stuff like that
2021-08-07 10:23:56 <ikke> go list -f '{{range $imp := .Imports}}{{printf "%s\n" $imp}}{{end}}' | sort
2021-08-07 10:27:00 <ikke> Not sure you how can reliably distinguish between standard imports and external ones
2021-08-07 10:27:02 <nmeum> we also need to integrate that with alpine tooling somehow so you can do something like "give me all go packages/aport which import os/user"
2021-08-07 10:27:31 <ikke> ap is pure static on data in APKBUILDs
2021-08-07 10:27:50 <nmeum> and there is also weird go software like docker which comes with its own strange build system
2021-08-07 11:05:42 <Thermi> if only ap could determine the name of the main package of the dependencies
2021-08-07 11:05:48 <Thermi> (e.g. foo, not foo-dev)
2021-08-07 11:22:20 <nmeum> apk search --origin foo-dev?
2021-08-07 11:22:48 <nmeum> probably want to add --exact too
2021-08-07 11:48:35 <Thermi> ap, not apk
2021-08-07 11:55:45 <nmeum> ah, I misread your message
2021-08-07 12:01:43 <Thermi> ap has recursive-deps that gives you the recursive deps of X, but they're not the main package names. If that was resolved directly, one could just loop over its output to descend into directories and run abuild
2021-08-07 12:03:59 <Hello71> ncopa: for abuild tests, are we assuming that build-base is installed as usual? e.g. gcc, binutils, etc are available
2021-08-07 12:05:57 <mps> Hello71: alpine-sdk metapkg
2021-08-07 12:06:05 <Hello71> ok
2021-08-07 12:13:23 <Ariadne> nmeum: i think lets do it
2021-08-07 12:13:42 <Ariadne> nmeum: risk seems low, and i dont think the builders are going to be too busy over weekend
2021-08-07 12:34:43 <Hello71> ikke: can you make https://gitlab.alpinelinux.org/alxu/apk-tools public
2021-08-07 12:35:14 <ikke> done
2021-08-07 12:35:30 <Hello71> thanks
2021-08-07 12:35:57 <Hello71> i think this may be the reason why people make MRs to own master?
2021-08-07 12:36:15 <Hello71> gitlab picked own repo master for me, but after you made public, it picked alpine master
2021-08-07 12:36:25 <ikke> aha, perhaps
2021-08-07 12:40:16 <Thermi> it is.
2021-08-07 12:41:52 <Ariadne> alpine needs an OS-tan and i'm putting Hello71 in charge of figuring that out
2021-08-07 12:42:14 <Hello71> wat
2021-08-07 12:42:20 <Ariadne> exactly
2021-08-07 12:42:49 <ikke> OS-tan?
2021-08-07 12:46:25 <Thermi> Oh no.
2021-08-07 12:46:33 <Thermi> An anime character representing the OS.
2021-08-07 12:47:17 <Thermi> I think Alpine already has the alps.
2021-08-07 12:47:22 <Thermi> Offline for now.
2021-08-07 12:53:56 <Ariadne> yes it can be depicted slaying systemd-tan, sudo-tan, etc
2021-08-07 12:53:57 <Ariadne> ;)
2021-08-07 14:24:35 <Thermi> People going crazy on ossec again
2021-08-07 14:24:41 <Thermi> ABOLISH SNI
2021-08-07 14:25:01 <Thermi> (ignoring that it's required for virtual http servers)
2021-08-07 14:25:32 <ikke> They argue that every site should have a unique ip
2021-08-07 14:26:07 <Ariadne> bad take aside, the issue is actually far worse than SNI
2021-08-07 14:26:11 <Ariadne> read my followup :)))
2021-08-07 14:27:47 <ikke> yea
2021-08-07 14:27:59 <ikke> When I saw the bug, I assumed something like that was the case
2021-08-07 15:12:00 <nmeum> why is the `uname -m` output on the armhf/armv7 GitLab CI armv8l?
2021-08-07 15:12:39 <ikke> that's arm 32-bits on aarch64
2021-08-07 15:13:07 <nmeum> ah
2021-08-07 15:15:40 <nmeum> what would be the "correct" `uname -m` value for armhf? armv6l?
2021-08-07 15:17:09 <ikke> that'
2021-08-07 15:17:15 <ikke> that's what it returns on my rpi
2021-08-07 15:18:00 <nmeum> ok, I will convience the build system to use that value then. thanks :)
2021-08-07 15:18:13 <nmeum> *convince
2021-08-07 16:30:26 <nmeum> hm. the GitLab CI just uses the alpinelinux/build-base docker images, right?
2021-08-07 16:31:03 <nmeum> because this job https://gitlab.alpinelinux.org/alpine/aports/-/jobs/457370 seems to hang on the CI but I can't reproduce it locally even if I use the build-base docker image
2021-08-07 16:35:30 <ikke> yes, alpine-gitlab-ci, which is based on build-base
2021-08-07 16:51:27 <liske> I'm trying to package a daemon that builds and uses it's own shared libraries. abuild fails with "Could not find owner package" for the .so files just build by abuild
2021-08-07 16:51:44 <liske> How could that be handled? !24018
2021-08-07 16:58:08 <Hello71> i think i recall that for dlopen, DT_NEEDED shouldn't be used
2021-08-07 20:34:47 <Ariadne> why
2021-08-07 20:35:06 <Ariadne> consider a "plugin" which depends on a third-party library
2021-08-07 20:35:19 <Ariadne> that the main app does not require
2021-08-07 20:35:31 <Ariadne> if DT_NEEDED is not processed, then that library wont get loaded
2021-08-07 20:49:22 <liske> I found the reason why abuild did complain: I had used $pkgdir in CMAKE_INSTALL_PREFIX instead of using make install DESTDIR="$pkgdir" *facepalm*
2021-08-07 20:49:41 <ikke> aha
2021-08-07 20:49:52 <ikke> I already was puzzled why it was a problem
2021-08-07 20:53:43 <liske> using ldd showed that the binary was linked to a weird path:  libtriton.so => /build/testing/accel-ppp/pkg/accel-ppp/usr/lib/accel-ppp/libtriton.so (0x7efcc5fb4000)
2021-08-07 20:56:18 <caskd> I've heard that there's gonna be some changes on how testing should be handled later and for how long a package should stay in testing and then it struck me that i didn't know what qualifies to go in community and when. I tried to look on the wiki and aports but didn't find much. Is this documented somewhere?
2021-08-07 21:02:55 <donoban> ey mps I noticed that powertop fails on linux-edge "modprobe cpufreq_stats failedFailed to mount debugfs!
2021-08-07 21:03:29 <donoban> it works properly on linux-lts
2021-08-07 21:03:32 <caskd> isn't debugfs disabled in kernel cfg?
2021-08-07 21:03:50 <donoban> it seems similar to linux-lts, I'm not sure what it misses
2021-08-07 21:03:54 <caskd> hm
2021-08-07 21:04:45 <donoban> maybe "CONFIG_GENERIC_IRQ_DEBUGFS is not set"
2021-08-07 21:05:46 <donoban> uhm no
2021-08-07 21:05:56 <donoban> this # CONFIG_DEBUG_FS is not set
2021-08-07 21:30:50 <mps> donoban: powertop is 'outdated' tool
2021-08-07 21:32:50 <mps> I intentionally disabled all debug options in linux-edge wherever is posible
2021-08-07 21:33:53 <mps> 'we' need small and fast default kernel imo, those who need debugging could build it easily
2021-08-07 21:36:18 <donoban> ah, good to know
2021-08-07 21:36:34 <donoban> is there some alternative for power usage monitoring?
2021-08-07 21:37:07 <mps> sbs_battery on arm :)
2021-08-07 21:37:17 <mps> sorry, couldn't resist
2021-08-07 21:37:48 <donoban> hehe I'm using edge for some weeks and didn't miss powertop
2021-08-07 21:38:14 <donoban> I just noticed that my battery die too fast
2021-08-07 21:38:31 <donoban> I wonder if is something related with the kernel
2021-08-07 21:39:48 <mps> default cpu frequency is performance, could this be reason
2021-08-07 21:40:07 <donoban> ahh
2021-08-07 21:40:09 <donoban> lol
2021-08-07 21:40:22 <donoban> lts is ondemand?
2021-08-07 21:40:22 <caskd> on current edge? it has been clocking down often recently
2021-08-07 21:40:25 <caskd> i think it changed
2021-08-07 21:40:27 <mps> on battery powered boxes I set it to conservative
2021-08-07 21:40:37 <donoban> uhM
2021-08-07 21:40:52 <donoban> conservative is not for slow down freq reduction?
2021-08-07 21:41:14 <mps> yes, but I find conservative is most battery friendly
2021-08-07 21:41:14 <donoban> it scales up when need, but waits a little for goin back
2021-08-07 21:41:39 <donoban> ah
2021-08-07 21:41:47 <mps> donoban: which arch you use
2021-08-07 21:41:52 <donoban> x86_64
2021-08-07 21:42:00 <mps> aha
2021-08-07 21:42:35 <mps> x86_64 linux-edge have config similar to linux-lts, arm ones are more different
2021-08-07 21:43:06 <donoban> well running performance governor is not good choice for a laptop
2021-08-07 21:43:31 <mps> right :)
2021-08-07 21:43:54 <caskd> interesting, i'm running edge and i have schedutil as governor
2021-08-07 21:44:04 <caskd> didn't tweak settings afaik
2021-08-07 21:44:12 <mps> caskd: also x86_64?
2021-08-07 21:44:14 <caskd> yep
2021-08-07 21:44:21 <donoban> I'm running tlp too, it should adjust the cpu governor
2021-08-07 21:44:30 <caskd> oh but i'm on lts
2021-08-07 21:44:32 <caskd> my bad
2021-08-07 21:44:51 <caskd> forgot i switched to lts because my laptop needs a out of tree module
2021-08-07 21:44:57 <caskd> should probably upstream it soon
2021-08-07 21:45:32 <mps> caskd: we now have akms, alpine kernel module system
2021-08-07 21:45:43 <caskd> oh
2021-08-07 21:46:44 <donoban> uhM
2021-08-07 21:46:53 <donoban> now I'm running powersave (probably due tlp)
2021-08-07 21:47:10 <donoban> maybe tlp fails on linux-edge
2021-08-07 21:47:32 <caskd> no package uses akms yet?
2021-08-07 21:48:14 <caskd> oh my god the irony
2021-08-07 21:48:18 <mps> caskd: I saw one
2021-08-07 21:48:25 <mps> forgot name
2021-08-07 21:48:30 <caskd> the module in the example is exactly the one i want to upstream
2021-08-07 21:48:32 <caskd> haha
2021-08-07 21:48:38 <donoban> hehe
2021-08-07 21:49:22 <mps> donoban: long to read but useful about cpu freqs, power and performance https://www.kernel.org/doc/html/v4.12/admin-guide/pm/cpufreq.html
2021-08-07 21:50:29 <donoban> is not so long :)
2021-08-07 21:50:32 <donoban> thanks mps 
2021-08-07 21:52:47 <mps> well, I didn't had patience to read it fully ;)
2021-08-07 21:52:59 <donoban> :D
2021-08-07 21:55:04 <donoban> mps: do you think is good idea to run on performance on powered on computers?
2021-08-07 21:58:54 <donoban> oh, conservative also steps up slowly
2021-08-07 21:59:01 <donoban> now I see the point
2021-08-07 22:00:37 <mps> donoban: you powered by electric power lines, not batteries?
2021-08-07 22:00:51 <donoban> yes a desktop
2021-08-07 22:00:54 <mps> you mean?
2021-08-07 22:00:59 <mps> you mean*
2021-08-07 22:01:01 <mps> uhh
2021-08-07 22:01:39 <ikke> caskd: regarding packages in testing: there is currently not a lot of documentation, it's something we plan to address
2021-08-07 22:01:47 <mps> yes, I run desktops and servers with performance
2021-08-07 22:02:41 <donoban> I will have to consider it
2021-08-07 22:02:47 <caskd> ikke: okay, as i have one package that's likely ready for community and another one which i have to submit some patches upstream to clean the build system so it's good to know
2021-08-07 22:03:08 <donoban> I guess you think that it doesn't affect lifetime significatlly
2021-08-07 22:03:10 <mps> donoban: there is powercap options (subsystem) in newer kernels by which power can be fine controlled but I didn't found time to 'play' with it, yet
2021-08-07 22:03:49 <ikke> The idea behind the testing repo was that it allows maintainers to test their packages before it becomes part of a supported release
2021-08-07 22:04:26 <caskd> oh, then i guess both packages are ready
2021-08-07 22:04:38 <mps> donoban: new 'features' in OS and apps is what 'take' lifetime of computers, mostly
2021-08-07 22:04:40 <ikke> So all that is required for a package to move to community is to verify it works correctly and general adheres to alpine policies
2021-08-07 22:05:01 <ikke> there are no time requirements
2021-08-07 22:06:27 <donoban> I was considering if the constant max freq would be less stressful for the CPU than the temperature variation due freq swtiching
2021-08-07 22:06:32 <caskd> Is there a way to get a list of packages from apk list without versions?
2021-08-07 22:07:01 <caskd> the new _git broke the zsh completion so i don't know if i should keep cutting the versions away manually
2021-08-07 22:07:54 <mps> donoban: I don't follow modern cpus chemistry but lower freq means lower temp, and lower temp means longer lifetime
2021-08-07 22:08:52 <donoban> well, next time I reboot to edge kernel I will check the governor and if there is some problem with tlp
2021-08-07 22:09:03 <mps> bu I remember that nearly from the beginning linux used 'halt' instruction when it doesn't have something to do
2021-08-07 22:09:16 <mps> but*
2021-08-07 22:11:14 <donoban> when I go to home I will test performance with some servers
2021-08-07 22:11:33 <donoban> maybe I switch to it :)
2021-08-07 22:12:23 <mps> and modern cpus have even voltage switching to control its efficiency and power usage
2021-08-07 22:15:20 <caskd> ikke: re !22449 : shouldn't it be re-enabled in a separate mr? I've only bumped the pkgrel which probably doesn't fix the problem
2021-08-07 22:15:35 <mps> to add a little about https://www.kernel.org/doc/html/v5.13/power/powercap/dtpm.html (Dynamic Thermal Power Management framework)
2021-08-07 22:15:53 <ikke> caskd: Didn't mean it has to be done in the same MR, but it has to be done before this can be merged
2021-08-07 22:16:01 <caskd> oh i see
2021-08-07 22:16:02 <mps> but hey, too late, good night all
2021-08-07 22:16:21 <donoban> good night :)
2021-08-07 22:16:44 <ikke> night
2021-08-07 22:16:51 <caskd> o/
2021-08-08 03:14:26 <Aftershock> clear
2021-08-08 03:15:11 <Aftershock> hey does anyone know when qemu-6.1.rc2 is coming to alpine edge?
2021-08-08 03:16:32 <Aftershock> qemu 6.0 has an incompatibility with LXD
2021-08-08 05:40:51 <mps> Aftershock: we don't package rc and beta software, especially important ones
2021-08-08 07:39:43 <mps> does someone know why this happens on s390x while not on others https://gitlab.alpinelinux.org/alpine/aports/-/jobs/457009#L4153
2021-08-08 09:16:55 <nmeum> mps: if you run it locally with CBUILD=s390x abuild rootbld you might be able to debug the test failure further in a chroot
2021-08-08 09:17:55 <nmeum> who knows, maybe it's an actual bug in dovecot
2021-08-08 09:23:49 <mps> nmeum: all other arches passed on CIs, and I also tested in lxc x86_64 and aarch64, only this one test fails on s390x CI
2021-08-08 09:25:21 <nmeum> still doesn't mean that the code executed by this test doesn't depend on some architecture-specific detail which only causes it to fail on s390x
2021-08-08 09:25:32 <nmeum> if you don't want to debug it at least report it upstream :p
2021-08-08 09:26:58 <mps> not that I don't want, but I don't know anything about s390x
2021-08-08 09:27:38 <mps> except it is a big box
2021-08-08 09:28:50 <mps> and yes, problems I can't solve with dovecot I always report to upstream, usually on irc
2021-08-08 09:29:19 <donoban> ey mps digging into switching my servers to performance I found this https://www.phoronix.com/scan.php?page=article&item=amd-linux511-perfgov&num=1
2021-08-08 09:29:28 <mps> upstream author is very responsive and helpful
2021-08-08 09:31:56 <mps> donoban: this is about perfomance, not about 'powersave' with acceptable responsiveness
2021-08-08 09:32:24 <mps> but 'poweroff' if best option for power saving :)
2021-08-08 09:32:28 <donoban> yeah, I missed some idle power consumption comparison
2021-08-08 09:44:50 <donoban> uhM, something is wrong, I only see "performance powersave" available governors regardless I loaded conservative and theorically ondemand and schedutil are built-in
2021-08-08 09:46:47 <mps> cpufreq_conservative.ko
2021-08-08 09:47:12 <donoban> yes
2021-08-08 09:47:21 <donoban> [donoban@localhost][~]% lsmod | grep conservative
2021-08-08 09:47:23 <donoban> cpufreq_conservative    16384  0
2021-08-08 09:48:30 <donoban> localhost# echo conservative > cpu0/cpufreq/scaling_governor
2021-08-08 09:48:32 <donoban> echo: write error: invalid argument
2021-08-08 09:48:52 <mps> at /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
2021-08-08 09:48:58 <mps> cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
2021-08-08 09:49:09 <donoban> only shows "performance powerasve"
2021-08-08 09:49:39 <mps> look full path above
2021-08-08 09:50:07 <donoban> localhost# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
2021-08-08 09:50:09 <donoban> performance powersave
2021-08-08 09:51:33 <mps> hmm, strange, in my case it shows all loaded (and built-in) governors
2021-08-08 09:51:47 <mps> conservative performance schedutil
2021-08-08 09:52:13 <donoban> maybe is some specific hardware problem
2021-08-08 09:53:01 <donoban> but theorically the governor is abstracted from it, right?
2021-08-08 09:53:06 <mps> hardware shouldn't 'disable' conservative governor
2021-08-08 09:53:10 <donoban> is the driver who interacts with low level 
2021-08-08 09:53:14 <donoban> yep
2021-08-08 09:54:01 <donoban> I'm gonna reboot to linux-ege
2021-08-08 09:54:05 <donoban> edge*
2021-08-08 09:57:28 <donoban> [donoban@localhost][~]% cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
2021-08-08 09:57:30 <donoban> performance
2021-08-08 09:57:32 <donoban> :D
2021-08-08 09:57:40 <donoban> same problem here mps 
2021-08-08 09:57:45 <donoban> [donoban@localhost][~]% cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
2021-08-08 09:57:47 <donoban> performance powersave
2021-08-08 09:57:56 <mps> uname -a
2021-08-08 09:58:09 <donoban> [donoban@localhost][~]% cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
2021-08-08 09:58:11 <donoban> performance powersave
2021-08-08 09:58:13 <donoban> ups sorry
2021-08-08 09:58:17 <donoban> Linux localhost 5.13.8-0-edge #1-Alpine SMP PREEMPT Wed, 04 Aug 2021 16:19:43 +0000 x86_64 Linux
2021-08-08 09:58:44 <mps> cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
2021-08-08 09:58:48 <donoban> so maybe I'm running my laptop on powersave for weeks
2021-08-08 09:58:57 <donoban> and then switched to performacne lol
2021-08-08 09:59:13 <donoban> [donoban@localhost][~]% cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
2021-08-08 09:59:15 <donoban> performance powersave
2021-08-08 09:59:31 <donoban> it seems that on lts it defaults to powersave because it can't load schedutil
2021-08-08 09:59:43 <mps> on my laptop which works as server: 5.13.5-0-edge #1-Alpine SMP PREEMPT Sun, 25 Jul 2021 14:09:48 +0000 x86_64 GNU/Linux
2021-08-08 09:59:53 <donoban> I remeber some message on the mail list about raspberry defaulting to powersave
2021-08-08 10:00:00 <donoban> maybe was there something related to this
2021-08-08 10:00:17 <mps> cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors => conservative performance schedutil
2021-08-08 10:00:46 <donoban> did you disable powersave?
2021-08-08 10:00:54 <mps> and, echo conservative > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
2021-08-08 10:01:19 <donoban> I'm gonna search that mail
2021-08-08 10:01:22 <mps> no, just didn't loaded driver
2021-08-08 10:02:03 <mps> now when driver is loaded: cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors => powersave conservative performance schedutil
2021-08-08 10:02:30 <donoban> yes I thought that powersave was builtin
2021-08-08 10:11:07 <donoban> uhM
2021-08-08 10:11:41 <donoban> "The intel_pstate drive does not have ondemand mode, but its powersave mode should be the equivalent of the acpi_cpufreq ondemand mode."
2021-08-08 10:11:54 <donoban> any thought on this?
2021-08-08 10:14:16 <donoban> lol
2021-08-08 10:14:33 <donoban> yeah, running powersave governor my curr_freq varies
2021-08-08 11:13:47 <Hello71> mps: i think s390x is alpine linux's only big-endian arch
2021-08-08 11:13:55 <Hello71> and this looks like could be endianness/aliasing issue
2021-08-08 11:14:34 <Hello71> arm has big-endian but i'm pretty sure alpine doesn't use it
2021-08-08 11:15:02 <ikke> mips64 is also big-endian
2021-08-08 11:16:32 <Hello71> hm, i wasn't sure about that one
2021-08-08 11:16:58 <ikke> That was the reason for the port, big-endian means less conversion for network applications
2021-08-08 11:17:46 <Hello71> ah, yes, i vaguely remember this
2021-08-08 11:18:18 <Hello71> not sure why then, looking at code
2021-08-08 13:28:24 <Ariadne> ikke: there are also some advantages for multimedia processing, but modern codecs assume little-endian world
2021-08-08 13:29:20 <Ariadne> although i would like our ppc64 port to target the G5 mac, i think the best way to do that is to write a bootloader to switch the system into little endian mode
2021-08-08 15:01:29 <Hello71> can someone move https://gitlab.alpinelinux.org/alpine/aports/-/issues/12338 to alpine-conf?
2021-08-08 15:02:40 <ikke> done
2021-08-08 15:06:53 <Hello71> thanks
2021-08-08 15:08:03 <Jenkler> ncopa, why do we not have any newer openjdk-jre on 3.14 
2021-08-08 15:08:32 <Jenkler> ncopa, is 16 in edge unsable?
2021-08-08 15:09:06 <ikke> Jenkler: you can better ask bratkartoffel 
2021-08-08 15:09:58 <Jenkler> bratkartoffel, is it possible to push openjdk 16 to 3.14
2021-08-08 15:10:20 <ikke> No
2021-08-08 15:10:31 <ikke> generally not
2021-08-08 15:10:35 <ikke> 3.14 is already released
2021-08-08 15:10:54 <Jenkler> ikke, ok, but 11 is old as s**t
2021-08-08 15:11:01 <Ariadne> too bad
2021-08-08 15:12:57 <Jenkler> ahhh, its only in testing 
2021-08-08 15:26:07 <Jenkler> ikke, if something is in testing. Is it hard to get it into edge ?
2021-08-08 15:26:21 <ikke> testing _is_ in edge
2021-08-08 15:26:31 <ikke> but you want to move it from testing to community
2021-08-08 15:26:51 <ikke> Jenkler: if you are on edge, you just need to enable the testing repository
2021-08-08 15:27:20 <Sheila> Jenkler: generally promotion to community requires an active maintainer.
2021-08-08 15:34:56 <Hello71> considering openjdk 17 is out in like a month i doubt there is appetite for pushing unstable release
2021-08-08 15:35:40 <Jenkler> so we dont have any maintainer for openjdk anymore?
2021-08-08 15:36:36 <ikke> bratkartoffel is maintaining it
2021-08-08 15:36:40 <Jenkler> Hello71, indeed better to fix openjdk 17
2021-08-08 15:37:04 <Hello71> didn't we just discuss this issue like a week ago
2021-08-08 15:37:08 <Hello71> wait, no, that was nodejs
2021-08-08 15:37:13 <Jenkler> minecraft 1.17.x needs java 16. I guess a few people play this game ;)
2021-08-08 15:37:25 <Hello71> use edge
2021-08-08 15:37:43 <Hello71> non lts openjdk is only supported for 6 months
2021-08-08 15:38:13 <Jenkler> I do not want to run edge on and production server 
2021-08-08 15:38:27 <ikke> You probably do not run minecraft on one either
2021-08-08 15:38:38 <Jenkler> ikke, yes, gameservers 
2021-08-08 15:38:51 <Jenkler> there are production game server you know :P
2021-08-08 15:39:24 <Jenkler> I guss there ar other usecases for java :P
2021-08-08 15:39:29 <Jenkler> *guess 
2021-08-08 15:40:35 <Jenkler> Until than 1.16.5 is the latest MC that kan be run, for those who care ;)
2021-08-08 15:41:57 <Ariadne> Jenkler: in a modern production server, you should be using containers for your production services
2021-08-08 15:42:09 <Ariadne> Jenkler: so a minecraft container on edge would be harmless
2021-08-08 15:42:59 <Jenkler> Ariadne, I know ;) But it is not even in edge yet. Only testing 
2021-08-08 15:43:05 <Hello71> you are already using "edge openjdk"
2021-08-08 15:43:28 <Jenkler> Hello71, no i use openjdk from 3.14
2021-08-08 15:43:40 <Ariadne> well, then you will have to live with LTS openjdk
2021-08-08 15:43:40 <Hello71> 
ACTION bails

2021-08-08 15:44:00 <Ariadne> because non-LTS openjdk is not what the maintainer wants in community, it seems
2021-08-08 15:44:21 <Jenkler> Ariadne, ahh 
2021-08-08 15:44:43 <ikke> Jenkler: "But it is not even in edge yet. Only testing"
2021-08-08 15:44:48 <ikke> that makes no sense at all
2021-08-08 15:44:58 <Ariadne> (and non-LTS openjdk is something the security team would not be happy about having to support for that matter)
2021-08-08 15:45:15 <Ariadne> have you ever tried to patch java?
2021-08-08 15:45:17 <Ariadne> it's fun!
2021-08-08 15:45:23 <Ariadne> and by fun i mean i never want to do it again
2021-08-08 15:45:30 <ikke> Jenkler: It _is_ in edge
2021-08-08 15:46:31 <Jenkler> ikke, testing does only exist for edge right?
2021-08-08 15:46:41 <Jenkler> I have newer used it ;)
2021-08-08 15:46:50 <ikke> exactly
2021-08-08 15:46:58 <Jenkler> ikke, my bad :P
2021-08-08 15:47:30 <Jenkler> so we need to wait for LTS of java 16+ then ;)
2021-08-08 15:48:55 <Jenkler> Nice page for people that play minecraft and want to test diffrent versions : https://mcversions.net/
2021-08-08 15:51:21 <Jenkler> Ariadne, i am stuck with Java. Java MC is better than bedrock version :) 
2021-08-08 16:00:39 <fsociety> Someone here?
2021-08-08 16:03:04 <Hello71> no
2021-08-08 16:15:07 <fsociety> Heyz?
2021-08-08 16:16:48 <ikke> If you want to ask something, just ask it
2021-08-08 17:43:37 <Hello71> ikke: can you make https://gitlab.alpinelinux.org/fijam/aports public
2021-08-08 17:43:56 <ikke> hmm, that should be done automatically
2021-08-08 17:44:20 <Hello71> *shrug*
2021-08-08 17:44:30 <Hello71> https://gitlab.alpinelinux.org/fijam/aports/-/merge_requests/1
2021-08-08 17:44:54 <Ariadne> look at it
2021-08-08 17:44:58 <Ariadne> its in his own namespace
2021-08-08 17:45:01 <Ariadne> not on the aports one
2021-08-08 17:46:43 <Hello71> yes, because repo was not public
2021-08-08 17:48:51 <ikke> Temporary issue apparerntly
2021-08-08 17:49:00 <ikke> Project is now public
2021-08-08 18:56:52 <Hello71> i was looking at #12830, and wondering... since we don't want to automagically run setup-udev, should we instead prefer libudev-zero for runtime dependency?
2021-08-08 18:57:41 <Hello71> and if we still want to build against eudev-dev, is it possible to encode "build against eudev-dev or libudev-zero-dev, but prefer eudev-dev, and run against eudev-libs or libudev-zero-libs, but prefer libudev-zero-libs" in apk
2021-08-08 18:58:10 <Hello71> i'm a little wary of building against libudev-zero-dev and running against eudev-libs
2021-08-09 03:56:14 <craftyguy> where does abuild rootbld place the build root?
2021-08-09 04:10:40 <veiviser> looks like a /var/tmp/abuild.xxxxxx mktemp dir
2021-08-09 04:12:17 <veiviser> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2382
2021-08-09 05:05:21 <craftyguy> ah thanks!
2021-08-09 06:32:56 <mps> 483357d8b28bb675f20a812e92b6fdeb486258c9
2021-08-09 06:33:12 <mps> 26fbb6dbfd96420c86fe50f54de86e9fb7d52951
2021-08-09 06:33:57 <mps> rnalrd: good morning
2021-08-09 06:34:48 <mps> rnalrd: are there errors in above two commits or you made last one for reason
2021-08-09 06:37:05 <mps> 483357d8b28bb675f20a812e92b6fdeb486258c9 is actually downgrade to 1.68 from 1.70
2021-08-09 06:40:05 <rnalrd> mps sorry I blindly did abump after receiving Anitya notification, let me revert that
2021-08-09 06:40:37 <mps> rnalrd: np, just wanted to inform you about state
2021-08-09 06:41:07 <rnalrd> thanks for the heads up :)
2021-08-09 06:41:33 <mps> you are welcome
2021-08-09 06:41:58 <mps> nice that we can fix such mistakes so fast. thanks
2021-08-09 06:48:07 <clandmeter> seems jirutka has been busy: https://twitter.com/JakubJirutka/status/1424481022364762115
2021-08-09 06:49:50 <mps> and would be nice if he is here again
2021-08-09 07:12:38 <ncopa> good morning
2021-08-09 07:14:28 <mps> good morning
2021-08-09 07:41:43 <bratkartoffel> ikke: just read the scrollback. fyi I plan to move openjdk9-17 to community as soon as openjdk17 is out
2021-08-09 07:48:17 <ikke> bratkartoffel: 👍
2021-08-09 10:20:29 <nmeum> PureTryOut: is there any specific reason why nlohmann-json doesn't have a -dev subpackage? 🤔
2021-08-09 10:20:33 <nmeum> ah, it's a header-only library?
2021-08-09 10:20:42 <PureTryOut> Yes
2021-08-09 10:22:28 <nmeum> unfourtunate, probably also means that we have to rebuild packages if upstream fixes a bug/security issue
2021-08-09 10:24:18 <PureTryOut> Why is that unfortunate?
2021-08-09 10:28:28 <nmeum> because normally software would link dynamically against libraries and as long as the ABI doesn't change we don't need to rebuild software using a library if the library's upstream fixes a bug/security issue but if everything is defined in a header file this code get's included directly in the software's binary thereby requiring rebuilds on bugs in the library
2021-08-09 10:28:41 <nmeum> or am i missing something here?
2021-08-09 10:30:13 <veiviser> sounds correct to me, same as the go packages that have to get rebuilt with new go versions
2021-08-09 12:57:14 <Hello71> it's much faster though
2021-08-09 12:57:30 <Hello71> which reminds me, we should try -fno-plt at some point
2021-08-09 13:02:55 <nmeum> why would it be faster?
2021-08-09 13:03:00 <nmeum> I suppose without -fno-lto it makes some optimization easier (more stuff is in the same compilation unit etc.)
2021-08-09 13:03:06 <nmeum> *without LTO
2021-08-09 13:15:37 <unrznbl[m]> Hello. How can I help get this merge request for upgrading cfengine merged? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22990 I see there are 310 MRs currently open so sorry for the noise. That's a lot of work. :)
2021-08-09 13:37:33 <Hello71> nmeum: inlining lots of short access functions, plus no plt overhead
2021-08-09 13:37:44 <Hello71> (see: -fno-semantic-interposition)
2021-08-09 13:55:56 <unrznbl[m]> ikke: thanks for the update on my cfengine MR
2021-08-09 15:20:01 <knuxify> could someone take a look at !23625?
2021-08-09 15:36:40 <PureTryOut> e8: when you upgraded gpsd you forgot to rebuild the packages depending on it
2021-08-09 15:37:00 <maxice8> ok
2021-08-09 15:40:24 <maxice8> thanks for taking care of it
2021-08-09 15:43:21 <PureTryOut> No problem. Got a report of a pmOS issue that couldn't install KDE Plasma because of it
2021-08-09 15:43:30 <PureTryOut> *pmOS uer
2021-08-09 15:43:32 <PureTryOut> *user, wtf
2021-08-09 15:50:19 <Ariadne> the gpsd needs to be backported, too
2021-08-09 15:50:22 <Ariadne> i'll work on it today
2021-08-09 16:06:22 <PureTryOut> 👍️
2021-08-09 16:15:08 <craftyguy> should tools installed by util-linux 'replace' counterparts in busybox?
2021-08-09 16:16:33 <minimal> craftyguy: are you asking if they do replace them or if they *should* replace them? They do replace them
2021-08-09 16:16:52 <craftyguy> I said "should"
2021-08-09 16:17:01 <craftyguy> because, they do not replace all of them
2021-08-09 16:17:12 <PureTryOut> They only replace what util-linux provides
2021-08-09 16:17:14 <Ariadne> huh?
2021-08-09 16:17:18 <PureTryOut> Not everything in Busybox is provided by util-linux
2021-08-09 16:17:18 <craftyguy> e.g., util-linux-misc installs rev @ /usr/bin/rev, but busybox's rev is @ /bin/rev
2021-08-09 16:17:21 <Ariadne> maxice8: why was gpsd moved to community ?
2021-08-09 16:18:02 <Ariadne> craftyguy: that sounds like a bug
2021-08-09 16:18:05 <craftyguy> PureTryOut: yeah I understand that. I meant "should util-linux replace things it provides that are also provided by busybox"
2021-08-09 16:18:18 <craftyguy> Ariadne: ok, I can make a patch then
2021-08-09 16:18:22 <minimal> crafyguy: various of the Busybox tools are replaced by util-linux subpackages as well as coreutils and other packages
2021-08-09 16:18:30 <PureTryOut> Yeah sorry your last message after my last message clarified that 😅
2021-08-09 16:18:50 <craftyguy> minimal: right, so I was surprised that rev wasn't being replaced. and wanted to confirm that my assumption, that it should have been replaced, was correct :)
2021-08-09 16:19:01 <Ariadne> maxice8: gpsd needs to be in main because people use it as a reliable clocksource for their ntp servers
2021-08-09 16:19:41 <Ariadne> ugh
2021-08-09 16:20:25 <maxice8> Ariadne: please add a comment
2021-08-09 16:22:03 <Ariadne> ?????
2021-08-09 16:22:17 <Ariadne> add a comment where, why?
2021-08-09 16:23:38 <Ariadne> i think we need a better process for determining what gets moved to community
2021-08-09 16:23:54 <Ariadne> adding a comment 'fixes' it in this case, but what about next time?
2021-08-09 16:23:55 <minimal> craftyguy: to fix that involves either an MR to busybox to fix the "//applet" line in util-linux/rev.c or else an MR to fix where util-linux puts rev - not sure which of busybox and util-linux is considered authoritative regarding the "right" directory
2021-08-09 16:24:17 <craftyguy> minimal: yeah I was just considering how it'd be fixes
2021-08-09 16:24:21 <craftyguy> s/fixes/fixed/
2021-08-09 16:24:46 <minimal> well first question is which is correct about location, busybox or util-linux?
2021-08-09 16:25:48 <craftyguy> at this point in time, isn't the difference between /bin and /usr/bin somewhat arbitrary?
2021-08-09 16:26:15 <minimal> well as you've observed with "rev" not quite :-)
2021-08-09 16:26:28 <craftyguy> well, ignoring ordering in PATH
2021-08-09 16:26:33 <craftyguy> I meant "what belongs where"
2021-08-09 16:26:47 <Ariadne> 
ACTION mutters

2021-08-09 16:27:06 <craftyguy> looking at where each installs things, they're both fairly dug into preferring one or the other. which supports my "it's arbitrary" conclusion :P
2021-08-09 16:27:14 <minimal> I've guess as busybox implements small "replacements" for util-linux/coreutils/etc tools then it should place the softlink where the other package puts its binary
2021-08-09 16:27:30 <craftyguy> that's a very good point
2021-08-09 16:28:20 <mps> where busybox 'thinks'
2021-08-09 16:28:22 <Ariadne> maxice8: i have requested the TSC define a process for moving things from main to community, so that we do not have these issues in the future
2021-08-09 16:28:23 <minimal> if you look at the busybox aport, there's a patch there to fix nologin location so a similar patch for rev makes sense
2021-08-09 16:29:22 <craftyguy> minimal: ah I hadn't noticed that patch for nologin. I just have been looking at the apkbuild and busybox source :P
2021-08-09 16:29:53 <craftyguy> but what you said makes sense, that BB should replace the things it sets out to replace
2021-08-09 16:30:10 <Hello71> isn't the /bin /usr/bin thing because of busybox.trigger
2021-08-09 16:31:07 <minimal> "busybox --install -s" is run to set up the softlinks but the locations used are defined by each applet in busybox's source code
2021-08-09 16:31:26 <craftyguy> right
2021-08-09 16:31:39 <craftyguy> that's why I was looking at the BB shource
2021-08-09 16:31:41 <craftyguy> *source
2021-08-09 16:31:45 <craftyguy> Hello71: what do you mean?
2021-08-09 16:32:05 <Hello71> hm
2021-08-09 16:32:39 <Hello71> never mind, my mistake
2021-08-09 16:32:47 <minimal> both busybox.post-install and busybox.trigger run the "busybox --install -s" command
2021-08-09 16:35:56 <Hello71> yeah, for some reason i thought busybox commands were in / and coreutils/util-linux were in /usr
2021-08-09 16:36:15 <Hello71> it might happen that some are that way but it's not intentional
2021-08-09 16:36:53 <minimal> yeah in theory the idea is to replace the busybox softlink when the "full" version of the utility is installed rather than reply on PATH order as to which is found
2021-08-09 16:37:35 <minimal> The idea is if you *really* want to use the busybox version you can still run "busybox rev <options>"
2021-08-09 16:52:06 <Hello71> yeah
2021-08-09 18:45:14 <Hello71> maxice8: arch="all" # fails to build? https://gitlab.alpinelinux.org/alpine/aports/commit/f8af2233838bccdbb4eb108910d0ea5804dda0e1
2021-08-09 18:45:19 <Hello71> does not compute
2021-08-09 18:45:40 <ikke> forgot to remove the comment
2021-08-09 23:44:39 <Hello71> ncopa, dalias: -fomit-frame-pointer was made the default in 2017: https://github.com/gcc-mirror/gcc/commit/8e941ae950ddce1745b4d6819a7131908dd7de24. it was then made un-default for aarch64 three months later: https://github.com/gcc-mirror/gcc/commit/efeee67f4c9fd021d2594e0271c84b7e90e63d3d
2021-08-10 00:02:43 <dalias> hello71, is that accurate? the description of the latter just says they unified it rather than making it per-arch
2021-08-10 00:08:17 <Hello71> oops, I pasted the wrong links
2021-08-10 00:10:56 <Hello71> https://github.com/gcc-mirror/gcc/blob/master/gcc/common/config/aarch64/aarch64-common.c#L53
2021-08-10 00:11:44 <Hello71> you can search for OPT_fomit_frame_pointer, it's only aarch64
2021-08-10 01:54:15 <Ariadne> weird
2021-08-10 01:54:44 <Hello71> https://github.com/gcc-mirror/gcc/commit/af3b4514fcb92b6275ed52e47bb0dd8146f7e304
2021-08-10 01:55:04 <Hello71> something something "this is an aarch64 abi guarantee"
2021-08-10 08:36:04 <xsteadfastx> i try to update the apk for community/broot and i step into some rust problems.... im no rust developer but im trying to figure it out. broot looks like to use a rust experimental feature called "or-patterns". any idea how i can deal with that?
2021-08-10 08:36:43 <ikke> ugh, so they are using rust nightly I suppose?
2021-08-10 08:36:52 <ikke> Not sure if there is anything to do about that except patching it out
2021-08-10 08:37:24 <xsteadfastx> oh ok... so i think i cant do that :)
2021-08-10 08:37:35 <ikke> me neither
2021-08-10 08:42:44 <mps> is the our riscv64 big or little endian?
2021-08-10 08:43:15 <mps> related to https://dovecot.org/pipermail/dovecot/2021-August/122787.html
2021-08-10 08:51:37 <ikke> little-endian according to https://en.wikipedia.org/wiki/RISC-V
2021-08-10 08:52:50 <mps> yes, I'm sure but was surprised with answer in above url, wondering did the OpenSUSE 'made' it big-endian
2021-08-10 10:18:30 <Habbie> mps, it's more likely Timo guessed wrong
2021-08-10 10:20:26 <mps> Habbie: Timo cmouse?
2021-08-10 10:20:35 <Habbie> cmouse and Timo are coworkers
2021-08-10 10:20:37 <Habbie> they are not the same person
2021-08-10 10:20:44 <Habbie> as much as their names may look alike to a foreigner ;)
2021-08-10 10:21:28 <mps> Habbie: wait, https://dovecot.org/pipermail/dovecot/2021-August/122793.html
2021-08-10 10:21:51 <Habbie> oh s390x
2021-08-10 10:21:53 <Habbie> makes more sense
2021-08-10 10:22:00 <mps> and cmouse wrote 'mps: there is now a patch for you to try in your email =)'
2021-08-10 10:22:05 <Habbie> right
2021-08-10 10:22:19 <mps> so cmouse is Aki?
2021-08-10 10:22:28 <Habbie> correct
2021-08-10 10:23:29 <mps> hmm, that is what I always thought but last cmouse comment made me puzzled
2021-08-10 10:25:36 <mps> '/whois cmouse' explains
2021-08-10 10:25:50 <Habbie> the comment about the patch?
2021-08-10 10:26:39 <mps> yes
2021-08-10 10:27:03 <Habbie> ack
2021-08-10 10:27:06 <Habbie> timo doesn't IRC much
2021-08-10 10:27:08 <Habbie> but he does fix much :)
2021-08-10 10:27:18 <mps> but cmouse also posted one patch
2021-08-10 10:28:22 <mps> so I hope dovecot will be ready when I come back to home
2021-08-10 10:28:32 <Habbie> :)
2021-08-10 10:28:56 <mps> (if you don't drink too much on meeting :D )
2021-08-10 11:01:28 <Newbyte> could someone have a look at !23915? it's trivial and having it merged would make my phosh 0.13.0 MR easier to work with
2021-08-10 11:02:11 <ikke> Newbyte: why would this even matter?
2021-08-10 11:02:18 <ikke> Oh, mr
2021-08-10 11:03:06 <ikke> Newbyte: Would it make sense to bump the pkgrel here?
2021-08-10 11:03:07 <Newbyte> right now, I have to wait for phoc and squeekboard to compile before I can see if I fixed the CI in my phosh 0.13.0 MR
2021-08-10 11:03:25 <Newbyte> ikke this doesn't affect the final package, so I don't think so. it's just a new upstream URL
2021-08-10 11:03:42 <ikke> Newbyte: You know that this is just used for metadata?
2021-08-10 11:03:50 <ikke> Did you mean to change the source url, not the url param?
2021-08-10 11:04:03 <Newbyte> oh yes, I forgot about pkgs.alpinelinux.org
2021-08-10 11:04:10 <Newbyte> yes, then it makes sense to bump the pkgrels. I'll do that
2021-08-10 11:04:33 <ikke> But still, I'm trying to figure out how the url param matters to you?
2021-08-10 11:05:14 <Newbyte> ikke it is used for the sources too
2021-08-10 11:05:33 <Newbyte> and the old URL doesn't have phosh 0.13.0 since it's abandoned
2021-08-10 11:05:41 <ikke> no it doesn't
2021-08-10 11:05:46 <ikke> Oh
2021-08-10 11:05:50 <ikke> n/m, ignore me
2021-08-10 11:06:05 <Newbyte> but, I'll bump pkgrels so pkgs.alpinelinux.org gets updated
2021-08-10 11:06:18 <ikke> It's just very uncommon to use the URL in the source as well
2021-08-10 11:07:50 <Newbyte> Yeah, I think I've been told to not do that at some point as well. I didn't write these APKBUILDs though
2021-08-10 11:07:55 <Newbyte> Anyway, pkgrels bumped
2021-08-10 11:08:03 <ikke> 👍
2021-08-10 11:31:50 <ncopa> Hi, I’m gonna be afk rest of this week
2021-08-10 11:32:23 <ikke> Ok, enjjoy whatever you'll be doing :)
2021-08-10 11:51:43 <Hello71> PureTryOut: !23988 failed on builders :/
2021-08-10 11:52:08 <Hello71> it really does need https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54
2021-08-10 11:52:13 <PureTryOut> Yeah I saw, no clue why. It succeeded on CI and the error makes no sense to me. Also only x86_64 failed
2021-08-10 11:52:30 <Hello71> it's because the scanelf runs in parallel with the copying
2021-08-10 11:52:51 <Hello71> and splitdebug files are valid ELF DSOs (sort of)
2021-08-10 11:53:17 <Hello71> it's unrelated to the arch, and triggers depending on disk speed, cpu speed, scheduler, etc
2021-08-10 11:55:34 <Hello71> :( 11:31 <@ncopa> Hi, I’m gonna be afk rest of this week
2021-08-10 11:56:03 <Hello71> do we have anyone else who can review and merge abuild!54?
2021-08-10 11:56:07 <Hello71> algitbot: no.
2021-08-10 11:56:20 <ikke> Technically, yes
2021-08-10 12:05:32 <ikke> 1
2021-08-10 12:13:43 <PureTryOut> Hello71: interesting that it's just the x86_64 machine that triggers it multiple times though
2021-08-10 12:15:35 <Hello71> i mean, knowing the cause, not that much
2021-08-10 12:27:06 <PureTryOut> Uh, ok. So, how to fix it?
2021-08-10 12:45:00 <Hello71> merge https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54 or revert https://gitlab.alpinelinux.org/alpine/aports/merge_requests/23988
2021-08-10 12:45:26 <Hello71> or, i guess, as a hacky solution, buffer scanelf in a file. should be lower risk but i don't want to make another patch
2021-08-10 12:45:58 <Hello71> the reason why it affects qt and not other packages is because qt is too fat, so the objcopy takes a long time, more window for scanelf to accidentally detect it
2021-08-10 12:46:34 <Hello71> also qt has a large number of files; it is less likely to happen if the whole list of files fits in pipe buffer
2021-08-10 12:46:50 <mps_> ncopa: I'm working on fixes for dovecot and hope to merge it today. sorry if something go wrong. enjoy your 'afk'
2021-08-10 15:43:12 <Ariadne> >>> ERROR: qt5-qtbase-dbg*: dbg failed
2021-08-10 15:43:21 <Ariadne> hmmph
2021-08-10 15:43:50 <ikke> Ariadne: 
2021-08-10 15:43:53 <ikke> README ¶
2021-08-10 15:43:55 <ikke> Testify - Thou Shalt Write Tests
2021-08-10 15:43:57 <ikke> ℹ️arg
2021-08-10 15:44:13 <Ariadne> haha
2021-08-10 15:44:13 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54
2021-08-10 15:44:39 <Ariadne> ahh yes
2021-08-10 15:44:44 <Ariadne> waiting on ncopa :)
2021-08-10 15:44:56 <ikke> I could try to build it with less threads
2021-08-10 15:45:05 <ikke> not sure if that matters
2021-08-10 15:45:24 <ikke> I guess it does not
2021-08-10 15:46:26 <Hello71> no
2021-08-10 15:47:30 <Hello71> i thought about it
2021-08-10 16:19:52 <ikke> fun, rust is blocking CI
2021-08-10 16:40:33 <mps> Habbie: you are right, Timos patch didn't solved issue with dovecot on s390x
2021-08-10 16:53:27 <Habbie> oh i made no claims about the quality of any patch
2021-08-10 17:02:55 <mps> sorry, then I misunderstood you
2021-08-10 17:09:39 <Thermi> For some packages (those that execute executables built at buildtime), cross compiling using the existing env vars (CFLAGS, LDFLAGS, ...) isn't possible because they contain --sysroot, which breaks them. They then segfault when run on the host at buildtime (because it's part of the build process). So we need new vars that are contain the original CFLAGS and so on.
2021-08-10 17:09:48 <Thermi> I did that in a small patch I will upload soon in an MR
2021-08-10 17:11:46 <Thermi> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/112
2021-08-10 17:12:17 <Thermi> The new vars are necessary to be able to take the CFLAGS into account for those new variables, without having to override any additional flags necessary for cross compiling.
2021-08-10 17:13:28 <Thermi> (e.g. function.sh in abuild adds --sysroot X. It'd need to be overridden with --sysroot /, I guess, but that's ugly because it needs to be done for any flag, and can't be done automatically without additional logic in the APKBUILD, also it can't know the original value of the flag)
2021-08-10 17:14:04 <Thermi> Please tell me what you think
2021-08-10 17:15:01 <Thermi> With the MR, maintainers of packages that need to run binaries built at buildtime of the package can just patch the Makefile of the required parts of the software and use $(HOSTCC) $(CBUILDFLAGS) (for example) 
2021-08-10 17:15:24 <Thermi> $(HOSTCC) because the Makefile of iproute2/netem uses that for the compiler
2021-08-10 17:19:33 <Ariadne> uhhhh
2021-08-10 17:27:49 <Thermi> Btw, libssh2 doesn't cross compile for me because it doesn't find any crypto backends although openssl-dev is installed. How did you fix that?
2021-08-10 17:33:58 <afontain[m]> It's probably a good idea to tell how you are trying to cross-compile
2021-08-10 17:46:35 <Thermi> using bootstrap.sh of course.
2021-08-10 18:07:06 <Ariadne> Thermi: it didn't come up last time i ran bootstrap.,sh
2021-08-10 18:12:01 <Ariadne> PureTryOut: can we revert !23988
2021-08-10 18:12:33 <PureTryOut> I guess, it's annoying that it only happens on x86_64 and isn't reproducable locally or on CI though
2021-08-10 18:22:35 <PureTryOut> Preferably https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54 gets merged instead 😅
2021-08-10 18:23:02 <Ariadne> yes, i agree, but blocking the builders is not tenable until it does
2021-08-10 18:24:59 <Ariadne> and with ncopa being afk for this week,
2021-08-10 18:25:12 <Ariadne> i don't think abuild!54 is going to be merged in a reasonable time
2021-08-10 18:25:35 <Ariadne> perhaps the MR regexp should be less greedy
2021-08-10 18:25:46 <Ariadne> \w!\d+
2021-08-10 18:25:49 <Ariadne> instead of !\d+
2021-08-10 18:28:41 <PureTryOut> Instead it should link to the abuild repository
2021-08-10 18:28:58 <PureTryOut> We have it like that on pmOS. pma!<whatever> links to pmaports, pmb!<whatever> links to pmbootstrap, etc
2021-08-10 18:31:50 <Ariadne> well regardless the current behavior is not very useful :P
2021-08-10 18:59:11 <Hello71> i am ok with reverting
2021-08-10 18:59:47 <Ariadne> i already did it
2021-08-10 18:59:53 <Ariadne> we can revisit when -dbg is safer
2021-08-10 19:01:29 <Hello71> ok
2021-08-10 19:02:20 <ikke> rust on armhf is 🤔
2021-08-10 19:19:29 <Thermi> Ariadne, lucky you. It crashes here, unless I apply the changes. And the changes make sense, I'm afraid.
2021-08-10 19:20:02 <Thermi> After all, compiling maketable with the cross compiler and setting sysroot is the same as cross compiling and thus the binary is not supposed to work on the host.
2021-08-10 19:20:38 <Thermi> ( 1) wrong binary format 2) invalid instructions )
2021-08-10 20:19:30 <Ariadne> Thermi: it occured to me that i do have qemu-openrc service running.
2021-08-10 20:19:41 <Ariadne> erm, qemu-binfmt service
2021-08-10 20:20:12 <Thermi> Yes.
2021-08-10 20:20:44 <Thermi> I had the same problem until it occured to me.
2021-08-10 20:22:04 <ikke> oof, CI is suddenly borked
2021-08-10 20:22:10 <ikke> it hangs on installing packages
2021-08-10 20:24:18 <ikke> connection to dl-cdn seems to be slow
2021-08-10 20:27:02 <ikke> oof, 200ms latency to dl-cdn
2021-08-10 20:28:26 <Thermi> local transparent proxy is not a solution?
2021-08-10 20:28:53 <Thermi> Well, caching proxy in that case
2021-08-10 20:33:48 <ikke> normally dl-cdn handles it fine, just seems to having an issue atm
2021-08-10 20:34:16 <ikke> at least, from some locations
2021-08-10 20:34:24 <ikke> locally it works fine
2021-08-10 20:35:10 <Thermi> Yeah, the Internet works until it doesn't. Wasn't it supposed to be redundant?  Nevermind.
2021-08-10 20:36:19 <ikke> The cloud is just someone else's computer
2021-08-10 20:36:23 <Thermi> Yes.
2021-08-10 20:36:49 <Thermi> Could we concievably have a CI job that runs bootstrap?
2021-08-10 20:37:39 <ikke> I suppose we could have a scheduled job that would do that
2021-08-10 20:37:39 <Hello71> when would it run
2021-08-10 20:37:51 <ikke> once a week or so?
2021-08-10 20:38:14 <Thermi> Like the normal builders. But there'd be a repo that holds the already built packets so it'd only build when changes were made. Just like the normal CI.
2021-08-10 20:38:23 <Thermi> *Just like the normal CI job.
2021-08-10 20:39:14 <Thermi> Obviously the repo needs to be filled up manually first, because bootstrap.sh takes a long time to build all the necessary packets.
2021-08-10 20:39:45 <Thermi> Alternatively, we could try to cross compile and fix all the packets and then just try to cross compile that packet.
2021-08-10 20:40:28 <Thermi> *and then just try to cross compile the changed packages, like the existing CI jobs.
2021-08-10 20:41:21 <Thermi> We'd only need the cross compilers and musl (and so on what bootstrap.sh builds first) in the beginning
2021-08-10 20:41:28 <Thermi> The rest could be filled up basically on the fly
2021-08-10 20:42:49 <ikke> WHy is it necessary to retain a repo?
2021-08-10 20:43:39 <Thermi> We at the very least need the basic cross compiler for the CBUILD to CHOST
2021-08-10 20:44:02 <Thermi> That's currently at least a two step process that takes time. You don't want to build that every time.
2021-08-10 20:44:37 <Thermi> Alternatively we just put all sort of cross compilers into the repos. Then we could just pull dependencies from aports like ususally.
2021-08-10 20:45:55 <ikke> note that, historically at least, we did not focus on providing general cross-compiling
2021-08-10 20:46:05 <Thermi> Yes.
2021-08-10 20:56:46 <Ariadne> NAK: re bootstrap.sh CI
2021-08-10 20:57:42 <Ariadne> unless it comes with resources to maintain bootstrap.sh that aren't me and fabled, i do not need some CI thing nagging us
2021-08-10 20:58:20 <Ariadne> because that is 100% how it is going to go
2021-08-10 20:58:28 <ikke> and to be honest, we generally do not have CI resources to spare for large jobs
2021-08-10 20:58:49 <Thermi> What would be a large job?
2021-08-10 20:59:06 <Ariadne> i am fundamentally against this
2021-08-10 20:59:28 <Thermi> Ariadne, conditionally?
2021-08-10 20:59:44 <Ariadne> i think it is important to respect the wishes of the people who actually maintain bootstrap.sh here
2021-08-10 20:59:55 <Ariadne> if you do not like its current maintenance, please volunteer to improve it
2021-08-10 21:00:09 <Thermi> I recently made at least one MR that I remember for bootstrap.sh
2021-08-10 21:00:10 <Ariadne> BEFORE proposing implementing a system that will just annoy the maintainers
2021-08-10 21:00:52 <Thermi> And that is for missing dependencies when you initially set up the system. Meaning, if your available $CHOST repos don't have the dependencies for the packages in PKG_LIST
2021-08-10 21:01:12 <Thermi> Sorry, for packages in the list in the for loop
2021-08-10 21:01:13 <Ariadne> bbl
2021-08-10 21:01:16 <Thermi> aye
2021-08-10 22:32:36 <Ariadne> Thermi: so, i'm okay with CI for bootstrap if there's more people working on it
2021-08-10 22:32:46 <Ariadne> that's the key thing though
2021-08-10 22:33:00 <Ariadne> if it winds up being automated nagging vs manual nagging, it's just going to annoy the people who maintain it
2021-08-10 22:34:41 <Thermi> Well, the nagging would be that people need to put their dependencies in the right vars
2021-08-10 22:34:52 <Thermi> We could make it like the linter
2021-08-10 22:34:57 <Thermi> soft-fail.
2021-08-10 23:00:21 <craftyguy> does abuild do anything special when building go packages?
2021-08-10 23:02:00 <craftyguy> I see a difference in the binary produced between running 'go build' in an APKBUILD vs running it manually
2021-08-10 23:03:33 <craftyguy> the binary from abuild/APKBUILD is "dynamically linked, interpreter /lib/ld-musl-x86_64.so.1", while doing the exact same thing manually (go build...) results in "statically linked"
2021-08-10 23:05:15 <craftyguy> grepping abuild's source, I don't see anything that stands out. hmm
2021-08-10 23:13:28 <Hello71> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.conf#L5
2021-08-10 23:17:33 <craftyguy> ah
2021-08-10 23:18:52 <craftyguy> that explains it. thanks
2021-08-10 23:53:56 <Ariadne> btw synapse tests are failing on builders
2021-08-11 00:07:29 <craftyguy> huh, go can't find the right dynamic linker thing on musl when cross compiling and using -buildmode=pie (which makes a dynamically linked exe)
2021-08-11 00:08:04 <craftyguy> GOARCH=arm64, "interpreter /lib/ld-musl-x86_64.so.1". oops.
2021-08-11 00:24:32 <ericonr-> craftyguy: I've seen it use glibc's ld-linux too :D
2021-08-11 00:24:42 <craftyguy> haha
2021-08-11 05:38:34 <fabled> Huh. My Alpine desktop stopped working after yesterday's updates. WLAN not getting IP, and LXDM freezes with kernel oops after login
2021-08-11 05:39:52 <ikke> fabled: so kernel upgrade?
2021-08-11 05:40:26 <fabled> I think so
2021-08-11 05:40:42 <ikke> edge?
2021-08-11 05:43:49 <fabled> Yes. Okay reverting kernel back to earlier 5.10.56-0-lts fixed the LXDM hang
2021-08-11 05:44:08 <fabled> Something else is still broken with wlan
2021-08-11 05:45:48 <fabled> Perhaps recent dhcpcd update
2021-08-11 05:46:27 <fabled> Wlan associates but does not get IP
2021-08-11 05:46:29 <ikke> How I did update it
2021-08-11 05:46:33 <ikke> -How*
2021-08-11 05:47:00 <ikke> From 8.1.9 -> 9.4.0
2021-08-11 05:48:44 <fabled> Looks definitely dhcpcd issue: the logs indicate it gets an IP, but start probing and never adds it. Adding the received IP+defaultgw+dns manually makes network work again
2021-08-11 05:49:06 <fabled> Also, init.d script is somehow broken, the stop/restart fails to stop the running instance
2021-08-11 05:50:18 <ikke> I upgraded it due to this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12900
2021-08-11 05:55:53 <fabled> ok, seems something in my dhcpcd.conf was incompatible. possibly using "background" option
2021-08-11 05:57:02 <fabled> works after tweaking config
2021-08-11 05:58:14 <ikke> ah ok
2021-08-11 05:58:41 <fabled> phew. that was not fun wake up. (did the update last thing yesterday) ... and having multiple things fail
2021-08-11 05:59:56 <ikke> yeah, can imagine
2021-08-11 06:02:31 <ikke> But wonder what that lxdm freeze is with the kernel
2021-08-11 06:04:05 <ikke> Do you use AMD?
2021-08-11 06:04:30 <ikke> drm/amd/display: Fix max vstartup calculation for modes with borders
2021-08-11 06:04:35 <ikke> drm/amd/display: Fix comparison error in dcn21 DML
2021-08-11 06:50:07 <fabled> I have a full Oops now from that. It's from i915 module (Intel integrated graphics)
2021-08-11 06:50:55 <ikke> 2 commits were reverted
2021-08-11 06:51:03 <ikke> drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
2021-08-11 06:51:20 <ikke> Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-08-11 06:51:38 <ikke> https://lwn.net/Articles/865627/
2021-08-11 06:52:40 <fabled> oops: https://tpaste.us/lygn
2021-08-11 06:53:59 <ikke> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c  was changed
2021-08-11 06:54:12 <ikke> Aug 11 05:26:06 vostro kern.warn kernel: [  566.385168]  i915_gem_do_execbuffer+0x1094/0x1de0 [i915]
2021-08-11 06:54:21 <fabled> yeah. quite possibly a bad revert, or backport of revert
2021-08-11 06:56:16 <fabled> I got LXDM greeter. But once LXDM session starts, it'd crash somewhere in the loading. IIRC top toolbar was rendered, but desktop background not yet. And happened always at same spot.
2021-08-11 07:05:12 <mps> linux-edge is not upgraded yet, I didn't had time from last friday to upgrade it
2021-08-11 07:54:14 <mps> do we really need pipewire in sdl2
2021-08-11 07:54:27 <mps> *really*, I mean
2021-08-11 08:10:51 <mps> fabled: just pushed linux-edge 5.13.9 where this i915 regression should be fixed. hope it will be on mirrors in 15-30 minutes if builders are not blocked by something
2021-08-11 08:17:15 <mps> uhm, builders are blocked by synapse fail
2021-08-11 08:18:25 <mps> disable synapse test temporary?
2021-08-11 08:24:56 <ikke> and open an issue about it
2021-08-11 08:26:20 <mps> will give one hour to maxice8 to respond before this
2021-08-11 08:27:19 <mps> hope no one runs synapse in 'production' on edge
2021-08-11 08:45:19 <PureTryOut> Uh, oh oh. I have the first package downloaded from pypi that does not include a setup.py anymore...
2021-08-11 08:46:35 <PureTryOut> Oh, Arch uses python-dephell to convert non-setup.py packages to setup.py ones, maybe that would work here as well
2021-08-11 08:49:12 <xsteadfastx> there is really a python-dephell? best name ever
2021-08-11 08:57:25 <PureTryOut> Yup, definitely a fitting name
2021-08-11 09:03:56 <clandmeter> dephell is no longer maintained
2021-08-11 09:05:03 <ikke> ironically
2021-08-11 09:08:05 <PureTryOut> Yeah I noticed, not sure how else to do this though
2021-08-11 09:08:49 <ikke> 😭
2021-08-11 09:11:31 <PureTryOut> Seems it's literally just dephell, not all the dephell_* libraries it depends on 🤔
2021-08-11 09:14:50 <fcolista> i'm playing a little bit with nfs, looks that mountstats (shipped with nfs-client) does not work out of the box because uses python3
2021-08-11 09:14:58 <fcolista> and python3 is not a dependency
2021-08-11 09:15:06 <fcolista> what do you think about this? http://dpaste.com/4G9ETDVV7.txt
2021-08-11 09:16:01 <fcolista> (besides the pkgrel to be bumped)
2021-08-11 10:24:30 <riverdc> requesting review of !19978
2021-08-11 11:24:43 <xsteadfastx> what is the best workflow if i have to change a patch for a abuild? should i recreate the patch or make the change in the patch itself?
2021-08-11 15:11:03 <Ariadne> i would suggest recreating the patch
2021-08-11 16:19:56 <Thermi> I am seeing an issue with how cross compile variables are set up in functions.sh. Right now CC is not set up before HOSTCC is set from it, so it's set but empty, which breaks iproute2 cross compiling right now
2021-08-11 16:20:37 <Ariadne> i dont think iproute2 is on the list of packages crosscompiled by bootstrap.sh ^_^
2021-08-11 16:20:40 <Thermi> (Because the Makefile in iproute2/netem checks if HOSTCC is set and if it isn't, it defaults to $CC. But it is, so $HOSTCC is empty, and then the Makefile tries to execute -D_GNU_SOURCE as program, which obviously fails)
2021-08-11 16:20:57 <Thermi> It is generally a problem though, because what functions.sh does right now is _wrong_
2021-08-11 16:21:06 <Thermi> It sets HOSTCC to an empty value
2021-08-11 16:21:20 <Ariadne> i don't like where this is going :(
2021-08-11 16:21:21 <Thermi> What is a sensible default for CC? gcc?
2021-08-11 16:21:24 <Ariadne> i want to delete bootstrap.sh
2021-08-11 16:21:49 <Thermi> I'd hate that because right now part of my work relies on it
2021-08-11 16:21:57 <Thermi> as in dayjob
2021-08-11 16:22:13 <Ariadne> cross-compilation in aports is intentionally a bad experience
2021-08-11 16:22:19 <Ariadne> we do not want people doing it really
2021-08-11 16:22:24 <Thermi> I'd hate that
2021-08-11 16:22:32 <Thermi> Would you accept patches?
2021-08-11 16:22:44 <Thermi> As in, I fix the stuff I find and it's not that awful anymore.
2021-08-11 16:22:47 <Ariadne> i don't want to "improve" cross-compilation experience
2021-08-11 16:23:03 <Thermi> Please at least accept patches that unbreak stuff
2021-08-11 16:23:09 <Thermi> (As in that HOSTCC fuckup)
2021-08-11 16:23:45 <Ariadne> why not just use qemu-user to cross-compile ?
2021-08-11 16:24:03 <Thermi> Because it does not always work, especially right now with me using a docker container.
2021-08-11 16:24:08 <Ariadne> CARCH=whatever `abuild rootbld`
2021-08-11 16:24:23 <Thermi> I can't set up binfmt in the docker container, AFAIK
2021-08-11 16:24:29 <Ariadne> bummer
2021-08-11 16:24:31 <ikke> Thermi: we use it for riscv
2021-08-11 16:24:33 <Thermi> At least I haven't succeeded in it
2021-08-11 16:24:40 <Thermi> Yes, necessarily
2021-08-11 16:24:47 <ikke> We build riscv64 in a docker container with qemu-user
2021-08-11 16:24:51 <Thermi> (I also want to have a riscv box some time)
2021-08-11 16:24:54 <Thermi> Great
2021-08-11 16:25:02 <ikke> (and thus binfmt)
2021-08-11 16:25:02 <Thermi> With an Alpine Linux host?
2021-08-11 16:25:05 <ikke> Yes
2021-08-11 16:25:15 <Thermi> I have Arch Linux as a host
2021-08-11 16:25:22 <Ariadne> you can't expect us to support strange use cases like this
2021-08-11 16:25:39 <Thermi> Last time I saw abuild implicitely invoke qemu-user in the container, it complained it couldn't find ld-musl*
2021-08-11 16:25:53 <ikke> We don't let abuild invoke qemu-user
2021-08-11 16:26:02 <Ariadne> we just register it in fixate mode
2021-08-11 16:26:05 <ikke> Instead, we run the docker container with qemu user
2021-08-11 16:26:31 <Thermi> How is that working=?
2021-08-11 16:26:32 <Thermi> *?
2021-08-11 16:26:49 <Ariadne> the qemu-user is pinned to an inode on disk, using fixate mode
2021-08-11 16:27:31 <Thermi> Ah, so everything below the inode is executed with qemu-user?
2021-08-11 16:28:39 <Ariadne> no
2021-08-11 16:28:52 <Ariadne> you can use this thing called binfmt
2021-08-11 16:28:56 <Thermi> I know of binfmt
2021-08-11 16:29:06 <Ariadne> to say "if the program has XYZ magic bytes, use this program as ELF interpreter"
2021-08-11 16:29:14 <ikke> https://github.com/jirutka/qemu-openrc/blob/master/qemu-binfmt.initd
2021-08-11 16:29:14 <Ariadne> so, we use qemu-user as ELF interpreter
2021-08-11 16:29:23 <Ariadne> and then we register it in fixate mode
2021-08-11 16:29:31 <Ariadne> so that it can live outside the container
2021-08-11 16:31:07 <ikke> Ariadne: where is that fixating done?
2021-08-11 16:31:40 <ericonr_> you can also build it fully static and throw it inside the container, if that's easier to do :)
2021-08-11 16:32:43 <Ariadne> https://github.com/jirutka/qemu-openrc/commit/b1cb9204a9be3d46e71eddb14f68cff489df0d0b
2021-08-11 16:32:54 <minimal> I use a docker container with binfmt/qemu on a Debian host to build all my local packages for armv7/aarch64/x86/x86_64 - works fine in general
2021-08-11 16:33:21 <ikke> Ariadne: ah, it's a flag
2021-08-11 16:33:46 <Ariadne> :)
2021-08-11 16:35:09 <ericonr_> Ariadne: I assume you have to retrigger this if you update/reinstall qemu, right
2021-08-11 16:35:20 <ikke> it's a service
2021-08-11 16:35:27 <Ariadne> ericonr_: yes, restart qemu-binfmt service
2021-08-11 16:35:57 <ikke> curious, why are is the magic / offset shorter for aarch64?
2021-08-11 16:36:18 <Ariadne> the header part is one byte shorter
2021-08-11 16:36:18 <mps> ime, lxc with qemu-user is quite fine for riscv64 build, testing etc
2021-08-11 16:36:39 <mps> and quite easy to setup on alpine
2021-08-11 16:38:15 <mps> qemu-system-* is also acceptable for some arches
2021-08-11 16:38:51 <mps> so don't see a reason to abuse bootstrap.sh
2021-08-11 16:39:22 <mps> which is not intended as cross build tool
2021-08-11 16:40:55 <Ariadne> ^
2021-08-11 16:41:07 <Ariadne> like, really, i'm half tempted to make users do something like
2021-08-11 16:41:23 <Ariadne> I_AGREE_THIS_TOOL_IS_PROBABLY_NOT_REALLY_WHAT_I_WANT=1 sh bootstrap.sh aarch64
2021-08-11 16:41:53 <Ariadne> but we live in a copy and paste from stack overflow world
2021-08-11 16:41:54 <Ariadne> sooooo
2021-08-11 16:42:14 <ikke> randomize it based on date :D
2021-08-11 16:42:45 <mps> :)
2021-08-11 16:44:00 <mps> two or three years ago I even started on basic cross build tools for alpine but stopped when I learned how it is easy with lxc
2021-08-11 16:44:30 <mps> in some simple cases mcm is quite fine
2021-08-11 16:45:52 <mps> I say 'simple cases' because I newer tried complicated tasks
2021-08-11 16:48:56 <Ariadne> i mean
2021-08-11 16:48:58 <Ariadne> its cool
2021-08-11 16:49:03 <Ariadne> to manage a sysroot with apk
2021-08-11 16:49:07 <Ariadne> but you can do that with the mcm tools
2021-08-11 16:49:14 <Ariadne> don't need to use bootstrap.sh :P
2021-08-11 16:49:27 <Ariadne> like, please don't use bootstrap.sh it is a giant hack :P
2021-08-11 16:52:17 <ikke> Affected us yesterday: https://status.fastly.com/incidents/3bwlf4zyqkk6
2021-08-11 17:38:55 <ikke> PureTryOut: is there a reason corrosion lists the same dependencies in both depends and makedepends?
2021-08-11 17:40:08 <PureTryOut> Because they are both needed at compile time and at runtime 😛 I suppose they could be added just to depends
2021-08-11 17:40:30 <ikke> The reason I'm wondering about that is because ap revdep rust lists corrosion twice
2021-08-11 17:59:19 <mps> Ariadne: you are on lwn https://lwn.net/Articles/865995/
2021-08-11 18:00:28 <veiviser> famous bunnies online
2021-08-11 18:35:52 <Thalheim> (31/40) Installing mpc1 (1.2.1-r0)
2021-08-11 18:35:56 <Thalheim> oops sorry
2021-08-11 18:59:48 <Hello71> Thermi: proot
2021-08-11 19:00:04 <adhawkins> Just wondering, but I maintain a fair few python packages for Alpine, and most of my recent changes have gone through without any issues. What's involved in getting 'commit' access for myself?
2021-08-11 19:24:24 <Thermi> Hello71, hmh?
2021-08-11 19:24:28 <Thermi> Can only answer later
2021-08-11 19:41:43 <Hello71> binfmt_misc using ptrace
2021-08-11 19:41:45 <Hello71> non root
2021-08-11 19:44:44 <ikke> adhawkins: this is something we are still working out. What certainly helps is being active, showing that you understand how things work, reviewing other MRs, etc.
2021-08-11 19:49:08 <adhawkins> Ok, understood ikke. Not sure I'm knowledgeable enough necessarily to be reviewing other PRs. I've worked out how to do simple Python packages and that's about it.
2021-08-11 19:49:31 <adhawkins> Thanks for the info though. It's no big deal waiting for MRs to be merged, but was just wondering if there was a logical next step.
2021-08-11 20:31:27 <anjan> hi, alpine docs is giving me a 404
2021-08-11 20:31:31 <anjan> https://docs.alpinelinux.org/
2021-08-11 20:31:48 <ikke> There is some issue where it does that
2021-08-11 20:32:00 <ikke> for me it loads properly
2021-08-11 20:34:48 <anjan> now it's loading
2021-08-11 21:01:00 <Ariadne> dalias: time to be annoying again :)
2021-08-11 21:01:22 <Ariadne> dalias: https://tools.ietf.org/html/rfc6943#section-3.1.1 specifies that octal and hex notation for ipv4 should be deprecated
2021-08-11 21:01:37 <Habbie> yes please
2021-08-11 21:06:22 <Ariadne> i mean if you want i can go
2021-08-11 21:06:26 <Ariadne> to the austin group
2021-08-11 21:06:44 <Ariadne> but i think we should remove support for such legacy crap
2021-08-11 21:07:03 <ikke> seems to be just a source for bugs / vulnerabilities
2021-08-11 21:09:30 <mps> :D
2021-08-11 21:12:02 <jvoisin> b-b-b-b-but job security :'(
2021-08-11 21:24:25 <Habbie> ikke, intrusion prevention systems hate this one trick!
2021-08-11 21:24:45 <ikke> heh
2021-08-11 21:46:46 <dalias> ariadne, no changes contrary to the standard will be made
2021-08-11 21:47:11 <dalias> i added the fucking byte-based C locale because the spec (after interpretation and additions for future version) requires it
2021-08-11 21:47:26 <Ariadne> if the standard is updated, will you change it :D
2021-08-11 21:47:45 <dalias> yes. but i will oppose change on the austin group because it's a gratuitous incompatible change with no benefits
2021-08-11 21:48:33 <Ariadne> there is benefits, in that attackers cannot use these obsolete syntaxes to glitch ACL systems
2021-08-11 21:48:52 <dalias> text-based ACL for IP addresses is fundamentally idiotic and unsafe
2021-08-11 21:48:53 <dalias> and deprecated because ipv6
2021-08-11 21:49:11 <Ariadne> text based ACL still exists in ipv6
2021-08-11 21:49:15 <Ariadne> we use CIDR
2021-08-11 21:49:23 <dalias> that's not text-based
2021-08-11 21:49:27 <dalias> that's byte content based
2021-08-11 21:49:37 <Ariadne> sure but it’s written in text form
2021-08-11 21:49:45 <dalias> that's not what i mean by text-based and you know it
2021-08-11 21:50:12 <Ariadne> and… because of the POSIX requirements things like MRT’s patricia code (the gold standard for CIDR lookup) supports this nonsense too
2021-08-11 21:50:16 <dalias> text based means doing pattern matching on strings rather than patterns in the actual address encoding
2021-08-11 21:50:34 <dalias> that's NOT A PROBLEM
2021-08-11 21:51:35 <dalias> the problem is doing the matching in textual presentation space rather than in the actual address space
2021-08-11 21:52:12 <Hello71> but nobody was doing that to begin with
2021-08-11 21:52:39 <Hello71> the problem is that people use one library to "validate" the address and another library to "use" the address
2021-08-11 21:53:20 <Hello71> the correct procedure should be to first parse the address, then validate it, then use the pre-parsed canonical form
2021-08-11 21:53:49 <dalias> are you talking about the perl thing?
2021-08-11 21:53:58 <Hello71> wasn't that the subject
2021-08-11 21:54:00 <dalias> where they were just misparsing it
2021-08-11 21:54:39 <Hello71> fwiw it seems that most of the "fixes" just treat leading zero as invalid
2021-08-11 21:54:49 <dalias> yes, and applications can already do that easily
2021-08-11 21:55:00 <dalias> if they don't want to accept leading zeros
2021-08-11 21:55:24 <dalias> you can write a trivial regex for 'ipv4 literal with leading zeros'
2021-08-11 21:55:30 <dalias> and reject matching strings
2021-08-11 21:55:30 <Ariadne> i’m talking about the class of vulnerability at large
2021-08-11 21:55:43 <dalias> there is no 'class of vulnerabilities' here
2021-08-11 21:56:14 <Ariadne> MITRE who have issued over a dozen CVEs relating to a defcon presentation this year relating to this seem to disagree
2021-08-11 21:57:07 <dalias> would you care to show at least one where you can viably claim the root cause was the existence of this address form rather than something idiotic like pattern matching in textual presentation space?
2021-08-11 21:57:23 <Ariadne> rust, go, perl, python, basically every language has a CVE for being inconsistent with libc on this
2021-08-11 21:57:35 <ikke> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-29922
2021-08-11 21:57:38 <ericonr_> I might be mistaken, but I think the issue was doing the parsing themselves 
2021-08-11 21:57:53 <Hello71> 21:52 <Hello71> the problem is that people use one library to "validate" the address and another library to "use" the address
2021-08-11 21:57:53 <ericonr_> Instead of passing to libc and using the parsed form
2021-08-11 21:58:18 <dalias> ikke, what is the actual supposed exploit mechanism there?
2021-08-11 21:59:10 <Ariadne> presumably somebody comparing presentation strings to a configured input
2021-08-11 21:59:17 <dalias> hello71, why are they validating it in text form rather than as an address??
2021-08-11 21:59:37 <Ariadne> i mean i agree they should not
2021-08-11 21:59:40 <Hello71> perhaps the language has bad data types
2021-08-11 21:59:46 <dalias> if you have an allow list of addresses, the address comes in on the wire as the address in an ip header
2021-08-11 21:59:47 <Ariadne> but i also think in the year of our lord 2021
2021-08-11 21:59:49 <dalias> not as a string
2021-08-11 21:59:56 <ikke> You should be supprised how many people treat ips as strings
2021-08-11 22:00:00 <Hello71> depends on your protocol
2021-08-11 22:00:00 <dalias> so there is no vector for misinterpretation
2021-08-11 22:00:04 <Ariadne> 0x7f000001
2021-08-11 22:00:10 <Ariadne> being an ipv4
2021-08-11 22:00:14 <Hello71> what if you are implementing a socks server
2021-08-11 22:00:15 <Ariadne> is insane
2021-08-11 22:00:32 <dalias> it's not at all. it always has been. your unfamiliarity with it != insanity
2021-08-11 22:00:32 <Hello71> or an http proxy, forward or reverse
2021-08-11 22:00:43 <Ariadne> im familiar with it
2021-08-11 22:00:51 <Ariadne> i think it’s stupid in 2021
2021-08-11 22:00:54 <dalias> it's one means for a user to specify an address they want to perform an operation on
2021-08-11 22:01:00 <dalias> with no security consequences whatsoever
2021-08-11 22:01:01 <Ariadne> it’s possible to hold both positions at once
2021-08-11 22:01:34 <dalias> i guarantee you there are shell scripts that use odd forms like this because of what math/string ops are easy to do in shell
2021-08-11 22:02:13 <dalias> e.g. a for loop over 0..0xffffffff to probe all hosts
2021-08-11 22:02:32 <Ariadne> why would you do that in shell instead of using zmap
2021-08-11 22:02:52 <dalias> because ppl do
2021-08-11 22:03:07 <dalias> also probably things like setting up iptables rules
2021-08-11 22:03:22 <Ariadne> i mean maybe you have a case with up tables
2021-08-11 22:03:25 <Ariadne> …
2021-08-11 22:03:28 <Ariadne> iptables
2021-08-11 22:03:46 <Ariadne> that one i could see
2021-08-11 22:03:49 <dalias> there is utterly no sense in breaking an interface that is not attack surface in any remotely plausible way
2021-08-11 22:04:05 <dalias> someone just wanted to pad their cv with cves
2021-08-11 22:04:30 <dalias> if they were real cves they would have a plausible narrative for how one uses the bug to gain privilege
2021-08-11 22:05:26 <dalias> and yes it is a bug in these language runtimes because leading-zero-decimal has never been a valid ipv4 literal form
2021-08-11 22:05:33 <Ariadne> well the defcon presentation did show a typical php application with IP acl for the admin panel being bypassed
2021-08-11 22:05:37 <Ariadne> or something
2021-08-11 22:05:44 <Ariadne> i should watch it again, kinda skimmed it
2021-08-11 22:06:59 <dalias> i dont think it's plausibly an IP ACL for remote addresses a resource can be accessed *from* since those would always inherently come in the canonical form when converted from wire form to text
2021-08-11 22:07:12 <dalias> it's probably an ACL for *outgoing* requests you're allowed to make
2021-08-11 22:08:07 <dalias> maybe doing something like blocking outgoing requests to localhost/localnet because the web app implicitly considers localhost/localnet trusted/root-equivalent
2021-08-11 22:08:23 <Ariadne> PHP users check against $_REQUEST[‘IPADDR’] or whatever it is
2021-08-11 22:08:35 <Ariadne> which is a string
2021-08-11 22:08:38 <dalias> right but that will not be attacker-provided text
2021-08-11 22:09:04 <dalias> PHP obtains it from getnameinfo() on getpeername() or whatever
2021-08-11 22:09:32 <dalias> anyway, continuing what i was saying
2021-08-11 22:09:34 <Ariadne> it gets it from env var actually
2021-08-11 22:09:44 <Ariadne> in fastcgi mode anyway
2021-08-11 22:09:55 <dalias> ...and then you write the outgoing localhost/localnet request in some form they're not expecting to bypass their text-matching-based ACL...
2021-08-11 22:10:15 <dalias> (or address-space-matching but with improper parsing of the address, as it seems to have been)
2021-08-11 22:10:36 <dalias> the env var comes from the httpd/cgi implementation doing getnameinfo/inet_ntop on getpeername
2021-08-11 22:10:57 <dalias> so it's in canonical form
2021-08-11 22:19:00 <dalias> so if my theory is correct, the scenario was something like this
2021-08-11 22:20:16 <dalias> it was something like a SSRF vuln, where the site was supposed to be blocking requests to 127.0.0.0/8 (properly done in address space not presentation space)
2021-08-11 22:20:49 <dalias> but the ACL rule was processed with buggy perl or whatever that misinterpreted 0177.0.0.1 as 177.0.0.1 and flagged it "allow"
2021-08-11 22:21:10 <dalias> then the text was re-processed by the actual http-request-performing library that interpreted it correctly as 127.0.0.1
2021-08-11 22:21:17 <dalias> thus bypassing the ACL
2021-08-11 22:32:33 <Hello71> yes, that's one possible instance
2021-08-11 22:33:57 <Hello71> i think we agree that the correct procedure is to first convert it to {127, 0, 0, 1}, then check it, then if it is ok, connect to {127, 0, 0, 1}, not 0177.0.0.1
2021-08-11 22:35:19 <Hello71> an alternative procedure would be to convert to {177, 0, 0, 1}, then check it, then if it is ok, connect to {177, 0, 0, 1} which is against some standards but is also secure
2021-08-11 22:36:07 <dalias> i get why the multiple conversion happens -- the actual connection workflow is expecting a url that's a text string because it's usually a name not an ip literal
2021-08-11 22:36:35 <dalias> of course there are all sorts of other ways this shit is insecure
2021-08-11 22:36:56 <dalias> like what if you have a dns record with a really low ttl that resolves to something harmless on first lookup then 127.0.0.1 on second lookup?
2021-08-11 22:38:03 <dalias> the underlying problem is bs ip-based access control: ability to make connections to 127.0.0.1 should not get you any privilege
2021-08-11 22:38:32 <dalias> but if they're going to insist on doing it that way, the process should be running in a network namespace where it's firewalled off from access to localhost
2021-08-11 22:38:40 <dalias> not doing these kind of insecure ACL things
2021-08-11 22:39:21 <Hello71> well the step 1 checks if it "is an ip address", the theory being that if it is an ip address then the form is canonical
2021-08-11 22:39:43 <Hello71> and netns is good but not portable
2021-08-11 22:39:46 <dalias> but how do you defend against my malicious dns record?
2021-08-11 22:40:16 <Hello71> "check if it is ok" includes a check if it "is an ip address". if you pass "mymaliciousdomain.com" it will reject it
2021-08-11 22:40:41 <dalias> are you sure? i think the expected usage in most of these is domain names
2021-08-11 22:40:58 <dalias> think of the situation where you're giving a web application a url for some resource you want it to fetch
2021-08-11 22:48:06 <Hello71> uhh... it could be?
2021-08-11 22:49:36 <Hello71> maybe it uses this procedure: if it is not an ip address, then resolve it to an ip address string. then, validate the string. then, connect to the string
2021-08-11 22:49:42 <Hello71> not sure
2021-08-12 02:53:45 <LACampbell> is there a guide for man pages that alpine follows? or should follow?
2021-08-12 08:14:17 <mps> andypost[m]: there is aports-glmr pkg which can be used to check if MR already exist
2021-08-12 08:14:57 <mps> not perfect but anyway very useful
2021-08-12 08:25:01 <andypost[m]> mps: thanks!
2021-08-12 09:17:18 <nmeum> mps: iirc you posted instructions for booting alpine riscv64 as a qemu vm a few weeks(?) ago, could you post the link again I can't seem to find it in the backlog
2021-08-12 09:19:46 <mps> nmeum: it is here https://dev.alpinelinux.org/~mps/riscv64/ but it is somewhat outdated. anyway it should work if you change create-rv64-img.sh '-X' (repo) params for apk to dl-cdn
2021-08-12 09:21:03 <mps> I intended to wait for 5.14 kernel release (stable) to test all this again, 5.14 have some important fixes for riscv
2021-08-12 09:22:17 <nmeum> thanks, my goal is booting on a real hifive1 unmatched anyhow :)
2021-08-12 09:22:36 <ikke> Do you have one?
2021-08-12 09:22:40 <nmeum> yes, 3 actually :D
2021-08-12 09:22:44 <mps> if you have it that is best option
2021-08-12 09:22:59 <nmeum> > Linux unmatched 5.11.10 #1 SMP Wed Apr 7 17:37:34 UTC 2021 riscv64 riscv64 riscv64 GNU/Linux
2021-08-12 09:23:10 <mps> uhm, 3 (I'm jealous)
2021-08-12 09:23:10 <nmeum> currently running the standard image that comes with the package
2021-08-12 09:24:03 <nmeum> I just have to understand the boot process and then figure out how to properly create an alpine image for it, but should be doable
2021-08-12 09:25:51 <mps> nmeum: if you know anything is needed for our kernels please add it to linux-edge or create MR or post it directly to me, whatever you find easier for you
2021-08-12 09:26:09 <nmeum> sure :)
2021-08-12 11:51:33 <xsteadfastx> can it be that a patch on the mailinglist doesnt get shown in gitlab because i wrote [Patch v2] instead of [PATCH v2]?
2021-08-12 11:53:07 <ikke> I would not expect that. sircmpwn ^
2021-08-12 11:53:34 <sircmpwn> yes, that's expected
2021-08-12 11:53:37 <sircmpwn> why did you rewrite that?
2021-08-12 11:53:47 <xsteadfastx> ok... https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24161 its not showing up there
2021-08-12 11:55:03 <ikke> xsteadfastx: there is currently no support for updating MRs, each patch series will be a new MR
2021-08-12 11:55:16 <xsteadfastx> ah ok
2021-08-12 11:55:42 <xsteadfastx> but still its not showing up. so i think its how i wrote PATCH in the header... damn me
2021-08-12 11:55:56 <sircmpwn> why did you change the way PATCH is written in the subject line?
2021-08-12 11:56:12 <sircmpwn> follow https://git-send-email.io and avoid changing anything you don't have to
2021-08-12 11:56:39 <xsteadfastx> i used --subject-prefix like on https://wiki.alpinelinux.org/wiki/Creating_patches ... but i wrote it wrong
2021-08-12 11:57:31 <sircmpwn> I didn't know this page existed
2021-08-12 11:57:33 <sircmpwn> this is not a good resource
2021-08-12 11:57:42 <sircmpwn> I'll add rewriting it to my todo list
2021-08-12 11:57:45 <xsteadfastx> i should have used your get-send-email website to do it. 
2021-08-12 11:57:57 <xsteadfastx> so should i send it again?
2021-08-12 11:57:59 <sircmpwn> aye
2021-08-12 11:59:31 <xsteadfastx> i will do that
2021-08-12 14:24:51 <minimal> Hi. I thought the recently introduced bot on gitlab meant that any MRs raised for a package would be auto-assigned to the package maintainer. Is this not the case?
2021-08-12 14:25:20 <ikke> minimal: should be
2021-08-12 14:25:25 <ikke> but only if it can find one
2021-08-12 14:26:26 <minimal> hmm, just noticed a MR on one of my packages and its not assigned to anyone yet, !24156
2021-08-12 14:27:06 <mps> it is now
2021-08-12 14:27:45 <minimal> hmm, maybe my eyes weren't working right lol
2021-08-12 14:28:02 <mps> and iirc, it was when it is created
2021-08-12 14:28:56 <mps> I noticed it this morning and wanted to merge but waited for you to approve
2021-08-12 14:28:59 <minimal> oops, guess I just haven't had enough coffee today
2021-08-12 14:29:12 <ikke> heh
2021-08-12 14:29:53 <minimal> mps: yeah it *needs* the newer jitterentropy-library or else the jitter stuff doesn't work right, its taken a couple of months for both rng-tools and jitterentropy-library authors to commits and release changes that interact
2021-08-12 14:30:22 <mps> I read your comment there
2021-08-12 14:31:22 <minimal> one weird think is that I added a patch to file a compile error - but I don't see compile error in the CI build logs for that MR, very weird
2021-08-12 14:31:33 <minimal> s/file/fix/
2021-08-12 14:40:07 <minimal> what's the mechanism for doing MR(s) for a package & its dep? Do I raise a single MR with 2 commits, 1 per package? OR do I have to raise separate MRs with the dep package first and have to wait for it to be merged before submittng 2nd MR?
2021-08-12 14:44:13 <ikke> one MR, multiple commits
2021-08-12 14:44:22 <minimal> ikke: thanks
2021-08-12 14:44:27 <ikke> If the amount of packages is large, you could combine them per repo
2021-08-12 17:24:12 <minimal> question about CI - just pushed a change to a MR where I modified a patch file (to patch 2 files rather than 1) but in the new pipeline build logs the output only logs it patched 1 file. Its almost like it has cache the old file - but then the build should fail (changed checksum) unless it has also cached the old APKBUILD as well
2021-08-12 17:24:50 <ikke> It should not cache anything
2021-08-12 17:25:40 <minimal> ok. I'm still confused as the build logs output does not look right
2021-08-12 17:25:55 <ikke> What MR?
2021-08-12 17:26:11 <minimal> !24170
2021-08-12 17:26:13 <ikke> The working tree should match exactly what's in the commit
2021-08-12 17:26:35 <minimal> the original MR only patches rngd_jitter.c, the revised MR patches configure.ac as well
2021-08-12 17:27:24 <minimal> in the x86_64 build pipeline output line 220 shows the 1 file being patched
2021-08-12 17:28:02 <ikke> https://gitlab.alpinelinux.org/dbradley/aports/-/jobs/460702
2021-08-12 17:28:09 <ikke> Here I see 2 files being patched
2021-08-12 17:30:15 <minimal> yeah. I think I'm having one of those days......seems like I might have somehow viewed the previous pipeline output. Doh!
2021-08-12 17:30:27 <ikke> It can happen :)
2021-08-12 17:30:49 <minimal> coffee isn't working for me today.....time for something stronger, like diesel ;-)
2021-08-12 17:30:55 <ikke> haha :D
2021-08-12 17:31:20 <minimal> <hears over loudspeaker> "step away from the keyboard!"
2021-08-12 17:48:35 <mps> nmeum: https://arvanta.net/alpine/install-alpine-riscv64-qemu/
2021-08-12 17:48:59 <mps> this one is 'renewed' to use alpine mirror and kernel
2021-08-12 17:49:26 <nmeum> I unfourtunatly need to sort out all the u-boot shenanigans first
2021-08-12 17:49:45 <nmeum> and it also seems that linux mainline does not fully support the unmatched yet
2021-08-12 17:50:28 <mps> yes, I think so
2021-08-12 17:50:51 <mps> we will see will it be better with 5.14
2021-08-12 17:51:31 <mps> anyway above short script is a hint for those who want to try alpine riscv in qemu
2021-08-12 17:53:59 <nmeum> https://github.com/sifive/meta-sifive/tree/2021.07/recipes-kernel/linux/files
2021-08-12 17:54:23 <nmeum> these are the patches they seem to apply for the kernel that is shipped on the sdcard that comes with the package
2021-08-12 17:54:41 <nmeum> 5.12 kernel though
2021-08-12 17:55:05 <mps> not small number of them
2021-08-12 17:55:10 <nmeum> yeah unfourtunatly
2021-08-12 17:55:43 <mps> I think we should not forward port them for alpine, but who knows
2021-08-12 17:56:11 <nmeum> nah, I don't think we should port them. I will just use a custom kernel for now I think
2021-08-12 17:56:59 <mps> sounds like better idea for now
2021-08-12 17:57:19 <nmeum> I think/hope they will be upstreamed eventually
2021-08-12 17:58:08 <mps> yes, same
2021-08-12 17:58:33 <nmeum> there are also a bunch of uboot and opensbi patches in the aforementioned repository but these seem less invasive
2021-08-12 18:00:11 <mps> eh, I'm 'monitoring' u-boot changes in hope that things will be fixed
2021-08-12 19:55:00 <senzilla> Not sure if this is the right place to ask... Has there been any progress on setting up the Alpine Foundation? I believe there were at least brief discussions about it during the last AlpineConf
2021-08-12 19:59:55 <ikke> senzilla: We have a council, but there is no legal entity yet
2021-08-12 20:43:23 <Ariadne> there's been a lot more urgent things to work on first :P
2021-08-12 20:43:36 <Ariadne> foundations and stuff is what you work on when you have everything else already figured out
2021-08-12 20:46:15 <ikke> It's something we'll be working on in the background
2021-08-13 05:15:16 <craftyguy> is this waiting on someone to include patches that bump all the applications listed there: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23671 ?
2021-08-13 05:15:47 <craftyguy> or is it waiting on something else?
2021-08-13 05:18:01 <ikke> That's at least one requirement
2021-08-13 05:22:48 <craftyguy> let me rephrase: I'd like to help out, but it's not clear what needs to get done, or how I can help
2021-08-13 05:25:13 <ikke> hmm, Leo/Maxice8 is not here atm
2021-08-13 05:25:24 <ikke> the work itself just means increasing the pkgrel of all those packages
2021-08-13 05:25:47 <craftyguy> right, that's not too hard to do
2021-08-13 05:26:27 <craftyguy> I could do that and make a merge request to Leo's aports branch I guess, if that's helpful
2021-08-13 05:26:33 <ikke> You could ask Leo to give push access to his fork, then you could contribute to that branch
2021-08-13 06:09:17 <Thermi> Is there a shorthand for making abuild build all packages in the right order?
2021-08-13 06:09:21 <Thermi> (to fullfill dependencies)
2021-08-13 06:22:34 <yyp> abuild -R
2021-08-13 06:23:14 <yyp> Hm, it got removed
2021-08-13 06:36:10 <ikke> ap builddirs
2021-08-13 06:36:14 <ikke> lists packages in build order
2021-08-13 06:36:26 <ikke> ap builddirs pkg1 pkg2 pkg3
2021-08-13 06:39:02 <ikke> You need lua-aports for that, and run it in the repo directory (ie, aports/commuunity)
2021-08-13 06:39:43 <Thermi> Tyvm
2021-08-13 06:42:23 <Thermi> Ariadne, https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/114
2021-08-13 06:42:41 <Thermi> Adds a warning and a check to make users aknowledge that cross compiling is not supported anymore
2021-08-13 06:44:01 <ikke> Thermi: I think that misses the point. bootstrap.sh is used for cross-compiling, but in a very limited sense.
2021-08-13 06:44:17 <ikke> If we want to bootstrap a new arch, that does involve cross-compiling
2021-08-13 06:44:58 <ikke> but as soon as there is a native tool-chain, the cross-compile tool-chain is no longer used
2021-08-13 06:45:06 <ikke> (as far as my understanding goes)
2021-08-13 06:45:28 <Thermi> So how is it supposed to be formulated?
2021-08-13 06:47:52 <ikke> Something like "this is not meant to create a general-purpose cross-compiler, and is only supported to created a native toolchain"
2021-08-13 07:32:12 <Thermi> I tried to get perl to cross compile but that is such a big problem that people made their own git repo to hold the needed stuff, so I postponed that into infinity. 
2021-08-13 07:32:18 <Thermi> https://github.com/arsv/perl-cross
2021-08-13 07:32:34 <Thermi> I'll try that when I have no other problems left.
2021-08-13 07:33:16 <Thermi> ikke, I just pushed a modified version with your wording.
2021-08-13 07:35:27 <Thermi> Hmh. Considering most people will cross compile using scripts/bootstrap.sh from aports, I think Timo might have an issue with that 
2021-08-13 07:35:51 <Thermi> Because I think at least one person will want that new env var to be set in bootstrap.sh
2021-08-13 07:35:54 <Thermi> and then it's useless.
2021-08-13 07:36:11 <Thermi> I think I'll add a warning in bootstrap.sh as a comment
2021-08-13 07:37:13 <mps> to repeat again: bootstrap.sh is not alpine cross build tool
2021-08-13 07:37:24 <ikke> mps: I think that's clear by now
2021-08-13 07:37:42 <Thermi> I think even the IRC server understands that now.
2021-08-13 07:37:44 <mps> I had a hope also ;)
2021-08-13 07:37:56 <Thermi> We are discussing right now how to best make users aware of that.
2021-08-13 07:38:23 <Thermi> And best with aware as in they read it, and not skip it.
2021-08-13 07:38:27 <ikke> I think a comment in bootstrap.sh should suffice, as most unfamiliar users would inspect it any way
2021-08-13 07:38:47 <Thermi> It's primarily for Ariadne, because she wanted that
2021-08-13 07:39:06 <ikke> Thermi: I'm not sure if it was actually a serious suggestion
2021-08-13 07:39:18 <mps> I wonder if users ever read comments :P
2021-08-13 07:39:19 <Thermi> There was no /s or anything following it
2021-08-13 07:39:50 <ikke> "I_AGREE_THIS_TOOL_IS_PROBABLY_NOT_REALLY_WHAT_I_WANT=1"
2021-08-13 07:40:10 <Thermi> That's a little bit long
2021-08-13 07:40:33 <ikke> yes, but, at least to me, kinda suggests it's not really serious
2021-08-13 07:40:35 <veiviser> i believe it is the appropriate length
2021-08-13 07:40:39 <mps> my english is bad but even I see what is it from name
2021-08-13 07:41:16 <mps> bootstrap != cross build
2021-08-13 07:41:23 <Thermi> TBH I just want bootstrap.sh to work again, because there are issues with its dependencies right now that I fixed
2021-08-13 07:41:26 <Thermi> and I want the MRs merged.
2021-08-13 07:42:03 <mps> I 'fear' of your MRs :)
2021-08-13 07:42:38 <Thermi> It's not overly complex. (Btw I want iproute2 in bootstrap.sh, too, because it's needed for fundamental network configuration)
2021-08-13 07:42:43 <mps> Thermi: please don't take this seriously, I'm just kidding
2021-08-13 07:42:49 <Thermi> good
2021-08-13 07:44:26 <ikke> Thermi: not sure if we want bash in the bootstrap path
2021-08-13 07:45:26 <ikke> and it would add bison and flex as well
2021-08-13 07:45:46 <Thermi> Those are fairly quick to build
2021-08-13 07:45:53 <ikke> It's not about the time to build
2021-08-13 07:47:57 <Thermi> I looked at it
2021-08-13 07:48:44 <Thermi> bison and flex are only needed for elfutils, which is needed for a dependency of iproute2
2021-08-13 07:48:54 <Thermi> so we could just keep it out of boostrap.sh
2021-08-13 07:49:38 <ikke> But I'm curious why you need a networking utility for bootstrapping
2021-08-13 07:50:46 <Thermi> Because right now, we actually use boostrap.sh for building the packages for an image directly, instead of using rootbld and qemu-user
2021-08-13 07:51:16 <Thermi> We'll get to a native build shortly, in a couple of weeks
2021-08-13 07:51:31 <Thermi> I just pushed a version without the dependencies for iproute2
2021-08-13 07:51:47 <Thermi> I will need to try to bootstrap that first though.
2021-08-13 07:58:41 <ikke> But can't you manually continue building packages after bootstrap.sh is finished?
2021-08-13 07:59:02 <ikke> Or maintain a customized verison of bootstrap.sh for the time being
2021-08-13 08:00:08 <Thermi> I have a locally adapted version that takes $2 and $3 for package name and abuild subcommand, so I have some thing
2021-08-13 08:00:39 <Thermi> The changes to bootstrap.sh and the dependencies are just so other people don't need to spend time on getting it working
2021-08-13 08:01:05 <ikke> Just fixes to get it working should not be an issue
2021-08-13 08:01:22 <Thermi> Yes. I am currently testing the MR locally.
2021-08-13 08:01:51 <Thermi> There's still an issue with the gcc package and gnat where the gnat libs are of the wrong format and architecture.
2021-08-13 08:03:00 <Thermi> The gcc package produces gnat libs that are of the wrong architecture when cross compiling
2021-08-13 08:03:16 <Thermi> I'll need to take a look at that too
2021-08-13 08:03:23 <ikke> Does that have to do with binutils?
2021-08-13 08:03:31 <Thermi> No, just with gcc and the packaging
2021-08-13 08:03:35 <ikke> ok
2021-08-13 08:03:42 <Thermi> All other files are correct
2021-08-13 08:03:47 <Thermi> just the gnat/ADA related ones are not.
2021-08-13 08:17:57 <clandmeter> the fix is not to say what bootstrap.sh is not, but to add a doc explain what it actually does. aka documentation.
2021-08-13 08:18:12 <ikke> yes
2021-08-13 08:18:28 <ikke> Add a readme to the scripts dir
2021-08-13 08:50:06 <Thermi> Will do. Can somebody do me a favor and review (and merge?) !18285 please?
2021-08-13 11:34:46 <Ariadne> 2:42 AM <mps> Thermi: please don't take this seriously, I'm just kidding
2021-08-13 11:34:54 <Ariadne> i'm not, bootstrap.sh is not intended for this purpose
2021-08-13 11:35:13 <Ariadne> everything in the package list is something that needs to be cross-built in order to bootstrap on the target
2021-08-13 11:42:56 <Ariadne> iproute2 is not needed to bootstrap on the target
2021-08-13 11:44:36 <Thermi> Yep. It was something I had in here.
2021-08-13 11:45:28 <Thermi> I prepared the dependencies of iproute2 and strongSwan for cross compilation because right now it was/is the fastest way to get the package for a different architecture from a custom APKBUILD. I dealt with all the issues in them to make them work with cross compiling.
2021-08-13 11:45:40 <Thermi> I also commented under abuild/114 now.
2021-08-13 11:46:11 <Thermi> Ariadne, ty for merging
2021-08-13 12:02:06 <mps> Ariadne: I meant to say that I'm kidding about my fear, not about bootstrap.sh changes
2021-08-13 12:03:27 <mps> as distro developers/maintainers we have to say 'no' for some changes or ideas or .... whatever
2021-08-13 12:05:01 <mps> 'keep your mind open and you will soon notice how much junk will random people put in it'
2021-08-13 12:07:46 <Thermi> !24079 should be fine, it's only the fixes
2021-08-13 15:52:49 <Thermi> Please somebody review and merge !24079. They're just two fixes for two packages so bootstrap.sh works again
2021-08-13 16:02:41 <Thermi> Ariadne, tyvm
2021-08-13 16:03:21 <Ariadne> Thermi: fwiw, i do have plans to improve cross-compilation support in alpine, but they do not focus around bootstrap.sh
2021-08-13 16:04:06 <Ariadne> if we are going to do this, we should do it by prebuilding the toolchains
2021-08-13 16:04:44 <Thermi> Ariadne, are you referring to the compilers, binutils, etc, or something different?
2021-08-13 16:04:52 <Ariadne> compilers, binutils, etc
2021-08-13 16:05:03 <Thermi> Yes, they are so common, they could be provided in the repos
2021-08-13 16:05:35 <Thermi> If they are built, too, we'd at least know when the gcc package again breaks
2021-08-13 16:07:26 <Thermi> Once the tools are available in the repo, what then? And how far do you want to go?
2021-08-13 16:14:16 <Ariadne> i don't want to impose a cross-compile requirement on package maintainers
2021-08-13 16:14:29 <Ariadne> at least, not yet
2021-08-13 16:14:35 <Ariadne> there's more important fires to put out
2021-08-13 16:23:05 <Thermi> Yes, of course. But what /do/ you want, in detail if possible?
2021-08-13 16:26:46 <Ariadne> i want bootstrap.sh to die :)
2021-08-13 16:27:17 <Ariadne> or, rather, i want bootstrap.sh to not generate a cross-toolchain and instead only focus on bootstrap
2021-08-13 16:30:40 <Thermi> Well, it's generated if it's not already there
2021-08-13 16:31:25 <Thermi> But you knew that already. So just checking if there's a tool for binutils in main or community should work
2021-08-13 16:31:39 <Thermi> if there's none, and none in a local repo, build it
2021-08-13 16:43:39 <Ariadne> yes, but we could just do `apk add build-base-aarch64` instead
2021-08-13 16:43:44 <Ariadne> and get a cross compiler :p
2021-08-13 17:21:15 <nmeum> yes that would be nice, we also have some cross compilers for embedded in the repos already
2021-08-13 17:21:54 <nmeum> community/gcc-cross-embedded
2021-08-13 17:53:04 <Hello71> but how useful is a distro cross compiler without support for actually building packages? the only applications i can think of are mingw and maybe bare-metal
2021-08-13 17:53:39 <Hello71> the strength of distro-supported cross-compilation is that it grants access to all the packages supported by the distro (at least in theory)
2021-08-13 17:54:05 <ericonr_> Hello71: arch ships aarch64-gnu cross toolchain, afaik
2021-08-13 17:54:14 <Hello71> yes, and some others
2021-08-13 17:54:33 <Hello71> https://archlinux.org/packages/?q=gcc (not exactly but close enough)
2021-08-13 17:57:59 <ericonr_> hm, aarch64, riscv64 and mingw for hosted targets
2021-08-13 17:59:04 <ericonr_> calling bare metal toolchains *-elf-* feels kinda weird, tbh
2021-08-13 17:59:23 <dalias> why?
2021-08-13 17:59:25 <Hello71> i assume they do actually make elfs
2021-08-13 18:00:02 <dalias> they use elf object files and generate elf executables (altho for the latter you might intend to dump out just the text to some other format to flash or whatever)
2021-08-13 18:00:10 <dalias> and have elf linking semantics
2021-08-13 18:00:40 <ericonr_> dalias: exactly because you will usually just dump .text somewhere else
2021-08-13 18:00:54 <ericonr_> so naming the toolchain after an "intermediary" step seems wrong
2021-08-13 18:01:05 <dalias> the toolchain produces elf
2021-08-13 18:01:15 <dalias> if you want to dump it to something else that's independent of the toolchain
2021-08-13 18:01:20 <dalias> but really you don't need to
2021-08-13 18:01:33 <ericonr_> like arm-none-eabi isn't called elf, for some reason (?)
2021-08-13 18:01:37 <dalias> for example the arduino-style avr flash utilities take elf input
2021-08-13 18:01:53 <ericonr_> for that matter so does openocd :)
2021-08-13 18:01:54 <dalias> maybe eabi implies elf? i dunno
2021-08-13 18:02:09 <ericonr_> (take elf input, I mean)
2021-08-13 18:02:56 <ericonr_> but yeah, thinking in terms of onlt the toolchain it makes sense to be called elf
2021-08-13 18:03:25 <ericonr_> and for hosted targets you'd add a -linux or -gnu or -musl or whatever
2021-08-13 20:33:06 <ikke> Anyone knows what's up with rust packages timing out on crates.io?
2021-08-13 20:40:29 <ikke> error: failed to download from `https://crates.io/api/v1/crates/aes/0.3.2/download`
2021-08-13 20:46:24 <ericonr> https://github.com/rust-lang/cargo/issues/9697
2021-08-13 20:48:43 <ikke> Hmm, that talks about nightlies, and as far as I know, we aren't on a nightly version
2021-08-13 20:49:28 <ericonr> I think it's a server side thing, so the toolchain version doesn't matter
2021-08-13 20:49:33 <ericonr> Or it's because of libcurk
2021-08-13 20:49:45 <ericonr> *libcurl
2021-08-13 20:49:55 <ikke> yeah, I read that in the linked issue
2021-08-14 07:20:16 <andypost> looks riscv builder is stuck on community/bullet 2.89-r2
2021-08-14 07:38:11 <clandmeter> algitbot: kick master
2021-08-14 07:43:00 <clandmeter> algitbot: it was not
2021-08-14 07:43:27 <clandmeter> It was building libwebp
2021-08-14 07:43:35 <ikke> clandmeter: I already kicked it
2021-08-14 07:43:50 <clandmeter> Ok
2021-08-14 07:44:08 <clandmeter> So I kicked something else
2021-08-14 07:44:11 <ikke> yes
2021-08-14 09:47:57 <ikke> Thermi: https://www.openwall.com/lists/oss-security/2021/08/14/2
2021-08-14 10:22:19 <ikke> FYI, I'll be restarting gitlab in 8 minutes for a security ugprade
2021-08-14 10:36:52 <ikke> Upgrade complete
2021-08-14 14:14:51 <Hello71> mps: what do you think about making libudev-zero the default udev provider
2021-08-14 14:15:19 <Hello71> i think it would allow sway to work ootb
2021-08-14 14:20:47 <mps> Hello71: I'm for it, but hot-plugging input devices could be problematic for X and wayland
2021-08-14 14:21:14 <mps> I didn't had time (and need, tbh) to work on fixing this
2021-08-14 14:22:11 <mps> and I remember that I had to write special script for usb-modeswitch not worked on one of my SBC about 6-8 months ago
2021-08-14 14:23:26 <mps> lets see what other devs (or tsc, pfffff) thinks about this and we can work more on it if 'we' decide to switch
2021-08-14 15:15:21 <mps> '-r-xr-xr-x 1 root root 251768 Nov 10  2020 /usr/bin/mandoc', I think installing system binaries non-writeable is quite sane, and i have no intention of changing that. Ingo Shwarze in mail just arrived in my inbox :)
2021-08-14 16:38:48 <Thermi> ikke, yeah, saw that this morning. I'll patch today.
2021-08-14 16:39:58 <Thermi> Well.
2021-08-14 16:40:11 <Thermi> I'll take a look at if we can patch this weekend, or just wait for kopano to provide a patch
2021-08-14 16:40:32 <Thermi> Well, I'll do *something*.
2021-08-14 17:43:03 <MY-R> mps: it doesnt change much if file owned by root is writable because you still can remove/edit it without any problem as a root
2021-08-14 17:45:32 <mps> MY-R: yes ofc
2021-08-14 17:49:20 <MY-R> if user make non writable file then at least getting message before remove it that file isnt writable etc
2021-08-14 17:55:34 <mps> yes, I know all these (mps is linux user nearly 30 years :) )
2021-08-14 20:45:19 <MY-R> mps: :D
2021-08-14 20:45:53 <MY-R> so you know that chmod 000 foo is nothing for root! :D
2021-08-14 21:15:53 <timlegge> mps: not sure if my explanation in !24211makes sense - basically I used that variable name because it is what apkbuild-cpan.in used..
2021-08-14 21:50:29 <mps> timlegge: 'to my english' it looks like somewhat unclear
2021-08-14 21:51:35 <mps> but I think I already drinked too much wine, maybe it would be better to continue tomorrow
2021-08-14 21:52:33 <MY-R> beer > wine!
2021-08-14 21:53:32 <mps> MY-R: no, just wine. I don't like bear
2021-08-14 21:53:56 <mps> ok, and home made brandy, ofc ;)
2021-08-14 21:54:08 <mps> beer*
2021-08-14 21:54:30 <mps> I like bears
2021-08-14 21:54:57 <mps> 'Маша и медвед' :)
2021-08-14 22:00:30 <MY-R> :P
2021-08-14 22:04:54 <mps> what!? you don't like Masha and Bear
2021-08-14 22:07:49 <timlegge> mps: no worries its no rush.  enjoy your night
2021-08-14 22:08:56 <mps> timlegge: thanks
2021-08-15 07:03:43 <sircmpwn> did anyone else have their firmware hosed by a recent update
2021-08-15 07:03:48 <sircmpwn> sure would be nice to have that apk.log file now
2021-08-15 07:09:36 <sircmpwn> ah, eudev was somehow uninstalled
2021-08-15 09:39:13 <mps> timlegge: good morning. '_pkgreal=DBD-SQLite' doesn't sounds to me as good variable name. what 'real' part means. ok, I understand in this case but only after seeing what is after '=' sign
2021-08-15 09:40:39 <mps> _pkgreal could be anything 'real' in pkg so I propose to change it to _pkgrealname and change apkbuild-cpan to create this var name when creating new pkgs
2021-08-15 09:41:11 <ikke> _pkgupstream?
2021-08-15 09:41:19 <ikke> or _upstreamname
2021-08-15 09:41:51 <mps> but I still think that old _pkgname is quite fine, especially because it is in use about 10 years for alpine
2021-08-15 09:42:30 <ikke> but it's not really a package name you are describing
2021-08-15 09:43:05 <mps> ikke: well, a lot other APKBUILDs have _pkgname var
2021-08-15 09:43:27 <ikke> Doesn't mean it's a good variable name
2021-08-15 09:43:57 <mps> I think we should change this 'custom' naming for all pkgs and not only perl pkgs
2021-08-15 09:44:15 <ikke> Yes, I'm not arguing it should only be done for perl packages
2021-08-15 09:45:46 <mps> that is what I think, and that is why I'm against this changes without wide discussions
2021-08-15 09:46:42 <mps> (ikke will change his misleading nick :P )
2021-08-15 09:58:45 <veiviser> ikke sant
2021-08-15 10:51:04 <timlegge> mps: ikke: when I did some work on apkbuild-cpan for edge cases _realname, _pkgreal, _pkgname, _name, _realpkgname, _pkg_real have been used in various perl packages over the years.
2021-08-15 10:52:11 <timlegge> _pkgreal has been in apkbuild-cpan for 10 years so I suspect it is in use in the majority by now.  It does not necessarity make it a great name though
2021-08-15 10:53:41 <timlegge> apkbuild-cpan would be a little simpler if we could recreate all the perl APKBUILDs with the current template.  whichever variable names are used.
2021-08-15 10:55:58 <timlegge> you probably already know that variable is there only to hold the cpan distribution name so that apkbuild-cpan can find it later for a recreate or update as the translation from CPAN modulename to apk package name is a one way algorithm :-)
2021-08-15 11:00:23 <ikke> timlegge: Yes, I indeed understand the purpose of the name, and don't oppose it. Just saying that the name of the variable should be descriptive. But like you said, this has a long history
2021-08-15 11:04:52 <timlegge> worth noting that it is also in apkbuild-pypi but I am not sure how much it is used (I did fix some issues with it a while ago)
2021-08-15 11:05:57 <timlegge> otherwise I might suggest _cpanpkgname (really apkbuild-cpan only knows how to find perl modules from cpan)
2021-08-15 11:06:46 <timlegge> there are a less than a half-dozen perl packages based on git repos I believe.
2021-08-15 11:11:54 <ikke> timlegge: it's used in all kinds of contexts
2021-08-15 11:12:17 <ikke> Some just manually add it
2021-08-15 11:18:39 <timlegge> I have no issue chaning it an apkbuild-cpan - I had given some thought to modernizing all the perl packages so it should be agreed upon before I go down that road...
2021-08-15 11:18:56 <timlegge> It would become template 4
2021-08-15 11:22:00 <mps> yes, what a mess
2021-08-15 11:22:15 <mps> grep -r "^_pkgreal=" main/ | wc -l => 249
2021-08-15 11:22:39 <mps> grep -r "^_pkgname=" main/ | wc -l => 118
2021-08-15 11:51:03 <timlegge> grep _realname= -r ../../*/perl*/APKBUILD | wc => 45
2021-08-15 11:51:20 <timlegge> grep _pkgname= -r ../../*/perl*/APKBUILD | wc => 38
2021-08-15 11:51:32 <timlegge> mps: yes indeed
2021-08-15 11:53:36 <timlegge> what ever is agreed on also needs to get documented in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2021-08-15 11:55:12 <mps> so, we should discuss what should proper variable name for 'real/upstream package name' and what to do with all this mess of different var names
2021-08-15 13:32:25 <timlegge> mps: I have been thinking of doing a walk through each perl package and essentially doing a `apkbuild-cpan recreate` so that would take care of it - unfortunately - summer and  it would need commitment from people who can merge to review - it is a lot of work for everyone but I would prefer it not be a never-ending project.
2021-08-15 13:32:53 <timlegge> also, other than clean up the value is low
2021-08-15 13:33:42 <timlegge> but with APKBUILDs using the same "template version" apkbuild-cpan could be simplified too...
2021-08-15 13:35:34 <timlegge> I don't mind picking away at it over time but the next release of many CPAN modules is just this side of never so assuming it will take care of itself  is not a goog assumption either
2021-08-15 13:35:49 <timlegge> s/goog/good/
2021-08-15 13:38:14 <timlegge> these days to upgrade a perl module version I just do apkbuild-cpan recreate and review the diff so I always get the latest version - I do have to update apkbuild-cpan to address patches and the secfixes paragraphs though
2021-08-15 13:38:39 <donoban> hi, I don't understnad what happens with a MR, I pushed this branch with only 1 commit 
2021-08-15 13:39:24 <donoban> uhM, it works fine now I don't know what I was doing
2021-08-15 13:40:55 <timlegge> mps: ikke: that does bring up whether secfixes is a standard format and should be documented in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2021-08-15 13:56:46 <mps> timlegge: this will be 'big work' and I think we should start on it, but first to see what TSC and (religious) council have to say
2021-08-15 13:58:15 <mps> timlegge: about merging (and review) your work, I will do whenewer I have time and understand changes
2021-08-15 13:59:32 <mps> though in last time my 'work' on alpine shifts more to system tools and system server, anyway I still like to help keep perl in sane shape on alpine
2021-08-15 14:01:15 <valerius> perl is probably still the duct tape holding the internet together
2021-08-15 14:02:29 <mps> yes, for sure
2021-08-15 14:02:39 <mps> with C, ofc
2021-08-15 14:14:52 <ikke> Cogitri: mind if I merge !24089?
2021-08-15 14:15:38 <Cogitri> ikke: Sure, go ahead :)
2021-08-15 14:15:51 <ikke> 👍
2021-08-15 14:36:28 <timlegge> c is probably my favorite language.  I have not used it seriously in years but liked working with it.  I dabble in php and python on occasion but kind of like perl...
2021-08-15 14:38:03 <timlegge> mps: how does one attract the notice of the TSC and religious council without stakes and fires being involved :-)
2021-08-15 14:38:44 <ikke> My feeling is these things should be handled by the development team, not necessarily TSC
2021-08-15 14:38:58 <ikke> https://gitlab.alpinelinux.org/alpine/tsc
2021-08-15 14:39:01 <ikke> That's the TSC project
2021-08-15 14:39:57 <mps> timlegge: nice note, make me smile :)
2021-08-15 14:40:28 <mps> ikke: what is 'development team'?
2021-08-15 14:40:41 <ikke> https://gitlab.alpinelinux.org/team/developers
2021-08-15 14:40:47 <mps> all maintainers?
2021-08-15 14:41:49 <mps> ah nice, even algitbot is on team ;)
2021-08-15 14:42:02 <ikke> :)
2021-08-15 14:42:58 <mps> ok, dev team sounds as better idea to discuss this than TSC and council
2021-08-15 14:43:45 <ikke> The goal of the TSC is to coordinate between different teams
2021-08-15 14:44:25 <mps> what S in TSC means
2021-08-15 14:44:32 <ikke> steering
2021-08-15 14:45:13 <mps> good, I head fear that maybe is 'stupid' :D
2021-08-15 14:46:44 <mps> that is the problem with TLAs, people could interpret them differently
2021-08-15 14:49:37 <PureTryOut> uh why are the builders currently not even trying to get the source of communicator from upstream? It immediately resorts to distfiles.a.o but that one is outdated
2021-08-15 14:50:13 <ikke> Did upstream change?
2021-08-15 14:50:32 <ikke> If it's available on distfiles, it will use distfiles
2021-08-15 14:51:33 <PureTryOut> Upstream changed yes, and I updated the checksums
2021-08-15 14:51:50 <PureTryOut> I guess clearing distfiles would resolve it then no? Can you do that?
2021-08-15 14:52:32 <ikke> Was already doing that :)
2021-08-15 14:52:47 <PureTryOut> Thanks!
2021-08-15 15:07:04 <Ariadne> 9:45 AM <mps> good, I head fear that maybe is 'stupid' :D
2021-08-15 15:07:06 <Ariadne> well, i'm on it
2021-08-15 15:07:17 <Ariadne> so stupid is covered
2021-08-15 15:07:22 <Ariadne> haha just kidding
2021-08-15 15:10:37 <mps> Ariadne: I hope you understand jokes
2021-08-15 15:11:01 <mps> not intended to offend you (or anyone)
2021-08-15 15:11:43 <ikke> mps: Ariadne made one as well ;-)
2021-08-15 15:12:05 <veiviser> one could say ariadne was the joke (/s)
2021-08-15 15:12:11 <ikke> :)
2021-08-15 15:12:39 <Ariadne> btw, unless somebody wants to argue a good case otherwise, alpine 3.15 will be shipping gcc 10.4, not gcc 11
2021-08-15 15:13:02 <Ariadne> still many immediately-post-release bugfix commits
2021-08-15 15:13:03 <ikke> 3.14 is slated for november, I would say it's quite late
2021-08-15 15:13:05 <Ariadne> not confident :P
2021-08-15 15:13:43 <ikke> I don't think we are in a hurry to upgrade to 11?
2021-08-15 15:14:34 <mps> ikke: 3.14 is already released ;)
2021-08-15 15:14:40 <ikke> soprry, 3.15
2021-08-15 15:14:55 <mps> I know you know
2021-08-15 15:15:08 <Ariadne> maybe gcc 11 will finally be stable in 3.16 window
2021-08-15 15:15:11 <mps> Ariadne: re gcc, ok
2021-08-15 15:15:49 <mps> no need to upgrade if it have some problems, imo
2021-08-15 15:16:28 <Ariadne> we should apply that patch to the musl nextafter() routine submitted by that arrogant person :)
2021-08-15 15:16:36 <Ariadne> haha, just kidding on that one too
2021-08-15 15:17:33 <mps> from musl ML?
2021-08-15 15:17:38 <Ariadne> yes
2021-08-15 15:17:45 <mps> heh
2021-08-15 16:38:12 <Hello71> if we are low on mirror space, why don't we move some old releases to ancient.alpinelinux.org or some other "archived versions" location with less mirroring? imo debug symbols are much more useful than being able to install v3.0 from my preferred mirror
2021-08-15 16:38:25 <Hello71> also on a related note, ancient.alpinelinux.org is not working for me
2021-08-15 16:44:14 <wener> maybe another repo for debug
2021-08-15 16:46:40 <ikke> It's not only the mirrors, it's the builders as well
2021-08-15 16:46:54 <Ariadne> yes, the problem is mostly the builders themselves
2021-08-15 16:48:44 <wener> I mean make the debug symbols goes to another repo, if someone need it, just put it in apk/repositories, the builder split the -debug pkgs to that repo
2021-08-15 16:49:04 <ikke> wener: all packages live on the builders
2021-08-15 16:52:03 <Hello71> why is that?
2021-08-15 16:52:14 <wener> from my pov, I mirrored 2.4-3.14 without delete since about 3.10, just 1.8T, it's ok. if add debug to repo will double or triple the size, I would say no, like I opt out mirroring edge.
2021-08-15 16:52:40 <ikke> wener: if you have storage nodes, getting disk space is not that bad
2021-08-15 16:52:53 <ikke> but we have donated builders that just have a limited storage space
2021-08-15 16:54:32 <ikke> Hello71: the builder build a local repo, and install all packages from that repo, remove old packages, and that gets synced to the master mirror
2021-08-15 16:55:00 <wener> but -debug is only useful in some cases, quit useless in most cases.
2021-08-15 16:55:15 <Hello71> wener: trouble is knowing in advance which packages you need it for
2021-08-15 16:55:17 <ikke> yes, that's why we opted to not build it by default
2021-08-15 16:55:30 <ikke> only for certain packages
2021-08-15 16:57:24 <wener> it's better to have -debug, but should consider the size of it, like make it into another mirror repo
2021-08-15 16:57:50 <ikke> We keep talking in circles :)
2021-08-15 16:57:56 <wener> hahah
2021-08-15 16:58:32 <wener> but I can still opt out the -debug with rsync, so, it's ok to me.
2021-08-15 17:00:12 <Hello71> ikke: could this "local repo" actually be a network drive? aiui the i/o shouldn't be that much, since it is the repo, not the builddir
2021-08-15 17:03:04 <timlegge> mps: glad it made you smile.  so basically a RFC to the dev list for a change to APKBUILD docs to formally replace _pkgreal and others with a standardized variable name that hopefully will be self explanatory 
2021-08-15 17:04:35 <ikke> _pkgupstream would be descriptive and generic
2021-08-15 17:05:25 <timlegge> also worth a discussion whether modernizing the APKBUILD files (for perl if not for others) has enough value to start
2021-08-15 17:06:08 <timlegge> ikke: yes upstream is likely a good choice
2021-08-15 17:07:13 <timlegge> _upstreampkg reads better but starting with pks is likely fine
2021-08-15 17:07:35 <timlegge> s/pks/pkg/
2021-08-15 18:10:17 <andypost[m]> IIRC debug symbols could use compression so would be great to check size, -static also needs lots of space
2021-08-15 18:18:19 <Hello71> if compress before apk then it should increase size, not decrease
2021-08-15 18:18:22 <Hello71> apk is already compressed
2021-08-15 18:18:40 <Hello71> although unfortunately with gzip, which is not good for this kind of super-low-entropy content
2021-08-15 18:18:50 <Hello71> (too low window size)
2021-08-15 18:20:25 <ikke> perhaps with apk3 we can switch to different compression algorithms
2021-08-15 18:29:38 <Hello71> e.g. zstd -9 mesa-dbg shrinks from 198 MiB to 144 MiB taking about the same time as gzip -9
2021-08-15 18:31:11 <Hello71> but mesa-dri-gallium is 6.4 MiB to 5.9 MiB, much less
2021-08-15 18:32:03 <Hello71> zstd decompression is much faster than gzip though
2021-08-15 18:36:34 <Thermi> Did you think about using a package name scheme like Arch? E.g. apk.xz, instead of apk with implied gzip compression?
2021-08-15 18:39:22 <ericonr> does that actually help? since any tool should be able to detect the magic bits
2021-08-15 18:39:46 <ericonr> Ariadne: I hadn't looked at my inbox today yet, holy shit that discussion's gone to hell
2021-08-15 18:39:58 <Ariadne> :D
2021-08-15 18:40:17 <Ariadne> Thermi: apk3 describes the compression used in the container header
2021-08-15 18:40:39 <ericonr> also, it's always fun to see nsz flex, he knows a lot :o
2021-08-15 18:40:42 <Thermi> Ariadne, So it's not just plain tars with compression?
2021-08-15 18:41:18 <Ariadne> Thermi: apk-tools 3 introduces a new format, yes
2021-08-15 18:42:12 <Thermi> Ewww.
2021-08-15 18:42:17 <Ariadne> specifically, apk3 represents the package filesystem as a serialized object graph, in a way similar to a real filesystem
2021-08-15 18:43:07 <Ariadne> apk3 also introduces tools for unpacking and (re)packing apk3 images
2021-08-15 18:43:38 <Ariadne> the control tarball is replaced with proper structured data
2021-08-15 18:43:40 <Ariadne> it is a nice format
2021-08-15 18:43:47 <Ariadne> has been worked on for many years now :P
2021-08-15 18:43:52 <veiviser> Thermi: the madness shall continue until apk installs a whole standard in under 2 seconds
2021-08-15 18:46:29 <Ariadne> ericonr: yes i trust nsz, i do not trust some internet rando who cannot avoid throwing a tantrum
2021-08-15 18:48:25 <valerius> but tantrums are a sure sign of intelligence
2021-08-15 18:56:44 <Hello71> Ariadne: what are the advantages of this format compared to a .PKGINFO or similar file as the first entry in the tarball?
2021-08-15 18:57:01 <Ariadne> the advantages are: this is how we're doing it and apk-tools is not a democracy
2021-08-15 19:00:38 <Ariadne> sorry if you do not like my bluntness, but i'm not doing this bikeshed for a tenth time
2021-08-15 19:12:25 <Hello71> is there actual documentation? if you want people to stop asking about it then it would be useful to write it down somewhere (that people can find)
2021-08-15 19:15:45 <Hello71> i googled "alpine apk3" as well as several other related terms, and checked https://lists.alpinelinux.org/~alpine/devel/?search=apk3, and https://lists.alpinelinux.org/~alpine/apk-tools/
2021-08-15 19:16:42 <Hello71> apparently the correct procedure was to read https://lists.alpinelinux.org/~alpine/apk-tools/%3C20201006161032.77adf2a2%40vostro.wlan%3E, then check https://gitlab.alpinelinux.org/alpine/apk-tools/-/commits/v3.0-wip, then scroll down several pages, then open https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/7ccda091c2c7cf18225b861962f952dc04a5295f
2021-08-15 19:18:45 <ikke> Ariadne was working on documenting the format
2021-08-15 21:04:29 <mps> timlegge: ikke: _pkgupstream doesn't look good to me. I would that we name it with 'name' in new var name to reflect 'pkgname'
2021-08-15 21:05:14 <mps> _pkgupstreamname or _upstreampkgname or _realpkgname or just _pkgname
2021-08-15 21:05:35 <ikke> so _pkgupstreamname? :)
2021-08-15 21:06:24 <mps> hmm, _pkg_upstream_name :)
2021-08-15 21:06:36 <mps> to be more readable
2021-08-15 21:26:57 <danieli> still bikeshedding? :D
2021-08-15 21:27:38 <omni> _pkgUpStrm_nme
2021-08-16 05:34:33 <Thermi> Ariadne, can you take a hold of #12898? That's breaking bootstrap.sh right now and I spent my weekend on it and couldn't find a working fix for it.
2021-08-16 05:35:52 <Ariadne> what are you running bootstrap against
2021-08-16 05:36:08 <Ariadne> i’m pretty sure we fixed that for edge already by stopping it from building static libs
2021-08-16 05:36:13 <Ariadne> in bootstrap mode
2021-08-16 05:36:22 <Ariadne> maybe it was only done for riscv64 tho
2021-08-16 05:43:08 <Thermi> gcc pkgver is 10.3.1_git20210625
2021-08-16 05:44:04 <Thermi> I can't find any such commit stopping building any static libs
2021-08-16 07:16:37 <ncopa> good morning! I'm back
2021-08-16 07:25:39 <mps> good morning! welcome back :)
2021-08-16 07:32:19 <danieli> morning, wb
2021-08-16 08:43:16 <mps> ncopa: did you noticed akms (Alpine Kernel Module System) in repo? last #alpine-commits msgs reminded me
2021-08-16 08:44:41 <ncopa> yeah, i saw it. i havent tested it though
2021-08-16 08:45:21 <ikke> And it seems you cannot just install a package and have the module as an AKMS version. Seems it requires user interaction
2021-08-16 08:45:51 <ikke> The modules themselves are just distributed as source packages
2021-08-16 08:46:04 <mps> ikke: yes
2021-08-16 08:46:09 <ikke> So you cannot automatically migrate users
2021-08-16 08:46:21 <mps> it should be rebuilt with kernel upgrades
2021-08-16 08:46:22 <ikke> which means, we cannot just deprecated the current modules easily
2021-08-16 08:46:42 <ikke> mps: Yes, I understand the concept
2021-08-16 08:46:58 <ikke> but there is no <module>-akms package, but <module>-src
2021-08-16 08:47:29 <mps> hmm, I didn't looked yet deeply and didn't tried it
2021-08-16 08:47:54 <mps> don't have anything I need for now
2021-08-16 08:47:59 <ikke> https://github.com/jirutka/akms/blob/master/akms.8.adoc
2021-08-16 08:48:04 <ikke> I briefly looked into it
2021-08-16 08:48:17 <ncopa> at least it will minimize the need for adding new 3rd party modules
2021-08-16 08:48:21 <ncopa> hopefully
2021-08-16 08:48:50 <mps> I looked at docs and source, but 'didn't looked deeply', i.e. test on my machines
2021-08-16 08:48:57 <ikke> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rtw89-src
2021-08-16 08:49:20 <ikke> So: 1 install akms, 2. install *-src. 3. run akms install <module>
2021-08-16 08:49:37 <ikke> Which on it's own is not bad, but it means we cannot use apk to migrate users to akms
2021-08-16 08:49:46 <mps> that sounds as good starting 'point'
2021-08-16 08:50:54 <ikke> although, the trigger might automatically do that once the user installed akms
2021-08-16 08:51:33 <mps> yes, as I understand from docs triggers are needed to be installed for this
2021-08-16 08:52:12 <mps> maybe jirutka intentionally left this as a 'option', to follow alpine 'spirit'
2021-08-16 08:52:52 <ikke> There is a config option indeed
2021-08-16 08:55:40 <mps> nice, I should try to make one akms at least, and get real 'experience' with it
2021-08-16 09:00:25 <xsteadfastx> anyone maintaining a go package in alpine? how can i get rid of the src dir? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/463903
2021-08-16 09:03:35 <ikke> xsteadfastx: at to global: export GOFLAGS="-modcacherw"
2021-08-16 09:06:09 <xsteadfastx> perfect :)
2021-08-16 09:06:11 <xsteadfastx> thanks alot
2021-08-16 09:29:32 <ikke> xsteadfastx: ali is failing on 32-bits arches
2021-08-16 09:31:57 <xsteadfastx> mh... i will check the logs
2021-08-16 09:33:06 <xsteadfastx> oh noez. 64-bit atomic operation
2021-08-16 09:34:15 <ikke> Leo disabled them for now
2021-08-16 09:35:11 <ikke> sircmpwn: I noticed that the committed here here is dispatch@listserv.local: https://git.alpinelinux.org/aports/commit/?id=c2c43adfb692 Can we change that?
2021-08-16 09:35:26 <sircmpwn> what to?
2021-08-16 09:35:49 <sircmpwn> send the desired configuration to me in an email and it'll be added to my near-term todo list
2021-08-16 09:59:18 <xsteadfastx> it is so strange. it builds just fine with the go cross compiler.
2021-08-16 10:06:29 <xsteadfastx> if i could reproduce this on my laptop i could try to fix this
2021-08-16 10:43:35 <xsteadfastx> i will try to set something with qemu up
2021-08-16 15:59:20 <bl4ckb0ne> is qt5-qtbase missing a libexecinfo dep?
2021-08-16 15:59:48 <bl4ckb0ne> getting and undefined ref to backtrace_symbols when building the apk
2021-08-16 16:08:22 <Ariadne> try building with `abuild rootbld`, something from the host environment might be leaking through causing that
2021-08-16 17:16:45 <bl4ckb0ne> what is rootbld?
2021-08-16 17:19:32 <xordspar0> If I maintain a package in community, can I / should I update my package in older Alpine releases if the upstream makes a bugfix release?
2021-08-16 17:20:11 <ikke> bl4ckb0ne: it's an abuild subcommand
2021-08-16 17:20:35 <ikke> bl4ckb0ne: it builds the package in an isolated environment using chroot / bubblewrap
2021-08-16 17:20:55 <bl4ckb0ne> is that what's the CI is using?
2021-08-16 17:20:59 <ikke> no
2021-08-16 17:21:02 <ikke> that's using docker
2021-08-16 17:22:12 <bl4ckb0ne> fwiw it built fine
2021-08-16 17:37:28 <Hello71> xordspar0: alpine community repo is only supported for the latest release
2021-08-16 17:39:26 <xordspar0> Ok thanks, that sounds familiar.
2021-08-16 17:55:14 <Ariadne> for serious issues, we have done some CVE patches in community after release, but it is rare
2021-08-16 18:20:52 <Ariadne> i'm backporting GNU grep 3.7 to all releases because it fixes a performance and memory use regression
2021-08-16 18:21:33 <Ariadne> there's no CVE, but its annoying nonetheless
2021-08-16 18:43:28 <mps> Ariadne: yes, read today about this, nice that you will take this 'job' :)
2021-08-16 18:44:07 <mps> hmm, looks like Leo did it already
2021-08-16 18:44:11 <Ariadne> in edge
2021-08-16 18:44:16 <Ariadne> 3.13/3.14 needed it too
2021-08-16 18:44:30 <mps> I saw in 3.13 also
2021-08-16 18:44:37 <Ariadne> i'm going to apply for a CVE for this because i think this is an issue requiring CVE
2021-08-16 18:44:53 <mps> alpine/aports:3.13-stable | Leo | main/grep: upgrade to 3.7
2021-08-16 18:44:53 <craftyguy> can the gitlab bot notify me if someone makes a MR that modifies something I am a maintainer for?
2021-08-16 18:45:09 <Ariadne> mps: yes, that was me backporting his commit
2021-08-16 18:45:17 <mps> alpine/aports:3.14-stable | Leo | main/grep: upgrade to 3.7
2021-08-16 18:45:19 <Ariadne> i just cherrypicked it
2021-08-16 18:45:23 <Ariadne> look on git.a.o
2021-08-16 18:45:28 <mps> ah, ok
2021-08-16 18:45:48 <mps> hmm, why CVE?
2021-08-16 18:46:03 <craftyguy> I know it assigns MRs to alpine developers that are a maintainer. but for everyone else it's possible for patches to get merged without the maintainer knowing anything about it. seems unfair to agree to maintain something in alpine and then not have any control over how it's changed by literally anyone else
2021-08-16 18:46:04 <mps> does this have assigned CVE
2021-08-16 18:46:46 <mps> craftyguy: gitlab does this
2021-08-16 18:47:08 <craftyguy> mps: ?
2021-08-16 18:47:11 <Ariadne> mps: because scripts (think CGI for example) which use grep could hit this bug and then exhaust resources
2021-08-16 18:47:36 <mps> gitlab sends me mail whenever someone create MR for pkg I maintain
2021-08-16 18:47:37 <craftyguy> mps: I don't get notified at all when someone modifies a package I maintain. I usually find out about it much later
2021-08-16 18:48:06 <mps> craftyguy: then you should ask ikke 
2021-08-16 18:48:06 <Ariadne> craftyguy: not all package modifications happen via MR
2021-08-16 18:48:37 <craftyguy> Ariadne: many do, so at least getting notified about that would be better than nothing
2021-08-16 18:48:40 <mps> Ariadne: understand
2021-08-16 18:48:49 <mps> and this is right
2021-08-16 18:49:03 <Ariadne> though, i try to do only the minimum necessary to fix an issue via non-maintainer updates
2021-08-16 18:49:14 <Ariadne> if i am in your packages, it is probably to fix CVEs
2021-08-16 18:49:19 <Ariadne> and you probably want that, i would hope :p
2021-08-16 18:49:43 <craftyguy> yeah that stuff is fine
2021-08-16 18:50:17 <mps> Ariadne: for me personally is not much important, I can revert if I don't agree with change :)
2021-08-16 18:50:27 <craftyguy> but like anyone can show up and change anything I maintain in any way they want, and if it's merged by y'all, then I'm suddenly responsible for it because I maintain the package
2021-08-16 18:51:04 <mps> Ariadne: but usually I agree with your work, except I like to annoy sometimes here ;)
2021-08-16 18:51:05 <Ariadne> yes, as i've said before, we need a better system for delegating consent for NMUs
2021-08-16 18:51:43 <craftyguy> sorry if you've said it before, I don't read the full backlog here :P
2021-08-16 18:55:39 <Ariadne> mps: anyway, i think MITRE is unlikely to issue a CVE for it
2021-08-16 18:55:46 <Ariadne> though it really should have one
2021-08-16 18:57:32 <mps> yes, 'CVE not assigned'
2021-08-16 19:02:30 <Ariadne> well, the world we are going to, the CVE database will just be one of many :p
2021-08-16 19:06:57 <ikke> any progress regarding linked data?
2021-08-16 19:07:05 <bl4ckb0ne> is there a way to install a built packages on the CI to build a dep and then the package?
2021-08-16 19:07:37 <ikke> bl4ckb0ne: sorry, I'm not following?
2021-08-16 19:07:54 <bl4ckb0ne> i have 2 packages in the same merge request
2021-08-16 19:08:08 <bl4ckb0ne> a package and its dependency, both are being bumped
2021-08-16 19:08:28 <ikke> packages built in CI are available
2021-08-16 19:08:32 <Ariadne> ikke: yes, a lot of progress now that we gave up on getting google's OSV team on board ;)
2021-08-16 19:08:35 <bl4ckb0ne> https://gitlab.alpinelinux.org/bl4ckb0ne/aports/-/jobs/464079
2021-08-16 19:09:18 <ikke> That's something different
2021-08-16 19:09:23 <ikke> cmd:glslangValidator (virtual):
2021-08-16 19:09:28 <ikke> provided by: glslang
2021-08-16 19:09:35 <ikke> required by: .makedepends-gulkan-20210816.185327[cmd:glslangValidator]
2021-08-16 19:09:41 <ikke> Not sure why APK cannot select it
2021-08-16 19:10:05 <ikke> I see issues more often with cmd: 
2021-08-16 19:11:11 <ikke> Ariadne: any idea why apk is not cooporating there?
2021-08-16 19:11:42 <Ariadne> i suspect its the virtual that is causing the problem
2021-08-16 19:12:18 <Ariadne> i will try to make a testcase
2021-08-16 19:12:20 <ikke> Ariadne: is it because the cmd: packages do not have a version?
2021-08-16 19:12:22 <bl4ckb0ne> should I just like it to glslang
2021-08-16 19:12:25 <ikke> I see it happening with upgrades
2021-08-16 19:12:32 <Ariadne> ikke: yes, i think so
2021-08-16 19:12:41 <Ariadne> ikke: maybe we should version the cmd: provider
2021-08-16 19:13:21 <Ariadne> default provider_priority is 0, which shortcircuits that
2021-08-16 19:13:34 <Ariadne> yes, we should change abuild to version the cmd: provider
2021-08-16 19:13:36 <Ariadne> :)
2021-08-16 19:13:39 <ikke> ok
2021-08-16 19:14:13 <ikke> bl4ckb0ne: for now, that's the best way to solve your issue
2021-08-16 19:14:52 <bl4ckb0ne> ty
2021-08-16 19:20:39 <bl4ckb0ne> cmd:glslang (no such package):
2021-08-16 19:20:41 <bl4ckb0ne>     required by: .makedepends-gulkan-20210816.191639[cmd:glslang]
2021-08-16 19:20:59 <bl4ckb0ne> could I just remove the cmd: ?
2021-08-16 19:21:01 <ikke> yes
2021-08-16 19:21:07 <ikke> just glslang
2021-08-16 19:25:01 <Ariadne> .provides-pc should also be versioned
2021-08-16 19:25:25 <Ariadne> i think it is not because freedesktop pkg-config did not have the ability to generate that output
2021-08-16 19:25:34 <Ariadne> but, i do not think we will ever use freedesktop pkg-config again :)
2021-08-16 19:25:53 <ikke> is that where the provides-pc was for?
2021-08-16 19:26:06 <bl4ckb0ne> got some green on the pipeline o/
2021-08-16 19:27:41 <Ariadne> .provides-pc is for generating the pc: provides yes
2021-08-16 19:34:55 <Ariadne> 's/$/='"$pkgver"'-r'"$pkgrel"'/'
2021-08-16 19:35:03 <Ariadne> shell quoting, not even once
2021-08-16 19:36:46 <Ariadne> nanabozho:~/abuild$ echo foobar | sed -e 's/^/provides = cmd:/' -e 's/$/='"$pkgver"'-r'"$pkgrel"'/'
2021-08-16 19:36:46 <Ariadne> provides = cmd:foobar=1.2.3-r0
2021-08-16 19:38:51 <Hello71> tbf you'd be find here with "" around the whole thing and just escaping the $
2021-08-16 19:39:14 <Ariadne> yes
2021-08-16 19:39:25 <Hello71> ... fine
2021-08-16 19:40:21 <Hello71> the bigger problem with sed is there's no (reasonably easy) way to provide a literal string
2021-08-16 19:54:23 <Ariadne> ikke: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/115/diffs
2021-08-16 19:56:53 <ikke> 👍
2021-08-16 20:54:28 <bl4ckb0ne> getting 502 when uploading artifacts
2021-08-16 20:55:26 <ikke> ppc64le is acting up
2021-08-16 20:55:34 <ikke> network issues, not sure what to do about it
2021-08-16 20:55:49 <ikke> well, I was thinking just skipping artifacts for ppc64le
2021-08-16 20:56:08 <bl4ckb0ne> ppc64le indeed, ill stop it
2021-08-16 20:56:30 <bl4ckb0ne> PureTryOut: minus ppc64le, !22880 is up for review
2021-08-16 20:57:56 <PureTryOut> 👍️ will look into it tomorrow, thanks!
2021-08-16 20:58:29 <bl4ckb0ne> np
2021-08-16 21:31:19 <ikke> go 1.17 is released
2021-08-16 21:31:23 <ikke> https://blog.golang.org/go1.17
2021-08-16 21:44:34 <mps> 
ACTION don't care for this useless lang :)

2021-08-16 21:44:44 <ikke> I know\
2021-08-16 21:44:50 <ikke> :P
2021-08-16 21:45:24 <mps> (and remembering time when I praised it and talked with author :) )
2021-08-16 21:46:00 <mps> joke aside, it is good for some tasks
2021-08-16 21:46:36 <mps> just don't like where its 'eccosystem' went
2021-08-16 21:47:29 <mps> I left community when CoC is added there
2021-08-16 21:49:32 <mps> these days I'm contemplating port worse lang called dart to musl (flutter is key word)
2021-08-16 21:49:50 <veiviser> what's wrong with the go coc
2021-08-16 21:50:13 <mps> veiviser: every CoC is 'bad thing'
2021-08-16 21:50:25 <veiviser> i see
2021-08-16 21:51:23 <mps> when I joined alpine I didn't know that it exists also 'in' alpine
2021-08-16 21:52:56 <mps> but luckily didn't saw it is ever 'called' in alpine channels or ML
2021-08-16 22:12:47 <Ariadne> tbh i am considering proposing deprecating the CoC, as it has outlived its usefulness
2021-08-16 22:13:15 <Ariadne> it is no longer discussed, because the 'systemd is a jewish plot for world domination' crowd showed themselves the door
2021-08-16 22:15:23 <meph> (33/51) Upgrading linux-firmware-ath11k (20210511-r0 -> 20210716-r0)
2021-08-16 22:15:23 <meph> ERROR: linux-firmware-ath11k-20210716-r0: BAD signature
2021-08-16 22:15:23 <meph> ERROR: Failed to create lib/firmware/ath11k/QCA6390/hw2.0/amss.bin: Connection aborted
2021-08-16 22:15:27 <meph> getting this on edge
2021-08-16 22:15:37 <meph> ppc64le
2021-08-16 22:15:51 <Ariadne> ppc64le is basically totally FUBAR
2021-08-16 22:16:03 <meph> rip
2021-08-16 22:16:14 <Ariadne> the build server kind of caught fire
2021-08-16 22:16:19 <meph> lmao oof
2021-08-16 22:16:22 <Ariadne> and then we were moved to IBM Cloud
2021-08-16 22:16:35 <Ariadne> and now we are moving to another server
2021-08-16 22:17:02 <Ariadne> so, who honestly knows
2021-08-16 22:17:08 <Ariadne> that package could be totally corrupt
2021-08-16 22:17:13 <meph> well hopefully it gets fixed at some point
2021-08-16 22:17:15 <Ariadne> you could also be out of disk space
2021-08-16 22:17:25 <Ariadne> i've never seen "Connection aborted" from apk before :D
2021-08-16 22:17:45 <meph> /dev/sda4                15.7G      2.9G     12.0G  20% /
2021-08-16 22:18:11 <meph> on the host
2021-08-16 22:18:11 <meph> /dev/mapper/internal-home    787G   59G  689G   8% /home
2021-08-16 22:18:34 <meph> yeah odd
2021-08-16 22:19:33 <Ariadne>                 /* If inner stream returned zero (end-of-stream), we
2021-08-16 22:19:33 <Ariadne>                  * more was to be expected. */
2021-08-16 22:19:33 <Ariadne>                  * are getting short read, because tar header indicated
2021-08-16 22:19:33 <Ariadne>                 if (r == 0) r = -ECONNABORTED;
2021-08-16 22:19:38 <Ariadne> corrupted package, probably
2021-08-16 22:19:45 <meph> nice
2021-08-16 22:20:48 <Ariadne> i suspect we will need to resync the entire ppc64le package set
2021-08-16 22:21:01 <Ariadne> what mirror are you using?
2021-08-16 22:21:32 <meph> http://sjc.edge.kernel.org/alpine/edge/
2021-08-16 22:22:12 <Ariadne> hmm, that one is reliable
2021-08-16 22:22:28 <Ariadne> yeah i am going to say some packages are fucked
2021-08-16 22:23:13 <meph> well i guess I'll just remove linux-lts and rebuild the firmware myself
2021-08-16 22:24:14 <Ariadne> possibly an option for now
2021-08-16 22:24:28 <Ariadne> though you might try a different mirror
2021-08-16 22:24:30 <Ariadne> just to be safe
2021-08-16 22:27:39 <meph> >>> linux-firmware-none*: Package size: 4.0 KB
2021-08-16 22:27:41 <meph> wat
2021-08-16 23:30:42 <afontain[m]> meph sounds about right
2021-08-16 23:30:55 <afontain[m]> it's an empty package
2021-08-16 23:32:07 <afontain[m]> the purpose of this package is to avoid installing linux-firmware instead, and since linux-firmware depends on every firmware package, it causes quite some megabytes to be installed.
2021-08-16 23:32:55 <afontain[m]> (and it would be installed automatically since linux-firmware is a dep of linux-lts)
2021-08-17 05:57:23 <ikke> go 1.17 has a test failure on ppc64le: "FATAL: ThreadSanitizer CHECK failed: ./gotsan.cpp:14506 "((personality(old_personality | ADDR_NO_RANDOMIZE))) != ((-1))" (0xffffffffffffffff, 0xffffffffffffffff)"
2021-08-17 06:00:11 <Ariadne> :D
2021-08-17 06:01:01 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/464396
2021-08-17 07:18:31 <xsteadfastx> if soemthing doesnt have a proper release so far.... i should use the date as version number?
2021-08-17 07:20:50 <ikke> 0_git<date>
2021-08-17 07:21:07 <ikke> That way, as soon as they get a proper release, it will be considered newer
2021-08-17 07:21:50 <xsteadfastx> brilliant... thanks :)
2021-08-17 09:35:03 <mps> !24312 would someone review
2021-08-17 10:04:43 <donoban> with last upgrades I get a conflict between polkit-libs-0.119-r1 and polkit-elogind-libs-0.119-r0 
2021-08-17 10:04:57 <donoban> ERROR: polkit-libs-0.119-r1: trying to overwrite usr/lib/libpolkit-agent-1.so.0 owned by polkit-elogind-libs-0.119-r0.
2021-08-17 10:05:26 <donoban> is this expected? shoud I uninstall one of them?
2021-08-17 10:07:30 <donoban> well, they come as dependencies of other packages
2021-08-17 11:05:47 <ncopa> i got the same conflict
2021-08-17 11:05:54 <ncopa> and i think my xfce4-polkit broke
2021-08-17 12:25:45 <PureTryOut> I noticed that too, seems to happen because of a commit of mine. I'm looking into it atm
2021-08-17 12:26:15 <PureTryOut> To clarify, if polkit-elogind-libs is currently installed and it's trying to install polkit-libs, that's wrong. You should keep polkit-elogind-libs
2021-08-17 13:37:42 <PureTryOut> Hmm something is wrong with the APKINDEX.tar.gz on aarch64, it's outdated compared to the packages it has in the repo
2021-08-17 13:37:59 <PureTryOut> E.g. it refers to polkit-elogind=0.119-r1 while the repo has polkit-elogind=0.119-r2
2021-08-17 14:48:45 <Hello71> ncopa: if you have some time can you review https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54? it is blocking qt5 debug symbols
2021-08-17 16:11:28 <ikke> PureTryOut: compare
2021-08-17 16:11:29 <ikke> curl -Ssf https://dl-master.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz | tar xz -O APKINDEX | grep -x -A1 P:polkit-elogind
2021-08-17 16:11:44 <ikke> curl -Ssf https://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz | tar xz -O APKINDEX | grep -x -A1 P:polkit-elogind
2021-08-17 16:11:52 <ikke> (sorry, first one without https)
2021-08-17 17:08:19 <mps> where can I find new CVEs assigned to some software
2021-08-17 17:09:20 <ikke> https://cve.mitre.org/cve/search_cve_list.html?
2021-08-17 17:09:37 <mps> uhm, pkg description is 'CVE ID         : not yet assigned'
2021-08-17 17:10:15 <mps> will push without CVE, hope our security when it will be assigned
2021-08-17 17:10:31 <ikke> what package?
2021-08-17 17:10:58 <mps> haproxy
2021-08-17 17:17:46 <ikke> I guess they are still waiting for the CVE assignment
2021-08-17 17:18:46 <mps> yes I think same, but I think I will not wait for them to push upgrades
2021-08-17 17:19:01 <mps> !24321
2021-08-17 17:19:04 <ikke> nope, we can add it later
2021-08-17 17:22:06 <mps> except if gitlab doesn't make me crazy :/
2021-08-17 17:33:39 <mps> hmm, something I expected, 3.12 have upstream unmaintained haproxy version - 2.1.12
2021-08-17 17:34:12 <mps> what to do? backport from 3.13-stable sounds most reasonable?
2021-08-17 17:34:23 <mps> ncopa: ^
2021-08-17 17:34:42 <mps> Ariadne: ikke: ^
2021-08-17 17:35:07 <ikke> mps: Any backwards incompattibilities?
2021-08-17 17:35:21 <mps> heh, who knows
2021-08-17 17:35:46 <mps> we could expect some minor config changes
2021-08-17 17:35:51 <PureTryOut> ikke: yeah second one is out of date
2021-08-17 17:36:54 <mps> picking security patches from newer version also seems too risky
2021-08-17 17:37:24 <Ariadne> mps: figure out about incompatibilities i guess
2021-08-17 17:37:33 <mps> (going to make coffee and wait for ncopa and Ariadne answer)
2021-08-17 17:37:49 <mps> eh, you are fast
2021-08-17 17:37:50 <Ariadne> if there are incompatibilities we don’t want to upgrade it
2021-08-17 17:38:37 <mps> with every haproxy major upgrade there are some config incompatibities
2021-08-17 17:39:12 <Hello71> move to community?
2021-08-17 17:39:48 <mps> Hello71: that was idea some time ago but not sure was it good
2021-08-17 17:41:24 <mps> coffee waits
2021-08-17 17:43:20 <ikke> Hello71: the issue was that it was upgraded to a non-lts version
2021-08-17 17:44:21 <ikke> 2.0.24, 2.2.16, 2.3.13 and 2.4.3 all received updates
2021-08-17 17:44:26 <ikke> just 2,1,x not
2021-08-17 17:47:55 <Ariadne> upgrade to 2.2.16 i guess
2021-08-17 17:50:20 <mps> ikke: yes, remember that I was grumpy about that upgrade
2021-08-17 17:51:29 <mps> Ariadne: that looks most proper to do, but I don't like again to argue with ncopa
2021-08-17 17:52:10 <Ariadne> do you want the security team to do it? :P
2021-08-17 17:52:16 <ikke> mps: all to well :P
2021-08-17 17:52:20 <mps> hehe
2021-08-17 17:52:48 <ikke> In general, ncopa indicated he prefered to use released version, avoid patching ourselves when possible
2021-08-17 17:52:52 <mps> Ariadne: ok, will risk another round with ....
2021-08-17 17:59:31 <Hello71> ah, i think i remember this discussion
2021-08-17 18:02:20 <mps> and about squid ;)
2021-08-17 18:26:51 <Guest4178> !24317 is very interesting, can reduce the dependency graph as more core projects adopt meson
2021-08-17 18:37:03 <mps> uhm, nice https://tpaste.us/YEYz :/
2021-08-17 18:37:43 <mps> did something changed of default build options in 3.14 in last two months
2021-08-17 18:40:06 <bl4ckb0ne> Guest4178: muon is not 1:1 with meson
2021-08-17 18:40:14 <Guest4178> i know
2021-08-17 18:48:06 <mps> uhm found issue, 'don't use CFLAGS'
2021-08-17 18:48:40 <mps> anyone tried new haproxy?
2021-08-17 18:55:17 <ericonr> mps: 	/* Catch forced CFLAGS that miss 2-complement integer overflow */ if (intovf + 0x7FFFFFFF >= intovf) {
2021-08-17 18:58:02 <mps> ericonr: I solved it by removing CFLAGS from make
2021-08-17 18:58:37 <mps> and as bonus build is now clean, without any warning
2021-08-17 18:58:42 <ericonr> the commit kinda makes sense, apparently their logic depends on -fwrapv
2021-08-17 19:00:11 <mps> changelog says ' BUILD: add detection of missing important CFLAGS'
2021-08-17 19:01:15 <mps> it now correctly works on my test server
2021-08-17 19:02:18 <mps> CFLAGS on alpine must be artifact when haproxy didn't supported musl
2021-08-17 19:04:11 <mps> waiting for problem confirmation from someone before pushing change to builders
2021-08-17 19:30:49 <betajinx> Hi All! I was wondering if it's possible to build an alpine image you've been working on into an ISO? I'm using packer to build the image into an AMI on AWS but am unable to turn it into an ISO
2021-08-17 19:43:45 <mps> ikke: if you have time !24335, do you have comment about git commit message there
2021-08-17 19:44:17 <mps> (why I ask you? because I respect your opinion)
2021-08-17 19:48:17 <ikke> mps: maybe the subject: 'don't override CFLAGS in make'?
2021-08-17 19:49:12 <mps> ok, will change
2021-08-17 19:51:05 <mps> thank you
2021-08-17 20:21:55 <tomalok> betajinx: #alpine-cloud - we have base AMI images at https://alpinelinux.org/cloud - and are working on expanding what we got to other clouds, adding cloud-init enabled images, etc.
2021-08-17 20:22:29 <tomalok> looks like that PSA came too late, they've already left
2021-08-17 20:29:55 <Ariadne> bl4ckb0ne: samurai is not 1:1 with ninja, either
2021-08-17 20:32:04 <Hello71> #12728
2021-08-17 20:53:44 <ericonr> fwiw you supposedly need ninja for C++ modules builds
2021-08-17 22:06:21 <Ariadne> 
ACTION is generally not in favor of #12728

2021-08-17 22:06:36 <Ariadne> better to just add the missing graph feature to samurai
2021-08-17 22:11:11 <Ariadne> mcf: what do you think about `-t graph`
2021-08-17 22:15:51 <mcf> i'm not opposed. should be pretty trivial to implement
2021-08-17 22:17:23 <Ariadne> i can work on that and `-t deps` tomorrow
2021-08-17 22:18:25 <Hello71> yes, that's what i was thinking too
2021-08-17 22:18:58 <danieli> in some cases samurai isn't ninja enough, and either way, i don't see why users can't make the choice themselves
2021-08-17 22:19:03 <Hello71> i looked into implementing it by post-processing -t targets but it seemed nontrivial
2021-08-17 22:19:43 <Ariadne> danieli: if it comes back, developers will not test their builds with samurai
2021-08-17 22:20:21 <Ariadne> we do not let people choose pkg-config either
2021-08-17 22:20:40 <Ariadne> sometimes, the only way to make forward progress is to make some firm decisions
2021-08-17 22:20:45 <ericonr> If you're looking to the future, someone has to remove gtk2 from graphviz too ;p
2021-08-17 22:21:07 <danieli> ref the issue, samurai will still be the default - and samurai does claim it's ninja compatible (for the most part)
2021-08-17 22:21:47 <danieli> i'm just not in favor of unnecessarily making choices for users and not leaving any choice
2021-08-17 22:21:56 <Ariadne> ref the issue, i would want it in writing that anyone is authorized to NMU a package that fails to build with samurai
2021-08-17 22:21:57 <danieli> er, i phrased that poorly, but you get the point
2021-08-17 22:22:33 <Ariadne> also, the solution in #12728 is a poor one, it would be better to add alternatives system to `apk`
2021-08-17 22:22:54 <danieli> it would, but that's a bit of a pandora's box, it has to be done properly and unambiguously from the get-go
2021-08-17 22:23:28 <Ariadne> the only value of #12728 to me, is seeing what ninja does so that things can be implemented in samurai
2021-08-17 22:23:31 <danieli> it's a mess in debian derivatives, iirc arch moves symlinks around
2021-08-17 22:24:18 <Ariadne> but really, it will become a problem for alpine
2021-08-17 22:24:30 <Ariadne> because, again, developers will not test their shit
2021-08-17 22:24:55 <Ariadne> and the ninja developer does not care about distributions
2021-08-17 22:25:15 <Ariadne> the whole reason we use samurai is because we can configure it to not demolish our build servers
2021-08-17 22:25:37 <Ariadne> ninja meanwhile is like "oh, you have 256 cpu cores?  great!"
2021-08-17 22:26:03 <Ariadne> like, fundamentally, i'd rather ninja just stay out of alpine
2021-08-17 22:26:13 <danieli> it's up to you, but i'm iffy about 1) intentionally leaving a commonly used build tool broken and 2) not giving users a choice
2021-08-17 22:26:33 <Ariadne> i'm not in favor of leaving a build tool broken
2021-08-17 22:26:39 <Ariadne> if samurai is missing something, we should add it
2021-08-17 22:27:05 <Ariadne> but, we should focus on what is missing *in the real world*
2021-08-17 22:27:15 <Ariadne> if people need `-t deps` and `-t graph`, we should add these things
2021-08-17 22:29:15 <Ariadne> danieli: for example, pkgconf is also 'mostly compatible' with pkg-config, but we changed some things because they made sense to change in the context of alpine.  that's basically my take on samurai vs ninja
2021-08-17 22:30:02 <ericonr> Ariadne: does ninja not respect -j in some situations or something?
2021-08-17 22:30:16 <Ariadne> ericonr: samurai allows configuration via environment
2021-08-17 22:30:44 <Ariadne> ericonr: ninja does not
2021-08-17 22:31:44 <Ariadne> we explicitly requested this of ninja, the ninja maintainer told us no
2021-08-17 22:31:50 <Ariadne> so, we switched to samurai
2021-08-17 22:44:42 <ericonr> Ariadne: to export it once and not have to add an arg in all APKBUILDs?
2021-08-17 23:51:19 <orbea> if you are adding things samurai is missing this would be nice too :) https://github.com/michaelforney/samurai/issues/36
2021-08-17 23:58:59 <valerius> I like the idea of adding to samurai vs going back to packaging ninja
2021-08-18 02:54:16 <orbea> ericonr: ninja developers expect users to use an alias or wrapper script instead of them implementing something like NINJAFLAGS because environment variables are bad or something
2021-08-18 07:26:44 <Thermi> ncopa, can you review https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/111 112 and 113 for me please?
2021-08-18 09:38:03 <rnalrd> ikke, FYI soon I'm going to push a fix for zabbix-agent2 (that reverts the commit introducing the problem) regarding https://support.zabbix.com/browse/ZBX-19614
2021-08-18 09:38:56 <rnalrd> currently testing it locally
2021-08-18 09:39:14 <ikke> rnalrd: 👍
2021-08-18 09:44:34 <nmeum> mps: are you frequently using u-boot with arm boards? if so: do you just create a ulimage from /boot/vmlinux manually on each kernel update with mkimage from u-boot-tools or what's your workflow in this regard?
2021-08-18 10:04:02 <fcolista> is Leo (thinkabit) around here?
2021-08-18 10:04:29 <fcolista> I wonder why he removed hexchat from community
2021-08-18 10:04:35 <fcolista> commit f4fccd26eaa896b944f056ab71c6f55412198c16
2021-08-18 10:04:58 <fcolista> we still have gtk2 
2021-08-18 10:05:19 <fcolista> I think that this commit should be reverted.
2021-08-18 10:05:57 <fcolista> commit links at a long discussion in hexchat forum : https://github.com/hexchat/hexchat/issues/2047
2021-08-18 10:06:33 <ikke> Maxice8 is not here, hasn't been for a while
2021-08-18 10:06:59 <fcolista> anyway imho does not make much sense to remove hexchat
2021-08-18 10:07:09 <fcolista> btw, I'm still using it in alpine...
2021-08-18 10:11:12 <mps> nmeum: not sure I understand your question. I usually 'dd' u-boot for board on mmc and create boot partition where I put kernel, initramfs and extlinux.conf
2021-08-18 10:11:32 <mps> didn't used boot.scr for long time
2021-08-18 10:13:12 <nmeum> ah, so you use u-boot in conjunction with extlinux?
2021-08-18 10:13:15 <mps> fcolista: yes, instead of zealously trying to remove gtk2 and similar, imo would be better to remove pulseaudio and pipewire ;)
2021-08-18 10:13:34 <nmeum> because u-boot itself can only boot ulimages and not the vmlinuz images we ship with our kernel package /vmlihttps://www.denx.de/wiki/view/DULG/HowCanICreateAnUImageFromAELFFile
2021-08-18 10:13:41 <nmeum> https://www.denx.de/wiki/view/DULG/HowCanICreateAnUImageFromAELFFile
2021-08-18 10:14:01 <nmeum> at least that's my current understanding
2021-08-18 10:14:28 <mps> nmeum: hmm, I think u-boot loads quite fine vmlinuz
2021-08-18 10:15:18 <mps> from extlinux.conf on my armv7 server 'KERNEL /vmlinuz-edge'
2021-08-18 10:15:38 <mps> and 'INITRD /initramfs-edge'
2021-08-18 10:17:09 <mps> and (as bonus) 'FDTDIR /dtbs-edge'
2021-08-18 10:18:25 <nmeum> I will look into extlinux.conf, thanks. I am presently still booting "manually" using fatload/booti
2021-08-18 10:18:45 <mps> ah, understand
2021-08-18 10:19:57 <mps> long ago I switched to extlinux to have boot menu where can select which kernel to boot with different options (for tests) and to have rescue kernel ready
2021-08-18 10:20:31 <nmeum> yeah, I am working on hifive unmatched support and thus didn't do the full u-boot stack with extlinux.conf yet
2021-08-18 10:20:34 <mps> nmeum: btw !24350 is ok for me
2021-08-18 10:20:54 <nmeum> sweet :)
2021-08-18 10:21:59 <nmeum> mps: I think one problem though is that u-boot-spl.bin is now also included in the package for other boards for example u-boot-cuboxi
2021-08-18 10:22:09 <nmeum> see the checkapk output
2021-08-18 10:22:09 <mps> I started to search for riscv64 board to buy, not sure will I find it soon here in Serbia
2021-08-18 10:22:44 <nmeum> if we don't want to ship u-boot-spl.bin for other boards the split function needs a riscv64/unmatched specific case-distinction
2021-08-18 10:23:04 <mps> nmeum: I will look, right now I'm 'on the road'
2021-08-18 10:23:18 <nmeum> sure, take your time
2021-08-18 10:23:53 <nmeum> I am currently mostly using a self-compiled u-boot version from u-boot master branch anyhow as the latest u-boot release still seems to be missing some fixes for the unmatched
2021-08-18 10:23:54 <mps> nmeum: yes, SPL is needed for most boards, afaik
2021-08-18 10:26:08 <mps> anyway, I'm testing riscv with qemu using u-boot-qemu pkg
2021-08-18 10:26:42 <mps> and it still doesn't boot though it loads kernel and initram
2021-08-18 10:28:11 <mps> maybe I will have more time because decided to not try (and buy yet another) apple M1, don't want to waste time on such closed thing from bad company
2021-08-18 10:42:28 <PureTryOut> ikke: are you here? Yes that command you gave me confirms the APKINDEX of aarch64 is out of date on dl-cdn
2021-08-18 10:51:13 <ikke> PureTryOut: I'm here
2021-08-18 10:54:03 <PureTryOut> Great 👍️ As I said, the APKINDEX is definitely out of date of aarch64 on dl-cdn, edge
2021-08-18 10:54:19 <PureTryOut> The package however is uploaded
2021-08-18 10:54:56 <ikke> curl -Ssf http://dl-t1-1.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz | tar xz -O APKINDEX | grep -x -A1 P:polkit-elogind
2021-08-18 10:55:01 <ikke> that's one of the back-end for dl-cdn
2021-08-18 10:55:06 <ikke> which is also out-of-date
2021-08-18 10:56:19 <nmeum> mps: which package ships the /dtbs-edge from your extlinux.conf?
2021-08-18 10:57:54 <mps> nmeum: linux-edge
2021-08-18 10:58:12 <mps> and linux-lts have dtbs-lts
2021-08-18 10:59:09 <veiviser> linux-edge is also seemingly out of date in the apkindex on aarch64, 5.13.10 in the index and .12 on the mirrors
2021-08-18 10:59:10 <mps> nmeum: look here how i install alpine on armv7 sbc https://arvanta.net/alpine/install-alpine-armv7-sbc/
2021-08-18 10:59:20 <PureTryOut> ikke: yeah can confirm
2021-08-18 10:59:38 <ikke> PureTryOut: aha
2021-08-18 10:59:40 <ikke> rsync bug
2021-08-18 10:59:53 <PureTryOut> Of course 😛 Please don't say it's the same one as on ppc64le
2021-08-18 11:00:01 <ikke> it is
2021-08-18 11:00:04 <veiviser> hahah
2021-08-18 11:00:17 <mps> nmeum: look part in script where extlinux.conf is created
2021-08-18 11:00:21 <nmeum> mps: I can't seem to find dtbs-edge in linux-edge
2021-08-18 11:00:32 <nmeum> > tar -tvf linux-edge-5.13.12-r0.apk  | grep dtbs | wc -l
2021-08-18 11:00:35 <nmeum> > 0
2021-08-18 11:00:45 <mps> hmm, strange
2021-08-18 11:00:47 <ikke> PureTryOut: I've upgraded rsync, lets see if it resolves that
2021-08-18 11:00:55 <PureTryOut> 👍️
2021-08-18 11:01:03 <mps> will check when I come back
2021-08-18 11:01:58 <mps> but it should be as 'boot/dtbs-edge'
2021-08-18 11:02:13 <nmeum> ahhhh
2021-08-18 11:02:19 <ikke> PureTryOut: in 15 minutes, it should be fixed
2021-08-18 11:02:27 <nmeum> I downloaded the wrong linux-edge version
2021-08-18 11:02:29 <PureTryOut> Great, thanks!
2021-08-18 11:02:30 <nmeum> the one for x86_64
2021-08-18 11:02:31 <nmeum> oopssi!
2021-08-18 11:02:40 <nmeum> sorry for the noise
2021-08-18 11:02:44 <mps> aha
2021-08-18 11:02:47 <mps> np
2021-08-18 11:03:23 <nmeum> does apk fetch not consult --arch?
2021-08-18 11:03:45 <ikke> no
2021-08-18 11:03:55 <ikke> --arch is only usefull with --root
2021-08-18 11:04:09 <ikke> (ie, when creating a new chroot)
2021-08-18 11:04:28 <nmeum> I used it with --root in the past but I was unware that it's not an option to apk fetch, my bad i guess
2021-08-18 11:04:29 <mps> hmm, learned something new
2021-08-18 11:05:37 <nmeum> would be neat to add that to apk-tools :D
2021-08-18 11:06:04 <mps> sure
2021-08-18 11:06:58 <Hello71> ikke: although apk-tools doesn't yell at you for it... https://gitlab.alpinelinux.org/alpine/aports/-/issues/12905
2021-08-18 11:07:34 <nmeum> yep, that's what confused me
2021-08-18 11:07:56 <nmeum> I will propose making fetch respect --arch in the issue tracker
2021-08-18 11:08:19 <Hello71> while you're at it, make apk add --arch without --root fail
2021-08-18 11:08:58 <ikke> yes, otherwise it would introduce a new set of issues
2021-08-18 11:11:14 <nmeum> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10761
2021-08-18 11:21:22 <mps> on my aarch64 mosh randomly segfaults. I think this is related to protobuf bug. who is maintainer of protobuf?
2021-08-18 11:22:00 <mps> ahm, BDFL
2021-08-18 11:26:36 <nmeum> mps: the vanilla riscv64 linux-edge config seems to be good enough to boot on the hifive unmatched :)
2021-08-18 11:26:48 <nmeum> >     0.000000] Linux version 5.13.10-0-edge (buildozer@build-edge-riscv64) (gcc (Alpine 10.3.1_git20210625) 10.3.1 20210625, GNU ld (GNU Binutils) 2.35.2) #1-Alpine SMP PREEMPT Thu, 12 Aug 2021 14:59:28 +0000
2021-08-18 11:26:51 <nmeum> \o/
2021-08-18 11:27:22 <ikke> PureTryOut: APKINDEX is up-to-date now
2021-08-18 11:27:46 <PureTryOut> Indeed it is, great!
2021-08-18 11:30:01 <mps> nmeum: aieee! good news
2021-08-18 11:30:48 <mps> nmeum: 5.13.12 should be on mirrors
2021-08-18 11:31:17 <nmeum> might have manually wget'ed an old version since I couldn't use apk fetch ;)
2021-08-18 11:32:02 <mps> does lscpu segfaults on it
2021-08-18 11:32:06 <nmeum> we don't build miniroot images for riscv64 yet or do we?
2021-08-18 11:32:23 <nmeum> mps: haven't added a rootfs yet, about to do that
2021-08-18 11:32:23 <mps> no
2021-08-18 11:33:05 <mps> I think ncopa decided to not build release images till riscv become officially supported
2021-08-18 11:34:08 <mps> I have script to build riscv64 VM image with two partitions, bootfs and rootfs
2021-08-18 11:35:05 <mps> but still doesn't boot, waiting for k3rnel 5.14 to see will it work, there are some fixes
2021-08-18 11:35:18 <mps> kernel*
2021-08-18 11:59:08 <PureTryOut> Oh, huh, I'm able to merge stuff in main now? It allowed me to merge a MR which also had a single main package in it 🤔
2021-08-18 11:59:48 <ikke> PureTryOut: ooh
2021-08-18 12:00:09 <PureTryOut> I don't think that was supposed to be the case lol
2021-08-18 12:14:19 <nmeum> > OpenRC 0.43.3.db6a4c49a7 is starting up Linux 5.13.10-0-edge (riscv64)
2021-08-18 12:14:23 <nmeum> openrc is coming up to
2021-08-18 13:52:50 <nmeum> mps: https://git.8pit.net/alpine-unmatched.git/
2021-08-18 13:53:19 <nmeum> works fine, though I will need to send you a few MRs for linux-edge, e.g. the ethernet driver is currently not enabled
2021-08-18 14:05:02 <mps> nmeum: ok, which drivers are needed
2021-08-18 14:05:26 <mps> also, why you didn't merged u-boot changes
2021-08-18 14:05:51 <mps> maybe you could skip building it in your script
2021-08-18 14:06:08 <nmeum> > 1629282118 (nmeum) mps: I think one problem though is that u-boot-spl.bin is now also included in the package for other boards for example u-boot-cuboxi
2021-08-18 14:06:16 <nmeum> > 1629282184 (mps) nmeum: I will look, right now I'm 'on the road'
2021-08-18 14:06:22 <nmeum> that's why I didn't merge my u-boot changes yet
2021-08-18 14:06:32 <mps> ah
2021-08-18 14:06:34 <mps> ok
2021-08-18 14:06:53 <nmeum> if you are fine with the changes to u-boot-cuboxi etc. just merge them :p
2021-08-18 14:07:08 <nmeum> re: linux drivers: CONFIG_MACB seems to be needed for the ethernet driver
2021-08-18 14:07:14 <mps> I skimmed trough it, thought it will be only on riscv
2021-08-18 14:07:17 <nmeum> not sure what else is needed but that's the first thing I noticed
2021-08-18 14:07:50 <nmeum> CONFIG_MACB is also enabled for the other linux-edge architectures
2021-08-18 14:09:36 <mps> yes, wonder why it is not on riscv64 config
2021-08-18 14:09:59 <nmeum> I think we should just enabled it
2021-08-18 14:10:01 <nmeum> *enable
2021-08-18 14:10:39 <mps> I'm right now in work for chromebook kernel upgrade, will look when finish
2021-08-18 14:11:39 <nmeum> nice, ty
2021-08-18 14:11:48 <mps> np
2021-08-18 14:22:01 <mps> nmeum: re: MACB driver. https://tpaste.us/QrRE does this looks ok
2021-08-18 14:23:01 <nmeum> I don't think CONFIG_MACB_PCI is needed
2021-08-18 14:23:21 <nmeum> it's also not enabled on the other arches
2021-08-18 14:23:48 <mps> well, maybe someone have PCI card
2021-08-18 14:24:21 <nmeum> I just think we should keep the config coherent accross different architectures
2021-08-18 14:24:35 <nmeum> also not enabled in linux-lts
2021-08-18 14:24:38 <mps> but ok, I will follow alpine^Wncopa rule, enable only things which are requested
2021-08-18 14:24:43 <nmeum> (:
2021-08-18 14:24:56 <nmeum> do whatever you want, you are the maintainer. just my personal opinion ;)
2021-08-18 14:25:11 <mps> understand
2021-08-18 14:25:18 <nmeum> FYI: this is the kernel config that the stock image which comes with the unmatched package uses https://github.com/sifive/meta-sifive/blob/2021.07/recipes-kernel/linux/files/defconfig
2021-08-18 14:25:27 <nmeum> 5.12 kernel though
2021-08-18 14:26:07 <mps> but even if I'm maintainer I'm not owner of packages, so you can do what you think is needed/good to have
2021-08-18 14:26:51 <mps> as I told (iirc) I have trust in your work and changes
2021-08-18 14:28:32 <nmeum> :)
2021-08-18 14:35:21 <nmeum> mps: do want to push the patch you posted soonish? otherwise I would just build my own kernel
2021-08-18 14:36:02 <fcolista> this is biting us: https://github.com/net-snmp/net-snmp/issues/293
2021-08-18 14:38:26 <mps> nmeum: just waiting to finish linux-elm config and fix patches, I hope I will push linux-edge in about ten minutes
2021-08-18 14:38:50 <nmeum> ok, I will just wait then. thanks
2021-08-18 14:53:58 <mps> nmeum: pushed, we just have to wait for builder to finish
2021-08-18 14:55:03 <mps> ah, riscv builder is busy with other pkgs
2021-08-18 15:02:02 <nmeum> I will check again later today
2021-08-18 15:27:22 <PureTryOut> I... have an interesting problem. I just packaged something but it has broken constraints and apk reports "  Huh? Error reporter did not find the broken constraints."
2021-08-18 15:41:11 <PureTryOut> Oh great, that has screwed up apk entirely. I can't even upgrade my system now 🤔
2021-08-18 15:48:01 <PureTryOut> (removing tthat package from world doesn't help, and it didn't even add it there in the first place)
2021-08-18 15:48:55 <ikke> hmm
2021-08-18 15:50:15 <PureTryOut> In fact, I can not find a reference to the package anywhere in the directories and files apk uses. So what the hell? I also removed it from my local repo just to be sure
2021-08-18 15:51:23 <ikke> I assume you checked /lib/apk/db?
2021-08-18 15:51:28 <PureTryOut> Yeah just did
2021-08-18 15:52:54 <ikke> Maybe you can build apk-tools with debug modes enabled
2021-08-18 15:53:15 <mps> I'm thinking to remove testing/linux-gru and testing/linux-elm from aports. Don't know if anyone still uses them except me and maybe Ariadne 
2021-08-18 15:54:00 <mps> anyone knows that anyone use these kernels
2021-08-18 15:54:39 <PureTryOut> ikke: if you tell me how sure, but I wonder if I'll be able to install that updated package then 🤔
2021-08-18 15:54:44 <mps> hmm, maybe should ask on #alpine-linux
2021-08-18 15:59:49 <ikke> PureTryOut: you can build it statically
2021-08-18 15:59:59 <ikke> and use the static binary
2021-08-18 16:00:16 <PureTryOut> Ah I guess yes, but again, how? 😛
2021-08-18 16:01:24 <PureTryOut> Oh wait just the apk-tools-static subpackage I guess
2021-08-18 16:01:42 <PureTryOut> Ok so how do I enable the debug modes?
2021-08-18 16:02:04 <ikke> Should be a flag somewhere
2021-08-18 16:02:07 <ikke> in the makefile
2021-08-18 16:02:11 <ikke> it mentions DEBUG
2021-08-18 16:03:46 <PureTryOut> I can't find a Makefile that mentions it
2021-08-18 16:09:44 <PureTryOut> the source codes has some ifdefs with DEBUG_PRINT, but no Makefile that sets it
2021-08-18 16:11:03 <afontain[m]> PureTryOut (matrix.org): CFLAGS?
2021-08-18 16:11:31 <afontain[m]> (CFLAGS=-DDEBUG_PRINT)
2021-08-18 16:15:08 <PureTryOut> I'll give it a shot, thanks!
2021-08-18 16:15:36 <ikke> PureTryOut: oh, src/solver.c
2021-08-18 16:16:47 <PureTryOut> afontain: that did the trick, thanks!
2021-08-18 16:17:22 <PureTryOut> That prints a lot, not sure what to search for and in what command 🤔
2021-08-18 16:25:37 <ikke> PureTryOut: is the error message you get the same?
2021-08-18 16:34:23 <PureTryOut> Yes
2021-08-18 17:06:33 <bratkartoffel> can someone please trigger a build on aarch64 for community/java-snappy? I think the error in #12925 just occurs sporadically
2021-08-18 17:07:34 <bratkartoffel> ah, i see, it's disabled there for that reason
2021-08-18 17:10:40 <ikke> Is it a race condition?
2021-08-18 17:16:09 <bratkartoffel> i have no idea, it fails pretty early. couldn't reproduce it so far locally with qemu build
2021-08-18 17:17:54 <ikke> bratkartoffel: fails in my aarch64 container
2021-08-18 17:19:22 <ikke> bratkartoffel: setting JOBS to 1 and it succeeds
2021-08-18 17:19:42 <ikke> so sounds like it's missing an build dependency in the makefile
2021-08-18 17:20:20 <ikke> so either fixing it or building with -j1 should solve this
2021-08-18 17:25:45 <ikke> Hmm, even -j2 fails
2021-08-18 17:29:42 <bratkartoffel> ok, thats really odd. i can build it without problems locally with docker-abuild
2021-08-18 17:30:07 <bratkartoffel> 5 times already, without a single failure
2021-08-18 17:30:23 <ikke> here it's not flaky
2021-08-18 17:30:27 <ikke> -j >1 fails
2021-08-18 17:30:30 <ikke> -j1 succeeds
2021-08-18 17:36:34 <bratkartoffel> ok, i can reproduce it locally even with amd64
2021-08-18 17:36:41 <ikke> aha
2021-08-18 17:36:49 <bratkartoffel> sometimes;   make clean && JAVA_HOME=/usr/lib/jvm/default-jvm make -j12
2021-08-18 17:37:20 <bratkartoffel> really seems like a racing condition, the unpacking of the bitshuffle isn't finished when the g++ to compile it is invoked
2021-08-18 17:37:47 <ikke> yes, that's my suspicion
2021-08-18 17:43:48 <ikke> maybe due to diskspeed?
2021-08-18 17:45:09 <bratkartoffel> !24366 should fix it
2021-08-18 17:45:22 <bratkartoffel> but it doesn't compile as it cannot download a dependency right now
2021-08-18 17:46:20 <bratkartoffel> oh my, google just removed the assets from the github releases at https://github.com/google/snappy/releases
2021-08-18 18:05:51 <Hello71> seems like still there, just not for newer releases?
2021-08-18 18:19:38 <Ariadne> PureTryOut: can you paste the output somewhere
2021-08-18 18:19:57 <PureTryOut> Not currently, am on a different PC. Will do tomorrow
2021-08-18 20:18:55 <blueness> hi ncopa et al.  Does anyone want to take over maintenance of eudev?  I'm going to give it up since gentoo/musl is moving to systemd+openembedded patches
2021-08-18 20:19:48 <ikke> blueness: You mean upstream maintenance?
2021-08-18 20:20:58 <blueness> ikke, yes
2021-08-18 20:21:08 <blueness> i'm the only upstream maintainer
2021-08-18 20:21:17 <blueness> i forked it for gentoo/musl years ago
2021-08-18 20:21:39 <blueness> but now we got systemd+openembedded patch building/working on gentoo/musl
2021-08-18 20:21:49 <blueness> so i don't want to maintain it, or have time
2021-08-18 20:21:59 <blueness> it only has a few bugs, but is lagging behind upstream
2021-08-18 20:21:59 <ikke> Understand
2021-08-18 20:22:08 <blueness> upstream meaning systemd proper
2021-08-18 20:22:16 <blueness> soooo
2021-08-18 20:22:18 <ikke> Myself I don't have the expertise to maintain something like that
2021-08-18 20:22:21 <ikke> but maybe others do
2021-08-18 20:22:23 <blueness> if you want it and can handle it, its yours
2021-08-18 20:22:43 <ikke> I can propose it and see if anyone is interested
2021-08-18 20:22:55 <blueness> it does require C coding and familiarity with its internals
2021-08-18 20:24:12 <blueness> ikke, yes please, else alpine might get stuck with something deprecated
2021-08-18 20:26:04 <Hello71> i think we would rather switch to libudev-zero
2021-08-18 20:27:01 <ericonr> blueness: please offer it up in #musl-distros as well
2021-08-18 20:27:07 <Hello71> if eudev is going away maybe we should just switch entirely instead of prioritizing it
2021-08-18 20:27:25 <ericonr> I think void cares the most about eudev :p
2021-08-18 20:27:31 <Hello71> the libudev-zero author said that some distros have switched already
2021-08-18 20:27:40 <ericonr> 
ACTION should look into libudev-zero

2021-08-18 20:28:15 <ericonr> 
ACTION hates hates hates the systemd component coupling

2021-08-18 20:28:35 <Hello71> i didn't move on it because i thought eudev would be around for a while longer
2021-08-18 20:28:45 <dalias> huh? udev-zero is not a udev/eudev substitute
2021-08-18 20:28:57 <ericonr> well, it has been a bit outdated for a while no
2021-08-18 20:28:59 <ericonr> now
2021-08-18 20:29:06 <Hello71> what functionality does it lack?
2021-08-18 20:29:10 <dalias> udev-zero is just a hack to make it so programs that link against libudev don't have a dependency on installing udev
2021-08-18 20:29:29 <dalias> it's a nopped out stub with the symbols there
2021-08-18 20:29:48 <dalias> so you can install it in place of eudev if you want to build programs that were linked against udev but dont want udev on your system
2021-08-18 20:29:51 <Hello71> no, it does device discovery
2021-08-18 20:30:15 <dalias> it might do some enumeration for these apps
2021-08-18 20:30:34 <dalias> but i dont think it has a daemon and does the equivalent hotplug events
2021-08-18 20:30:42 <skarnet> that's what mdev/d is for
2021-08-18 20:31:00 <minimal> cloud-init currently relies on eudev, I haven't had time to see if I could make it work with mdev
2021-08-18 20:31:04 <Hello71> if you install sway on fresh alpine linux and run it it will fail complaining that no input devices could be found
2021-08-18 20:31:06 <dalias> ok, but if you drop eudev and require move to mdev, everyone has to figure out how to convert their configs when upgrading
2021-08-18 20:31:16 <dalias> and i'm not sure if the functionality is matching
2021-08-18 20:31:24 <Hello71> mdev is already the alpine default
2021-08-18 20:31:39 <dalias> hello71, only until you install a package that pulls in eudev :-p
2021-08-18 20:31:47 <dalias> which lots used to do
2021-08-18 20:31:47 <Hello71> but it's true that for those who did install udev there needs to be some migration path
2021-08-18 20:31:51 <dalias> maybe that's no longer the case
2021-08-18 20:31:59 <skarnet> dalias: the functionality is matching for anything that doesn't require the statefulness of libudev
2021-08-18 20:32:03 <dalias> but it means lots of us have configurations built up around eudev
2021-08-18 20:32:10 <ikke> setup-xorg installs eudev
2021-08-18 20:32:24 <Hello71> because libinput
2021-08-18 20:32:28 <skarnet> it's not like alpine has to drop eudev *right now*, there is time to set up a migration path
2021-08-18 20:32:36 <dalias> does xorg input device hotplug work with just mdev and udev-zero ?
2021-08-18 20:33:08 <dalias> that's rather important for many users
2021-08-18 20:33:12 <minimal> exactly: like the dep I added for eudev to cloud-init - the other Linux dists that cloud-init upstream supports have udev via systemd, not sure how the BSDs supported function
2021-08-18 20:33:15 <Hello71> not ootb on alpine afaik
2021-08-18 20:33:22 <Hello71> https://github.com/illiliti/libudev-zero#hotplugging
2021-08-18 20:34:38 <skarnet> please don't make me write a libudev this year
2021-08-18 20:34:56 <Hello71> afaik if that gets added to alpine, and eudev was replaced by libudev-zero, the only thing missing would be custom udev rules
2021-08-18 20:34:57 <ericonr> 
ACTION starts counting down the months

2021-08-18 20:35:34 <skarnet> there needs to be a tool converting udev rules to mdev.conf format
2021-08-18 20:35:38 <skarnet> and we're good to go
2021-08-18 20:36:13 <mps> 
ACTION waiting pulseaudio author to say something like blueness :)

2021-08-18 20:36:20 <dalias> :-p
2021-08-18 20:36:44 <mps> libudev-zero works fine on my machines
2021-08-18 20:36:59 <mps> except Xorg hotplug
2021-08-18 20:37:04 <skarnet> I think there's one functionality missing: the support for bind/unbind actions (if those are even what they are, I mean the thing other than add/remove)
2021-08-18 20:37:12 <dalias> Xorg hotplugs are big
2021-08-18 20:37:14 <skarnet> but I plan to add support for all actions in mdevd soon anyway
2021-08-18 20:37:23 <dalias> for example my mouse is bluetooth and it's always "hotplugged"
2021-08-18 20:38:05 <mps> I planned to talk with libudev-zero author about hot plugging but didn't found time
2021-08-18 20:38:06 <dalias> but so is any mouse on a laptop, altho you might keep it plugged into usb most of the time
2021-08-18 20:38:20 <dalias> the above link says it's there but it sounds like a nasty hack
2021-08-18 20:38:54 <mps> dalias: it have helper program which i didn't tested yet (don't need it actually)
2021-08-18 20:43:47 <Hello71> dalias: what do you mean by "hotplug"
2021-08-18 20:44:28 <Hello71> it sounds like a different thing than illiliti means
2021-08-18 20:45:17 <dalias> hello71, i mean the device dynamically coming into and going out of existence during the lifetime of Xorg server
2021-08-18 20:45:19 <skarnet> hotplug is when a device creates an event (typically ADD), what does illiliti mean with it?
2021-08-18 20:46:05 <dalias> logical device of course. although i guess i could smash a mouse and make a new one from scratch (or at least from some pcb service) well within the lifetime of my X session too :)
2021-08-18 20:46:27 <skarnet> weird flex but ok
2021-08-18 20:46:58 <skarnet> please avoid animal cruelty
2021-08-18 20:55:19 <minimal> in a VM/Cloud provider context "hotplug" would be where you e.g. add a 2nd network adaptor to a running VM - upstream cloud-init is only now adding support for this via udev functionality in the next release (due out in a matter of days) where a udev "hotplug" event gets passed on to cloud-init to then configure the interface
2021-08-18 20:56:37 <nmeum> xorg hotplug is kind of big deal, I add and remove xorg input devices all the time when docking and undocking my laptop etc.
2021-08-18 21:27:58 <clandmeter> how do you edit the isolinux cmdline?
2021-08-18 21:28:29 <ikke> tab when you see boot:
2021-08-18 21:28:35 <ikke> Or just start typing
2021-08-18 21:28:39 <clandmeter> it only shows lts
2021-08-18 21:38:16 <Ariadne> i think eudev vs libudev-zero should be decided by TSC
2021-08-18 21:38:46 <ikke> Ariadne: I've created an issue already
2021-08-18 21:39:03 <Ariadne> i think libudev-zero is fine if we can fix hotplug
2021-08-18 21:39:09 <Ariadne> but we should determine the requirements
2021-08-18 21:39:09 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/12
2021-08-18 21:40:13 <Ariadne> 
ACTION fires up an s390x VM to do her work for the week

2021-08-18 21:40:24 <Ariadne> i give up on this x86 laptop :D
2021-08-18 21:58:37 <mps> Ariadne: interesting 'laptop' box ;)
2021-08-18 21:59:10 <Ariadne> mps: i mean, i have a working chromebook, and a working macbook air, and a working desktop
2021-08-18 21:59:29 <Ariadne> i just liked using the x86 laptop because it had an i5 that could turbo at 4.3ghz
2021-08-18 22:01:28 <mps> M1 is really fast
2021-08-18 22:01:59 <Ariadne> yes, unfortunately s390x is even faster
2021-08-18 22:02:00 <Ariadne> :p
2021-08-18 22:02:06 <mps> if it is not made by evil company I would buy tomorrow yet another
2021-08-18 22:02:26 <Ariadne> yes, unfortunately, apple have decided that your phone should be a cop
2021-08-18 22:02:42 <Ariadne> hmm, this is actually -offtopic material
2021-08-18 22:02:48 <mps> and not only phone
2021-08-18 22:02:56 <mps> yes, sorry
2021-08-18 23:54:45 <tomalok> could i get someone to review !24341? would like to follow up with a MR to move this to community.
2021-08-19 05:32:28 <ikke> tomalok: merged
2021-08-19 05:47:17 <bratkartoffel> ikke: !24366 is ready to merge, fixing the racing condition on java-snappy
2021-08-19 05:47:36 <ikke> yeah, I was waiting for CI to compplete
2021-08-19 05:48:02 <bratkartoffel> perfect, thanks :)
2021-08-19 05:51:05 <ikke> huh
2021-08-19 05:51:09 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/java-snappy/java-snappy-1.1.8.4-r0.log
2021-08-19 05:58:26 <ikke> cannot reproduce
2021-08-19 06:01:50 <bratkartoffel> ikke: oh, come on
2021-08-19 06:02:19 <ikke> I know, right
2021-08-19 06:04:00 <bratkartoffel> compared with s390x it nags about missing lscpu
2021-08-19 06:04:37 <bratkartoffel> is it present on the other builders but not aarch64?
2021-08-19 06:05:15 <bratkartoffel> util-linux-misc
2021-08-19 06:07:24 <ikke> It's not present on the other builders as well
2021-08-19 06:08:13 <bratkartoffel> but also complaining there... hate scala, always trouble since i know it. maybe !24378 finally makes it work?
2021-08-19 06:08:43 <ikke> let me try it 
2021-08-19 06:09:49 <ikke> nope
2021-08-19 06:13:31 <nmeum> 8ece2b732b4edf494272f12b7adb283e9d1ed539
2021-08-19 06:13:59 <nmeum> do we really beed to build a security critical application like gnupg with that many patches? 🤔
2021-08-19 06:14:05 <nmeum> *need
2021-08-19 06:24:43 <bratkartoffel> nmeum: the patches seem reasonable and harden the application, so why not?
2021-08-19 06:25:36 <bratkartoffel> s/the patches/most of the patches/
2021-08-19 06:46:29 <nmeum> bratkartoffel: I think this is a unnecessary deviation from the upstream code, there is likely a reason why upstream hasn't merged these patches, I don't trust debian at all with downstream patches to security critical software (remember CVE-2008-0166?) and these patches make it harder to upgrade the package in the future
2021-08-19 06:47:49 <nmeum> IMHO this shouldn't have been merged without any prior discussion in a merge request
2021-08-19 07:06:48 <danieli> I prefer it when packaged software is left as vanilla as possible - but do keep in mind that both people and things change, and that 2008 was 13 years ago
2021-08-19 07:09:09 <sircmpwn> ikke: you never followed up on the committer question
2021-08-19 07:14:33 <PureTryOut> 
ACTION posted a file: (14578KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/yxKIORXjseaOcDXOFIPKQXJu/apk.log >

2021-08-19 07:14:47 <PureTryOut> Ariadne and ikke: everything apk prints out while failing on the unknown constraints
2021-08-19 07:22:45 <Ariadne> 14.2mb
2021-08-19 07:22:47 <Ariadne> holy moly :D
2021-08-19 07:33:11 <PureTryOut> Yeah it's big lol
2021-08-19 07:33:23 <PureTryOut> That's what you get when you enable debug mode 🤷
2021-08-19 07:44:45 <mps> when we will *finally* stop with enabling -dbg?
2021-08-19 07:48:06 <ikke> mps: when people stop adding bugs to programs
2021-08-19 07:50:28 <mps> hah, you mean never
2021-08-19 07:50:36 <nmeum> danieli: sure, that cve is just one example I rembember vividly the past. the more general question here really is if we trust debian more than upstream I guess
2021-08-19 07:51:24 <danieli> for me it depends on an individual basis, some upstream maintainers are really sketchy.. and in some cases package maintainers make bad choices
2021-08-19 07:51:33 <mps> ikke: is the 'Inferno' still obligatory literature in schools
2021-08-19 07:51:50 <mps> (looks like it is not)
2021-08-19 07:54:18 <Ariadne> i mean
2021-08-19 07:54:24 <nmeum> danieli: yep, though the thing with security critical stuff like gnupg is that there is a lot of room for package maintainers to make bad choices when it comes to applying patches
2021-08-19 07:54:44 <Ariadne> what danieli is really saying is debian patched openssl once to use the PID (and only the PID) as the only source of entropy for openssl's PRNG
2021-08-19 07:55:01 <Ariadne> so, depends on who is maintaining what and what the actual patches do
2021-08-19 07:55:05 <Ariadne> they should be reviewed :)
2021-08-19 07:55:28 <nmeum> yes, and ideally upstream would review them because they have the best understanding of the codebase that is modified by the patches
2021-08-19 07:55:53 <Ariadne> i think when it comes to GPG, we should stick with upstream
2021-08-19 07:56:01 <danieli> pretty much.. and yeah, i remember some of the fallout of CVE-2008-0166
2021-08-19 07:56:29 <Ariadne> but again it depends on who/what about the patches
2021-08-19 07:56:48 <Ariadne> there are smart crypto people in debian, like dkg
2021-08-19 07:56:58 <Ariadne> who i would trust
2021-08-19 07:57:20 <PureTryOut> Ariadne: but the big question is, is that giant log useful in anyway?
2021-08-19 07:57:27 <Ariadne> idk i havent looked at it yet
2021-08-19 07:57:42 <Ariadne> i've been busy doing surgery on my laptop
2021-08-19 07:57:45 <Ariadne> with a butter knife
2021-08-19 07:58:41 <nmeum> the gnupg change is not only about "do we trust debian though" but also: do these patches make it harder for us to maintain the package in the long run etc.
2021-08-19 07:59:06 <Ariadne> well, maintenance with the patches can be handled with cross-distro collaboration
2021-08-19 07:59:07 <nmeum> I think this could have all been discussed in a MR but the change was just merged without any prior discussion which I find a bit questionable
2021-08-19 07:59:17 <Ariadne> e.g. you could do maintenance collaboratively with the debian team
2021-08-19 08:00:47 <Ariadne> all of those patches appear to be from dkg, so i trust them
2021-08-19 08:01:17 <Ariadne> however, with my security hat on, it would have been nice to review this prior to it being merged
2021-08-19 08:04:54 <Ariadne> nmeum: i'm okay with the patchset, but i would have liked this in MR format, especially since i was not even aware it was merged
2021-08-19 08:05:32 <nmeum> that's also my main critique
2021-08-19 08:06:24 <nmeum> maybe we can convince jakub do that in the future, unfourtunatly he is not irc
2021-08-19 08:07:49 <nmeum> mps: btw, did you make up your mind on the hifive unmatched u-boot changes yet? :)
2021-08-19 08:08:31 <mps> nmeum: I put it on hold about half an hour ago
2021-08-19 08:08:58 <nmeum> I can just add a case-distinction to the split function so u-boot spl is only packaged for the hifive unmatched
2021-08-19 08:09:10 <mps> some results doesn't look ok, but don't have time now to test
2021-08-19 08:09:35 <nmeum> ok
2021-08-19 08:09:38 <mps> yes, that is something I thought about
2021-08-19 08:10:12 <mps> sunxi files doesn't look 'good' after build
2021-08-19 08:12:49 <nmeum> ah indeed
2021-08-19 08:14:49 <nmeum> that's because of the -- after u-boot-spl.bin I suppose
2021-08-19 08:15:29 <nmeum> so it escapes the for loop before copying u-boot-sunxi-with-spl.bin to the package
2021-08-19 08:15:36 <donoban> I don't see too much sense raising key sizes from gpg upstream
2021-08-19 08:16:23 <nmeum> I also don't understand why the rsa keysize is not changed to 4096 if it is modified in the first place
2021-08-19 08:16:56 <Ariadne> donoban: i do
2021-08-19 08:17:59 <mps> nmeum: yes, something about that
2021-08-19 08:18:02 <Ariadne> they should really go to 4096
2021-08-19 08:18:17 <Ariadne> nmeum: presumably, 3072 is more performant on 'slow' systems
2021-08-19 08:20:27 <nmeum> mps: if we remove the -- u-boot.img and some other stuff is also include in the hifive unmatched package but I guess that's fine?
2021-08-19 08:21:34 <mps> nmeum: I think so but we should test that, and I'm too busy now, sorry
2021-08-19 08:21:39 <nmeum> np
2021-08-19 08:22:33 <Ariadne> more gpg changes
2021-08-19 08:22:42 <Ariadne> i'm going to poke him about it
2021-08-19 08:26:10 <donoban> https://github.com/certbot/certbot/issues/2080 interesting discussion about raising 2048 to 3072 (or 4096), opened in 2016 still being default 2048
2021-08-19 08:26:51 <Ariadne> TLS certs and GPG keys are a bit different usecases
2021-08-19 08:28:47 <donoban> I don't see the different usecases implies too much different attack risk for justify different key sizes
2021-08-19 08:29:38 <donoban> https://xkcd.com/538/ :D
2021-08-19 08:45:18 <Ariadne> thats true for a state adversary, but think about things like say, patient data
2021-08-19 08:46:43 <Ariadne> i recovered my ssh key, that's all i care about
2021-08-19 08:46:52 <Ariadne> anybody want a laptop that i did a lot of surgery on? :D
2021-08-19 08:47:30 <veiviser> was it.. plastic surgery
2021-08-19 08:47:43 <Ariadne> no
2021-08-19 08:48:02 <Ariadne> it involved knocking caps off the motherboard's vcore rail until i found the one that was acting as a vampire tap
2021-08-19 08:51:22 <donoban> omg
2021-08-19 08:51:30 <donoban> what laptop is it Ariadne ?
2021-08-19 08:54:20 <veiviser> Ariadne: ah.. i see now.. what an adventure :p
2021-08-19 10:20:01 <mps> if someone missed comments https://lwn.net/Articles/865995/
2021-08-19 10:28:26 <ikke> Anyone got a clue why java-snappy is now failing on aarch64? I cannot reproduce it in my aarch64 lxc container on the same host
2021-08-19 11:21:37 <Hello71> ikke: how many cpus did you say the aarch64 has?
2021-08-19 11:23:32 <mps> Hello71: builder?
2021-08-19 11:23:37 <Hello71> yes
2021-08-19 11:23:43 <mps> 160
2021-08-19 11:23:51 <ikke> The builders are limited to 80 (numa domain)
2021-08-19 11:25:58 <Hello71> with qemu or with cpu affinity? (i.e. what does sysfs say)
2021-08-19 11:27:30 <ikke> nproc returns 80
2021-08-19 11:27:50 <Hello71> nproc uses cpu affinity
2021-08-19 11:27:58 <Hello71> what does nproc --all say
2021-08-19 11:28:12 <ikke> 160
2021-08-19 11:28:22 <ikke> the builders do not use qemu
2021-08-19 11:28:25 <ikke> just lxc
2021-08-19 11:29:11 <ikke> lxc.cgroup.cpuset.cpus = 80-159
2021-08-19 11:29:32 <nmeum> mps: the addition of macb seems to have introduced some new problems https://tpaste.us/ovgR
2021-08-19 11:31:19 <mps> nmeum: could depmod -a help
2021-08-19 11:32:35 <mps> I think you know this, but just reminding you
2021-08-19 11:35:35 <Hello71> ikke: can you compile and run this program on the builder (in lxc)? public class Processors { public static void main(String[] args) { System.out.println(Runtime.getRuntime().availableProcessors()); } }
2021-08-19 11:36:18 <ikke> I can try that later
2021-08-19 11:37:20 <nmeum> mps: nope, doesn't seem to help. seems like cpu 0 gets stuck somehow when attempting to load the macb module for some reason? https://tpaste.us/jN4q
2021-08-19 11:39:23 <mps> hmm, maybe we should some other distro which boots on this board and compare kernel config
2021-08-19 11:39:37 <mps> do you know one
2021-08-19 11:39:50 <nmeum> i am currently comparing with the 5.12 from meta-riscv
2021-08-19 11:39:59 <nmeum> https://github.com/sifive/meta-sifive/blob/2021.07/recipes-kernel/linux/files/defconfig
2021-08-19 11:40:19 <Hello71> ah, i found the bug
2021-08-19 11:40:25 <nmeum> we definitly want SIFIVE_L2 I think, that should be the cache control the one modprobe warning is complaining about
2021-08-19 11:40:33 <nmeum> See !24383
2021-08-19 11:40:38 <Hello71> https://github.com/openjdk/jdk8u/blob/master/hotspot/src/os/linux/vm/os_linux.cpp#L5287
2021-08-19 11:41:11 <Hello71> shouldn't have been looking at jdk16 code -.-
2021-08-19 11:41:19 <clandmeter> mps: you added a duplicate issue on tsc?
2021-08-19 11:41:35 <mps> really, I missed it
2021-08-19 11:41:47 <clandmeter> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/9
2021-08-19 11:42:30 <mps> I see, sorry
2021-08-19 11:43:09 <ikke> Hello71: Why does it work on my personal container, even though it also has the CPUs set?
2021-08-19 11:43:17 <Hello71> which numbers?
2021-08-19 11:43:18 <mps> thought it was not added already, because I didn't received notification
2021-08-19 11:43:37 <ikke> Ah, the first 80, not the 2nd
2021-08-19 11:43:40 <ikke> is that the bug?
2021-08-19 11:43:42 <Hello71> i think what is happening is the "optimization" checks 0-79
2021-08-19 11:43:46 <Hello71> but none of those are enabled
2021-08-19 11:43:49 <ikke> aha
2021-08-19 11:45:24 <Hello71> ah, yes, and musl implements _SC_NPROCESSORS_CONF by sched_getaffinity
2021-08-19 11:46:25 <Hello71> there is a discussion on the mailing list about implementing it properly, but not resolved yet
2021-08-19 11:46:37 <mps> nmeum: remove Draft and merge it, looks ok to me
2021-08-19 11:46:59 <mps> !24383 I mean
2021-08-19 11:47:29 <nmeum> I am currently cross compiling a new kernel with that config to test it, give me a sec ;)
2021-08-19 11:47:56 <Hello71> ikke: it can be fixed by upgrading to java 11
2021-08-19 11:47:58 <mps> ok, no hurries 
2021-08-19 11:48:20 <Hello71> the broken code is still there but as long as libc implements CPU_COUNT (which musl does) it will be bypassed
2021-08-19 11:48:50 <ikke> bratkartoffel: ^
2021-08-19 11:49:03 <ikke> Hello71: thanks for investigating
2021-08-19 11:49:26 <Hello71> funnily enough they could have implemented the same footgun here with CPU_COUNT_S
2021-08-19 11:50:07 <Hello71> seems like jirutka is maintaining java-snappy
2021-08-19 11:50:22 <ikke> Yes, but he deferred to bratkartoffel for the build issues
2021-08-19 11:50:39 <Hello71> i see.
2021-08-19 11:50:41 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12925
2021-08-19 11:52:50 <bratkartoffel> ikke: Hello71: thanks for analyzing this, i'll update the MR this evening
2021-08-19 12:45:47 <nmeum> mps: the macb issue is related to u-boot it seems
2021-08-19 12:45:54 <nmeum> I previously built u-boot without network support
2021-08-19 12:46:03 <nmeum> I suppose u-boot initializes the ethernet peripheral
2021-08-19 12:46:07 <nmeum> works like a charm now \o/
2021-08-19 12:56:41 <Ariadne> i can try it on my unleashed board later today
2021-08-19 12:57:05 <Ariadne> i’ve been using a sifive kernel instead
2021-08-19 13:02:19 <nmeum> just pushed a few more riscv64 specific changes to linux-edge
2021-08-19 13:02:52 <nmeum> linux-lts doesn't have unmatched support yet
2021-08-19 13:37:35 <mps> Hello71: libudev-zero author helped me to solve problem with hot plugging input devices for xorg, now that works \o/
2021-08-19 13:38:13 <Hello71> it was more complicated than "follow the instructions"?
2021-08-19 13:38:33 <mps> yes, more, he have to make docs cleaner
2021-08-19 13:38:49 <mps> and clear about this
2021-08-19 15:19:01 <DavyLandman[m]> If I wanted to include some extra devices in the armv7 & aarch64 images, where should I make a MR on? I'm assuming I have to re-run the kernel config to add those. Or is this not something open for discussion? I would like to add support for odroid devices (so Exynos and meson/amlogic device trees).
2021-08-19 15:31:19 <mps> DavyLandman[m]: would be nice to first tell here which devices you want to be supported
2021-08-19 15:32:09 <DavyLandman[m]> That makes sense, I was thinking about the odroid-xu4 (and the odroid-hc1/hc2) which are quite popular in the homeserver market.
2021-08-19 15:33:30 <DavyLandman[m]> And the odroid-c4 (and odroid-hc4), odroid-n2 which are at a quite nice powerfull ARM devices that are gaining traction.
2021-08-19 15:34:34 <DavyLandman[m]> hardkernel has been producing interesting set of boards with gigabyte NIC and enough memory to run quite some stuff.
2021-08-19 15:34:39 <mps> we need someone to test will it work with alpine, and to report back to us
2021-08-19 15:35:56 <mps> alpine userspace works fine on most armv7 boards
2021-08-19 15:36:26 <skarnet> as long as you don't get screwed by fortify-headers >.>
2021-08-19 15:36:28 <mps> only problem could be u-boot and not enabled kernel drivers and/or options
2021-08-19 15:36:36 <DavyLandman[m]> I have a xu4 and a n2 here, but I don't know when I'll have enough time to run some tests.
2021-08-19 15:37:08 <DavyLandman[m]> I've been reading, and at least for the n2, armbian is using mainline 5.10 and mainline u-boot.
2021-08-19 15:38:12 <mps> xu4 is arm64?
2021-08-19 15:38:18 <DavyLandman[m]> I mean, I could take their uboot and kernel images, and just make a frankenbuild as described in the wiki, but I was just wondering, what is the criteria for the current chipsets/dtbs that are part of the generic arm image.
2021-08-19 15:38:24 <DavyLandman[m]> xu4 is armv7, n2 is arm64
2021-08-19 15:38:39 <mps> aha, thanks
2021-08-19 15:38:41 <DavyLandman[m]> there are dtb's in the mainline kernel for xu4
2021-08-19 15:39:01 <mps> we can build u-boot for xu4, I think
2021-08-19 15:39:34 <mps> and I think we already have dtbs in kernel for it, but have to check
2021-08-19 15:39:36 <DavyLandman[m]> but I know hardkernel has been maintaining their own kernel for xu4 and also u-boot. so I don't know the specifics there, I think it has to do with hardware video decoding.
2021-08-19 15:40:23 <mps> we don't add patches from vendors, only what is in mainline kernels
2021-08-19 15:40:37 <DavyLandman[m]> not proposing that either
2021-08-19 15:40:46 <mps> ok :)
2021-08-19 15:40:56 <DavyLandman[m]> I was just reporting on what armbian has been doing
2021-08-19 15:41:19 <DavyLandman[m]> true, the armv7 image already contains the dtb for xu4
2021-08-19 15:41:34 <mps> armbian is at the easy there, it is distro only for arm and we are more wide
2021-08-19 15:42:14 <DavyLandman[m]> True, just trying to see what can be learned from their efforts. It's different goals, I get that.
2021-08-19 15:42:48 <DavyLandman[m]> just checked, the aarch64 image doesn't contain dtbs for n2 (or any other amlogic cpu). 
2021-08-19 15:43:19 <mps> ok, please tell us what you can and will test and we will try to add support for these devices
2021-08-19 15:44:09 <mps> we have outdated amlogic kernel in repo, it should be removed and config merged to our supported kernels
2021-08-19 15:44:39 <DavyLandman[m]> interesting, the linux-meson project has been upstreaming stuff right?
2021-08-19 15:45:02 <mps> yes, mostly
2021-08-19 15:45:11 <DavyLandman[m]> I might be missing what you meant by outdated amlogic kernel
2021-08-19 15:45:32 <DavyLandman[m]> so reading here: there u-boot support for xu4 and friends: https://github.com/u-boot/u-boot/blob/v2021.07/doc/README.odroid
2021-08-19 15:46:10 <mps> yes, but no one asked us to add u-boot for it
2021-08-19 15:46:23 <DavyLandman[m]> ah ok :)
2021-08-19 15:46:24 <mps> till now, I mean
2021-08-19 15:47:09 <DavyLandman[m]> similarly for odroid-n2: https://github.com/u-boot/u-boot/blob/v2021.07/doc/board/amlogic/odroid-n2.rst
2021-08-19 15:47:29 <DavyLandman[m]> but I think the most users are still on the xu4 and friends side.
2021-08-19 15:48:04 <DavyLandman[m]> Should I make an issue on gitlab to track this? So we have a place to share the files and I can report back test results?
2021-08-19 15:48:09 <mps> agree
2021-08-19 15:48:26 <DavyLandman[m]> on aport?
2021-08-19 15:48:38 <mps> I hate web tracking but yes, you can open issue
2021-08-19 15:49:11 <DavyLandman[m]> If you prefer are different route, I'm open to suggestions.
2021-08-19 15:49:29 <mps> gitlab issue is ok
2021-08-19 15:49:46 <mps> and if you can 'hang' here would be nice
2021-08-19 15:50:26 <DavyLandman[m]> I'll hang here
2021-08-19 15:50:31 <DavyLandman[m]>  * I'll hang here as well.
2021-08-19 15:52:12 <mps> ok, lets start with u-boot for xu4 first
2021-08-19 15:53:18 <DavyLandman[m]> 👍️
2021-08-19 15:53:19 <DavyLandman[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12931
2021-08-19 15:53:44 <mps> hmm, yet another emoticon on IRC :)
2021-08-19 15:54:27 <DavyLandman[m]> my bad, using the matrix bridge, that hides the fact that this is IRC too well ;)
2021-08-19 15:54:44 <mps> I know ;)
2021-08-19 15:55:26 <mps> some people here even like to irritate me with emoticons
2021-08-19 15:55:31 <DavyLandman[m]> Timing wise, I have debugging acces on the xu4 by the end of the weekend.
2021-08-19 15:55:55 <DavyLandman[m]> I'll take that into account next time ;)
2021-08-19 15:56:00 <mps> good, do you use serial console for debuging
2021-08-19 15:56:08 <DavyLandman[m]> I have the right adapter yes
2021-08-19 15:56:46 <DavyLandman[m]> (and have used it before for debugging)
2021-08-19 15:56:52 <DavyLandman[m]>  * (and have used it before for debugging/rescueing)
2021-08-19 15:57:03 <DavyLandman[m]>  * (and have used it before for rescueing)
2021-08-19 15:57:04 <mps> very good, this could be begining of friendship :)
2021-08-19 15:57:10 <DavyLandman[m]> lol
2021-08-19 15:57:28 <DavyLandman[m]> as long as I avoid the emoticons...
2021-08-19 15:57:37 <mps> :D
2021-08-19 15:58:10 <mps> no, my good friends here use emoticons also
2021-08-19 15:58:26 <DavyLandman[m]> :D
2021-08-19 15:59:17 <mps> I assigned issue to me, have first to check another MR for u-boot and after that I will enable xu4
2021-08-19 15:59:35 <DavyLandman[m]> ok, tnx, talk to you later
2021-08-19 15:59:51 <mps> np
2021-08-19 16:09:12 <Ariadne> the cmdline=quiet battle was fought
2021-08-19 16:09:17 <mps> nmeum: can we move opensbi in separate MR or directly without MR
2021-08-19 16:09:27 <mps> Ariadne: who wins?
2021-08-19 16:09:30 <Ariadne> 3 fought valiantly for cmdline=quiet, but unfortunately the forces of apathy won
2021-08-19 16:09:57 <mps> huh, make me a member of TSC
2021-08-19 16:10:03 <Ariadne> :D
2021-08-19 16:10:38 <Ariadne> well its supposed to be rotating, so yes, maybe someday in the future it is possible :P
2021-08-19 16:10:59 <mps> when the 'quiet' is settled? too late :)
2021-08-19 16:11:01 <nmeum> mps: why?
2021-08-19 16:11:21 <mps> nmeum: easier to test in my builders
2021-08-19 16:11:22 <nmeum> mps: the u-boot payload for riscv embeds the fw_payload.bin opensbi payload
2021-08-19 16:11:32 <nmeum> so you need opensbi in community for this
2021-08-19 16:11:48 <nmeum> if it is just a build issue in your setup I can just go ahead and move it now
2021-08-19 16:11:50 <Ariadne> mps: it can always be settled again
2021-08-19 16:11:55 <mps> no, u-boot is in main so opensbi should move there
2021-08-19 16:12:01 <nmeum> ah yes sorry
2021-08-19 16:12:05 <nmeum> that's what i meant to say
2021-08-19 16:12:12 <mps> ok
2021-08-19 16:12:20 <Ariadne> anyway
2021-08-19 16:12:25 <nmeum> the cmdline=quiet battle messed with my brain!
2021-08-19 16:12:37 <nmeum> mps: so should I just move it now?
2021-08-19 16:12:45 <mps> yes
2021-08-19 16:12:48 <nmeum> ok
2021-08-19 16:12:51 <nmeum> one sec
2021-08-19 16:13:43 <Ariadne> do we need riscv64 kernel tested on unleashed?
2021-08-19 16:13:51 <mps> I'll fire my sunxi test board later and test
2021-08-19 16:14:34 <nmeum> Ariadne: I am still not done with kernel config changes so not neccessairly now, but maybe later?
2021-08-19 16:14:41 <Ariadne> okay
2021-08-19 16:14:49 <nmeum> should probably work though if you want to test it now
2021-08-19 16:14:54 <nmeum> u-boot config for the unleashed might also be neat
2021-08-19 16:16:18 <mps> configs/sifive_unleashed_defconfig?
2021-08-19 16:16:28 <mps> u-boot
2021-08-19 16:16:31 <nmeum> mps: moved it, will quickly rebase my u-boot MR
2021-08-19 16:16:41 <mps> nice and thanks
2021-08-19 16:17:03 <nmeum> rebased it
2021-08-19 16:17:25 <mps> ok
2021-08-19 16:18:03 <nmeum> mps: yes, u-boot has a config for the unleashed. though the booting process for the unleashed and the unmatched differs iirc. but should be doable *if* we want to support the unleashed (i think you can't buy it anymore from sifive)
2021-08-19 16:18:54 <mps> I think Ariadne already have it
2021-08-19 16:19:25 <nmeum> *nod*
2021-08-19 16:19:26 <Ariadne> yes, i have a pair of unleashed boards in my colo
2021-08-19 16:20:09 <Ariadne> i haven't done anything with them because the performance was really lackluster
2021-08-19 17:14:33 <knuxify> i'm currently trying to package pinta, although it uses gtk2 and i'm not sure what's the general consensus on that; should i make a package for it now or wait until gtk3 support is finished?
2021-08-19 17:18:08 <knuxify> ...or just say "screw it" and package the wip gtk3 branch instead? :p
2021-08-19 17:19:32 <mps> nmeum: tested u-boot on one 32bit sunxi board and it boots, but apk have extra file u-boot-spl.bin which are not needed
2021-08-19 17:20:10 <mps> also u-boot-cuboxi looks suspiciously small
2021-08-19 17:20:42 <mps> I don't have this board to test but from content of apk I doubt it can be used
2021-08-19 17:22:25 <mps> maybe rewrite this in 'case' block, 'case "$CARCH" in ..... riscv64)' and put there this change in MR
2021-08-19 17:32:36 <nmeum> mps: ok, can do that
2021-08-19 17:33:14 <mps> nice, I will stop work on this now :)
2021-08-19 17:35:18 <mps> !24388
2021-08-19 17:35:43 <mps> this is ok
2021-08-19 17:35:46 <nmeum> mallory: something along these lines ok? https://tpaste.us/1Ey0
2021-08-19 17:35:48 <nmeum> *mps
2021-08-19 17:35:49 <nmeum> sorry
2021-08-19 17:36:27 <mps> nmeum: np
2021-08-19 17:36:45 <mps> nmeum: this is change to your current MR?
2021-08-19 17:37:03 <nmeum> yes
2021-08-19 17:37:07 <nmeum> haven't pushed it yet will test it locally first
2021-08-19 17:37:13 <nmeum> just "design"-wise
2021-08-19 17:37:29 <mps> ok, inform me when you push change so I can test again
2021-08-19 17:37:35 <nmeum> ok :)
2021-08-19 18:03:04 <nmeum> mps: pushed the requested case distinction for the unmatched to the u-boot pr
2021-08-19 18:26:03 <kunrooted[m]> heyo, I think this might be a better channel than #alpine-linux, I have a question, can I make a Live .iso from Alpine BUT with added some tools and tweaks?
2021-08-19 18:26:51 <ikke> The scripts to build the iso's can be found here: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts
2021-08-19 18:26:52 <mps> nmeum: building it now
2021-08-19 18:27:43 <kunrooted[m]> are there any docs for that?
2021-08-19 18:28:13 <kunrooted[m]> or I just need to use `mkimage.sh` from the thing you've provided and I'll be fine?
2021-08-19 18:29:51 <ikke> sadly, there is no documentation. https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.standard.sh contains most information about what is included in the standard image
2021-08-19 18:36:42 <kunrooted[m]> looks nice
2021-08-19 18:36:54 <Misthios> https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage i used this to make custom iso #gotta love realtek wifi
2021-08-19 18:37:32 <kunrooted[m]> but I'm kinda worried it won't be suitable for me because I wanted to use Nix on it + I wanted to make it Bedrock
2021-08-19 18:45:24 <kunrooted[m]> Or maybe there is some hacky way to do some directory magic as with Nix and Bedrock? basically I'll need to keep /bedrock and /nix within that iso
2021-08-19 18:51:28 <ikke> I know nothing about those systems, so I would not know
2021-08-19 18:59:43 <mps> nmeum: looks like u-boot is ok now
2021-08-19 19:01:16 <mps> this commit msg looks 'strange' though 'See previous commit.'
2021-08-19 19:15:55 <kunrooted[m]> ikke: I Just Wonder if it can preserve files and directory structure
2021-08-19 19:18:12 <ikke> You'd have to create a package that has the structure
2021-08-19 19:21:40 <nmeum> mps: ok, will change the commit message
2021-08-19 19:22:41 <ikke> I like git show -s --format=reference <commit>
2021-08-19 19:23:49 <nmeum> mps: changed the commit message, merge?
2021-08-19 19:27:07 <kunrooted[m]> god damn, sounds hard
2021-08-19 19:27:26 <mps> nmeum: looks ok
2021-08-19 19:28:22 <nmeum> mps: is that a yes? :D
2021-08-19 19:28:35 <mps> yes, it is yes :)
2021-08-19 19:28:38 <nmeum> ok, sweet
2021-08-19 19:29:24 <mps> I will test again but when it pass builders
2021-08-19 19:29:53 <mps> and I hope we will read soon that alpine boots on hifive
2021-08-19 19:31:51 <nmeum> it does already
2021-08-19 19:32:25 <mps> I mean with u-boot and kernel from the repo
2021-08-19 19:32:59 <mps> without needs of users to compile something
2021-08-19 19:33:25 <nmeum> yeah that would be ideal
2021-08-19 19:33:49 <nmeum> we also need something analog to the generic arm images for riscv
2021-08-19 19:34:40 <nmeum> one step at a time
2021-08-19 19:36:28 <mps> we 'need' to persuade olimex to make riscv laptop like this one https://www.olimex.com/Products/DIY-Laptop/
2021-08-19 19:41:06 <mps> DavyLandman[m]: we already have u-boot for xu4, because it actually xu3 boot, they are same according to u-boot docs
2021-08-19 19:42:07 <mps> u-boot docs/README.odroid => Board config: odroid-xu3_config for XU3/XU4/HC1
2021-08-19 19:44:20 <DavyLandman[m]> mps aha, okay, I'll try to do that this weekend. Let you know how it goes. Sorry, should have check it. I was at the same time check-in for n2 (which is missing) and the uboot for xu4, and got confused by expecting files present for both.
2021-08-19 19:45:42 <mps> yes, n2 is missing but I hope we can add it easily
2021-08-19 19:46:30 <DavyLandman[m]> That would be nice. I was reading their uboot stuff and it looked a bit dicey, pulling in blobs from another repo and stuff.
2021-08-19 19:46:54 <DavyLandman[m]> The n2 I can test this weekend as well. 
2021-08-19 19:47:35 <mps> ok, will try to ad n2 tomorrow
2021-08-19 19:47:47 <DavyLandman[m]> But I can only do that for a short while, as it has to replace something in my network that is broken, so I cannot leave that too long in a a disconnected/debug environment.
2021-08-19 19:48:00 <DavyLandman[m]> Ok, tnx.
2021-08-19 19:48:36 <mps> DavyLandman[m]: you are welcome
2021-08-19 21:31:29 <Ariadne> nmeum: i was able to get u-boot + opensbi from alpine to boot on my unleashed board.  will push to aports git shortly
2021-08-19 21:52:06 <mps> kpcyrd: we don't ship 'raspi' images
2021-08-19 21:52:34 <Ariadne> yes, technically they are rpi
2021-08-19 21:53:28 <Ariadne> i don't really see the problem -- kpcyrd made a typo, what of it
2021-08-19 21:53:47 <Ariadne> there are plenty of typos in aports.git
2021-08-19 21:54:02 <mps> well, commiter should be more careful
2021-08-19 21:54:26 <mps> and ofc, we all make mistakes
2021-08-19 21:55:04 <mps> I just wanted to note this, not to criticize anyone
2021-08-19 21:55:53 <kpcyrd> not sure if I'm missing context, I've assumed it's a common abbreviation :)
2021-08-19 21:56:21 <mps> well, it is not afaik
2021-08-19 21:56:38 <mps> as Ariadne told we use 'rpi' term
2021-08-19 21:57:54 <kpcyrd> I see, thanks for pointing it out :)
2021-08-19 21:57:56 <mps> my first thought when saw this commit msg was that you added 'raspi' image
2021-08-19 21:58:17 <mps> kpcyrd: np :)
2021-08-19 21:58:49 <mps> this is not a bug, I think
2021-08-20 06:40:29 <DavyLandman[m]> mps i just got my n2 delivered, it's a n2+, I checked it has a specific  dtb, so just in case, could you do the n2-plus? Tnx
2021-08-20 06:50:09 <xsteadfastx> if i have to copy something in my abuild from the dir where the APKBUILD file is in to $builddir? what is the variable of the dir where the APKBUILD is in?
2021-08-20 06:51:04 <xsteadfastx> $startdir 
2021-08-20 06:51:07 <xsteadfastx> :)
2021-08-20 06:51:17 <xsteadfastx> should have read the docs better
2021-08-20 06:55:30 <bratkartoffel> if the stuff you need to copy is within the "sources", you can also use $srcdir
2021-08-20 06:55:44 <bratkartoffel> this way your files are also checksumed
2021-08-20 06:57:25 <PureTryOut> Ariadne, ikke: had any of you had a chance yet to look at the apk output I posted? Currently I'm unable to update my system or install/remove anything 😅
2021-08-20 06:57:40 <Ariadne> nope
2021-08-20 06:57:50 <Ariadne> can you link me agai 
2021-08-20 06:57:51 <Ariadne> n
2021-08-20 07:02:04 <xsteadfastx> bratkartoffel: thanks... yeah :) now i have to find a way to confirm that GO111MODULE was used
2021-08-20 07:07:26 <PureTryOut> 
ACTION posted a file: (14578KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/SJaYkShjgVNuEAaaciZlnots/apk.log >

2021-08-20 07:07:27 <PureTryOut> Ariadne: ☝️
2021-08-20 07:07:42 <PureTryOut> That was while running `apk upgrade -a`
2021-08-20 07:08:04 <nmeum> Ariadne: sweet, support for more riscv boards \o/
2021-08-20 07:11:24 <mps> DavyLandman[m]: ofc, will look later today
2021-08-20 07:14:19 <mps> DavyLandman[m]: u-boot config says 'CONFIG_IDENT_STRING=" odroid-n2/n2-plus"' so looks like both will work with same u-boot
2021-08-20 07:26:11 <DavyLandman[m]> True, and the dtb is only slightly different. 
2021-08-20 07:30:14 <mps> nmeum: re MACB initialization: u-boot should initialize it if u-boot need network (netboot) but I think also kernel should initialize if u-boot (or other bootloaders) didn't
2021-08-20 07:30:39 <mps> maybe this is kernel bug
2021-08-20 07:32:01 <mps> but who knows what is done by riscv coders, looks like we will have somewhat stable kernel from 5.16
2021-08-20 07:50:18 <mps> DavyLandman[m]: just pushed main/u-boot: add support for odroid-n2 board
2021-08-20 07:50:56 <mps> enjoy your weekend playing with your new and shiny board, and report bugs or success to us
2021-08-20 08:27:49 <DavyLandman[m]> <mps> "enjoy your weekend playing..." <- lol, tnx...
2021-08-20 08:33:24 <DavyLandman[m]> mps: can you point me to the url that contains CI images?
2021-08-20 08:35:35 <DavyLandman[m]> is this it? https://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/
2021-08-20 08:36:59 <mps> CI images?
2021-08-20 08:38:10 <DavyLandman[m]> I might be wrong, but I assumed at the end of the CI process something like this "image" is produced: https://dl-cdn.alpinelinux.org/alpine/v3.14/releases/aarch64/alpine-uboot-3.14.1-aarch64.tar.gz
2021-08-20 08:39:13 <mps> no, it is in edge release, not stable
2021-08-20 08:39:49 <DavyLandman[m]> true, so I was looking for that link on edge releases, but I was having problems finding it
2021-08-20 08:39:53 <mps> when builder finish, apk update and apk add u-boot-odroid
2021-08-20 08:40:24 <Ariadne> PureTryOut: can you paste your apk world file
2021-08-20 08:41:01 <mps> DavyLandman[m]: apk search u-boot-odroid 
2021-08-20 08:41:20 <DavyLandman[m]> mps: so I have to do that on another machine? the times before I just downloaded that image, extracted it onto an sd card, and got cracking.
2021-08-20 08:41:27 <mps> but builder is stuck for something right now
2021-08-20 08:42:30 <mps> DavyLandman[m]: apk --aarch aarch64 --root /some_rootfs add u-boot-odroid
2021-08-20 08:43:06 <DavyLandman[m]> mps: ah check, tnx 🙂. I keep getting surprise how well alpine is layed-out.
2021-08-20 08:43:40 <mps> DavyLandman[m]: look at some of these scripts I made to get idea how to install alpine on arm https://arvanta.net/alpine/
2021-08-20 08:50:41 <DavyLandman[m]> mps: I'll start debugging fun tomorrow evening, but just to be sure, I saw your commit only changed the uboot config, shouldn't also something change in the kernel config to add the n2 dtbs? Or did I also miss the fact that they were already there?
2021-08-20 08:50:49 <nmeum> mps: is there any easy way to sync the linux-edge configs in regards to non-architecture specific features?
2021-08-20 08:51:08 <nmeum> because there is a lot of architecture-independed stuff that is enabled for all other architectures but not for riscv
2021-08-20 08:51:13 <xsteadfastx> howto deal with python modules that doesnt offer a setup.py?
2021-08-20 08:53:28 <xsteadfastx> beets needs this module in its new version and i try to package it: https://github.com/beetbox/confuse
2021-08-20 08:55:50 <mps> DavyLandman[m]: right, first thing is to get working u-boot and after that you can try kernel and then see which drivers and options must be enabled and maybe which are 'good to have'
2021-08-20 08:56:27 <mps> else we will have 'make allyesconfig' which is toooooo big
2021-08-20 08:56:57 <DavyLandman[m]> ok, clear, I'll see if I can bootup the uboot tonight, maybe learn a bit already. 
2021-08-20 08:57:07 <mps> nmeum: this is somewhat a 'limbo'
2021-08-20 08:57:24 <hjaekel> xsteadfastx can you use the Makefile?
2021-08-20 08:58:02 <mps> ncopa and I discussed this few times but still don't have 'proper' plan how to make kernels 'similar'
2021-08-20 08:58:08 <PureTryOut> 
ACTION posted a file: world (3KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/jjoAORfdYNkQvdadaKhmNlEb >

2021-08-20 08:58:11 <nmeum> mps: it would be nice to have the same scheduler/accounting/networking/… features accross all architectures
2021-08-20 08:58:12 <PureTryOut> Ariadne: ☝️
2021-08-20 08:58:27 <nmeum> I can manually diff the configs and copy stuff
2021-08-20 08:58:51 <xsteadfastx> hjaekel: i think i use the tar.gz from pypi... there is a generated setup.py in it... this i can use
2021-08-20 08:58:58 <mps> nmeum: yes, I agree. it would be nice but we didn't reached to this yet
2021-08-20 09:00:00 <mps> nmeum: I think we have to do this in 'small steps' and always discuss with ncopa and kernel team
2021-08-20 09:00:32 <hjaekel> xsteadfastx that's also an option
2021-08-20 09:03:45 <nmeum> mps: ok, I guess I will just send you MRs for individual subsystems configs then
2021-08-20 09:04:47 <nmeum> I just think it might be more efficient to just sync the entire config once
2021-08-20 09:06:24 <mps> eh, maybe
2021-08-20 09:06:54 <mps> I tried this for linux-lts virt and had bad day talking with ncopa
2021-08-20 09:07:05 <nmeum> I am only talking linux-edge though
2021-08-20 09:07:21 <mps> understand
2021-08-20 09:07:50 <mps> but long term is to make -lts and -edge with similar configs
2021-08-20 09:07:54 <nmeum> yes, sure
2021-08-20 09:08:21 <mps> else I would agree with your proposal
2021-08-20 09:08:26 <nmeum> I do think it would be nice to keep linux-edge and linux-lts in sync
2021-08-20 09:08:42 <nmeum> but for now I just want to sync the x86_64 and riscv64 linux-edge configs
2021-08-20 09:09:13 <mps> well similar is enough, in sync is not possible practically
2021-08-20 09:09:19 <nmeum> yeah
2021-08-20 09:09:20 <nmeum> similar
2021-08-20 09:09:38 <nmeum> network options and cpu account stuff would be on my list currently
2021-08-20 09:09:43 <nmeum> should I just do that and send you an mr?
2021-08-20 09:10:04 <mps> ok, I will look over weekend what is useful to change for riscv64
2021-08-20 09:10:40 <mps> nmeum: sure, you can, but I would like to look diffs before merging
2021-08-20 09:10:46 <nmeum> ofc
2021-08-20 09:11:11 <nmeum> I will just tackle what annoys me most for now then ;)
2021-08-20 09:11:22 <mps> try to not enable any debuging options
2021-08-20 09:11:49 <nmeum> i will try to keep changes minimal for now
2021-08-20 09:12:02 <mps> nice to hear :)
2021-08-20 09:12:26 <mps> I also like changes in 'small' steps if they are not urgent
2021-08-20 09:12:31 <nmeum> yes, I agree
2021-08-20 09:13:13 <mps> have to repeat, I really trust you that you will do the best and right
2021-08-20 09:14:03 <mps> and hope you will agree with my idea to split vim, one day in long future ;)
2021-08-20 09:14:45 <mps> or it should be written as 'far future'
2021-08-20 09:15:00 <nmeum> hehe
2021-08-20 09:19:02 <mps> looking back, I promised much too things for this weekend
2021-08-20 09:20:12 <mps> but I think I should first write about replace eudev with libudev-zero
2021-08-20 09:29:16 <clandmeter> PureTryOut: have you tried removing those versioned entries in world and run apk fix?
2021-08-20 09:30:59 <PureTryOut> I didn't even realize I have one. Note that outside of the portaudio ones, they were virtual packages
2021-08-20 09:31:12 <PureTryOut> But atm `apk fix` is also broken because of the same reason
2021-08-20 09:35:49 <clandmeter> PureTryOut: did you remove all =version lines?
2021-08-20 09:36:07 <PureTryOut> For now, except for the virtual packages
2021-08-20 09:36:22 <PureTryOut> Or should I remove those too?
2021-08-20 09:36:32 <clandmeter> you can try
2021-08-20 09:36:48 <PureTryOut> It does not fix anything 😉
2021-08-20 09:37:07 <PureTryOut> I just find it strange that this only happened after I tried to install a package I just made. The package itself did nothing strange
2021-08-20 09:37:35 <clandmeter> the package is listed in world?
2021-08-20 09:55:27 <PureTryOut> No
2021-08-20 09:55:37 <PureTryOut> It never was, it didn't even get that far
2021-08-20 09:55:44 <PureTryOut> Which makes it even stranger
2021-08-20 10:00:29 <clandmeter> maybe your installed db is corrupted?
2021-08-20 10:06:13 <mps> nmeum: during coffee pause I skimmed diffs for linux-edge, looks like if we start with 'syncing' config-edge.riscv64 with config-edge.aarch64
2021-08-20 10:06:41 <nmeum> mps: I actually just opened a bug in the issue tracker to discuss this issue in general
2021-08-20 10:06:52 <nmeum> #12933
2021-08-20 10:07:12 <mps> I mean, it looks less changes and aarch64 is better configured
2021-08-20 10:07:26 <nmeum> I looked into how debian handles this and they split architecture-specific and architecture-independed options into different files and then generate a single config using a python script something like that would be neat for our kernel packages as well
2021-08-20 10:07:27 <mps> aha, good
2021-08-20 10:08:34 <mps> heh, I thought something similar looking on some other kernel build system, but have fear it would too complicated for us
2021-08-20 10:09:49 <nmeum> we don't have to adopt what debian does, but I think implement
2021-08-20 10:09:57 <nmeum> *implementing something similar shouldn't be too complicated
2021-08-20 10:10:55 <mps> I don't think so
2021-08-20 10:11:45 <mps> but we can ask ncopa to do this for linux-lts first ;)
2021-08-20 10:12:14 <nmeum> (:
2021-08-20 10:15:52 <PureTryOut> clandmeter: I checked the db and didn't see anything special, but idk if the format is corrupt or something. How would I check?
2021-08-20 10:16:28 <PureTryOut> the package I tried to install is not present there either
2021-08-20 10:19:57 <clandmeter> PureTryOut: you could rename the db and try apk fix -s, it should  try to reinstall everything from world
2021-08-20 10:20:32 <clandmeter> if that doesnt work it must be one of your repos that has a problem.
2021-08-20 10:21:02 <clandmeter> but i dont know apk internals enough to debug it.
2021-08-20 10:21:10 <clandmeter> just some hacks i did before
2021-08-20 10:22:30 <PureTryOut> Well at least that reveals some packages that were installed by not longer exists
2021-08-20 10:23:18 <PureTryOut> Installing 2167 packages, nice
2021-08-20 10:37:33 <PureTryOut> Well that did fix the database, so I guess it was corrupt somehow indeed
2021-08-20 10:37:37 <PureTryOut> Not sure how that happened
2021-08-20 10:38:10 <PureTryOut> Let's see if I can reproduce it
2021-08-20 10:54:35 <PureTryOut> Huh, no this time it worked fine. Ok no clue what the hell happened 🤷
2021-08-20 10:54:50 <PureTryOut> But thanks for the tip clandmeter, removing the db (or well, renaming it) and letting it regenerate worked
2021-08-20 11:03:42 <mps> nmeum: https://tpaste.us/JqN4 starting riscv64 syncing config
2021-08-20 11:04:02 <nmeum> nice
2021-08-20 11:04:13 <nmeum> you also want to enable CONFIG_BLK_DEV_NVME
2021-08-20 11:04:15 <mps> more will come on requests and on upgrades
2021-08-20 11:04:18 <nmeum> or merge my config change in this regard first :p
2021-08-20 11:04:33 <mps> yes, I thought to add your change
2021-08-20 11:04:49 <nmeum> ah ok
2021-08-20 11:07:17 <mps> working with kernel changes on lxc with qemu-user is slow
2021-08-20 11:11:03 <nmeum> yeah, also noticed that
2021-08-20 11:11:08 <nmeum> I just started cross compiling the kernel instead
2021-08-20 11:11:26 <nmeum> actually very easy if you have a rv64 linux cross toolchain around
2021-08-20 11:16:43 <mps> hah, I'm trying to use only alpine and not other distros
2021-08-20 11:17:01 <mps> and I'm successfull at this :)
2021-08-20 11:17:18 <mps> so don't have cross tools
2021-08-20 11:25:58 <nmeum> mps: you have to build your own cross toolchain for this, but you can just use with abuild as you would normally on Alpine
2021-08-20 11:26:01 <nmeum> no need for other distro
2021-08-20 11:26:17 <nmeum> https://github.com/riscv/riscv-gnu-toolchain
2021-08-20 11:48:38 <mps> 9355f64b34a9
2021-08-20 11:48:46 <mps> hmm
2021-08-20 11:49:05 <mps> 9355f64b34a9f6a43b8f2b33f25dbc643662afb5
2021-08-20 11:53:44 <nmeum> do you want me to test this?
2021-08-20 11:54:53 <nmeum> 
ACTION starts cross compiling

2021-08-20 11:55:12 <mps> nmeum: you are so fast, wrote same msg to close :)
2021-08-20 11:55:55 <mps> nmeum: just in case keep previous apk 
2021-08-20 11:56:00 <nmeum> always
2021-08-20 11:56:07 <mps> nice :)
2021-08-20 11:57:38 <mps> I want to add chromebook support for linux-edge aarch64, but this will take time to test
2021-08-20 11:57:57 <mps> arm64 chromebooks*
2021-08-20 12:58:22 <nmeum> mps: 5.13.12-4-edge works well, thanks
2021-08-20 13:01:10 <kpcyrd> hmm, https://github.com/xxx/yyy/commit/fullcommithash.patch is considered a `volatile source`, is this the commit could theoretically be garbage collected?
2021-08-20 13:02:32 <ikke> kpcyrd: the index part of the patch can change
2021-08-20 13:02:54 <ikke> And so the hash of the patch will change
2021-08-20 13:03:03 <kpcyrd> index?
2021-08-20 13:03:30 <kpcyrd> ah, found it
2021-08-20 13:03:37 <kpcyrd> ikke: I see, thanks!
2021-08-20 13:06:20 <ikke> To be honest, I don't know why it changes, but we've seen it happen
2021-08-20 14:28:29 <mps> nmeum: good to hear
2021-08-20 14:29:53 <mps> huh, this is becoming nonsense, adding gnupg to mutt depends
2021-08-20 14:30:33 <mps> can I 'call' TSC to discuss such nonsenses
2021-08-20 14:32:19 <nmeum> have you tried talking to jakub first?
2021-08-20 14:32:52 <mps> no, he is not on IRC and I don't like our mailing lists
2021-08-20 14:33:25 <nmeum> you can comment on gitlab commits
2021-08-20 14:33:57 <nmeum> at least that's what I personally do when I have comments/questions/issues with individual commits
2021-08-20 14:34:31 <mps> hmm, maybe this is good idea (at least because I don't see better one)
2021-08-20 14:34:55 <nmeum> iirc our policy has always been that optional dependencies shouldn't be added to $depends so users are not forced to install them when they don't need them
2021-08-20 14:35:20 <mps> but I thought in general, do not add dependencies if they are not essentially needed
2021-08-20 14:35:40 <mps> nmeum: yes, right
2021-08-20 15:06:59 <mps> Hello71: just added this https://arvanta.net/alpine/libudev-zero/ 'Setting libudev-zero on Alpine'
2021-08-20 15:07:21 <mps> comment, fixes and other improvements are welcome
2021-08-20 15:07:29 <mps> comments*
2021-08-20 15:07:43 <Hello71> i don't understand, isn't the second part the same as https://github.com/illiliti/libudev-zero#hotplugging
2021-08-20 15:08:40 <mps> yes
2021-08-20 15:08:48 <Hello71> but you said those instructions didn't work
2021-08-20 15:08:51 <mps> to explain
2021-08-20 15:09:28 <mps> I had extra rule for input devices in my local mdev.conf and because this it didn't worked
2021-08-20 15:10:04 <Hello71> yes, mdev has this -exec footgun
2021-08-20 15:10:34 <mps> using clean (as shipped on alpine) with these extra rules at the solved the problem
2021-08-20 15:10:58 <mps> I tested with usb mouse and keyboard, both works fine
2021-08-20 15:11:08 <Hello71> i think your instructions are not consistent? if you start with fresh system then you don't need to apk del eudev, just apk add libudev-zero. other users should have run setup-udev already so need rc-update add mdev
2021-08-20 15:11:30 <Hello71> also your second echo command will overwrite first
2021-08-20 15:12:36 <mps> right
2021-08-20 15:13:12 <Hello71> probably also not needed to apk del udev-init-scripts-openrc eudev-openrc
2021-08-20 15:13:14 <mps> but these are not intended to be instructions, just hints till we prepare 'guide'
2021-08-20 15:13:36 <mps> these are for people who already have eudev installed
2021-08-20 15:14:06 <mps> I intentionally installed eudev to test all this
2021-08-20 15:15:38 <mps> with 'real guide' to come if we decide to remove eudev and use libudev-zero by default
2021-08-20 15:20:38 <skarnet> if you write this guide, friendly reminder that mdevd is a better version of mdev and actually maintained :P
2021-08-20 15:31:19 <mps> skarnet: yes, I thought to add it later, but to repeat waiting for TSC decision about eudev
2021-08-20 15:31:43 <skarnet> sure
2021-08-20 15:32:06 <skarnet> again I don't think Alpine needs to move particularly swiftly, eudev isn't going to bitrot overnight
2021-08-20 15:35:39 <mps> yes, but I already switched and Hello71 also expressed interest in it. maybe someone else also want to switch
2021-08-20 15:36:16 <mps> so, why not to write short hints from my experience
2021-08-20 15:42:34 <orbea> mps: TSC decision about eudev? Is there some issue with eudev?
2021-08-20 15:44:20 <ikke> orbea: the maintainer doesn't want to maintain it anymore
2021-08-20 15:44:32 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/12
2021-08-20 15:45:34 <orbea> ah
2021-08-20 15:46:25 <orbea> "I'm going to give it up since gentoo/musl is moving to systemd+openembedded patches" ?!
2021-08-20 15:46:49 <valerius> did you hear that?
2021-08-20 15:46:59 <valerius> that was Lennart rapidly rubbing his hands together
2021-08-20 15:54:26 <jvoisin> I only hear the noise of people complaining, without helping to support something else than systemd.
2021-08-20 15:57:33 <mps> jvoisin: main problem is that most upstream projects supports only systemd and don't care for other (at least I see it as such)
2021-08-20 15:58:15 <orbea> also poettering bans you if you talk back
2021-08-20 15:59:10 <valerius> jvoisin, it's just a joke to make light of the situation...
2021-08-20 15:59:51 <jvoisin> it's always the same joke, and people are always shitting on Lennart
2021-08-20 16:01:20 <valerius> or maybe they're just laughing as he achieves world domination
2021-08-20 16:03:21 <ericonr> 
ACTION now understands why skarnet tires of this conversation

2021-08-20 17:31:56 <mps> what does this mean '>>> ERROR: linux-edge-chromebook*: Split function set arch="aarch64" for linux-edge-chromebook, use subpackages=pkg:split:arch format instead'
2021-08-20 17:32:11 <mps> and how to solve it
2021-08-20 17:32:59 <ikke> mps: don't set arch in the split function, set it in the subpkg list
2021-08-20 17:35:05 <mps> ikke: I have this 'subpackages="$pkgname-dev:_dev:$CBUILD_ARCH $pkgname-chromebook"'
2021-08-20 17:35:52 <mps> not sure how to set split function for it
2021-08-20 17:36:58 <mps>  $pkgname-chromebook:_chromebook and create separate _chromebook function
2021-08-20 17:41:11 <mps> I already have 'pkg/linux-edge-chromebook', why it is not automatically split
2021-08-20 17:41:51 <mps> but lets try
2021-08-20 18:04:37 <Ariadne> mps: fwiw libudev zero is probably what we will use, it’s just a matter of figuring out the transition requirements
2021-08-20 18:08:33 <mps> Ariadne: ok, we are not in hurry yet, I think
2021-08-20 18:12:24 <mps> looks like I managed to integrate chromebook kernels to linux-edge
2021-08-20 18:12:44 <mps> chromebooks kernel*
2021-08-20 18:13:35 <mps> not perfect but good starting point
2021-08-20 18:24:27 <Ariadne> PureTryOut: you have 4 different .makedeps virtuals, and some cmd:[foo] things in world, try removing the makedeps and fixing world to use the actual packages for now
2021-08-20 18:28:28 <PureTryOut> Didn't help. But I already resolved it by renaming the installed db and letting apk reinstall everything
2021-08-20 18:30:47 <PureTryOut> So I guess somehow the db went corrupt
2021-08-20 20:45:54 <ikke> anyone have an idea why on the builders apk thinks libcrypto1.1 only contains these(https://tpaste.us/dPol) files, unless I run apk fix libcrypto1.1?
2021-08-20 22:06:25 <Ariadne> ikke: maybe related to openssl3 transition
2021-08-20 22:06:48 <ikke> yea
2021-08-20 22:46:18 <dalias> am i imagining things or was there a blender package at one time?
2021-08-20 22:48:13 <ikke> c0e7af5325aaf983e87350c353230a3966b735a4
2021-08-20 22:48:30 <dalias> :/
2021-08-20 22:49:05 <dalias> what's wrong with opencolorio ?
2021-08-20 22:49:46 <Ariadne> fails to build
2021-08-20 22:50:07 <ikke> # fails to build with OpenEXR 3
2021-08-20 22:50:25 <ikke> 31667ddbfdbdd84268406531894c6ed30b0baa6b
2021-08-20 22:50:31 <Ariadne> we upgraded OpenEXR to latest version yes
2021-08-20 22:50:37 <dalias> :(
2021-08-20 22:50:42 <Ariadne> because the old one was quite old and had many vulnerabilities
2021-08-20 22:51:22 <dalias> ah it's some hdr color thing :/
2021-08-20 22:51:35 <dalias> is there an open bug for it?
2021-08-20 22:53:17 <ikke> I don't see one
2021-08-20 22:58:13 <ikke> make[2]: *** No rule to make target 'ext/dist//usr/lib/libHalf-2_4.a', needed by 'src/OpenColorIO/libOpenColorIO.so.2.0.1'.  Stop.
2021-08-20 23:01:05 <dalias> libopencolorio should not be a .so
2021-08-20 23:01:26 <dalias> back when i had it installed, it constantly broke shit from abi incompat between versions
2021-08-20 23:01:33 <dalias> it should just be static linked
2021-08-20 23:19:36 <Ariadne> :D
2021-08-20 23:50:57 <Thermi> What's the criteria for moving from testing to community?
2021-08-21 00:34:40 <Ariadne> does it work
2021-08-21 00:34:53 <Ariadne> does the maintainer want to do it?
2021-08-21 00:34:57 <Ariadne> thats basically it
2021-08-21 00:43:59 <Thermi> I see, ty
2021-08-21 07:49:52 <mps> Thermi: what? kopano? ;)
2021-08-21 09:58:52 <mps> mutt APKBUILD have 'suid' in options. anyone knows why and is it really needed
2021-08-21 09:59:44 <ikke> c172eceed77bc0330347b09a284d86d99da6146f
2021-08-21 10:01:25 <mps> hmm, where is the mutt_dotlock
2021-08-21 10:03:06 <ikke> This was in 2015, 6 years ago
2021-08-21 10:03:56 <mps> yes, but we don't ship mutt_dotlock
2021-08-21 10:04:26 <mps> i.e. we don't build it
2021-08-21 10:04:58 <mps> src is mutt-2.1.1/mutt_dotlock.c
2021-08-21 10:05:22 <ikke> yes, I see
2021-08-21 10:05:22 <donoban> z
2021-08-21 10:05:28 <donoban> (ups)
2021-08-21 10:05:52 <ikke> mps: can it be that upstream disabled it by default at some point?
2021-08-21 10:07:08 <mps> no, upstream have '--enable-external-dotlock' configure option, and we don't use it on Alpine
2021-08-21 10:07:53 <ikke> What I mean is that it might have been the default
2021-08-21 10:07:58 <ikke> in an older version
2021-08-21 10:08:00 <mps> I can't remember if it is ever was default in upstream (I'm long time mutt user)
2021-08-21 10:08:51 <mps> ikke: yes, I understand. but still can't remember was it ever default, though I remember it is discussed some years ago
2021-08-21 10:10:37 <mps> but it is not important now, I think. I can ask current upstream but doubt it does matter
2021-08-21 10:10:45 <nmeum> I think we can just remove the option
2021-08-21 10:10:58 <nmeum> should be a no-op if the package doesn't contain any suid binaries
2021-08-21 10:11:04 <mps> nmeum: you took words from my mouths
2021-08-21 10:12:49 <ikke> yes, it just allows suid binaries if present
2021-08-21 10:13:02 <nmeum> yep
2021-08-21 10:13:15 <ikke> https://gitlab.com/muttmua/mutt/-/commit/440f7e9048adfe577935df7311582cf0bafdfe4d seems to imply that option is already 20+ years old
2021-08-21 10:14:38 <nmeum> do we want to upgrade to busybox 1.34.0 before 3.15 is released? if so: would welcome more people testing !24465
2021-08-21 10:14:43 <nmeum> currently testing it locally on my systems
2021-08-21 10:15:32 <ikke> maybe I can include it in the CI image
2021-08-21 10:19:09 <mps> nmeum: sure, I'm always interested in testing busybox
2021-08-21 10:24:33 <nmeum> ty
2021-08-21 10:49:06 <nmeum> Ariadne: any idea what this might be about https://gitlab.alpinelinux.org/alpine/aports/-/issues/12817#note_175888 ? looks to me like libatomic is broken on riscv64
2021-08-21 10:49:23 <ikke> #12817
2021-08-21 11:42:58 <mps> nmeum: installed bb 1.34.0 and using it now. didn't noticed any problem yet. lets test it few days
2021-08-21 14:30:14 <nmeum> mps: i also didn't notice any problems yet, let's hope it stays that way
2021-08-21 15:53:41 <donoban> what is the best path for checkout MR branch?
2021-08-21 15:54:07 <ikke> donoban: gitlab shows instructions under the "checkout branch" button
2021-08-21 15:54:24 <donoban> uhM, let me check thanks ikke 
2021-08-21 15:57:51 <donoban> I was doing it in a more difficult way
2021-08-21 16:01:10 <donoban> ok, another one testing busybox 1.34
2021-08-21 16:32:13 <Ariadne> nmeum: no idea
2021-08-21 18:19:04 <nmeum> donoban: you can also just append .patch to the MR curl that and pipe it into git-am(1)
2021-08-21 18:38:32 <Misthios> I was wondering if llvm12 will be available in 3,15 or wil it be skipped?
2021-08-21 18:39:12 <ikke> Probable skipped
2021-08-21 18:39:36 <ikke> It's not even in testing yet
2021-08-21 18:39:52 <Misthios> hm, when is the 3,15 freeze?
2021-08-21 18:40:26 <ikke> I expect next month
2021-08-21 18:42:28 <Misthios> would that be enough time to try to get llvm12 in? (saw that cogitri was working on it few moneths/weeks ago)
2021-08-21 18:44:09 <ikke> Depens on how long it takes to get it in proper shape
2021-08-21 18:45:54 <Misthios> i might be able to look at it next week if no one is working on it now
2021-08-21 19:13:14 <mps> Misthios: would be nice because llvm12 is needed for zig 0.8.0 upgrade
2021-08-21 19:18:07 <Misthios> Yup thats the reason i want it 
2021-08-21 19:18:18 <Misthios> River needs zig,zig needs llvm
2021-08-21 19:49:45 <Thermi> Bump pkgrel when moving from testing to community? The package is still the same.
2021-08-21 19:52:16 <ikke> not necessary
2021-08-21 19:53:13 <DavyLandman[m]> mps: I've tried multiple times, but the u-boot of n2 is not even picked up by the n2. I've tried flashing the u-boot of archlinux arm, and the same "flashing" commands to the SD card, then suddenly prints the u-boot loading. So the bootloader is not even seeing the the u-boot as something it want's to try and load.
2021-08-21 19:53:33 <DavyLandman[m]> all I'm getting is this printed in a loop:
2021-08-21 19:53:33 <DavyLandman[m]> > CHK:1F;USB:8;LOOP:4;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;CHK:1F;USB:8;LOOP:5;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;CHK:1F;USB:8;
2021-08-21 19:53:59 <DavyLandman[m]> which I assume is the bootloader going through the different candidates for boot images, and not seeing a thing.
2021-08-21 19:54:16 <DavyLandman[m]> any tips on what I could try?
2021-08-21 19:57:48 <DavyLandman[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/fpjemnPHnXIHPGEpeIIXaxEr/message.txt >

2021-08-21 19:58:11 <DavyLandman[m]> 00000000: 29b4 c6dd a9d4 e80d cdc9 e4b1 0a57 9a82  )............W..
2021-08-21 19:58:11 <DavyLandman[m]> xxd uboot-alpine.bin | head -n 2
2021-08-21 19:58:11 <DavyLandman[m]> 00000010: 4041 4d4c f0ff 0000 4000 0101 0000 0000  @AML....@.......
2021-08-21 19:58:37 <DavyLandman[m]> 00000010: b077 0a00 0000 0000 b077 0a00 0000 0000  .w.......w......
2021-08-21 19:58:37 <DavyLandman[m]> xxd uboot-alpine.bin | head -n 2
2021-08-21 19:58:37 <DavyLandman[m]> 00000000: 0a00 0014 1f20 03d5 0000 0001 0000 0000  ..... ..........
2021-08-21 20:00:32 <DavyLandman[m]> I would expect there to be some kind of common magic number at the head of it? but I'm not that well versed in u-boot binaries.
2021-08-21 20:03:11 <Thermi> Err, CI fails because it doesn't find py3-sleekxmpp and py3-soappy, which is in community
2021-08-21 20:04:43 <Thermi> DavyLandman[m], maybe it's the wrong arch or something. I can't tell exactly. I use uboot on aarch64 on Alpine and I might be able to take a look
2021-08-21 20:06:04 <mps> holy $whatever, matrix users have read about IRC usage
2021-08-21 20:06:30 <DavyLandman[m]> ooops, what did I do?
2021-08-21 20:07:10 <Thermi> Ah, nvm with the CI problem
2021-08-21 20:07:22 <Thermi> gitlab log view didn't show me the build of -sleekxmpp and -soappy failed
2021-08-21 20:07:42 <skarnet> DavyLandman[m]: I think it was a compliment to you and a jab at other matrix users ;)
2021-08-21 20:07:54 <DavyLandman[m]> interestingly, wikipedia says the u-boot image should start with the following 4 hex numbers: 27 05 19 56
2021-08-21 20:08:03 <mps> DavyLandman[m]: do not paste too much here
2021-08-21 20:08:21 <skarnet> head -n 2 is fine
2021-08-21 20:08:22 <mps> use tpaste.us
2021-08-21 20:08:48 <DavyLandman[m]> mps: true, I was contemplating the tradeoff to a pastebin. next time I will
2021-08-21 20:08:50 <mps> not some web/JS paste service, please
2021-08-21 20:09:15 <mps> tpaste.us is best
2021-08-21 20:09:29 <DavyLandman[m]> so, you mean, no screenshots of my terminal?
2021-08-21 20:09:33 <DavyLandman[m]> >:)
2021-08-21 20:09:39 <mps> DavyLandman[m]: I see that arch linux have some extra patches for u-boot
2021-08-21 20:09:41 <Thermi> Only fax
2021-08-21 20:10:39 <DavyLandman[m]> mps: I also tried armbians u-boot. that also works. and I think armbian uses stock u-boot.
2021-08-21 20:12:15 <DavyLandman[m]> Maybe a word document with the serial log in a non-monospaced font shared on wetransfer is the best option. 
2021-08-21 20:12:27 <mps> ah, arch uses hardkernel u-boot
2021-08-21 20:13:06 <mps> and last update in arch alarm git is 'Date:   Sun Dec 8 22:07:41 2019 +0000'
2021-08-21 20:13:28 <mps> hmm, maybe we should look at armbian how it is built
2021-08-21 20:13:44 <mps> DavyLandman[m]: did you tried xu4
2021-08-21 20:15:04 <DavyLandman[m]> mps: I've gotten a bit into a deadlock there. the n2 I have now will replace the xu4. so after I have finished debugging the n2 problems, I can switch it out for the xu4, and start debugging on that. but it's hosting a bit too much internal stuff that my partner won't be happy about if I drop that for "debugging" purposes.
2021-08-21 20:16:14 <DavyLandman[m]> if you prefer, I'll close the gitlab issue until I find out it doesn't work (because it looks it might just work already on the xu4)
2021-08-21 20:19:54 <DavyLandman[m]> this seems to be the commit that added n2 support for armbian: https://github.com/armbian/build/commit/2bd7f8efbd165e9e3a0db1cfb9d18dad1432cc4d
2021-08-21 20:20:23 <DavyLandman[m]> it looks like they are also using hardkernel's u-boot
2021-08-21 20:20:45 <DavyLandman[m]> s/using/started with/
2021-08-21 20:21:57 <mps> yes, looks like armbian is also use hardkernel
2021-08-21 20:22:01 <DavyLandman[m]> ok, they aren't anymore: https://github.com/armbian/build/blob/master/config/sources/families/meson-g12b.conf 
2021-08-21 20:22:25 <DavyLandman[m]> but line 34  does do some post-processing specific for the n2 :(
2021-08-21 20:23:00 <mps> yes
2021-08-21 20:24:03 <DavyLandman[m]> I just checked the serial log, it does print: "U-Boot 2015.01 (Jun 16 2021 - 08:31:32)" .... so that looks like the old hardkernel stuff :|
2021-08-21 20:26:05 <DavyLandman[m]> But what I'm wondering is, you managed to build an u-boot image. but if I flash that, it's just completly ignored. did if flash it wrongly?
2021-08-21 20:26:11 <DavyLandman[m]>  * But what I'm wondering is, you managed to build an u-boot image. but if I flash that, it's just completly ignored. did if flash it incorrectly?
2021-08-21 20:26:42 <mps> file in u-boot upstream 'says' something doc/board/amlogic/odroid-n2.rst
2021-08-21 20:27:38 <DavyLandman[m]> ah, the "get blobs from vendor part"?
2021-08-21 20:27:42 <DavyLandman[m]>  * ah, the "get blobs from vendor" part?
2021-08-21 20:28:32 <mps> yes
2021-08-21 20:28:35 <DavyLandman[m]> tnx, at the bottom there are some flashing instructions, I'll try those specific ones. I only did the first.
2021-08-21 20:28:52 <mps> so I doubt we can have it on alpine, yet
2021-08-21 20:29:57 <mps> but you are free to try to build it and if it works and no problems with licenses we maybe can merge it if the patch wouldn't be too big
2021-08-21 20:30:25 <mps> or, till some of developers buy this board and make it working
2021-08-21 20:30:34 <mps> alpine devs*
2021-08-21 20:31:55 <mps> btw, I think olimex boards are better, they are fully open
2021-08-21 20:32:28 <DavyLandman[m]> on one hand I'm tempted to make that patch, but it's a bit more out of my comfort zone than I think it smart for me to tackle currently.
2021-08-21 20:32:55 <DavyLandman[m]> I was just gonna try and pitch everyone the odroid n2+, but I think you are right, the olimex boards are more attractive in many ways.
2021-08-21 20:33:16 <mps> DavyLandman[m]: you can use armbian u-boot if you want with Alpine kernel if it works
2021-08-21 20:33:51 <mps> that is how I run some boards
2021-08-21 20:34:58 <DavyLandman[m]> true, but the alpine kernel doesn't include the n2 dtbs, (so I assume none of the amlogic specific code). I mean, compiling a custom kernel is fun, but I gotta prioritize sometimes. especially with regards to updates.
2021-08-21 20:35:27 <DavyLandman[m]> these franken-configs are nice, and feel great to get working, but 2y later, when you have to fix/update something, future you is less impressed
2021-08-21 20:36:50 <mps> DavyLandman[m]: /boot/dtbs-edge/amlogic/meson-g12b-odroid-n2-plus.dtb
2021-08-21 20:37:19 <mps> alpine linux-edge kernel
2021-08-21 20:38:14 <DavyLandman[m]> ah, I've been looking in the alpine-uboot-3.14.1-aarch64.tar.gz ...
2021-08-21 20:38:28 <DavyLandman[m]> but that is containing the lts kernel I see
2021-08-21 20:39:13 <mps> yes
2021-08-21 20:40:03 <DavyLandman[m]> I just did the dual flashing commands of the odroid-n2.rst upstream description. but that didn't magically made the n2 happy.. so yeah it's for sure the messy fip & vendor tools that is missing.
2021-08-21 20:41:03 <mps> ok, see tomorrow, too late is here now
2021-08-21 20:41:12 <mps> see you*
2021-08-21 20:41:25 <DavyLandman[m]> see you, thanks for the help
2021-08-21 20:41:36 <mps> np
2021-08-21 20:45:04 <DavyLandman[m]> If possible, could somebody here point me to an wikipage/repo on how to build one of those uboot archives yourself?
2021-08-21 20:46:43 <riverdc> hey all, can someone review !19978 ?
2021-08-21 20:55:14 <nmeum> whooo, more dependently typed programming languages \o/
2021-08-21 21:11:41 <danieli> the only ones i've used are ada 2012+, clojure, and idris
2021-08-21 21:34:37 <Cogitri> Misthios: I think LLVM12 Itself works now, but between GSoC, uni projects and actually doing holidays for once I haven’t gotten to the other LLVM projects (like CLang) yet
2021-08-21 21:35:06 <Cogitri> I would very much appreciate a hand with that though, otherwise I certainly won’t have the time to get it into 3.15 unfortunately
2021-08-21 21:36:30 <ikke> what gsoc project did you work on?
2021-08-21 21:37:15 <Cogitri> I’m mentoring GSoC for a Health tracking application for GNOME
2021-08-21 21:37:51 <Cogitri> Basically a thingie to reach your step/weight goals (and in the future remind you to drink enough water)
2021-08-21 21:38:16 <ikke> aha, nice
2021-08-21 21:44:48 <mps> not so good project. you forgot wine ;)
2021-08-22 07:07:57 <mps> !24478, I predicted this yesterday here
2021-08-22 07:08:27 <mps> I vote against, and very strongly against this
2021-08-22 07:09:15 <mps> Thermi: it is not against you personally
2021-08-22 08:06:53 <mps> fcolista: apk info -W /usr/lib/perl5/core_perl/Unicode/Normalize.pm => /usr/lib/perl5/core_perl/Unicode/Normalize.pm is owned by perl-5.34.0-r0
2021-08-22 08:07:49 <mps> and you are maintainer of the perl-unicode-normalize-1.26-r6, maybe it could be removed from repo
2021-08-22 08:16:32 <fcolista> goog, so now is part of the perl core
2021-08-22 08:16:38 <fcolista> going to remove it. Thanks!
2021-08-22 08:19:55 <mps> yaw :)
2021-08-22 08:22:02 <fcolista> it's only unicode-normalize that needs to be removed? Or other unicode-* has been integrated in core?
2021-08-22 08:27:18 <mps> base Unicode is alsi in core but it somewhat outdated, and new even have not about CVE fix, so I'm not sure what to do with it
2021-08-22 08:27:31 <mps> also*
2021-08-22 08:27:56 <mps> https://metacpan.org/dist/Encode/changes
2021-08-22 08:28:44 <mps> would wait for Tim Ledge to appear here and ask
2021-08-22 08:29:31 <fcolista> sounds good. In the meanwhile I removed perl-unicode-normalize
2021-08-22 08:29:32 <mps> huh
2021-08-22 08:29:52 <mps> and new even have note about CVE fix*
2021-08-22 08:30:16 <mps> and new even have note* about CVE fix
2021-08-22 08:30:32 <mps> what's with me this morning
2021-08-22 09:23:32 <Misthios>  /msg NickServ IDENTIFY Misthios JustWessol
2021-08-22 09:23:38 <Misthios> ffs
2021-08-22 09:23:42 <Misthios> kill me plz
2021-08-22 09:24:28 <ikke> And pick a stronger password :P
2021-08-22 09:24:42 <Misthios> yeah ik, this was just to try irc
2021-08-22 09:24:45 <Misthios> never changed it
2021-08-22 09:25:02 <Misthios> but for some reason ofttc doesnt allow a msg to nickserv in the lobby while others do
2021-08-22 09:25:10 <ikke> protip: first open a private window to nickserv, then identify, or even better, use certfp
2021-08-22 09:25:33 <ikke> /query nickserv should work
2021-08-22 09:25:40 <Misthios> yeah was planning to redo irc anyway
2021-08-22 09:25:42 <veiviser> the lobby?
2021-08-22 09:25:46 <Misthios> so moved up the list now
2021-08-22 09:26:10 <Misthios> the main empty thing that the server gives when u join
2021-08-22 09:26:28 <veiviser> you can message anyone from there
2021-08-22 09:26:38 <veiviser> you are probably trying to send a message before you are fully connected?
2021-08-22 09:26:56 <Misthios> dont think so, anyway this is getting off topic
2021-08-22 09:27:08 <Misthios> will redo irc stuff and get back to doing usefull htings
2021-08-22 09:27:10 <veiviser> or your client is blocking you for some reason, but yes
2021-08-22 09:27:11 <veiviser> good luck
2021-08-22 09:30:53 <mps> does oftc support certfp
2021-08-22 09:31:51 <ikke> yes
2021-08-22 09:32:10 <mps> oh, time to add it
2021-08-22 09:33:01 <mps> eh, already have it set but forgot :)
2021-08-22 10:20:34 <PureTryOut> So, problem. on aarch64 using dl-cdn as the mirror, `apk search polkit | grep libs` only lists polkit-elogind-libs while it should also list polkit-libs`. On x86_64 it does do this, just not on aarch64. The APKINDEX however does mention the package just fine, so not sure what is going on
2021-08-22 10:24:17 <ikke> PureTryOut: apk list does list both
2021-08-22 10:24:29 <PureTryOut> Not on aarch64 using dl-cdn for me
2021-08-22 10:24:33 <ikke> apk list | grep polkit.\*lib
2021-08-22 10:24:36 <PureTryOut> And another user reported it as well
2021-08-22 10:24:36 <ikke> it does for me
2021-08-22 10:25:08 <PureTryOut> Oh huh using your regex it does
2021-08-22 10:25:19 <PureTryOut> Why does a simple `apk search polkit | grep libs` not return the same though?
2021-08-22 10:25:24 <ikke> Don't know
2021-08-22 10:25:37 <ikke> fyi, that does not return polkit-libs for me either
2021-08-22 10:27:06 <ikke> PureTryOut: apk search -a does return it as well
2021-08-22 10:27:17 <ikke> apk search -a polkit | grep libs
2021-08-22 10:33:40 <PureTryOut> Oh huh ok
2021-08-22 10:34:43 <ikke> again, I don't know why there is this difference
2021-08-22 11:49:43 <mps> I think aarch64 builder is stuck
2021-08-22 12:28:56 <Guest4178> Morning
2021-08-22 19:06:16 <DavyLandman[m]> mps: regarding u-boot & the n2, it's a mess... read this discussion: https://github.com/armbian/build/pull/2943#issuecomment-873477002 so maybe better drop that idea completely. Even the kernels are a mess.. there are some bugs in mainline 5.10 that prevent the machine from rebooting.. seriously reconsidering this device, although it is quite a powerful ARM device.
2021-08-22 19:10:46 <DavyLandman[m]> (that rebooting mess is fixed in 5.13 kernel it seems, but it's been quite a ride)
2021-08-22 19:40:28 <mps> DavyLandman[m]: alpine linux-lts 5.10 also crashes on my allwinner A20 board
2021-08-22 19:41:04 <mps> you can try alpine linux-edge, it is now 5.13.12 version
2021-08-22 19:44:51 <DavyLandman[m]> mps: I tried many things till late last night, I created some franken versions with u-boots from other distros, but I'm just not that comfortable writing the u-boot boot.ini to manually load kernel and other steps. If there is a wiki that points out what to do, I could give it a try, but it has been quite a ride yesterday. 
2021-08-22 19:46:24 <mps> not sure but new u-boot supports extlinux.conf file which is practically same as syslinux config. it is a lot easier to understand and use
2021-08-22 19:47:47 <mps> with extlinux.conf you can have menu (numbers with options to select on boot) and you can have rescue boot option and diferent boot options to play with
2021-08-22 19:49:49 <DavyLandman[m]> aha, but the new u-boot is quite a ride it seems. okay, gotta stop early tonight, if there are some links you can point me to, I'm open to giving it a shot.
2021-08-22 19:53:13 <mps> I don't have any arm64 SBC so can't give you example I tested. I plan to order one olimex allwinner A64 board this week and then I will have (I hope) ready example
2021-08-22 19:53:36 <mps> of arm64 I only have two chromebooks
2021-08-22 19:56:06 <DavyLandman[m]> Ok, that sounds good.
2021-08-22 20:18:13 <mps> DavyLandman[m]: yes, that is life of 'niche' distro user/hacker: per aspera ad astra
2021-08-22 20:28:11 <Ariadne> is alpine a niche distro at this point
2021-08-22 20:28:27 <Ariadne> i have doubts
2021-08-22 20:28:28 <Ariadne> :p
2021-08-22 20:29:58 <mps> Ariadne: I would like to prove me wrong but I have doubts, also ;)
2021-08-22 20:30:40 <mps> few days ago I talked with people of olimex and they even didn't knew alpine linux exists
2021-08-22 20:31:13 <mps> and olimex makes and sells arm boards around the world
2021-08-22 20:31:58 <Ariadne> 
ACTION shrugs

2021-08-22 20:32:56 <mps> and I even don't like the idea that alpine become mainstream distro one day, then will come a lot of companies and hijack (still) good distro
2021-08-23 05:37:35 <DavyLandman[m]> I think alpine became mainstream inside docker community, but it's less known as a standalone distro. Just googling for alpine related questions shows this messy situation.
2021-08-23 06:47:30 <xsteadfastx> i try to add the changes from this note: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24498#note_176179
2021-08-23 06:48:12 <xsteadfastx> but abuild complains that i cant change the ownership of /etc/tlsrouter
2021-08-23 06:48:25 <xsteadfastx> install: can't change ownership of /home/marv/wip/aports/testing/tlsrouter/pkg/tlsrouter/etc/tlsrouter: Permission denied
2021-08-23 06:50:06 <ikke> xsteadfastx: how are you running this?
2021-08-23 06:50:17 <xsteadfastx> abuild -r
2021-08-23 06:50:35 <xsteadfastx> as my normal user
2021-08-23 06:55:52 <ikke> That should work
2021-08-23 07:01:32 <xsteadfastx> mh it doesnt
2021-08-23 07:14:54 <markand> DavyLandman[m], not mentioning that Alpine is also a car brand heh
2021-08-23 09:34:02 <SameExpert> I'm unable to use openrc before /usr is mounted. OpenRC requires libeinfo.so.1 which is in /usr/lib. To make it usable at the startup, the two ".so" files (libeinfo.so.1 and librc.so.1) in /usr/lib should be moved to /lib.
2021-08-23 09:49:04 <skarnet> 👍 openrc 👍
2021-08-23 09:52:54 <ikke> SameExpert: We do not really make sure the system runs without /usr
2021-08-23 09:53:05 <ikke> There are probably more dependencies on /usr
2021-08-23 10:48:26 <caskd> I wonder if s6 will ever be able to be run from init itself instead of using mkinitfs
2021-08-23 10:50:13 <caskd> Would be nice to make the init process uniform (even though it's likely most stuff needs to be setup before init)
2021-08-23 11:13:55 <nero> i have trouble finding the code that builds the alpine docker image listed here: https://hub.docker.com/_/alpine
2021-08-23 11:14:37 <ikke> https://github.com/alpinelinux/docker-alpine
2021-08-23 11:14:55 <ikke> https://github.com/alpinelinux/docker-alpine/tree/v3.14 for example
2021-08-23 11:15:08 <nero> i saw this, but i dont see any reference to minirootfs
2021-08-23 11:15:21 <nero> or apk or sth comparable
2021-08-23 11:15:58 <ikke> https://github.com/alpinelinux/docker-alpine/blob/master/fetch-latest-releases.lua#L67
2021-08-23 11:16:31 <ikke> Here you see the minirootfs included: https://github.com/alpinelinux/docker-alpine/tree/v3.14/x86_64
2021-08-23 11:16:56 <ikke> docker itself builds the images from this repo
2021-08-23 11:18:59 <nero> i see
2021-08-23 11:36:09 <skarnet> caskd: hm? s6 can run under any init, it's just wasteful to do so since some functionality is duplicated
2021-08-23 13:38:39 <Misthios> cogitri i started on llvm12 btw, is it just llvm12 and clang that need a upgrade or more? (and most of the runners hit the 1h limit with llvm only both x86 runners finished)
2021-08-23 14:09:28 <ikke> Misthios: You can increase the limit on your project (just do not make it too wild)
2021-08-23 14:21:12 <Misthios> Oh, didnt know that
2021-08-23 14:36:34 <Misthios> ikke, where can i find the settings?
2021-08-23 14:36:43 <Misthios> if i just google it and use docs i get some locks
2021-08-23 14:45:26 <Misthios> nvm i was blind 
2021-08-23 17:53:04 <Cogitri> Misthios: you’ll have to bump everything LLVM, so stuff like lldb and lld too. You can try greping for llvm.org in aports
2021-08-23 17:53:35 <Misthios> i looked at your llvm11 rebuilds
2021-08-23 17:54:00 <Misthios> but clang doesnt wanna play nice atm, so i just put all the errors in a file to look at tmrw
2021-08-23 18:01:39 <bl4ckb0ne> anybody working on building dotnet from source?
2021-08-23 18:03:32 <ikke> There was someone from MS here that mentioned it, but I believe they are working on a different build system that makes bootstrapping more trivial
2021-08-23 18:05:05 <bl4ckb0ne> neat
2021-08-23 18:05:31 <bl4ckb0ne> gave a quick try to the sdk build script and it died on its own filth
2021-08-23 18:18:36 <bl4ckb0ne> building the runtime wasnt conclusive either..
2021-08-23 18:42:08 <mps> I hope no one will merge anything from microsoft to alpine
2021-08-23 18:42:48 <bl4ckb0ne> lots of project dropped mono
2021-08-23 18:43:01 <bl4ckb0ne> i guess running stuff in podman isnt too bad for now
2021-08-23 18:43:43 <mps> imo, we should not give status of 'first class citizen' to evil companies
2021-08-23 18:45:20 <mps> could we have two pkgs which have same file name, I mean full path file name
2021-08-23 18:46:02 <mps> ofc, one of pkg have 'conflict' set
2021-08-23 18:46:24 <mps> i.e. depends="!iwd"
2021-08-23 18:47:10 <ikke> What is wrong with that solution?
2021-08-23 18:48:02 <mps> if someone installs iwd and later replace it with eiwd /etc/iwd/main.conf file is in both
2021-08-23 18:48:33 <ikke> then you need replaces=
2021-08-23 18:49:50 <mps> aha, so I need both? replaces and depends?
2021-08-23 18:50:03 <ikke> yes
2021-08-23 18:50:15 <ikke> replaces just tells apk it's ok for the package to take over the files of another package
2021-08-23 18:50:18 <mps> ikke: thanks (as usual)
2021-08-23 18:50:30 <ikke> depens="!pkg" tells apk they cannot be installed at the same time
2021-08-23 18:51:09 <mps> hmhmhm, you gave me anothor idea
2021-08-23 18:51:52 <mps> we can have both installed, and use replaces= even if they have same file?
2021-08-23 18:52:29 <mps> hm, doesn't make sense, I see
2021-08-23 18:53:02 <ikke> You could make a subpackage that contains just that file and have both depend on that
2021-08-23 18:53:10 <ikke> if that makes sense
2021-08-23 18:53:46 <mps> no, not really. better is to have conflict for them (at least for now)
2021-08-23 18:54:22 <ikke> ok
2021-08-23 18:54:41 <mps> ikke: thanks again
2021-08-23 18:55:17 <mps> you are best person on Alps^WAlpine world
2021-08-23 21:36:55 <donoban> the best and the fastest :d
2021-08-23 21:41:58 <mps> not fastest always, sometimes I 'beat' him ;)
2021-08-23 21:42:16 <ikke> :)
2021-08-23 21:42:22 <mps> but always the best
2021-08-23 21:42:23 <donoban> heh
2021-08-24 05:39:19 <bratkartoffel> can someone please take a look and merge !24283?
2021-08-24 05:47:11 <bratkartoffel> thanks ikke
2021-08-24 05:54:35 <ikke> bratkartoffel: yw
2021-08-24 05:58:13 <bratkartoffel> is the workaround for aarch64 from !24378 still active?
2021-08-24 05:59:01 <ikke> no, I reverted it
2021-08-24 05:59:46 <bratkartoffel> ok, so what should we do about it? i think that specific code causes the build hangs on aarch64
2021-08-24 06:00:41 <bratkartoffel> whats the reason why cores 80+ are enabled and not the first 80?
2021-08-24 06:00:51 <ikke> to balance the cores
2021-08-24 06:01:04 <ikke> 2 different numa domains
2021-08-24 06:01:17 <ikke> so some containers we run on the first 80, some on the 2nd 80
2021-08-24 06:01:44 <bratkartoffel> this would explain why some builds succeeed and some fail
2021-08-24 06:02:14 <bratkartoffel> still thinking about how to fix it...
2021-08-24 06:02:57 <ikke> Hello71 identified the code in jdk that is the problem
2021-08-24 06:03:19 <bratkartoffel> jep, just looking at the few lines which cause so much trouble
2021-08-24 06:24:24 <bratkartoffel> looks like i need to backport the jdk9 version to fix JDK-6515172
2021-08-24 06:48:22 <mps> \o good morning
2021-08-24 07:37:24 <ikke> Anyone got a clue why doxygen is hanging (building pipewire) on the builders?
2021-08-24 07:48:00 <Ariadne> dunno
2021-08-24 07:48:13 <Ariadne> i had to disable it on bullet
2021-08-24 07:48:17 <Ariadne> on riscv64
2021-08-24 07:48:23 <Ariadne> maybe related
2021-08-24 07:49:07 <ikke> strace just shows it waiting on a futex
2021-08-24 08:02:39 <Ariadne> awesome
2021-08-24 08:02:50 <ikke> ahuh
2021-08-24 08:07:32 <nmeum> mps: do you think it would be worthwhile to add support for u-boot to setup-disk from alpine-conf? that would should "the installer" to just work on boards which use u-boot as a bootloader. how do you install alpine on your arm boards?
2021-08-24 08:08:03 <Ariadne> ok lets see if this x86 craptop i bought has everything soldered on the motherboard
2021-08-24 08:08:30 <nmeum> basically just need to enhance this case distinction https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L554
2021-08-24 08:10:26 <mps> nmeum: you mean add u-boot in release tarballs?
2021-08-24 08:11:32 <nmeum> no, I mean adding support for u-boot to alpine-conf so it autogenerates the u-boot configuration file for you
2021-08-24 08:12:18 <mps> aha, hmm maybe this is good idea
2021-08-24 08:12:59 <nmeum> ok, I will work on a patch then
2021-08-24 08:13:13 <nmeum> would allow me to just run setup-alpine to install alpine to the ssd of the unmatched (:
2021-08-24 08:14:26 <mps> I install u-boot by 'crystal ball' method. every time i did it differently though in last times I'm trying to make some common methods, scripts mostly
2021-08-24 08:15:42 <mps> nmeum: all our current iso imgs support uefi boot and ncopa added grub to them to setup them bootable
2021-08-24 08:15:49 <Ariadne> holy shit
2021-08-24 08:15:52 <Ariadne> not soldered on
2021-08-24 08:16:27 <ikke> a miracle
2021-08-24 08:17:01 <mps> nmeum: here is my script to install u-boot on armv7 board https://arvanta.net/alpine/install-alpine-armv7-sbc/
2021-08-24 08:18:09 <mps> nmeum: and here is script to install armv7 virt iso img https://arvanta.net/alpine/install-armv7-qemu/ (this img is with grub)
2021-08-24 08:18:16 <Ariadne> huh
2021-08-24 08:18:23 <Ariadne> it also has a full size nvme slot
2021-08-24 08:19:41 <mps> nmeum: also, I made script to install riscv64 with u-boot on VM img, but because it still doesn't boot I didn't 'released' this script anywhere
2021-08-24 08:19:43 <nmeum> mps: yeah, I have my own scripts for the unmatched as well, but having that in the installer just makes it easier to use
2021-08-24 08:20:55 <nmeum> https://tpaste.us/1EV0 something like this maybe?
2021-08-24 08:21:20 <mps> nmeum: yes, mkimg.sh and other there needs fixes, and I have some local but didn't pushed to not make ncopa angry
2021-08-24 08:22:15 <mps> nmeum: looks ok at first glance
2021-08-24 09:05:29 <nmeum> mps: improved the patch a bit and just installed alpine to my unmatched ssd with it https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/28
2021-08-24 09:06:04 <nmeum> I don't think alpine-conf has an active maintainer atm, so if you approve it and/or want to test it I would just merge it
2021-08-24 09:32:22 <mps> nmeum: looks good except one thing I'm not sure. should 'default alpine' be 'default $KERNEL_FLAVOR'?
2021-08-24 09:33:00 <nmeum> oh indeed
2021-08-24 09:33:01 <nmeum> good catch
2021-08-24 09:33:04 <mps> and I feel bad last 3 days so don't have energy to test it now
2021-08-24 09:33:51 <nmeum> np, get well soon
2021-08-24 09:34:06 <nmeum> do you have any thoughts on https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/28#note_176378 ?
2021-08-24 09:34:30 <mps> thanks, I'm 'working' on improvement by resting a lot more :)
2021-08-24 09:36:57 <mps> nmeum: I think you know a lot better what options are needed for your riscv boards, so don't have anything to add/remove from above
2021-08-24 09:37:34 <nmeum> this should also be usable for arm boards etc
2021-08-24 09:38:07 <mps> yes, but with different parameters (and *quiet* removed)
2021-08-24 09:38:21 <nmeum> maybe we should just rely completly on the default update-u-boot values?
2021-08-24 09:38:26 <nmeum> and not pass bootdev explicitly?
2021-08-24 09:38:30 <nmeum> I think that makes more sense
2021-08-24 09:39:50 <mps> didn't tried for long without explicit bootdev, so not sure would it work with current kernels and initramfs
2021-08-24 09:40:10 <mps> I think it is worth to test
2021-08-24 09:41:16 <mps> also, maybe you notice that I have 'console=${console}' in APPEND line here: https://arvanta.net/alpine/install-alpine-armv7-sbc/
2021-08-24 09:42:46 <nmeum> you can set custom kernel parameters using the KERNELOPTS envirnoment variable which is read by setup-disk
2021-08-24 09:43:10 <nmeum> e.g. KERNELOPTS="rootwait console=ttySIF0,115200 earlyprintk earlycon=sbi" setup-disk -k edge -m sys /mnt
2021-08-24 09:43:48 <mps> aha, thanks. Somehow I missed to notice KERNELOPTS exitst
2021-08-24 09:56:42 <mps> nmeum: forgot to tell (in case you didn't noticed) that the kernel 5.14 probably will be released next week. it has some riscv bugfix and I hope it will work better than current 5.13, but as usual 'we will see'
2021-08-24 09:57:25 <nmeum> neat, the 5.13 kernel works suprisingly well on my unmatched
2021-08-24 09:57:42 <nmeum> though I am really looking forward to the upcoming u-boot release since I am still manually building git head at the moment
2021-08-24 09:58:32 <mps> aha, and I need to look at current master u-boot, didn't for some time
2021-08-24 10:01:14 <mps> I just joined #riscv
2021-08-24 10:02:42 <mps> (and I think it is time for me to find riscv ISA and chip docs to read them finally)
2021-08-24 10:06:03 <nmeum> I removed the -d argument from update-u-boot in setup-disk btw
2021-08-24 10:06:10 <nmeum> unless you have any objections I would just go ahead and merge this
2021-08-24 10:09:21 <mps> nmeum: 'Aproved' because I don't see approve button on MR
2021-08-24 10:10:09 <nmeum> \o/
2021-08-24 10:29:11 <ikke> anyone got a clue why my qemu edge vm with vga virtio suddenly cannot start xorg anymore since I upgraded it?
2021-08-24 10:29:55 <ikke> my user is in video / input
2021-08-24 10:30:10 <ikke> /dev/dri/card0 exists
2021-08-24 10:30:53 <ikke> Xorg.0.log fails with "Caught signal 6 (Aborted). Server aborting"
2021-08-24 10:32:06 <ikke> I see 'Loadmodule "glx"' and 'LoadModule "modesetting"'
2021-08-24 10:32:38 <ikke> Xorg.0.log: https://tpaste.us/pleW
2021-08-24 10:33:21 <ikke> oh, I may have an idea
2021-08-24 10:34:32 <ikke> Missing mesa-egl
2021-08-24 10:34:46 <ikke> That fixed it
2021-08-24 10:34:48 <ikke> Thanks for listening
2021-08-24 10:38:04 <mps> ikke: you are trying arm guest?
2021-08-24 10:38:28 <ikke> no, x86_64
2021-08-24 10:39:02 <mps> hmm, wonder why mesa-gl is not enough then
2021-08-24 10:39:59 <ikke> oh, maybe it is
2021-08-24 10:40:43 <ikke> no, it was not
2021-08-24 10:40:46 <ikke> I need mesa-egl
2021-08-24 10:41:40 <mps> aha, good to know. I thought mesa-egl is only needed on ARMs
2021-08-24 10:42:25 <mps> though I mostly run qemu with -nographic so I forgot details
2021-08-24 10:42:41 <ikke> Apparently it used to work without it (or something stopped depending on it)
2021-08-24 10:43:15 <mps> yes, I think this must be changed with qemu 6.0.0
2021-08-24 10:43:32 <ikke> Well, qemu on the host hasn't changed
2021-08-24 10:43:40 <ikke> it broke yesterday after I did an apk upgrade on the guest
2021-08-24 10:44:01 <mps> uhm, interesting then to investigate
2021-08-24 10:44:47 <mps> alpine is in guest?
2021-08-24 10:45:52 <mps> 
ACTION will be afk

2021-08-24 10:47:52 <ikke> yes, alpine is in my guest
2021-08-24 10:49:20 <ikke> testing out akms
2021-08-24 11:26:49 <nmeum> Ariadne: I think I figured out why libatomic is broken on riscv64, from the buildlog "checking for __atomic_load/store for size 1... yes" but this should be no since the builtins are not available on riscv64
2021-08-24 11:28:43 <nmeum> Ariadne: I think this check might return the wrong value because due to 0040-configure-Add-enable-autolink-libatomic-use-in-LINK_.patch the configure test code is linked against -latomic which in turn provides the __atomic_store_N built-in symbols the code is configure test code is checking for?
2021-08-24 11:30:41 <nmeum> is there some way to disable autoliniking against libatomic to test this theory?
2021-08-24 11:55:43 <nmeum> `gcc_no_link=yes ./configure` does seem to resolve this 🤔
2021-08-24 13:03:54 <Ariadne> hmm okay
2021-08-24 13:04:25 <Ariadne> i just added that patch because sircmpwn sent it to me to add
2021-08-24 13:05:04 <sircmpwn> this was a while ago
2021-08-24 13:05:15 <sircmpwn> but it gcc + libatomic is a real jackass on riscv64
2021-08-24 13:05:36 <sircmpwn> so if you want to test it out, remove it and start building packages which use libatomic, and you'll run into whatever issues originally motivated the patch soon enough
2021-08-24 13:09:50 <nmeum> Ariadne: I haven't looked into the -latomic shenanigans but, for example, if we build libatomic with `gcc_no_link=yes` it will not link the configure test programs against -latomic and should correctly detect which builtins are available I believe
2021-08-24 13:10:06 <nmeum> either way it would be nice to resolve this because every program using certain functions from libatomic is broken atm
2021-08-24 13:10:29 <Ariadne> i’m okay with whatever you want to do :)
2021-08-24 13:10:45 <nmeum> I don't know what I want to do :D
2021-08-24 13:11:51 <nmeum> probably best if upstream would just resolve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
2021-08-24 13:11:55 <Ariadne> i don’t have any ideas what to do yet.  i need to acquire coffee
2021-08-24 13:12:32 <nmeum> (:
2021-08-24 13:15:37 <Ariadne> and so i will defer to your judgement on the issue as i need to go find out if i accidentally broke my foot a week and a half ago when i kicked something back into place
2021-08-24 13:21:01 <nmeum> how does automake work can I somehow only set gcc_no_link for libatomic/configure but not for the top-level configure script?
2021-08-24 13:21:22 <nmeum> puh, interacting with autotools is always so painful
2021-08-24 14:40:02 <nmeum> Ariadne: !24570 if you have a better idea let me know. if I just built libatomic this seems to work, haven't built the entire thing yet and I am also not at all familar with gcc so idk what sideeffects this might have
2021-08-24 14:50:44 <Ariadne> looks good to me but can you do it as a separate patch to make my life easier
2021-08-24 14:57:33 <nmeum> sure, currently buliding gcc on the unmatched _if_ it works I can also do it as a seperate patch
2021-08-24 14:59:34 <nmeum> > /home/soeren/src/aports/main/gcc/src/gcc-10.3.1_git20210625/gcc/ipa-param-manipulation.c:1009:3: internal compiler error: in copy_rtx, at rtl.c:367
2021-08-24 14:59:36 <nmeum> *sigh*
2021-08-24 15:12:19 <Ariadne> :D
2021-08-24 15:12:27 <Ariadne> ipa-ssa strikes again
2021-08-24 15:12:51 <Ariadne> or hmm maybe that’s a different thing
2021-08-24 15:38:35 <tomalok> re: uboot -- i've been thinking what it might take to use that instead of grub-efi for EFI-capable cloud images?  i've noticed that EFI_STUB is enabled in the virt kernel now, so in theory the kernel itself is the bootloader?  (except how would one pass kernel opts to it without some kind of stable on-hardware storage which one doesn't have with
2021-08-24 15:38:35 <tomalok> instances in the cloud...)
2021-08-24 15:47:50 <nmeum> Ariadne: idk, I am giving up on this for now. maybe it is easier to remove the autolink-libatomic patch. how do other distributions handle this?
2021-08-24 15:54:29 <nmeum> https://github.com/riscv/riscv-gcc/issues/12
2021-08-24 15:54:33 <nmeum> 🤯
2021-08-24 15:57:50 <nmeum> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/linux.h;h=4afef7c228ca4b488d9af790f6e76d216ad85b27;hb=f00b5710a30f22efc3171c393e56aeb335c3cd39#l38
2021-08-24 15:58:11 <nmeum> if `--as-needed -latomic` is enabled by default, in which cases do we still need the --enable-libatomic-autolink patch then?
2021-08-24 16:35:54 <Ariadne> this is honestly something where i have deferred to other people who were doing more of the heavy lifting :p
2021-08-24 16:36:23 <Ariadne> i wonder if we should try to schedule a call on BBB to discuss the riscv64 port and get everyone synced back up on it
2021-08-24 16:38:26 <Ariadne> this gcc issue seems like a shitshow though
2021-08-24 16:59:23 <nmeum> i wolud be very happy to defer this issue to "other people" :p
2021-08-24 17:00:25 <nmeum> if there is a need to coordinate stuff we can surely schedule a bbb
2021-08-24 18:12:57 <Ariadne> yes i think the -latomic patch is redundant looking at the spec patch
2021-08-24 18:14:09 <Ariadne> oh i see
2021-08-24 18:14:27 <Ariadne> it only brings in libatomic in pthread mode
2021-08-24 18:15:04 <Ariadne> that seems sketchy
2021-08-24 18:16:05 <Ariadne> maybe just change the spec to use libatomic always
2021-08-24 18:16:11 <Ariadne> and drop the current patch
2021-08-24 18:39:55 <nmeum> oh indeed! that's interesting because the original version of the patch as committed to riscv-gcc actually added it unconditionally https://github.com/riscv/riscv-gcc/commit/2c4857d0981501b7c50bbf228de9e287611f8ae5
2021-08-24 18:39:58 <nmeum> I wonder why they changed that
2021-08-24 18:41:38 <nmeum> 
ACTION is confused

2021-08-24 19:07:58 <bl4ckb0ne> does cmake automatically builds in parallel in `build()` or I have to set it myself
2021-08-24 19:09:14 <ikke> You can set the amount of jobs in /etc/abuild.conf
2021-08-24 19:09:31 <bl4ckb0ne> i think `${JOBS:+ --parallel ${JOBS}}` is what im looking for
2021-08-24 19:09:51 <bl4ckb0ne> surprisingly only used for mesa stuff
2021-08-24 19:09:53 <bl4ckb0ne> meson*
2021-08-24 19:10:08 <ikke> cmake generates a makefile, which then picks up JOBS
2021-08-24 19:10:26 <bl4ckb0ne> even when called with --build ?
2021-08-24 19:11:14 <ikke> I would expect it
2021-08-24 19:12:00 <ikke> Apparently with meson, you do need to provide it
2021-08-24 19:12:10 <ikke> meson compile ${JOBS:+-j ${JOBS}} -C output
2021-08-24 19:13:17 <ikke> bl4ckb0ne: none of the APKBUILDs that use cmake use $JOBS
2021-08-24 19:14:26 <bl4ckb0ne> then it does makes sense
2021-08-24 19:23:58 <bl4ckb0ne> in case of a package variant with and without gui, is it better a single package with subpackage, or two seperate packages
2021-08-24 19:24:58 <ikke> single package is easier to keep up-to-date
2021-08-24 19:25:42 <bl4ckb0ne> is there something to do with pkgdir?
2021-08-24 19:27:12 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/zabbix/APKBUILD#L106
2021-08-24 19:27:16 <ikke> This builds 3 variants
2021-08-24 19:29:27 <bl4ckb0ne> thanks
2021-08-24 19:52:21 <craftyguy> Cogitri: can CI not build pipewire on arm and x86 within the 2hr time limit?
2021-08-24 19:52:29 <craftyguy> https://gitlab.alpinelinux.org/craftyguy/aports/-/pipelines/91290
2021-08-24 20:17:49 <mps> this 'Approved' button in MRs is misleading when author click it :)
2021-08-24 20:18:04 <mps> could it be disabled for author?
2021-08-24 20:18:06 <ikke> yes
2021-08-24 20:34:26 <Cogitri> craftyguy: I think doxygen for pipewire likes to get stuck at times
2021-08-24 20:34:43 <Cogitri> ikke already noticed that on the builders I think
2021-08-24 20:36:46 <ikke> ahuh
2021-08-24 20:43:46 <craftyguy> ah
2021-08-24 20:44:26 <craftyguy> Cogitri: ok, I was confused why it was timing out for my MR since I'm not actually touching pipewire's source 
2021-08-25 01:51:17 <andypost[m]> ir second day the pipewire eating most of builders
2021-08-25 06:37:12 <mps> rakudo and pipewire are builder blockers. disable them?
2021-08-25 06:38:06 <mps> disable by 'git rm ....'
2021-08-25 06:38:17 <mps> :)
2021-08-25 06:39:46 <mps> hmm, rakudo is blocker only for aarch64, and on one test
2021-08-25 06:41:29 <mps> pipewire is 'Killed' during build
2021-08-25 06:44:59 <ikke> that was me
2021-08-25 06:52:37 <mps> ah
2021-08-25 07:27:38 <PureTryOut> Still stuck 😢
2021-08-25 07:28:24 <ikke> Could we disable doc generation?
2021-08-25 07:30:37 <mps> ikke: no, it will be unusable without docs :P
2021-08-25 07:38:02 <nmeum> if doxygen is flaky I think we should rather fix doxygen
2021-08-25 07:38:35 <ikke> nmeum: I agree
2021-08-25 07:38:53 <ikke> but pipewire is now blocking the builders
2021-08-25 07:39:17 <nmeum> maybe disable for now and create an issue in gitlab or something along those lines?
2021-08-25 07:39:24 <nmeum> disable doc generation I Mean
2021-08-25 09:52:13 <ikke> maxice8: wb here :P
2021-08-25 09:52:47 <maxice8> ty, Cogitri switched to dendrite so I'm rebuilding
2021-08-25 09:53:03 <ikke> aha
2021-08-25 10:04:23 <maxice8> Should all be ok now
2021-08-25 11:21:29 <ecraven> ;) how do I set the default for -j for make invoked by abuild? it seems to be 4 here, but I'd like it to be 1 ;)
2021-08-25 11:21:42 <Hello71> abuild.conf
2021-08-25 11:21:50 <ikke> /etc/abuild.conf JOBS
2021-08-25 11:21:54 <ecraven> thanks!
2021-08-25 13:41:11 <fcolista> I have an issue with cni-plugins
2021-08-25 13:41:21 <fcolista> appears that they are not built correctly
2021-08-25 13:43:20 <fcolista> a kubernetes master is not able to find loopback plugin even if the path is correct. 
2021-08-25 13:43:24 <fcolista>  ./loopback 
2021-08-25 13:43:24 <fcolista> CNI loopback plugin version unknown
2021-08-25 13:44:50 <fcolista>  objdump loopback | less
2021-08-25 13:45:05 <fcolista> sorry
2021-08-25 13:45:21 <fcolista>  objdump -x loopback says: warning: private headers incomplete: bad valuearchitecture: i386:x86-64, flags 0x00000112:
2021-08-25 13:48:48 <ecraven> how would I cross-compile an APKBUILD for another architecture? I'm on x86_64, but would like to compile for aarch64?
2021-08-25 13:49:06 <ncopa> fcolista: does strace give any hints? iirc the cni-plugins are expected to be in /opt/ somewhere, but I think we move them to some other place
2021-08-25 13:50:03 <fcolista> we have moved the plubins into /usr/libexec/cni
2021-08-25 13:50:13 <ncopa> ecraven: that is generally not supported, however, we provide a scripts/bootstrap.sh script that will create a crosscompiler toolchain which you can use
2021-08-25 13:50:15 <fcolista> *plugins
2021-08-25 13:50:25 <ecraven> ncopa: so I *should* just compile on that system?
2021-08-25 13:50:32 <ncopa> ecraven: basicaly, you will have to build a crosscompiler for your target
2021-08-25 13:50:59 <ncopa> yeah, that is what we do. we build everything natively and dont do corsscompile
2021-08-25 13:51:19 <ncopa> well, we cross compile when bootstrap new architectures, but that is the only time we do so
2021-08-25 13:52:09 <ncopa> reasons for that is: its simpler than crosscompile, it allows us to run the testsuites to verify that packages actually work
2021-08-25 13:52:30 <ncopa> fcolista: thats how i remember. maybe check that kubernetes look there at all
2021-08-25 13:52:33 <fcolista> this is the strace https://tpaste.us/VEpe 
2021-08-25 13:53:03 <fcolista> yes, I've copied /usr/libexec/cni/* into /opt/cni/bin jsut to be sure
2021-08-25 13:53:07 <fcolista> *just
2021-08-25 13:53:09 <ncopa> ok
2021-08-25 13:53:22 <ncopa> it still does not find it?
2021-08-25 13:53:47 <fcolista> yes
2021-08-25 13:53:50 <fcolista> failed to find plugin \\\"loopback\\\" in path [/opt/cni/bin]
2021-08-25 13:54:11 <fcolista> loopback ofc is there and is executable
2021-08-25 13:54:26 <fcolista> i wonder if there's something wrong in the way it si built
2021-08-25 13:54:30 <ncopa> maybe kubernetes tries to execute it and parse the the version info?
2021-08-25 13:54:51 <fcolista> that's my guess to, and it fails due to the wrong version
2021-08-25 13:55:33 <ecraven> how do I ignore the signature for apk add?
2021-08-25 13:55:51 <ncopa> --allow-untrusted or similar
2021-08-25 13:56:16 <ncopa> yeah, htats it.
2021-08-25 13:56:18 <ncopa>   --allow-untrusted     Install packages with untrusted signature or no
2021-08-25 13:56:18 <ncopa>                         signature
2021-08-25 13:56:46 <ecraven> thanks!
2021-08-25 13:57:00 <mps> and '--allow' is enough
2021-08-25 13:57:34 <fcolista> ncopa...interesting 
2021-08-25 13:57:59 <ecraven> thanks a lot, I now have a working Gambit-C Scheme compiler on my pinephone ;)
2021-08-25 13:58:07 <ecraven> though it takes an hour or two to compile on it ;D
2021-08-25 14:02:01 <ecraven> sorry, one more, how do I list the files inside an apk file without installing it?
2021-08-25 14:03:18 <mps> ecraven: if the apk on local FS then tar -tvf file
2021-08-25 14:03:31 <ecraven> mps: thanks
2021-08-25 14:03:33 <mps> if it is on remote then no options
2021-08-25 14:04:58 <ncopa> apk fetch --quiet --stdout $package | tar -ztv
2021-08-25 14:05:39 <mps> hah :)
2021-08-25 14:05:51 <ikke> ecraven: one option is to setup qemu (or qemu-user) to build for a different arch
2021-08-25 14:06:49 <ecraven> ah, good point, that should still be much faster than the pinephone
2021-08-25 14:45:15 <nmeum> if you have a package for gambit feel free to submit a merge request
2021-08-25 14:45:38 <nmeum> I was also looking into packaging it but haven't gotten around to it yet
2021-08-25 15:24:45 <Alexthek1d> hello
2021-08-25 15:25:42 <Alexthek1d> Is alpine docker images released somwhere else before they are released on dockerhub? 
2021-08-25 15:26:10 <Alexthek1d> For example the new openSSL CVe is fixed on github but not yet in the docker image on dockerhub
2021-08-25 15:38:15 <ikke> Alexthek1d: which cve are you referring to?
2021-08-25 15:38:52 <ikke> https://security.alpinelinux.org/vuln/CVE-2021-3711 https://security.alpinelinux.org/vuln/CVE-2021-3712?
2021-08-25 15:39:02 <Alexthek1d> CVE-2021-3711
2021-08-25 15:39:05 <Alexthek1d> yes
2021-08-25 15:40:03 <Hello71> are you actually using SM2
2021-08-25 15:43:11 <ncopa> fcolista: i think i may have a fix for the cni-plugins version thingy
2021-08-25 15:48:51 <ncopa> fcolista: try cni-plugins-1.0.0-r1
2021-08-25 15:56:45 <fcolista> doing right now
2021-08-25 15:58:06 <fcolista> bad thing is that cni-plugins-1.0.0 has removed flannel binary...i/we need to package it :-/
2021-08-25 15:58:45 <fcolista> indeed it works
2021-08-25 15:58:52 <fcolista> thanks ncopa!!
2021-08-25 16:11:15 <Alexthek1d> @ikke they aren't fixed in the docker images on dockerhub yet. Is there another source where images are more up to date?
2021-08-25 16:11:48 <ikke> Alexthek1d: indeed, that requires ncopa to tag a snapshot / stable-release 
2021-08-25 16:12:16 <ikke> We do build some images weekly ourselves, but not a vanilla alpine image
2021-08-25 16:12:38 <Alexthek1d> So not for public use?
2021-08-25 16:13:02 <ikke> They can be used publically, but they all contain something additonally
2021-08-25 16:13:18 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker
2021-08-25 16:15:03 <ikke> And mostly based on alpine:edge
2021-08-25 16:16:22 <Alexthek1d> Not what we are looking for. Guess we have to wait.
2021-08-25 16:16:29 <Alexthek1d> But thank you :)
2021-08-25 16:17:39 <ikke> Alexthek1d: what prevents you from doing apk add -u openssl?
2021-08-25 16:20:49 <Alexthek1d> We (The Developers) have many firewall restrictions in our company. So we only get ready to use images from dockerhub. And this new CVE is a problem for our security department. So we can't use alpine right now :/
2021-08-25 16:24:07 <ikke> so you cannot install any packages from the repositories?
2021-08-25 16:26:46 <Alexthek1d> ikke: no
2021-08-25 16:26:52 <Alexthek1d> i know, it's crazy ...
2021-08-25 16:27:30 <ikke> but you can download any random image from docker hub, which can container about anything :)
2021-08-25 16:27:36 <ikke> can contain*
2021-08-25 16:28:15 <Alexthek1d> not not every image. just some official ones without critical or High CVEs
2021-08-25 16:28:21 <ikke> ok
2021-08-25 16:28:55 <ikke> If i would publish an image that is up-to-date, it would not be an official image
2021-08-25 16:29:04 <ikke> it would be under the alpinelinux/* namespace
2021-08-25 16:31:15 <Alexthek1d> okay
2021-08-25 16:31:22 <Alexthek1d> thanks for the chat ikke :)
2021-08-25 16:35:16 <ikke> I'll ask ncopa if he can tag new releases
2021-08-25 16:36:42 <Alexthek1d> That would be cool <3
2021-08-25 16:37:49 <ikke> Must be frustrating sometimes to work under such circumstances
2021-08-25 16:40:12 <Alexthek1d> Yes it is :/
2021-08-25 16:41:52 <Alexthek1d> I have to go. Cya!
2021-08-25 17:19:37 <chris> Is the abuild documentation up to date? It lists "-R Recursively build and install missing dependencies (using sudo)" but running abuild -R I get missing dependencies errors, whereas a lowercase r correctly fetches the deps as binary packages
2021-08-25 17:22:09 <ikke> Yeah, -R is no longer supported
2021-08-25 17:26:02 <chris> thanks!
2021-08-25 21:24:58 <Ariadne> what’s the deal with this pipewire issue
2021-08-25 21:25:04 <ikke> doxygen
2021-08-25 21:25:08 <Ariadne> jirutka is complaining about it
2021-08-25 21:25:13 <Ariadne> can we just disable doxygen
2021-08-25 21:25:18 <dalias> ?
2021-08-25 21:25:20 <ikke> that was my suggestion
2021-08-25 21:25:30 <ikke> doxygen is deadlocked
2021-08-25 21:25:45 <dalias> imo there should be a global policy of disabling doxygen, makeinfo, etc.
2021-08-25 21:26:04 <dalias> man pages as foo-doc, yes
2021-08-25 21:26:24 <dalias> but large manuals meant to be read in a brower or similar have no need to be in distro packages
2021-08-25 21:27:18 <Ariadne> there is already a TSC issue open for such a policy (or split manpages to -man)
2021-08-25 21:29:37 <Ariadne> ikke: i told jirutka to just disable doxygen
2021-08-25 21:29:44 <Ariadne> can somebody kick the builders
2021-08-25 21:29:48 <ikke> yes
2021-08-25 21:29:52 <ikke> once that commit is in
2021-08-25 21:32:33 <Ariadne> should be done in a few minutes
2021-08-25 21:34:29 <Ariadne> pushed
2021-08-25 21:35:03 <ikke> rakudo hangs as well
2021-08-25 21:35:21 <ikke> on aarch64
2021-08-25 21:37:29 <Ariadne> disable it i guess
2021-08-25 21:37:36 <ikke> It hangs on install
2021-08-25 21:37:37 <ikke> make install
2021-08-25 21:37:47 <ikke> something with moar
2021-08-25 21:39:35 <mps> dalias: 'but large manuals meant to be read in a brower or similar have no need to be in distro packages'. I agree fully
2021-08-25 21:42:26 <Ariadne> we should try to get an alpine 3.13 update out
2021-08-25 21:42:36 <Ariadne> for apk 2.12.7
2021-08-25 21:43:16 <ikke> also openssl
2021-08-25 21:43:50 <Ariadne> yes
2021-08-25 21:44:11 <ikke> someone here was asking about that
2021-08-25 21:44:29 <Ariadne> hmm we should have the TSC document the release process and establish a release team so that we can do these update releases more quickly
2021-08-25 21:45:07 <ikke> yes, ncopa already mentioned establashing a release engineering team
2021-08-25 21:45:15 <ikke> wanting to*
2021-08-25 21:45:21 <dalias> btw this is a related thought of mine, albeit as an outsider:
2021-08-25 21:45:47 <dalias> deadlocks in broken software's build systems should not stall the builders
2021-08-25 21:46:10 <dalias> there should be a way to measure forward progress and error out on extended time spent with no forward progress
2021-08-25 21:46:33 <dalias> so that other packages that can be built get built and the broken one gets reported automatically
2021-08-25 21:46:41 <ikke> yes, ideally it should
2021-08-25 21:47:11 <dalias> like even just "du" on the build dir every minute and kill if it doesn't change
2021-08-25 21:47:26 <dalias> it's stupid but it would work
2021-08-25 21:47:35 <ikke> maybing just even expecting log output
2021-08-25 21:47:43 <ikke> maybe*
2021-08-25 21:48:16 <dalias> i mean this has been an issue frustrating ppl working with it for years now, and there's got to be an easy hack fix
2021-08-25 21:48:23 <dalias> even if it's not pretty
2021-08-25 21:49:52 <ikke> but one challenge that was mentioned is properly killing the build automatically
2021-08-25 21:50:18 <ikke> you don't want to kill abuild itself
2021-08-25 21:54:15 <Ariadne> 
ACTION mutters things about apkfoundry

2021-08-25 21:54:38 <Ariadne> though admittedly it’s hard to sell everyone on apkfoundry when it’s not in prod anywhere
2021-08-25 21:55:12 <Hello71> ikke: why not?
2021-08-25 21:55:37 <Ariadne> hello71 it will leave the builder state dirty
2021-08-25 21:55:37 <ikke> Hello71: abuild needs to clean up stuff
2021-08-25 21:56:00 <Ariadne> anyway apkfoundry does solve those problems
2021-08-25 21:56:14 <Ariadne> but lack of validation is frustrating :)
2021-08-25 21:57:19 <ikke> And it needs to fit in our build process
2021-08-25 21:58:41 <ikke> Dependencies: python3
2021-08-25 21:59:14 <ikke> Do we want python in out bootstrap chain?
2021-08-25 23:30:01 <kevint> Can I get a look at !21493 ?
2021-08-26 06:28:40 <ncopa> good morning
2021-08-26 06:28:46 <ncopa> for some reason i missed the openssl cve
2021-08-26 06:40:05 <ikke> morning
2021-08-26 06:40:17 <danieli> morning
2021-08-26 06:45:05 <mps> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/470506#L1585
2021-08-26 06:45:12 <mps> good morning
2021-08-26 06:45:32 <mps> ../linux-user/syscall.c:7308:14: error: 'struct host_sigevent' has no member named '__sev_fields'
2021-08-26 06:46:53 <mps> and, /usr/include/signal.h:  } __sev_fields;
2021-08-26 06:47:27 <mps> sorry, /usr/include/signal.h:#define sigev_notify_thread_id __sev_fields.sigev_notify_thread_id
2021-08-26 06:49:03 <mps> dalias: ^
2021-08-26 06:49:16 <mps> could you help about this
2021-08-26 08:49:14 <Thermi_> Somebody please merge !24478
2021-08-26 08:56:00 <ikke> maxice8: howard-bc is failing on aarch64 (somehow killed after tests).
2021-08-26 09:05:52 <maxice8> can you get the test logs ? tests/dc/errors/33.txt 
2021-08-26 09:07:00 <ikke> The output is binary
2021-08-26 09:07:11 <ikke> https://tpaste.us/Lm4x
2021-08-26 09:11:21 <maxice8> huh
2021-08-26 09:13:39 <xsteadfastx> is there a way, if i send a patch through mail that it gets matched to my gitlab.alpine.org account in the merge requests view?
2021-08-26 09:13:52 <mps> I vote to close with `don't` !24478
2021-08-26 09:14:30 <mps> do we really need to maintain such pkgs in community?
2021-08-26 09:14:55 <maxice8> xsteadfastx: not currently, it uses the mailinglist-bot
2021-08-26 09:15:33 <xsteadfastx> ok... its ok. just a question :)
2021-08-26 09:27:54 <maxice8> It might be possible using GitLab admin tokens but I don't think we want to hand those out for such reasons
2021-08-26 09:30:26 <xsteadfastx> its the only project i can use git send-email and i love to use it.... so im still doing it that way :)
2021-08-26 10:27:20 <mps> re: my note about qemu build. it is related to hexagon target. do we support hexagon in toolchain?
2021-08-26 10:35:02 <ikke> does arch="noarch arch1 arch2" work? This is for an akms package, where the source itself is noarch, but the modules will only build on certain arches 
2021-08-26 10:39:52 <mps> af23b53c5edd4be6f0fe72663de3f7ff848ab663
2021-08-26 10:40:27 <mps> how then qemu 6.0.0 passed build, I wonder
2021-08-26 10:47:56 <mps> oh no, it is not related to only hexagon but looks like all targets have this problem
2021-08-26 10:50:16 <Ariadne> ikke: i think that it should just be arch="arch1 arch2" in that case
2021-08-26 10:50:52 <ikke> Ok, and just ignroe the noarch warning
2021-08-26 10:51:46 <Ariadne> yup
2021-08-26 11:34:01 <markand> mps, packages in testing/ aren't available in releases so yes unless they are provided it's fine to move them to community
2021-08-26 11:34:22 <markand> packages are maintained by contributors so I'm not sure in which way it involves you some work to do
2021-08-26 11:36:29 <mps> markand: please read backlog here and issues about kopano, and maybe even what upstream says about packaging it
2021-08-26 11:37:05 <markand> it's not just kopano, you also already complained several times when I pushed libretro packages into community saying that "alpine is a trash can"
2021-08-26 11:37:18 <mps> world is not based on *one* rule
2021-08-26 11:37:42 <mps> markand: yes, alpine is more and more 'trash can'
2021-08-26 11:38:15 <markand> in which way it is? because it has APKBUILDs to build packages? no one force you to install KDE, GNOME or all other stuff you personaly dislike
2021-08-26 11:38:25 <veiviser> if the community repository specifically intended for contributor-maintained packages is not the intended place for such things, what exactly is it for then?
2021-08-26 11:38:39 <veiviser> might as well remove community in its entirety then
2021-08-26 11:39:05 <mps> veiviser: yes, community is becoming 'trash can'
2021-08-26 11:39:14 <markand> but this behavior of "I don't like this so it should stay elsewhere" isn't welcoming for contributors
2021-08-26 11:39:17 <veiviser> do you have anything productive to say or just calling things trash
2021-08-26 11:39:40 <veiviser> i heard /g/ is a better place for such input
2021-08-26 11:40:13 <mps> veiviser: cleaning trash is most productive first steps (i.e. identifying trash)
2021-08-26 11:40:39 <markand> calling something trash is quite subjective 
2021-08-26 11:40:54 <mps> markand: I agree, but ...
2021-08-26 11:41:50 <mps> markand: you are careful with your packages and I even forgot about them, but not all contributors like you
2021-08-26 11:44:11 <mps> markand: if we tell that something is subjective then we will tell everything is subjective
2021-08-26 11:44:48 <mps> there are clearly 'objective' things which can't be called subjective
2021-08-26 11:45:11 <mps> and 'trash' is 'trash'
2021-08-26 12:00:51 <knuxify> out of curiosity - would it be acceptable to put a proprietary package in upstream non-free repos if it required glibc? i was trying to get my scanner working recently but it requires a proprietary utility to interface with SANE, and it requires some glibc libraries
2021-08-26 12:01:18 <knuxify> (using libc6compat or whatever it was called)
2021-08-26 12:03:02 <knuxify> personally i'd keep it as far out of aports as possible and offer apkbuilds/binaries in a separate, clearly marked as unofficial repo, but if someone wants to have it in nonfree i could change my mind :p
2021-08-26 12:03:32 <knuxify> (brscan3 btw. perhaps there's an open-source rewrite and i didn't search hard enough :p)
2021-08-26 12:04:29 <Thermi_> mps, please qualify your protest
2021-08-26 12:12:13 <Ariadne> dalias: on twitter, you say: https://twitter.com/RichFelker/status/1430846024931856390
2021-08-26 12:12:41 <Ariadne> dalias: what are the details you want to work out on such a proposal?
2021-08-26 12:14:05 <Ariadne> (yes, we will recommend skarnet's dnsfunnel on new installs, obviously, but the "docker" use case needs to be solved in some way too.)
2021-08-26 12:17:52 <Ariadne> of note, https://datatracker.ietf.org/doc/html/rfc7766#section-5 supercedes rfc5966 and says that a DNS resolver library (e.g. the libc one) must support TCP
2021-08-26 12:28:26 <ericonr> Ariadne: why do people even want to use glibc on alpine? base userspace can't be that smaller than debian with busybox or some such D>:
2021-08-26 12:28:37 <Ariadne> i don't know
2021-08-26 12:28:48 <jvoisin> compatibility with various crapwares
2021-08-26 12:29:02 <Ariadne> just use distroless
2021-08-26 12:29:34 <Ariadne> hmm
2021-08-26 12:29:38 <Ariadne> hmmmmmmm
2021-08-26 12:29:51 <Ariadne> i think we are overthinking this DNS issue tbh
2021-08-26 12:30:12 <mps> Ariadne: I expected that you will say *NO* to such things
2021-08-26 12:30:40 <ericonr> jvoisin: right but if you have the need for compatibility, just use glibc directly lol
2021-08-26 12:30:57 <Ariadne> mps: to which things
2021-08-26 12:31:03 <ericonr> they have to build libz and a bunch of stuff into their /usr/x86_64-linux-gnu prefix to make things work
2021-08-26 12:31:04 <mps> glibc
2021-08-26 12:31:16 <ericonr> and you could just *avoid that entirely* with a debian image
2021-08-26 12:31:23 <Ariadne> mps: i mean, i proposed adding conflicts on `glibc` in the musl package
2021-08-26 12:31:28 <mps> ericonr: +1
2021-08-26 12:31:37 <ericonr> the only issue debian brings is libcurl-{gnutls,openssl}
2021-08-26 12:31:44 <mps> Ariadne: yes, I saw it
2021-08-26 12:31:56 <Ariadne> can't get much more *no* than that
2021-08-26 12:32:14 <mps> but I think it is not needed, say no to glibc and there is no issue
2021-08-26 12:32:44 <Ariadne> well, the issue is not really glibc per se
2021-08-26 12:32:50 <Ariadne> but creating franken alpines in general
2021-08-26 12:32:59 <Ariadne> glibc is just one path to breaking your system :P
2021-08-26 12:33:06 <mps> that is what I think
2021-08-26 12:33:27 <Ariadne> what i really want is
2021-08-26 12:33:29 <mps> 'franken alpine', nice term
2021-08-26 12:33:31 <Ariadne> for apk to be smart
2021-08-26 12:33:43 <Ariadne> and recognize (and warn) when the user is proposing to do something stupid
2021-08-26 12:33:53 <Ariadne> maybe we add tensorflow support to apk3
2021-08-26 12:33:55 <Ariadne> :D
2021-08-26 12:34:03 <mps> :)
2021-08-26 12:34:32 <Ariadne> maybe we just unconditionally link everything against BIND libresolv and have a nice life too
2021-08-26 12:35:00 <mps> hahm, 'nice life'
2021-08-26 12:35:17 <Ariadne> hmm
2021-08-26 12:35:18 <jvoisin> having recommendations would be fun. "it looks like you're trying to install BIND9. Would you prefer to throw it into a volcano and install knotd or powerdns instead? [Y/n]"
2021-08-26 12:35:29 <Ariadne> /etc/ld.preload.conf
2021-08-26 12:35:37 <Ariadne> or rather
2021-08-26 12:35:43 <Ariadne> /etc/ld.preload.d/libresolv.conf
2021-08-26 12:36:00 <Ariadne> could contain /lib/libresolv.so.whatever
2021-08-26 12:36:06 <Ariadne> and musl could just LD_PRELOAD it
2021-08-26 12:36:11 <Ariadne> voila
2021-08-26 12:36:31 <Ariadne> "i want my DNS to work like BIND libresolv" -> "apk add libresolv-preload"
2021-08-26 12:36:55 <Ariadne> man
2021-08-26 12:37:01 <Ariadne> this is brilliant
2021-08-26 12:37:05 <Ariadne> i mean, its totally a rootkit
2021-08-26 12:37:07 <Ariadne> but
2021-08-26 12:37:10 <mps>  "i want my DNS to work like BIND libresolv" => install other distro, I would say
2021-08-26 12:37:28 <Ariadne> mps: i mean, i hate to say it
2021-08-26 12:37:40 <Ariadne> but BIND libresolv is pretty consistent across every other UNIX implementation
2021-08-26 12:37:50 <Ariadne> and that's what people actually want
2021-08-26 12:37:52 <mps> Ariadne: I have feeling that I understand you
2021-08-26 12:38:30 <mps> but 'we' are trying to make alpine better and not worse
2021-08-26 12:38:36 <ericonr> Ariadne: does it try to be ABI compatible with libc structs?
2021-08-26 12:39:00 <Ariadne> no, but musl tries to emulate libresolv ABI
2021-08-26 12:39:11 <Ariadne> it even has that stupid `_res` thingy
2021-08-26 12:39:51 <mps> Ariadne: do whatever you think is 'less bad', I trust you on this
2021-08-26 12:40:19 <Ariadne> well 'less bad' is teach musl to use TCP
2021-08-26 12:40:22 <mps> last time I hacked I hacked libresolv was about 25 years ago
2021-08-26 12:40:32 <Misthios> How is the build order in the ci decided?, It fails to buid lld because it needs libunwind but its build after
2021-08-26 12:41:10 <Ariadne> even less bad is teach musl to use a UNIX socket
2021-08-26 12:41:10 <mps> Misthios: build them in proper order and push in proper order
2021-08-26 12:41:33 <Misthios> Mps its gonna be fun.... Llvm12 split some parts 
2021-08-26 12:41:35 <ikke> Misthios: it uses ap builddeps to build packages in dependency order, but it first builds main, then community and then testing
2021-08-26 12:41:49 <Misthios> Ah okay
2021-08-26 12:41:57 <mps> Misthios: last time I did this was with llvm6 (or 5) so I forgot exact procedure
2021-08-26 12:42:11 <Misthios> Oh im halfway done already toh
2021-08-26 12:42:19 <Ariadne> but in all seriousness
2021-08-26 12:42:36 <Ariadne> libresolv.so is already available on alpine today
2021-08-26 12:43:09 <Ariadne> through bind
2021-08-26 12:43:25 <mps> yes, I expected this
2021-08-26 12:43:29 <Ariadne> so we could just, like
2021-08-26 12:43:36 <Ariadne> link things against it
2021-08-26 12:43:38 <Ariadne> idk
2021-08-26 12:44:00 <mps> though didn't looked at it, and don't like idea to look at bind-anything
2021-08-26 12:45:00 <mps> I thought I will forgot qemu-anything after my last mess, but I'm right now on qemu channel and qemu gitlab. what's a life
2021-08-26 12:45:23 <mps> life is serious fun ;)
2021-08-26 12:45:36 <Ariadne> basically, my position, which i have not really successfully formulated these past years
2021-08-26 12:45:56 <mps> I'm ears
2021-08-26 12:46:10 <Ariadne> is that if musl is going to provide the libresolv APIs, it should behave like the reference implementation
2021-08-26 12:46:18 <Ariadne> i think that's what people expect
2021-08-26 12:46:36 <Ariadne> it has nothing to do with XYZ feature, but rather that the libresolv APIs feel like the real deal
2021-08-26 12:46:41 <mps> we only have to 'force' dalias
2021-08-26 12:46:47 <Ariadne> i mean, we don't
2021-08-26 12:46:52 <Ariadne> we could just replace the DNS code :p
2021-08-26 12:47:13 <Ariadne> or write a linker script ^_^
2021-08-26 12:47:40 <dalias> ?
2021-08-26 12:48:01 <mps> I 'learned' to respect dalias decisions, be they bad or good. life with alpine is easier then
2021-08-26 12:48:05 <Ariadne> oh, i was reading through last year's bikeshed on TCP DNS
2021-08-26 12:48:06 <dalias> i told you aiui what you want is already in a pretty much approved state but not written
2021-08-26 12:48:45 <Ariadne> what i want is for developers building their apps on alpine to stfu about dns
2021-08-26 12:48:57 <dalias> :)
2021-08-26 12:49:21 <Ariadne> which, i think the issue is actually that they are expecting behavior from the DNS APIs to match that of BIND's libresolv
2021-08-26 12:49:29 <dalias> well you need to be more specific. some of them want things that are outright wrong and inconsistent, because glibc happened to do them. but the issue at hand right now is not one of those
2021-08-26 12:49:41 <dalias> s/now/not/
2021-08-26 12:50:30 <dalias> afaict the issue at hand is that folks are using google dns and it's giving them 0 results on tc because google has a bad interpretation of what tc means :-p
2021-08-26 12:50:46 <Ariadne> no, that one is a non-issue these days
2021-08-26 12:50:51 <dalias> oh? then what is it?
2021-08-26 12:50:57 <Ariadne> the issue now is that crazy people are doing things like
2021-08-26 12:51:04 <Ariadne> putting 200 A records in a domain
2021-08-26 12:51:08 <Ariadne> and expecting to get all 200 back
2021-08-26 12:51:15 <dalias> *sigh*
2021-08-26 12:51:39 <Ariadne> which works on libresolv (glibc or otherwise)
2021-08-26 12:52:06 <mps> 200 A records? omg
2021-08-26 12:52:07 <dalias> the conclusion of the last thread on this is that support for tcp queries is needed because you can have important data (dnssec) that's not representable in smaller size
2021-08-26 12:52:37 <Ariadne> yes, solving that is also good obviously
2021-08-26 12:52:43 <Ariadne> but tcp support can solve both :P
2021-08-26 12:53:09 <dalias> and basically that, possibly depending on config in resolv.conf (?), the res_query api should support that
2021-08-26 12:53:10 <dalias> so that you can get the full answer
2021-08-26 12:53:19 <mps> wait, doesn't musl already support TCP for this?
2021-08-26 12:53:25 <Ariadne> mps: no
2021-08-26 12:53:46 <mps> ah, why I thought it does. I wonder
2021-08-26 12:53:48 <Ariadne> dalias: i also think that having a local resolver is good practice, and that's how i have done it for years
2021-08-26 12:54:00 <mps> probably didn't read carefully
2021-08-26 12:54:12 <Ariadne> but the problem is
2021-08-26 12:54:26 <Ariadne> people do shit like put 200 A records on a single DNS name
2021-08-26 12:54:39 <Ariadne> and then it breaks on alpine
2021-08-26 12:54:44 <Ariadne> and they go to "hacker" "news"
2021-08-26 12:55:01 <Ariadne> and start posting "omg alpine suxxxxxx bro what are you doing in life it cant even support my 200 records DNS name"
2021-08-26 12:55:42 <Ariadne> and then somebody else replies "wow, i think we will banish musl from the entire stack at $company"
2021-08-26 12:55:49 <dalias> but that getaddrinfo should continue to bound the number of results
2021-08-26 12:55:49 <dalias> which i dont think will make these ppl doing ridiculous things happy
2021-08-26 12:56:11 <Ariadne> the problem is
2021-08-26 12:56:31 <Ariadne> i don't care if we make them happy or not, i just want them to STFU
2021-08-26 12:56:33 <dalias> ignore hacker news
2021-08-26 12:56:39 <dalias> it's ALL IDIOTS
2021-08-26 12:56:47 <Ariadne> i'm not arguing otherwise
2021-08-26 12:56:51 <mps> :)
2021-08-26 12:57:06 <dalias> basically whatever is the opposite of what you read on HN is what you should assume is true unless you're an expert on the topic
2021-08-26 12:57:08 <Ariadne> but those idiots can cause musl-based distributions like alpine to be disqualified from projects
2021-08-26 12:57:46 <dalias> sometimes idiots select themselves out of your userbase and it's a good thing
2021-08-26 12:57:48 <mps> not sure musl distro should be used by 'these' people anyway
2021-08-26 12:58:01 <dalias> "HN users" are *NOT* the userbase you want to build
2021-08-26 12:58:08 <Ariadne> it's not about 'those' people, to be clear
2021-08-26 12:58:09 <dalias> they will perpetually be abusive and demanding of wrong things
2021-08-26 12:58:15 <Ariadne> it's about containing the *damage* of those people
2021-08-26 12:58:18 <mps> and I don't care for _such_ people, tbh
2021-08-26 12:58:32 <Ariadne> because too many idiots believe their nonsense
2021-08-26 12:58:33 <dalias> i'm not convinced the "damage" spreads
2021-08-26 12:58:49 <dalias> but the idiots who believe their nonsense are also not the userbase you want
2021-08-26 12:58:51 <Ariadne> i've seen the DNS FUD in other places
2021-08-26 12:59:19 <Ariadne> are they the userbase i want?  no
2021-08-26 12:59:23 <mps> 
ACTION left channel for better things to do

2021-08-26 12:59:31 <Ariadne> do they get in the way of accomplishing goals i want?  to some extent
2021-08-26 13:00:13 <Ariadne> gnu/linux with systemd allows these idiotic things
2021-08-26 13:00:17 <dalias> the good users you want do not say "oh look how nicely that distro bends to whatever abusive shit HN idiots are doing?  that makes me want to use it!" ?
2021-08-26 13:01:55 <Ariadne> again: i don't care about HN, in fact, if you didn't notice, i basically mock them every time
2021-08-26 13:02:13 <Ariadne> what i do care about is managers banishing alpine from places because of FUD
2021-08-26 13:02:54 <dalias> i know you do. but you also seem to dwell a lot on what they're thinking about, and harm your relationships with projects (e.g. musl) and users you do care about, over concerns about what will happen if the HN idiots are unhappy
2021-08-26 13:03:20 <dalias> yes some managers are idiots who read HN and listen to ppl who do
2021-08-26 13:04:10 <dalias> that's not your (our?) problem
2021-08-26 13:04:49 <dalias> yes some of it spills over to ppl who didn't intend to be getting their info from shit sources
2021-08-26 13:05:08 <Ariadne> listening to concerns, and trying to empathize with people who are hitting corner cases in negatively impactful ways, is not harmful i think
2021-08-26 13:05:09 <dalias> and it's some work to find and correct that
2021-08-26 13:06:04 <dalias> if there are actual legitimate complaints in legitimate settings (non-HN), they can be discussed reasonably
2021-08-26 13:06:22 <Ariadne> the problem is that HN is where these people vent
2021-08-26 13:06:23 <dalias> but the perpetual goalpost changing from people who just want glibc is not helpful
2021-08-26 13:06:50 <dalias> they should go use glibc and enjoy all the bloat, lack of failsafe guarantees, etc.
2021-08-26 13:07:06 <Ariadne> well my position is more
2021-08-26 13:07:14 <Ariadne> if they want 200 A records guaranteed in a response
2021-08-26 13:07:21 <Ariadne> they should use a DNS library designed for that
2021-08-26 13:07:40 <dalias> ok, that seems reasonable. in the future, just res_query would be sufficient for that
2021-08-26 13:08:06 <Ariadne> is there a technical reason to limit it to res_query? :p
2021-08-26 13:08:34 <dalias> yes. there the caller controls the size they want and are willing to accept
2021-08-26 13:08:35 <Ariadne> (also, i am quite certain node uses c-ares ala libuv?)
2021-08-26 13:09:58 <dalias> whereas in gai we use fixed result buffer on stack so as not to allocate anything before comitting to success, so that gai can be used in malloc-free static programs and not be subject to large allocation under control of what's in dns
2021-08-26 13:10:27 <Ariadne> could that be modified to make it a compile-time tunable?
2021-08-26 13:11:11 <dalias> tunable in what sense?
2021-08-26 13:11:24 <Ariadne> at compile time of musl itself
2021-08-26 13:11:40 <dalias> tuning the particular limit would impose potentially large stack size requirements where not expected
2021-08-26 13:11:49 <Ariadne> hmm, true
2021-08-26 13:12:00 <dalias> tuning to not have a limit would require very different high level flow (2 implementations)
2021-08-26 13:12:08 <dalias> neither seems appealing
2021-08-26 13:12:32 <Ariadne> i wonder if the solution is basically say
2021-08-26 13:12:36 <dalias> the normal/intended use of gai results is to try a sequence of fallbacks if the first address doesn't work
2021-08-26 13:12:38 <Ariadne> "if you want to do crazy shit, use libresolv"
2021-08-26 13:12:56 <Ariadne> thats basically what i am getting at :)
2021-08-26 13:13:17 <dalias> 200 fallbacks is going to be ridiculously slow and is not a reasonable thing to do :-p
2021-08-26 13:13:43 <Ariadne> i'm confused though
2021-08-26 13:13:44 <Ariadne> because,
2021-08-26 13:14:10 <Ariadne> https://news.ycombinator.com/item?id=28312935
2021-08-26 13:14:23 <Ariadne> > so node fails to resolve the name
2021-08-26 13:14:32 <Ariadne> isn't node using c-ares?
2021-08-26 13:14:34 <Ariadne> i should check
2021-08-26 13:14:43 <dalias> no, i dont think so
2021-08-26 13:14:56 <dalias> also this means they ARE using google dns or some broken nameserver with the same bug
2021-08-26 13:15:13 <Ariadne> its built with
2021-08-26 13:15:15 <dalias> they're complaining about not getting a working truncated result, not about not getting all 200 names
2021-08-26 13:15:16 <Ariadne>                 --shared-cares \
2021-08-26 13:15:27 <dalias> it probably only uses that for something else
2021-08-26 13:15:59 <Ariadne> did i mention i hate node
2021-08-26 13:16:04 <dalias> (as usual, HN is dumb and I feel dumber for having clicked on that)
2021-08-26 13:16:21 <dalias> can't you just like mute anything with HN in it?
2021-08-26 13:16:31 <dalias> and avoid all this shit?
2021-08-26 13:16:57 <Ariadne> i mean, i can, but then these use cases work on FreeBSD
2021-08-26 13:17:00 <dalias> no matter what you try to do to make ppl happy, HN will always be stirring up shit because *they don't even have to be right about what they're complaining about*
2021-08-26 13:17:31 <Ariadne> i'm confused though
2021-08-26 13:17:37 <Ariadne> like, why link to c-ares
2021-08-26 13:17:40 <Ariadne> if you're not going to use it
2021-08-26 13:17:57 <dalias> who knows. maybe they didnt even hit the issue and they just *made it up* based on their partial understanding of the problem
2021-08-26 13:17:57 <veiviser> https://nodejs.org/en/docs/meta/topics/dependencies/#c-ares
2021-08-26 13:18:05 <veiviser> idk how up to date this is
2021-08-26 13:18:20 <dalias> or maybe some external utility that's using libc is being invoked and that's where the error was
2021-08-26 13:18:31 <dalias> they're not actually interested in describing what they're doing in sufficient detail to get help
2021-08-26 13:18:39 <Ariadne> what the actual fuck
2021-08-26 13:18:40 <dalias> they're just interested in shitting on things
2021-08-26 13:19:17 <Ariadne> dalias: well, HN is also the people who brought us alpine-pkg-glibc
2021-08-26 13:19:28 <Ariadne> which has been the bane of my existence for the past like 5 years now
2021-08-26 13:19:32 <Ariadne> sooooo
2021-08-26 13:19:52 <dalias> uhg
2021-08-26 13:20:33 <Ariadne> veiviser: so it uses one DNS resolver for one thing, and the libc one for everything else
2021-08-26 13:20:37 <Ariadne> how delightfully inconsistent
2021-08-26 13:21:07 <Ariadne> with *threads*
2021-08-26 13:21:12 <veiviser> yes- i don't think resolve() is used by anything but user code
2021-08-26 13:21:15 <Ariadne> why
2021-08-26 13:21:17 <Ariadne> just why
2021-08-26 13:21:31 <veiviser> and anything in nodejs itself just uses libc as you say
2021-08-26 13:21:38 <veiviser> i can't understand why they did it this way
2021-08-26 13:23:38 <Ariadne> so, basically
2021-08-26 13:23:39 <veiviser> and c-ares apparently has a lot of issues too?
2021-08-26 13:23:42 <veiviser> https://github.com/nodejs/node/issues/14713
2021-08-26 13:23:54 <Ariadne> this is "fixed" by using a stub resolver like unbound or dnsfunnel
2021-08-26 13:24:06 <Ariadne> so we should just tell people in all cases to do that
2021-08-26 13:24:21 <ecraven> hello ;) if I want to package something directly from git, I'm supposed to snapshot it, right? 
2021-08-26 13:24:30 <ecraven> or should I just run git clone directly during the build process?
2021-08-26 13:24:30 <Ariadne> yes
2021-08-26 13:24:34 <Ariadne> no
2021-08-26 13:24:57 <ecraven> is it ok to just put the snapshot in ./, and not upload it anywhere? just to get this working at all
2021-08-26 13:25:13 <Ariadne> yes
2021-08-26 13:25:19 <Ariadne> but dont MR it that way
2021-08-26 13:25:40 <veiviser> use a version like 0_git20210807-r0 in case you didn't know already
2021-08-26 13:25:52 <veiviser> that way when a 0.1 or 1.0 comes out it prefers that one
2021-08-26 13:26:03 <Ariadne> dalias: so, basically, this DNS issue is solved by stub resolver, and we just need to document it (and have setup-alpine offer to set up a stub resolver)
2021-08-26 13:26:52 <ecraven> Ariadne: thanks!
2021-08-26 13:27:20 <veiviser> sadly i think the people doing single-process containers will still be complaining
2021-08-26 13:27:27 <ecraven> I'm just trying to package this for myself, if it actually works, I'll try to improve it so it could be MR'd ;)
2021-08-26 13:27:34 <Ariadne> dalias: fwiw, i think that writing some documentation about using alpine in k8s / docker / whatever deployments might help to smooth a lot of issues
2021-08-26 13:27:41 <dalias> yes, and yes
2021-08-26 13:27:52 <Ariadne> veiviser: you can run a stub resolver in XYZ container and forward it along to another one
2021-08-26 13:27:56 <dalias> and i'd really like to see skarnet's work to make something specifically for alpine get put to use :)
2021-08-26 13:28:00 <Ariadne> at least kubernetes makes it very easy
2021-08-26 13:28:08 <mps> ecraven: this is how I made wiringx aports/testing/wiringx/
2021-08-26 13:28:29 <mps> not ever released
2021-08-26 13:28:33 <Ariadne> so in a k8s deployment of dnsfunnel, you'd have a dnsfunnel container
2021-08-26 13:28:48 <veiviser> of course :)
2021-08-26 13:28:49 <Ariadne> and then the other k8s containers would be connected to it
2021-08-26 13:28:54 <dalias> altho actually getting validation and other importane behaviors might require something else at present
2021-08-26 13:29:05 <Ariadne> yes, unbound
2021-08-26 13:29:26 <dalias> or dnsmasq ;-)
2021-08-26 13:29:37 <Ariadne> for setup-alpine, my suggestion is to offer both unbound or dnsfunnel
2021-08-26 13:29:38 <Ariadne> nah
2021-08-26 13:29:41 <Ariadne> i'm good re: dnsmasq
2021-08-26 13:29:49 <Ariadne> i've seen the code, i'm good
2021-08-26 13:30:14 <Ariadne> trying to keep the CVE count down
2021-08-26 13:30:16 <Ariadne> not up
2021-08-26 13:31:02 <Ariadne> wait, maybe it was something else i had to patch
2021-08-26 13:31:14 <Habbie> having seen dnsmasq's code, you are not wrong
2021-08-26 13:31:15 <dalias> :)
2021-08-26 13:31:20 <dalias> thus the ";-)"
2021-08-26 13:31:36 <Habbie> so uh, i only skimmed the backlog, am i gathering correctly that the stub resolver in musl does not do TCP? does it do EDNS bufsize?
2021-08-26 13:31:43 <dalias> altho you can just contain it and the worst that can happen is forged results
2021-08-26 13:32:15 <dalias> no, and edns almost surely won't be done -- it requires modifying the query then fudging the response to hide that the query was modified
2021-08-26 13:32:36 <Habbie> right
2021-08-26 13:33:24 <Ariadne> ah
2021-08-26 13:33:30 <dalias> i mean there are complex ways it could be used just for gai, but gai isn't even the one where we want large results. and for res_*, the response actually needs to semantically match the query submitted in dns packet form, not a modified query in a form the caller might not expect to get back
2021-08-26 13:33:32 <Ariadne> now we have two people with Opinions(tm) on DNS
2021-08-26 13:33:44 <dalias> ariadne, o? :)
2021-08-26 13:33:46 <Ariadne> unfortunately, we do not have an octagon available
2021-08-26 13:33:49 <Habbie> i have opinions, but only if you need them
2021-08-26 13:33:56 <Habbie> for now i was just making sure i got it all right :)
2021-08-26 13:34:09 <Ariadne> dalias: Habbie works for powerdns
2021-08-26 13:34:15 <Habbie> that i do
2021-08-26 13:34:24 <Ariadne> which admittedly is the best dns server
2021-08-26 13:34:29 <Habbie> 
ACTION bows

2021-08-26 13:34:37 <Ariadne> at least for my use case
2021-08-26 13:34:47 <mps> and complicated to setup ;)
2021-08-26 13:34:55 <dalias> ahh :)
2021-08-26 13:35:07 <Habbie> mps, there is a balance, yes ;)
2021-08-26 13:35:10 <Ariadne> mps: and supported by OpenStack
2021-08-26 13:35:21 <mps> Habbie: yes, I use powerdns
2021-08-26 13:35:38 <dalias> i want to do a dns server but the cost/benefit doesn't make sense for me :/
2021-08-26 13:35:50 <Habbie> dalias, do as in write?
2021-08-26 13:35:52 <dalias> yeah
2021-08-26 13:35:57 <dalias> there's no reason an auth server should take more than a few kb of resources
2021-08-26 13:36:04 <Habbie> tinydns :)
2021-08-26 13:36:27 <mps> tinydns can still work nowadays?
2021-08-26 13:36:30 <Habbie> the only reason tinydns is 30kbyte is that djb did not even like the parts of libc that -were- available
2021-08-26 13:36:44 <Habbie> mps, a few minor patches are recommended, and of course there's no DNSSEC and a few other limitations, but it could work
2021-08-26 13:36:47 <Habbie> facebook
2021-08-26 13:36:49 <Habbie> and also amazon route53
2021-08-26 13:36:52 <Habbie> ran on forks of tinydns until recently
2021-08-26 13:37:00 <dalias> and recursive/caching i want implemented with fixed resource usage because it's resource attack surface
2021-08-26 13:37:14 <dalias> but i'm happy just not running a recursive/caching server except for use by localhost
2021-08-26 13:37:32 <mps> Habbie: yes, I used patched tinydns, and then switched to powerdns
2021-08-26 13:37:43 <Ariadne> i just used powerdns to begin with
2021-08-26 13:37:46 <Ariadne> because it sounded cool
2021-08-26 13:37:54 <dalias> habbie, what does "no dnssec" mean ? for the auth server it shouldn't need anything special, and should just work unless very broken stuff was done
2021-08-26 13:37:57 <Ariadne> since 2006 or so
2021-08-26 13:38:05 <Habbie> dalias, dnssec requires tons of processing by an auth server
2021-08-26 13:38:08 <dalias> for the recursive server it needs validation which is nontrivial
2021-08-26 13:38:32 <Habbie> dalias, for positive answers, gathering signatures; for negative answers, gathering NSEC(3) records for negative proofs
2021-08-26 13:38:37 <dalias> won't the recursive servers just query the dnssec records they need if not included in the original auth response?
2021-08-26 13:38:41 <Habbie> they won't
2021-08-26 13:38:43 <Habbie> because they can't
2021-08-26 13:38:51 <Habbie> there's no consistency between individual queries
2021-08-26 13:38:52 <mps> I would say that I choose powerdns because it is 'less bad' than others (sorry Habbie )
2021-08-26 13:38:58 <Habbie> mps, works for me
2021-08-26 13:39:16 <Habbie> and NSEC3 records cannot be queried for at all (which wouldn't make sense anyway - the validator doesn't know which one it needs)
2021-08-26 13:39:24 <Ariadne> i don't even use dnssec
2021-08-26 13:39:25 <dalias> nsec3 is awful :-p
2021-08-26 13:39:34 <Habbie> dalias, agree
2021-08-26 13:39:48 <Habbie> Ariadne, i don't know if i would use dnssec if i wasn't dogfooding ;)
2021-08-26 13:40:03 <Misthios> Libcxx now requires libcxxabi. Should that be a separate pkg or just try to compile it into libcxx itself? (Wont build without)
2021-08-26 13:40:08 <dalias> pandering to stupid enterprise "we dont want anyone enumerating our domains" bs
2021-08-26 13:40:19 <dalias> they'd be so much more secure if they assumed everyone had access to that info
2021-08-26 13:40:41 <dalias> and it's not like nsec3 even prevents that with mining rigs being a thing nowadays
2021-08-26 13:41:16 <Habbie> part of nsec3s popularity is the optout flag
2021-08-26 13:41:19 <Habbie> which is what big TLDs need
2021-08-26 13:41:29 <dalias> that's even worse :/
2021-08-26 13:41:30 <Habbie> some of who don't even want the hashing, but it's a package deal
2021-08-26 13:41:57 <dalias> i dont see why they "need" it
2021-08-26 13:42:18 <Habbie> well, 'need' is a strong word, of course
2021-08-26 13:42:23 <Habbie> but their zone sizes would explode without it
2021-08-26 13:42:33 <Habbie> which is kind of betting on dnssec -not- taking off, of course
2021-08-26 13:42:44 <Ariadne> why do dns zones need to be signed at all
2021-08-26 13:42:44 <dalias> only assuming most aren't signed
2021-08-26 13:42:49 <Habbie> dalias, yes
2021-08-26 13:42:50 <dalias> you can't use it for any that do need to be signed
2021-08-26 13:43:20 <dalias> ariadne, because bad actors forge results to deliver you spam, get fraudulent certificates for your domains, capture your traffic, etc.
2021-08-26 13:43:29 <Habbie> dalias, 'oh and dnssec helps?' 'well'
2021-08-26 13:43:46 <Ariadne> yes, i am not really convinced dnssec prevents any of that
2021-08-26 13:43:57 <Habbie> (that's not entirely fair - cert issuance really is safer through dnssec these days, i believe)
2021-08-26 13:44:19 <dalias> here by "spam" i mean "forged isp partner results in place of nxdomain to show you a page full of malware-infested ads"
2021-08-26 13:44:59 <dalias> which dnssec completely precludes
2021-08-26 13:45:02 <Ariadne> 99% of isp users will trust their auth server without doing local validation though
2021-08-26 13:45:17 <Habbie> yep
2021-08-26 13:45:23 <Habbie> their resolver, i presume you mean, but yep
2021-08-26 13:45:24 <dalias> that's why OS's need to get their act together and ship validating resolvers on localhost
2021-08-26 13:45:43 <Ariadne> i'm sure microsoft will get around to it as part of windows 15
2021-08-26 13:45:52 <Ariadne> but only on Pro
2021-08-26 13:46:06 <Habbie> apple has been shipping validation code for years, but i don't know what they do with it
2021-08-26 13:46:32 <dalias> re: certificates, with proper use of dnssec there's no way for a forged certificate to be issued except by a CA breaking the rules (and there is cryptographic proof of them breaking the rules)
2021-08-26 13:47:01 <Ariadne> the only thing that convinces me on dnssec is DANE
2021-08-26 13:47:01 <Habbie> well, there's still MITMing HTTP challenges
2021-08-26 13:47:09 <Habbie> but that can be precluded with a good CA
2021-08-26 13:47:11 <dalias> you use a (must be signed) CAA record to limit issuance to the only CA you trust
2021-08-26 13:47:16 <Habbie> yes, exactly
2021-08-26 13:47:22 <Habbie> CAA for CA + validation method
2021-08-26 13:47:25 <Habbie> then dnssec works for it
2021-08-26 13:47:25 <Ariadne> i trust none of them
2021-08-26 13:47:53 <Ariadne> lets encrypt just costs me $0
2021-08-26 13:47:55 <dalias> then you either use DNS-01 ACME with a signed acme challenge txt record, *or* use HTTP-01 but with the CAA record binding to a particulare ACME account key you possess
2021-08-26 13:48:08 <Habbie> Ariadne, and with DNSSEC+CAA, you can prevent anybody else from using any other CA for your domain
2021-08-26 13:48:43 <Habbie> dalias, oh account is clever too
2021-08-26 13:48:45 <Habbie> anyway
2021-08-26 13:48:48 <Habbie> i did not come here to advocate for DNSSEC ;)
2021-08-26 13:48:51 <dalias> :)
2021-08-26 13:49:17 <Habbie> EDNS, however ;)
2021-08-26 13:49:52 <Ariadne> fwiw if Habbie says musl's dns code is legit i will stop bitching about it
2021-08-26 13:50:08 <Habbie> oh it's not
2021-08-26 13:50:10 <Habbie> sorry
2021-08-26 13:50:20 <dalias> habbie, btw if you want to discuss i have a design in the works for making DNS-01 much easier to use (not requiring your own dns infrastructure or giving your webserver credentials to modify your hosted DNS))
2021-08-26 13:50:35 <Habbie> dalias, always interested, and sometimes i even hav etime
2021-08-26 13:50:37 <Habbie> *have time
2021-08-26 13:51:11 <Ariadne> i'll expand that to any known DNS expert on irc.terahertz.net #ix
2021-08-26 13:51:59 <Habbie> i trust you will find several that go 'having so many A records on a name is ridiculous' but few that go 'so it is fine that musl can only handle 512 byte responses'
2021-08-26 13:52:02 <dalias> habbie, do you have specific concerns about where it's not, aside from the known issue of not doing tcp fallback (which is proposed for change alredy)
2021-08-26 13:52:33 <Habbie> dalias, 'can only handle 512 byte responses' is the core, i think
2021-08-26 13:52:40 <Habbie> 300 A records is not the only problem
2021-08-26 13:52:44 <Habbie> DKIM TXT records too
2021-08-26 13:53:07 <dalias> yes, the actual problem is not "kooks who put too many A records" (who cares; just the first N are fine)
2021-08-26 13:53:26 <Habbie> (well, your resolver may not give you the first N, even, so you still have a problem)
2021-08-26 13:53:32 <dalias> the problem is large meaningful records like DKIM, DANE in the awful mode that has the full key rather than the hash, etc.
2021-08-26 13:53:38 <Habbie> yep
2021-08-26 13:54:10 <Ariadne> well as long as it actually returns the first N
2021-08-26 13:54:10 <dalias> it's really not cool to just not honor DANE because some fool used the bloated mode rather than the reasonable one
2021-08-26 13:54:15 <Habbie> Ariadne, many resolvers don't
2021-08-26 13:54:19 <Ariadne> i dont think anyone is actually testing
2021-08-26 13:54:26 <Ariadne> if 300/300 records get returned
2021-08-26 13:54:34 <Ariadne> by getaddrinfo(3)
2021-08-26 13:54:38 <Habbie> do we have an offending name of such an A rrset?
2021-08-26 13:55:20 <Habbie> i run into some occasionally but i do not have one at hand right now
2021-08-26 13:58:19 <ecraven> hm.. how do I tell git archive to include submodules, for the snapshot?
2021-08-26 13:58:41 <orbea> ecraven: you dont
2021-08-26 13:59:05 <orbea> you need to include sources for the submodules manually
2021-08-26 13:59:23 <orbea> (or better yet dont use submodules)
2021-08-26 13:59:30 <ecraven> not my choice :-/ upstream uses them
2021-08-26 13:59:38 <orbea> yea, i know the feeling
2021-08-26 13:59:47 <ecraven> but the idea is I check them out during snapshot() and include them in the snapshot, right? no downloading during build()?
2021-08-26 14:00:11 <Ariadne> nap for a bit
2021-08-26 14:00:32 <Ariadne> (hacker news seems quite upset that i have the GAUL to propose blocking install of glibc on alpine)
2021-08-26 14:00:54 <orbea> ecraven: i think the best you can do is include git archives for the submodules in the sources and then move them into place
2021-08-26 14:07:39 <mps> Ariadne: heh, HN :)
2021-08-26 14:09:27 <Habbie> 100-ips.7bits.nl now has 100 A records
2021-08-26 14:09:32 <Habbie> if anybody wanted to test something
2021-08-26 14:10:35 <skarnet> I still plan to write a full dns cache and server at some point (yes dalias, it would do dnssec validation) but can it wait a couple years? >.>
2021-08-26 14:10:41 <dalias> :) :) :)
2021-08-26 14:10:44 <Habbie> and test300.t0d.nl has 300
2021-08-26 14:11:06 <dalias> yes of course. i dont mind continuing to use dnsmasq or unbound in the mean time
2021-08-26 14:11:18 <ecraven> when building from a snapshot, how do I tell abuild to ignore the checksum? can I put that into the APKBUILD/
2021-08-26 14:11:43 <skarnet> for my personal use dnscache and tinydns work perfectly, I patched them so they support ipv6 (no, I did not apply fefe's patches, I did my own tyvm)
2021-08-26 14:11:55 <skarnet> the only thing that's missing from it is dnssec for those who want it
2021-08-26 14:12:58 <dalias> heh lacking ipv6 omg
2021-08-26 14:12:59 <mps> for local I use dnsmasq because it have dhcp and tftp servers
2021-08-26 14:14:15 <skarnet> dalias: it's code from 1998 and it's awesome that it still works better than about anything else today
2021-08-26 14:14:58 <skarnet> I kicked myself into adding ipv6 support to it because it was still less effort than getting some other shit to run the way I wanted it to run
2021-08-26 14:15:24 <mps> iirc, I patched it to use ipv6
2021-08-26 14:15:26 <dalias> i dont use any of the extra stuff in dnsmasq (except blocking some ad domains, but i want to drop that and do it differently), i just like that it's small and validating
2021-08-26 14:15:42 <mps> found patch somewhere on the but forgot where
2021-08-26 14:15:59 <mps> on the net*
2021-08-26 14:16:31 <mps> (not easy to type at 3 channels simultaneously)
2021-08-26 14:16:56 <Habbie> hmm, it looks like musl sends the same query to all IPs in resolv.conf simultaneously
2021-08-26 14:17:41 <Habbie> i can also confirm it will not resolve a name with 100 or 300 A records
2021-08-26 14:18:03 <skarnet> yes, that's what it does
2021-08-26 14:18:09 <Habbie> right
2021-08-26 14:18:12 <Habbie> most stubs don't :)
2021-08-26 14:18:25 <skarnet> most?
2021-08-26 14:18:32 <Habbie> as far as i know, yes
2021-08-26 14:18:35 <dalias> yes this is musl's secret sauce for why it's so fast :-p
2021-08-26 14:18:36 <skarnet> it's not like there are hundreds
2021-08-26 14:18:47 <Habbie> certainly tens
2021-08-26 14:19:13 <Habbie> dalias, lol
2021-08-26 14:19:13 <skarnet> deriving from the same shitty old implementation :P
2021-08-26 14:19:27 <Habbie> i have written a few stubs too, but they are not in any libc :D
2021-08-26 14:20:00 <Habbie> skarnet, at least those do TCP :/
2021-08-26 14:20:53 <skarnet> maybe that's why they don't parallelize, because it's too hard to do that *and* tcp :P
2021-08-26 14:21:20 <skarnet> (not every library can be s6dns)
2021-08-26 14:21:29 <skarnet> 
ACTION is already outside

2021-08-26 14:21:32 <Habbie> haha
2021-08-26 14:21:46 <Habbie> well, I'd say it's okay for TCP to be on the slow path anyway
2021-08-26 14:23:46 <dalias> yes, one of the open questions is how to do the tcp query in this framework
2021-08-26 14:24:19 <Habbie> yes, i understood that that would be tricky
2021-08-26 14:24:22 <Habbie> (i was not informed why)
2021-08-26 14:24:45 <dalias> query just the server that replied with tc?
2021-08-26 14:24:49 <dalias> or go back to all of them
2021-08-26 14:24:50 <dalias> etc
2021-08-26 14:24:53 <Habbie> oh like that
2021-08-26 14:25:17 <dalias> presumably whoever replied with tc already knows the full response
2021-08-26 14:25:28 <dalias> but it may be over a higher latency link
2021-08-26 14:25:30 <Habbie> well i'm not a fan of the 'to all of them' anyway, so 'go TCP to the one that said TC' makes sense to me
2021-08-26 14:25:37 <Habbie> yep, all true
2021-08-26 14:28:01 <Habbie> in that sense EDNS is more fun
2021-08-26 14:28:12 <Habbie> or at least, it mostly avoids -these- questions
2021-08-26 14:28:13 <Hello71> no matter what you pick, someone will complain that it doesn't work with some shit enterprise software
2021-08-26 14:28:41 <Habbie> correct
2021-08-26 14:28:56 <Habbie> glibc had to grow an option to make parallel A+AAAA queries more distinct because some firewall would always eat the second of the two
2021-08-26 14:31:26 <dalias> i think that one was junk routers made for home not enterprise but i'm not sure
2021-08-26 14:31:56 <Habbie> oh could be
2021-08-26 14:33:54 <Habbie> dalias, if i wanted to hack on this, are there open tickets, abandoned attempts (both TCP and EDNS) i could look at?
2021-08-26 14:34:35 <Habbie> i think you mentioned a thread in a tweet?
2021-08-26 14:34:42 <skarnet> the problem with multi-tcp sessions is that tcp is a stream, not a dgram sequence, so sends and recvs aren't atomic and you have to memorize a lot of state, this makes for a complex state machine
2021-08-26 14:34:53 <skarnet> this is probably why nobody does it
2021-08-26 14:35:28 <Habbie> ack
2021-08-26 14:35:44 <skarnet> (I've done it but it's a separate library, can use malloc, would be annoying to fit into a libc)
2021-08-26 14:37:33 <dalias> skarnet, i dont think it's that bad.
2021-08-26 14:37:53 <dalias> habbie, mostly it's a matter of figuring out what the behavior should be, what the weird corner cases are, etc.
2021-08-26 14:38:33 <skarnet> dalias: as long as you don't mind pulling in malloc and relax your size constraints, sure, it can be done
2021-08-26 14:38:45 <dalias> ?? malloc has nothing to do with it
2021-08-26 14:38:47 <Habbie> skarnet, i've also done it, can probably even do it without mallocs -per lookup-
2021-08-26 14:38:59 <Habbie> 'just' need 64kbyte of permanent scratch space
2021-08-26 14:39:01 <Habbie> .. per thread
2021-08-26 14:39:06 <dalias> at the api level the caller provides the buffer space
2021-08-26 14:39:17 <Habbie> dalias, which api?
2021-08-26 14:39:43 <Habbie> i was thinking in getaddrinfo terms, with a black box underneath
2021-08-26 14:39:57 <dalias> res_send and friends
2021-08-26 14:40:09 <skarnet> what if the answer is bigger than the caller-provided buffer space? you fail and the caller has to query again? I don't like malloc, but I like network round-trips even less
2021-08-26 14:40:12 <Habbie> right - musl builds on those internally too? just reimplemented?
2021-08-26 14:40:46 <Habbie> (brb)
2021-08-26 14:40:46 <dalias> habbie, basically. there's an awkward internal res_msend (m=multi) for parallel queries of a and aaaa
2021-08-26 14:41:13 <dalias> skarnet, that's the api :-p
2021-08-26 14:41:26 <dalias> caller can make it 64k if they want arbitrary result
2021-08-26 14:41:49 <skarnet> yeah this is why gai and res_ suck
2021-08-26 14:45:07 <dalias> or am i misremembering and there's no 64k limit?
2021-08-26 14:45:30 <skarnet> on udp, there is
2021-08-26 14:45:35 <dalias> at least individual rdata has such a limit
2021-08-26 14:45:36 <skarnet> on tcp, I'm not sure, would need to check
2021-08-26 14:46:29 <dalias> anyway there's no interface here that performs raw dns queries and returns an allocated result
2021-08-26 14:47:02 <skarnet> which is why I will never use the libc resolvers :P
2021-08-26 14:47:16 <Habbie> back
2021-08-26 14:48:07 <dalias> and there's no clear documentation on what res_send is supposed to do if the result does not fit in the provided buffer
2021-08-26 14:48:18 <Habbie> on udp the limit is 512 without EDNS and 'a bigger number' (but under 64k and usually under 4k) with EDNS
2021-08-26 14:48:40 <dalias> i think the most reasonable thing is just patching up the header to add TC bit and cut off counts that don't fit
2021-08-26 14:49:07 <Habbie> patching up where exactly?
2021-08-26 14:49:11 <Habbie> slash when
2021-08-26 14:49:19 <skarnet> it's incredible that it's exactly what dnsfunnel does
2021-08-26 14:49:21 <dalias> before returning
2021-08-26 14:49:39 <Habbie> dalias, oh, right, this is the case where we got full data, perhaps even over tcp, but our caller has given us a small buffer?
2021-08-26 14:49:44 <dalias> right
2021-08-26 14:49:50 <Habbie> ok, sure, yes
2021-08-26 14:50:16 <dalias> so i think you have to iterate the records in the result until the next would go past the end of the packet
2021-08-26 14:50:21 <Habbie> do we expect callers to grab records from a TC=1 response at all?
2021-08-26 14:50:26 <skarnet> dalias: exactly
2021-08-26 14:50:36 <dalias> then limit that count in the header, and zero all the subsequent counts
2021-08-26 14:50:43 <dalias> then |= TC to the flags
2021-08-26 14:50:46 <Habbie> sure - that's how name servers also used to do that
2021-08-26 14:50:51 <Habbie> (most have stopped, though)
2021-08-26 14:51:12 <dalias> afaik all except google's do
2021-08-26 14:51:32 <dalias> i've not seen reports of this problem except with google dns
2021-08-26 14:51:51 <Habbie>  dig a 100-ips.7bits.nl @8.8.8.8 +ignore +noedns
2021-08-26 14:51:53 <Habbie> zero records
2021-08-26 14:51:55 <Habbie> right
2021-08-26 14:52:11 <dalias> right, google dns
2021-08-26 14:52:26 <Habbie> i get no records out of 9.9.9.9 either
2021-08-26 14:52:42 <Habbie> nor 1.1.1.1
2021-08-26 14:53:27 <Habbie> so now i wonder why your reports appear to be limited to google dns
2021-08-26 14:54:18 <dalias> maybe nobody uses the others :-p
2021-08-26 14:54:30 <Habbie> hehe
2021-08-26 14:54:50 <dalias> but i was thinking of most standard dns software not a few giant providers running their own quirky software
2021-08-26 14:54:59 <Habbie> quad9 runs powerdns and unbound, fwiw
2021-08-26 14:55:21 <dalias> likely heavily modified?
2021-08-26 14:55:24 <Habbie> nope
2021-08-26 14:55:34 <Habbie> (i talk to them almost every day)
2021-08-26 14:55:43 <Habbie> (about the powerdns side of things, anyway)
2021-08-26 14:56:03 <dalias> cloudflare does some wacky stuff for the domains they host but i dont know about their public recursive
2021-08-26 14:56:11 <dalias> (messing up nodata vs nxdomain)
2021-08-26 14:56:21 <Habbie> 1.1.1.1 once was Knot Resolver but now barely resembles it
2021-08-26 14:56:43 <Habbie> and OpenDNS still has about 100 lines of djbdns dnscache left, they tell me ;)
2021-08-26 14:56:44 <dalias> anyway without the @8.8.8.8 i get results :)
2021-08-26 14:56:59 <ikke> ecraven: we do not support skipping checksums
2021-08-26 14:56:59 <Habbie> dalias, without EDNS?
2021-08-26 14:57:03 <dalias> yes
2021-08-26 14:57:05 <Habbie> can i see?
2021-08-26 14:57:31 <dalias> meh is ix.io still down? :(
2021-08-26 14:57:43 <Habbie> i see the ix.io frontpage
2021-08-26 14:57:51 <dalias> ah it's back now
2021-08-26 14:57:53 <dalias> just slow
2021-08-26 14:57:58 <dalias> http://ix.io/3x1m
2021-08-26 14:58:11 <Habbie> says 127.0.0.1
2021-08-26 14:58:17 <dalias> yes
2021-08-26 14:58:22 <Habbie> what's on there?
2021-08-26 14:58:31 <dalias> validating dnsmasq
2021-08-26 14:58:50 <Habbie> right - i suspect dnsmasq is making this 'as big as possible' packet for you then?
2021-08-26 14:59:15 <dalias> yes, it's doing the truncation skarnet and i described per the original spec :)
2021-08-26 14:59:20 <Habbie> right!
2021-08-26 14:59:28 <Habbie> ok, then i am no longer confused
2021-08-26 14:59:59 <Habbie> the problem then is people pointing musl directly at just about any popular resolver software
2021-08-26 15:00:58 <dalias> well it's unfriendly not to do it. even once we add tcp fallback, not doing the truncation in will make the lookup much slower
2021-08-26 15:01:19 <Habbie> because they have to alloc bigger and retry?
2021-08-26 15:01:32 <Habbie> and we have no way to hold on to it for them until they retry with a bigger buffer
2021-08-26 15:02:20 <Habbie> but, academic until we have EDNS or TCP at all, of course
2021-08-26 15:02:31 <dalias> no, just because there are multiple extra round trips just to recv the tcp result into a 512-byte buffer and truncate it client side :-p
2021-08-26 15:02:52 <Habbie> right, if the buffer is the problem, the roundtrips are just between user and kernel space
2021-08-26 15:03:05 <dalias> no, i mean ip round trips
2021-08-26 15:03:31 <Habbie> once TCP is connected, why would there be more roundtrips than for UDP?
2021-08-26 15:05:34 <dalias> "once tcp is connected" is already 1.5 round trips :-p
2021-08-26 15:05:52 <dalias> which occur after 1 round trip attempting udp and not getting the answer we wanted
2021-08-26 15:06:10 <Habbie> oh sure, there i agree
2021-08-26 15:06:23 <Habbie> i thought you were saying a big answer would require multiple 'reads from the other server' inside the TCP session
2021-08-26 15:06:29 <dalias> if the recursive had given us the tc'd answer we want, we'd be done after one round trip
2021-08-26 15:06:36 <Habbie> sure
2021-08-26 15:06:41 <Habbie> but recursives mostly don't do that any more
2021-08-26 15:07:18 <dalias> i dont think that's a well-quantified "most"
2021-08-26 15:07:22 <dalias> aren't most bind?
2021-08-26 15:07:40 <Habbie> it is not well-quantified
2021-08-26 15:07:51 <dalias> anyway right nog i'm not trying to make an argument against supporting tcp fallback.
2021-08-26 15:07:54 <dalias> now*
2021-08-26 15:07:56 <Habbie> right, ok
2021-08-26 15:08:03 <dalias> rather i'm saying that not doing the tc is *bad server behavior*
2021-08-26 15:08:11 <Habbie> it's clear that there are -plenty- recursives out there that send empty TC
2021-08-26 15:08:17 <Habbie> and that's not going to change
2021-08-26 15:08:19 <dalias> because, even if the client can fallback to tcp, it makes the lookup take a lot longer
2021-08-26 15:09:00 <dalias> so it's simultaneously true that (1) libc should deal with the bad behavior, and (2) the bad behavior should be fixed (i.e. return to following historical practice) to get rid of the gratuitously bad performance
2021-08-26 15:09:19 <Habbie> i don't think (2) is going to happen
2021-08-26 15:09:37 <Habbie> especially as EDNS also mostly takes the pain away
2021-08-26 15:09:57 <Habbie> and (2) does not help the DKIM or DANE cases
2021-08-26 15:10:07 <Habbie> because there, individual records are already too big
2021-08-26 15:10:16 <Habbie> and also, clients need to know if their answer is complete
2021-08-26 15:10:29 <dalias> right. it just helps avoid slowness where someone put way too many A or AAAA records
2021-08-26 15:10:33 <dalias> but that does happen a lot
2021-08-26 15:10:41 <Habbie> ack
2021-08-26 15:10:57 <Habbie> i also know a lot of people who say "well, let those services suffer" :)
2021-08-26 15:11:01 <dalias> :-p
2021-08-26 15:11:59 <Habbie> (i tend to agree with them)
2021-08-26 15:12:06 <Habbie> anyway, we digress, often ;)
2021-08-26 15:12:39 <Habbie> musl needs TCP support, and EDNS would help performance in some of the cases where TCP support at least makes things work
2021-08-26 15:16:25 <dalias> yes. I don't think EDNS support is worthwhile. it's a lot of complexity (rewriting queries and answers) purely for the sake of making badly behaved sites less slow
2021-08-26 15:18:25 <Habbie> right, that comes back to the various API layers I'm not yet familiar with, but I believe you
2021-08-26 15:45:33 <skarnet> is EDNS0 still mandatory for dnssec support?
2021-08-26 15:45:45 <skarnet> I haven't been following that in a while
2021-08-26 16:28:38 <dalias> skarnet, depends on what you mean
2021-08-26 16:32:52 <dalias> it's not needed to ask the trusted namerserver to suppress bogus results from upstream (it should always do that) or to have it report whether the result is secure or not (requested by AD bit)
2021-08-26 16:33:36 <dalias> but unless i'm missing something it's needed for requesting the upstream to include signatures and other additional records needed to validate in the reply
2021-08-26 16:33:56 <dalias> some of these you could get without edns0 by querying them yourself
2021-08-26 16:34:15 <dalias> but i think denial of existence is hard to do that way
2021-08-26 16:40:41 <Habbie> +AD (I demand authentic data) and +CD (checking disabled - give me whatever you got even if it is DNSSEC bogus) are in the DNS header, indeed
2021-08-26 16:41:03 <Habbie> +DO is in EDNS flags - in fact it's the only EDNS flag currently defined
2021-08-26 16:41:35 <Habbie> dalias, indeed - positive answers are sometimes doable (although many servers out there will not give you consistency between your two queries, and some servers don't give out bare RRSIGs at all)
2021-08-26 16:41:42 <Habbie> and denial is right out
2021-08-26 16:42:42 <Habbie> should we be doing this here, btw, or on some musl channel? :)
2021-08-26 16:56:18 <dalias> :)
2021-08-26 17:02:11 <dalias> habbie, +AD is not "I demand authentic data"
2021-08-26 17:02:34 <dalias> that was the poorly specified old version of it that was replaced
2021-08-26 17:03:05 <Habbie> my coworker made this handy table https://doc.powerdns.com/recursor/dnssec.html#what-when
2021-08-26 17:03:15 <dalias> the current meaning is "tell me if the result is secure or insecure via the AD bit in the result"
2021-08-26 17:03:17 <Habbie> which should be 'not old'
2021-08-26 17:03:35 <Habbie> well, yes, but validators that are not strict also take it to mean 'and please validate for me', unless +CD is also set
2021-08-26 17:03:58 <dalias> validation is always mandatory
2021-08-26 17:04:04 <dalias> unless +CD is set
2021-08-26 17:04:10 <Habbie> or configured otherwise, in practice
2021-08-26 17:04:14 <dalias> :/
2021-08-26 17:04:27 <Habbie> which is a great mode for an ISP that is scared to completely turn it on
2021-08-26 17:04:30 <Habbie> so they can get logs of what would break
2021-08-26 17:04:57 <dalias> modern windows sets +AD in query
2021-08-26 17:05:02 <Habbie> good :)
2021-08-26 17:05:07 <dalias> so this mode you propose would not get used, anyway
2021-08-26 17:05:18 <Habbie> when did windows start doing that?
2021-08-26 17:05:30 <dalias> i dont know. i found out about it via postfix list iirc
2021-08-26 17:05:35 <Habbie> ah
2021-08-26 17:06:09 <Habbie> unbound, btw, also has ignore-cd-flag: :D
2021-08-26 17:06:11 <dalias> postfix folks were helpful working out what musl's AD behavior should be
2021-08-26 17:06:16 <Habbie> nice
2021-08-26 17:07:24 <dalias> currently musl always generates +AD with res_mkquery, but gai disables the +AD before sending, since it won't use the result anyway, in case it's dealing with a broken nameserver that won't accept it
2021-08-26 17:07:47 <dalias> that way res_query/res_send gets a meaningful ±AD for the caller
2021-08-26 17:07:57 <dalias> which is essential if the caller wants to do DANE
2021-08-26 17:08:16 <Habbie> there are resolvers that choke on +AD?
2021-08-26 17:08:25 <dalias> historically i think there were some :/
2021-08-26 17:08:30 <Habbie> right
2021-08-26 17:08:32 <dalias> i'm pretty sure they were all fixed ages ago
2021-08-26 17:08:33 <Habbie> and then hacks stick around
2021-08-26 17:08:36 <dalias> since windows does it
2021-08-26 17:08:41 <Habbie> right
2021-08-26 17:08:56 <dalias> but since gai has no use for the result, i dropped it there to be safe
2021-08-26 17:09:01 <Habbie> got it
2021-08-26 17:09:41 <dalias> if the user has configured their nameserver not to validate if +AD is not set, that's their problem. if it's their isp's server, the validation is not meaningful anyway (it's a third party)
2021-08-26 17:10:00 <Habbie> yes - and that resolver wouldn't set +AD on non-validated results, still
2021-08-26 17:10:04 <Habbie> (one hopes)
2021-08-26 17:10:49 <dalias> yeah, the spec is that you're only allowed (and then required) to set +AD in the result if it was in the query and the result is secure
2021-08-26 17:11:01 <dalias> if it's missing in the query, the result should not have any AD
2021-08-26 17:11:25 <Habbie> powerdns trusts that a client that sets +DO can also handle +AD set
2021-08-26 17:11:38 <Habbie> i don't know if that is RFC-mandated, or suggested, or not mentioned
2021-08-26 17:11:43 <dalias> btw the reason this matters for DANE is that you're only supposed to enforce DANE if the domain is secure
2021-08-26 17:11:51 <Habbie> yep, am aware
2021-08-26 17:12:04 <Habbie> i'm glad to hear musl handles that use case
2021-08-26 17:12:09 <Habbie> took a while for glibc
2021-08-26 17:12:34 <dalias> i hit this and had to research it all working on mxclient
2021-08-26 17:12:47 <dalias> i was just going to always enforce dane
2021-08-26 17:13:07 <dalias> but apparently there are broken domains where the lookup always servfails >_<
2021-08-26 17:13:08 <Habbie> ah, was not aware of mxclient, neat tool
2021-08-26 17:13:11 <Habbie> yep
2021-08-26 17:13:15 <Habbie> bane of my existence some days
2021-08-26 17:13:33 <Habbie> the .nl registry sends me a daily dump of domains that fail that way
2021-08-26 17:13:55 <Habbie> (well, and a few other ways)
2021-08-26 17:14:06 <Misthios> " libc++ now requires being built in a monorepo layout with libcxxabi available" what would be the best way to solve this (already tried adding libcxxabi sources to the apk build, might need to actually build it aswell toh)
2021-08-26 17:31:14 <mps> '../docs/meson.build:32:6: ERROR: Problem encountered: Install a Python 3 version of python-sphinx and the readthedoc theme"
2021-08-26 17:31:36 <mps> this I got building new qemu, what to do to fix this?
2021-08-26 17:33:35 <veiviser> disable docs? or get the py3-sphinx*something packages
2021-08-26 17:35:07 <mps> veiviser:  py3-sphinx is in makedepends
2021-08-26 17:35:57 <veiviser> i would go read that meson.build file and see what it's specifically checking for
2021-08-26 17:36:05 <veiviser> then it's probably just the theme
2021-08-26 17:36:35 <mps> looks like we don't have needed theme, whatever it is
2021-08-26 17:38:26 <veiviser> py3-sphinx_rtd_theme
2021-08-26 17:38:31 <veiviser> mps: ^ should be that i think
2021-08-26 17:39:36 <mps> veiviser: apk search py3-sphinx-theme, don't show anything like this
2021-08-26 17:40:49 <ecraven> ikke: how does that work with snapshots? so I need to update the APKBUILD every time I create a new snapshot?
2021-08-26 17:40:56 <ikke> yes
2021-08-26 17:41:00 <ikke> that's the idea
2021-08-26 17:43:19 <veiviser> mps: it exists, that's what it's called
2021-08-26 17:43:33 <veiviser> i found it in the online search
2021-08-26 17:43:55 <veiviser> https://pkgs.alpinelinux.org/package/v3.14/main/x86_64/py3-sphinx_rtd_theme
2021-08-26 17:46:18 <mps> hmm, why apk search didn't found it
2021-08-26 17:47:01 <mps> ahm, '_' instead of '-'
2021-08-26 17:47:18 <mps> veiviser: thanks for help
2021-08-26 17:47:33 <veiviser> np
2021-08-26 17:51:32 <andypost[m]> mps: so only patch removal and extra dependency blocks qemu 6.1?
2021-08-26 17:52:08 <mps> andypost[m]: well, maybe system-moxie also must be removed or fixed
2021-08-26 17:53:15 <mps> andypost[m]: yes, moxie is removed, https://wiki.qemu.org/ChangeLog/6.1
2021-08-26 17:54:00 <mps> andypost[m]: I'm testing build, when I finish I'll post it to you
2021-08-26 17:54:55 <andypost[m]> thank you! meantime checking why openssl tests faled on builders for php
2021-08-26 17:55:50 <andypost[m]> ikke: looks like the same ones as before
2021-08-26 17:55:58 <ikke> huh
2021-08-26 17:56:25 <ikke> same symptom
2021-08-26 17:57:31 <andypost[m]> yes, the same 5 tests
2021-08-26 17:57:51 <ikke> Ariadne: same is happening again with libcrypto1.1. apk info -L only lists a handful of files, while the package contains more
2021-08-26 17:58:30 <ikke> https://tpaste.us/lyOo 
2021-08-26 17:58:52 <ikke> for some reason /etc is missing
2021-08-26 17:58:53 <andypost[m]> I checked and see nothing in aport to touch this files, maybe some php tests/install internals...
2021-08-26 17:59:18 <ikke> andypost[m]: but then apk should still report these files I assume
2021-08-26 17:59:34 <ikke> and non-root processes should not be able to touch them anyway
2021-08-26 18:00:50 <andypost[m]> hm, yes... and all builders looks affected again
2021-08-26 18:01:02 <ikke> andypost[m]: maybe due to openssl3.0?
2021-08-26 18:01:10 <ikke> it has replaces=libcrypto1.1
2021-08-26 18:02:20 <ikke> yes
2021-08-26 18:02:40 <ikke> after I install openssl3.0 from testing, libcrypto1.1 no longer owns those files, and after it's removed, they don't come back
2021-08-26 18:02:43 <ikke> Ariadne: ^
2021-08-26 18:02:47 <andypost[m]> but nothing is using 3.0 yet
2021-08-26 18:03:13 <andypost[m]> openldap is blocker
2021-08-26 18:05:50 <ikke> I don't know how it's installed, but installing it reproduces the issue
2021-08-26 18:06:58 <ikke> ecraven: alpine's philosofy is that the same apkbuild should result in the same package
2021-08-26 18:08:13 <mps> andypost[m]: there is 'more' changes for qemu, https://tpaste.us/dPZl
2021-08-26 18:08:15 <ecraven> ikke: ok, not a bad idea ;)
2021-08-26 18:08:22 <andypost[m]> I wanna remove php7-static from 3.14 as it useless nowadays - is it fits in BC policy?
2021-08-26 18:08:55 <ikke> I don't think we should remove it from a stable release
2021-08-26 18:09:17 <veiviser> mps: having fun i see!
2021-08-26 18:09:29 <andypost[m]> then just reordering -static and then -dbg? as I see 
2021-08-26 18:09:42 <mps> ncopa: what you think about these qtest servers for qemu?
2021-08-26 18:10:18 <mps> veiviser: yes, fun. but luckily qemu people are kind
2021-08-26 18:40:35 <mps> andypost[m]: here is complete fix for qemu build https://tpaste.us/Mz41
2021-08-26 18:40:40 <mps> ncopa: ^
2021-08-26 18:48:48 <mps> hmm, ncopa forgot to speak ;)
2021-08-26 18:49:48 <veiviser> almost bedtime
2021-08-26 18:50:44 <mps> ah, 'just married' :) I understand
2021-08-26 18:51:00 <veiviser> not sure i understand what that means
2021-08-26 18:51:14 <mps> heh
2021-08-26 18:51:41 <mps> what do just married people in bed
2021-08-26 18:51:49 <veiviser> sleep?
2021-08-26 18:51:54 <mps> :D
2021-08-26 18:56:43 <ncopa> i apk fix openssl on build-edge-armv7
2021-08-26 18:56:56 <ncopa> yes im married and my wife calls me. so....
2021-08-26 18:56:58 <ncopa> see you tm
2021-08-26 18:57:49 <veiviser> sleep well
2021-08-26 18:58:19 <andypost[m]> ikke: thank you, now php passed
2021-08-26 18:59:29 <mps> enjoy, and tomorrow look at andypost[m]s qemu MR
2021-08-26 19:01:35 <mps> what's left? huh llvm12. hope Misthios will finish it
2021-08-26 19:01:52 <Misthios> i am trying
2021-08-26 19:02:12 <Misthios> just upstream made it rlly difficult, split lots up into new stuff
2021-08-26 19:03:09 <Misthios> mps: what would be the best way to solve this: " libc++ now requires being built in a monorepo layout with libcxxabi available"
2021-08-26 19:03:25 <mps> Misthios: something for you https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2021-08-26 19:04:21 <ericonr> Misthios: recommend looking how other distros did the llvm update
2021-08-26 19:04:31 <mps> Misthios: sorry, didn't looked at llvm changes in last few releases, so don't have idea for now
2021-08-26 19:04:36 <Misthios> yeah i was looking at void
2021-08-26 19:04:37 <ericonr> though void has a single package for everything, so we didn't have to condense things together
2021-08-26 19:04:58 <ericonr> anyway, probably just add libcxxabi into things and move it to the correct location in the build tree
2021-08-26 19:05:01 <Misthios> mps it comes down to lld requiring lib-unwind which requires libcxx which wont compile without libcxxabi
2021-08-26 19:05:15 <ericonr> that part you can almost def find from the void build
2021-08-26 19:05:22 <Misthios> question is should i convert libcxx into a package?
2021-08-26 19:05:41 <Misthios> yeah, will take a better look tmw
2021-08-26 19:05:55 <mps> Misthios: sounds like yes, but not sure because didn't looked it
2021-08-26 19:06:42 <mps> iirc from the news, llvm13 is on horizon
2021-08-26 19:06:57 <Misthios> yes, but requires the same as 12 anyway
2021-08-26 19:07:01 <Misthios> so might as well do it now
2021-08-26 19:08:45 <mps> next few days and whole week I think I will be busy with kernel 5.14 upgrade
2021-08-26 19:09:02 <andypost[m]> mps: please check !23389
2021-08-26 19:09:18 <Misthios> i will try to finish llvm12 soon, so u can try to update zig?
2021-08-26 19:10:19 <mps> andypost[m]: sorry, I don't like to mess with Cogitris pkgs
2021-08-26 19:11:25 <mps> I only make mess with ncopas pkgs :) (and jirutka sometimes)
2021-08-26 19:12:23 <mps> but 'time' is mostly problem, never enough
2021-08-26 19:12:51 <mps> (except for babbling on irc)
2021-08-26 19:13:03 <andypost[m]> np) 
2021-08-26 19:15:01 <mps> hehe, руски смайлы
2021-08-26 19:37:05 <Cogitri> mps: Do feel free to mess with my pkgs, I’m on holidays until the 21st September
2021-08-26 19:37:43 <ikke> enjoy
2021-08-26 19:38:53 <mps> Cogitri: thanks. considering removal pipewire and pulse from FF :D
2021-08-26 19:39:16 <mps> and ofc, enjoy your holidays
2021-08-26 19:40:34 <mps> but as I told, I want to concentrate now more on kernels for next stable
2021-08-26 19:40:53 <mps> especially riscv kernel
2021-08-26 19:42:26 <mps> I hope Misthios will finish with llvm
2021-08-26 19:49:50 <Misthios> So do i
2021-08-26 19:53:35 <Misthios> When is the feature freeze max?
2021-08-26 19:53:57 <mps> a day before release ;)
2021-08-26 19:56:13 <ikke> depends on the impact
2021-08-26 19:56:23 <ikke> most of the toolchain is frozen after the builders are setup
2021-08-26 19:56:47 <ikke> Not sure whether llvm is considered part of that
2021-08-26 19:57:22 <ikke> if it's just added as an optional version (not the main llvm version), then it should not matter that much
2021-08-26 20:13:03 <Misthios> I mean llvm has clang which is toolchain
2021-08-26 20:13:49 <Cogitri> ikke, mps: Thanks :)
2021-08-26 20:14:25 <Cogitri> Do feel free to ping me if there’s something that needs my attention though, I’m sure there’ll be some rainy days here on Guernsey too :)
2021-08-26 20:15:22 <Cogitri> Re bumping LLVM before release: IMHO it should be done at least two weeks before the release because LLVM, CLang, LLDB and all have to be updated at the same time
2021-08-26 20:15:33 <Cogitri> So the chance that one of those fails on some arch is relatively high
2021-08-26 20:20:07 <Misthios> Llvm and clang are done
2021-08-26 20:20:22 <Misthios> Just some "smaller" parts are giving me a hard time
2021-08-26 20:21:03 <ikke> But if you provide it just as llvm12, then only packages that explicitly ask for llvm12 should be affected
2021-08-26 20:27:13 <Cogitri> Yeah but we don’t version clang
2021-08-26 20:27:32 <Cogitri> And an application pulls in llvm12 it can’t use clang (11)
2021-08-26 20:28:03 <ikke> oh, ok
2021-08-26 20:28:12 <Cogitri> And I think zig also needs clang
2021-08-26 20:29:58 <ikke> The amount of packages seem limited
2021-08-26 20:30:56 <Cogitri> That pull in llvm?
2021-08-26 20:31:10 <ikke> llvm / llvm11 / clang
2021-08-26 20:31:41 <Cogitri> Ah yes, if we decide to keep those at lower versions so they work with llvm11 that shouldn’t be a problem
2021-08-26 20:31:59 <ikke> 9 in main+community
2021-08-26 20:32:03 <Cogitri> But I’m not sure if it’s worth it introducing llvm12 in the repos only to then only build a handful of packages against it
2021-08-26 20:32:39 <ikke> well, there are some packages that require it, like you mentioned
2021-08-26 21:13:33 <Ariadne> > Same seems to be the case for AWS corretto.
2021-08-26 21:13:43 <Ariadne> ncopa: yeah but does that come with per-second billing :D
2021-08-26 21:17:14 <mps> Cogitri: you are right, zig still needs clang
2021-08-26 21:17:49 <mps> while crystal only need llvm
2021-08-26 21:19:32 <mps> and iirc, as of zig 0.8.0 it would be posible to use zig to build next zig. but we will see
2021-08-27 03:22:05 <kevint> I'm trying to login to the Gitlab on my laptop and am getting a 422: "The change you requested was rejected." I'm not getting this error on my desktop. Does anyone know what could be going on?
2021-08-27 03:23:07 <smcavoy> hello, I was going to update jenkins LTS across alpine-3.1x, does this make sense? Currently I see various versions for each 3.1x release
2021-08-27 03:24:05 <veiviser> yes, because at the time of each release a different version was tagged
2021-08-27 03:25:48 <smcavoy> veiviser: are they meant to left as is? 
2021-08-27 03:26:48 <veiviser> that is how released packages usually work, yes, unless there is a security issue for the tagged version on the specific i.e. 3.13 release, it will be that version forever
2021-08-27 03:26:57 <veiviser> if you want the newer version you have to update to the latest alpine too
2021-08-27 03:31:51 <smcavoy> certainly there are security issues. It seems to me tracking the lts release and doing security updates within 3.1x releases would better than distributing a version that is released on a weekly basis..
2021-08-27 03:32:27 <veiviser> what security issues are there
2021-08-27 03:34:16 <smcavoy> this is from the jenkins included in 3.14 (2.297) https://www.jenkins.io/security/advisory/2021-06-30/
2021-08-27 03:35:35 <veiviser> ah, i see what you mean
2021-08-27 03:35:47 <veiviser> sorry, took me like 10 minutes to understand this versioning scheme
2021-08-27 03:36:00 <veiviser> yes, it should probably pick the latest lts at time of package freeze
2021-08-27 03:38:15 <veiviser> fcolista: perhaps it would make more sense to tag the lts version of jenkins for releases? ^
2021-08-27 03:51:38 <Hello71> kevint: have you tried clearing your cookies
2021-08-27 03:52:59 <Hello71> smcavoy: jenkins is in community repository so only supported for 6 months
2021-08-27 03:53:13 <Hello71> however probably lts version should be used
2021-08-27 03:53:23 <Hello71> fcolista: ^
2021-08-27 04:08:11 <kevint> Hello71: yes, it's still not working
2021-08-27 04:38:29 <ikke> kevint: it's only happening on your laptop?
2021-08-27 04:39:39 <kevint> ikke: yes
2021-08-27 04:40:24 <ikke> In the logs it complains about InvalidAuthentiticyToken
2021-08-27 04:43:12 <ikke> kevint: can you try to see if it works in a private tab?
2021-08-27 04:43:21 <ikke> or in a clean browser profile
2021-08-27 04:45:26 <kevint> Ah yeah, switching to a clean browser profile worked
2021-08-27 04:47:04 <kevint> Oh, and a private window works too, I thought I already tried that but I guess I didn't
2021-08-27 04:47:13 <kevint> Thanks!
2021-08-27 04:48:17 <ikke> so either something in the cache, or an extension might be causing this
2021-08-27 04:50:35 <kevint> Yeah I think it must be something in the cache, because I only have Ublock Origin, Privacy Badger, and Dark Reader, and neither one of the first two block anything
2021-08-27 04:54:02 <ikke> maxice8: regaring howard-bc, it seems on the builder, after the tests is starts to use a huge amount of memory
2021-08-27 04:54:46 <ikke> the oom-killer is what's killing it
2021-08-27 05:13:57 <ikke> maxice8: interesting, the archive on the builder as 3 more tests
2021-08-27 05:28:27 <ikke> oh, needed to upgrade
2021-08-27 05:28:31 <ikke> my repo
2021-08-27 05:44:13 <ncopa> good morning
2021-08-27 05:44:29 <mps> good morning
2021-08-27 05:44:32 <ikke> morning
2021-08-27 05:49:56 <ncopa> mps: sorry that i have been unavailable for your questions lately. did you have a fix for qemu build?
2021-08-27 05:51:02 <mps> ncopa: no problem
2021-08-27 05:52:19 <mps> actually andypost[m] made upgrade and MR (and assigned to me), I just found some issues and add some changes to APKBUILD
2021-08-27 05:53:11 <mps> !24208
2021-08-27 05:53:44 <mps> upgrade to 6.1.0 have a significant changes
2021-08-27 05:54:32 <mps> here is changelog https://wiki.qemu.org/ChangeLog/6.1
2021-08-27 06:09:56 <ncopa> mps: did you investigate the qemu module dependencies? I remember spending some time on that in the past
2021-08-27 06:10:48 <ncopa> there are some new hw-display-virtio-gpu-* modules
2021-08-27 06:13:42 <smcavoy> Hello71: is there any problem with putting in updates for security releases in 3.1x ?
2021-08-27 06:14:02 <mps> ncopa: no, I didn't. I just wanted to fix build first and to test some new features on my local boxes (and also I remember previous 'upgrade' :) )
2021-08-27 06:16:01 <ncopa> ok. but it builds at least, which is good.
2021-08-27 06:16:07 <ncopa> thank you for following up with upstream also
2021-08-27 06:16:20 <ncopa> the qemu module deps are non-trivial
2021-08-27 06:16:24 <mps> ncopa: ikke: (and other) you probably remember my attitude to deps, i.e. minimum needed
2021-08-27 06:17:20 <ncopa> yes, i understand that, but we need to make sure that it actually pulls in required dependencies, instead of expectin end user figure that out
2021-08-27 06:17:26 <mps> yes, qemu is 'big' piece of code and not so simple
2021-08-27 06:17:27 <ncopa> otherwise people will just install them all
2021-08-27 06:18:48 <mps> making decision what to install (pull) for our users is 'complicated' for me
2021-08-27 06:19:06 <ncopa> yes, its complicated
2021-08-27 06:19:36 <ncopa> basically, nm -D /path/to/module will list the needed symbols with 'U'
2021-08-27 06:19:49 <ncopa> those will be provided by other libraries or qemu itself
2021-08-27 06:20:14 <ncopa> nm -D /path/to/module will also list the symbols that is provided by that module
2021-08-27 06:20:28 <mps> one of important reasons to left debian and switch to alpine is that the debian pulls a lot of deps which mostly are not needed
2021-08-27 06:21:23 <ncopa> so if moduleA has a 'T' qemu_symbola, and moduleB has a 'U' qemu_symbola, then moduleB should depend on moduleA
2021-08-27 06:21:46 <ncopa> but figuring out all those is non-trivial
2021-08-27 06:21:48 <mps> if you think they are essentially needed I could try tomorrow to find them
2021-08-27 06:22:00 <ncopa> i have a lua script here to help me do it
2021-08-27 06:23:11 <ncopa> what are those qemu-accel-qtest-* modules?
2021-08-27 06:24:03 <mps> 'The qtest server can be created using "-object qtest,chardev=...,log=...". This is alternative to the -qtest and -qtest-log options.' quote from changelog
2021-08-27 06:25:09 <mps> I promised to post build logs to upstream and thought to ask them what are these and do the distros 'must' have them 
2021-08-27 06:25:47 <ncopa> $ lua5.3 ~/qemu-module-deps.lua /usr/lib/qemu/*.so | sort -u | tpaste
2021-08-27 06:25:47 <ncopa> https://tpaste.us/ypgy
2021-08-27 06:26:22 <mps> aha
2021-08-27 06:26:42 <mps> would you mind to share your lua script for this?
2021-08-27 06:28:39 <ncopa> https://tpaste.us/YEdg
2021-08-27 06:29:05 <ncopa> $ tpaste < ~/qemu-module-deps.lua 
2021-08-27 06:29:05 <ncopa> https://tpaste.us/5nPy
2021-08-27 06:30:44 <mps> thanks
2021-08-27 06:30:58 <mps> ohm, Bad Gateway :)
2021-08-27 06:31:09 <ncopa> i think it works if you retry
2021-08-27 06:31:16 <mps> yes, ofc
2021-08-27 06:31:16 <ncopa> tpaste.us is not feeling well this morning
2021-08-27 06:31:31 <mps> but annoying in last two days
2021-08-27 06:31:57 <ikke> restarted it again
2021-08-27 06:32:21 <mps> ikke: rewrite it in perl ;)
2021-08-27 06:32:38 <ncopa> i was actually thinking of reqriting it in go
2021-08-27 06:34:14 <mps> it's a pity crystal doesn't works on more arches, it looks nice for web apps imo
2021-08-27 06:34:29 <ncopa> ok. qtest is a frameqork for the qemu unit test: https://wiki.qemu.org/Features/QTest
2021-08-27 06:35:38 <ncopa> i think golang is designed for things like tpaste.us and would be my first choice for that task today
2021-08-27 06:36:03 <mps> yes, I saw that. but still not sure should we make them all for users
2021-08-27 06:36:24 <mps> I mean, qtest
2021-08-27 06:37:02 <mps> if we package them maybe this is 'overkill', if we don't maybe users ask why we didn't
2021-08-27 06:37:52 <mps> I tend to think we should package them, but not sure
2021-08-27 06:59:02 <ncopa> i think its ok to package them. and it is good that they are in separate subpackages
2021-08-27 07:00:47 <ncopa> i will try tag a 3.14 release today
2021-08-27 07:00:54 <ikke> \o/
2021-08-27 07:04:47 <mps> ncopa: ok, if you think that is good to have them in qemu I will not 'object' against
2021-08-27 07:07:13 <mps> and I will try again to fix linux-lts virt for armv7, but next week, too late now for new iso armv7 img
2021-08-27 08:45:27 <markand> o/
2021-08-27 08:58:03 <ncopa> mps: fix linux-virt for armv7? i think I already fixed it?
2021-08-27 08:58:37 <ncopa> cd1c7cfdc49b2ed6de504c53a23fb11620786888
2021-08-27 09:06:12 <mps> ncopa: just got answer on #qemu about these accel-qtest modules => 10:54 ..... mcayland| mps: qtest is the test framework for running "make check" so shouldn't be needed for end users
2021-08-27 09:12:32 <ncopa> ok. we probably just delete those then?
2021-08-27 09:14:39 <mps> looks like that is what we should do
2021-08-27 09:18:12 <mps> oh, we have check disabled in options for qemu APKBUILD
2021-08-27 09:56:56 <mps> ncopa: https://tpaste.us/vgaY
2021-08-27 09:57:17 <mps> does this looks sane as last change to qemu MR
2021-08-27 10:15:57 <ncopa> yes 👍
2021-08-27 10:17:06 <mps> ok, lets test yet another 'abuild -r' with you change for module deps
2021-08-27 10:48:08 <mps> andypost[m]: could you somehow apply this patch to qemu MR https://tpaste.us/Qr0b
2021-08-27 10:53:47 <andypost[m]> mps: pushed, thanks
2021-08-27 10:56:26 <mps> andypost[m]: thank you
2021-08-27 10:57:02 <mps> ncopa: looks like it is ready for merge
2021-08-27 11:04:36 <ncopa> maybe remove the "draft" prefix
2021-08-27 11:08:22 <mps> done
2021-08-27 11:15:41 <ncopa> good job!
2021-08-27 11:16:14 <mps> I hope so, but we will know in few days
2021-08-27 11:16:51 <mps> did you finished with 3.14.2 release
2021-08-27 11:17:49 <mps> I would like to discuss armv7 virt when you have some time
2021-08-27 11:18:15 <ncopa> i tagged it and am working on the post relase stuff like release notes, signing etc
2021-08-27 11:18:22 <ncopa> does this look ok? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.14.2-released.md
2021-08-27 11:18:41 <ncopa> see the release progress here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12952
2021-08-27 11:20:31 <mps> huh, didn't I upgraded dovecot for 3.14-stable
2021-08-27 11:21:50 <mps> uhm, uhm
2021-08-27 11:26:00 <Hello71> smcavoy: what is this "3.1x" you keep talking about
2021-08-27 11:57:23 <ncopa> can anyone please help me review before I publish? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.14.2-released.md
2021-08-27 11:58:55 <ikke> the git log link does not work (redirected to the main log)
2021-08-27 11:59:26 <ikke> oh, because the tag does not exist yet ofcourse
2021-08-27 12:00:22 <ikke> ncopa: looks good
2021-08-27 12:05:52 <ncopa> no the tag exists, it url was wrong. needed to remove .../cgit/...
2021-08-27 12:05:54 <ncopa> i think
2021-08-27 12:05:58 <ncopa> now it works
2021-08-27 12:06:04 <ncopa> ppc64le is broken again
2021-08-27 12:06:11 <ncopa> i dont know what happened with it this time
2021-08-27 12:08:10 <ncopa> it fails to upload
2021-08-27 12:40:15 <ncopa> seems like i can upload from build-3-14-ppc64 if I add a --bwlimit to rsync
2021-08-27 12:41:24 <ncopa> i have two tcpdumps, one from the ppc64 ubuntu host and one from the dl-master in case someone whats to investigate.
2021-08-27 13:11:14 <andypost[m]> ikke: riscv builder looks hanging on smokeping
2021-08-27 13:28:52 <ikke> It seems to be doing nothing
2021-08-27 14:02:41 <mps> ncopa: re armv7 virt iso, it doesn't boot as fcolista can confirm, some other options or drivers needs to be added
2021-08-27 14:03:10 <ncopa> ok. do know which options or drivers?
2021-08-27 14:03:45 <ncopa> can you create an issue with the details you know
2021-08-27 14:03:47 <mps> not sure, have to look at diff with linux-edge
2021-08-27 14:04:25 <ncopa> can you please create an issue? and fill in what you do know
2021-08-27 14:04:38 <ncopa> and how i can reproduce
2021-08-27 14:04:39 <mps> I created 'private' iso img with linux-edge and made short script here https://arvanta.net/alpine/install-armv7-qemu/
2021-08-27 14:05:12 <mps> probably fcolista can explain where it failed better than me
2021-08-27 14:06:19 <mps> I can make needed changes for linux-lts, if you are willing to review them and merge if you are satisfied
2021-08-27 14:06:43 <ncopa> please add the info to an issue to i can find it later
2021-08-27 14:07:07 <ncopa> yes you can create an MR referring to the issue that I can evaluate
2021-08-27 14:07:14 <mps> will try (though this gitlab interface annoys me)
2021-08-27 14:07:29 <ncopa> thanks
2021-08-27 14:07:36 <ncopa> alternatively git send-email
2021-08-27 14:07:40 <ncopa> if that still works
2021-08-27 14:07:56 <mps> uh, worse then :)
2021-08-27 14:08:32 <mps> I would propose disabling this, i.e. git send-email
2021-08-27 14:09:25 <mps> but, yesterday I even opened account on gitlab.com to help with qemu fixes, so maybe I will learn to live gitlab interface
2021-08-27 14:11:01 <ikke> mps: glab issue create :P
2021-08-27 14:11:33 <mps> ikke: yes, yet another UI to learn ;)
2021-08-27 14:16:02 <xordspar0> As a package maintainer, I have been pretty impressed with the mailing list/Gitlab integration. I recently had a contributor send a patch with git send-email to the mailing list. I reviewed and accepted the patch via Gitlab. The process was seamless for both of us. It makes me want to try using the mailing list to submit all my patches.
2021-08-27 14:17:03 <ikke> The downside for us is that each patch series revision becomes a new MR for us
2021-08-27 14:24:23 <mps> and we have two 'channels' for patches/MRs which is annoying at least
2021-08-27 14:47:25 <Habbie> skarnet, dalias, somebody on https://chat.dns-oarc.net/ just mentioned that we sorely lack stub developers in the community - are either of you interested in joining? signup is free
2021-08-27 14:53:19 <skarnet> did you just call me a stub developer
2021-08-27 14:53:37 <Habbie> well i did not explicitly mean to
2021-08-27 14:53:48 <Habbie> but you have written software that does DNS things, and you had interest in the musl stub discussion, so i just put you in there ;)
2021-08-27 14:54:07 <skarnet> I WILL SHOW YOU STUBS
2021-08-27 14:54:37 <skarnet> more seriously, it will be quite some time before I can get serious with DNS again
2021-08-27 14:54:45 <Habbie> ack
2021-08-27 14:54:50 <skarnet> (that's a lot of seriousness in one line)
2021-08-27 14:54:55 <Habbie> yes
2021-08-27 14:55:39 <skarnet> DNS is a very high maintenance mistress
2021-08-27 14:56:09 <skarnet> really not worth the headaches, the nightly rows, the drama
2021-08-27 14:58:35 <xordspar0> ikke: Ah, that's too bad. I like how Gitlab handles revisions of a patch.
2021-08-27 15:05:23 <dalias> what is this chat platform? something new and web based? :(
2021-08-27 15:07:02 <Habbie> it is, yes
2021-08-27 15:09:00 <dalias> that's kinda a big obstacle to casual participation :/
2021-08-27 15:12:31 <skarnet> tbf I was expecting a Discord channel :P
2021-08-27 15:14:35 <dalias> :-p
2021-08-27 15:50:35 <Habbie> skarnet, at least you only need to signup once for all of Discord
2021-08-27 15:51:13 <Habbie> dalias, 'matterbridge' and 'matterircd' do exist, to turn it into some other protocol
2021-08-27 16:56:23 <maxice8>  @Ikke: hopefully that is something that can be fixed 
2021-08-27 20:37:16 <craftyguy> hmm, what options do I have when the apk database is busted? "ERROR: Unable to read database state: No buffer space available"
2021-08-27 20:43:56 <craftyguy> I guess that's errno 105
2021-08-27 20:51:00 <craftyguy> there was some garbage at the end of /lib/apk/db/installed, so I just deleted that. /shrug 
2021-08-27 21:10:31 <kevint> Can I get a look at !23448 ?
2021-08-28 02:15:43 <smcavoy>   Hello71 Alpine releases. I see updates, security related, to 3.12 3.13 and 3.14 from time to time, I assumed they were considerd current and therefore should get security updates..
2021-08-28 02:16:02 <Hello71> https://alpinelinux.org/releases/
2021-08-28 02:16:11 <Hello71> "3.1x" isn't a thing
2021-08-28 02:19:56 <smcavoy> what is the best way to referr to the currently supported versions of Alpine Linux?
2021-08-28 02:20:12 <veiviser> that page tells you the EOL for all the versions
2021-08-28 02:20:40 <veiviser> 3.11 ends in november, 3.12 6 months after that, etc
2021-08-28 02:21:37 <smcavoy> right, so I was referring to those versions and not the versions that are no longer supported.
2021-08-28 02:22:43 <veiviser> yes
2021-08-28 02:22:57 <veiviser> i see hello71 was just being pedantic about what you were referring to instead of actually being useful
2021-08-28 02:23:25 <veiviser> there should indeed not be an issue with security fixes on the supported releases, but you should reach out to the specific maintainers of affected packages if you're unsure
2021-08-28 02:23:32 <veiviser> and email is probably better than irc, but i'm not sure
2021-08-28 02:26:58 <smcavoy> An email directly or via an issue in gitlab?
2021-08-28 02:27:30 <veiviser> now that i think about it an issue should be best
2021-08-28 02:43:25 <smcavoy> done. 
2021-08-28 08:49:50 <ikke> maxice8: fyi, tests on howard-bc 5.0.2 are working again
2021-08-28 09:35:07 <maxice8> thanks, didn't get around to it yet
2021-08-28 09:35:47 <ikke> I just tested it in my LXC container
2021-08-28 11:02:38 <nmeum> mps: did you encounter any issues with busybox 1.34? otherwise I would probably merge it soonish because I didn't enconuter any problems
2021-08-28 11:16:41 <mps> nmeum: no problems, though I didn't tested it thoroughly, just use it daily
2021-08-28 20:07:47 <mps> finally got riscv64 booting to alpine with u-boot in qemu
2021-08-28 20:10:11 <ikke> nice
2021-08-28 20:10:50 <mps> ikke: where is '\o/' :)
2021-08-28 20:13:52 <Habbie> \o/
2021-08-28 20:14:54 <mps> Habbie: :)
2021-08-28 20:14:59 <Habbie> :)
2021-08-28 20:19:57 <Thermi_> \o/
2021-08-28 20:21:24 <mps> Thermi_: aieee !
2021-08-28 20:22:46 <mps> Thermi_: sorry I didn't answered your comment about kopano, I had a lot of work on fixing some pkgs and I still don't feel good
2021-08-28 20:23:07 <mps> but I didn't forgot it and keep it in mind
2021-08-28 20:35:57 <Thermi_> mps, no worries.
2021-08-28 20:37:36 <mps> if it is really justified for community we have some time before freeze
2021-08-28 20:38:14 <mps> imo, we need really good written rationale why we have to have it in community
2021-08-28 20:42:01 <Thermi_> Community is for community packages.
2021-08-28 20:42:45 <Thermi_> They're obv maintained by community contributors and community maintainers. The only difference between testing and community is that with community they're available without having to enable an additional repo.
2021-08-28 20:42:57 <Thermi_> (AFAIK)
2021-08-28 20:43:28 <Thermi_> Also, the packages are stable, so they're not in a beta or alpha status that implies any further testing is required
2021-08-28 20:44:15 <mps> what is *your* reason to move it
2021-08-28 20:44:28 <Thermi_> The opposite question from my understanding is: If a really good written rationale is required for moving things from testing to community, why is there anything in community at all?!
2021-08-28 20:44:38 <mps> and community is badly named I think
2021-08-28 20:44:59 <mps> Thermi_: good question :)
2021-08-28 20:45:14 <Thermi_> My reason is that the packages are stable and fullfill the quality criteria formulated for stuff available for installation from any repo available from a default installation
2021-08-28 20:45:32 <mps> my answer is 'because community is badly named'
2021-08-28 20:45:51 <Thermi_> What is a fitting name then that conveys the intended purpose?
2021-08-28 20:46:21 <mps> I don't know because we are not come to sane name, yet
2021-08-28 20:46:27 <Thermi_> What is it supposed to be?
2021-08-28 20:46:45 <mps> imo, community should be testing
2021-08-28 20:47:07 <mps> i.e. unsupported officially
2021-08-28 20:47:22 <Thermi_> No official support?
2021-08-28 20:47:29 <mps> yes
2021-08-28 20:47:31 <Thermi_> Support by community members only?
2021-08-28 20:47:34 <Thermi_> So .. community? :D
2021-08-28 20:48:07 <mps> heh, not so simple
2021-08-28 20:48:34 <Thermi_> What is the intention behind the support statement for community?
2021-08-28 20:48:40 <Thermi_> Support only by their maintainers?
2021-08-28 20:49:10 <Thermi_> What is the end result supposed to be?
2021-08-28 20:49:22 <mps> community 'counts' as stable for half year and need bug and security fixes, so I think it couldn't rely on 'community'
2021-08-28 20:50:57 <mps> from time to time some of official devs have to fix packages which they 'see' first time because 'community' forget them
2021-08-28 20:51:19 <Thermi_> What is the half year supposed to be? For the duration of one release?
2021-08-28 20:51:32 <Thermi_> So only major changes from one release to another, not within one release?
2021-08-28 20:51:43 <mps> yes
2021-08-28 20:51:48 <mps> but no :)
2021-08-28 20:51:55 <Thermi_> So it's complicated :P
2021-08-28 20:52:14 <mps> usually we have to fix pkgs in community far longer
2021-08-28 20:52:20 <Thermi_> Far longer than what?
2021-08-28 20:52:28 <mps> half year
2021-08-28 20:52:34 <Thermi_> And how is that important?
2021-08-28 20:52:46 <mps> it is
2021-08-28 20:52:54 <Thermi_> No, for what _reason_ is that important
2021-08-28 20:53:03 <Thermi_> not if it is important, but for what reason
2021-08-28 20:53:22 <mps> because users expect two year support even for community pkgs
2021-08-28 20:53:57 <Thermi_> So the support duration for main is two years (where does that specific time frame come from?), but for community it's half a year (where does that specific time duration come from?)?
2021-08-28 20:54:45 <Thermi_> (next topic: Why do devs have to fix packages in community for time to time? (And what devs? Devs that do not "own" these packages?))
2021-08-28 20:55:05 <mps> huh
2021-08-28 20:55:49 <mps> I think you know all answer to your questions
2021-08-28 20:56:06 <Thermi_> I do not know if we both are on the same page here
2021-08-28 20:56:16 <mps> :)
2021-08-28 20:56:35 <Thermi_> I want to make sure that we are on the same page. Otherwise I possibly come to a different conclusion with the same arguments.
2021-08-28 20:58:04 <mps> because most of official devs care for alpine 'image' and they took burden when casual contributors forget or don't care much for their pkgs
2021-08-28 20:58:30 <Thermi_> Don't the maintainers of those packages do that?
2021-08-28 20:58:43 <mps> most do, but some don't
2021-08-28 20:58:48 <Habbie> maintainers come and go
2021-08-28 20:59:01 <mps> Habbie: yes
2021-08-28 20:59:44 <Thermi_> Okay, so from what I could gather, the problem is that packages are merged into community where their maintainers stop maintaining them after some time, and because the main devs that do NOT own those packages care for the image of alpine, they then start maintaining them.
2021-08-28 21:00:09 <mps> Thermi_: like this
2021-08-28 21:00:31 <Thermi_> And that's a problem because these packages are not part of the "main offering" of Alpine so to say, and instead of bringing standard functionality that is agreed upon by the main team, they bring extra work that they do not want.
2021-08-28 21:01:11 <mps> yes
2021-08-28 21:01:36 <mps> I 'maintain' some number of such packages
2021-08-28 21:02:11 <mps> and even didn't added self as contributor, to not talk about maintainership
2021-08-28 21:02:41 <Thermi_> Okay. I got it now. As far as I can see, a reasonable mechanism for doing that is something like the orphaning mechanism of the AUR where the package can be orphaned if there is no fix/upgrade WITHOUT JUSTIFICATION within a certain (yet to be determined) time after it is available or a problem becomes public knowledge (like a CVE).
2021-08-28 21:03:08 <Thermi_> No reaction within 2 weeks->Orphan/move to testing
2021-08-28 21:03:24 <mps> I vote for this :)
2021-08-28 21:03:41 <mps> even simple 'git rm ...'
2021-08-28 21:04:01 <Thermi_> The gitlab bot could do that as reaction to user created issues with a certain structure at the beginning
2021-08-28 21:04:12 <Thermi_> It could automatically create MRs
2021-08-28 21:04:33 <mps> which is 'bad thing' imo
2021-08-28 21:04:47 <Thermi_> You want to do it manually?
2021-08-28 21:04:54 <mps> always
2021-08-28 21:04:59 <Thermi_> Create the MRs?
2021-08-28 21:05:06 <Thermi_> Create the MRs manually, every time?
2021-08-28 21:05:25 <Thermi_> Or merge them manually every time? Because that I can agree on.
2021-08-28 21:05:36 <mps> 'git rm ... && git push origin' is enough
2021-08-28 21:06:04 <Thermi_> How can we be sure that the maintainer is notified of such an issue?
2021-08-28 21:06:54 <mps> if the maintainer doesn't respond in time then it is not important what is the reason
2021-08-28 21:07:06 <Thermi_> A Map of maintainer names (without email address?) to the gitlab user name, so they can be used within an, for example, automatically created response to the issue?
2021-08-28 21:07:44 <Thermi_> So theoretically if I report an issue for a package without mentioning its maintainer, I can cause its deletion?
2021-08-28 21:08:27 <mps> hmm, look like dream for AI ;)
2021-08-28 21:08:52 <Thermi_> Looks like an abuse vector
2021-08-28 21:09:09 <mps> no, always last 'word' have devs
2021-08-28 21:09:45 <mps> merges are done 'manually'
2021-08-28 21:10:21 <mps> but I think ikke could explain workflow better than me
2021-08-28 21:10:42 <Thermi_> Couldn't we move it to unmaintained?
2021-08-28 21:10:49 <Thermi_> That way it's still readily available in the tree
2021-08-28 21:11:04 <mps> I just wanted to hear rationale for moving kopano to community
2021-08-28 21:11:15 <Thermi_> Well, then we went down the rabbit hole
2021-08-28 21:11:29 <mps> reason 'because we can' doesn't mean 'we should'
2021-08-28 21:12:00 <Thermi_> My justification is that it should be available in a release with its dependencies being stable too so it doesn't suddenly break because a dependency with a version can not be fullfilled (because it moved forward in edge)
2021-08-28 21:12:17 <Thermi_> (we can see that happen a lot with gcc upgrades)
2021-08-28 21:13:14 <mps> do you know (or estimate) number of potential users for kopano with alpine
2021-08-28 21:13:42 <Thermi_> Unknown right now because the total number of organizations interested or using Kopano is unknown
2021-08-28 21:13:53 <Thermi_> It will be at least 1
2021-08-28 21:13:59 <Thermi_> so number >= 1
2021-08-28 21:14:04 <mps> afaik most uses kopano in docker
2021-08-28 21:16:11 <Thermi_> It can be of interest to organizations that for one reason or another can not use docker or have increased security requirements that exclude systemd based distros
2021-08-28 21:16:19 <mps> Thermi_: thank you for your explanations and thinking, I don't have anything more to add about this move. lets see will other devs have something to say
2021-08-28 21:16:22 <Thermi_> but that require an Exchange compatible groupware
2021-08-28 21:17:08 <Thermi_> Like there are people using Devuan or other forks of mainstream distros that removed systemd for a reason or another
2021-08-28 21:17:29 <Thermi_> mps, ty, I learned some stuff as well.
2021-08-28 22:49:22 <adhawkins> Hi all. I maintain the emborg package, and a number of its python dependencies. I notice that the latest version appears to now have tests, so I want to try to get them integrated into the alpine build.
2021-08-28 22:50:32 <adhawkins> To do this though, I need to package up another python package to allow the tests to run. Emborg is in 'community', and I know that generally new packages initially go into testing. Is it Ok for a single MR to modify and package in community *and* add this new dependency to testing? Is it allowed for a package in community to have a check_depends
2021-08-28 22:50:32 <adhawkins> pointing at a package in testing?
2021-08-28 23:09:31 <Hello71> no
2021-08-28 23:10:02 <Hello71> if it is a simple package you can add it directly to community
2021-08-28 23:11:06 <adhawkins> Ok, thanks for that Hello71.
2021-08-28 23:11:17 <adhawkins> This is the package: https://github.com/KenKundert/nestedtext
2021-08-28 23:14:35 <Hello71> looks probably ok to add to community (as long as you can maintain it)
2021-08-28 23:15:36 <adhawkins> Ok. I would continue to maintain it, yes.
2021-08-28 23:15:50 <adhawkins> Having trouble getting the tests to run. Looks like the tests refer to an external repo.
2021-08-28 23:15:51 <adhawkins> https://github.com/KenKundert/nestedtext/tree/master/tests
2021-08-28 23:15:58 <adhawkins> (See official_tests).
2021-08-28 23:16:51 <adhawkins> This directory doesn't seem to be in the tarball that's downloaded from "https://github.com/KenKundert/nestedtext/archive/v$pkgver/nestedtext-v3.1.tar.gz
2021-08-28 23:16:58 <adhawkins> Any suggestions on how that should be handled?
2021-08-28 23:17:21 <adhawkins> Sorry, failed to fully edit the url
2021-08-28 23:17:38 <adhawkins> Should be "https://github.com/KenKundert/nestedtext/archive/v3.1/nestedtext-v3.1.tar.gz"
2021-08-28 23:18:21 <adhawkins> That directory (official_tests) exists in the tarball, but is empty
2021-08-28 23:26:07 <adhawkins> This is what I have so far: https://paste.debian.net/1209482/
2021-08-28 23:32:42 <Hello71> it's a submodule
2021-08-28 23:32:57 <adhawkins> Yes, I couldn't remember the correct git term :)
2021-08-28 23:33:08 <adhawkins> Any way to handle that in an alpine package
2021-08-28 23:33:10 <adhawkins> ?
2021-08-28 23:49:42 <Hello71> add a url
2021-08-28 23:54:03 <adhawkins> Can you give me a bit more info?
2021-08-28 23:54:24 <adhawkins> I was looking at adding a git clone to the 'check' function perhaps?
2021-08-28 23:54:30 <Thermi_> Add an additional source
2021-08-28 23:54:39 <Thermi_> then move the extracted dir to where you need it
2021-08-28 23:54:49 <Thermi_> if there are build time checks that require the .git repo patch them out
2021-08-28 23:55:03 <adhawkins> Ah ok, that would probably work. Good ide Thermi_.
2021-08-28 23:55:29 <Thermi_> Alternatively, package that other software as a -src package and add that to makedepends
2021-08-28 23:56:13 <Thermi_> (meaning as a -src package, that you have a package that contains the source code of the software and stores it somewhere in the hierarchy. Then you can copy from there at buildtime of that software you _actually_ wanted to build)
2021-08-28 23:56:26 <adhawkins> The other package doesn't seem to have 'releases' as such. The submodule seems to point to a specific commit.
2021-08-28 23:56:28 <Thermi_> Take a look at the APKBUILD for kopano-webapp. I did that there. It's in testing.
2021-08-28 23:56:52 <Thermi_> AFAIR github has the ability to make a specific archive of some commit
2021-08-28 23:56:53 <Thermi_> Do that
2021-08-28 23:57:02 <Thermi_> Add a comment why that is necessary
2021-08-28 23:57:05 <adhawkins> Yeah, was considering that.
2021-08-28 23:57:30 <adhawkins> So I would add a source pointing to a specific commit, and then in the 'check' method move the relevant directory into the src of the 'real' package?
2021-08-28 23:57:35 <Thermi_> No, in prepare
2021-08-28 23:57:42 <Thermi_> And not move, but copy
2021-08-28 23:57:59 <Thermi_> Because the directory where the src of the second package is stored is ususally not writable by the build user
2021-08-28 23:58:14 <adhawkins> Ok, got it.
2021-08-28 23:58:17 <Thermi_> Take a look at the APKBUILD for kopano-webapp in testing
2021-08-28 23:58:32 <Thermi_> Then look at the other kopano-webapp-* packages. They do it like that and it was accepted.
2021-08-28 23:58:40 <Thermi_> So that's your best shot at a solution right now
2021-08-28 23:59:30 <Thermi_> Assuming of course, that if the second software is built, it is usable for something
2021-08-28 23:59:35 <Thermi_> e.g. library
2021-08-29 00:06:13 <adhawkins> It's not, it's just the tests for the first.
2021-08-29 00:09:07 <Thermi_> Then use it as a source
2021-08-29 00:10:42 <adhawkins> Thermi_: OK, I now have this:
2021-08-29 00:10:42 <adhawkins> https://paste.debian.net/1209487/
2021-08-29 00:12:07 <Thermi_> adhawkins, parametrize the commithash as a variable please
2021-08-29 00:12:26 <adhawkins> And during the test, I get this: https://paste.debian.net/1209488/
2021-08-29 00:12:39 <adhawkins> Thermi_: I would do that for the final version, yes. Just trying to make it work initially!
2021-08-29 00:13:02 <Thermi_> adhawkins, makeshifts stay forever
2021-08-29 00:13:36 <Thermi_> I'd add newlines between the depends and builddir
2021-08-29 00:14:09 <Thermi_> I now see what you mean with copying in check
2021-08-29 00:16:01 <adhawkins> Thermi_: No, I won't commit anything until I get it working. Then I'll tidy it up.
2021-08-29 00:16:52 <adhawkins> Need to resolve the error though before I worry too much about making it look pretty :)
2021-08-29 00:17:10 <Thermi_> adhawkins, what error?
2021-08-29 00:17:28 <adhawkins> The one in the post above. (01:12:26 in my timezone)
2021-08-29 00:17:37 <adhawkins> https://paste.debian.net/1209488/
2021-08-29 00:18:36 <Thermi_> adhawkins, get situated with pytest and debug it, I can't help you with that, sorry. I presume it has to do with that you set PYTHONPATH because the exception ends in ImportpathMismatchError
2021-08-29 00:18:57 <adhawkins> Ok. I'll look into that. Thanks Thermi_.
2021-08-29 00:19:08 <adhawkins> Sadly pytest isn't one of my strong points!
2021-08-29 00:20:15 <adhawkins> I've done the same thing in other modules and it worked. Seem to remember it was suggested here.
2021-08-29 00:20:57 <adhawkins> s/modules/packages
2021-08-29 00:22:25 <Thermi_> I'm off for now.
2021-08-29 00:22:26 <Thermi_> Cya
2021-08-29 00:29:35 <adhawkins> Thanks for the help Thermi_. Seems setting PY_IGNORE_IMPORTMISMATCH=1 seems to fix this.
2021-08-29 00:53:29 <Hello71> why are you overriding PYTHONPATH
2021-08-29 00:53:47 <Hello71> hm, wait
2021-08-29 00:55:44 <adhawkins> Hello71: When I first started packaging python packages, someone helped me out with specifying that.
2021-08-29 01:03:25 <adhawkins> Ok, got it to this, which builds Ok: https://paste.debian.net/1209490/
2021-08-29 01:03:44 <adhawkins> What's the 'rule' for the variable name specifying the hash? Thought I'd seen it somewhere but can't seem to find it.
2021-08-29 08:26:35 <mps> would someone with meson/ninja experience review !24751 this is first time I changed from autotools to meson build
2021-08-29 08:35:44 <Cogitri> mps: You could take a look at the GNOME APKBUILDs (like mutter) to have a reference
2021-08-29 08:40:17 <mps> Cogitri: thanks. looks like 'meson build' can be used instead of 'ninja build'
2021-08-29 09:40:49 <adhawkins> How would you name this package? https://github.com/kalekundert/parametrize_from_file
2021-08-29 09:40:56 <adhawkins> py3-parametrize-from-file ?
2021-08-29 09:45:11 <adhawkins> Hmmm, plus it doesn't have a setup.py. Install instructions say to use pip. How would I go about packaging it?
2021-08-29 10:29:00 <mps> Cogitri: thank you again for mentioning mutter. that is what I got https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24751/diffs
2021-08-29 10:39:16 <Cogitri> mps: I don’t think you need line 18
2021-08-29 10:39:34 <Cogitri> Or rather the entirety of prepare()
2021-08-29 10:39:37 <Cogitri> Other than that lgtm
2021-08-29 10:40:56 <mps> Cogitri: thanks for notice, will check also this
2021-08-29 10:58:35 <mps> nmeum: if we add u-boot-qemu to makedepends for opensbi will it produce circular makedeps? u-boot makedeps to opensbi, if you remember
2021-08-29 10:59:30 <nmeum> mps: yes, why is u-boot-qemu needed in the opensbi makedepends?
2021-08-29 11:00:51 <mps> to build fw_payload.elf
2021-08-29 11:01:10 <mps> nmeum: https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md
2021-08-29 11:02:14 <nmeum> is it not possible to use fw_jump or fw_dynamic with qemu?
2021-08-29 11:03:13 <mps> I tried but didn't succeed. only what I managed to make working is fw_payload.elf
2021-08-29 11:03:43 <nmeum> IIRC I used qemu with fw_jump in the past
2021-08-29 11:04:18 <mps> did it worked?
2021-08-29 11:04:36 <nmeum> yes
2021-08-29 11:04:43 <mps> hmm
2021-08-29 11:04:45 <nmeum> the qemu wiki also still recommends using fw_jump it seems
2021-08-29 11:04:47 <nmeum> https://wiki.qemu.org/Documentation/Platforms/RISCV#Booting_64-bit_Buildroot_Images
2021-08-29 11:05:25 <nmeum> fw_jump should also be trivial for qemu it just needs to load the payload (e.g. linux kernel or u-boot) at a specific address and fw_jump will then just jump to it
2021-08-29 11:05:43 <mps> ah, I see. but this is not what I want to do
2021-08-29 11:06:54 <nmeum> fw_payload is the same thing basically but the payload (e.g. linux kernel or u-boot) is embedded directly instead of loaded at a seperate address
2021-08-29 11:07:02 <nmeum> which ofc requires rebuilding every time the payload changes
2021-08-29 11:07:24 <mps> I want '-bios fw_payload.elf' only as parameter and have all rest in VM image (kernel, initramfs, extlinux.conf)
2021-08-29 11:08:35 <mps> actually I made this all yesterday and it works fine, but now thinking how to integrate these changes to aports
2021-08-29 11:10:24 <mps> going to make black tea, maybe after that some ideas appears
2021-08-29 11:10:30 <nmeum> I think qemu actually even embeds opensbi these days https://github.com/qemu/qemu/commit/91f3a2f0ce59cb621630bd224f634955222fc3e0
2021-08-29 11:11:05 <mps> yes, for riscv it is embeded from 5.1 version
2021-08-29 11:12:04 <nmeum> makes it even easier to use the fw_jump payload then :p
2021-08-29 11:12:10 <nmeum> s/payload/firmware/
2021-08-29 11:13:56 <mps> yes, in theory but not in practice because it doesn't work ;)
2021-08-29 11:15:00 <nmeum> it should though
2021-08-29 11:15:09 <nmeum> so if it doesn't I would consider that a bug in qemu
2021-08-29 11:15:45 <mps> bug is somewhere for sure, but I don't like to hunt it, just want working VM
2021-08-29 11:25:23 <mps> hmm, looking now, your change to u-boot is to add opensbi to u-boot image
2021-08-29 11:26:14 <nmeum> correct
2021-08-29 11:27:10 <nmeum> this is needed for u-boot itb on the unmatched/unleasehd and this will also be needed for other riscv boards
2021-08-29 11:28:53 <mps> hmhm, maybe same can be done for u-boot-qemu smode
2021-08-29 12:10:06 <ArsenArsen> how does alpine derive the hwdb for eudev?
2021-08-29 12:23:40 <adhawkins> Anyone help with how to package up a Python package that has no setup.py?
2021-08-29 12:23:53 <adhawkins> It's this one: https://github.com/kalekundert/parametrize_from_file
2021-08-29 12:30:17 <maxice8> it uses the new pyproject.toml
2021-08-29 12:39:37 <adhawkins> Ah ok. How would I go about packaging using that?
2021-08-29 12:41:15 <veiviser> you can try pyproject2setuppy
2021-08-29 12:41:50 <adhawkins> Yeah, just found a reference to that. Looking.
2021-08-29 12:42:13 <nmeum> adhawkins: https://setuptools.readthedocs.io/en/latest/setuptools.html#setup-cfg-only-projects
2021-08-29 12:42:27 <nmeum> you can also just create a setup.py which only contains a setuptools.setup() invocation
2021-08-29 12:43:07 <nmeum> or, alternatively, use the pypi.org tarball in $source
2021-08-29 12:43:12 <nmeum> that should contain a setup.py file iirc
2021-08-29 12:43:20 <maxice8> There are examples in aports, grep
2021-08-29 12:43:52 <nmeum> https://pypi.org/project/parametrize-from-file/#files
2021-08-29 12:44:27 <adhawkins> Thanks nmeum, looking into those.
2021-08-29 12:52:45 <maxice8> If the pypi have the testsuite (sometimes they don't) then using them is the best option
2021-08-29 13:01:41 <adhawkins> maxice8: Is the URL for download logically derived on pypi? It seems to have some hash values or something in it?
2021-08-29 13:10:19 <maxice8> use this example fo rpy3-virtualenv: https://files.pythonhosted.org/packages/source/v/virtualenv/virtualenv-$pkgver.tar.gz
2021-08-29 13:25:45 <adhawkins> I can't get to that site for some reason maxice8
2021-08-29 13:26:04 <adhawkins> Ah, apologies, just realised it was an example not an absolute page.
2021-08-29 13:30:31 <nmeum> mps: unless you object I would merge the busybox 1.34 update today. nobody complained in a week and I haven't noticed any problems with it
2021-08-29 13:31:18 <ikke> If it gives problems, we can always revert
2021-08-29 13:32:56 <nmeum> sure, though I always like to be extra careful with critical basesystem stuff like busybox and such
2021-08-29 13:33:16 <ikke> yup
2021-08-29 13:36:21 <mps> nmeum: I wonder why I would object, it works fine for me
2021-08-29 13:38:01 <ikke> mps: because you have been testing it
2021-08-29 13:38:09 <ikke> you could've run into issues
2021-08-29 13:38:40 <mps> ikke: still didn't had any problem with it
2021-08-29 13:38:56 <mps> and I think donoban also testing it
2021-08-29 13:39:29 <ikke> so you do not object :-)
2021-08-29 13:39:35 <mps> ikke: above was 'a word play'
2021-08-29 13:39:49 <mps> yes, I don't object, ofc
2021-08-29 13:40:12 <mps> looks like I'm bad in 'word play' in english
2021-08-29 13:40:38 <nmeum> (:
2021-08-29 13:42:50 <nmeum> done dfdb1229c6014c884e13cb10f4b6bda49e69818a
2021-08-29 13:53:09 <adhawkins> Anyone familiar with pytest able to look at the tests for emborg? Some of them fail in the dockerised build system as they try to use 'emborg mount' which requires fuse support, which isn't available in the container. Trying to work out if it's possible to disable these tests.
2021-08-29 13:54:06 <ikke> https://docs.pytest.org/en/6.2.x/skipping.html
2021-08-29 13:55:52 <maxice8> see --deselect
2021-08-29 13:57:37 <adhawkins> Yes, but the way the tests are run in this case is a little unusual, using py3-parametrize-from-file
2021-08-29 13:59:14 <adhawkins> In pytest terms I think there's a single 'run all the tests in this file' and the tests are listed in another file (test-cases.nt)
2021-08-29 14:23:28 <maxice8> apkbuild-cpan is acting weird
2021-08-29 14:23:54 <maxice8> anyone else can confirm that running `apkbuild-cpan upgrade` is causing the creation of makedepends="perl-dev" and checkdepends=""
2021-08-29 14:24:37 <maxice8> and they don't have ending newlines ?
2021-08-29 14:25:19 <adhawkins> Ok, I've committed and pushed all the work so far to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24746
2021-08-29 14:25:31 <maxice8> http://ix.io/3xkk it produces a diff like this with `apkbuild-cpan upgrade`
2021-08-29 14:25:51 <adhawkins> Would appreciate if anyone can advice on the test errors that are being generated. I suspect they're due to the tests being run in docker (I'm using dabuild)
2021-08-29 14:28:18 <ikke> timlegge is not here atm
2021-08-29 14:34:53 <adhawkins> Was that for me ikke?
2021-08-29 14:35:51 <ikke> no, for maxice8 
2021-08-29 14:36:34 <adhawkins> Ok, apologies ikke
2021-08-29 14:36:38 <ikke> np
2021-08-29 14:38:21 <adhawkins> Ok, looks like the build pipelines on gitlab are failing in the same way as I'm seeing here, so hopefully someone else can find time to take a look at it and help out.
2021-08-29 14:38:26 <adhawkins> Thanks to all who have helped me get this far!
2021-08-29 14:38:37 <adhawkins> !24746
2021-08-29 15:20:00 <maxice8> oh wow
2021-08-29 15:20:04 <maxice8> we weren't applying any readline patches 
2021-08-29 15:20:44 <maxice8> because they were .diff and we don't process those
2021-08-29 15:20:49 <maxice8> !24579 should be fixed now
2021-08-29 15:21:02 <maxice8> oops, !24759
2021-08-29 19:17:20 <nmeum> Ariadne: I actually got around to testing my fix for libatomic on riscv64 and it does seem to work https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24570#note_177286 I can't guarantee that it doesn't introduce any new sideeffects though but I don't think it should. Maybe we merge this for now until we find a better solution for dealing with #12948?
2021-08-29 20:57:41 <maxice8> udev-init-scripts uses `-containers` keyword to noop services that are not meant to run in containers, should we update ours to conform too ? 
2021-08-30 00:50:28 <linearcannon> has anyone tested the bootstrap script in aports lately? i'm having issues with it and i'm trying to figure out if its an issue with my machine or me doing something wrong, or if it has bitrotted in the last 3 years
2021-08-30 00:51:29 <Hello71> it is tested during release
2021-08-30 01:42:58 <Thermi_> linearcannon, there are issues with it, yes. Particularly with gcc and gnat
2021-08-30 01:43:13 <Thermi_> It's not really a problem with bootstrap though, but with the specific packages that are built
2021-08-30 01:43:48 <Thermi_> I have/had some stuff in MRs to fix the situation, but don't know from the top of my head if all of it was merged into master
2021-08-30 01:44:55 <linearcannon> i'm having issues getting it to even start building the first host package, but it's looking like at least some of that might be my system
2021-08-30 01:45:52 <Thermi_> linearcannon, if you pastebinned the output somebody could help you
2021-08-30 01:59:43 <linearcannon> made a clean chroot on another box and it's working as expected, so it's just something with that particular machine i guess. more interested in continuing what i was working on than trying to debug the first machine atm
2021-08-30 02:08:55 <Thermi_> chroot?
2021-08-30 02:09:00 <Thermi_> you mean sysroot-$arch?
2021-08-30 02:09:27 <Thermi_> If yours is broken, just delete it. The script creates it from scratch just fine and abuild installs all dependencies specified.
2021-08-30 02:24:28 <linearcannon> nah, i mean i made an alpine chroot, installed alpine-sdk, cloned aports, and attempted there
2021-08-30 02:24:37 <linearcannon> on another machine
2021-08-30 02:25:40 <linearcannon> on the first machine, the script does not successfully create a sysroot from scratch - that is the part that is failing. there are directories missing. if i manually create them and initialize the apk db myself then it moves forward.
2021-08-30 02:31:04 <Ariadne> just use musl cross make ffs
2021-08-30 05:23:49 <segfault0> Has anyone here tried cross compiling rust lately? I've had some trouble, even when I used a 32 bit host architecture because of issues with different pointer sizes going from 64 to 32 bit hosts
2021-08-30 06:55:10 <ncopa> good morning
2021-08-30 07:01:40 <mps> good morning
2021-08-30 07:17:45 <xsteadfastx> good morning :)
2021-08-30 07:23:36 <sircmpwn> is there a way for my package to overwrite a config file from another package?
2021-08-30 07:23:46 <sircmpwn> i.e. can my sr.ht-nginx package provide an /etc/nginx/nginx.conf
2021-08-30 07:25:11 <ncopa> replaces=...
2021-08-30 07:25:52 <sircmpwn> aha, thanks
2021-08-30 07:38:51 <craftyguy> sircmpwn: if that package is just configuring a host, you could just install a .conf into /etc/nginx/http.d (which the default nginx.conf 'includes')
2021-08-30 07:39:58 <sircmpwn> aye, I'm aware, but it is not just configuring a host
2021-08-30 07:40:01 <sircmpwn> thanks for the tip
2021-08-30 07:40:25 <craftyguy> ah ok, np
2021-08-30 08:16:40 <mps> nmeum: do you know could your rv64 box can boot with 'image' (uncompressed) kernel or must use vmlinuz (compressed)
2021-08-30 08:18:06 <nmeum> mps: the unmatched? both works, it's a matter of u-boot configuration. I am presently using the vmlinuz image from the linux-edge package with an extlinux.conf u-boot configuration file
2021-08-30 08:21:28 <mps> nmeum: aha, ok. I'm building rv64 flavors with uncompressed ones because qemu can't boot with compressed with u-boot, i.e.  fw_payload.elf
2021-08-30 08:22:46 <mps> but if your boxes can't boot uncompressed I can make uncompressed only for linux-edge-virt riscv64 flavor
2021-08-30 08:23:19 <nmeum> can't you just use the risc-v bootflow and boot u-boot spl and u-boot itb and then load vmlinuz from there as I do?
2021-08-30 08:23:23 <nmeum> https://github.com/qemu/qemu/blob/526f1f3a5c6726e3d3b893d8063d31fda091c7e0/docs/system/riscv/virt.rst#running-u-boot
2021-08-30 08:24:07 <nmeum> I don't think there is a need for packaging a different image format
2021-08-30 08:24:24 <mps> I think this is not 'elegant' solution
2021-08-30 08:24:28 <nmeum> you can also convert stuff with the mkimage tool from u-boot-tools
2021-08-30 08:24:59 <mps> you know, I like 'simple, small ....' :)
2021-08-30 08:25:12 <nmeum> so do I
2021-08-30 08:25:20 <nmeum> that's why I don't like packaging different formats of the kernel image :p
2021-08-30 08:25:53 <mps> well, we already do this in linux-lts and linux-edge
2021-08-30 08:26:22 <nmeum> oh, really?
2021-08-30 08:26:34 <mps> some arm64 boxes also can't boot with compressed kernel
2021-08-30 08:26:57 <mps> and even some armv7 iirc
2021-08-30 08:27:02 <nmeum> is it packaged in a subpackage?
2021-08-30 08:27:09 <mps> no
2021-08-30 08:27:46 <mps> we just build for most boxes, i.e. how they can boot
2021-08-30 08:28:10 <nmeum> my, linux-lts package only includes a vmlinuz-lts image in /boot
2021-08-30 08:28:27 <mps> which arch
2021-08-30 08:28:37 <nmeum> ah, is it only packaged for certain architectures?
2021-08-30 08:29:06 <nmeum> which arch has it?
2021-08-30 08:29:49 <mps> I already 'contemplated' to make all linux-edge compressed and add uncompressed for arches and flavors which need it
2021-08-30 09:06:33 <tiotags> hello, I should probably ask here not in support, does the gcc in alpine use a different default -std ?
2021-08-30 09:24:29 <Newbyte> Is libadwaita packaged in Alpine?
2021-08-30 09:26:42 <ikke> Newbyte: https://pkgs.alpinelinux.org/contents?file=libadwaita*&path=&name=&branch=edge&arch=x86_64
2021-08-30 09:27:17 <Newbyte> ikke: that's something else. libadwaita is a library that extends GTK 4 with more widgets 
2021-08-30 09:27:43 <PureTryOut> Newbyte https://pkgs.alpinelinux.org/packages?name=libadwaita&branch=edge
2021-08-30 09:27:46 <PureTryOut> so seemingly not
2021-08-30 09:27:54 <PureTryOut> (you can use that search function yourself too you know 😉)
2021-08-30 09:28:08 <markand> remember to put wildcards ;)
2021-08-30 09:28:08 <Newbyte> Yes, I couldn't find it, but maybe there was a reason it's not packaged or something like that
2021-08-30 09:28:17 <markand> probably no one needed yet
2021-08-30 09:28:34 <PureTryOut> wildcards are not needed when there is no reason to call it anything other than "libadwaita" 😛
2021-08-30 09:28:42 <Newbyte> It will be very necessary when GNOME 41 comes out 
2021-08-30 09:29:02 <Newbyte> thus I was surprised to not see it packaged
2021-08-30 09:29:09 <Newbyte> but, I see
2021-08-30 09:29:12 <PureTryOut> It'll get packaged once that comes to Alpine
2021-08-30 09:29:20 <PureTryOut> No need to package something when it has no users yet
2021-08-30 09:31:13 <Cogitri> Newbyte: It’s currently still in alpha
2021-08-30 09:31:39 <Newbyte> Cogitri: I see, thanks. a package I maintain (Giara) needs it to be upgraded to 1.0, but I'll just wait then
2021-08-30 09:31:46 <Cogitri> But I guess we should package alpha3/beta1 once that’s released
2021-08-30 09:33:47 <markand> it's so much alpha that the website doc's link is already broken : https://gnome.pages.gitlab.gnome.org/libadwaita/doc/
2021-08-30 09:48:04 <Newbyte> <markand> "it's so much alpha that the..." <- "upcoming version" docs work
2021-08-30 09:53:13 <ncopa> nmeum: just want to say thanks for an excellent git commit  message for dfdb1229c6014c884e13cb10f4b6bda49e69818a
2021-08-30 09:56:06 <nmeum> glad you found it useful :)
2021-08-30 10:00:43 <ncopa> i saw that busybox got updated when i did apk upgrade and wondered what changed. the commit message told me everything I was interested to know
2021-08-30 10:00:48 <mps> except last sentence is not true :)
2021-08-30 10:01:19 <ncopa> mps: what is not true about it?
2021-08-30 10:01:22 <mps> ascii and crc32 applets are not enabled
2021-08-30 10:01:59 <ncopa> ".... but not enabled in our busybox configuration: ascii, crc32"
2021-08-30 10:02:59 <mps> ah, it is fixed in meantime, ok
2021-08-30 10:10:47 <mps> new in kernel 5.14 is SCHED_CORE option. 'SCHED_CORE is default disabled. When it is enabled and unused, which is the likely usage by Linux distributions, there should be no measurable impact on performance.'
2021-08-30 10:11:18 <mps> I really don't understand what this meant to say
2021-08-30 10:19:18 <ncopa> as I understand it, the enabling CONFIG_SCHED_CORE in kernel config does not introduce any measurable impact on performance, unless you enable the feature from userspace (via  prctl(PR_SCHED_CORE) )
2021-08-30 10:19:34 <mercenary> Sounds like 'enabling it compiles in the code, but unless one tweaks a sysctl knob it will do nothing'
2021-08-30 10:20:24 <ncopa> yup
2021-08-30 10:21:55 <ncopa> except it is not a sysctl knob but a prctl(2) knob. https://man7.org/linux/man-pages/man2/prctl.2.html
2021-08-30 10:40:55 <adhawkins> I don't suppose there's any chance of having FUSE support enabled in the CI containers? I think you need to pass in the host's fuse device for this to work.
2021-08-30 10:41:19 <adhawkins> Trying to update the package to the new version of emborg and allow its tests to run. Some of these involve using borg mount, which requires FUSE support
2021-08-30 12:54:08 <adhawkins> Ok, on the assumption there's no way to get FUSE support in the Alpine CI containers, I've patched out the tests that require it. 
2021-08-30 12:54:25 <adhawkins> Any chance someone could look at !24746 particularly the patch? All look Ok?
2021-08-30 13:03:23 <bl4ckb0ne> could somebody review !24589 pls
2021-08-30 13:57:38 <mps> I was afk, not sure should we CONFIG_SCHED_CORE set to yes for distro, default is no
2021-08-30 15:40:54 <afontain[m]> scientology service?
2021-08-30 15:40:55 <afontain[m]> (kidding)
2021-08-30 15:41:33 <afontain[m]> IIRC there is `apk info --who-owns`
2021-08-30 15:46:36 <afontain[m]> https://pkgs.alpinelinux.org/contents?file=*-xenu*&name=&branch=edge doesn't seem to give results
2021-08-30 15:46:48 <afontain[m]> sry, https://pkgs.alpinelinux.org/contents?file=&path=*-xenu*&name=&branch=edge
2021-08-30 15:59:04 <mps> it is really annoying to have 'quiet' in kernel boot options on -virt images
2021-08-30 16:01:26 <artok> quiet should be setup-alpine question
2021-08-30 16:03:05 <mps> I agree, and quiet should be removed from release imgs
2021-08-30 16:03:22 <artok> default off and optionally added
2021-08-30 16:03:33 <mps> again agree
2021-08-30 16:03:57 <mps> artok: nice to see you again after some time
2021-08-30 16:04:17 <artok> just installed alpine 4 times and doing those edits to kernel commandline =)
2021-08-30 16:04:28 <mps> heh, doing same
2021-08-30 16:04:40 <artok> well tomorrow I'll be again less here, as I go to work =)
2021-08-30 16:04:50 <artok> next 14 days working
2021-08-30 16:05:08 <mps> huh, 'bad work' :)
2021-08-30 16:05:27 <artok> not that good internet connection on boat, only when we're at harbour =)
2021-08-30 16:07:47 <mps> ah yes, music on boats
2021-08-30 16:07:52 <artok> yeah
2021-08-30 16:08:17 <artok> back after 1,5years of covid shit
2021-08-30 16:09:04 <mps> wait, you can't do 'remote work' ;)
2021-08-30 16:10:17 <artok> hehe =)
2021-08-30 16:10:28 <mps> jk, I know
2021-08-30 16:11:19 <artok> I prefer to have girls dancing some meters from me rather than watching them from screen =)
2021-08-30 16:11:19 <maxice8> !24793
2021-08-30 16:11:51 <mps> artok: fully understand you
2021-08-30 16:12:37 <veiviser> interesting
2021-08-30 18:09:22 <ecraven> when building a package locally, at the very end I run into: Updating the user/aarch64 repository index...\nERROR: APKINDEX.tar.gz: UNTRUSTED signature
2021-08-30 18:12:12 <dalias> wasn't julia dlopen mess discussed here before and resolved in alpine?
2021-08-30 18:12:29 <dalias> their upstream is upset over it (again?)
2021-08-30 18:14:59 <dalias> re: quiet I don't get why anyone would ever want it
2021-08-30 18:15:16 <dalias> all it does is make things harder to debug when they break
2021-08-30 18:15:39 <artok> on kiosk systems, having it is totally ok
2021-08-30 18:16:48 <veiviser> of course, but then kiosk systems can add it no?
2021-08-30 18:27:24 <artok> yeah
2021-08-30 21:15:23 <tjones> Hi Folks, first time alpiner.  I'm in need of gcompat as described on the WIKI, but apk reports that no such package exists.
2021-08-30 21:18:19 <omni> again my kernel is out of sync with the modules, I'm glad I use zfs and take snapshots
2021-08-30 21:20:45 <c7s> tjones: you need to enable the community repo in /etc/apk/repositories
2021-08-30 21:21:14 <omni> I probably have a unique setup, but keeping the modules of the currently running kernel would've helped
2021-08-30 21:21:52 <omni> I mention it because I remember talk of retaining modules for previous kernels
2021-08-30 21:23:09 <omni> and it's probably not an easy problem to decide what to keep and not, I've often had orphaned modules on debian systems
2021-08-30 21:32:21 <tjones> @c7s - that's my D'Oh moment for the afternoon :)
2021-08-30 21:48:25 <Hello71> also irc is not twitter. use name: not @name
2021-08-30 22:29:12 <omni> those are the roules of hashtag alpine-devel
2021-08-31 00:53:26 <tjones> Working on a port that needs libresolv functions.  Is there a libresolv.so for the current Alpine.  If not, is there documentation discussing this and is there an alternative?  
2021-08-31 01:01:28 <veiviser> there is a libresolv.a in musl-dev to link against statically, and it's the musl resolv instead of glibc, i guess
2021-08-31 01:02:45 <ericonr> veiviser: libresolv.a is empty :p
2021-08-31 01:02:50 <veiviser> ha
2021-08-31 01:02:54 <ericonr> It's just to satisfy -lresolv
2021-08-31 01:03:11 <veiviser> i did not in fact check :p
2021-08-31 01:03:18 <ericonr> tjones: which functions specifically?
2021-08-31 01:04:43 <ericonr> veiviser: the only relevant files for musl are libc.so and libc.a, the rest are to satisfy -l arguments like -lrt or -lm or -lpthread
2021-08-31 01:04:58 <veiviser> that is good to know
2021-08-31 01:25:03 <tjones> ericonr: dn_expand()
2021-08-31 07:07:34 <mps> good morning
2021-08-31 07:08:35 <mps> I think we should add f2fs to base file systems in release images
2021-08-31 07:09:12 <mps> so, can be selected with setup-disk
2021-08-31 07:45:27 <mps> would someone with protobuf knowledge look at #12936 quite annoying
2021-08-31 08:55:51 <ignaloidas> Hi, asked a while ago on #alpine-linux but didn't get an answer, maybe this is a better place for this question. I'm trying to build some packages, and it seems like tar is replacing ends of files with NULs in abuilds compression step, happens for all the files reported with the message "File shrank by x bytes; padding with zeros", with such files getting x number of bytes overwritten with NULs
2021-08-31 08:56:17 <ignaloidas> Is my environment in some way corrupt or am I doing something wrong?
2021-08-31 08:57:12 <ncopa> huh. that sounds weird
2021-08-31 08:57:18 <ncopa> what filesystem is it?
2021-08-31 08:57:37 <ncopa> maybe it is some weirdness of btrfs or similar
2021-08-31 08:57:54 <ignaloidas> I'm doing it on a shared folder in a VM, so it's over 9p, that might be the issue
2021-08-31 08:58:12 <ignaloidas> though I wouldn't really expect that
2021-08-31 08:58:15 <ncopa> possibly
2021-08-31 08:58:30 <ncopa> never seen that error
2021-08-31 09:02:01 <ignaloidas> seems like that has been it, that's slightly annoying, but thanks!
2021-08-31 10:57:35 <minimal> mps: re f2fs, I used it as rootfs in the past and there were issues relating to fsck during boot (basically fsck check occurs after rootfs is mounted by initramfs and f2fs fsck doesn't like mounted filesystems)
2021-08-31 11:18:02 <mps> minimal: I use f2fs as rootfs for more than 3 years, didn't had any problem
2021-08-31 11:18:34 <mps> even didn't noticed that fsck is run :)
2021-08-31 11:18:36 <minimal> mps: do you see a fsck-related message during every boot?
2021-08-31 11:18:50 <mps> minimal: ^
2021-08-31 11:19:23 <mps> next time I reboot machine with initramfs I will look
2021-08-31 11:19:42 <minimal> mps: strange, I was seeing it every boot - it still booted fine but the issue was that fsck.f2fs didn't actually do anything as the rootfs was mounted, so if anything ever needed to be fixed it never would be
2021-08-31 11:20:02 <minimal> I have to add a "-f" force option to the fsck call to get it to do anything
2021-08-31 11:20:50 <mps> I didn't do anything special when installed boxes with f2fs rootfs
2021-08-31 11:21:26 <minimal> mps: from a check of the IRC log archives I see you and I chatted about this in January
2021-08-31 11:21:42 <minimal> from the logs:
2021-08-31 11:21:43 <minimal> 2021-01-08 14:38:50 <minimal> mps: I tried using f2fs for SDs and SSDs a while ago but it doesn't "like" that the rootfs is initially mounted read-only, I had to modify /etc/conf.d/fsck to add "-f -a" to the fsck_args as otherwise it didn't work right
2021-08-31 11:22:04 <minimal> 2021-01-08 14:42:32 <minimal> however this forces a fsck every boot :-( Its been raised by others in the past on the f2fs email list.
2021-08-31 11:22:33 <mps> ah yes, I forgot
2021-08-31 11:23:41 <mps> I run armv7 and x86_64 machines with f2fs rootfs and don't have any such problem
2021-08-31 11:26:31 <minimal> mps: perhaps something has changed relating to fsck config/initscript - I have tested f2fs for 6+ months, let me build a VM now to see if the same issue appears
2021-08-31 11:27:00 <mps> ok
2021-08-31 11:28:11 <mps> tested linux-edge 5.14 on x86_64, armv7 on 'metal' and rv64 in qemu. all works fine \o/
2021-08-31 11:29:19 <mps> 5.14-rc7 aarch64 runs about week on chromebooks
2021-08-31 11:58:42 <ikke> nice, numa support for qemu. We can use that for our ARM CI as well
2021-08-31 12:34:13 <minimal> mps: tested f2fs rootfs, still seeing fsck message scrolling past during boot, basically it seem that fsck.f2fs will check a rootfs (as its mounted RO) but will *NOT* fix any problems that may exist as it can only do so with an unmounted fs - so there's a risk with using f2fs for rootfs that if it ever gets corrupted (i.e. power failure) that it will not be fixed when fsck runs
2021-08-31 12:35:06 <minimal> message is something like "Info: Check FS only due to RO"
2021-08-31 12:51:52 <ncopa> i think we have an issue about that somwhere
2021-08-31 12:51:59 <ncopa> that we should run fsck from initramfs
2021-08-31 12:52:32 <ncopa> iirc its more or less only ext4 that supports fixing filesystems when mounted as RO
2021-08-31 12:53:27 <Hello71> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/15
2021-08-31 12:55:09 <minimal> ncopa: yes, it was raised the last time this was discussed: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/15
2021-08-31 12:55:54 <minimal> there is a workaround for f2fs - if "-f" or "-y" is added to the fsck call then apparently it will fix any issues when mounted RO
2021-08-31 12:57:03 <mps> minimal: I'm waiting for kernel 5.14 to finish on builders and then will upgrade and look carefully if I see something
2021-08-31 12:59:39 <minimal> mps: it happens just after initramfs mounts rootfs so it will probably scroll off the console very quickly
2021-08-31 13:02:21 <tjones> Revisit from last night - I'm working on a port that needs libresolv functions.  Is there a libresolv.so for the current Alpine.  If not, is there documentation discussing this and is there an alternative?  The function that's missing from the builtin functions is dn_rename()
2021-08-31 13:02:23 <PureTryOut> Is it possible to make default_unpack ignore some source files to unpack?
2021-08-31 13:04:44 <mps> I can reboot my armv7 testing box, I have screen as console so can easily scroll back
2021-08-31 13:08:40 <mps> minimal: here is console out https://tpaste.us/gBXx
2021-08-31 13:11:41 <ericonr> tjones: what port is it? this function doesn't seem to exist even for libc
2021-08-31 13:21:42 <minimal> mps: strange, just after the line "Checking local filesystems" is where I'd expect to see the warning. Have you fsck_args set in /etc/conf.d/fsck?
2021-08-31 13:23:20 <mps> minimal: no, I don't have it
2021-08-31 13:23:52 <mps> acrtually #fsck_args="-p", commented 
2021-08-31 13:24:01 <Hello71> if fsck.f2fs not installed i think it will be silently ignored
2021-08-31 13:24:51 <minimal> ok, so then mps: do you have f2fs-tools installed?
2021-08-31 13:28:15 <mps> minimal: yes, but I think not in initramfs
2021-08-31 13:29:38 <minimal> mps: the fsck is run by openrc, not by in the initramfs
2021-08-31 13:31:36 <minimal> I captured the output I'm seeing and right after "* Checking local filesystems" I'm seeing 5 lines including a yellow "* Operational error" before the "* Remounting root filesystem read/write" message
2021-08-31 13:33:40 <mps> really don't have idea why this happens on your machines
2021-08-31 13:34:41 <minimal> it happens as fsck.f2fs doesn't like running on a RO-mounted FS, I'm more confused as to why it doesn't happen on your machine
2021-08-31 13:36:42 <Thermi_> ncopa, I just mentioned you in a couple of MRs for abuild, and an MR for samba. The samba one is kind of important because it contains a patch for broken vfs_btrfs support that upstream Samba team is dragging their heels on in regards to merging it.
2021-08-31 13:37:18 <Thermi_> It'd be great if we could "quickly" merge that so it's in the next couple of releases. I saw that I missed the next release by a couple of hours, but alas, not all can be perfect.
2021-08-31 13:38:00 <minimal> mps: there is for example a Gentoo bug for the same issue: https://bugs.gentoo.org/show_bug.cgi?id=666657
2021-08-31 13:40:31 <mps> we really need to move arm machines to europe ;)
2021-08-31 13:42:45 <mps> minimal: hmm, I see. and yes, I know fsck.f2fs can't check mounted FSs, I use it long time
2021-08-31 13:42:50 <minimal> Europe? what do you mean? The company Arm?
2021-08-31 13:43:08 <mps> alpine arm machines, I mean
2021-08-31 13:43:17 <mps> RTT is too high
2021-08-31 13:43:36 <ikke> They're hosted in the west of US
2021-08-31 13:44:02 <mps> ah, I thought they are on mars or venus :)
2021-08-31 13:45:22 <minimal> mps: so going back full circle to your earlier talk of adding F2FS support to setup-alpine/setup-disk I was pointing out that this would mean that F2FS rootfs' would not have any FS corruption fixed due to this issue and so it would be "risky" to add this to setup-alpine until some soft of solution was in place
2021-08-31 13:46:10 <minimal> s/soft/sort/
2021-08-31 13:48:04 <mps> minimal: sure it is bug because 'fsck.f2fs /dev/mmcblk1p3' says 'Info: Check FS only on RO mounted device'. and it is RO mounted
2021-08-31 13:49:18 <minimal> mps: that message apparently means that fsck.fsf2 will check for any corruption but will never fix any it finds (unless the "-f" option is passed)
2021-08-31 13:49:56 <mps> temp solution is to use '-f' flag, i.e. force
2021-08-31 13:50:11 <mps> ah, you are faster
2021-08-31 13:50:28 <minimal> mps: yes, that's what I was doing myself when I was using F2FS on SDcard last year/start of this year
2021-08-31 13:50:55 <minimal> but its a workaround as it means every boot takes longer as full filesystem check is forced
2021-08-31 13:51:15 <mps> hmm, true
2021-08-31 13:51:20 <Thermi_> mps, oracle offers free 4 core 24 gb ram 45 gb ssd VMs
2021-08-31 13:51:27 <Thermi_> kind of fast
2021-08-31 13:51:31 <minimal> that's why I stopped using F2FS and went back to EXT4
2021-08-31 13:51:35 <mps> looks like I need yet another cup of black tea
2021-08-31 13:51:42 <Thermi_> you read oracle? :D
2021-08-31 13:52:20 <mps> Thermi_: uh, not good day for such bad jokes ;p
2021-08-31 13:52:38 <Thermi_> mps, sadly, the information about the VMs wasn't a joke :(
2021-08-31 13:53:14 <Thermi_> I can't let Oracle get into my good graces after what they did for the last 25 years
2021-08-31 13:54:06 <mps> capitalism on its extreme, i.e. idiocy
2021-08-31 13:54:25 <mps> s/idiocy/oracle/
2021-08-31 13:54:28 <mps> :)
2021-08-31 13:55:24 <mps> minimal: looking f2fs-tools git log https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/
2021-08-31 13:55:36 <mps> don't see solution on horizon
2021-08-31 13:55:44 <minimal> Thermi_: in the past I worked in at least 1 place that had an Oracle site license so once the license was paid using any additional Oracle stuff was "free" - so policy was to use Weblogic, Oracle (ex-Sun) LDAP/SSO, Oracle DB, etc :-(
2021-08-31 13:57:01 <minimal> mps: I think the correct solution is as Hello71 said in the Issue, for initramfs' init to do any fsck for rootfs before mounting rootfs - which as you pointed out means including relevant fsck binary into initramfs
2021-08-31 13:58:34 <mps> minimal: I thought it is already there
2021-08-31 13:59:13 <tjones> ericonr: It's part of libresolv, not libc.  
2021-08-31 14:00:02 <minimal> mps: grep fsck /usr/share/mkinitfs/initramfs-init gives nothing
2021-08-31 14:01:17 <minimal> so the init mounts rootfs RO, switch_roots into the mounted rootfs and starts OpenRc...which then runs /etc/init.d/fsck
2021-08-31 14:03:04 <Hello71> tjones: https://www.google.com/search?q=dn_rename+libresolv
2021-08-31 14:03:18 <Hello71> yesterday you said the function was dn_expand
2021-08-31 14:04:01 <Hello71> it would be more useful if you said what program it is and what error you are getting
2021-08-31 14:08:37 <mps> minimal: long ago I intended to contact upstream but didn't because their ML is on sourceforge and don't like to subscribe there and ML don't accept mails for unsubscribed mail address
2021-08-31 14:10:46 <mps> maybe now when current author have mail address on kernel.org
2021-08-31 14:10:52 <Hello71> problem isn't with fsck.f2fs
2021-08-31 14:11:07 <Hello71> if you want to fsck a mounted filesystem, you need huge cooperation from kernel
2021-08-31 14:11:22 <Hello71> otherwise you will corrupt kernel memory and probably make it corrupt filesystem
2021-08-31 14:11:41 <mps> sure
2021-08-31 14:12:05 <Hello71> even e2fsprogs, by far the best fsck, cannot fully do it (usually need reboot after fixes)
2021-08-31 14:12:06 <mps> I don't see point of fscking mounted FS, ro or rw, doesn't matter
2021-08-31 14:12:16 <Hello71> so what are you contacting them about?
2021-08-31 14:12:28 <Hello71> i thought you wanted to ask them to not require -f
2021-08-31 14:12:54 <minimal> mps: yes I've found it hard to search their mailing list on there too, especially as search results are not ordered by date.
2021-08-31 14:13:05 <mps> I wanted to post patch for kernel driver about two years ago, but in meantime someone else fixed that for what I had fix
2021-08-31 14:13:55 <mps> hmm, maybe I should review, not sure is it really fixed
2021-08-31 14:16:14 <tjones> Hello71: yes - I mis-typed from the original error that included the dn_rename.  That is in the musl libc.  dn_expand is the one that is still missing.
2021-08-31 14:16:37 <Hello71> wat
2021-08-31 14:17:04 <Hello71> i don't think there is such thing as libresolv dn_rename
2021-08-31 15:17:38 <ericonr> Not even glibc provides it
2021-08-31 15:17:56 <ericonr> tjones: glibc and musl provide some of the libresolv functionality 
2021-08-31 15:18:14 <ericonr> glibc provides a bit more of the trash and undocumented interfaces
2021-08-31 15:31:40 <mps> '/home/mps/aports/main/u-boot/src/u-boot-2021.07/drivers/virtio/virtio-uclass.c:337: undefined reference to `__lshrdi3''
2021-08-31 15:31:54 <mps> where is this __lshrdi3
2021-08-31 15:32:04 <mps> libgcc?
2021-08-31 15:43:12 <mps> hmm, linux kernel
2021-08-31 15:44:26 <mps> uh no
2021-08-31 15:46:07 <Ariadne> mps: btw systemd-udev for short term, libudev-zero evaluated for long term
2021-08-31 15:47:01 <mps> Ariadne: don't understand
2021-08-31 15:47:31 <mps> what with systemd-udev
2021-08-31 15:56:09 <Ariadne> to deal with eudev
2021-08-31 15:57:16 <mps> oh, I'm blind, above 17:44 ............... mps| uh no
2021-08-31 15:58:03 <mps> oh, I'm blind, above __lshrdi3 issue happened by trying to build 32bit u-boot on 64bit box
2021-08-31 15:58:43 <mps> Ariadne: so alpine will use systemd-udev?! :D
2021-08-31 15:58:49 <Ariadne> for now
2021-08-31 15:58:54 <Ariadne> with libudev-zero in future
2021-08-31 15:59:20 <mps> I don't care, I will continue with libudev-zero :P
2021-08-31 15:59:36 <mps> Ariadne: who decided that?
2021-08-31 15:59:42 <Ariadne> the TSC
2021-08-31 15:59:45 <ikke> That's the goal for Alpine as well, but we need to have something in between
2021-08-31 15:59:57 <mps> hah, I knew that TSC is bad idea
2021-08-31 16:00:22 <mps> I want BDFL back
2021-08-31 16:00:28 <Ariadne> mps: why, its implementing what you wanted :p
2021-08-31 16:00:41 <Ariadne> we just want an upstream for udev in meantime
2021-08-31 16:00:47 <Ariadne> while libudev-zero is tested
2021-08-31 16:00:49 <ikke> mps: the bdfl would have done the same
2021-08-31 16:01:12 <mps> ikke: no if I 'wrote' to him ;)
2021-08-31 16:01:42 <mps> Ariadne: but we will have to maintain systemd-udev in stable for 2 years, at least
2021-08-31 16:02:07 <Ariadne> mps: systemd-udev is likely to be maintained upstream :P
2021-08-31 16:02:19 <mps> yes, I presume
2021-08-31 16:02:44 <mps> but having anything systemd* in alpine doesn't sounds nice
2021-08-31 16:03:10 <Ariadne> oh, the package will just be called udev
2021-08-31 16:03:23 <ncopa> i agree that having anything s*d in alpine does not sound nice. but we already have that, as eudev.
2021-08-31 16:03:32 <mps> meh*
2021-08-31 16:03:44 <ncopa> the long term goal is to use libudev-zero
2021-08-31 16:03:54 <mps> heh
2021-08-31 16:04:05 <ncopa> but we can not switch all over in one go
2021-08-31 16:04:07 <mps> but libudev-zero already works
2021-08-31 16:04:12 <ncopa> does it?
2021-08-31 16:04:20 <mps> what doesn't work
2021-08-31 16:04:22 <ncopa> im not convinced it works for everything
2021-08-31 16:04:25 <Ariadne> i thought hotplug needs to be addressed
2021-08-31 16:04:42 <ncopa> will it sucessfully create /dev/disk/by-id/ symlinks?
2021-08-31 16:04:49 <Ariadne> there is also a lot of // XXX NOT IMPLEMENTED in the source
2021-08-31 16:04:50 <mps> no, hotplug works for all things I tested
2021-08-31 16:05:11 <Ariadne> ncopa: no, but its just a library.  we would use mdev or skarnet's mdevd for that
2021-08-31 16:05:29 <mps> ncopa: yes, with scripts from mdev-like-a-boss, though I don't use them
2021-08-31 16:05:58 <ncopa> i did have a look at creating by-id links using a script
2021-08-31 16:06:10 <ncopa> and its non-trivial to catch all cornercases
2021-08-31 16:06:15 <mps> yes, I wanted to tell that we can ask skarnet for help because he knows internals best
2021-08-31 16:06:44 <ncopa> the point here is that libudev-zero does not work as a 100% replacement of eudev
2021-08-31 16:06:53 <mps> but I didn't wanted to bother him till we decide switch
2021-08-31 16:07:09 <mps> ncopa: true, not 100%
2021-08-31 16:07:13 <ncopa> if we simply repleace eudev with libudev-zero, things will break
2021-08-31 16:07:49 <ncopa> so the plan is to make them run in parallel and move package by package over
2021-08-31 16:08:22 <mps> and I talked with libudev-zero upstream (illiliti) and s/he told me that s/she will work and maintain libudev-zero in future
2021-08-31 16:08:33 <ncopa> but the problem is that eudev is already now dead upstream, and in a few month we will tag a new stable release
2021-08-31 16:08:50 <ncopa> i dont think we will be able to fix all issues in libudev-zero by the next stable
2021-08-31 16:09:16 <ncopa> so in the meantime, Ariadne will look into use udev from s*d with openembedded patches
2021-08-31 16:09:20 <mps> ncopa: also I'm not sure, but we can most, I hope
2021-08-31 16:09:28 <Ariadne> lets refer to it as s5d
2021-08-31 16:09:30 <Ariadne> like k8s
2021-08-31 16:09:32 <Ariadne> :D
2021-08-31 16:09:41 <mps> s6d then ;)
2021-08-31 16:09:44 <ncopa> lol
2021-08-31 16:23:48 <nmeum> Ariadne: btw: any chance you could take a quick look at !24570 iirc you were ok with this change, but just wanted to make sure that the updated version is to your liking before merging it
2021-08-31 16:24:14 <Ariadne> looks good to me
2021-08-31 16:24:21 <Ariadne> can you send me that patch to alpine-gcc-patches repo
2021-08-31 16:24:37 <nmeum> I already did!
2021-08-31 16:24:38 <nmeum> :p
2021-08-31 16:25:06 <nmeum> https://gitlab.alpinelinux.org/kaniini/alpine-gcc-patches/-/merge_requests/3
2021-08-31 16:27:06 <nmeum> I pushed the gcc change
2021-08-31 16:27:27 <Ariadne> great
2021-08-31 17:02:01 <tjones> ericonr: That was a mistype on my part - dn_expand is the one I'm looking for now.
2021-08-31 17:04:13 <maxice8> Ikke: is aports-qa-bot already using aports-proxy-bot ?
2021-08-31 17:34:54 <maxice8> belr is failing to fetch 404
2021-08-31 17:36:43 <ikke> Seems like 5.0.0 has been pulled
2021-08-31 17:36:48 <maxice8> can fetch locally
2021-08-31 17:37:22 <ikke> https://github.com/BelledonneCommunications/belr/releases/tag/5.0.0
2021-08-31 17:41:54 <ikke> maxice8: re aports-proxy-bot, not yet, need to take a look at it
2021-08-31 17:45:36 <maxice8> Ok, it is obligatory in the newer versions of aports-qa-bot
2021-08-31 17:48:49 <Hello71> ncopa: did you look at the udev builtins? seems like it is not too systemd dependent
2021-08-31 18:05:06 <mps> ksmbd is finally merged to kernel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e24c567b7ecff1c8b6023a10d7f78256cef742c4
2021-08-31 18:09:59 <maxice8> huh, synapse failing on builders but pass on CI, fun
2021-08-31 18:10:57 <ikke> oh
2021-08-31 18:11:03 <ikke> I might know that one
2021-08-31 18:12:35 <ikke> Ariadne: can we fix the libcrypto1.1 / openssl3.0 situation? It corrupts the builders
2021-08-31 18:21:14 <tiotags> I have this mr https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24837/diffs?commit_id=504abba7aee907b63004af3401229b27aa9b8872 and leo undid it, is using specific commit hashes instead of git tags discouraged ?
2021-08-31 18:22:26 <tiotags> can I ask why it's preferred to use tags ?
2021-08-31 18:25:38 <yyp> Because tags correspond to releases, and using git checkout is only accepted in few rare cases
2021-08-31 18:29:49 <yyp> Might be also because it broke the build
2021-08-31 18:30:01 <tiotags> and then what should I do if my release doesn't compile on alpine, just use a patch ? or just skip the release ?
2021-08-31 18:30:22 <ikke> A patch is ok
2021-08-31 18:30:27 <yyp> ^
2021-08-31 18:31:15 <tiotags> yyp for me it shows that it compiled ? what do you mean
2021-08-31 18:31:30 <yyp> Failed to production builders aka build.alpinelinux.org
2021-08-31 18:32:39 <ericonr> tjones: dn_expand is in <resolv.h>, what does the error look like?
2021-08-31 18:33:42 <yyp> s/to/on
2021-08-31 18:36:15 <tiotags> yyp can you elaborate because I don't know how to get errors from there ?
2021-08-31 18:37:12 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/hinsightd/
2021-08-31 18:38:01 <ikke> tiotags: If I look here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24837, I don't see the changes being reverted
2021-08-31 18:38:07 <ikke> as a matter of fact, I just see them being pushed
2021-08-31 18:38:14 <ikke> https://git.alpinelinux.org/aports/commit/?id=fec59d9542ec
2021-08-31 18:39:20 <tiotags> hello leo, waves
2021-08-31 18:39:28 <ikke> maxice8 here
2021-08-31 18:40:08 <tiotags> ty maxice8
2021-08-31 18:43:58 <maxice8> welcome
2021-08-31 18:44:14 <tiotags> I mean I can provide patches if it's easier for the distro flow, but I did it like that bc it was simpler for me
2021-08-31 18:44:54 <maxice8> I just fixed the commit title
2021-08-31 18:45:21 <tiotags> patch file or commit hashes is better ?
2021-08-31 18:45:29 <tiotags> ok
2021-08-31 18:45:38 <ikke> In general releases + patch file
2021-08-31 18:45:42 <ikke> that makes updating packages easier
2021-08-31 18:46:05 <tiotags> will do that
2021-08-31 18:46:40 <ikke> No need to fix it right away, you can do that next time, if even still relevant
2021-08-31 18:53:02 <tiotags> my big problem is that I can't test a release without making a tag but if I do that the tag remains forever in different build systems and caches
2021-08-31 19:06:39 <ncopa> Hello71: no i didnt
2021-08-31 19:26:00 <mps> ncopa: Ariadne: ikke: I tested creating '/dev/disk/by-label/' and '/dev/disk/by-uuid/' with libudev-zero and it works when insteting mmc cards
2021-08-31 19:26:30 <mps> I have to test it with hot plugging usb disks
2021-08-31 19:28:49 <ncopa> and /dev/disk/by-id?
2021-08-31 19:29:40 <ncopa> i guess the by-uuid by-label should be relatively simple to implement with libblkid
2021-08-31 19:30:27 <ncopa> the udev rules for generating the /dev/disk/by-id seems a bit complicated to handle all the different storage types and cornercases
2021-08-31 19:30:30 <Hello71> iirc udev already uses libblkid
2021-08-31 19:31:08 <mps> no, not tested /dev/disk/by-id, what id are there
2021-08-31 19:31:32 <ncopa> persistant storage id for the disk itself
2021-08-31 19:31:47 <mps> isn't that uuid
2021-08-31 19:31:48 <ncopa> udev fishes out serial number of disk and similar
2021-08-31 19:31:55 <ncopa> uuid is from filesystem
2021-08-31 19:32:06 <mps> ah, whole disk
2021-08-31 19:32:11 <ncopa> by-id works even if there are no filesystems
2021-08-31 19:32:13 <ncopa> yeah
2021-08-31 19:32:26 <mps> will look at this
2021-08-31 19:32:39 <ncopa> by-id looked non-trivial to implement. the other ones not so bad
2021-08-31 19:32:55 <skarnet> you don't need /dev for that, you just need blkid and friends
2021-08-31 19:33:17 <mps> I don't have this even on servers where eudev runinng
2021-08-31 19:33:20 <tjones> ericonr: Error relocating /usr/local/bin/mfserver: __dn_expand: symbol not found
2021-08-31 19:33:44 <ncopa> can somebody please help me review https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.11.12-3.12.8.-3.13.6-released.md
2021-08-31 19:34:16 <ncopa> the by-id is needed for zfs. i had a look at it last week and it was hairy
2021-08-31 19:34:39 <ncopa> so hairy that I seriously considered pull in udev in initramfs
2021-08-31 19:34:43 <ericonr> tjones: that sounds like bad code; grep for __dn_expand and replace with dn_expand. It should have a warning about implict declaration of dn_expand as well
2021-08-31 19:34:54 <mps> oh, on one server all these => by-id/  by-label/  by-partuuid/  by-path/  by-uuid/
2021-08-31 19:35:20 <ericonr> *implicit declaration of __dn_expand
2021-08-31 19:36:08 <ncopa> i dont think "blkid and friends" implements all the nasty udev rules for by-id https://github.com/gentoo/eudev/blob/master/rules/60-persistent-storage.rules
2021-08-31 19:38:32 <tjones> ericonr: my code calls dn_expand():
2021-08-31 19:38:46 <tjones> p += dn_expand(query, query + 1000, p, buf, 1000);
2021-08-31 19:40:59 <tjones> No warning because I include arpa/nameser.h and resolv.h
2021-08-31 19:41:16 <mps> and for long time I use one-line patch to mdev.conf to rename net interfaces using nameif and /etc/mactab
2021-08-31 19:43:04 <ericonr> tjones: I'm struggling to imagine how __dn_expand could appear then
2021-08-31 19:44:01 <ncopa> drats.... ppc64le build of 3.12.8 is broken
2021-08-31 19:44:08 <ncopa> im so tired of ppc64le
2021-08-31 19:44:23 <ericonr> tjones: just tried to build something using dn_expand, it worked fine...
2021-08-31 19:49:49 <Hello71> ncopa: i think biggest problem is those builtins. everything else is somewhat tedious but basically just needs mechanical translation
2021-08-31 19:52:04 <mps> whatever, but I don't think we have to emulate/implement everything udev does with mded or mdevd and libudev-zero
2021-08-31 19:52:55 <mps> else we have to switch to glibc, systemd*
2021-08-31 19:53:55 <Hello71> i think if you want to silently replace eudev with libudev-zero then it should work ootb for at least 99% of upgrading users
2021-08-31 19:54:21 <Hello71> if udev remains an option then the transition can be made more gradually, with feature breaks if necessary
2021-08-31 19:54:22 <mps> Hello71: ime this will not work
2021-08-31 19:55:39 <mps> if we want to switch to libudev-zero users must be informed and expect that some things will not work or not work as with eudev
2021-08-31 19:56:40 <mps> but I think we can make alpine quite fine with libudev-zero, i.e. small, simple ...
2021-08-31 19:57:12 <mps> true, this will require some efforts from all of us
2021-08-31 20:01:18 <ncopa> the current plan it to make the switch gradually
2021-08-31 20:02:41 <mps> I don't insist on anything
2021-08-31 22:33:04 <Ariadne> one concern is that people might try to make systemd itself work on alpine :D
2021-08-31 22:33:22 <dalias> :-p
2021-08-31 22:33:39 <valerius> 
ACTION grits teeth

2021-08-31 22:34:42 <dalias> ericonr, sounds like tjones was compiling against glibc headers ...
2021-08-31 22:35:03 <dalias> #define dn_expand               __dn_expand
2021-08-31 22:46:21 <ericonr> dalias: seemed possible, but this is an alpine channel :<
2021-08-31 23:00:43 <dalias> i think they're trying to compile something for glibc and run it on alpine
2021-08-31 23:00:46 <dalias> and not disclosing that
2021-08-31 23:16:04 <Ariadne> haha