2021-09-01 00:01:08 <Hello71> shouldn't that actually work?
2021-09-01 00:01:14 <Hello71> i mean the former, not the latter
2021-09-01 00:01:24 <Hello71> my guess is they themselves have no idea what they're doing
2021-09-01 01:52:16 <dalias> hello71, former = ?
2021-09-01 01:52:44 <Hello71> well isn't both glibc and musl #define dn_expand __dn_expand
2021-09-01 03:08:07 <Ariadne> no
2021-09-01 03:08:15 <Ariadne> musl only have dn_expand()
2021-09-01 03:08:17 <Ariadne> afaik
2021-09-01 03:08:27 <Ariadne> gcompat provides one or the other, as an alias
2021-09-01 03:23:34 <craftyguy> I'm packaging something that has optional runtime 'dependencies'. e.g. packages can be installed that cause additional functionality to be enabled at runtime, but they aren't hard dependencies and users probably want to pick/choose what they install
2021-09-01 03:23:59 <craftyguy> arch linux pkgbuild has a 'optdepends', that will list them out after the package is installed. doesn't look like apkbuild has something like that...
2021-09-01 03:24:08 <craftyguy> so is the convention here to just print them out in the post-install script?
2021-09-01 03:25:10 <craftyguy> some message like "for xyz functionality, install package foo-xyz. for abc functionality, install package foo-abc (and so on)"
2021-09-01 03:27:38 <ikke> https://lists.alpinelinux.org/~alpine/devel/?search=optional+dependencies
2021-09-01 03:29:39 <craftyguy> so, "don't recommend anything" and let users figure out on their own why it might not work out of the box like they expect?
2021-09-01 03:30:26 <craftyguy> that's fine too I guess. I hadn't seen that thread, thanks for sharing it
2021-09-01 04:18:59 <Ariadne> craftyguy: we are working on adding `recommends`
2021-09-01 04:19:15 <Ariadne> 
ACTION looks into this cryptsetup issue

2021-09-01 04:20:57 <Ariadne> i'm very confused
2021-09-01 04:21:15 <Ariadne> cryptsetup builds fine on my sifive unleashed board
2021-09-01 04:22:24 <Ariadne> hmm, but it does not due to LUKS
2021-09-01 04:22:45 <Ariadne> ohh, err
2021-09-01 04:22:47 <Ariadne> okay
2021-09-01 04:22:58 <Ariadne> helps if i update git :P
2021-09-01 04:24:30 <Thermi_> I AM FREE OF MY BURDEN
2021-09-01 04:24:34 <Thermi_> I switched my job.
2021-09-01 04:24:41 <Thermi_> (sorry)
2021-09-01 04:24:59 <Thermi_> Dobby is freeeeee
2021-09-01 04:25:37 <craftyguy> Ariadne: no. I was just wanting to use something like that for a package I made
2021-09-01 04:27:05 <Thermi_> Ariadne, the gcc gnat cross compile issue is due to chost arch libs being in cbuild directories. The packages have the same name though, and in order to avoid building packages twice (to avoid package name duplication), I propose symlinking libs from /usr/lib to /usr/$arch[...]/ depending on if $arch is the cbuild arch or not. That way libs for other archs aren't in /usr/lib on cbuild.
2021-09-01 04:27:32 <Ariadne> seems reasonable
2021-09-01 04:27:43 <Ariadne> feel free to open an MR doing it
2021-09-01 04:27:56 <Ariadne> would be nice to get ada on riscv64
2021-09-01 04:28:15 <Thermi_> Alright, I'll keep it in mind and might do it
2021-09-01 04:28:17 <Thermi_> We'll see.
2021-09-01 04:31:48 <Ariadne> figured out cryptsetup
2021-09-01 04:32:03 <Ariadne> god this unleashed board is slow
2021-09-01 04:32:27 <Thermi_> riscv64?
2021-09-01 04:32:32 <Ariadne> yes
2021-09-01 04:32:39 <Ariadne> or maybe its because i am using a crappy sd card
2021-09-01 04:32:42 <Thermi_> OH lord yes.
2021-09-01 04:32:47 <Thermi_> That's a cheap test.
2021-09-01 04:33:06 <Thermi_> You could try loading it all into memory using vmlock afair
2021-09-01 04:33:25 <Thermi_> There's a tool
2021-09-01 04:33:29 <Thermi_> vmlock wasn't the name
2021-09-01 04:33:54 <Ariadne> i could just run from tmpfs
2021-09-01 04:33:55 <Ariadne> :P
2021-09-01 04:34:02 <Thermi_> vmtouch.
2021-09-01 04:34:22 <Thermi_> less work to just run vmtouch /usr or something and then test than copying stuff around
2021-09-01 04:34:54 <Thermi_> vmtouch -tfq /usr
2021-09-01 04:35:12 <Ariadne> so, which burden
2021-09-01 04:35:17 <Ariadne> moving kopano into community? :P
2021-09-01 04:36:28 <Thermi_> I haven't figured that part out yet :D
2021-09-01 04:36:42 <Thermi_> "HiFive Unleashed (Discontinued)"
2021-09-01 04:36:43 <Thermi_> Hahahaha
2021-09-01 04:38:28 <Thermi_> Of course it's discontinued.
2021-09-01 04:39:36 <Ariadne> trust me, you're not missing much
2021-09-01 04:39:54 <Ariadne> this board has performance redolent of a raspberry pi 2, just with more ram
2021-09-01 05:57:37 <ncopa> good morning
2021-09-01 06:18:40 <psycogenesis> I want to maintain unmaintained package: github-cli, how step I should follow to commit my APKBUILD?
2021-09-01 06:22:55 <mps> good morning
2021-09-01 06:23:25 <linearcannon> could i get someone to ook at merge request !24786 before i have to rebase it again
2021-09-01 06:24:10 <mps> Thermi_: good news, hope you found a better job
2021-09-01 06:29:04 <psycogen1sis> quit
2021-09-01 08:06:19 <mps> nmeum: could you post your guide about u-boot for rv64 boards, please
2021-09-01 08:24:25 <nmeum> mps: I just followed the u-boot documentation https://u-boot.readthedocs.io/en/latest/board/sifive/unmatched.html
2021-09-01 08:24:53 <nmeum> and based on that wrote a script to generate a bootable alpine sdcard image https://gitlab.alpinelinux.org/nmeum/alpine-unmatched
2021-09-01 08:26:13 <mps> thanks
2021-09-01 08:26:28 <mps> I tried same for qemu but it doesn't boot
2021-09-01 08:27:17 <mps> hope that you found some 'tweaks' for it to fix problem
2021-09-01 08:43:19 <nmeum> mps: qemu also has its own documentation on this, see https://github.com/qemu/qemu/blob/65388f404492daac86e02980d10ae84c694870b3/docs/system/riscv/virt.rst#running-u-boot
2021-09-01 08:59:14 <mps> nmeum: yes, I know, but also doesn't work, or I didn't made it correctly
2021-09-01 09:19:17 <Ariadne> btw
2021-09-01 09:19:28 <Ariadne> alpine is now on amiga
2021-09-01 09:21:54 <linearcannon> well, not quite. my test machine is a macintosh quadra 700
2021-09-01 09:21:58 <linearcannon> i don't have an amiga on hand lol
2021-09-01 09:23:33 <Ariadne> i do :D
2021-09-01 09:28:02 <linearcannon> pushing the remaining WIP/temporary commits https://gitlab.alpinelinux.org/goshhhy/aports/-/tree/m68k - it's dirty, i'll clean up a bit more tomorrow
2021-09-01 09:28:42 <linearcannon> some of the stuff that isn't directly m68k has already had merge requests made - you approved one, there's also !24870 and !24871
2021-09-01 09:29:02 <linearcannon> and issue #12967 will probably be important, i did a dirty workaround for that
2021-09-01 09:29:23 <linearcannon> but for now i have to go to bed
2021-09-01 09:29:26 <linearcannon> i should've been asleep an hour ago
2021-09-01 10:52:18 <wej> Ariadne, linearcannon: alpine on 68k and possibly amiga sound awesome :D i still have an amiga somewhere, if testing needs to be done, just let me know
2021-09-01 11:50:23 <andypost[m]> Ariadne: interesting how amiga's blitter could be used via linux)
2021-09-01 11:56:52 <andypost[m]> ikke: any idea why rust x2-x3 slower in aarch64 CI https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/92037/builds
2021-09-01 11:57:23 <andypost[m]> it needs ~8G of disk space
2021-09-01 11:57:47 <ikke> andypost[m]: you mean armhf?
2021-09-01 11:58:07 <andypost[m]> yes, sorry
2021-09-01 11:58:50 <ikke> Not sure. It runs in identical qemu vms as the other arm arches
2021-09-01 12:00:22 <andypost[m]> last 2 hours it stuck on the same line as previous run has timed out
2021-09-01 12:06:51 <ikke> hmm
2021-09-01 12:54:44 <ikke> OpenSSL 3.0 GA targetted for next tuesday
2021-09-01 12:55:11 <ikke> https://mta.openssl.org/pipermail/openssl-project/2021-August/002729.html
2021-09-01 14:15:47 <Hello71> Ariadne: https://git.musl-libc.org/cgit/musl/tree/src/network/dn_expand.c
2021-09-01 14:15:59 <Hello71> seems like both?
2021-09-01 16:50:59 <mps> does ibmswtpm2 is needed on rv64
2021-09-01 17:06:29 <Ariadne> probably not
2021-09-01 17:12:01 <mps> it failed on ricv64 with a lot of error, I will disable it for now on this arch
2021-09-01 17:12:55 <ericonr-> Hello71: musl header exposes dn_expand only, __dn_expand is the internal one. and glibc's internal one is... ___dn_expand, which is aliased to __dn_expand, which is aliased to dn_expand
2021-09-01 17:33:33 <Hello71> uh.
2021-09-01 18:31:46 <staceee> Hello there, we'd like to release Sxmo 1.5.1 but we still need light to be moved from testing to community
2021-09-01 18:31:56 <staceee> anyone could speed up this merge ?
2021-09-01 18:32:23 <staceee> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24399
2021-09-01 18:33:10 <ikke> staceee: will look at it in a bit if no one preempted me
2021-09-01 18:33:19 <staceee> thanks a lot !
2021-09-01 18:33:22 <Hello71> would be good to ask maintainer
2021-09-01 18:33:59 <Hello71> hm, not sure if they are active anymore
2021-09-01 18:34:28 <Hello71> yeah, bumps were by maxice8 
2021-09-01 18:38:26 <mps> move it
2021-09-01 18:40:00 <mps> moved
2021-09-01 18:42:22 <Hello71> staceee, mps: close !24537?
2021-09-01 18:42:36 <staceee> you guys rocks
2021-09-01 18:44:26 <mps> I use it from the beginnig, even created it before mainter pushed it to aports because his APKBUILD was better than mine
2021-09-01 18:44:38 <mps> maintainer*
2021-09-01 18:45:48 <mps> eu is not active for some time on alpine
2021-09-01 18:46:04 <mps> eu i.e. Eivind
2021-09-01 18:46:21 <ikke> Right, he was active again for a couple of weeks, but then disappeared again
2021-09-01 18:47:03 <mps> yes, I remember and iirc he was one of the first alpine developers
2021-09-01 18:58:46 <staceee> dunno if it is important but that job failed : https://gitlab.alpinelinux.org/alpine/aports/-/jobs/475764
2021-09-01 19:06:47 <mps> staceee: no, it is not important
2021-09-01 19:07:41 <mps> I rebased it and didn't wait to finish but merged immediately and because that it failed
2021-09-01 19:58:20 <maxice8> Back, installed a new OS
2021-09-02 04:30:13 <staceee> light still is in testing for two archs. There is a build issue ? https://pkgs.alpinelinux.org/packages?name=light&branch=edge
2021-09-02 04:30:46 <ikke> mips is gone
2021-09-02 04:31:58 <ikke> aarch64 seems stuck
2021-09-02 06:24:49 <link2xt> aarch64 didn't build rust 1.54.0 yet
2021-09-02 06:28:02 <andypost[m]> riscv64 also looks stuck on spotify-qt
2021-09-02 06:56:29 <mps> good morning
2021-09-02 06:57:04 <mps> goede morgen, доброе йутро :)
2021-09-02 06:58:33 <mps> we really need to do something with community repo, reorganize it better, split, make something new, idk what exactly but something have to be done
2021-09-02 07:03:10 <ikke> link2xt: it just finished building rust
2021-09-02 07:03:46 <ikke> Lets make a dir called mps with package just as mps wants it :P
2021-09-02 07:03:57 <ikke> packages*
2021-09-02 07:07:10 <mps> likke: like that idea :)
2021-09-02 07:07:52 <mps> and another one called ikke
2021-09-02 07:17:18 <andypost[m]> salut) @ikke do you mean to add second level hierarchy a-la debian doing?
2021-09-02 07:17:37 <ikke> andypost[m]: I don't mean anything, that was not a serious suggestion
2021-09-02 07:17:52 <mps> whenever I propose something I'm met with enthusiasm, indifference, and hostility, depending on whom you asked
2021-09-02 07:18:15 <mps> only ikke met me with jokes :)
2021-09-02 07:18:36 <mps> s/you/I/
2021-09-02 07:18:41 <andypost[m]> 4k dirs in community
2021-09-02 07:27:44 <mercenary> No problem in software cannot be solved by adding another layer of indirection
2021-09-02 07:28:43 <mercenary> Make community a set of personal dirs containing symlinks to packages required, and actual packages for personal overrides
2021-09-02 08:13:03 <andypost[m]> there's 2 upgrades (MRs ready) - libffi and icu but it affects ~60 aports to rebuild for each, CI timed out - how to test it?
2021-09-02 08:13:44 <ikke> how long was CI timeout?
2021-09-02 08:14:24 <andypost[m]> 8hrs https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/91882
2021-09-02 08:14:48 <ikke> ok, that is already quite long
2021-09-02 08:14:53 <andypost[m]> I even excluded few packages
2021-09-02 08:15:51 <andypost[m]> the only failure I get is seamonkey but it fails to build also without new icu
2021-09-02 08:18:21 <andypost[m]> ikke: in ci settings I have 12h timeout but https://gitlab.alpinelinux.org/alpine/aports/-/jobs/476078 limited by 6 (not clear why)
2021-09-02 08:19:09 <ikke> It's a detached pipeline, it uses the project settings apparently
2021-09-02 08:19:49 <andypost[m]> also https://gitlab.alpinelinux.org/alpine/aports/-/jobs/476077 "Job's log exceeded limit of 104857600 bytes."
2021-09-02 08:20:23 <ikke> yeah, kind of running against the limits of what CI is able to handle atm
2021-09-02 08:20:56 <andypost[m]> sane limits for sure
2021-09-02 08:21:50 <ikke> only real option I have for now is splitting the MR up into multiple, where in each MR you also upgrade icu
2021-09-02 08:27:36 <andypost[m]> thank, good idea, all firefoxes needs rebuild)
2021-09-02 11:13:52 <Newbyte> Cogitri: Do you have any idea why gnome-software 41.beta doesn't build the gnome-software-static subpackage?
2021-09-02 11:14:01 <Newbyte> Is that why it's still on 3.38 in Alpine?
2021-09-02 11:31:26 <Cogitri> <Newbyte> "Cogitri: Do you have any idea wh" <- I think they moved to a shared library now 
2021-09-02 11:31:42 <Cogitri> Ah sorry I shouldn’t quote in bridged rooms
2021-09-02 11:32:09 <Cogitri> And it’s still on 3.38 because I didn’t have time to test the apk plug-in against the new API of 40
2021-09-02 11:32:57 <Newbyte> Oh, dang it. I wanted to update the package to 41.beta in postmarketOS since it should be adaptive to phones now
2021-09-02 11:33:19 <Newbyte> I think the current package is a fork of 3.34 and it doesn't really work very well
2021-09-02 11:39:16 <Cogitri> Yeah
2021-09-02 11:39:26 <Cogitri> You can help test though
2021-09-02 11:40:14 <Cogitri> https://github.com/Cogitri/gnome-software-plugin-apk/pull/8
2021-09-02 11:41:16 <Newbyte> Cogitri: Should this work for 41.beta as well?
2021-09-02 11:41:56 <Cogitri> I haven’t tested it but I don’t think they changed the API again
2021-09-02 11:42:00 <Cogitri> You could give it a try
2021-09-02 11:42:10 <Newbyte> How do I go about the -static subpackage thing?
2021-09-02 11:49:48 <Cogitri> Just remove it
2021-09-02 11:50:29 <andypost[m]> how it possible that "next" package exists but not in repo? https://pkgs.alpinelinux.org/packages?name=next&branch=edge
2021-09-02 11:52:06 <andypost[m]> ah it was renamed in 5c58240ac1
2021-09-02 12:26:52 <staceee> then is light stucked foravar at the doors of aarch64 community ? https://pkgs.alpinelinux.org/packages?name=light&branch=edge
2021-09-02 12:27:29 <staceee> oh in fact my bad, it is duplicated in the web ui
2021-09-02 12:35:33 <ikke> gnuradio is stuck on aarch64 (twice already)
2021-09-02 12:40:10 <ericonr> ikke: did you try importing https://github.com/doxygen/doxygen/pull/8739 ?
2021-09-02 12:42:47 <ericonr> i see https://github.com/alpinelinux/aports/commit/febbcf1c57685c0d98b66abc521ca6a89855b89b now
2021-09-02 12:43:55 <ikke> ericonr: you mention crashes, not hangs?
2021-09-02 12:45:23 <ikke> And this is a test that is hanging
2021-09-02 12:45:51 <ikke> blocks_qa_gr_top_block
2021-09-02 12:46:22 <Newbyte> >>> ERROR: gnome-software-dev*: usr/lib/pkgconfig/gnome-software.pc: pkgconf version 41.beta is invalid 🤔
2021-09-02 12:46:46 <Newbyte> Do you have any suggestions regarding how to deal with that?
2021-09-02 12:50:53 <sircmpwn> patch it I expect
2021-09-02 12:54:27 <ericonr> ikke: ah, thought it would have been another doxygen hang. And all manners of thing can be caused by memory corruption, idk :{
2021-09-02 12:55:14 <Hello71> Newbyte: s/\./_/
2021-09-02 12:56:03 <Newbyte> Hello71: yes, but where would I do that?
2021-09-02 12:56:16 <Newbyte> I can send my current APKBUILD if it helps
2021-09-02 13:15:49 <Hello71> depends where the pc is made
2021-09-02 13:20:26 <Newbyte> I would assume it comes from the sources: https://gitlab.gnome.org/GNOME/gnome-software/-/tree/41.beta
2021-09-02 13:22:55 <andypost[m]> ikke: better to disable the test !24907
2021-09-02 13:29:54 <minimal> will someone please look at merging !24296?
2021-09-02 15:03:03 <bl4ckb0ne> what's the status for !24083 ?
2021-09-02 15:36:53 <Ariadne> minimal: done
2021-09-02 15:44:27 <minimal> Ariadne: thanks. Any chance of getting !24896 merged too? ;-)
2021-09-02 15:45:27 <Ariadne> done
2021-09-02 15:46:15 <minimal> thanks
2021-09-02 17:27:30 <Cogitri> Ariadne: BTW, how close to release is apk v3 by now?
2021-09-02 17:27:49 <Ariadne> i mean, it will be released when it is done
2021-09-02 17:27:58 <Ariadne> but i think it is close
2021-09-02 17:28:53 <Cogitri> Alright, just curious since I’m starting to look for topics for my thesis and apk-ostree would be an interesting candidate
2021-09-02 17:40:01 <Ariadne> i think its done enough for that
2021-09-02 17:45:05 <Cogitri> Neat
2021-09-02 17:56:16 <tjones> Hi all - rebuilt an Alpine dev tool chain and am working on compiling against musl.  However, one more issue comes up - utsname().  My system has sys/utsname.h, but it seems to be missing in musl libc.  Any thoughts?
2021-09-02 18:00:21 <ericonr> if it's missing you have your include paths wrong :p
2021-09-02 18:01:00 <ericonr> also, really recommend using a proper chroot/container/whatever over an external toolchain, if you can :p especially if the toolchain isn't a musl-cross-make one
2021-09-02 19:53:03 <tjones> ericonr: the include file is found, it's at the linker phase where it's being reported as not found (in libc).
2021-09-02 19:53:18 <tjones> make
2021-09-02 19:59:31 <Hello71> it really doesn't help when you refuse to show your error messages
2021-09-02 20:05:52 <tjones> Hello71: I see.  Sorry to have disturbed you.  
2021-09-02 20:07:59 <veiviser> any particular reason you can't just pastebin the builds
2021-09-02 20:08:54 <veiviser> also the easiest way to build for musl is to follow the alpine-in-a-chroot guide, which is just running a script and installing build tools in it, just in case you were doing something else more manual that could've gone wrong
2021-09-02 20:43:57 <xordspar0> I want to package a game that has GPL code and freeware assetes (proprietary but redistributable). Should I... a) package this in non-free b) package it in community and download the assets in post-install c) don't package this in Alpine
2021-09-02 20:56:35 <valerius> whether the game sucks or not is part of the equation ;)
2021-09-02 21:04:50 <mps> valerius: not only these, but is the 'game' free or not. in this case looks like it is not for alpine even in non-free
2021-09-02 21:05:33 <valerius> what even is the game?
2021-09-02 21:05:36 <mps> non-free is mostly for _really_ needed things and things which suddenly becomes non free
2021-09-02 21:06:05 <orbea> if its just the assets then all of the code is GPL?
2021-09-02 21:06:17 <valerius> mps, so firmware and code that we have relied on but had a license change
2021-09-02 21:06:54 <mps> valerius: yes, some firmware and latest mongodb 'debacle'
2021-09-02 21:08:01 <valerius> code quality/release engineering is also a factor when considering something to package
2021-09-02 21:08:11 <mps> ok, we will allow simple script which is free and wihich download windows and intall it on user machine
2021-09-02 21:08:29 <orbea> that is an absurd analogy
2021-09-02 21:09:26 <mps> valerius: no, code quality is not important anymore, every trash which is free can be added ;)
2021-09-02 21:09:37 <valerius> rofl... please keep that script away from my machine ;)
2021-09-02 21:10:15 <mps> orbea: what is absurd today tomorrow could be 'normal'
2021-09-02 21:11:16 <orbea> i think comparing proprietary game assets to a windows install script is going to be as absurd today as it will be tomorrow
2021-09-02 21:11:51 <valerius> a lot of this relies on knowing what the actual package in question is
2021-09-02 21:12:07 <mps> look at history, what was absurd 30 years ago now is normal
2021-09-02 21:12:29 <veiviser> such as
2021-09-02 21:12:43 <mps> veiviser: look history
2021-09-02 21:12:55 <veiviser> such as
2021-09-02 21:13:16 <mps> ah, you don't know history :P
2021-09-02 21:13:24 <veiviser> phenomenal argument
2021-09-02 21:13:31 <Thermi_> blown away
2021-09-02 21:13:34 <veiviser> indeed
2021-09-02 21:13:54 <mps> think
2021-09-02 21:13:59 <Thermi_> A N N I H I L A T ED
2021-09-02 21:14:06 <Thermi_> *A N N I H I L A T E D
2021-09-02 21:14:13 <veiviser> xordspar0: what game is it
2021-09-02 21:20:03 <xordspar0> The game is Cave Story. There is a GPL reimplementation of the code called nxengine-evo.
2021-09-02 21:21:22 <veiviser> ahh
2021-09-02 21:21:22 <xordspar0> Ha, currently the most recently updated package in the repo is openmw, which is a reimplementation of a commercial game. It ships without the assents and you have to provide them yourself. nxengine is better off than that because the assets are redistributable.
2021-09-02 21:21:54 <valerius> I've seen Cave Story in a lot of places, it seems like it's somewhat popular
2021-09-02 21:22:09 <valerius> but maybe it does make sense in cases such as these to not install the assets
2021-09-02 21:22:24 <veiviser> personally i think all these things would make more sense in a third party repo, but following precedent you could just package it without assets
2021-09-02 21:22:26 <valerius> what is the situation with doom engines?
2021-09-02 21:23:09 <veiviser> freedoom exists
2021-09-02 21:24:38 <veiviser> i believe even the assets are free there
2021-09-02 21:26:16 <valerius> yeah, I don't see any other doom source ports
2021-09-02 21:26:32 <valerius> that's usually a good example of how to do these types of things but freedom is the only one in this distro by the looks of it
2021-09-02 21:26:52 <valerius> freedoom*
2021-09-02 21:27:22 <xordspar0> I don't understand that. Freedoom is just assets. It's a free replacement of the original assets that you need an engine to use.
2021-09-02 21:28:07 <valerius> https://pkgs.alpinelinux.org/contents?branch=edge&name=freedoom&arch=x86_64&repo=testing
2021-09-02 21:28:23 <valerius> looks like executable binaries to me
2021-09-02 21:30:48 <valerius> https://packages.debian.org/sid/prboom-plus
2021-09-02 21:31:11 <valerius> this is sort of how I am used to seeing such things packaged... no assets included, or assets as a separate package (preferably free assets)
2021-09-02 21:31:17 <mps> rule is, don't package something which doesn't have source code/text
2021-09-02 21:31:29 <mps> even if it is free
2021-09-02 21:31:51 <orbea> nxengine-evo has source code
2021-09-02 21:32:16 <Ariadne> mps: assets are okay to package, as long as they are freely licensed
2021-09-02 21:32:19 <valerius> so in the case of nxengine-evo it might make sense to package that, and it is up to the user to install assets
2021-09-02 21:32:35 <mps> orbea: I'm not talking about particular things, but in general
2021-09-02 21:32:45 <Ariadne> mps: what that policy is against is binary blob programs
2021-09-02 21:33:26 <mps> Ariadne: I understand your question but I can't give simple answer
2021-09-02 21:35:43 <Ariadne> sure, i just wanted to clarify it
2021-09-02 21:36:03 <Ariadne> the problemw ith urbanterror, for example, was not that it was just data
2021-09-02 21:36:13 <Ariadne> it was because the license did not allow redistribution
2021-09-02 21:36:39 <Ariadne> freedoom, on the other hand, is fine to distribute
2021-09-02 21:36:46 <mps> yes, we don't have written rules, just 'best practice' told to us overtime by (retired) BDFL
2021-09-02 21:37:21 <mps> and 'founding fathers' ;)
2021-09-02 21:38:31 <mps> <irony> says someone who 'cares' for linux firmware in last time</irony>
2021-09-02 21:40:54 <mps> there is also parole pkg, which ask to download something which is non free (I guess) when it is started
2021-09-02 21:41:16 <Ariadne> linux-firmware is complicated.  i think there needs to be some work done to audit it
2021-09-02 21:42:09 <mps> also I think so, but I doubt we have 'resources' for this
2021-09-02 21:42:43 <mps> we simply rely on current upstream on kernel.org
2021-09-02 21:46:16 <Ariadne> its just a matter of going through WHENCE and dropping the ones we cant ship
2021-09-02 21:47:11 <mps> ianal
2021-09-02 21:48:06 <mps> and I will not audit such things as firmware, taking the risk personally by installing even firmware from non-free
2021-09-02 21:49:32 <ericonr> Ariadne: what sort of limitations would you have? I always assumed things being in linux-firmware meant they were redistributable
2021-09-02 21:49:49 <Ariadne> ericonr: read the WHENCE file, it is pretty scary
2021-09-02 21:49:58 <Ariadne> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE
2021-09-02 21:51:13 <Ariadne> most of it is okay, but theres a lot that needs to be trimmed too
2021-09-02 21:51:19 <ericonr> Is linux-firmware a dumpster diving project or something?
2021-09-02 21:51:36 <ericonr> "Found in ..."
2021-09-02 21:52:08 <ericonr> Maybe some fw here fell from the back of a truck
2021-09-02 21:52:16 <mps> and 'taken from kernel source'
2021-09-02 21:52:52 <mps> after last umich (edu) affair
2021-09-02 21:53:48 <Ariadne> umn
2021-09-02 21:53:52 <veiviser> fell off a truck
2021-09-02 21:54:17 <mps> yes, umn
2021-09-02 22:14:10 <adamplumb> I'm trying to package libadwaita but the version string  in the pkgconfig seems to be invalild.  i get ">>> ERROR: libadwaita*: usr/lib/pkgconfig/libadwaita-1.pc: pkgconf version 1.0.0_alpha.2 is invalid"
2021-09-02 22:15:15 <adamplumb> is there a way around this? i guess i could maybe add a patch to sanitize the version string
2021-09-02 22:16:30 <Cogitri> I think we just have to adjust abuild’s regex for that since this will happen for every single GNOME alpha/beta build
2021-09-02 22:25:16 <toniz4> hello, there is any rules on how to use variables inside strings in APKBUILDS? I usualy use ${var}, but in most of apkbuilds that i see, most of the time its just $var
2021-09-02 22:25:57 <mps> toniz4: 'we' prefer last style
2021-09-02 22:30:14 <toniz4> mps: got it, thanks!
2021-09-02 22:31:57 <xordspar0> valerius: Ah, I figured out what the freedoom files in /usr/bin/ are. They're not binaries, but scripts that look for any Doom engine and then use it to run the game. So Freedoom will not run unless you install a Doom engine. https://github.com/freedoom/freedoom/blob/master/dist/freedoom
2021-09-02 22:32:11 <xordspar0> Maybe I'll package chocolate-doom :)
2021-09-02 22:44:09 <valerius> xordspar0, crispy-doom is the better option
2021-09-02 22:44:20 <valerius> can be just like chocolate, or can have non-painful resolution :)
2021-09-02 22:48:57 <Hello71> Cogitri: it's apk pkgver
2021-09-02 22:49:15 <Hello71> because depends=pc:pkg-ver
2021-09-02 22:50:39 <Cogitri> Ah
2021-09-02 23:00:31 <Hello71> now that i think about it, it would probably make sense for abuild to just filter those itself
2021-09-02 23:01:01 <Hello71> at least for e.g. 1.2.3.alpha
2021-09-02 23:02:38 <Hello71> 1.0.0_alpha.2 could be automangled into 1.0.0.2_alpha. maybe that's too automagic though
2021-09-02 23:04:52 <andypost[m]> Good idea to relax linter requirement about version, as it anyway needs kinda `_pkgver=${pkgver//}` which also bring error
2021-09-03 00:00:15 <adamplumb> I ended up writing a patch for my MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24923
2021-09-03 00:00:50 <adamplumb> not an awesome scalable solution but it got it working for me and now i can use this cool new reddit app
2021-09-03 01:58:21 <Ariadne> Hello71: it does
2021-09-03 01:59:05 <Ariadne> Cogitri: abuild asks pkgconf to validate the version afaik
2021-09-03 04:16:15 <andypost[m]> is there a way to point specific order for builder when bumping dependent aports?
2021-09-03 04:18:14 <andypost[m]> it's about icu/ffi upgrade - python and llvm should be rebuild first otherwise abuild using to install old version (guess because old .so requirement)
2021-09-03 07:01:12 <nmeum> Ariadne: does su show a password prompt on your unleashed (e.g. if you try `su root` as a unpriv. user)? because on the unmatched it doesn't. in fact, it seems that all applets using the ask_and_check_password libbb function don't work correctly (su, getty, …)
2021-09-03 07:16:41 <mps> any objection to !24920
2021-09-03 08:12:38 <mps> ncopa: !24869
2021-09-03 08:19:27 <Cogitri> andypost: the builders always determine the build order automatically by building the package which depends on other rebuilds last
2021-09-03 08:19:38 <Cogitri> So the build order should be correct by default
2021-09-03 08:24:16 <Cogitri> Hm, I thought CI ordered it the same way
2021-09-03 08:24:19 <Cogitri> ikke: ^
2021-09-03 08:25:17 <andypost[m]> Cogitri: thank you, it means only CI needs specific order of commits
2021-09-03 08:37:58 <ncopa> morning
2021-09-03 08:44:06 <Cogitri> Morning
2021-09-03 08:46:01 <ikke> CI uses ap builddirs, so commit order is irrelevant
2021-09-03 08:46:47 <ncopa> andypost[m]: im looking at the libffi upgrade now
2021-09-03 08:49:36 <andypost[m]> ncopa: I need to push updates and rebase community for ruby-ffi
2021-09-03 08:53:44 <andypost[m]> ncopa: pushed
2021-09-03 09:21:59 <ncopa> why the rebuilds of lua5.[1-4]? i cannot see that they link to libffi
2021-09-03 09:23:01 <ncopa> $ apk list --depends so:libffi.so.7 | tpaste
2021-09-03 09:23:02 <ncopa> https://tpaste.us/Zjde
2021-09-03 09:28:43 <andypost[m]> that strange, I used apk search -r libffi
2021-09-03 09:30:37 <andypost[m]> also "4" is not listed at https://pkgs.alpinelinux.org/package/edge/main/x86_64/libffi
2021-09-03 09:55:53 <mps> I made yet another short script to install base alpine for riscv64 in qemu VM on x86_64 host https://arvanta.net/alpine/install-alpine-riscv64-qemu-uboot/
2021-09-03 09:57:49 <mps> diffs from previous one (https://arvanta.net/alpine/install-alpine-riscv64-qemu/) is that this new uses u-boot so it is possible to keep few kernels or boot options and select them from boot menu (numerical menu though)
2021-09-03 10:02:24 <mps> fcolista: I remember that you need such things ^
2021-09-03 10:37:20 <adhawkins> Any chance someone could look at !24746
2021-09-03 10:37:28 <adhawkins> It's got a patch in it, want to make sure it's Ok.
2021-09-03 10:37:45 <adhawkins> The patch won't be required in the next upstream version, as the author has made it easier to exclude the failing tests.
2021-09-03 10:43:39 <ncopa> andypost[m]: we have a problem with libffi and ghc
2021-09-03 10:44:32 <ncopa> ghc makedepends on ghc which runtime depends on libffi
2021-09-03 10:44:48 <ncopa> and current ghc is linked against libffi.so.7
2021-09-03 10:45:41 <ncopa> so to build ghc, it installs current ghc, which pulls in libffi.so.7, when libffi-dev is pulled in, it will use the old, libffi-dev-3.3
2021-09-03 10:47:02 <ncopa> i think the way to fix this is to add a libffi3.3 package which replaces libffi and provides the needed libffi.so.7
2021-09-03 10:47:11 <ncopa> so they both can be installed in parallel
2021-09-03 10:47:26 <ncopa> other alternative is to add libffi3.4
2021-09-03 10:48:18 <ncopa> this is what happens with packages with circular deps
2021-09-03 10:59:00 <ncopa> im fixing it
2021-09-03 12:10:46 <fcolista> mps, you are the best
2021-09-03 12:10:50 <fcolista> thanks a lot!!!
2021-09-03 12:14:04 <mps> fcolista: thanks and you are welcome :)
2021-09-03 12:14:49 <mps> clandmeter preparing something even better, hope we will publish it later
2021-09-03 12:15:56 <mps> side note, some of you boys and girls keep me 'locked' to this limbo distro called alpine ;)
2021-09-03 12:17:30 <fcolista> well, alpine is addictive..
2021-09-03 12:18:44 <mps> few times I wanted to say 'goodbye' but didn't because of such people like you 
2021-09-03 12:19:24 <mps> s/didn't/can't/
2021-09-03 12:30:33 <PureTryOut> How can I get `CBUILD=x86 abuild rootbld` to work? Just installing qemu-i386 and restarting the binfmt service doesn't seem to do it
2021-09-03 12:45:42 <Hello71> try i386 abuild rootbld
2021-09-03 12:46:07 <Hello71> hm, wait, you said qemu
2021-09-03 12:46:59 <mps> qemu-binfmt or similar apk
2021-09-03 12:49:06 <mps> qemu-openrc
2021-09-03 12:57:41 <PureTryOut> I know I know, I have this working fine for other arches. Just not x86
2021-09-03 14:02:28 <kpcyrd> 
ACTION opened a bunch of merge requests to make rust development on alpine nicer :)

2021-09-03 14:06:32 <mps> git -rm *rust|cargo* ?
2021-09-03 14:16:56 <veiviser> kpcyrd: awesome
2021-09-03 14:21:26 <mps> 'aferim efendi' :)
2021-09-03 14:23:51 <kpcyrd> cargo-{outdated,audit,watch,edit} are common tools I use for development, the first two are likely useful for CI too :)
2021-09-03 14:32:53 <mps> kpcyrd: anything which will help with such beast as is rust is welcome
2021-09-03 16:17:39 <mps> updated version of the https://arvanta.net/alpine/install-alpine-riscv64-qemu-uboot/ with great help of clandmeter 
2021-09-03 17:17:13 <minimal> is/was there something up with aarch64 builds recently? Just noticed that a package did not build for aarch64 but also did not "fail": https://gitlab.alpinelinux.org/alpine/aports/-/jobs/476625
2021-09-03 17:18:00 <ikke> minimal: gnuradio being stuck
2021-09-03 17:21:06 <minimal> ah ok, can't you tune it to a different station? ;-)
2021-09-03 17:29:27 <ikke> Getting only static :P
2021-09-03 17:32:56 <skarnet> static obviously wouldn't happen with gnusomething
2021-09-03 17:38:45 <minimal> is a software-defined-radio something like an elephant defined by committee? lol
2021-09-03 18:22:57 <mps> Hello71: libudev-zero is 1.0.0 now 34ec901f84b5d5b48f3bf9bbb11bd1c91c8c7679
2021-09-03 18:23:07 <Hello71> ok
2021-09-03 19:17:15 <ikke> maxice8: libgit2 upgrade has a soname change
2021-09-03 19:19:04 <maxice8> oops
2021-09-03 19:19:21 <maxice8> reverted for now since it require rebuild of some pretty big stuff
2021-09-03 19:19:26 <ikke> right
2021-09-03 19:26:55 <ikke> hjaekel: netcdf has test failures
2021-09-03 19:27:07 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/netcdf/netcdf-4.8.1-r0.log
2021-09-03 19:27:19 <hjaekel> I will have a look
2021-09-03 19:27:27 <ikke> 47/115 Test  #47: ncdump_test_rcmerge ..............***Failed    0.03 sec
2021-09-03 19:27:51 <ikke> hjaekel: thanks
2021-09-03 19:29:04 <hjaekel> did the test fail on all platforms or only on x86_64?
2021-09-03 19:29:14 <ikke> most arches
2021-09-03 19:29:18 <ikke> x86, armhf/v7
2021-09-03 19:29:25 <ikke> riscv64 for a different reason
2021-09-03 19:29:37 <ikke> dhdf5-dev (no such package):
2021-09-03 19:52:22 <Ariadne> working on the configuration directory stuff for doas btw
2021-09-03 19:59:08 <ikke> aha
2021-09-03 20:02:25 <ikke> hmmf, cannot repro the gnuradio hang
2021-09-03 20:02:27 <ikke> don't like that
2021-09-03 20:04:10 <ikke> seems to only happen on the builder
2021-09-03 20:07:00 <Ariadne> weird
2021-09-03 20:08:04 <hjaekel> ikke: is network access allowed on the builders?
2021-09-03 20:08:44 <ikke> hjaekel: yes
2021-09-03 20:09:48 <hjaekel> do I need to set options="net" or is it always allowed?
2021-09-03 20:10:01 <ikke> for now, it does not matter for the builders
2021-09-03 20:10:28 <ikke> need="net" is mostly when using abuild rootbld
2021-09-03 20:10:29 <Ariadne> its preferred to set it if you know you need it :D
2021-09-03 20:10:56 <ikke> (need it during build/check/package)
2021-09-03 20:12:55 <hjaekel> OK, then I will set it, the tests need network. But this cannot be the reason why the tests fail on the builder. Locally and in the CI pipeline the tests were successful
2021-09-03 20:13:03 <ikke> should I just disable checks on gnuradiop for aarch64 for now? Attempts to disabel that specific check seem to fail
2021-09-03 20:13:23 <ikke> Do you know what that specific test does?
2021-09-03 20:19:30 <hjaekel> ncdump_test_rcmerge merges rc files which are configuration files for network access (proxy server etc.). ncdap_test_manyurls opens netCDF files from an url list
2021-09-03 20:20:19 <hjaekel> Is it possible to see the contents of the file /home/buildozer/aports/community/netcdf/src/netcdf-c-4.8.1/Testing/Temporary/LastTest.log
2021-09-03 20:21:13 <ikke> hjaekel: was just on it 😆
2021-09-03 20:21:38 <ikke> https://tpaste.us/YEVM
2021-09-03 20:22:20 <hjaekel> great, thank you
2021-09-03 21:58:05 <Ariadne> hmm
2021-09-03 21:58:12 <Ariadne> riscv64 builder ran out of disk space
2021-09-04 02:39:31 <timetravelingman[m]> Hello
2021-09-04 06:23:05 <Ariadne> AlpineLeo, not to be confused with OnlyFansLeo
2021-09-04 06:53:49 <craftyguy> I think the edge aarch64 builder is stuck on testing/gnuradio 3.8.3.1-r0
2021-09-04 06:54:24 <maxice8> Ariadne: lol
2021-09-04 06:55:08 <ikke> craftyguy: yes, correct 😑
2021-09-04 06:55:50 <craftyguy> my apologies if this is already known :P
2021-09-04 06:55:56 <ikke> no worry
2021-09-04 06:56:14 <craftyguy> ah yes I see you asked about it earlier. oops
2021-09-04 06:56:44 <ikke> it's something that only affects the builder for some reason, cannot reproduce it in my container
2021-09-04 06:57:02 <craftyguy> the best kind of problem..
2021-09-04 06:57:25 <ikke> ahuh
2021-09-04 07:45:32 <hjaekel> ikke, I created !24965 to enable the failed test on netcdf again. My guess is that the test fails because there are dependencies between the tests, so I added -j 1 to ctest. But I cannot really test it locally, so can you give it a try on the builders?
2021-09-04 07:49:46 <ikke> hjaekel: will do
2021-09-04 08:22:42 <Ariadne> it was blocking more urgent things on the builders, which is why i disabled it
2021-09-04 08:23:17 <ikke> like libgit2 
2021-09-04 08:30:51 <mps> does samurai works with cmake, or we have to use ninja
2021-09-04 08:31:08 <ikke> afaik is samurai a drop-in replacement
2021-09-04 08:31:41 <mps> ok, lets try. clamav swithed to cmake
2021-09-04 08:33:20 <mps> btw, do anyone have guide or example how to switch pkg from autotools to cmake
2021-09-04 08:38:29 <ikke> 18fd2cfccaa056910c6742b25ab552f5b4798428
2021-09-04 08:40:25 <mps> ikke: thanks
2021-09-04 10:09:52 <mps> I've got X on rv64 in qemu on x86_64 host, awesome wm ofc ;)
2021-09-04 10:10:39 <ikke> nice
2021-09-04 10:11:52 <mps> thank you all who had a patience to fix all these pkgs on rv64
2021-09-04 10:29:58 <adhawkins> Hi all. I have a waiting MR for emborg 1.25, but emborg 1.26 has just been released. Is it Ok to modify the MR for the new version? It also introduces some new packages for dependencies required to run the tests.
2021-09-04 10:32:29 <ikke> adhawkins: yeah, should be fine
2021-09-04 10:34:16 <adhawkins> Ok, working on that now.
2021-09-04 10:45:45 <adhawkins> Ok, think that's done. Pushed the changes, CI tests just running now.
2021-09-04 10:47:37 <adhawkins> Ok, looks good. At least some of the architectures have successfully completed so all should be well.
2021-09-04 10:57:12 <adhawkins> ikke: Should I rename the branch? It's still called 'emborg-1.25' although the version is now 1.26
2021-09-04 10:57:26 <ikke> nah, does not matter
2021-09-04 10:58:04 <adhawkins> Ok cool. Thanks
2021-09-04 10:59:26 <adhawkins> Test has failed for armv7. That's a little odd...
2021-09-04 11:09:37 <adhawkins> Odd, retried it and it's completed this time.
2021-09-04 11:10:02 <adhawkins> All tests passed, looks good.
2021-09-04 11:10:08 <adhawkins> !24746
2021-09-04 13:15:28 <ikke> hjaekel: fyi, still fails with -j 1
2021-09-04 17:15:41 <maxice8> how can we do a whole-go-world rebuild for the CVE fixed in go1.17 ?
2021-09-04 17:17:04 <craftyguy> aarch64 builder is still stuck on gnuradio...
2021-09-04 17:17:22 <craftyguy> so you're not going to be rebuilding the whole world until that's unstuck :P
2021-09-04 17:18:41 <maxice8> riscv is also segfaulting itself (every time it sources an APKBUILD I assume)
2021-09-04 17:19:08 <craftyguy> ouch
2021-09-04 17:25:15 <mps> maxice8: riscv must be issue because its disk is full
2021-09-04 17:34:49 <maxice8> !24274
2021-09-04 17:49:46 <nmeum> maxice8: whole-world go rebuild is quite easy, just use ap revdep go to find packages which use go and bump their pkgrel with apkgrel(1)
2021-09-04 17:50:52 <maxice8> alright, gonna bump go and do that after aarch64 unstucks itself with gnuradio and riscv stops dying
2021-09-04 17:56:32 <nmeum> sounds like a plan
2021-09-04 17:56:59 <nmeum> we should also consider doing a go rebuild of the -stable branches, I think
2021-09-04 17:58:27 <maxice8> yes
2021-09-04 19:41:38 <maxice8> looking at ucto, forgot to add a dep
2021-09-04 19:53:38 <maxice8> algitbot retry master
2021-09-04 19:53:47 <maxice8> I forgot how to do it, help
2021-09-04 19:58:18 <mps> algitbot: retry master
2021-09-04 19:59:43 <maxice8> ty
2021-09-04 20:00:38 <mps> np
2021-09-04 21:26:43 <maxice8> under 300
2021-09-04 21:27:34 <ikke> 👍
2021-09-04 21:27:44 <ikke> fyi, tomorrow I'll be out for a week
2021-09-04 21:28:26 <Cogitri> ikke: Oh, you’re going on vacation too? :)
2021-09-04 21:28:33 <ikke> Yes
2021-09-04 21:29:12 <Cogitri> Neat, where to?
2021-09-04 21:29:24 <ikke> Staying in the Netherlands
2021-09-04 21:34:49 <Cogitri> Ah, neat nonetheless :)
2021-09-05 01:07:42 <craftyguy> is the aarch64 builder going to unstick itself at some point, or does the gnuradio update need to be reverted (or tests disabled on aarch64?)
2021-09-05 03:10:12 <andypost[m]> It needs to kick builder to make sure the same test hanging
2021-09-05 03:31:22 <craftyguy> the builder hasn't built any aarch64 packages for edge in over a day now
2021-09-05 04:10:51 <maxice8> algitbot: retry master
2021-09-05 04:15:44 <maxice8> algitbot: retry master
2021-09-05 07:52:46 <mps> just reading linux-next git log and I see that Paragon ntfs driver is merged as fs/ntfs3. good news for those who have to 'mount' windows disks
2021-09-05 09:02:44 <mps> anyone know how to set LDFLAGS for cmake? need to add -lfts for clamav
2021-09-05 09:04:47 <Cogitri> Setting the LDFLAGS variable should work (probably)
2021-09-05 09:05:33 <mps> hmm, worth to try. lets see
2021-09-05 09:09:38 <mps> didn't helped in clamonacc module
2021-09-05 09:17:17 <mps> heh, clamav devs uses alpine in docker to test it, and still I can't get it to build on alpine (except disabling clamonacc module as they do)
2021-09-05 09:17:32 <mps> funny life of pkg maintainers :)
2021-09-05 09:24:11 <nmeum> LDFLAGS is only picked up if the aport uses -DCMAKE_BUILD_TYPE=None
2021-09-05 09:25:39 <mps> ah, ok. but now I see the problem is upstream disabled clamonacc, don't know why but probably it has problem
2021-09-05 09:41:16 <mps> I got it to the point where I have installed it to pkgdir but I would like to 'give' it to someone who understand cmake, ofc if anyone are ready to take it
2021-09-05 10:16:29 <sircmpwn> what's the word on llvm12
2021-09-05 10:16:56 <skarnet> "no" should be the word
2021-09-05 10:17:15 <sircmpwn> what is the slightly more detailed than a single word on llvm12
2021-09-05 10:17:32 <skarnet> "hell no"
2021-09-05 10:17:48 <sircmpwn> I bet you've won an award for helpfulness
2021-09-05 10:17:53 <skarnet> multiple ones!
2021-09-05 10:18:45 <sircmpwn> consider a job in government
2021-09-05 10:19:21 <skarnet> I'd rather say yes to llvm12
2021-09-05 10:19:32 <ikke> sircmpwn: there was someone working on it here, but ran into some issues
2021-09-05 10:20:05 <ikke> Misthios: 
2021-09-05 10:22:13 <ikke> > Misthios │       Just some "smaller" parts are giving me a hard time
2021-09-05 11:23:36 <mps> timlegge: do you have objections to merge !25003
2021-09-05 11:24:29 <mps> actually, perl Cor, OO programming in 'new way'
2021-09-05 12:25:35 <Misthios> I was working on it just now (school started last week so had things to take care of)
2021-09-05 12:25:59 <Misthios> Will continue later today
2021-09-05 12:29:32 <mps> forget school (it is useless anyway) and work on free software ;)
2021-09-05 12:46:26 <Misthios> :O
2021-09-05 12:54:21 <mps> anyone have idea why clamav APKBUILD have check() function two times
2021-09-05 12:54:51 <mps> clandmeter: ^ you are maintainer
2021-09-05 14:23:04 <maxice8> should we set PYTHONHASHSEED=0 to make generation of .pyc reproducible ? pacman-makepkg now does it
2021-09-05 14:35:17 <AlpineLeo> for packages that don't produce libraries with sonames patchelf --set-soname can be used temporarily
2021-09-05 14:51:09 <mps> heh, /nick Alpine.mps
2021-09-05 14:51:33 <mps> better alpinist.mps :)
2021-09-05 16:06:22 <Misthios> is it possible to do manual tar in apkbuilds?
2021-09-05 16:07:09 <Misthios> since libcxx wants its abi in the same root folfder, as wall as the llvm source tar for the cmake file :(
2021-09-05 16:08:59 <toniz4> hello, there is any way to skip the build part of an APKBUILD? I'm trying to build a large package, and it keeps failing in the package() fase, but everytime I have to build it to reach package()
2021-09-05 16:16:25 <Cogitri> Left immediately, that’s unfortunate
2021-09-05 16:56:36 <hjaekel> Hi Leo thanks for trying my fix for netcdf, but I think it failed, right? I have one more idea, can we try it?
2021-09-05 16:58:39 <maxice8> ok
2021-09-05 16:59:01 <hjaekel> OK, I will prepare the PR
2021-09-05 17:00:21 <maxice8> ping me
2021-09-05 17:48:20 <hjaekel_> maxice8, this is my final try for fixing the test: !25013
2021-09-05 18:37:24 <adamplumb> what would make my pulseaudio package keep getting purged in favor of pipewire?  I'm running pmOS and just about every day i run apk upgrade and it re-installs pulseaudio and purges pipewire.
2021-09-05 18:46:01 <dalias> uhg
2021-09-05 18:46:11 <dalias> can you add a constraint to world to ban pulseaudio?
2021-09-05 18:46:19 <dalias> then you'd see what's conflicting with that constraint
2021-09-05 18:54:23 <adamplumb> how do i add such a constraint?
2021-09-05 18:55:31 <mps> by creating metapackage?
2021-09-05 18:56:37 <dalias> also once pulseaudio does get installed..
2021-09-05 18:56:48 <dalias> you should be able to use apk info to query what is pulling it in
2021-09-05 18:57:06 <dalias> but imo it's stupid that installing pa can purge pipewire
2021-09-05 18:57:16 <dalias> pipewire should conflict with and preclude installation of pa itself
2021-09-05 18:58:06 <mps> and both should conflict with alpine-base ;)
2021-09-05 19:06:28 <mps> what are problems with llvm12 and batteries? (tempted to put my fingers again in this 'mud')
2021-09-05 19:13:09 <mps> hmm, something called libcxx is needed first, I see in !24526
2021-09-05 19:13:50 <mps> could this be added separately?
2021-09-05 19:29:15 <Misthios> mps libcxx likes to be a bitch
2021-09-05 19:30:19 <Misthios> Got it building manually this way: download src for llvm,libcxx,libcxx abi , extract them, cd into llvm run cmake with enable projects libcxx,libcxxabi
2021-09-05 19:30:32 <Misthios> Got stuck finding out how to do all that in the apkbuild
2021-09-05 19:30:42 <mps> ah
2021-09-05 19:30:53 <mps> I thought it is separate pkg
2021-09-05 19:31:02 <Misthios> It kinda is
2021-09-05 19:31:23 <Misthios> But llvm-unwind needs it, and lld requires llvm-unwind
2021-09-05 19:31:52 <mps> ok, but could the libcxx build independently of those rest
2021-09-05 19:32:16 <Misthios> Libcxx wont build outside of a monorepo with libcxxabi
2021-09-05 19:32:29 <mps> ahm
2021-09-05 19:32:39 <mps> (I knew it is mud again)
2021-09-05 19:32:47 <Misthios> See, fun right
2021-09-05 19:33:15 <mps> uhm, no, I would not put my fingers there
2021-09-05 19:33:22 <Misthios> Void just threw everything in 1 go and every sub package seems like a symlink to llvm package
2021-09-05 19:33:34 <mps> better to waste time on some more important things
2021-09-05 19:33:40 <Misthios> ^
2021-09-05 19:34:37 <Misthios> Im gonna try to spend some more time tmr evening or something. But even if im to late for 12 we still need those changes for 13
2021-09-05 19:40:38 <Hello71> the proper alpine way is probably to build everything together and then just do subpackages
2021-09-05 19:41:14 <Hello71> splitting it up is only useful if you want to pick and choose which ones to build, so basically just gentoo
2021-09-05 19:45:24 <mps> uh, yet another reason to not PFM (put fingers in mud) tm
2021-09-05 19:46:01 <mps> earlier we built all these batteries as separate pkgs
2021-09-05 19:47:09 <Misthios> Yup
2021-09-05 19:47:39 <Misthios> But that was before upstream made the changes regarding the building
2021-09-05 19:47:56 <mps> wait, it is still separate on llvm.org
2021-09-05 19:48:26 <Misthios> Yes?
2021-09-05 19:49:12 <mps> no, I see on GH
2021-09-05 19:49:17 <mps> :(
2021-09-05 19:50:29 <mps> hm, https://github.com/llvm/llvm-project/releases/download/llvmorg-12.0.1/libcxx-12.0.1.src.tar.xz
2021-09-05 19:50:51 <mps> confusing
2021-09-05 19:52:23 <mps> hmhm, 'It is possible to build libc++ standalone (i.e. without building other LLVM projects). A standalone build would look like this:'
2021-09-05 19:52:35 <mps> on https://releases.llvm.org/12.0.1/projects/libcxx/docs/BuildingLibcxx.html
2021-09-05 19:56:13 <Misthios> Yeah thats what i found
2021-09-05 19:56:26 <Misthios> Just got stuck trying to do that in a apkbuild
2021-09-05 19:57:15 <Misthios> Or is git prefered over the src tar balls
2021-09-05 20:11:04 <mps> no, tarballs always preferred 
2021-09-05 20:29:29 <Hello71> hm, looks like arch has it separate: https://github.com/archlinux/svntogit-community/blob/packages/libc%2B%2B/trunk/PKGBUILD
2021-09-05 20:29:37 <Hello71> although libcxx and libcxxabi still together
2021-09-05 21:26:16 <heyitscassio> hello, i'm trying to make a APKBUILD for librecad, but they don't have a install target in their Makefile, there is a better way of doing this? Here is the apkbuild: https://0x0.st/-wTV.txt
2021-09-06 02:20:35 <Hello71> heyitscassio: mostly ok, fix your global variable formatting and do install -d $pkgdir/usr/share/librecad; install -m644 unix/resources/* $pkgdir/usr/share/librecad/
2021-09-06 02:24:22 <Hello71> aports expects busybox sh, so _pkgver=${pkgver/_/-}
2021-09-06 02:24:56 <Hello71> and i'm pretty sure package function already cds to builddir so you don't need to specify it
2021-09-06 06:10:16 <ncopa> good morning
2021-09-06 06:10:35 <caskd> o/
2021-09-06 06:13:57 <mps> good morning
2021-09-06 06:17:58 <mps> ncopa: any objection to merge !24869 it works few days on my workstation, and I didn't noticed any 'issue' (what a 'term')
2021-09-06 06:18:25 <ncopa> it says draft?
2021-09-06 06:18:49 <ncopa> I interpret "draft" as "not ready, do not merge yet"
2021-09-06 06:19:04 <mps> sure, to not risking someone 'nervous' to merge it before your amend
2021-09-06 06:19:30 <ncopa> ok. I 'll have a look at it in a bit
2021-09-06 06:19:43 <ncopa> looks like they no longer use autoconf?
2021-09-06 06:19:50 <mps> right
2021-09-06 06:20:32 <mps> configure looks like autoconf but it is not 'autoconf', as you noticed
2021-09-06 06:35:53 <ncopa> only suggestion I have is to replace `./configure` with `make config` or removed it completely. To reduce the risk someone thinking it is autoconf by mistake: "oh are we removeing the --prefix now? cool I'll do so with my own autconf packages as well then..."
2021-09-06 06:37:23 <mps> ok, will do later
2021-09-06 06:37:46 <mps> thanks for reviewing it
2021-09-06 06:39:30 <mps> I just merged 'eiwd', iwd pkg which don't need dbus, for those who run iwd on small and simple SBCs with not much RAM and CPU power
2021-09-06 06:40:08 <mps> but it has to be configured 'manually'
2021-09-06 06:42:30 <fcolista> kunkku, is there any way to explicitly tell to awall to put the rules in a custom-name chain?
2021-09-06 06:42:31 <fcolista> https://docs.docker.com/network/iptables/
2021-09-06 06:43:07 <fcolista> i want to add all rules in DOCKER-USER chain (otherwise we have race condition where iptables are overwritten by docker)
2021-09-06 07:14:39 <mps> ncopa: alpine 3.15 will be released around same time when kernel 5.16 will be released (my crystal ball says)
2021-09-06 07:15:09 <mps> and I think 5.16 will be next long term stable
2021-09-06 07:16:26 <mps> so, my thinking is that 'we' (actually you) should consider to switch to 5.16 even if it be 5.16-rcX at the time of alpine release
2021-09-06 07:18:50 <mps> (and ofc, on time of alpine release 'Carthago delenda est', i.e. pa and pw)
2021-09-06 07:18:55 <mps> :D
2021-09-06 07:27:35 <ncopa> do you have any documentation claim ing 5.16 be next lts? my crystal ball says its gonna be 5.15
2021-09-06 07:27:49 <ncopa> https://www.kernel.org/category/releases.html
2021-09-06 07:28:24 <mps> well, right, clashes of crystal balls
2021-09-06 07:28:46 <mps> 5.15-rc1 will be next monday
2021-09-06 07:29:16 <mps> so, 5.16 will be in november I expect
2021-09-06 07:29:40 <mps> 5.16-rc1 I mean
2021-09-06 07:30:07 <caskd> already time for 5.15?
2021-09-06 07:30:14 <caskd> damn, time passes quick
2021-09-06 07:31:04 <mps> so I expect that 5.16 final will be released after we release alpine 3.15
2021-09-06 07:32:11 <mps> yes, this all is 'Monte Carlo' method, so not sure what to propose, tbh
2021-09-06 07:32:23 <clandmeter> leave me out of it please
2021-09-06 07:32:39 <mps> :)
2021-09-06 07:38:27 <mps> anyway, 'official' crystal ball http://phb-crystal-ball.org/
2021-09-06 11:52:30 <mps> could someone explain to me dependencies inheritance in subpkgs?
2021-09-06 11:53:23 <mps> community/linux-tools tmon subpkg depends on cpupower subpkg for example
2021-09-06 11:53:35 <mps> I don't understand why
2021-09-06 11:55:45 <mps> and how 'make' tmon to not depend on subpkgs about it in APKBUILD
2021-09-06 11:57:45 <mps> hmm, I need more coffee :) depends=""
2021-09-06 12:26:32 <kunkku> fcolista: have you tried { "variable": { "awall_dedicated_chains": true } } ?
2021-09-06 12:33:40 <fcolista> no, is it documented somewhere?
2021-09-06 12:37:21 <kunkku> https://gitlab.alpinelinux.org/alpine/awall#co-existence-with-other-firewall-management-tools
2021-09-06 12:37:46 <fcolista> <3 gr8. Thx kunkku 
2021-09-06 12:59:36 <fcolista> ok, so this add awall-* to all the rules that awall creates. Still, awall  activate -f flushes all the rules.
2021-09-06 13:00:07 <fcolista> so i have to restart docker to get the correct iptables rules 
2021-09-06 13:00:23 <fcolista> (which, in turn, doesnt' flush twhat is in iptables)
2021-09-06 13:01:19 <fcolista> I don't know if there's a way to tell iptables that all awall-* rules should go into DOCKER-USER chain. 
2021-09-06 13:01:29 <fcolista> ..going to investigate..
2021-09-06 13:10:31 <fcolista> ok gotcha. Thanks kunkku now I got the point. Whant that variable is set, awall activate -f does not flush all the iptables rules. Just the one with awall- prefix 
2021-09-06 13:10:58 <fcolista> so just adding that rule is enough.
2021-09-06 13:11:07 <fcolista> s/rule/variable 
2021-09-06 13:48:39 <ericonr> do I need to rebase !24960 before merging?
2021-09-06 14:03:08 <mps> yes but that should be done by someone who merges it
2021-09-06 14:04:21 <mps> ericonr: oh, you mentioned me there (: will look later I'm really busy now
2021-09-06 14:05:07 <mps> ah no, my 'thumbs up' is there
2021-09-06 14:06:46 <ericonr> ok, will wait. and yeah, I didn't mention you myself :p
2021-09-06 14:20:27 <ncopa> ericonr: merged. thanks!
2021-09-06 14:25:52 <heyitscassio> What is the process to translate wiki pages? I'm a portuguese speaker and I'm intrested in contributing in some way to alpine 
2021-09-06 14:28:00 <ericonr> ncopa: nice, thanks!
2021-09-06 14:35:53 <Ariadne> btw thanks to clandmeter or whoever fixed the riscv64 builder
2021-09-06 14:35:54 <Ariadne> :)
2021-09-06 15:14:13 <ncopa> heyitscassio: i dont think we have any process for that, sorry
2021-09-06 16:08:28 <heyitscassio> ncopa: it's fine, there is other stuff to work on too
2021-09-06 16:11:01 <mps> I've built usbip utils in linux-tools pkg, i.e. 'integrate' it in linux-tools subpkg
2021-09-06 16:11:53 <mps> question is should we rename usbip to linux-tools-usbip or keep as usbip
2021-09-06 16:32:41 <Hello71> pls no
2021-09-06 16:34:33 <mps> Hello71: what 'no'?
2021-09-06 16:35:16 <Hello71> i don't want to apk add linux-tools-usbip libutil-linux0-dev
2021-09-06 16:36:30 <mps> but you have linux-tools-gpio and linux-tools-iio already
2021-09-06 16:37:21 <mps> and linux-tools-dev (as a bonus)
2021-09-06 16:41:49 <Hello71> :|
2021-09-06 16:42:55 <Hello71> debian doesn't even have iio: https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=lsiio
2021-09-06 17:04:31 <clandmeter> Ariadne: yw
2021-09-06 17:56:10 <mps> Hello71: what is your proposal? to keep two aports in future
2021-09-06 17:56:23 <Hello71> huh?
2021-09-06 17:58:20 <mps> that way I 'integrated' previously separate cpupower pkg
2021-09-06 20:35:13 <libsys> Hello all :) I've been using Alpine for a lot of time for containers and my Pinephone, and I'm considering moving most of my workflow to it. I do use desktop, servers and use and promote self-hosted solutions on cheap ARM SOCs, I'm an activist so its important to focus my work on things I can recommend. But I have mainly 2 points that make me wonder if I should move to Alpine.
2021-09-06 20:35:15 <libsys> 1. is that apparently there's no libre linux kernel option to use, are you interested in this package?... it seems like the project owners are concerned with software freedom since they have a non-free repo, so, if there were a linux-libre package, would the project consider to offer this kernel as default option? 2. Is the support for ARM SoCs stable enough as to build projects
2021-09-06 20:35:17 <libsys> based on this? I've efforts to deprecate its support in the past. 
2021-09-06 20:36:25 <libsys> * I've seen efforts to deprecate...
2021-09-06 20:36:52 <mps> kernel, libraries and tools are not stable but 'as is'
2021-09-06 20:37:54 <mps> else what will do bug hunters, die from bore
2021-09-06 20:39:11 <mps> reality is, after more than 30 years I still didn't see software which is bug free
2021-09-06 20:40:15 <mps> and arm SOCs/SBCs are buggy like a '$use_preferred_word'
2021-09-06 20:41:33 <mps> but despite all this I run servers, routers, appliances, workstations on alpine linux and I'm quite fine with this
2021-09-06 20:43:08 <libsys> (indeed I intended to say SBCs when I spelled SOCs, sorry)
2021-09-06 20:43:59 <libsys> yeah... my worry is that eventually Alpine just drops support for ARMv7-
2021-09-06 20:44:22 <mps> sure evidence that God exists is the 'thing' that all this somehow still works ;)
2021-09-06 20:45:14 <mps> we don't plan to drop armv7 in foreseeble future
2021-09-06 20:45:50 <mps> even we plan to 'keep' armhf till 2026 if possible
2021-09-06 20:46:27 <minimal> libsys: why armv7 specifically? I'd assume most modern SBCs can run aarch64
2021-09-06 20:46:51 <libsys> there's still a lot of armv7 around
2021-09-06 20:47:00 <mps> but my hope is that riscv will 'destroy' arm
2021-09-06 20:47:39 <libsys> me too :) but that's a few years ahead at least
2021-09-06 20:47:52 <Cogitri> libsys: I'm not sure if we want another kernel flavour, since maintaining a kernel and all 3rd party modules is a lot of work because we dont do DKMS
2021-09-06 20:48:00 <libsys> (most probably a ton)
2021-09-06 20:48:13 <Cogitri> (Also I sure hope the new IRC bridge resolves nicknames correctly)
2021-09-06 20:48:26 <mps> Cogitri: we have AKMS, thanks to jirutka
2021-09-06 20:48:46 <mps> Alpine KMS
2021-09-06 20:49:01 <Cogitri> Oh, there is? Neat, I have to admit I missed that
2021-09-06 20:49:34 <mps> yes, he made it just in week when I prepared DKMS for alpine :)
2021-09-06 20:49:49 <mps> and I'm happy because of this
2021-09-06 20:50:04 <mps> I don't have to maintain dkms
2021-09-06 20:51:09 <mps> and yes, as Cogitri says we don't want to maintain yet another kernel flavor
2021-09-06 20:51:40 <libsys> ):
2021-09-06 20:54:36 <mps> libsys: but we will support arm in future
2021-09-06 20:55:46 <mps> I'm running nearly all my things on arm32 and arm64
2021-09-06 21:00:09 <libsys> Sincerely I don't have any experience with linux kernel maintenace, but I'll do some testing with linux-libre and alpine. If I were able to make that work and pay attention to its maintenance, would you consider to include the package? (and help me with my doubts, hehe) 
2021-09-06 21:04:58 <mps> we have kernel team and TSC but I doubt it will be accepted
2021-09-06 21:05:57 <mps> you can always build it in your local repo and use it (as I do for some kernel flavors)
2021-09-06 21:06:47 <mps> for example I have local linux-rc, you guess what is it
2021-09-06 21:07:36 <mps> officially supported kernel is linux-lts only
2021-09-06 21:12:01 <libsys> Yeah, but my thing has more to do with being able to recommend Alpine rather than using the linux-libre kernel really... For what I see on the project there's a concern regarding software freedom, so I think probably it would be well accepted by more than a few 
2021-09-06 21:13:22 <mps> software freedom doesn't exists
2021-09-06 21:13:57 <libsys> tell that to the non-free repo xd
2021-09-06 21:14:38 <mps> you know that arm64 cpu have another cpu in it, and not much people doesn't know this
2021-09-06 21:15:13 <mps> s/not//
2021-09-06 21:16:07 <mps> non-free is just to 'fake' people to think that rest is free :)
2021-09-06 21:16:40 <libsys> well... I appreciate your answers mps, and I respect that you have your opinion regarding the software freedom, but that's not what I'm looking for
2021-09-06 21:17:00 <libsys> IDK, I've never reached Alpine devs before... I'll be around here waiting for someone to say that a linux-libre kernel would be an acceptable package for Alpine and start working if that happens..
2021-09-06 21:18:10 <mps> libsys: :)
2021-09-06 21:19:34 <ericonr> a kernel that blocks fw udpates isn't great from a security perspective
2021-09-06 21:20:57 <mps> ericonr: but it is quite 'good' for people with little experience in security ;)
2021-09-06 21:26:41 <libsys> not knowing what the firmware does isn't great for security neither
2021-09-06 21:27:35 <libsys> in any case, linux-libre about a political stance, not security
2021-09-06 21:28:12 <libsys> *is about
2021-09-06 22:20:35 <minimal> libsys: and the proposed linux-libre would be what what exactly? linux-lts without firmware? the (majority) of firmware is in separate packages so you could just install linux-lts plus linux-firmware-none
2021-09-06 22:21:26 <minimal> libsys: also how many SBCs would work without some form of firmware, typically for the onboard graphics?
2021-09-06 23:53:41 <libsys> minimal: nice, I had no idea of the existence of linux-firmware-* packages... if indeed there's no blobs on the default kernel, that is exactly what I was expecting :D
2021-09-06 23:56:21 <minimal> libsys: not sure if there are any. Normally installing the linux-lts package drags in all the various firmware packages as deps whereas if you install linux-firmware-none at the same time it doesn't automatically drag them in (you can still decide to manually install specific ones if you wanted). e.g. for some PCs I have with AMD graphics I install linux-firmware-none plus linux-firmware-amd (or radeon or whatever)
2021-09-06 23:58:15 <minimal> its possible there may be some hex "tables" in some of the kernel drivers themselves which some might consider a form of firmware but not sure. For the SBCs you use what graphics chip do they have?
2021-09-07 00:00:17 <libsys> minimal: IDK which boards would work without proprietary firmware... AFAIK the olinuxino variants do, since debian runs smoothly on these without enabling the non-free packages
2021-09-07 00:00:54 <libsys> I use 2 onlinxino lime2
2021-09-07 00:02:17 <minimal> its Mali (Arm's own) graphics
2021-09-07 00:02:29 <minimal> so I think the Linux driver is reverse engineered for that
2021-09-07 00:04:12 <minimal> seems like there's both proprietry and open drivers for that: https://wiki.debian.org/MaliGraphics
2021-09-07 00:05:05 <libsys> noice
2021-09-07 00:05:53 <minimal> not fully featured though: "Hardware video acceleration is not within the scope of the Panfrost or Lima drivers"
2021-09-07 00:07:29 <minimal> looking at the Alpine kernel-lts config file I see:
2021-09-07 00:07:30 <minimal> # CONFIG_DRM_LIMA is not set
2021-09-07 00:07:30 <minimal> # CONFIG_DRM_PANFROST is not set
2021-09-07 00:07:46 <minimal> so someone would need to raise a MR to that to be enabled
2021-09-07 00:08:16 <minimal> in both the armv7 and aarch64 kernel config files
2021-09-07 00:08:19 <libsys> well... I use these boards as mini servers, so never had a problem with that... I've used xfce though, and it runs as expected 
2021-09-07 00:08:27 <libsys> (on debian)
2021-09-07 00:09:09 <minimal> depends on the debian kernel config I guess. Also without these it would probably fall back to a generic DRM/FB driver
2021-09-07 00:11:01 <minimal> actually the CPU on that board is 32bit armv7 only
2021-09-07 00:16:40 <libsys> yup... haven't found a recent board that works with arm64, allows HDD and works with a 100% free OS
2021-09-07 00:17:37 <tomalok> i'm trying to extract specific files from an APK using python3 urlopen and tarfile libs...  tar_obj.getnames() is only returning the .SIGN.RSA....pub file -- any hints?  (the apk tool may not be available on the system trying to do this)
2021-09-07 00:39:14 <minimal> tomalok: I normally unpack APK files using zcat abc.apk|tar xvf -
2021-09-07 01:36:12 <tomalok> minimal: i may have to resort to using the subprocess lib with system tar
2021-09-07 03:10:31 <Hello71> post your code
2021-09-07 03:20:53 <craftyguy> aarch64 and x86 builders have been stuck for a while on libtorrent-rasterbar :(
2021-09-07 03:22:42 <craftyguy> seems to happen a lot that builders get 'stuck', are they really stuck? and is that by design or is there some issue that y'all might need help figuring out/fixing?
2021-09-07 03:22:54 <craftyguy> 
ACTION unfamiliar with alpine's package build infra

2021-09-07 03:32:27 <dalias> it's a silly issue that goes unfixed :/
2021-09-07 03:32:42 <dalias> need a watchdog to kill builds not making forward progress
2021-09-07 03:32:58 <dalias> probably it's broken testcases with bugs/UB that make them infinite loop
2021-09-07 05:02:51 <craftyguy> yeah, I guess I'm wondering if help is needed to make some watchdog to do that?
2021-09-07 05:02:57 <tomalok> minimal, hello71: https://pastebin.com/UGAkhPhJ
2021-09-07 05:08:50 <mps> libsys: there is also linux-edge kernel where panfrost is enabled for aarc64 and lima driver enabled for armv7
2021-09-07 06:22:58 <alandiwix> ncopa: Hi. I hope this is the right place to ask. initramfs-init currently doesn't respect any kernel root mounting parameters if we specify "overlaytmpfs" mode. That results in kernel panic on boot on some setups like booting from non-root btrfs subvolume. I've provided a PR, would you kindly take a look?
2021-09-07 06:27:08 <ncopa> hi alandiwix, this is the right place to ask
2021-09-07 06:30:12 <ncopa> i can have a look when i get a chance. the current problem with mkinitfs prjoect is the lack of test suite
2021-09-07 06:38:50 <alandiwix> Ok, many thanks. Can't help with the test suite unfortunately, my shell/C magic skills are lacking.
2021-09-07 06:59:08 <ncopa> testsuite is non-trivial also
2021-09-07 07:21:01 <sircmpwn> cockroach presents a bit of a problem
2021-09-07 07:21:14 <sircmpwn> the package in testing should be moved to nonfree and probably renamed cockroach-bsl
2021-09-07 07:21:27 <sircmpwn> and I could make a package to replace it with the latest apache release
2021-09-07 07:21:36 <sircmpwn> but upstream EOL's each release before it becomes FOSS
2021-09-07 07:21:42 <sircmpwn> not a great situation in general
2021-09-07 07:28:16 <Ariadne> sircmpwn: bsl?
2021-09-07 07:28:30 <sircmpwn> business source license
2021-09-07 07:28:42 <sircmpwn> nonfree license which becomes another license some period after release, in this case Apache 2.0 and 3 years
2021-09-07 07:28:44 <Ariadne> oh, another one?
2021-09-07 07:28:48 <Ariadne> ugh :D
2021-09-07 07:28:54 <sircmpwn> well, at least it *does* eventually become free
2021-09-07 07:29:03 <sircmpwn> I don't have as much of a beef with this one as with some of the others
2021-09-07 07:29:17 <Ariadne> indeed, but if its non-free obviously its non-free
2021-09-07 07:29:30 <sircmpwn> conveniently putting your EOL date ahead of the OSS date is a bit shitty though
2021-09-07 07:30:32 <sircmpwn> I was going to move it to non-free and set up a package for testing which tracks the FOSS release, but I'm not sure if the latter is even a good idea given that they're always EOL'd on arrival
2021-09-07 07:30:47 <sircmpwn> might just move it to nonfree and wash my hands of it
2021-09-07 07:32:24 <Ariadne> with security hat on, i would rather not ship EOL'd software in alpine that is as complex as cockroach
2021-09-07 07:32:58 <Ariadne> because some CVE will come out and we will be scrambling to backport the fix to a 3 year old codebase
2021-09-07 07:35:17 <mps> to non-free and forget it
2021-09-07 07:36:19 <Ariadne> its a similar issue as berkeley db
2021-09-07 07:36:46 <Ariadne> to the best of our ability, we believe bdb5 to not be affected by the bdb6 CVEs, but who knows for sure on all of them
2021-09-07 07:39:51 <mps> wener: hi, would you mind to look !25061 iirc we talked about this idea some months ago
2021-09-07 07:40:04 <wener> ok
2021-09-07 07:47:41 <sircmpwn> https://lists.alpinelinux.org/~alpine/aports/patches/3648
2021-09-07 08:02:57 <wener> trying to build usbip, but my machine is working hard on building grpc, need some time.
2021-09-07 08:04:52 <mps> wener: no hurries, it is draft
2021-09-07 09:11:02 <Ariadne> sircmpwn: done, thanks for catching this
2021-09-07 09:11:51 <sircmpwn> cheers
2021-09-07 13:50:06 <mps> https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ officially released
2021-09-07 13:50:32 <minimal> mps: you beat me to it, was just about to post that
2021-09-07 13:51:08 <mps> minimal: ;)
2021-09-07 13:51:41 <jvoisin> the lack of digestible changelog is annoying.
2021-09-07 13:52:26 <mps> minimal: btw, to not install all linux-firmware-* it is enough to install just one needed, or as you noticed linux-firmware-none if no firmware is needed
2021-09-07 13:54:08 <minimal> wasn't sure if installing only 1 was sufficient, always like to install linux-firmware-non to make sure I don't get the full set installed, especially on a VM
2021-09-07 13:56:02 <mps> none is if you don't need/want any, installing just one of needed will purge rest
2021-09-07 13:57:02 <mps> ofc, more than one can be installed and just those installed will be kept and rest purged
2021-09-07 13:57:28 <mps> there is even linux-firmware-any to make more confusion
2021-09-07 13:58:33 <mps> but this are only for build kernels
2021-09-07 13:58:41 <mps> s/are/is/
2021-09-07 13:59:48 <mps> and yes, this should be analyzed for virt kernels
2021-09-07 14:27:45 <tomalok> minimal: looks like you snuck out before you had a chance to see https://pastebin.com/UGAkhPhJ (trying to extract ovmf firmware from the apks with python tarfile lib)
2021-09-07 14:29:46 <minimal> ah, that remind me that I need to look at "fixing" the OVMF/AVMF stuff as it needs to be packaged arch-independent
2021-09-07 14:30:25 <tomalok> that'd be nice, in theory i'd only need to download one APK then... ;)
2021-09-07 14:31:18 <minimal> I found this when trying to run qemu-aarch64 on a x86_64 with UEFI and realised there was no package with AVMF to install
2021-09-07 14:31:30 <mps> tar xf ovmf-0.0.201908-r0.apk usr/share/OVMF/QEMU_EFI.fd
2021-09-07 14:31:53 <mps> -O tar option could be of help
2021-09-07 14:32:17 <tomalok> yeah, shell tar works, but tarlib for some reason only extracts the signing keys
2021-09-07 14:32:28 <minimal> tomalok: why do you need to unpack it anyway? if you're on Alpine then install the package, if you're on another distro then install their equivalent package - unless you're hitting the cross-arch situation I mentioned
2021-09-07 14:32:46 <tomalok> i'm not guaranteed to be on alpine when i launch qemu
2021-09-07 14:33:13 <mps> tomalok: https://arvanta.net/alpine/install-aarch64-qemu/
2021-09-07 14:33:41 <tomalok> mps: does that include the ovmf firmware for UEFI?
2021-09-07 14:33:59 <mps> tomalok: yes, commented in script
2021-09-07 14:34:00 <minimal> tomalok: right, but when I run Alpine x86_64 images on Debian I have the Debian ovmf package installed, no need for the Alpine one
2021-09-07 14:34:29 <tomalok> no macOS/brew package for it, afaik
2021-09-07 14:35:04 <mps> tomalok: https://arvanta.net/alpine/install-armv7-qemu/ this one use debian ovmf on alpine host
2021-09-07 14:35:42 <tomalok> would rather source it from Alpine packages. ;)
2021-09-07 14:35:58 <mps> we don't have ovmf for armv7
2021-09-07 14:36:37 <tomalok> are there any cloud providers that have armv7 instances?  (afaik they're all just x86 and aarch64)
2021-09-07 14:36:41 <mps> I put comment about this in script
2021-09-07 14:37:04 <minimal> yeah it is confusing, on Debian (and I think upstream) the OVMF_CODE.fd file is for x86_64 only and the AAVMF_CODE.fd file is for aarch64 only
2021-09-07 14:38:07 <minimal> whereas (from memory) on Alpine the ovmf package contains OVMF_CODE.fd files on both aarch64 and x86_64 but on aarch the OVMF_CODE.fd file is really the AAVMF_CODE.fd file
2021-09-07 14:38:16 <mps> till we got all this on alpine I'm quite ok of using debian one
2021-09-07 14:38:20 <minimal> s/aarch /aarch64 /
2021-09-07 14:38:42 <tomalok> OVMF_FIRMWARE = {
2021-09-07 14:38:42 <tomalok> }
2021-09-07 14:38:42 <tomalok>     'x86_64':   '/usr/share/OVMF/OVMF.fd'
2021-09-07 14:38:42 <tomalok>     'aarch64':  '/usr/share/OVMF/QEMU_EFI.fd',
2021-09-07 14:39:14 <minimal> tomalok: is there UEFI support for armv7 (i.e. 32bit) in general?
2021-09-07 14:40:04 <mps> minimal: I think debian have it, I use it to boot armv7 iso in qemu
2021-09-07 14:40:36 <minimal> wasn't sure if it was ever part of the UEFI specs
2021-09-07 14:42:18 <tomalok> minimal: i just know enough about UEFI to get qemu working for x86_64 and aarch64 (mostly thanks to all o' youse)
2021-09-07 14:43:01 <minimal> ok, I see armv7 mentioned in UEFI 2.6 spec from 2016
2021-09-07 14:43:36 <tomalok> is there something special about the APK format that "separates" the signing keys from the other files?
2021-09-07 14:44:44 <minimal> tomalok: as mentioned, when using zcat|tar xvf to unnpack APK files I've always seen these messages in the output: "tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'"
2021-09-07 14:45:04 <minimal> I assume the Python lib you are using doesn't like this unknown header and stops processing the tarfile when it sees it
2021-09-07 14:46:18 <tomalok> (nod) that's probably the case...  i'll probably just dump the pure python approach and shell out for the extraction
2021-09-07 14:48:05 <minimal> you'll have more fun when APK3 is out as I believe it is using a different file format and not sure if it will be easy to unpack using standard tools
2021-09-07 14:50:06 <tomalok> yeah, thought about that as well... there design docs on APK3 somewhere I'd imagine?
2021-09-07 14:52:51 <minimal> not sure, maybe ask Ariadne?
2021-09-07 14:54:30 <PureTryOut> How can I request a change to the linux-lts kernel config? Just make a PR or ask ncopa directly?
2021-09-07 14:55:11 <minimal> raise a PR
2021-09-07 15:07:27 <mps> PureTryOut: create issue, you will have more chances then
2021-09-07 15:07:56 <mps> ncopa prefer to have history in issues
2021-09-07 15:08:50 <PureTryOut> Oh I already made the MR 😅 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25068
2021-09-07 15:09:16 <mps> this is also ok
2021-09-07 15:11:20 <mps> hmm, I see. though not sure it is ok to enable PSI by default
2021-09-07 15:13:09 <mps> iirc, someone already asked for it some time ago
2021-09-07 17:35:35 <Ariadne> hi
2021-09-07 17:35:43 <Ariadne> build-edge-x86 and build-edge-aarch64 are stuck
2021-09-07 17:35:48 <Ariadne> somebody please do the needful
2021-09-07 17:51:19 <Hello71> i think they've been stuck for a couple days now
2021-09-07 17:54:45 <Misthios> mps im kinda thinking about stopping with llvm12 since 13 will come out around the end of the month. So im gonna close my mr and gonna switch to trying to get 13 working on time
2021-09-07 17:54:56 <Misthios> as rc2 is tagged already
2021-09-07 18:02:31 <mps> Misthios: this could be to late for next alpine stable
2021-09-07 18:02:45 <Misthios> when is the next stable?
2021-09-07 18:03:11 <mps> at the beginning of december
2021-09-07 18:03:20 <Misthios> I might be able to just get 12 in and put 13 in edge since 12 and 13 are the same amount of work.
2021-09-07 18:03:42 <Misthios> or isnt that the right way?
2021-09-07 18:03:59 <mps> I think Cogitri[m] could tell more because he is maintainer
2021-09-07 18:04:52 <Cogitri> Ah sure
2021-09-07 18:05:06 <Misthios> so what should i do?
2021-09-07 18:05:26 <mps> I still didn't looked deeply at it, in hope that Misthios or Cogitri would take proper actions
2021-09-07 18:06:01 <Cogitri> I have to admit I havent looked at 13 yet due to vacation, so I'm not sure how many API breakages it brings along
2021-09-07 18:06:03 <mps> and I want to concentrate on next kernels and tools
2021-09-07 18:06:23 <Cogitri> So I'm not sure how many packages will work with LLVM13 already or at least have working patches around already
2021-09-07 18:06:53 <Misthios> yeah thats what im thinking about as well
2021-09-07 18:07:16 <Cogitri> But if we're OK with (temporarily?) disabling packages in edge that dont work with LLVM13 but need other LLVM packages like lang it wouldn't hurt to upgrade to LLVM13 directly
2021-09-07 18:07:31 <Cogitri> s/like lang/like clang/
2021-09-07 18:08:01 <Cogitri> Does algitbot not do corrections anymore or did I mess it up somehow? :D
2021-09-07 18:08:10 <Misthios> anyway what do u think is the best way to build libcxx (problem for both 12 and 13), 1: we download 3 tar files and extract them into a mono repo like layout for them to build. or we clone the repo to essentially get the same result
2021-09-07 18:08:49 <Misthios> because it wont build without being in a mono repo layout 
2021-09-07 18:09:05 <Cogitri> Cloning isnt an option so tarballs it is
2021-09-07 18:09:20 <Misthios> can we do manual untar and move etc in apkbuilds?
2021-09-07 18:09:25 <mps> to me (from somewhat outdated experience with llvm batteries) looks like llvm12 is proper candidate for alpine 3.15
2021-09-07 18:09:56 <Misthios> *prays that zig doesnt require 13 soon*
2021-09-07 18:10:36 <Ariadne> Hello71: well
2021-09-07 18:10:48 <Misthios> i got libcxx compling (or at least started building without complaining) in local folders but gotta figure out how to make a apkbuild do that
2021-09-07 18:10:53 <linearcannon> there is already an llvm13 branch for zig and they will be merging it probably as soon as llvm13 releass
2021-09-07 18:10:53 <Ariadne> Hello71: there are a ton of security updates that need to go out
2021-09-07 18:10:55 <Ariadne> so,
2021-09-07 18:11:02 <Ariadne> it'd be cool if they could get unfucked :D
2021-09-07 18:11:35 <Cogitri> Misthios: You can override unpack()
2021-09-07 18:11:47 <linearcannon> llvm13 would be nice for my m68k port, but i recognize that's not particularly important :)
2021-09-07 18:12:04 <Misthios> oh did not know that, ty
2021-09-07 18:12:18 <Hello71> ah, my mistake, they were previously stuck for a few days on gnuradio
2021-09-07 18:12:25 <Misthios> should spent some time to read lots more about apkbuild
2021-09-07 18:12:47 <mps> I think it would be nice to have llvm12 in git history even if 'we' use llvm13 for 3.15-stable
2021-09-07 18:12:48 <Hello71> Cogitri: it was alpine-meetbot but seems to be not here
2021-09-07 18:13:35 <Misthios> okay. 13 will require most of the work from 12 so might as well
2021-09-07 18:14:43 <mps> Misthios: https://github.com/archlinux/svntogit-community/blob/packages/libc%2B%2B/trunk/PKGBUILD could give some ideas
2021-09-07 18:15:25 <Misthios> way better as the void template
2021-09-07 18:15:27 <Misthios> ty
2021-09-07 18:16:20 <mps> also for llvm12 https://github.com/archlinux/svntogit-packages/blob/packages/llvm/trunk/PKGBUILD
2021-09-07 18:16:35 <Hello71> i think the only reason why they're split in arch is because libcxx is in community
2021-09-07 18:17:06 <mps> I think this is good idea to split all these
2021-09-07 18:17:58 <Hello71> yes, as subpackages, not as top-level packages
2021-09-07 18:18:22 <mps> huh, I disagree
2021-09-07 18:19:22 <mps> but this is on maintainer to decide
2021-09-07 18:19:24 <Hello71> what is the benefit of forcing them apart when not well supported upstream
2021-09-07 18:19:41 <Hello71> for gentoo it is because users may need to recompile components individually
2021-09-07 18:19:53 <Hello71> for arch libcxx is separate due to community repo
2021-09-07 18:20:05 <mps> maybe this applies also to alpine
2021-09-07 18:20:19 <Misthios> not everything from llvm is in main atm
2021-09-07 18:20:30 <Misthios> llvm-libunwind is community i believe
2021-09-07 18:20:51 <mps> and lld
2021-09-07 18:23:42 <Hello71> hm, i thought llvm-libunwind will be required for llvm, but i think only for libcxxabi with clang
2021-09-07 18:23:55 <Hello71> or is it compiler-rt?
2021-09-07 18:24:13 <mps> I think later
2021-09-07 18:26:05 <Misthios> lld needs libunwind which needs libcxx 
2021-09-07 18:26:07 <Misthios> i believe it was
2021-09-07 18:27:41 <Hello71> seems lld needs libunwind/include/mach-o
2021-09-07 18:28:05 <Misthios> ah yes that was it
2021-09-07 18:28:12 <Hello71> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/lld/lld-12.0.1.ebuild#n26
2021-09-07 18:28:24 <Hello71> it doesn't actually need it built
2021-09-07 18:30:13 <Misthios> so it just needs to src?
2021-09-07 18:30:16 <Misthios> the*
2021-09-07 18:34:23 <Hello71> that's what the ebuild says
2021-09-07 21:08:28 <mps> how we can get info about CVE just published in the wild
2021-09-07 21:08:34 <dalias> ?
2021-09-07 21:09:12 <mps> I received mail from debian-security ML about one new CVE and can't find it on net
2021-09-07 21:09:23 <dalias> in what software?
2021-09-07 21:09:29 <mps> haproxy
2021-09-07 21:10:17 <mps> and haproxy doesn't mention CVE though in changelog description is nearly same as in mail I received
2021-09-07 21:10:25 <dalias> :/
2021-09-07 21:10:36 <mps> CVE-2021-40346
2021-09-07 21:11:18 <mps> http://www.haproxy.org/download/2.4/src/CHANGELOG => BUG/MAJOR: htx: fix missing header name length check in htx_add_header/trailer
2021-09-07 23:57:59 <Ariadne> you can try https://security.alpinelinux.org/vuln/CVE-2021-40346
2021-09-07 23:58:04 <Ariadne> but if its not in the CVE database yet
2021-09-07 23:58:07 <Ariadne> it wont show up there
2021-09-08 00:52:07 <maxice8> openrc-0.44 released with meson
2021-09-08 01:03:19 <nzm> hi all, I was browsing the alpine packages and noticed that mingw-w64 has no active maintainer. I am not completely sure I have the energy or OSS experience to take this on, but it got me thinking
2021-09-08 01:04:48 <nzm> again I might not be ready to get directly involved, but I found the wiki very hard to follow as far as invitations for contribution. I've been using alpine for years and years and I absolutely love it, I would be very interested to know what ways people are being encouraged to get involved.
2021-09-08 01:26:28 <nzm> Oh right, if package maintenance is a consistent need, I do personally use mingw-w64 often :)
2021-09-08 02:13:16 <Ariadne> maxice8: thanks, i hate it
2021-09-08 02:13:28 <maxice8> You're welcome
2021-09-08 02:14:33 <maxice8> rofi-1.7.0 breaks pre-1.6.1 themes, should I add a pre-upgrade notice for people pointing to the official workarounds page ?
2021-09-08 02:20:56 <Ariadne> maxice8: looks like openrc 0.44 still has non-meson build system, so we are OK for now.
2021-09-08 02:21:28 <maxice8> for now but the changelog notes that is deprecated and will be removed in a future 0.44.x release
2021-09-08 02:22:33 <timetravelingman[m]> Hello, does anyone know who maintains the chromium package?
2021-09-08 02:22:39 <maxice8> and muon (meson in c) is too strict (or meson.build for openrc is too lax) and so it can't build it
2021-09-08 02:29:04 <JulianGro> timetravelingman[m]: "Natanael Copa" according to the package search https://pkgs.alpinelinux.org/packages?name=chromium
2021-09-08 02:29:32 <JulianGro> I don't know how to reach maintainers though.
2021-09-08 02:33:37 <Ariadne> maxice8: worst case, we fork openrc and restore the buildsystem
2021-09-08 02:33:56 <Ariadne> in the long term, s6-rc will be ready
2021-09-08 02:35:05 <maxice8> sounds good, moderately excited for s6-rc since I experimented with it a lot during my init learning phase
2021-09-08 04:07:00 <back-2-95> Any knowledge why git.alpinelinux.org gives 502 ?
2021-09-08 04:17:05 <nzm> I was getting an error code with a few alpine services earlier today (3h ago?), not sure if this is related. It might have been my internet but the server was resolving incorrectly for a few minutes. This is probably my internet being weird though.
2021-09-08 04:17:42 <nzm> I was getting a 404 on the mailing list archive website, but not alpine.org
2021-09-08 04:17:49 <nzm> then it resolved itself, so I have no idea
2021-09-08 04:18:05 <back-2-95> It has been giving me 502 from yesterday when I tried to access
2021-09-08 04:19:24 <back-2-95> All the links from https://alpinelinux.org/ or https://pkgs.alpinelinux.org/packages to git will result Nginx 502 Bad Gateway
2021-09-08 04:20:06 <nzm> this is the case for me as well
2021-09-08 04:22:53 <back-2-95> dunno who to contact so I sent a Tweet to them
2021-09-08 04:22:58 <nzm> I'm not involved in the project, but the infrastructure team might be more helpful in this
2021-09-08 04:23:02 <nzm> they're on this irc, one second
2021-09-08 04:23:14 <nzm> #alpine-infra
2021-09-08 04:24:13 <back-2-95> ok might pop there too - thanks
2021-09-08 05:32:02 <ncopa> timetravelingman[m]: i guess it is me who is the official maintainer
2021-09-08 05:44:31 <mps> Misthios: zig 0.8.1 released and looks like it will need llvm 12.0.1, not 13.0
2021-09-08 05:47:47 <Misthios> Nice
2021-09-08 05:48:12 <mps> and good morning
2021-09-08 05:48:19 <Misthios> U2
2021-09-08 05:49:12 <mps> 'U2', a famous airplane :)
2021-09-08 06:27:11 <xsteadfastx> in what package do i find the abuild linter?
2021-09-08 06:27:42 <andypost[m]> ncopa: please chech !25100 am I wrong with replace or ghc needs upgrade first
2021-09-08 06:28:18 <andypost[m]> Totally not clear why it does not work if I put it into community
2021-09-08 06:36:09 <ncopa> andypost[m]: i had a look at it last friday. i came as far as you. ghc fails for some reason, but i never had time to figure out why
2021-09-08 06:39:47 <andypost[m]> Thanks, then ghc is blocker
2021-09-08 06:43:39 <ncopa> yup
2021-09-08 07:36:09 <mps> oh no, kernel release again ;)
2021-09-08 07:36:38 <mps> we need a 'robot' to upgrade kernels
2021-09-08 07:46:45 <PureTryOut> Cogitri: any reason gtk+3.0 hasn´t upgraded to 3.24.30 yet? I got this bug where I get ´ instead of ' when using dead keys and it´s supposedly fixed in releases since 3.24.28
2021-09-08 07:57:20 <PureTryOut> for reference, the bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/3807, and the fix https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3387
2021-09-08 08:41:47 <Cogitri> PureTryOut: Just that I haven't gotten around to doing that yet
2021-09-08 08:51:59 <PureTryOut> In that case, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25116
2021-09-08 09:18:37 <Cogitri> PureTryOut: lgtm
2021-09-08 09:20:34 <PureTryOut> I can't merge it myself, no commit access to main
2021-09-08 09:21:46 <mps> community/libtorrent-rasterbar is stuck again on aarch64 and x86
2021-09-08 09:22:45 <Cogitri[m]> Oh
2021-09-08 09:35:33 <PureTryOut> Of course it is
2021-09-08 10:06:47 <adhawkins> Anyone comment on whether there's an issue with !24746, or is it just a question of waiting for someone to look at it?
2021-09-08 10:07:12 <adhawkins> Previous MRs of mine have generally been merged sooner than this. Don't mean it to sound like a complaint, just want to make sure I haven't done anything wrong with the MR.
2021-09-08 10:09:19 <PureTryOut> Some random newlines between variables, but it seems fine otherwise. I'll merge it
2021-09-08 13:42:55 <adhawkins> PureTryOut: Is that not recommended? I thought it made things more readable?
2021-09-08 13:43:07 <adhawkins> Would have happily changed it if you'd said before merging.
2021-09-08 13:43:12 <PureTryOut> I never seen it before
2021-09-08 13:43:44 <PureTryOut> I think you're the first to do it, so I doubt it's recommended lol
2021-09-08 13:44:08 <adhawkins> Ok, will try to remember to remove them next version.
2021-09-08 13:44:33 <adhawkins> Also, #alpine-commits says one of the builds failed, but the log (while it does contain errors) does seem to show a successful build.
2021-09-08 13:44:41 <adhawkins> https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/py3-nestedtext/py3-nestedtext-3.1-r0.log
2021-09-08 13:46:32 <adhawkins> PureTryOut: I'll do an MR to remove those various blank lines. Ok to do multiple commits, one for each package that it affects?
2021-09-08 13:46:39 <adhawkins> Or would it be better as multiple MRs?
2021-09-08 13:46:53 <PureTryOut> Oh no it's fine you don't have to change it, I was just noticing it
2021-09-08 13:47:06 <adhawkins> If I don't do it now, I'll probably forget next time. :)
2021-09-08 13:47:29 <PureTryOut> as for the build failure, it probably retried and succeeded the second time
2021-09-08 13:47:42 <PureTryOut> adhawkins: lol ok that's fine. It's ok to do it 1 commit
2021-09-08 13:49:43 <adhawkins> I'll do multiple commits, one for each package. But one MR for all the commits.
2021-09-08 14:02:47 <adhawkins> This look Ok PureTryOut? !25121
2021-09-08 14:07:24 <PureTryOut> Oh no, you don't understand. I said just the variables, not between the functions
2021-09-08 14:08:52 <adhawkins> Oh ok. I'll sort that then.
2021-09-08 14:10:19 <adhawkins> Should there be a blank line before the first function? (i.e. between the variables and the functions)
2021-09-08 14:11:25 <adhawkins> And how about between the last function and the checksums?
2021-09-08 14:13:03 <adhawkins> Looking at another random package, looks like there should be.
2021-09-08 14:16:18 <adhawkins> Ok, how's that PureTryOut?
2021-09-08 14:16:19 <adhawkins> !25121
2021-09-08 14:17:21 <PureTryOut> It's good now 👍️
2021-09-08 14:17:47 <PureTryOut> Oh although it didn't need a pkgrel bump. Oh well, that's fine
2021-09-08 15:00:44 <adhawkins> PureTryOut: Oh didn't it? I could have removed that. I assumed that it would because something had changed.
2021-09-08 15:02:11 <PureTryOut> The pkgrel only needs to be bumped when the package built from the APKBUILD will change. Removing some empty lines in the APKBUILD doesn't change the resulting package, so a bump wasn't needed
2021-09-08 15:06:48 <adhawkins> Understood PureTryOut. Will try to remember that in future.
2021-09-08 15:37:38 <ncopa> I reported libtorrent-rasterbar deaadlock upstream: https://github.com/arvidn/libtorrent/issues/6451
2021-09-08 15:42:49 <Hello71> ncopa: thread apply all bt is a thing
2021-09-08 15:43:47 <Hello71> :p
2021-09-09 05:14:12 <Ariadne> anyway, i am preparing openrc in alpine to be maintained the way we do gcc.  that will minimize the cost of maintaining the legacy build system.
2021-09-09 05:39:24 <mps> Ariadne: what that means? not follow upstream build changes?
2021-09-09 05:39:37 <Ariadne> correct, for now.
2021-09-09 05:39:45 <Ariadne> until muon can build openrc.
2021-09-09 05:40:12 <mps> ah, what is muon? new build system?
2021-09-09 05:40:19 <Ariadne> because to bring meson into bootstrap.sh is going to involve adding a *lot* of new packages
2021-09-09 05:40:35 <mps> auh
2021-09-09 05:40:56 <mps> s/auh/oof/
2021-09-09 05:41:01 <Ariadne> muon is a build tool that can interpret meson.build files, yes
2021-09-09 05:41:14 <Ariadne> but is very new, and lots of features are still missing
2021-09-09 05:42:08 <mps> ah, thanks for explanation
2021-09-09 05:43:00 <mps> nowadays 'every gay and his dog' invent build system
2021-09-09 05:43:08 <Ariadne> every what?
2021-09-09 05:43:24 <Ariadne> i assume you mean every guy and his dog
2021-09-09 05:43:25 <Ariadne> :p
2021-09-09 05:43:34 <mps> yes, sorry
2021-09-09 05:44:02 <mps> you know that I'm bad self teacher in english
2021-09-09 05:44:43 <Ariadne> anyway, some random person decided to argue with me over alpine bootstraps, which was fascinating
2021-09-09 05:44:54 <Ariadne> but i think WilliamH will keep the build system around
2021-09-09 05:45:04 <Ariadne> at least until muon can build openrc
2021-09-09 05:45:08 <Ariadne> if not, we maintain ourselves
2021-09-09 05:45:09 <Ariadne> nbd
2021-09-09 05:45:29 <mps> ok, I agree with you
2021-09-09 05:46:56 <mps> I'm not sure when we could switch to s6, if ever
2021-09-09 05:58:39 <Ariadne> 2023
2021-09-09 05:59:07 <Ariadne> though, presumably, we will need to support openrc for a while once s6 is ready, too
2021-09-09 05:59:21 <Ariadne> there are a lot of not yet answered questions :)
2021-09-09 05:59:46 <Ariadne> so, i think at the very least, openrc couldn't be retired until 2025 at the latest
2021-09-09 05:59:50 <Ariadne> er, earliest
2021-09-09 06:00:53 <Ariadne> that allows for introduction of testing versions in mid-2022, viable migration in 2023, and then a period where openrc remains supported for some time
2021-09-09 06:01:07 <Ariadne> this is of course assuming openrc still exists in 2022, 2023, or 2025
2021-09-09 06:03:00 <mps> too long time, imo
2021-09-09 06:06:14 <mps> btw, just noticed that dnsmasq APKBUILD has secfixes section at top of the file. should it be moved to be same as of most other pkgs
2021-09-09 06:07:59 <Ariadne> its so strange
2021-09-09 06:08:10 <Ariadne> alpine is most likely the largest deployment of openrc in reality
2021-09-09 06:08:30 <Ariadne> yet upstream has not been very cooperative
2021-09-09 06:10:22 <mps> my main 'fear' of s6 is the 'strong' temper of upstream
2021-09-09 06:18:57 <Ariadne> i think skarnet is a great upstream
2021-09-09 06:19:01 <Ariadne> better than gentoo :D
2021-09-09 06:30:22 <mps> I understand that smart and knowledgeable people have strong temper (else they will be average)
2021-09-09 06:32:01 <mps> but (sometimes) they should use more 'calm' language
2021-09-09 06:38:10 <Ariadne> i try not to have a strong temper
2021-09-09 06:39:49 <mps> :)
2021-09-09 06:41:05 <mps> you are quite fine in last time (remembering our clashes few times ;) )
2021-09-09 06:41:42 <mps> times or time, not sure of proper term
2021-09-09 06:42:16 <mps> and now is is pleasure to talk with you even when we disagree
2021-09-09 06:42:43 <Ariadne> well i had to rip on some dude for mansplaining my own work to me earlier
2021-09-09 06:42:52 <Ariadne> and gentoo people got mad about it :p
2021-09-09 06:48:36 <nzm> :) hi all, I brought this up earlier but it got lost in scrollback (or ignored, if there's a better place this should go let me know): I've been using alpine for a number of years, and am trying to understand what opportunities there are for getting involved. I saw mingw-w64 has no active maintainer and I am a regular user of this.
2021-09-09 06:49:25 <nzm> However I also have no experience being part of a linux distro, the most relevant experience I have to this sort of organization is union work, honestly.
2021-09-09 06:49:59 <nzm> where the bulk of activity is administrative, but requires technical skills (tech committee)
2021-09-09 06:50:40 <nzm> but to reiterate I have no clue what options there are to get involved, so I don't even know if my tech-comm work is relevant here.
2021-09-09 06:54:47 <nzm> My past experience involved system maintenance, but a lot of my hobbies involve programming. I also feel I am decent at writing documentation but organizing the wiki would be difficult for me to take on as I'm fairly new to the IRC and don't have a good understanding of what users are looking for in it.
2021-09-09 07:05:59 <maxice8> How are the builders ? I wanna do the go1.17 security upgrade + go-world rebuild
2021-09-09 07:07:10 <maxice8> if successful do it on 3.14
2021-09-09 07:09:29 <mps> nzm: alpine is not (still) strongly organized with a lot of steering document/rules
2021-09-09 07:10:31 <mps> nzm: whatever you can and/or want to do is good for alpine
2021-09-09 07:11:18 <nzm> :D that's sort of what I'm afraid of! I don't know what all options there are. I'm having discussions with a friend who volunteers with Debian and they might be able to help me figure out where to go.
2021-09-09 07:11:21 <mps> you say you are good in writing docs and this is where alpine need help
2021-09-09 07:12:19 <mps> regarding wiki, it is in some kind of abandoned state
2021-09-09 07:12:55 <mps> docs.alpinelinux.org is the space where we should concentrate more
2021-09-09 07:14:10 <mps> helping users on #alpine-linux (if you have strong nerves :) ) also is of the help for alpine
2021-09-09 07:14:13 <nzm> ooh, I wasn't aware of the docs.alpinelinux.org site, I'm reading through it now. It's a very different focus to the wiki
2021-09-09 07:14:42 <nzm> I've had a few conversations on the main channel, mostly just words of encouragement haha so nothing that helpful yet
2021-09-09 07:15:07 <mps> anything you do for alpine is good and means you are already involved
2021-09-09 07:15:57 <nzm> the docs site reminds me of more formal documentation provided by redhat and the like, which sparks some ideas for me
2021-09-09 07:16:20 <mps> and we are not like debian, there is no formal process for involvement, alpine is more meritocracy
2021-09-09 07:16:37 <Ariadne> maxice8: go for it
2021-09-09 07:16:40 <kevint> nzm if you are also interested in creating or learning more about alpine packages, https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package and https://wiki.alpinelinux.org/wiki/APKBUILD_Reference are your friends :)
2021-09-09 07:17:12 <maxice8> Ariadne: ight
2021-09-09 07:17:46 <Ariadne> nzm: if you know how to build mingw-w64, then help would be appreciated there
2021-09-09 07:18:09 <mps> nzm: I would be grateful if you improve my notes about some things in alpine here https://arvanta.net/alpine/ ;)
2021-09-09 07:18:52 <nzm> :) meritocracy has its downsides but things seem stable so far, you're not full of jerks.. it seems! I'm just mulling over things and I'm not promising this, but the first thing that jumped to mind for docs is https://docs.fedoraproject.org/en-US/Fedora/24/html/Networking_Guide/ch-Configure_Networking.html
2021-09-09 07:19:11 <nzm> sorry for long link, but this sort of long-winded explanation rather than "type this and pray that it works"
2021-09-09 07:19:59 <nzm> was helpful for me learning things, for sure! I'll mull things over further and get back to y'all! It's super late for me and I should be going to bed
2021-09-09 07:21:50 <nzm> Ariadne: I do not know how to build mingw-w64 but I can try things out and get back to you, as with all the above no promises but I've written it into my notes to look into
2021-09-09 07:24:53 <mps> nzm: you can always ask here for help
2021-09-09 07:26:10 <nzm> absolutely, I intend to :) I'm glad I was able to talk to y'all, I'll look into the build process on mingw-w64 compiler suite and think about what sorts of documentation I can contribute.
2021-09-09 07:27:09 <nzm> (that was two separate thoughts, I missed a comma).. s/and think/and also think/
2021-09-09 07:37:20 <maxice8> so many aports are rebuilt that my git-hooks to lint my changes choke
2021-09-09 07:43:43 <maxice8> and produce funny unexpected results
2021-09-09 07:43:58 <maxice8> like saying files X are missing from a package that doesn't even have them in source=
2021-09-09 07:50:43 <maxice8> s390x failed to build go
2021-09-09 07:53:30 <linearcannon> is there a defined process for getting things from testing into community
2021-09-09 07:55:22 <mps> linearcannon: two years ago it was rule to wait one release cycle (at least) but nowadays if it builds it is moved on request (MR)
2021-09-09 07:55:49 <mps> (however useless pkg is)
2021-09-09 07:56:32 <mps> but I still think we should not move pkgs which don't have devoted maintainer
2021-09-09 07:56:44 <linearcannon> in the case of this package i would be volunteering as maintainer
2021-09-09 07:56:52 <linearcannon> and technically am already listed, on an old email i don't want to use...
2021-09-09 07:57:18 <mps> are you maintainer? and which pkg?
2021-09-09 07:57:37 <linearcannon> testing/windowmaker
2021-09-09 07:59:58 <mps> surprised that it is still used by someone (I used it for some time, long time ago)
2021-09-09 08:00:10 <linearcannon> i use it on several of my older machines
2021-09-09 08:00:30 <linearcannon> i also have some side projects which use its WINGs library (and so depend on windowmaker-dev being installed)
2021-09-09 08:00:50 <mps> ok, you can create MR, and change you mail if it is changed
2021-09-09 08:06:18 <kunkku> I also think xfce is bloatware...
2021-09-09 08:09:30 <mps> kunkku: I agree, and after few years of trying even persuaded my wife to use awesome wm :)
2021-09-09 08:11:12 <linearcannon> merge request made !25151
2021-09-09 08:12:18 <mps> linearcannon: 'and add myself as maintainer' part should be in commit description, not in commit msg
2021-09-09 08:13:43 <linearcannon> changed
2021-09-09 08:14:20 <mps> though I would write 'change mainter mail address' with saying you are previous maintaner.
2021-09-09 08:14:31 <linearcannon> for personal reasons i would prefer not to
2021-09-09 08:14:42 <mps> and would be nice to add your real name in maintaner
2021-09-09 08:15:58 <mps> I don't trust people who hide their real identities
2021-09-09 08:16:42 <andypost> Ariadne, as I got new package should be main/openssl-compat like libusb-compat
2021-09-09 08:16:57 <Ariadne> openssl1.1-compat
2021-09-09 08:17:05 <psykose> some people don't have real identities
2021-09-09 08:17:06 <linearcannon> that's fair, however i do have legitimate reasons for not going by the previously listed name online, which are probably best not discussed here
2021-09-09 08:17:24 <linearcannon> also, it's perfectly possible that i have legally changed my name to "linear cannon" :)
2021-09-09 08:17:38 <psykose> i prefer the curvature cannons
2021-09-09 08:17:42 <Ariadne> mps: other alpine people have contributed under psuedonym before.  i am willing to vouch for linearcannon's lack of evilness here
2021-09-09 08:18:02 <mps> linearcannon: I don't insist and I understand, but I don't trust, still
2021-09-09 08:18:18 <mps> I don't say these people are 'bad' in any way
2021-09-09 08:19:58 <mps> Ariadne: yes, I know and I always have 'strange' feeling about their contributions
2021-09-09 08:22:42 <linearcannon> my parents drilled into me when i was young that i should not be giving personal information out online, such as my name. to me the idea of sharing my name online still feels foreign and strange, and the one time i did start to give in, i ended up regretting it *very* quickly, and had to purge numerous accounts online to protect myself and people around me from grave harm.
2021-09-09 08:23:14 <linearcannon> so, since then, my rule has been that i contribute under a pseudonym, or not at all, and i try not to make it too easy to clearly link the pseudonym to myself.
2021-09-09 08:23:19 <maxice8> huh
2021-09-09 08:23:27 <maxice8> s390x decided to not fail on building go after a few tries
2021-09-09 08:25:17 <mps> linearcannon: yes, modern time, I understand
2021-09-09 08:26:53 <mps> alpine is serious OS and as such should have serious people involved, imo
2021-09-09 08:27:07 <psykose> very welcoming
2021-09-09 08:27:13 <mps> and brave ones
2021-09-09 08:27:20 <Ariadne> contributing under a pseudonym does not make people not serious or not brave
2021-09-09 08:27:42 <mps> meh :p
2021-09-09 08:28:39 <mps> in Japan till the end of 19th century you could loose head if you don't say your real name
2021-09-09 08:30:46 <Ariadne> Alpine, thankfully, is not 19th century Japan.
2021-09-09 08:31:25 <mps> :)
2021-09-09 08:54:04 <skarnet> <mps> my main 'fear' of s6 is the 'strong' temper of upstream
2021-09-09 08:54:31 <skarnet> that's code for "someone doesn't agree with me all the time and calls me out when I am gratuitously hostile"
2021-09-09 08:54:54 <skarnet> most people actually *like* that aspect of me, and you better get used to it
2021-09-09 08:55:10 <skarnet> and if it prevents you from switching to s6 when the time comes, that's on you, and don't let the door hit you on the way out
2021-09-09 08:57:40 <skarnet> I try not to let my personal feelings get in the way of good tech, and it has caused disagreements between me and other community members in the past (for instance, I have defended some parts of suckless more than was palatable for several people, because I liked suckless minimalistic's approach and tried to be oblivious to their politics, until I could not)
2021-09-09 08:57:55 <skarnet> I expect the same effort from others
2021-09-09 09:02:55 <mps> heh ;)
2021-09-09 09:04:11 <mps> I'm of those who likes 'that aspect' of you
2021-09-09 09:04:43 <mps> but I don't like yours (sometimes) harsh words
2021-09-09 09:05:49 <skarnet> Hi pot, I'm kettle :P
2021-09-09 09:06:04 <mps> hehe, nice
2021-09-09 09:07:18 <maxice8> I'm gonna be leaving in 2 hours and around 20-30 minutes, if someone can look over the go-world rebuild in the meantime it would be very nice
2021-09-09 09:08:19 <mps> skarnet: but when you are here, does it make sense to run mdevd from /proc/sys/kernel/hotplug on systems where hot plug is seldom done?
2021-09-09 09:09:09 <mps> and not as daemon
2021-09-09 09:09:11 <skarnet> mps: no, mdevd isn't a spawned program like mdev, it's a daemon like mdev -d, so you can't register it as a hotplug helper
2021-09-09 09:09:33 <skarnet> mdev isn't bad at all as a hotplug helper tbh
2021-09-09 09:10:15 <mps> with mdev and libudev-zero I got hot plug working fine
2021-09-09 09:11:20 <mps> now I'm searching for ideas how to use usb-modeswitch (though I got first results)
2021-09-09 09:11:51 <skarnet> one of the main problems of mdev is that it reads its config file for every event, which is expensive when run as a daemon and during coldplug; but in a situation where you prefer having a hotplug helper, you have to read the config on every event *anyway*, so that drawback from mdev disappears
2021-09-09 09:12:45 <mps> yes, that is for me to contemplate
2021-09-09 09:12:57 <skarnet> so yeah, if you don't want to run a daemon, keep mdev as your hotplug helper, it does the job just fine
2021-09-09 09:13:43 <mps> I see you improve mdedv in last time
2021-09-09 09:14:00 <mps> mdevd*
2021-09-09 09:14:33 <skarnet> yeah, and next release (current master branch) will have support for any type of event (as suggested by libudev-zero's author)
2021-09-09 09:14:57 <mps> but ok, we have time for these switch for yet another release cycle (at least)
2021-09-09 09:15:27 <mps> yes, I read this on libudev-zero GH
2021-09-09 09:16:16 <mps> that will be 'good thing'
2021-09-09 09:19:41 <Ariadne> skarnet: in fairness, i think suckless have improved on that front in recent years
2021-09-09 09:21:08 <skarnet> well I'll be happy if working with them becomes socially acceptable :)
2021-09-09 09:45:35 <andypost[m]> Ariadne: are you ok to remove dbg and docs, what about static?
2021-09-09 09:45:44 <Ariadne> keep static and dbg
2021-09-09 09:45:54 <Ariadne> remove docs
2021-09-09 09:46:11 <fabled> yeah, I'd like to have even more packages ship -dbg (or perhaps even enable it by default?) assuming we have disk space for them
2021-09-09 09:46:29 <fabled> might need to think about splitting -dbg packages to separate repository
2021-09-09 09:47:16 <fabled> reminds me, I'd like to enable -dbg on nodejs-current. any objections? (will likely do PR for that)
2021-09-09 09:52:47 <Cogitri[m]> fabled: https://gitlab.alpinelinux.org/alpine/aports/-/issues/10603
2021-09-09 09:54:03 <mps> I'm not sure -dbg by default would 'pass' 32-bit arches on big pkgs
2021-09-09 10:10:03 <fabled> Cogitri[m]: thanks
2021-09-09 10:20:40 <andypost[m]> Ariadne: finally it works locally but need more eyes
2021-09-09 10:22:47 <andypost[m]> and onlu include/openssl has collision
2021-09-09 10:30:18 <Ariadne> thats fine
2021-09-09 10:30:30 <Ariadne> there should be only one or the other in a build environment
2021-09-09 10:31:41 <Ariadne> andypost[m]: have you verified that upgrade works?
2021-09-09 10:32:03 <andypost[m]> Because of "replaces"?
2021-09-09 10:32:22 <andypost[m]> Oh, did not(
2021-09-09 10:32:43 <Ariadne> see my note
2021-09-09 10:32:46 <Ariadne> thats the outcome we want
2021-09-09 10:40:01 <andypost[m]> At least curl works after upgrade, so probably fine
2021-09-09 10:40:31 <andypost[m]> Ariadne replied
2021-09-09 10:45:44 <Ariadne> try with `--available`
2021-09-09 10:47:03 <andypost[m]> nothing happens
2021-09-09 10:47:48 <Ariadne> hmm
2021-09-09 10:47:53 <Ariadne> i'll defer to fabled 
2021-09-09 10:55:49 <andypost[m]> I send one more commit to bump abuild, but locally it rebuilds against `so:libcrypto.so.3`
2021-09-09 11:24:53 <Ariadne> yes, it should :)
2021-09-09 11:25:14 <Ariadne> we will want to rebuild everything against libcrypto next
2021-09-09 11:25:20 <Ariadne> but this way, we can test the rebuilds with CI
2021-09-09 11:25:22 <Ariadne> :)
2021-09-09 11:48:45 <fabled> I was building nodejs-current with debug package enabled on my laptop, and ld got OOM killed. :/
2021-09-09 11:48:52 <fabled> sounds like an excuse to buy new one ;)
2021-09-09 12:06:15 <xsteadfastx> what does it take to move a package from testing to community?
2021-09-09 12:27:48 <staceee> hello there ! we dont have xcb-util-errors to build wlroots. How is that possible ? Someone tried to add it one year ago but the mr has been closed (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/2700). I'm trying to build it and got a redflag on meson but it still can build. But I got a crash when trying to config xcb layouts and other related sway configs.
2021-09-09 12:27:49 <staceee> Someone know something about that ?
2021-09-09 12:38:12 <Hello71> pretty sure xcb-util-errors is obsolete
2021-09-09 12:41:27 <Hello71> hm, seems like it actually does do something in wlroots but just unmaintained upsream
2021-09-09 12:41:30 <Hello71> t
2021-09-09 13:40:47 <Ariadne> 5MB alpine image is so last year
2021-09-09 13:40:58 <Ariadne> its all about the 619KB alpine image now: https://ariadne.space/2021/09/09/introducing-witchery-tools-for-building-distroless-images-with-alpine/
2021-09-09 13:42:37 <andypost> Ariadne: ncopa: upgrade of openssl require to upgrade oprnldap, !24084 builds fine but needs to bump dependencies
2021-09-09 13:45:07 <jvoisin> Ariadne: "àpk" is the French version of apk ? :P
2021-09-09 13:45:25 <Ariadne> hmm>
2021-09-09 13:45:27 <Ariadne> ?
2021-09-09 13:46:36 <Ariadne> 
ACTION looks at wordpress, disapprovingly

2021-09-09 13:46:36 <minimal> Ariadne: looks good. Re: s6 in containers, unfortunately I moved the s6-overlay package to unmaintained a little while ago as upstream for that is practically dead. Skarnet is working on working on equivalent functionality in s6 itself but that may be some time off
2021-09-09 13:47:32 <Ariadne> just use kubernetes obviously
2021-09-09 13:47:38 <Ariadne> then it can supervise for you
2021-09-09 13:47:45 <Ariadne> without having to have supervisors on supervisors
2021-09-09 13:47:46 <Ariadne> :P
2021-09-09 13:48:17 <mps> what is plan about openssl 3.0 and 3.15-stable
2021-09-09 13:48:40 <minimal> how does that manage the situation of a container where you may want to run more than a single process?
2021-09-09 13:48:41 <mps> upgrade all pkgs to use openssl 3.0?
2021-09-09 13:49:25 <skarnet> minimal, Ariadne: for now my schedule is: finishing my current round of work in September, out in October (medical reasons), and working on s6-overlay in November
2021-09-09 13:49:44 <Ariadne> mps: yes
2021-09-09 13:49:47 <skarnet> might start at the end of October if recovery's good enough
2021-09-09 13:50:06 <minimal> skarnet: oh you're going to keep s6-overlay active? I thought you were going to replace it.
2021-09-09 13:50:28 <mps> Ariadne: good to know, to start looking what needs to be fixed
2021-09-09 13:50:41 <Ariadne> mps: i already looked
2021-09-09 13:50:44 <Ariadne> it is not too bad
2021-09-09 13:51:17 <mps> in their changelog I read that some pkgs could be problematic
2021-09-09 13:51:24 <skarnet> minimal: it will be some time before full s6 init can replace s6-overlay in all the containers that need it and I'm afraid the duct tape won't hold for long enough
2021-09-09 13:51:36 <mps> but ok, it is our 'job' to cope with them
2021-09-09 13:51:37 <skarnet> whereas in one month or two I can whip out a new version of s6-overlay that works
2021-09-09 13:54:26 <Ariadne> one might notice that i don't discuss google distroless at all
2021-09-09 13:54:29 <Ariadne> and, well
2021-09-09 13:54:35 <Ariadne> if you don't have anything nice to say, best to say nothing :D
2021-09-09 13:55:06 <Ariadne> you pretty much have to use their bazel thing
2021-09-09 13:55:11 <Ariadne> to make the most of distroless
2021-09-09 13:55:25 <Ariadne> verses here, you just use docker as you do already
2021-09-09 13:55:56 <skarnet> "distroless" sounds like yet another pile of hidden costs
2021-09-09 14:04:43 <Ariadne> oh
2021-09-09 14:04:44 <Ariadne> absolutely
2021-09-09 14:05:07 <Ariadne> its basically a shortcut to use parts of distros without the whole thing
2021-09-09 14:05:59 <skarnet> ah, so not-really-distroless-but-we-hide-the-distro-part-because-it-is-sexier
2021-09-09 14:06:32 <Ariadne> yeah, witchery does not do that, on the other hand :)
2021-09-09 14:07:13 <skarnet> :GeraltHmmm:
2021-09-09 14:54:37 <minimal> Ariadne: I was looking at Google's distroless last night so your work is timely for me :-)
2021-09-09 14:58:08 <ncopa> i dont know what to do with ghc update. it has like 800 test failures
2021-09-09 14:58:51 <ncopa> 851 unexpected failures
2021-09-09 15:02:05 <ncopa> it is blocking the libffi update
2021-09-09 16:04:14 <Cogitri[m]> Hm, I guess disabling won’t be fun since we have to re-bootstrap then?
2021-09-09 16:08:32 <mps> it is possible to split variable in posix shell to two new variables?
2021-09-09 16:15:22 <Hello71> depends what you want to split on
2021-09-09 16:20:42 <dalias> you can use ${var#pat} ${var%pat} etc. or use IFS=something read -r foo bar <<EOF\n$var\nEOF
2021-09-09 16:23:24 <mps> 'PRODUCT=12d1/1446/0' and to get two vars of values 12d1 and 1446
2021-09-09 16:25:02 <mps> usb vendor and product ids
2021-09-09 16:26:40 <dalias> either of my solutions would work
2021-09-09 16:27:18 <mps> dalias: what is 'pat', regex pattern?
2021-09-09 16:27:29 <dalias> glob style pattern
2021-09-09 16:27:44 <mps> ah
2021-09-09 16:27:45 <dalias> ${PRODUCT%%/*} will get 12da
2021-09-09 16:28:07 <dalias> then use ${PRODUCT#*/} to remove the 12da/
2021-09-09 16:28:11 <dalias> then apply the same idea to the tail
2021-09-09 16:28:31 <dalias> %% and ## forms match the longest possible, % and # shortest
2021-09-09 16:28:36 <dalias> or something like that
2021-09-09 16:28:41 <dalias> i might have it stated imprecisely
2021-09-09 16:30:27 <mps> have to try, thanks
2021-09-09 16:30:42 <mps> btw, I read your posix shell tricks
2021-09-09 16:36:52 <mps> dalias: got it to work, thanks again
2021-09-09 16:36:59 <dalias> :)
2021-09-09 16:37:20 <dalias> shell is quite powerful without external utilities if you know the arcane tricks :)
2021-09-09 16:37:23 <mps> why ash doesn't have pcre ;)
2021-09-09 16:37:54 <mps> yes, I have to know arcanes
2021-09-09 16:54:43 <Hello71> if you want bloat then just invoke bash instead
2021-09-09 16:55:18 <Hello71> i think even bash regex doesn't use pcre
2021-09-09 16:58:20 <mps> if I have to use bash then I will chose perl rather
2021-09-09 16:58:35 <mps> choose*
2021-09-09 16:58:51 <nzm> dobar dan, hi all! I'm done class for the day, so I'll be working on mingw-w64 today to trial some packaging like Ariadne suggested, I'll probably have some questions about what you're looking for with this. If I feel too lost I'll start brainstorming some documentation
2021-09-09 16:59:15 <mps> nzm: добар дан, actually :)
2021-09-09 16:59:55 <nzm> :D I don't have cyrillic keyboard, but I also only really know a few phrases so cyrillic keyboard might not help haha
2021-09-09 17:00:27 <mps> good that you can read it
2021-09-09 17:01:00 <nzm> :) I used to work in your area a few years ago, now I'm back in Canada
2021-09-09 17:01:24 <mps> ah really? where exactly?
2021-09-09 17:02:06 <nzm> Sarajevo, I had a job doing IT maintenance for a non-profit and so they sent me to a bunch of different places
2021-09-09 17:02:28 <mps> not my area, but not far
2021-09-09 17:03:36 <mps> nzm: we also have #alpine-docs channel, though not sure is it active now
2021-09-09 17:04:34 <nzm> oh right, sorry I just meant broadly speaking. I'll join #alpine-docs, I've got too many questions already about packaging things and I think I need to get a better sense of the scope of alpine, beyond that of someone who uses it
2021-09-09 17:05:51 <mps> ok
2021-09-09 17:06:47 <mps> APKBUILD is actually posix shell script, so not much complicated (except posix shell is complicated :) )
2021-09-09 17:07:35 <nzm> I'm gonna clone the package from git repo first and see history of commits, that'll probably answer a few of my questions without asking hehe
2021-09-09 17:07:52 <mps> currently I'm struggling to read env variables in noninteractive shell ;)
2021-09-09 17:08:03 <Misthios> hf
2021-09-09 17:08:15 <Misthios> i think i got lld building *prays it finishes*
2021-09-09 17:08:51 <mps> Misthios: 'hf' ?
2021-09-09 17:08:59 <Misthios> have fun
2021-09-09 17:11:20 <mps> why the internet thinks that the linux/unix shell is only bash!!!
2021-09-09 17:15:32 <nzm> This is probably not helpful, but the ash source code is relatively small, would it help to try to read it? I've found documentation on ash to be lacking generally
2021-09-09 17:17:01 <mps> well, I think 'env' is enough
2021-09-09 17:17:50 <Hello71> APKBUILD is only posix-ish
2021-09-09 17:18:09 <Hello71> ${var//a/b} is not posix
2021-09-09 17:34:54 <dalias> mps, what are you trying to do?
2021-09-09 17:42:05 <mps> dalias: I'm trying to parse mdev hotplug events, in that case detect if the device plugged in usb is in usb-modeswitch list
2021-09-09 17:43:31 <dalias> i mean you said you're struggling to read variables non-interactive
2021-09-09 17:43:45 <mps> ah, yes
2021-09-09 17:43:46 <dalias> were you using some bashisms in interactive bash that dont work in posix shell
2021-09-09 17:44:05 <dalias> (i dont have that problem because my interactive shells are ash :)
2021-09-09 17:44:11 <mps> no, I don't use bash at all, only ash and tcsh
2021-09-09 17:44:37 <mps> in interactive ash env vars works fine
2021-09-09 17:45:01 <mps> but can't get it work in shell invoked by mdev
2021-09-09 17:45:35 <dalias> are you sure the values come in the vars you think they're in?
2021-09-09 17:47:10 <mps> yes, I dump env buy 'env >> /tmp/log' and see them there
2021-09-09 17:47:30 <mps> here it is https://tpaste.us/Prwe
2021-09-09 17:47:59 <dalias> and what code fails?
2021-09-09 17:48:38 <mps> https://tpaste.us/6Wqa
2021-09-09 17:48:44 <mps> here is shell
2021-09-09 17:49:09 <mps> hmm, I'm blind
2021-09-09 17:49:40 <mps> I see '>> /tmp/log' after echo is missing
2021-09-09 17:50:11 <dalias> why not just exec >>/tmp/log at top of script?
2021-09-09 17:50:15 <dalias> then all output will go there
2021-09-09 17:50:40 <mps> good idea
2021-09-09 18:22:07 <mps> huh, so nice, usb-modeswitch have tcl dispatcher script long 1000 lines :/
2021-09-09 18:54:53 <dalias> :/
2021-09-09 19:27:55 <mps> I will left this to usb-modeswitch apk maintainer
2021-09-09 19:28:39 <mps> for now we can tell users how they can do this manually for their devices
2021-09-09 19:29:44 <mps> and this is more 'alpine way' how to do things, we are not ubuntu at the end
2021-09-09 21:01:21 <maxice8>   looking at step-cli
2021-09-09 21:01:29 <maxice8> upstream answered and asked to use the new release that has that fixed
2021-09-09 22:45:13 <maxice8> x86 can't fetch aports-glmr
2021-09-09 22:45:36 <maxice8> or rather it can but it is fetching a wrong one somehow
2021-09-09 23:39:47 <adamplumb> what does openrc do with services that log to stdout?  Is there any way to get the log?
2021-09-09 23:43:23 <psykose> use supervise-daemon
2021-09-09 23:45:15 <psykose> i assume you mean a service that remains in foreground when you run it, in which case you just need to set supervisor=supervise-daemon in the init script and set error_log and output_log to where you want stderr/stdout to go
2021-09-09 23:46:39 <psykose> example: https://git.alpinelinux.org/aports/tree/testing/soju/soju.initd
2021-09-09 23:50:22 <adamplumb> oh i found that the service i'm looking at uses start-stop-daemon which has a --stdout argument to specify the log file, that's just what i needed
2021-09-09 23:50:54 <psykose> ah, yeah ssd has those options too
2021-09-09 23:50:55 <adamplumb> are there any conventions in alpine about whether services should log or not log by default?  or just up to the app
2021-09-09 23:51:22 <psykose> i believe they are still set with the same _log variables
2021-09-09 23:51:37 <psykose> so you don't need to mess with the ssd params in start() yourself
2021-09-09 23:52:10 <skarnet> adamplumb: I believe it's service by service policy
2021-09-09 23:52:21 <skarnet> no universal rule can apply
2021-09-10 00:06:17 <maxice8> testing/thanos is reliably failing on x86
2021-09-10 00:26:29 <maxice8> huh
2021-09-10 00:26:35 <maxice8> I was proven wrong
2021-09-10 01:24:38 <tomalok> adamplumb: i use log_proxy to capture/rotate stdout/stderr from docker so my logs don't grow without bound until docker is restarted.
2021-09-10 01:27:04 <tomalok> hm, looks like mips64 didn't build after the latest update & move to community?  https://pkgs.alpinelinux.org/packages?name=log_proxy&branch=edge
2021-09-10 01:33:11 <minimal> tomalok: for the json logger?
2021-09-10 01:40:41 <tomalok> so dockerd just keeps on writing to stderr/stdout forever - this is for the engine not the containers
2021-09-10 01:42:05 <tomalok> something something 12-factor application...
2021-09-10 01:43:11 <tomalok> https://12factor.net/logs
2021-09-10 01:43:48 <minimal> tomalok: yes I know but dockerd has configurable loggers, so "json" has been default for long time but there is now a recommended "local" driver which does rotation
2021-09-10 01:44:15 <tomalok> you're thinking of the logs that the running containers spit out, not the daemon's logs
2021-09-10 01:44:28 <minimal> ah, you're right
2021-09-10 01:45:29 <tomalok> time="2021-09-09T23:58:45.526628608Z" level=warning msg="grpc: addrConn.createTransport failed to connect to {172.30.16.131:2377  <n
2021-09-10 01:45:29 <tomalok> ". Reconnecting..." module=grpc
2021-09-10 01:45:29 <tomalok> il> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial tcp 172.30.16.131:2377: connect: no route to host\
2021-09-10 01:45:38 <tomalok> and such
2021-09-10 01:46:36 <tomalok> so my /etc/conf.d/docker says
2021-09-10 01:46:51 <tomalok> DOCKERD_BINARY="/usr/bin/log_proxy_wrapper"
2021-09-10 01:47:00 <tomalok> DOCKER_OPTS="-F /var/log/log_proxy -O /var/log/docker.log -s 10485760 -t 0 -- /usr/bin/dockerd"
2021-09-10 01:47:53 <tomalok> ...and then it gets automagically rotated without interrupting dockerd or anything running on it
2021-09-10 01:49:56 <Hello71> i heard mips64 builder is still dead
2021-09-10 01:55:09 <tomalok> that might explain it.
2021-09-10 02:42:46 <maxice8> good news: go-world rebuild is almost done
2021-09-10 02:42:53 <maxice8> bad news: go1.17.1 is released with another CVE fix
2021-09-10 02:45:01 <maxice8> CVE-2021-39293 which is a bypass for a fix for CVE-2021-33196 (1.16.5)
2021-09-10 02:48:34 <psykose> here it goes again :p
2021-09-10 02:56:56 <maxice8> on the bright side I didn't get around to 3.14-stable yet so we will need to rebuild the 3.14-go-world only once
2021-09-10 03:29:20 <Ariadne> well 1.17.1 will be smoother
2021-09-10 03:30:09 <maxice8> yeah, some packages had testfixes some were disabled with an upstream issue opened
2021-09-10 03:30:31 <maxice8> Plus I'll be less stupid and run it through CI first instead of just pushing
2021-09-10 05:42:45 <maxice8> ok gonna push go 3.14 upgrade 1.16.7->1.16.8 then make a MR for go-world rebuild, any objections to the former ?
2021-09-10 06:00:46 <mps> maxice8: could we merge in meantime some MRs
2021-09-10 06:01:24 <maxice8> go ahead, I see you have some MRs
2021-09-10 06:02:19 <mps> I don't want to make builders busy if some problem arises
2021-09-10 06:05:46 <mps> maxice8: finished
2021-09-10 06:08:50 <maxice8> ok
2021-09-10 06:08:58 <maxice8> riscv64 seems stuck
2021-09-10 07:24:07 <xsteadfastx> what does it take to move a package from testing to community?
2021-09-10 07:27:54 <mps> most frequently asked question in last time :)
2021-09-10 07:29:20 <mps> pkg must have devoted maintainer, dependencies in community satisfied, build cleanly, no license issues (and usable is my criteria)
2021-09-10 07:40:12 <clandmeter> and dont forget, approval from mps
2021-09-10 07:40:48 <mps> clandmeter: oh sorry, I forgot most important rule ;)
2021-09-10 07:40:55 <clandmeter> :p
2021-09-10 07:40:57 <mps> thanks for reminder
2021-09-10 07:41:07 <clandmeter> you are PAM
2021-09-10 07:41:11 <clandmeter> package approval manager
2021-09-10 07:41:17 <mps> :D
2021-09-10 07:42:02 <mps> clandmeter: do you have little time to look commit msg of the !25043
2021-09-10 07:42:49 <mps> you are maintainer (and I just wanted to take some burden from you and because that I made this MR)
2021-09-10 07:46:20 <maxice8> go is failing on armv7 3.14-stable
2021-09-10 08:03:30 <Ariadne> going through the openrc patchset
2021-09-10 08:03:42 <Ariadne> busybox fsck -C now seems to be supported
2021-09-10 08:03:48 <Ariadne> so i guess we can drop that one
2021-09-10 08:08:36 <xsteadfastx> mps: thanks :) 
2021-09-10 08:10:33 <clandmeter> mps: sure
2021-09-10 08:12:13 <Ariadne> hmm
2021-09-10 08:12:15 <Ariadne> no
2021-09-10 08:12:49 <mps> any objections to !25061
2021-09-10 08:12:59 <mps> wener: ^
2021-09-10 08:13:16 <wener> lgtm
2021-09-10 08:13:39 <mps> ok, and thanks for review
2021-09-10 08:16:07 <clandmeter> mps: are you sure there are no tests?
2021-09-10 08:16:31 <mps> I'm not sure on anything
2021-09-10 08:17:03 <mps> but looks like there is no, and at least I can't get it to start
2021-09-10 08:17:54 <mps> actually, I copied most of these cmake from their Dockerfile, which is alpine based
2021-09-10 08:18:19 <mps> and i don't understand how cmake works
2021-09-10 08:18:31 <mps> just superficially
2021-09-10 08:20:00 <clandmeter> not sure docker is the best example to look at 
2021-09-10 08:20:41 <mps> well, I couldn't find anything else better that it
2021-09-10 08:39:40 <mps> I think they make clamav intentionally cumbersome for distributions to sell their commercial version and still pretend they are open source friendly
2021-09-10 08:46:49 <clandmeter> im going to make your life hard ;-)
2021-09-10 08:47:03 <mps> I see
2021-09-10 08:47:16 <clandmeter> but, you asked for it.
2021-09-10 08:47:25 <clandmeter> :p
2021-09-10 08:47:34 <clandmeter> your wish...
2021-09-10 08:48:41 <mps> no, I wanted to take some of your burden
2021-09-10 08:49:08 <mps> be careful what you will write in MR ;p
2021-09-10 08:50:46 <mps> actually I would like if someone with cmake knowledge take this and fix, and take all credits (if s/he works for high git commit rank)
2021-09-10 08:51:57 <clandmeter> i checked out your branch
2021-09-10 08:52:00 <clandmeter> looking at it
2021-09-10 08:52:07 <clandmeter> interesting fts issue
2021-09-10 08:53:24 <mps> fts is problem for clamonacc, despite told to use external it uses internal
2021-09-10 08:55:17 <mps> their developers (micah especially who was/is quite responsive) left IRC with frenode fiasco 
2021-09-10 08:58:12 <clandmeter> i think the fts isssue is related to ldflags
2021-09-10 09:07:42 <wener> dose leo here ? have some question about !25063 , should I split every bump version or one commit to include all bump version ?
2021-09-10 09:09:18 <wener> this pr is all in one https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23500 
2021-09-10 09:13:17 <clandmeter> wener: maxice8 is leo
2021-09-10 09:13:40 <wener> maxice8: 
2021-09-10 09:28:02 <Ariadne> guys
2021-09-10 09:28:04 <Ariadne> guys
2021-09-10 09:28:11 <Ariadne> alpine is not secure, because awall sucks
2021-09-10 09:28:22 <caskd> ????
2021-09-10 09:28:23 <Ariadne> somebody literally sent me a mail to tell me that just now
2021-09-10 09:29:25 <Misthios> isnt awall a wrapper over iptables?
2021-09-10 09:30:12 <clandmeter> mps: i give up on this fts crap, i have no idea why cmake does not want to link to it.
2021-09-10 09:32:06 <Ariadne> yes
2021-09-10 09:32:12 <Ariadne> clandmeter: whats going on with fts?
2021-09-10 09:32:47 <mps> clandmeter: I understand (I did same after some number of tries)
2021-09-10 09:32:58 <clandmeter> clamav switched to cmake
2021-09-10 09:33:11 <clandmeter> before we just exported LDFLAGS which works
2021-09-10 09:33:19 <clandmeter> but with cmake its not working
2021-09-10 09:33:31 <mps> right
2021-09-10 09:33:42 <clandmeter> its passed but still... maybe its the order or something
2021-09-10 09:33:44 <ncopa> good day! Ariadne please thank him for letting us know. did he say what distro we should all switch to?
2021-09-10 09:34:03 <mps> :D
2021-09-10 09:34:09 <Ariadne> yes, he suggested we should all use pfsense, actually
2021-09-10 09:34:22 <mps> ncopa: you make fun in the morning
2021-09-10 09:34:39 <clandmeter> pfsense is nice
2021-09-10 09:34:44 <Ariadne> firewall solves 85% of security problems, apparently
2021-09-10 09:34:49 <clandmeter> for sure when you are using pppoe :)
2021-09-10 09:35:25 <mps> firewall is more than net filtering/policing
2021-09-10 09:35:28 <Ariadne> he also wanted to know if we heard about exploit mitigation, so i asked if he knew about clang's control flow integrity
2021-09-10 09:35:57 <clandmeter> you had an actual conversation with him/her, nice.
2021-09-10 09:35:58 <Ariadne> which we already build some packages with :)
2021-09-10 09:36:20 <ncopa> Ariadne: please ask for his email so I know who to ask whenever i replace my alpine desktop and alpine router. i may need help from an expert like him/her to get opennhrp running on my router
2021-09-10 09:37:16 <ncopa> exploit mitigation. sounds like 2010 and grsecurity
2021-09-10 09:38:28 <mps> sounds like someone who don't understand security (i.o.w. security doesn't exists actually, just mitigations)
2021-09-10 09:38:54 <mps> but, I don't care
2021-09-10 09:39:33 <Ariadne> https://distfiles.dereferenced.org/email.txt
2021-09-10 09:42:14 <mps> oh, fun, as first s/he don't know who was Ariadne in greek mythology :)
2021-09-10 09:43:11 <caskd> lmao
2021-09-10 09:43:28 <caskd> i really hope that mail is a troll and not legit
2021-09-10 09:43:43 <caskd> i would feel bad if it was legit
2021-09-10 09:44:28 <mps> looks like troll
2021-09-10 09:44:53 <Ariadne> yeah i assume it is trolling
2021-09-10 09:44:57 <mps> hmm, I should not use word 'troll' for anyone
2021-09-10 09:45:03 <Ariadne> but none the less, they got a legit response
2021-09-10 09:46:30 <mps> sometimes I receive 'strange' mails in private inbox about something in alpine, but I simply ignore them
2021-09-10 09:46:48 <Ariadne> oh, i always feed the trolls
2021-09-10 09:46:50 <kunkku> heh, he has access to a lot of security related statistics
2021-09-10 09:47:17 <Ariadne> well, i can make up statistics too
2021-09-10 09:47:18 <Ariadne> :D
2021-09-10 09:47:42 <caskd> "alpine cleans up your whole network of malware with one install"
2021-09-10 09:48:27 <mps> well, we have to understand that most of nowadays science is actually statistic, and usually badly done statistic
2021-09-10 09:49:16 <Ariadne> well either way, i think i laid out the facts that alpine is just as serious as everyone else on security
2021-09-10 09:50:16 <kunkku> we spend less time on touting how secure we are
2021-09-10 09:50:39 <maxice8> go seems to be failing reliably on armv7 3.14
2021-09-10 09:51:26 <mps> I like to 'bash' security theater but I'm always serious about security whatever I work on
2021-09-10 09:51:58 <Ariadne> panic: test timed out after 18m0s
2021-09-10 09:52:13 <Ariadne> mps: me too, which is why writing marketing fluff about alpine's security is a low-priority item
2021-09-10 09:52:33 <Ariadne> i think all of us who are working on security projects in alpine just want to fix bugs
2021-09-10 09:54:17 <mps> about 15-20 years ago I was even owner of small security firm, but left this business 
2021-09-10 09:56:08 <Ariadne> security industry is certainly something
2021-09-10 09:56:22 <donoban> ey hi guys, talking about maintaining an "smaller base system", I'm trying to simpliciy the pam base config
2021-09-10 09:56:34 <mps> heh, I was bad in marketing :)
2021-09-10 09:56:48 <donoban> If someone it's using gdm (pretty rare here) and wants to test !25178
2021-09-10 09:57:19 <midi[m]> <Ariadne> "https://distfiles.dereferenced...." <- Wtf?
2021-09-10 09:57:23 <mps> donoban: pam, yet another layer in security (and usually useless)
2021-09-10 09:57:37 <midi[m]> That email is ridiculous 
2021-09-10 09:58:15 <donoban> yeah but removing pam is an option? :D
2021-09-10 09:58:21 <Ariadne> i wish it were
2021-09-10 09:58:22 <midi[m]> Good on the guy replying for keeping calm. I'd be so heated man
2021-09-10 09:58:28 <Ariadne> the person replying
2021-09-10 09:58:29 <Ariadne> is me
2021-09-10 09:59:04 <donoban> if it has to be there at least have a simpler and clearer config
2021-09-10 09:59:05 <mps> ncopa: looks like you have some free time :) !25061 would you mind to look at this
2021-09-10 09:59:10 <midi[m]> HA. Well good on you man. I'd be pulling my hair haha
2021-09-10 10:00:00 <mps> donoban: yes, pam is not installed on any of my systems
2021-09-10 10:00:12 <Ariadne> 4:59 AM <donoban> if it has to be there at least have a simpler and clearer config
2021-09-10 10:00:17 <Ariadne> it is worthwhile endeavour
2021-09-10 10:00:22 <donoban> I know mps but it doesn't mean it is removed from alpine
2021-09-10 10:00:25 <Ariadne> the problem is that PAM is fragile
2021-09-10 10:00:31 <Ariadne> any changes we do need to be tested
2021-09-10 10:00:43 <Ariadne> i would suggest asking the #postmarketOS crew
2021-09-10 10:00:50 <Ariadne> they are probably the heaviest users of PAM
2021-09-10 10:00:53 <donoban> yes, so I switcehd to a smaller MR strategy
2021-09-10 10:01:10 <donoban> ok, I will ping them
2021-09-10 10:01:13 <Ariadne> . o O (maybe we should make a postmarketOS team on our gitlab so its easy to ping them?)
2021-09-10 10:01:38 <mps> or rename alpine to pmOS ;P
2021-09-10 10:01:40 <donoban> I just noticed that that the current MR is probably not calling pam_elogind.so
2021-09-10 10:02:11 <Ariadne> i would ask ollieparanoid what he thinks but hes not here
2021-09-10 10:02:32 <donoban> oh it's ok, base-auth already calls elogind
2021-09-10 10:02:56 <donoban> what is the pmos channel?
2021-09-10 10:03:02 <donoban> #postmarketOS?
2021-09-10 10:03:08 <Ariadne> yes
2021-09-10 10:03:11 <donoban> ok
2021-09-10 10:03:30 <donoban> ouch: | #postmarketos :You must connect via SSL to join this channel (+S)
2021-09-10 10:03:48 <psykose> you weren't already? :p
2021-09-10 10:04:29 <donoban> I didn't bother about that :\
2021-09-10 10:05:42 <donoban>    oftc =!= | irc: TLS handshake failed
2021-09-10 10:05:44 <donoban>    oftc =!= | irc: error: An unexpected TLS packet was received.
2021-09-10 10:05:46 <donoban> :(
2021-09-10 10:07:50 <psykose> did you change to 6697
2021-09-10 10:08:05 <donoban> wops nope
2021-09-10 10:13:52 <donoban> fixed :D
2021-09-10 10:14:25 <psykose> grats :D
2021-09-10 10:15:27 <ncopa> mps: I added a comment
2021-09-10 10:16:30 <mps> ncopa: thanks
2021-09-10 10:18:45 <mps> actually, my plan is to do same for cpupower and probably perf subkpgs
2021-09-10 10:19:54 <mps> to consolidate naming and to be clear where all of these is origin
2021-09-10 11:15:24 <ncopa> i think im making progress with ghc and libffi
2021-09-10 11:33:54 <Ariadne> i asked some haskell pals to pop in
2021-09-10 11:36:24 <ncopa> there are some known issues with libffi 3.4. we could either build libffi 3.4 with --disable-exec-static-tramp, or we could simply use the bundled libffi
2021-09-10 11:36:45 <ncopa> i think using the bundled libffi is a generally good idea, as it will make it easier to upgrade libffi in the future
2021-09-10 11:36:54 <Ariadne> bundle for now i think
2021-09-10 11:37:08 <ncopa> yeah. thats what im doing
2021-09-10 12:13:10 <minimal> Ariadne: did you tell him Alpine is webscale? ;-) http://www.mongodb-is-web-scale.com/
2021-09-10 12:22:53 <Misthios> lol
2021-09-10 12:23:07 <minimal> donoban: so is nothing in Alpine using the system-*.pamd files? Otherwise removing them may break stuff. I agree with simplification of the config in principle/
2021-09-10 12:25:16 <donoban> I'm not 99% sure but I tested a lot of login managers and pam related programs and gdm was the only that depends on them
2021-09-10 12:26:48 <minimal> I thought /bin/login might also use them but a speed-read of shadow's login.c left me none the wiser
2021-09-10 12:30:00 <donoban> I just looked at all pamd files on aports, no system-local reference
2021-09-10 12:30:30 <donoban> the first time I did it I missed gdm because it has the pamd files inside source tarball, maybe there are other packages with that behaviour
2021-09-10 12:50:02 <minimal> donoban: ok. login only uses /etc/pam.d/login and that file doesn't reference the system-* files so I guess its fine. Was just being cautious
2021-09-10 12:55:03 <donoban> :)
2021-09-10 12:55:48 <donoban> I will try to look for pamd files listed in pkgs.alpinelinux.org that don't appear in apports
2021-09-10 13:10:48 <mps> xsteadfastx: did you read COMMITSTYLE.md in aports root dir
2021-09-10 13:14:54 <mps> !25182
2021-09-10 14:13:34 <andypost[m]> Am I get it right for  !25186 - looks like all apps using zip needs rebuild
2021-09-10 14:35:09 <mps> andypost[m]: why?
2021-09-10 14:44:28 <andypost[m]> mps: suppose because https://pkg.go.dev/archive/zip is part of 1.17
2021-09-10 14:45:06 <mps> ahm, not sure, zip is separate pkg in aports
2021-09-10 14:45:30 <mps> and I don't see any CVE for zip in last days
2021-09-10 14:45:48 <andypost[m]> yes, because it's in std lib of go
2021-09-10 14:45:51 <mps> maybe this in go is some other of zips
2021-09-10 14:48:44 <mps> I think no, but who knows with go what to rebuild (safe is 'rebuild world :) )
2021-09-10 14:52:18 <mps> andypost[m]: OT, but do you know for this https://plumspace.com/products/smart-sfp/5g-4g-usb-router/
2021-09-10 14:53:02 <mps> company is in Skolkovo and I think it is near you (we talked about it on #alpine-offtopic)
2021-09-10 14:54:12 <andypost[m]> mps: see first time, and last years I'm moved to Ukraine) but surely there's tons of usb-routers)
2021-09-10 14:55:50 <mps> ah, ok
2021-09-10 15:58:47 <minimal> andypost: the "cool" factor of that router is that it fits in a switch's SFP port
2021-09-10 16:25:36 <Habbie> and it's big enough to run Debian, so it could certainly also run Alpine ;)
2021-09-10 17:56:40 <maxice8> lets hope I did the skip-test thing right
2021-09-10 18:25:43 <maxice8> can someone that actually knows go skip the net/http test that timeouts (https://build.alpinelinux.org/buildlogs/build-3-14-armv7/community/go/go-1.16.8-r0.log) ?
2021-09-10 18:29:31 <mps> I don't understand modern go but will look on lxc
2021-09-10 18:31:40 <mps> hmm, latest commit is f3daffda673342a38065b9d50ba8bcf89aa95dd6
2021-09-10 18:31:56 <mps> Mon Aug 16 19:43:26 2021 -0300
2021-09-10 18:32:34 <mps> ah, 3.14-stable
2021-09-10 18:39:56 <mps> maxice8: it passed in my lxc
2021-09-10 18:40:27 <mps> futex issue again on builders?
2021-09-10 18:43:54 <minimal> is there any sort of a cli-based regex tester packaged for Alpine?
2021-09-10 18:44:47 <minimal> I don't mean perl or python etc, I mean a simple cli tool ;-)
2021-09-10 18:45:31 <mps> that is I sometimes need
2021-09-10 18:45:59 <mps> do you know for any which is supports multiple variants
2021-09-10 18:46:07 <mps> any*
2021-09-10 18:46:15 <mps> uh
2021-09-10 18:47:30 <minimal> hmm, found check-regexp in source-highlight package, no to see if I support grouping etc...
2021-09-10 18:47:37 <minimal> s/no/now/g
2021-09-10 18:49:52 <mps> most regex tools I saw are gui/visual ones
2021-09-10 18:54:02 <minimal> that check-regexp tool seems ok, based on 5mins testing of it
2021-09-10 21:55:34 <maxice8> mps: go passed in 3.14 CI
2021-09-11 00:41:19 <adamplumb> i've been having an issue on pmOS/edge where the pulseaudio package keeps getting purged, and i'm not sure when or why.  I run `apk upgrade -a` and that puts it right back and sound works again, but it seems every other time i reboot (not sure what triggers it yet) the pulseaudio package gets removed
2021-09-11 01:12:37 <adamplumb> after talking in pmos channel, i ran `apk add !pipewire-pulse` and removed that package and hopefully that will resolve the issue
2021-09-11 05:32:15 <Ariadne> heads up: openssl 3 is entering alpine edge.  this is probably going to result in some weirdness for a little bit.  thank you for your patience.
2021-09-11 05:51:09 <andypost> maxice8, 3.14 go finally passed
2021-09-11 07:17:23 <maxice8> andypost: thanks for the headsup gonna make a go-world rebuild for 3.14 MR
2021-09-11 07:24:28 <andypost[m]> maxice8: as I got it passed after 5 restarts(
2021-09-11 07:28:08 <maxice8> thank you
2021-09-11 07:38:29 <andypost> Ariadne, looks CI runners wont pick jobs
2021-09-11 07:38:36 <Ariadne> cool
2021-09-11 07:38:51 <Ariadne> i can't do anything about that :(
2021-09-11 07:39:31 <andypost> Probably 2 big rebuilds running - go and ruby
2021-09-11 07:39:47 <Ariadne> oh, the CI is starting to catch up
2021-09-11 07:39:49 <Ariadne> its just lagged
2021-09-11 07:41:00 <Ariadne> thankfully, the rebuild is going mostly smoothly :)
2021-09-11 08:33:36 <maxice8> ok to push stuff to edge ?
2021-09-11 09:15:58 <Ariadne> go for it
2021-09-11 09:16:04 <Ariadne> i mean its not getting built anytime soon
2021-09-11 09:16:13 <Ariadne> if you want to work on something useful
2021-09-11 09:16:14 <Ariadne> please move
2021-09-11 09:16:17 <Ariadne> - py3-cryptography
2021-09-11 09:16:20 <Ariadne> - py3-paramiko
2021-09-11 09:16:23 <Ariadne> - ansible-base
2021-09-11 09:16:24 <Ariadne> - ansible
2021-09-11 09:16:26 <Ariadne> to community
2021-09-11 09:16:42 <Ariadne> unfortunately, we will not be able to continue supporting them in main, because the only maintained version of py3-cryptography depends on rust
2021-09-11 09:16:49 <Ariadne> thanks "rewrite it in rust" hacker news crowd
2021-09-11 09:16:51 <Ariadne> love you very much
2021-09-11 09:17:43 <alexeymin> hello alpine devs, any1 can explain weird CI failure at https://gitlab.com/postmarketOS/pmaports/-/jobs/1581999747 ? simple CI job that uses alpine:edge docker image fails at  "apk -q upgrade"
2021-09-11 09:17:54 <mps> rust hype reminds me of the java hype when it was new lang, everything will be in java :D
2021-09-11 09:18:42 <mps> and java 'is' safe lang 
2021-09-11 09:18:44 <Ariadne> alexeymin: because we are working to migrate
2021-09-11 09:18:48 <Ariadne> alexeymin: to openssl 3
2021-09-11 09:18:54 <alexeymin> oh no
2021-09-11 09:19:02 <Ariadne> you will just need to be patient
2021-09-11 09:19:12 <Ariadne> or perhaps refresh your alpine:edge image
2021-09-11 09:19:16 <alexeymin> I thought it has to do something with openssl3
2021-09-11 09:19:32 <Ariadne> or perhaps disable https for your repos
2021-09-11 09:19:49 <Ariadne> problem is, you have openssl1.1 apk-tools, but openssl 3 config file
2021-09-11 09:20:18 <alexeymin> I think alpine:edge docker image that gitlab.com CI is using is not under our control
2021-09-11 09:20:33 <Ariadne> well, thats all i can tell you
2021-09-11 09:20:52 <Ariadne> i am working to get this done as fast as possible
2021-09-11 09:21:08 <alexeymin> np, ofc we can be patient, for how long approximately do you expect it to be broken
2021-09-11 09:22:02 <Ariadne> HOW THE FUCK SHOULD I KNOW
2021-09-11 09:22:23 <Ariadne> you are literally asking about something we do not control
2021-09-11 09:22:38 <mps> my instinct say it will take 'some' time
2021-09-11 09:22:40 <alexeymin> ok, calm down.. I think nothing urgent is happening right now :)
2021-09-11 09:23:14 <mps> 
ACTION remembering switch from libress

2021-09-11 09:23:22 <Ariadne> openssl migrations are always complicated
2021-09-11 09:23:22 <mps> libressl*
2021-09-11 09:23:25 <Ariadne> just be patient
2021-09-11 09:23:33 <Ariadne> it will be done when its done
2021-09-11 09:23:40 <Ariadne> about halfway there with main
2021-09-11 09:23:50 <Sheila> there isn't a timeframe because there really isn't any telling what's going to break or not.
2021-09-11 09:23:59 <Sheila> if you wanted something stable, you should not have picked edge.
2021-09-11 09:24:22 <Ariadne> indeed, you might try alpine:3.14 as workaround
2021-09-11 09:24:23 <Ariadne> for now
2021-09-11 09:24:37 <alexeymin> that's probably what I'll do now, thx
2021-09-11 09:32:00 <Ariadne> most likely, once we get a full build for main it will be fixed
2021-09-11 09:32:14 <Ariadne> you may have to wait for gitlab to refresh their image though
2021-09-11 09:43:18 <Ariadne> thank u maxice8 
2021-09-11 09:44:21 <maxice8> no worries, just ping if you need any help (within reason, I don't know C)
2021-09-11 09:57:44 <Ariadne> okay
2021-09-11 09:57:47 <Ariadne> welp
2021-09-11 09:57:58 <Ariadne> this was fun i guess
2021-09-11 10:02:25 <Ariadne> thanks mariadb
2021-09-11 10:04:13 <andypost[m]> looks there's no much attention https://jira.mariadb.org/browse/CONC-503
2021-09-11 10:05:09 <Ariadne> yeah
2021-09-11 10:05:20 <Ariadne> we'll have to take some things back to openssl 1.1
2021-09-11 10:05:26 <Ariadne> let me see if i can figure out alexeymin's issue
2021-09-11 10:11:09 <Ariadne> aha.
2021-09-11 10:12:54 <Ariadne> alexeymin: i have a fix
2021-09-11 10:13:05 <Ariadne> and, a workaround
2021-09-11 10:13:34 <Ariadne> alexeymin: copy /etc/ssl/cert.pem to /etc/ssl1.1/cert.pem
2021-09-11 10:14:26 <Ariadne> fixed openssl1.1 transitional package will be pushed shortly
2021-09-11 10:33:11 <alexeymin> for now I commented "apk upgrade" command in gitlab-CI script. Turns out if you don't try to upgrade, it works fine
2021-09-11 10:34:04 <wener> seems del/upgrade go will not sync /usr/lib/go/ cause this issues https://github.com/golang/go/issues/43320
2021-09-11 10:35:08 <wener> after manual rm & del then install, works now
2021-09-11 10:46:17 <alandiwix> mps: libudev-zero hotplugging stopped working after latest update for me. I believe (correct me if I'm wrong) they implemented "fileless hotplug" and we now need a helper program to handle events. Do we have it compiled in the repositories?
2021-09-11 10:46:51 <Ariadne> i see a big rant about rust in the near future
2021-09-11 10:50:00 <mps> alandiwix: hmm, have to check, last few days I made a big mess with my /etc/mdev.conf playing with usb-modeswitch
2021-09-11 10:54:59 <mps> alandiwix: could be that we need helper program by default now
2021-09-11 10:55:43 <mps> will check tomorrow, now I'm busy with some non-computer related tasks
2021-09-11 10:59:46 <Cogitri[m]> Ariadne: how come?
2021-09-11 10:59:55 <Ariadne> how come what
2021-09-11 10:59:57 <Ariadne> oh
2021-09-11 11:00:09 <alandiwix> mps: Ok, many thanks. I quickly looked through the code and they removed anything related to /tmp/.libudev-zero directory and examples in /contrib/ are only about helper.c now.
2021-09-11 11:00:16 <Ariadne> Cogitri[m]: because when we remove openssl 1.1, we will have to make a decision about py3-cryptography
2021-09-11 11:00:40 <Ariadne> Cogitri[m]: and we will have to make that decision about ansible, too
2021-09-11 11:00:57 <Ariadne> we already moved ansible to community, but we will have to restrict ansible to rust-only archs
2021-09-11 11:01:13 <Ariadne> because py3-cryptography is "rewrite it in rust" hell now
2021-09-11 11:02:37 <Cogitri[m]> Ah right
2021-09-11 11:03:48 <Cogitri[m]> So we’ll either have to disable lots of arches or get to bootstrapping Rust on more arches
2021-09-11 11:05:10 <Ariadne> also, legacy openssl sucks
2021-09-11 11:05:22 <Ariadne> there is still dependencies out there which touch openssl internals :(
2021-09-11 11:05:38 <Ariadne> not many, but some
2021-09-11 11:09:02 <mps> alandiwix: np
2021-09-11 11:10:48 <Ariadne> my current pain largely is based around the fact that mariadb touches openssl internals in really filthy ways
2021-09-11 11:12:55 <mps> alandiwix: yes. it must be that. thanks. I will test right now on my chromebook
2021-09-11 11:13:44 <mps> source changes indicates this, (why I didn't looked little more)
2021-09-11 11:14:23 <mps> syncing aports on this slow link takes time
2021-09-11 11:16:03 <alandiwix> @mps well, the didn't provide any warning about the old way to be instantly deprecated, so it was pretty easy to miss
2021-09-11 11:17:10 <mps> do you (or anyone) have idea how to name this helper? 'helper' looks to generic to me
2021-09-11 11:17:37 <mps> libudev-zero-helper?
2021-09-11 11:17:52 <mps> and put it in /sbin
2021-09-11 11:18:18 <alandiwix> yea, looks good to me
2021-09-11 11:18:32 <mps> too generic*
2021-09-11 11:18:58 <mps> (when will those english people learn to write ;) )
2021-09-11 11:19:24 <Ariadne> what does the helper do ?
2021-09-11 11:19:30 <alandiwix> help
2021-09-11 11:19:37 <Ariadne> ...in what way?
2021-09-11 11:21:10 <mps> source is so short, but I still not sure what it actually does
2021-09-11 11:21:30 <mps> Ariadne: https://github.com/illiliti/libudev-zero/blob/master/contrib/helper.c
2021-09-11 11:21:33 <alandiwix> It's triggered by device manager, then some magic happens (I believe it sends uevents to some socket) and next device is recognized by anything using libudev
2021-09-11 11:22:25 <mps> fd = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT);
2021-09-11 11:22:36 <Ariadne> libudev-zero-send-uevent ?
2021-09-11 11:22:58 <mps> you see
2021-09-11 11:24:33 <mps> and I wondered why there is no /tmp/.libudev-zero in last two days, but was busy to look :)
2021-09-11 11:24:43 <alandiwix> helper is just upstream name
2021-09-11 11:24:58 <alandiwix> but whatever
2021-09-11 11:25:53 <mps> yes, libudev-zero-send-uevent is more descriptive
2021-09-11 11:26:42 <mps> but I would prefer to keep upstream 'part' of the name in our naming
2021-09-11 11:27:27 <mps> will ask upstream to maybe rename it
2021-09-11 11:27:38 <alandiwix> would be nice
2021-09-11 11:28:19 <Ariadne> if it is just called "helper"
2021-09-11 11:28:21 <mps> oh, finally downloaded and built. yes, that was it
2021-09-11 11:28:25 <Ariadne> people will be sketched out
2021-09-11 11:28:45 <mps> alandiwix: thanks for reporting this
2021-09-11 11:29:14 <alandiwix> mps: np
2021-09-11 11:30:28 <mps> actually, I build it locally always and renamed it to ludz-helper, but didn't with last upgrade
2021-09-11 11:31:10 <mps> and maybe it should go to /usr/libexec and not to /sbin
2021-09-11 11:40:39 <alandiwix> mps: does it make sense to have it as a separate package?
2021-09-11 11:41:24 <alandiwix> I guess ludz can be used without it
2021-09-11 11:41:53 <alandiwix> with some other device manager, theoretically
2021-09-11 12:35:22 <Ariadne> community needs to be shaken out too
2021-09-11 12:35:23 <Ariadne> but
2021-09-11 12:35:30 <Ariadne> that can wait until after i've slept
2021-09-11 14:08:30 <Hello71> wtf is this #13002
2021-09-11 14:16:19 <Misthios> hmm
2021-09-11 14:16:57 <Hello71> i think it's some nonsense like iSH = alpine, checkra1n = iSH
2021-09-11 14:28:04 <maxice8> can I get op privs ? #alpine-linux is having a situation
2021-09-11 14:32:49 <dalias> iSH ?
2021-09-11 14:34:08 <Hello71> dalias: https://ish.app/
2021-09-11 14:34:18 <Hello71> seen a couple nonsense bugs about it
2021-09-11 14:37:57 <dalias> ah interesting
2021-09-11 14:38:22 <dalias> x86 is an odd choice tho
2021-09-11 14:46:15 <maxice8> 3.14 go:world rebuild :D
2021-09-11 15:03:59 <skarnet> "Linux shell on iOS using a x86 emulator"
2021-09-11 15:04:12 <skarnet> ah yes, because God forbid someone ran Linux on ARM
2021-09-11 15:09:55 <dalias> :-p
2021-09-11 15:11:02 <Hello71> https://news.ycombinator.com/item?id=24862329
2021-09-11 15:14:21 <skarnet> there are always excellent reasons why the world is so insane
2021-09-11 15:14:29 <skarnet> that doesn't change the fact that it's insane
2021-09-11 15:15:22 <dalias> *sigh* HN is so dumb
2021-09-11 15:15:36 <dalias> "so you’re stuck using a pure interpreter, at which point there’s no real benefit to emulating the same architecture you’re running on."
2021-09-11 15:17:44 <dalias> you really want to be interpreting an ISA with simple instruction encoding and smaller register file than the host ISA
2021-09-11 15:18:02 <dalias> on the register file size matter, x86_64 is actually a good choice
2021-09-11 15:18:30 <dalias> you can fit all the x86_64 gprs in aarch64 gprs with room left over for actual working space
2021-09-11 15:18:56 <dalias> but the instruction encoding and sheer number of instructions to emulate is hideous
2021-09-11 15:19:18 <dalias> i think emulating 32-bit ARM would actually be ideal here
2021-09-11 15:19:51 <dalias> or if you want to go wild, sh4 :)
2021-09-11 15:23:59 <Hello71> you do also have to consider whether programs can actually compiled for that arch
2021-09-11 15:26:58 <dalias> :)
2021-09-11 15:27:18 <dalias> yes. 32-bit arm is really the sweet spot here
2021-09-11 15:27:41 <dalias> only 16 gprs, reasonably simple isa to decode, supported as a target by virtually everything (tooling & applications)
2021-09-11 16:07:27 <maxice8> 3.14 builders are full
2021-09-11 18:08:30 <sircmpwn> are we aware that curl is broken
2021-09-11 18:08:39 <sircmpwn> Ariadne?
2021-09-11 18:11:11 <Ariadne> news to me
2021-09-11 18:11:18 <Ariadne> what’s up with it
2021-09-11 18:11:26 <dalias> ?
2021-09-11 18:11:33 <sircmpwn> hm, I'm not sure now
2021-09-11 18:11:37 <sircmpwn> it may be more related to openssl than curl
2021-09-11 18:11:50 <caskd> is it a ssl error?
2021-09-11 18:11:54 <sircmpwn> yeah
2021-09-11 18:11:59 <caskd> yeah then likely yes
2021-09-11 18:12:08 <caskd> i also have problems with openssl in some stuff
2021-09-11 18:12:24 <sircmpwn> youtube-dl gives me certificate verify failed: unable to get local issuer certificate
2021-09-11 18:12:28 <caskd> same here
2021-09-11 18:12:36 <sircmpwn> and I had a problem earlier with some local software I'm building and it was segfaulting somewhere in curl's SSL code
2021-09-11 18:12:37 <Ariadne> oh, that
2021-09-11 18:12:41 <sircmpwn> but that went away after a rebuild
2021-09-11 18:12:58 <caskd> Ariadne: aware of local issuer stuff?
2021-09-11 18:13:10 <Ariadne> there was a little too much innovation by sed when openssl 1.1 compat package was introduced
2021-09-11 18:13:26 <Ariadne> if you update your openssl 1.1 compat to -r3 it should be fixed
2021-09-11 18:13:51 <sircmpwn> has it not hit the mirrors yet?
2021-09-11 18:14:11 <sircmpwn> dl-cdn still has r1
2021-09-11 18:14:47 <Ariadne> ugh
2021-09-11 18:14:49 <Ariadne> hang on
2021-09-11 18:17:03 <Ariadne> sircmpwn: it seems the x86_64 builder was having some issues with nginx, so it didnt make it out yet
2021-09-11 18:17:08 <sircmpwn> can confirm that rebuilding openssl1.1-compat myself fixes the issue
2021-09-11 18:17:29 <Ariadne> yeah it was looking for the cert bundle in /etc/ssl1.1 instead of /etc/ssl
2021-09-11 18:19:02 <Ariadne> so sorry for the inconvenience, i did not want to break edge but openssl 3 is something we really need to get done and the weekend seemed like a good time to do it :(
2021-09-11 18:19:18 <sircmpwn> 
ACTION shrugs

2021-09-11 18:19:20 <sircmpwn> edge is for breaking
2021-09-11 18:19:26 <caskd> ^
2021-09-11 18:19:28 <sircmpwn> but yeah, ideally it would be best to take more care
2021-09-11 18:20:14 <Ariadne> i think overall we did a pretty good job other than the /etc/ssl1.1 mistake which i admit i should have caught
2021-09-11 18:20:31 <Ariadne> sircmpwn: do you mind a PM by the way?
2021-09-11 18:20:38 <sircmpwn> go ahead
2021-09-11 18:25:03 <Ariadne> i have a wish that MariaDB would not touch OpenSSL 0.9 APIs in the year 2021 incidentally
2021-09-11 18:25:21 <Ariadne> did you know that 93% of main builds just fine with OpenSSL 3?
2021-09-11 18:25:40 <Ariadne> but we had to revert half of that back to OpenSSL 1.1 because MariaDB :(
2021-09-11 18:26:00 <caskd> half???
2021-09-11 18:26:02 <caskd> jesus
2021-09-11 18:26:27 <Ariadne> yeah because mariadb depends on curl, and php depend on both curl and mariadb
2021-09-11 18:28:20 <dalias> uhg. could mariadb just be built against a new curl-legacy package? 
2021-09-11 18:28:30 <dalias> (or could mariadb just be fixed?)
2021-09-11 18:30:47 <Ariadne> i assume mariadb will be fixed soon
2021-09-11 18:30:53 <Ariadne> its not like they can just pretend this isnt a thing
2021-09-11 18:39:37 <Ariadne> (i also appreciate the work that andypost did in setting up the compat package, it was his first!)
2021-09-11 18:39:46 <andypost[m]> Btw pgsql also needs 1.1 yet
2021-09-11 18:39:59 <Ariadne> well, pgsql itself doesnt
2021-09-11 18:40:12 <Ariadne> it built just fine after backporting the testsuite fixes
2021-09-11 18:40:21 <andypost[m]> Ah through curl
2021-09-11 18:42:08 <andypost[m]> Sadly only php 8.1 is fixed for 3.0 but it's coming in 2 months
2021-09-11 18:44:01 <Ariadne> ugh, the arm builder ran out of disk
2021-09-11 18:44:48 <andypost[m]> Ariadne: nginx works) but I have no idea how to test uswgi)
2021-09-11 18:44:59 <Ariadne> both work
2021-09-11 18:45:10 <Ariadne> the test is flaky
2021-09-11 18:46:13 <andypost[m]> But what about 5 commits in 1.21.2 link in !25232
2021-09-11 18:49:01 <Ariadne> andypost[m]: yes, if nginx upstream prefers 1.20 be built with openssl 1.1, lets just do it
2021-09-11 19:18:45 <andypost[m]> Ariadne then tests should be enabled !25233
2021-09-11 19:36:34 <maxice8> builders are full
2021-09-11 19:48:20 <Ariadne> yes the arm ones are
2021-09-11 19:48:31 <Ariadne> we will shake out community for openssl 3 after that’s fixed i guess
2021-09-11 19:53:17 <maxice8> I see
2021-09-11 19:53:23 <maxice8> also affecting go:world rebuild on 3.14
2021-09-11 19:56:27 <mps> oh yes, /dev/mapper/vg0-lv_root  875G  831G  140K 100% /
2021-09-11 19:59:28 <mps> now, /dev/mapper/vg0-lv_root  875G  798G   33G  97% /
2021-09-11 19:59:44 <mps> I cleaned it a bit, lets see can I do more
2021-09-11 20:01:51 <mps> ok better /dev/mapper/vg0-lv_root  875G  752G   79G  91% /
2021-09-11 20:02:08 <craftyguy> this big upgrade to openssl3 seems quite intrusive/complicated.. so thank you all for dealing with it :)
2021-09-11 20:02:49 <Ariadne> i will hold back for go
2021-09-11 20:03:03 <Ariadne> craftyguy: openssl upgrade is always a shitshow
2021-09-11 20:03:27 <Ariadne> problem is some people wrote openssl code and then never touch it again until they have to
2021-09-11 20:04:09 <craftyguy> yeah it touches a lot of stuff. i wasn't trying to start trouble, just wanted to say your efforts are appreciated :)
2021-09-11 20:04:34 <Ariadne> yeah i know
2021-09-11 20:05:16 <mps> ok now, /dev/mapper/vg0-lv_root 874.8G    732.1G     98.2G  88% /
2021-09-11 20:14:24 <xordspar0> Ariadne: I read your witchery article and the source code. Awesome work! Those 150 lines of sh pack a punch!
2021-09-11 23:01:47 <dalias> :)
2021-09-11 23:09:27 <skarnet> my next scripting language will be called 'coke'
2021-09-11 23:09:54 <skarnet> "you need 4 lines of coke to achieve that"
2021-09-11 23:10:01 <dalias> :)
2021-09-11 23:55:11 <maxice8> writing list of installed files to '/home/buildozer/aports/main/syslog-ng/src/syslog-ng-3.30.1/modules/python/pylib/install-manifest.txt'
2021-09-11 23:55:13 <maxice8> >>> ERROR: syslog-ng: rootpkg failed
2021-09-11 23:55:13 <maxice8> Killed
2021-09-12 08:11:30 <DylanVanAssche> Is there a way to view the content of .apk packages after building? They are probably archives, but I haven't found a way to inspect the content after building which can be useful for debugging.
2021-09-12 08:12:37 <mps> DylanVanAssche: tar tvf file-ver.apk
2021-09-12 08:16:46 <DylanVanAssche> @mps Thanks! For some reason UI tools don't like it and say unsupported, but I guess that's an UI tool problem :P
2021-09-12 08:17:38 <mps> UI tools? what is it
2021-09-12 08:17:45 <psykose> good old file tells you it's gzip, and then a zcat apk | file - tells you it's tar
2021-09-12 08:17:53 <psykose> the ui tool probably only looked at the extension
2021-09-12 08:18:09 <DylanVanAssche> @mps GNOME Archive Manager 
2021-09-12 08:18:53 <mps> ah, gnome-* (which should be removed from alpine, together with kde ;p )
2021-09-12 08:19:12 <mps> 'Cartago delenda est' ;)
2021-09-12 08:19:32 <DylanVanAssche> @mps Then I'm removed from Alpine as well ;) 
2021-09-12 08:20:10 <mps> DylanVanAssche: heh, not bad idea
2021-09-12 08:21:24 <mps> you will (i guess) install ubuntu and have a better supported gnome and your life will be more pleasant ;)
2021-09-12 08:22:14 <alexeymin> ark open .apk with no problems
2021-09-12 08:33:08 <DylanVanAssche> @mps no ubuntu or whatever, Alpine is so nice in terms of speed, packages, etc. Alpine ships vanilla GNOME/KDE, other distros (except a few) apply changes to it, which I really hate
2021-09-12 08:33:21 <DylanVanAssche> @alexeymin ah good to know, thanks!
2021-09-12 08:33:50 <DylanVanAssche> It's just to quickly verify some stuff like: is X in subpackage Y as I intended in the APKBUILD
2021-09-12 08:38:28 <mps> DylanVanAssche: alpine will lost all these 'good parts' soon because in last two years alpine is trying to be like 'big and user friendly' distros
2021-09-12 08:39:56 <psykose> who knew adding a desktop environment to a distro rendered the whole thing broken and useless
2021-09-12 08:40:18 <mps> I hope someone will fork alpine soon, till it is not to late
2021-09-12 08:41:09 <DylanVanAssche> @mps You can easily install Alpine without all these goodies, it's a bare install like Arch Linux and others. If you don't need them, you can easily skip them.
2021-09-12 08:42:04 <psykose> you are wasting your time trying to reason with this person
2021-09-12 08:42:48 <mps> one of things which forced me switching from debian to alpine was the pulse-audio and then alpine didn't had it, now it is deps for not small number of pkgs
2021-09-12 08:43:15 <mps> and I don't want PA on my machines (also pipewire)
2021-09-12 08:43:33 <DylanVanAssche> @psykose lol :P
2021-09-12 08:44:28 <DylanVanAssche> @mps Whatever floats your boat :P
2021-09-12 08:45:03 <mps> I think sabotage linux or kiss linux will do :)
2021-09-12 08:45:42 <mps> else I will try *BSD as workstations
2021-09-12 08:48:28 <donoban> good morning guys, I read yesterday about some problems with openssl3, is currently "safe" to upgrade edge?
2021-09-12 08:48:42 <psykose> should be fine
2021-09-12 08:49:07 <psykose> mine works- maybe some specific packages are broken
2021-09-12 08:49:44 <donoban> ok, let's try
2021-09-12 08:49:50 <mps> arm arches are not yet built
2021-09-12 08:50:48 <mps> so, if you are using arm machines expect breaks
2021-09-12 08:50:54 <donoban> I'm on x86_64
2021-09-12 09:06:07 <donoban> Speed
2021-09-12 09:06:08 <donoban> 5G speeds will range from ~50 Mbps to over 1 Gbps. The fastest 5G speeds would be in the mmWave bands and can reach 4 Gb/s with carrier aggregation and MIMO. 
2021-09-12 09:06:32 <donoban> wops, wrong window :\
2021-09-12 09:25:00 <Ariadne> mps: arm was able to upload before running out of disk
2021-09-12 09:25:14 <Ariadne> i elected to wait on community until that is fixed
2021-09-12 09:29:46 <mps> hmm, for test I started build kernel there, and it works
2021-09-12 09:32:38 <mps> also noticed two kernel 'crashes' two days ago on the host, maybe host needs cold reboot
2021-09-12 09:37:17 <mps> heh, now we have warnings with kernel build related to openssl upgrade
2021-09-12 09:37:47 <mps> 'linux-5.14/scripts/sign-file.c:89:2: warning: 'ERR_get_error_line' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]'
2021-09-12 09:40:09 <mps> we will have to use openssl1.1-compat for some future
2021-09-12 09:41:30 <mercenary> almost time to go back to libressl?
2021-09-12 09:45:50 <donoban> Error: While pulling app/org.signal.Signal/x86_64/stable from remote flathub: While fetching https://dl.flathub.org/repo/config: [35] SSL connect error
2021-09-12 10:46:13 <Ariadne> mercenary: nah
2021-09-12 10:51:20 <Ariadne> donoban: what openssl1.1-compat version do you have
2021-09-12 10:53:05 <donoban> uhm.. none?
2021-09-12 10:53:15 <donoban> let me check :D
2021-09-12 10:53:54 <donoban> (1/1) Installing openssl1.1-compat (1.1.1l-r3)
2021-09-12 10:54:17 <donoban> still failing
2021-09-12 11:18:50 <andypost[m]> btw it could be caused by missing ciphers, for example site is using tls 1.0
2021-09-12 11:25:46 <Ariadne> curl should be back on 1.1
2021-09-12 11:25:58 <Ariadne> try apk upgrade -Ua
2021-09-12 11:26:41 <Ariadne> andypost i would assume flathub would have their shit together tho
2021-09-12 11:26:55 <Ariadne> maybe not tho if they use a crappy CDN
2021-09-12 11:27:43 <andypost[m]> 
ACTION learned something new everyday, snap vs flatpack

2021-09-12 11:45:53 <Ariadne> heh :)
2021-09-12 18:05:00 <ikke> good day
2021-09-12 18:05:04 <ikke> back from vacation
2021-09-12 18:06:19 <Misthios> wb
2021-09-12 18:06:44 <ikke> thankis
2021-09-12 18:06:53 <Misthios> does anybody know how to depend on linux-*-dev? Like libcxx needs futex.h from linux-lts or linux-edge-dev
2021-09-12 18:08:15 <mps> ikke: \o/
2021-09-12 18:08:55 <mps> Misthios: linux-lts-dev
2021-09-12 18:09:22 <Misthios> does that work if you run edge?
2021-09-12 18:09:32 <mps> ikke: hope you enjoyed it (though it looks like was short)
2021-09-12 18:10:21 <mps> Misthios: yes, not much changed in futex.h
2021-09-12 18:10:29 <Misthios> ah okidoki
2021-09-12 18:10:34 <Misthios> ty
2021-09-12 18:11:08 <mps> linux doesn't often change such things, trying to be backward compatible
2021-09-12 18:15:47 <ikke> mps: yes, it was short (just one week), but I enjoyed it immensely
2021-09-12 18:18:02 <mps> nice
2021-09-12 18:19:21 <Hello71> Misthios: linux-headers.
2021-09-12 18:19:44 <Hello71> it won't work if you add linux-edge-dev and i'm pretty sure linux-lts doesn't even come with any file called futex.h
2021-09-12 18:20:07 <Misthios>  it does (/usr/src/linux-headers-5.14.2-0-edge/arch/arm/include/asm/futex.h 	linux-edge-dev )
2021-09-12 18:20:22 <Misthios> whats the diff between headers and dev?
2021-09-12 18:20:59 <Hello71> linux-edge-dev has a futex.h but it's not directly includable
2021-09-12 18:21:17 <Hello71> and actually i think it should be able to prune those files but meh
2021-09-12 18:21:48 <Misthios> hmm
2021-09-12 18:22:16 <Hello71> hm, no, arch packages arch/x86/include so i think you can only prune unused archs
2021-09-12 18:22:26 <Hello71> would be nice to do if we're going down akms path
2021-09-12 18:24:37 <Hello71> yeah, debian https://packages.debian.org/sid/linux-headers-5.10.0-8-amd64 is 5 MB installed, our https://pkgs.alpinelinux.org/package/edge/main/x86_64/linux-lts-dev is a whopping 131 MB
2021-09-12 18:24:57 <Hello71> ah wait need to count https://packages.debian.org/sid/linux-headers-5.10.0-8-common and https://packages.debian.org/sid/linux-kbuild-5.10
2021-09-12 18:25:10 <Hello71> so debian is like 60 MB and alpine is 130 MB
2021-09-12 18:26:12 <Hello71> huh, but arch is also 131 MB: https://archlinux.org/packages/core/x86_64/linux-headers/
2021-09-12 18:26:20 <Hello71> what's up with that
2021-09-12 18:26:54 <Misthios> hmm
2021-09-12 18:27:13 <Hello71> ah, arch comes with vmlinux
2021-09-12 18:27:23 <Hello71> uncompressed
2021-09-12 18:27:47 <Hello71> alpine doesn't have vmlinux anywhere
2021-09-12 18:28:53 <mps> yes, I always thought that linux-*-dev are to big but never tried to trim them down
2021-09-12 18:29:38 <Hello71> arch https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/PKGBUILD is quite clear
2021-09-12 18:30:07 <Hello71> at some point heftig gave up on make install_headers
2021-09-12 18:30:35 <Hello71> i think about two years ago, around the time of move from tarball to git
2021-09-12 18:30:53 <Hello71> unfortunately abuild has poor support for git
2021-09-12 18:31:12 <mps> Hello71: yes, I have arch alarm git on my local disk and use it sometimes to check our APKBUILDs for kernels
2021-09-12 18:33:47 <mps> I wanted to follow linux-lts and because that didn't tried trimming. maybe I should do that for linux-edge now
2021-09-12 18:42:51 <Hello71> would be good to do for both
2021-09-12 18:44:24 <mps> agree
2021-09-12 18:45:12 <mps> if I find some time next week will start on this
2021-09-12 19:29:15 <dalias> wow looks like https://github.com/nodejs/node/pull/31567 is finally fixed
2021-09-12 19:50:43 <lemontree> -11
2021-09-12 19:51:37 <dalias> ?
2021-09-13 04:01:07 <smcavoy> Hi there, wondering if anyone has tried out linux-lts (armv7) on a Odroid XU4? was about to wipe one and was thinking Alpine would do well on it.
2021-09-13 05:32:43 <mps> smcavoy: I think u-boot works but not sure for kernel
2021-09-13 05:33:45 <mps> you can use u-boot/kernel combo from other distro (armbian for example) and alpine userspace without big problems
2021-09-13 05:54:02 <smcavoy> I used the existing Armbian u-boot to try and boot the linux-lts kernel, no output :( and indeed, boots the Armbian kernel from the Armbian u-boot into a Alpine userspace
2021-09-13 05:55:17 <smcavoy> I did a quick check of the armv7 linux-lts kernel config and exynos support seems to be enabled.. I *thought* the xu4 was fully supported in 5.4+ mainline kernels..
2021-09-13 05:56:28 <mps> smcavoy: I don't have odroids so can't tell anything for sure, but what I read around looks like kernel need some patches to work
2021-09-13 05:56:54 <mps> could you try with linux-edge
2021-09-13 05:58:43 <mps> someone here (DavyLandman[m] iirc) promised will test it when find time
2021-09-13 05:59:20 <mps> we have open issue report for odroid
2021-09-13 05:59:49 <mps> #12931
2021-09-13 06:16:15 <smcavoy> mps: linux-edge boots!
2021-09-13 06:19:25 <mps> smcavoy: ah, good news
2021-09-13 06:22:10 <smcavoy> I updated the issue with the findings.. 
2021-09-13 06:23:36 <smcavoy> a quick search seemed to suggest  building u-boot *seems* to be hassle for the xu4, unlike other arm soc using plain u-boot.. but further investigations might reval otherwise.. 
2021-09-13 06:24:56 <mps> our u-boot should also work, though someone have to test it and report
2021-09-13 06:27:51 <smcavoy> I *think* it needs the bl1/bl2 stuff from hardkernel/samsung and that needs to be combined with the u-boot.bin file. the existing u-boot package does this well with the pine64 systems
2021-09-13 06:30:16 <mps> could be, hope someone will test this
2021-09-13 06:41:35 <maxice8> the builders are back
2021-09-13 06:41:39 <maxice8> what was the issue ?
2021-09-13 06:42:19 <ikke> see #alpine-infra
2021-09-13 06:42:29 <clandmeter> maxice8: mps did rm -rf /do/not/delete/this
2021-09-13 06:42:30 <clandmeter> ;-)
2021-09-13 06:42:42 <mps> :D
2021-09-13 06:42:59 <clandmeter> seriously, it was a shared dir
2021-09-13 06:43:18 <mps> really?
2021-09-13 06:43:21 <clandmeter> somehow this got into lxc comon config
2021-09-13 06:44:40 <ikke> And can we somehow defang husky putting its hooks in aports .git?
2021-09-13 06:44:51 <mps> I wondered why I have so much used space
2021-09-13 06:44:59 <ncopa> good morning
2021-09-13 06:45:23 <clandmeter> but like a famous dutch footballer ones said, every disadvantage has its advantage. we have 100G of free space now.
2021-09-13 06:46:21 <maxice8> gonna continue the 3.14 go:world rebuild then
2021-09-13 06:46:43 <mps> ooooof
2021-09-13 06:47:16 <ncopa> the go:world rebuild is due to thie recent go vulnerability?
2021-09-13 06:47:34 <ncopa> iirc it was in the zip (de)compressor?
2021-09-13 06:48:20 <maxice8> https://groups.google.com/g/golang-announce/c/dx9d7IOseHw
2021-09-13 06:48:43 <maxice8> yes
2021-09-13 06:49:09 <maxice8> it is done on all arches but ARM ones for 3.14, and needs to be done on edge
2021-09-13 06:50:06 <ncopa> theoretically we could: for pkg in go:world: apk add pkg; if strings /usr/bin/binary | grep archive/zip; then rebuild else skip; done
2021-09-13 06:50:24 <ncopa> in any case, thank you for taking care of it
2021-09-13 06:51:03 <maxice8> Might do it for 1.17.1 on edge, thanks for the tip
2021-09-13 07:59:32 <maxice8> Is there a reliable way to list all ELF binaries with apk ? or should I just loop over every file of the package with file -i and check for application/x-executable ?
2021-09-13 08:03:46 <ikke> apk info -P <pkg> | grep -E '^cmd:'?
2021-09-13 08:04:45 <maxice8> I thought about that but there might be binaries installed in /usr/libexec
2021-09-13 08:05:01 <ikke> maybe something with scanelf
2021-09-13 08:06:49 <mps> smcavoy: odroid-xu4 is 64bit?
2021-09-13 08:06:55 <ikke> I don't think apk itself can provide a list of binaries
2021-09-13 08:08:54 <maxice8> yeah, I'm gonna install everything ap revdep gives me then file -i all files at once and grep for application/x-executable and strings each and grep -x archive/zip
2021-09-13 08:14:55 <smcavoy> mps: 32bit
2021-09-13 08:26:06 <mps> according to u-boot doc we don't need ATF for xu3/xu4, but I see that arch linux alarm uses it.
2021-09-13 08:27:15 <mps> and they use one from hardkernel GH repo
2021-09-13 08:55:38 <maxice8> ok the archive/zip method seems to have worked
2021-09-13 08:59:12 <ikke> nice
2021-09-13 09:13:32 <maxice8> needed to grep -v /usr/share from the filelist we get tho
2021-09-13 09:22:07 <ncopa> Cook
2021-09-13 09:22:11 <ncopa> cool
2021-09-13 09:25:19 <maxice8> https://gist.github.com/maxice8/5559138908f3639a38f42b88d6ab676b
2021-09-13 09:27:35 <psykose> that's a lot of pulumi
2021-09-13 09:29:21 <maxice8> multiple binaries present
2021-09-13 09:49:21 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/485943 ppc64le go1.17.1 failing with this
2021-09-13 13:14:16 <minimal> dalias: musl doesn't appear to provide definitions for sysconf-related things like _SC_LEVEL1_DCACHE_SIZE and _SC_LEVEL2_CACHE_SIZE. For glibc systems these appear to come from /usr/include/bits/confname.h. Is this by intention?
2021-09-13 13:19:33 <dalias> i'm not sure how intentional this specific item is, but generally we avoid adding things that have little chance of being portable or meaningful on other systems
2021-09-13 13:19:56 <dalias> iirc it never came up before
2021-09-13 13:20:18 <dalias> if it were supported, would auxv suffice to get values or would it require some procfs/sysfs parsing mess?
2021-09-13 13:20:51 <minimal> dalias: ok, was working on packaging up latest version of something I maintain and new version is using these defs. I'll raise an issue with upstream, just wasn't sure if they were glibc-isms or not
2021-09-13 13:22:11 <minimal> Its a C library rather than shell code - jitterentropy-library
2021-09-13 13:25:06 <minimal> dalias: https://github.com/smuellerDD/jitterentropy-library/blob/master/jitterentropy-base-user.h#L235
2021-09-13 13:37:35 <elibrokeit> Hmm, I heard through the grapevine that y'all are looking at muon as a potential meson replacement :p
2021-09-13 13:39:48 <maxice8> I was looking at it for openrc since it switched to meson and is a very base dependency
2021-09-13 13:40:01 <maxice8> also applies to anything before python3 can be compiled
2021-09-13 13:40:37 <dalias> having openrc be a really base dependency is kinda a mistake imo
2021-09-13 13:41:14 <dalias> openrc is a near-root dependency for "booting running services"
2021-09-13 13:41:29 <dalias> but it's not a dependency at all for building software, running in a chroot/light container, etc.
2021-09-13 13:41:52 <ikke> We do use it for the builders, though
2021-09-13 13:42:15 <elibrokeit> (meson developer here) I'm pretty excited about muon as I think having multiple implementations is a sign of maturity and having an actual spec, and also I'd like something more bootstrappable myself.
2021-09-13 13:42:51 <dalias> excellent
2021-09-13 13:42:52 <elibrokeit> Although you'll need to post muon patches to implement "install" if you want to use muon for packaging any time soon.
2021-09-13 13:43:52 <dalias> using python for what it was made for, rapid prototyping *ducks*
2021-09-13 13:43:56 <dalias> ;-)
2021-09-13 13:46:52 <elibrokeit> I don't believe the need for a python reference implementation of meson will go away any time soon ;) it will inevitably be the only thing that has the very very latest meson.build API and probably the most comprehensive module support.
2021-09-13 13:46:52 <elibrokeit> But having a C11 version that maybe lags behind a couple versions that most people don't use because they need to be compatible with the version of meson in debian stale, will hopefully end up covering most cases.
2021-09-13 13:47:24 <elibrokeit> Most early system dependencies aren't exactly going to use modules anyway...
2021-09-13 13:48:55 <mps> :]
2021-09-13 14:01:49 <skarnet> the fact that those build systems and dependencies discussions have come up again and again
2021-09-13 14:01:51 <skarnet> and again
2021-09-13 14:01:53 <skarnet> and again
2021-09-13 14:02:08 <skarnet> is reason enough to make sure build systems have the least possible amount of dependencies
2021-09-13 14:02:18 <skarnet> so they can be universally used
2021-09-13 14:02:41 <skarnet> it is INCREDIBLY FUCKING STUPID to have a build system pull in a kitchen sink of dependencies and programming languages and packages and whatnot
2021-09-13 14:03:10 <mps> :)
2021-09-13 14:03:31 <skarnet> I may be an old man yelling at a cloud but this cloud has been harming computer engineering for decades
2021-09-13 14:03:44 <skarnet> and if you haven't noticed it has, you haven't been paying attention
2021-09-13 14:04:00 <skarnet> this things have REAL COSTS
2021-09-13 14:04:04 <skarnet> these*
2021-09-13 14:04:25 <streampunk> dalias: contract work usually ends with the prototype, because the customer won't pay more. because of that everything is so broken.
2021-09-13 14:04:43 <skarnet> not the least of which is the engineer time that is wasted discussing how to manage the forest of dependencies in order to be able to build the damn thing that is supposed to help you build the real thing you're interested in
2021-09-13 14:05:00 <mps> most of these 'modern' build systems irritates me, also
2021-09-13 14:05:34 <skarnet> mps: I know you are sensitive to that, but I wish *other people* were, too
2021-09-13 14:06:37 <mps> I 'feel' that other who feels like you and me are shy to say their opinions publicly
2021-09-13 14:07:41 <mps> valerius: ^ ;)
2021-09-13 14:08:04 <mercenary> mps: the bad news is, not all possible combinations of features have been tried. In another discussion about build systems I got given this https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf
2021-09-13 14:08:37 <streampunk> making "internal" API calls over the network instead of in-process is a big waste of energy and make everything sloooooow.
2021-09-13 14:09:04 <mps> mercenary: thanks, but today is not good day for me to read microshit docs
2021-09-13 14:09:54 <mercenary> more research than docs, but I also put it on the 'to read later' list
2021-09-13 14:10:28 <mps> I'm already irritated by linux-5.15-rc1 headlines around, most important new things are related to ms, new ntfs driver and kernel smbd daemon
2021-09-13 14:11:12 <mps> looks like kernel community works nowadays for ms, google, amazon ....
2021-09-13 14:11:56 <mps> and, btw it doesn't boot my elm chromebook, which works with 5.14
2021-09-13 14:12:06 <mercenary> Like it or not, industry and business world excluding hyperscalers still revolve around microsoft :p
2021-09-13 14:12:10 <mps> 'nice progress'
2021-09-13 14:22:52 <elibrokeit> skarnet: meson tries to limit the damage this can do, by declaring that whole python is a dependency for obvious reasons, meson shall never under any circumstances add third-party python modules as a dependency, no matter how tempting or useful
2021-09-13 14:23:48 <elibrokeit> We would even like to in the long term get rid of setuptools, which is a build dependency that you can get around by running meson.py.from the root of the source tree
2021-09-13 14:25:06 <ericonr> 
ACTION has done that when experimenting with making changes

2021-09-13 14:26:32 <ericonr> minimal: am I missing something there? they already support fallback code for when those sysconf defines aren't available, via parsing `#define JENT_SYSFS_CACHE_DIR "/sys/devices/system/cpu/cpu0/cache"`
2021-09-13 14:27:18 <ericonr> 
ACTION still doesn't understand the purpose of userspace jitterentropy

2021-09-13 14:27:20 <elibrokeit> ericonr: (so do I)
2021-09-13 14:27:58 <sircmpwn> fucking openssl
2021-09-13 14:28:16 <skarnet> may be a health hazard
2021-09-13 14:29:08 <sircmpwn> I sure love having my work completely derailed by external forces
2021-09-13 14:47:07 <Ariadne> 8:37 AM <elibrokeit> Hmm, I heard through the grapevine that y'all are looking at muon as a potential meson replacement :p
2021-09-13 14:47:17 <Ariadne> no, just for building stuff in the bootstrap set
2021-09-13 14:48:51 <Ariadne> and, yes, muon needs additional functionality like `install` before it can be used
2021-09-13 14:50:41 <minimal> ericonr: compilation is failing with the like of: error: '_SC_LEVEL1_DCACHE_SIZE' undeclared
2021-09-13 14:53:46 <psykose> -D _SC_LEVEL1_DCACHE_SIZE=1
2021-09-13 14:53:47 <psykose> fix'd
2021-09-13 14:53:59 <psykose> smol cache
2021-09-13 14:56:56 <ericonr> minimal: the code is https://github.com/smuellerDD/jitterentropy-library/blob/829273054570b8bd88c8d0100c45218123a6a840/arch/jitterentropy-base-x86.h#L118 then
2021-09-13 14:57:03 <ericonr> (and for other archs)
2021-09-13 14:57:18 <ericonr> The link you shared gated it appropriately
2021-09-13 15:19:47 <maxice8> !25304
2021-09-13 15:33:33 <Ariadne> please hang on with that
2021-09-13 15:35:52 <maxice8> ok
2021-09-13 15:49:56 <Ariadne> andypost[m]: once the rebuilds i pushed for main are done, you can check things against openssl 3 or openssl 1.1 in CI for community
2021-09-13 15:50:12 <Ariadne> there are ~140 packages or so that need to be checked
2021-09-13 15:57:30 <Ariadne> maxice8: once the cleanups (and also downgrades for php) in main are done, go ahead and push it
2021-09-13 16:01:58 <maxice8> ok
2021-09-13 16:23:54 <elibrokeit> Ariadne: I see, makes sense.
2021-09-13 16:45:30 <dalias> psykose, that's not the size it's the queried property
2021-09-13 16:45:45 <dalias> defining it to 1 will make it return CHILD_MAX
2021-09-13 17:15:36 <ncopa> make: Leaving directory '/home/ncopa/aports/main/linux-lts/src/linux-5.10'
2021-09-13 17:15:36 <ncopa> Illegal instruction
2021-09-13 17:16:00 <ncopa> looks like something is broke recently
2021-09-13 17:17:11 <mps> worked for me with building linux-edge
2021-09-13 17:17:33 <ncopa> on aarch64?
2021-09-13 17:17:37 <mps> had to add openssl1.1-compat-dev
2021-09-13 17:17:42 <ncopa> this is x86_64
2021-09-13 17:17:51 <mps> on both
2021-09-13 17:18:10 <mps> in lxc containers
2021-09-13 17:18:21 <ncopa> did you add openssl1.1-compat-dev or replaced openssl-dev?
2021-09-13 17:18:34 <mps> replaced, ofc
2021-09-13 17:19:52 <mps> not sure if that is solution because I replaced it before started build
2021-09-13 17:20:14 <ncopa> yup. that seems to solve it
2021-09-13 17:20:42 <ncopa> I think I need to investigate this closer
2021-09-13 17:21:10 <ncopa> but its definitively openssl-3.0 that does it. thank you for pointing me in right direction mps
2021-09-13 17:22:20 <mps> though I built linux-elm-5.14.3 with openssl3, but was unsatisfied with warning and switched to old openssl
2021-09-13 17:22:35 <mps> warnings*
2021-09-13 17:23:26 <mps> I expected a lot of breakage with such important change as is new openssl
2021-09-13 17:23:40 <mps> but that is normal, all is ok
2021-09-13 17:25:58 <ncopa> actually, i might have had some openssl 1.1 leftovers there
2021-09-13 17:26:56 <ncopa> it works now
2021-09-13 17:39:27 <durrendal> ncopa: no rush, but would you mind taking a look at MR!25207 when you have a moment? Trying to see if we can add libfido2 support to openssh, but I want to know if adding that should also add a without libfido subpackage like we do for kerberos support
2021-09-13 17:42:30 <ncopa> durrendal: i saw the MR but havent had time to respond. will try take a closer look today
2021-09-13 17:45:11 <elibrokeit> Ariadne: found the quote I was looking for...
2021-09-13 17:45:11 <elibrokeit> [01:49:59 PM] <lattis> I'm currently postponing all things installation, so I could just provide a dummy implementation for now
2021-09-13 17:45:11 <elibrokeit> [01:49:16 PM] <lattis> I see.  Is there a way to use the generated pkg-config files at build type, or is this something that would get installed only?
2021-09-13 17:45:44 <Ariadne> okay?
2021-09-13 17:45:53 <elibrokeit> If you want muon to handle installation sooner rather than later, patches would be best or it may take a while
2021-09-13 17:45:57 <Ariadne> we will just maintain openrc 0.44.x forever
2021-09-13 17:46:07 <Ariadne> its no problem
2021-09-13 17:46:26 <Ariadne> s6 will be ready by 2025
2021-09-13 17:46:35 <Ariadne> i can maintain openrc 0.44.x until then
2021-09-13 17:46:51 <Ariadne> i'm not in any hurry
2021-09-13 17:50:00 <durrendal> ncopa: no worries! I just wanted to make sure it was seen. When you get to it I'll jump on it, so if you don't find time today that's fine!
2021-09-13 17:55:08 <ncopa> so, exactly what is libfido2 support (sorry for being lazy and not google it..)
2021-09-13 17:55:26 <ncopa> or more specific, what benefit does it bring to alpine
2021-09-13 17:56:23 <ncopa> ok. use of yubico keys
2021-09-13 17:56:39 <minimal> ncopa: newest generation of U2F for 2FA
2021-09-13 17:57:03 <ncopa> is it for a single vendor or are there multiple vendors producing those dongles?
2021-09-13 17:57:18 <jvoisin> multiple vendors
2021-09-13 17:57:22 <minimal> FIDO is an industry group
2021-09-13 17:57:27 <jvoisin> like https://www.nitrokey.com/
2021-09-13 17:57:42 <ncopa> ok
2021-09-13 17:57:58 <Ariadne> it would be good if openssh gained this actually
2021-09-13 17:58:05 <ncopa> yeah
2021-09-13 17:58:12 <ncopa> im checking the "cost" now
2021-09-13 17:58:15 <ncopa> its only 200k
2021-09-13 17:58:16 <jvoisin> it's already in openssh iirc
2021-09-13 17:58:50 <ncopa> oh, it pulls in libudev
2021-09-13 17:58:58 <jvoisin> I mean, support is in openssh, maybe not in alpine itself. See https://developers.yubico.com/SSH/
2021-09-13 17:59:17 <minimal> ncopa: reasonable explanation: https://www.stavros.io/posts/u2f-fido2-with-ssh/
2021-09-13 17:59:20 <durrendal> ncopa: yep you got it, it adds 2FA support for openssh. This change should make it work out of the box like it does in Debian 
2021-09-13 18:00:18 <ncopa> ok, my general thinking here is that we want this. question is how
2021-09-13 18:00:47 <durrendal> :D glad to hear it, and to know that I'm not the only one wondering how haha
2021-09-13 18:01:45 <durrendal> my initial guess was that since it was pulling in libudev, and it isn't necessary for ssh to work itself, that we'd probably want a _do_configure to build it without libfido2, but to put it in the base package since it's a good feature to have
2021-09-13 18:02:00 <durrendal> but it isn't my package, I just know I want 2FA ssh on Alpine :)
2021-09-13 18:02:35 <ncopa> yeah. understand
2021-09-13 18:02:41 <ncopa> i think this is a bit tricky
2021-09-13 18:04:33 <ncopa> so, we could just add the dep. it seems to pull in totally ~400k extra deps
2021-09-13 18:04:42 <ncopa> which might be around the limit
2021-09-13 18:05:05 <ncopa> but then it pulls in libudev, which means that it will likely not work at all unless udev is running
2021-09-13 18:05:56 <ncopa> hm
2021-09-13 18:06:05 <Hello71> libudev-zero would be ok i think, but unfortunately we're not there yet
2021-09-13 18:06:18 <minimal> I assume the udev pull is for the udev rules to spot such devices
2021-09-13 18:06:33 <ncopa> but that would require that libudev-zero was running, right?
2021-09-13 18:06:47 <Hello71> libudev-zero doesn't come with daemon
2021-09-13 18:06:48 <durrendal> yeah that's all it does, libfido2 provides a set of udev rules to pickup the keys
2021-09-13 18:06:52 <minimal> so if mdev equivalent rule(s) were added to mdev would that be sufficient?
2021-09-13 18:07:44 <Hello71> or, more precisely, libudev-zero doesn't need daemon except for hotplug
2021-09-13 18:08:20 <Hello71> which i think shouldn't be relevant unless you try to log in and then plug key in the middle of logging in
2021-09-13 18:08:30 <durrendal> potentially, as long as the fido devices can be accessed at /dev/hiddraw they should work.
2021-09-13 18:08:55 <durrendal> Hello71: from what I've seen you have to have the key plugged in before you initiate your ssh session so that it can sign the ssh key
2021-09-13 18:09:11 <ncopa> i think that might need some investigation
2021-09-13 18:09:21 <Hello71> i'm not sure how it works, maybe there is a mode where it prompts you and then you can plug in then
2021-09-13 18:09:26 <ncopa> how to make it work without depending on libudev
2021-09-13 18:09:31 <Hello71> but anyways we shouldn't focus on that
2021-09-13 18:10:05 <ncopa> im thinking that maybe we could add it to the krb5 build?
2021-09-13 18:10:40 <ncopa> so if you want libfido2 support, install the openssh-server-krb5
2021-09-13 18:10:51 <ncopa> or maybe with openssl-server-pam
2021-09-13 18:11:07 <ncopa> instead of adding yet another flavor
2021-09-13 18:12:35 <ncopa> i think it might make sense to add it with openssh-server-pam
2021-09-13 18:12:51 <psykose> is it possible to have openssh-server use fido 2fa at all without pam?
2021-09-13 18:13:12 <ncopa> thats absolutely a good question
2021-09-13 18:13:36 <Hello71> last i checked, new fido implementation is supposed to be transparent to server
2021-09-13 18:15:25 <psykose> the example 'guides' all seem to just enable *-sk accepted keytypes and it works, so i guess it would
2021-09-13 18:16:58 <minimal> yeah I'd expect it would just add the -sk stuff to the list to be negotiated in the SSH handshake with the server
2021-09-13 18:17:35 <Hello71> seems only needs to split ssh-sk-helper
2021-09-13 18:24:57 <psykose> on gentoo building with +security-key adds ssh-sk-helper which links to libudev, the main sshd binary still doesn't link to it though
2021-09-13 18:25:03 <Hello71> i think possibly some inconvenience to those who want to use "current" implementation
2021-09-13 18:25:12 <psykose> deleting it still starts sshd fine and accepts connections, so i guess it's fine to subpackage it
2021-09-13 18:25:13 <Hello71> but should be ok
2021-09-13 18:26:05 <ncopa> oh, that sounds promising
2021-09-13 18:26:35 <durrendal> that sounds very very promising!
2021-09-13 18:32:29 <mps> please keep base openssh as it is now, and add this wherever else you want 
2021-09-13 18:39:26 <Hello71> mps: the whole point of this discussion is to avoid adding runtime deps for openssh
2021-09-13 18:40:31 <mps> Hello71: good then, and thanks ;)
2021-09-13 18:42:14 <psykose> a quick glance at the code only uses that helper on use of sk-related things (verifying an sk key, generating one) and fails with a helper not found at path error, doesn't seem that it would be triggered on regular usage unless someone enabled sk-keys and tried to connect with one
2021-09-13 18:43:19 <Hello71> durrendal: fwiw i think it's falling on you to write the subpackage code. it is good learning experience anyways. you can look at other packages (grep -r subpackage aports) for examples, it should only be about 5 lines added to APKBUILD
2021-09-13 18:43:35 <psykose> the errors end up in sshfatal() or somesuch that exits, probably not a great experience
2021-09-13 18:45:38 <durrendal> Hello71: no worries, I fully expected that. I just wanted the discourse on it so I knew how best to approach it. If it was one of my own packages I'd just make the changes and move on
2021-09-13 18:46:49 <Hello71> it would also be good to test what happens in the case where user needs to install ssh-sk-helper separately, as psykose says. we have too many inscrutable errors due to subpackages already, it would be good to try not to make more
2021-09-13 18:48:56 <durrendal> I agree, I'm now curious too if there might also be issues if pam is missing or something like that. I'm not familiar with mdev, but I'll try and add mdev rules to the libfido2 package as well so that we can test that as well
2021-09-13 18:50:11 <Hello71> i think the whole point of integrating fido2 is that it doesn't need pam anymore
2021-09-13 18:50:17 <Hello71> but sure, it is worth testing
2021-09-13 18:50:24 <psykose> it does just look like it's only on sk usage, so it would just be a case of the forked connection crashing and not succeeding, and that's the only part where the ssh keys get used anyway
2021-09-13 18:50:39 <psykose> if it returned a helpful error on connection failure it would be nice, i don't know what it would do currently
2021-09-13 18:50:54 <psykose> you can go and test :)
2021-09-13 18:51:01 <psykose> sadly i don't have one of these keys
2021-09-13 18:51:45 <durrendal> I've got a yubikey and a titan key somewhere, so I'll at least test what I can and go from there. I will say I appreciate the support from everyone :)
2021-09-13 18:51:54 <psykose> best of luck
2021-09-13 19:03:28 <ncopa> durrendal: thank you for following up!
2021-09-13 19:03:42 <ncopa> im gonna call it a day. have a nice evening everyone
2021-09-13 19:03:53 <Misthios> cya
2021-09-13 19:04:35 <ikke> 👋
2021-09-13 19:08:08 <minimal> Ariadne: cloud-init doas support ready to be merged :-)
2021-09-13 19:08:15 <Ariadne> hooray
2021-09-13 19:08:18 <ikke> nice
2021-09-13 19:09:09 <minimal> don't think there's any point trying to upstream it until opendoas releases with doas.d support
2021-09-13 19:09:23 <Ariadne> do you have an MR?
2021-09-13 19:09:29 <Ariadne> and yes, no need to upstream it
2021-09-13 19:09:44 <minimal> !25308
2021-09-13 19:11:10 <durrendal> ncopa: thanks for taking the time to give some guidance, it's truly appreciated! Have a good night!
2021-09-13 19:42:22 <Ariadne> minimal: i merged it
2021-09-13 20:35:39 <mepholic> cool, hopefully they take that patch upstream
2021-09-13 21:48:03 <mcf> fwiw, libfido2 uses libudev only to scan for hidraw devices. it doesn't depend on a running udevd or any sort of hotplug mechanism, just that the fido hidraw devices can be accessed by the user. i think it should work fine with libudev-zero
2021-09-13 21:51:08 <mcf> in my libfido2 branch i just patched hid_linux.c to just scandir("/dev") for hidraw* (with a delta of +42 -77). perhaps i should try to submit that upstream as hid_linux_sysfs.c or something
2021-09-13 21:53:33 <Hello71> are you sure it doesn't depend on udevd? i thought the libudev enumeration would just be empty
2021-09-13 21:53:48 <Hello71> otherwise what's the point of libudev-zero
2021-09-13 21:54:41 <Hello71> yes, i also think it doesn't really need libudev, but maybe easier to switch to libudev-zero instead of patching every package
2021-09-13 22:01:41 <mcf> libfido2 only uses the udev_enumerate api, which basically amounts to scanning sysfs
2021-09-13 22:04:00 <mcf> i think both the real libudev and libudev-zero do essentially the same thing there
2021-09-13 22:10:58 <mcf> though the real libudev supports things like matching tags which depend on /run/udev/tags populated by udevd. but libfido2 only matches against SUBSYSTEM=hidraw (i.e. ls /sys/class/hidraw)
2021-09-13 22:26:00 <Hello71> hm, i think you are right
2021-09-14 06:47:29 <ncopa> good morning
2021-09-14 06:51:51 <ikke> o/
2021-09-14 06:55:02 <Misthios> gm
2021-09-14 07:06:51 <mps> ave!
2021-09-14 07:30:57 <mps> last night I tested armv7 userspace on arm64 chromebook. mpv load is about 10-15 percents less and memory 'gain' is about 20%
2021-09-14 07:31:42 <mps> firefox is more 'smooth'
2021-09-14 07:32:02 <mps> even boot is faster
2021-09-14 07:34:00 <mps> I gcc thumb2 (default on alpine armv7) also helped to this
2021-09-14 07:34:11 <mps> I think*
2021-09-14 08:19:02 <psykose> the 32bit binaries run that much better than the 64 ones? sounds strange
2021-09-14 08:34:19 <Ariadne> for thumb it makes sense
2021-09-14 08:35:22 <xsteadfastx> oh i try to upgrade the notmuch package, but so many tests fail in check command
2021-09-14 08:40:03 <mps> psykose: less bits/bytes to fetch from ram (more cpu cache) and less bits to decode
2021-09-14 08:40:40 <psykose> i see
2021-09-14 09:17:33 <donoban> that's interesting
2021-09-14 11:29:45 <Misthios> how would abuild prepare for a static package fail if the normal package builds fine?
2021-09-14 11:30:13 <Misthios> >>> ERROR: lld-static*: prepare_package failed (it worked fine last time, only change is depending on llvm-libunwind now)
2021-09-14 11:34:55 <Ariadne> later today, we will begin opportunistic rebuilds of packages that can be rebuilt against openssl 3 in edge/community.  this may result in some packages temporarily becoming uninstallable as the rebuild process proceeds.  thanks in advance for your patience.
2021-09-14 12:10:06 <Cogitri[m]> Misthios: It fails when there are no static libs around
2021-09-14 12:12:09 <Misthios> ah
2021-09-14 12:12:29 <Misthios> btw i should be almost done now (after 2 week )
2021-09-14 15:48:38 <ikke> openjdk 17 (LTS) has been released
2021-09-14 15:50:39 <ikke> Oracle JDK 17*
2021-09-14 16:08:12 <danieli> alpine doesn't ship oracle's jdk builds, does it?
2021-09-14 16:08:28 <ikke> no, only openjdk
2021-09-14 16:08:37 <ikke> But they are related
2021-09-14 16:08:58 <ikke> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006037.html "GPL-licensed OpenJDK builds from Oracle are available here:
2021-09-14 16:09:00 <ikke> "
2021-09-14 16:25:10 <Misthios> how does this happen: >> lld-dev*: Preparing subpackage lld-dev... /usr/bin/abuild: cd: line 2461: can't cd to /builds/Misthios/aports/community/lld/pkg/lld-dev: No such file or directory. the building worked fine before i added a dep on llvm-libunwind which made this happen????
2021-09-14 16:26:06 <maxice8> that means it could not find any files that are supposed to be in -dev subpackages to be put there, check the pkg directory
2021-09-14 16:33:02 <danieli> i mean yeah, they are of course related, but if i see 'oracle' i have to double check
2021-09-14 16:33:11 <danieli> everything they touch turns to shit, especially when it comes to open source
2021-09-14 16:34:28 <Misthios> ah ty maxice8
2021-09-14 16:53:35 <Hello71> technically both OpenJDK 17 and Oracle JDK 17 were released today
2021-09-14 16:53:59 <ikke> right
2021-09-14 16:54:25 <Hello71> it's not possible for alpine to ship oracle jdk because there's no oracle jdk for alpine
2021-09-14 16:54:38 <Hello71> but we also don't ship openjdk openjdk builds, we use our own
2021-09-14 16:56:07 <Hello71> in fact i'm not sure any distros use openjdk openjdk builds? i thought everybody uses adoptopenjdk^Wadoptium ugh
2021-09-14 16:56:53 <danieli> there was project portola too, haven't kept up with it in a while
2021-09-14 16:57:16 <danieli> moral of the story: java bad?
2021-09-14 16:57:36 <Hello71> portola was integrated: https://openjdk.java.net/jeps/386
2021-09-14 16:59:39 <ikke> https://openjdk.java.net/jeps/386
2021-09-14 17:01:55 <Hello71> uh
2021-09-14 17:02:27 <ikke> No idea what this involves, just noticed it
2021-09-14 17:02:38 <Hello71> yes, didn't i already link it
2021-09-14 17:02:47 <ikke> oh, maybe :P
2021-09-14 17:02:55 <Hello71> i think someone brought it up last year already
2021-09-14 17:06:23 <minimal> Alpine build still isn't provided with OpenJDK 17 upstream right?
2021-09-14 17:06:25 <minimal> "The Alpine Linux build previously available on this page was removed as of the first JDK 17 release candidate. It’s not production-ready because it hasn’t been tested thoroughly enough to be considered a GA build. Please use the early-access JDK 18 Alpine Linux build in its place."
2021-09-14 17:17:18 <Hello71> yes
2021-09-15 02:29:32 <Ariadne> if you need certified JDK for alpine, azul has one
2021-09-15 02:29:37 <Ariadne> they even provide repos
2021-09-15 02:29:41 <Ariadne> very nice
2021-09-15 06:03:39 <PureTryOut> Has the OpenSSL 3.0 migration settled down yet? Currently it's impossible to update Flatpak packages as it complains about SSL connect errors
2021-09-15 06:09:10 <PureTryOut> Actually, the latest system upgrade has fixed that, although I don't see any Flatpak or OpenSSL related package, interesting
2021-09-15 06:28:25 <ncopa> morning
2021-09-15 06:28:51 <ncopa> also amazon provides a what they call "production ready" openjdk build for alpine
2021-09-15 06:54:37 <Misthios> gm
2021-09-15 07:44:21 <Ariadne> PureTryOut: there was slightly too much innovation-by-sed in openssl1.1-compat -r2
2021-09-15 07:44:46 <PureTryOut> Sounds fun
2021-09-15 07:45:17 <Ariadne> the openssl1.1-compat -r3 fixed the incorrect innovation-by-sed, and thus allowed openssl 1.1 to find the ca-certificates bundle again
2021-09-15 07:45:20 <Ariadne> :)
2021-09-15 11:25:46 <ncopa> seems like chromium crashes more often now with the latest update
2021-09-15 12:22:56 <Ariadne> quality
2021-09-15 12:23:10 <Ariadne> firefox is nice and crash-free :)
2021-09-15 12:29:57 <andypost[m]> FF++ )
2021-09-15 13:02:00 <Hello71> Ariadne: fwiw there's the unrelated issue that openssl 3 disables tls 1.0 and 1.1 by default
2021-09-15 13:02:16 <Ariadne> good
2021-09-15 13:02:22 <Ariadne> it is 2021
2021-09-15 13:02:41 <Ariadne> TLS 1.2 has been in the world since 2008
2021-09-15 13:02:58 <Hello71> i'm not saying we should turn them back on, but it's good to know about in case people ask
2021-09-15 13:03:04 <Hello71> i also wrote it in the release notes
2021-09-15 13:03:12 <Ariadne> i was already aware
2021-09-15 13:03:14 <ikke> 👍
2021-09-15 13:03:19 <Ariadne> it is one of the many reasons i want openssl 3 :P
2021-09-15 13:03:40 <Hello71> i mean like if people ask then it could be the ca-certificates thing, or the tls 1.0 and 1.1 thing, or the legacy providers thing
2021-09-15 13:03:54 <Hello71> see e.g. #13004
2021-09-15 13:04:01 <Hello71> still not sure what that's about
2021-09-15 13:05:24 <Ariadne> i mean, we can downgrade cryptsetup to 1.1 if it helps
2021-09-15 13:06:06 <Ariadne> Hello71: i think openssl.cnf also needs to be present to direct it to load the legacy module
2021-09-15 13:06:19 <Hello71> not for cryptsetup
2021-09-15 13:06:24 <Hello71> it loads it from C
2021-09-15 13:06:42 <Ariadne> dunno then
2021-09-15 13:06:59 <Hello71> https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.4.0/lib/crypto_backend/crypto_openssl.c#L140
2021-09-15 13:07:10 <Hello71> i think it is a problem with nlplug-findfs
2021-09-15 13:07:34 <Hello71> but not sure exactly what
2021-09-15 13:08:21 <Ariadne> i wonder if it is trying to read from /dev/tty in openssl code
2021-09-15 13:08:26 <Ariadne> i think the initramfs does not have it
2021-09-15 13:12:23 <Ariadne> Hello71: i am admittedly not familiar with how nlplug-findfs handles cryptsetup
2021-09-15 13:13:57 <Hello71> i'm pretty sure it's an issue with legacy module or something like that, since i think everybody is using whirlpool
2021-09-15 13:14:07 <Hello71> i assume on the poor recommendations of the wiki
2021-09-15 13:15:47 <Ariadne> maybe we should downgrade cryptsetup to 1.1 for now
2021-09-15 13:15:52 <Ariadne> until we have time to do a deep dive
2021-09-15 13:17:04 <Ariadne> Hello71: i think it is related to /dev/tty not being present
2021-09-15 13:17:15 <Ariadne> Hello71: it would explain why they can open it by hand
2021-09-15 13:18:13 <Hello71> are you sure initramfs doesn't have /dev/tty? i'm pretty sure devtmpfs makes it
2021-09-15 13:18:44 <Hello71> and i don't think cryptsetup/nlplug-findfs would work at all without devtmpfs
2021-09-15 13:19:25 <Ariadne> i have no idea ;)
2021-09-15 13:19:37 <Ariadne> its not easy to get to a shell in the initramfs intentionally
2021-09-15 13:21:02 <Ariadne> Hello71: shall i downgrade cryptsetup to 1.1?
2021-09-15 13:21:42 <Hello71> mkinitcpio has break=, maybe mkinitfs should add that
2021-09-15 13:21:44 <caskd> wasn't there a way to interrupt the initramfs process and drop to a rescue shell temporarily?
2021-09-15 13:21:51 <Hello71> but if you just want to make it stop working then just set root=garbage
2021-09-15 13:21:58 <Ariadne> hmm
2021-09-15 13:22:05 <caskd> Hello71: exactly what i use
2021-09-15 13:22:11 <Ariadne> actually
2021-09-15 13:22:28 <Ariadne> cryptsetup is built against 1.1 already
2021-09-15 13:22:32 <Hello71> or use singlemode which is apparently in the initramfs?
2021-09-15 13:23:03 <minimal> cryptsetup/nlplug-findfs works in general in Edge, I tested it a day or 2 ago. That issue is specific to using the legacy stuff
2021-09-15 13:23:24 <Ariadne> https://git.alpinelinux.org/aports/tree/main/cryptsetup/APKBUILD#n11
2021-09-15 13:23:43 <Ariadne> i had to downgrade cryptsetup to 1.1 already
2021-09-15 13:23:52 <Ariadne> because other dependents were using 1.1
2021-09-15 13:24:02 <Ariadne> in fd79dc08fe3fb5f0c0a491bea711c1821980893d
2021-09-15 13:24:20 <Ariadne> so, it is on 1.1
2021-09-15 13:24:26 <Ariadne> they should regen their mkinitfs
2021-09-15 13:24:44 <Hello71> they said they already did
2021-09-15 13:25:08 <Ariadne> well
2021-09-15 13:25:16 <Ariadne> i dont know what to tell you
2021-09-15 13:25:21 <Ariadne> if cryptsetup
2021-09-15 13:25:25 <Ariadne> is linked against openssl 1.1
2021-09-15 13:25:29 <Ariadne> then it is back to status quo
2021-09-15 13:25:46 <Ariadne> so, i punt this back to you :)
2021-09-15 13:27:37 <minimal> ah, just realised my test VM is using GRUB to prompt for the passphrase and then uses a keyfile to unlock rootfs in initramfs - let me quickly build a VM with just initramfs unlock and see (as a reference point) if that still works as expected
2021-09-15 13:35:03 <Ariadne> well
2021-09-15 13:35:05 <Ariadne> it should
2021-09-15 13:35:07 <Ariadne> because
2021-09-15 13:35:12 <Ariadne> its openssl 1.1 :P
2021-09-15 13:38:02 <andypost[m]> Ariadne: any idea why I'm getting this error building with 1.1 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25359#note_180053
2021-09-15 14:16:16 <minimal> tested and confirmed that LUKS unlocking in general currently works fine with Alpine Edge
2021-09-15 14:36:56 <Ariadne> andypost[m]: no idea, perhaps it is linking against 3?
2021-09-15 14:37:12 <Ariadne> or dlopen()
2021-09-15 14:37:48 <Ariadne> i dont know how php ext openssl works
2021-09-15 14:42:20 <Ariadne> andypost[m]: possibly comingling
2021-09-15 14:45:50 <Ariadne> andypost[m]: try add `apk dot | grep so:libcrypto.so` to the APKBUILD in check()
2021-09-15 14:53:50 <Ariadne> sec
2021-09-15 15:01:08 <Ariadne> andypost[m]: depgraph looks clean.  no idea :s
2021-09-15 16:37:59 <andypost[m]> I should report upstream, looks related to test config
2021-09-15 16:38:36 <Newbyte> Is the link to ClamAV deliberately broken: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0
2021-09-15 16:39:57 <ikke> no
2021-09-15 16:40:31 <ikke> Fixed it
2021-09-15 16:41:17 <andypost[m]> is openssh backportable to 3.14 !24443
2021-09-15 18:35:10 <alandiwix> Since eudev is being retired, what's the plan with it in Alpine repos? Will there be a maintained fork or will we completly move to something like libudev-zero?
2021-09-15 18:47:12 <psykose> slow move to zero as it gets ready
2021-09-15 18:47:17 <psykose> eudev will remain for a while
2021-09-15 18:48:53 <mps> except libudev-zero is ready for me about one full year
2021-09-15 18:49:05 <ikke> keyword: "for me"
2021-09-15 18:49:36 <mps> ikke: also for you? ;) good news
2021-09-15 18:49:45 <ikke> It's a quote :)
2021-09-15 18:56:53 <mps> obviously not only 'for me', other people use it
2021-09-15 19:03:02 <alandiwix> Yea, needs some adjustments between major versions, but works nicely otherwise.
2021-09-15 19:04:06 <mps> and busybox mdev can work in daemon mode
2021-09-15 19:05:12 <mps> yes, needs some tweaks and some software needs to rewrite their udev based rules, and some helper scripts
2021-09-15 19:06:02 <mps> I promised to write short note about usage on alpine but didn't had time last weekend
2021-09-15 19:06:20 <mps> (and forgot tbh :| )
2021-09-15 19:06:49 <alandiwix> anyway it seems to be way easier to maintain/contribute then eudev 
2021-09-15 19:07:49 <mps> alandiwix: yes, and upstream developer is quite responsive and kind person
2021-09-15 19:09:17 <skarnet> yes, illiliti is easy to work with
2021-09-15 19:10:29 <minimal> mps: any mdev-related docs would be great as I have to try and figure out how to add support for it to cloud-init
2021-09-15 19:11:18 <mps> minimal: I only have what comes with mdev and source
2021-09-15 19:12:09 <mps> and this https://github.com/slashbeast/mdev-like-a-boss
2021-09-15 19:12:25 <minimal> was referring to your mention of writing a short note about usage on alpine
2021-09-15 19:12:38 <mps> there are some guides somewhere on gentoo site but forgot url
2021-09-15 19:12:50 <mps> ah
2021-09-15 19:13:07 <mps> https://arvanta.net/alpine/libudev-zero/
2021-09-15 19:13:10 <alandiwix> I guess that was more about libudev-zero
2021-09-15 19:13:31 <mps> this is outdated for 1.0.0 release but applies to previous ones
2021-09-15 19:15:25 <mps> minimal: I started to write rules for usb-modeswitch but gave up, this is 'job' for usb-modeswitch maintaner ;)
2021-09-15 21:06:53 <liske> Should py3-* packages depend on python3?
2021-09-15 21:13:22 <psykose> don't they all
2021-09-15 22:46:05 <liske> psykose: nope, there are multiple packages *not* depending on python3
2021-09-15 22:46:16 <psykose> show one
2021-09-15 22:46:32 <liske> py3-pyroute2*
2021-09-15 22:47:16 <liske> py3-btrfs-progs (just randomly found)
2021-09-15 22:47:44 <liske> python3 is available during package build if makedepends has py3-setuptools
2021-09-15 22:48:12 <liske> (this is why I did not run in packaging errors on py3-pyroute2*)
2021-09-15 22:48:13 <psykose> the former contains no binaries
2021-09-15 22:48:19 <psykose> it's just a python lib
2021-09-15 22:48:40 <psykose> you can't use it without py3, but it also can't run anything/fail without py3, so it's not a dependency indeed
2021-09-15 22:49:34 <psykose> though given that other packages of similar contents do depend on py3, that one is probably an exception by accident
2021-09-15 22:50:57 <psykose> ditto for the second one, they all seem the same as any other python lib just missing the dependency
2021-09-15 22:51:38 <psykose> i don't think it makes a difference really, nobody is using these without adding py3 themselves
2021-09-15 22:55:10 <liske> ok, so no need to add a python3 depend for py3 libs
2021-09-15 22:56:12 <psykose> most of them have it
2021-09-15 23:04:04 <psykose> also while looking around i found py3-cx_freeze which ships an executable but doesn't depend on python so you can't use it without adding it yourself, and also doesn't work as the package uses the old <3.8 importlib_metadata and can't run on new python
2021-09-15 23:04:19 <psykose> funnily, the author removed the compatibility https://github.com/marcelotduarte/cx_Freeze/pull/822/files
2021-09-15 23:07:54 <liske> I forgot ifstate (cli cmd) to depend on python3 but py3-yaml did pull python3 anyway :-O
2021-09-16 06:35:24 <anjan> Hi, I asked a question here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24276#note_175508
2021-09-16 06:35:38 <anjan> Please let me know how to fix so that we can merge this package
2021-09-16 06:49:29 <mps_> !24276
2021-09-16 07:16:41 <sircmpwn> hi prio release: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25401
2021-09-16 07:18:29 <sircmpwn> only edge is affected
2021-09-16 07:27:43 <Ariadne> sircmpwn: done
2021-09-16 07:27:54 <sircmpwn> thanks
2021-09-16 07:34:50 <Ariadne> sircmpwn: do you know if there is a CVE for the seatd issue?  i just noticed there is no secfixes block on the APKBUILD, so I figured I'd ask
2021-09-16 07:35:04 <sircmpwn> I asked them to file for one but they haven't got back to me yet
2021-09-16 07:35:07 <Ariadne> kk
2021-09-16 07:36:25 <sircmpwn> is there any documentation on how the secfixes comments work?
2021-09-16 07:36:29 <sircmpwn> or other security-related procedures
2021-09-16 07:39:05 <Ariadne> i think there was a page on the wiki, but we plan to document all of this formally in the developers' handbook
2021-09-16 07:39:18 <sircmpwn> gotcha
2021-09-16 07:39:23 <Ariadne> secfixes block, however, is just a YAML block
2021-09-16 07:39:36 <Ariadne> each version is a key, which has a list of fixes
2021-09-16 07:40:00 <sircmpwn> secfixes: <version number>: [list of CVE assignments addressed by this version]
2021-09-16 07:40:04 <Ariadne> yep
2021-09-16 07:40:16 <sircmpwn> easy enough
2021-09-16 07:40:17 <Ariadne> or use version 0 to reject the CVE
2021-09-16 07:40:19 <sircmpwn> should still be written down :)
2021-09-16 07:40:29 <sircmpwn> what does "rejecting" it mean?
2021-09-16 07:41:02 <Ariadne> rejection means the maintainer (or security team) does not believe it is relevant to the alpine package
2021-09-16 07:41:06 <sircmpwn> ah
2021-09-16 07:41:08 <Ariadne> for example, if a CVE only affects Windows
2021-09-16 07:42:24 <Ariadne> you can check to see if your package has any CVEs to investigate at https://security.alpinelinux.org/srcpkg/[package-name] too
2021-09-16 07:42:54 <sircmpwn> it would be nice if there was some automation which, upon merging a patch which updates the secfixes list, posts about it to a mailing list
2021-09-16 07:43:24 <Ariadne> yes, the secfixes-tracker software has some support for this
2021-09-16 07:44:07 <Ariadne> i'm just working on grouping all of the fixed versions into a single advisory
2021-09-16 07:44:13 <sircmpwn> cool
2021-09-16 07:44:21 <sircmpwn> do you already have a list provisioned?
2021-09-16 07:44:29 <Ariadne> but, there is https://lists.alpinelinux.org/~alpine/security-announcements
2021-09-16 07:44:35 <sircmpwn> cool
2021-09-16 10:49:05 <Ariadne> this Vortex86 CPU seems really broken
2021-09-16 10:52:24 <ikke> hmm
2021-09-16 10:52:29 <ikke> Just in general?
2021-09-16 10:53:58 <Ariadne> anyway, i think Alpine x86 at this point is defacto i686
2021-09-16 10:54:39 <Ariadne> an excitingly salacious discussion for the next TSC meeting, or a later one :)
2021-09-16 10:56:47 <Ariadne> Hello71: if you have a pitch deck for making alpine x86 i686, now is a great time :P
2021-09-16 10:56:55 <Habbie> i386 in most distros is actually i586/i686 these days i think?
2021-09-16 10:57:14 <Ariadne> in alpine it is "i586" on paper, but whether or not MMX is required is "???"
2021-09-16 10:57:26 <Ariadne> in practice, i think it is already i686 with SSE2 in a lot of places
2021-09-16 10:57:37 <Ariadne> because autoconf :D
2021-09-16 10:57:42 <ikke> de65d1eac557da3a382ccb355e23f7e0b8d1e941
2021-09-16 11:00:09 <ikke> Ariadne: I'd guess we would need to disable it explicitly for each package if we want to target i586?
2021-09-16 11:01:31 <Ariadne> yes
2021-09-16 11:01:45 <Habbie> Ariadne, right, because the builders have SSE2
2021-09-16 11:02:21 <ikke> Is this only for x86 or also x86_64?
2021-09-16 11:02:27 <Ariadne> only for x86
2021-09-16 11:02:30 <ikke> ok
2021-09-16 11:02:50 <Ariadne> x86_64 baseline is much newer
2021-09-16 11:02:53 <Ariadne> :)
2021-09-16 11:03:00 <ikke> makes sense
2021-09-16 11:03:32 <Ariadne> basically, i am 100% sure that this Vortex86 CPU user has just been lucky
2021-09-16 11:03:43 <Ariadne> and that most of our packages do not actually work on his CPU
2021-09-16 11:03:47 <Ariadne> :)
2021-09-16 11:04:18 <ikke> ahuh, untill openssl decided to use MMX
2021-09-16 11:05:46 <Ariadne> 1.1 uses mmx too
2021-09-16 11:06:03 <Ariadne> i think basically openssl determines it can use sse2
2021-09-16 11:06:11 <Ariadne> and so does
2021-09-16 11:15:20 <ikke> Ok, but why did it work before then?
2021-09-16 12:49:25 <dalias> ncopa, know anything else about the docker issue you @'d me on?
2021-09-16 12:50:13 <dalias> my bet is on "reporter lied about the address, it's actually ipv6, and they have a bogus seccomp filter making ipv6 EPERM or something"
2021-09-16 12:50:43 <ncopa> dalias: i dont, sorry. I saw the issue and though it looked suspicious
2021-09-16 12:51:23 <dalias> it's so bad how stack overflow has made "reporter lied" part of my go-to explanations for bug reports
2021-09-16 12:58:13 <ncopa> yeah. but in this case the reporter had exepcted musl work like glibc and run the nameserver in sequence, so he/she has definitively misunderstood at least parts
2021-09-16 12:58:23 <ncopa> an strace will tell the real problem
2021-09-16 13:20:29 <Ariadne> ikke: presumably because it didn’t do that before
2021-09-16 13:21:26 <dalias> ncopa, *nod*
2021-09-16 14:18:58 <nmeum> andypost[m]: did you make any progress on the icu upgrade? I would almost lean towards just upgrading it and dealing with rebuild errors as they occur on the builders
2021-09-16 14:19:16 <nmeum> it would be very neat to have this to finally be able to upgrade firefox :S
2021-09-16 14:36:45 <andypost[m]> nmeum: last mr just needs rebase, and better to split main, community and testing
2021-09-16 14:44:05 <Ariadne> ikke: bluntly though, i think if you're going to use a weird embedded CPU which, among other things, claims to be a Pentium MMX class CPU, while actually being basically a 386, you should really use Yocto
2021-09-16 14:44:14 <Ariadne> Alpine is not the right distro for that user
2021-09-16 14:48:34 <dalias> :/
2021-09-16 14:50:17 <Ariadne> dalias: i mean i can't think of any distro that would be "right" for that user, other than one built explicitly for his broken CPU
2021-09-16 14:52:17 <dalias> any distro that's called "i586" should work
2021-09-16 14:52:53 <dalias> i dont see how it's a "broken cpu"
2021-09-16 14:53:06 <dalias> it seems to be providing the isa level it advertises, no?
2021-09-16 14:57:10 <nmeum> andypost[m]: nice (:
2021-09-16 14:57:42 <Ariadne> dalias: no, it does not
2021-09-16 14:58:47 <dalias> what's it missing?
2021-09-16 15:00:10 <Ariadne> MMX, for one
2021-09-16 15:00:17 <dalias> mmx is not part of i586
2021-09-16 15:00:21 <Ariadne> though that was added at the end of the i586 lifecycle
2021-09-16 15:00:47 <dalias> it was an optional feature of some '586' class cpus but wasn't part of base isa until 686
2021-09-16 15:01:00 <dalias> however according to wikipedia it lacks fpu
2021-09-16 15:01:08 <dalias> which means i dont know how you'd use it at all
2021-09-16 15:01:16 <dalias> since linux dropped fpu emulation a long time ago
2021-09-16 15:01:36 <dalias> oh, later it says some more advanced ones have fpus
2021-09-16 15:01:57 <Ariadne> the one he has, has an FPU, but not MMX
2021-09-16 15:02:02 <Ariadne> the original one has MMX, but not FPU :D
2021-09-16 15:02:05 <dalias> lol
2021-09-16 15:02:22 <Ariadne> i mean, bluntly
2021-09-16 15:02:27 <Ariadne> i don't have one of these chips
2021-09-16 15:02:33 <Ariadne> so i have no idea how to debug it
2021-09-16 15:02:58 <dalias> debugging it isn't the question though. just not breaking the baseline isa profile that's shipping is the question
2021-09-16 15:02:59 <Ariadne> and i think in practice
2021-09-16 15:03:17 <dalias> the same will also affect anyone using the real intel 586
2021-09-16 15:03:33 <Ariadne> dalias: it does need to be debugged, because openssl crashes in a constructor function trying to probe for SSE2
2021-09-16 15:03:47 <dalias> oh i thought it was using mmx
2021-09-16 15:04:00 <dalias> "trying to probe for sse2" seems wrong
2021-09-16 15:04:12 <Ariadne> well, specifically,
2021-09-16 15:04:13 <dalias> you can read that from AT_HWCAP
2021-09-16 15:04:19 <Ariadne> it uses CPUID to test for SSE2
2021-09-16 15:04:21 <dalias> not probing insns and trying to catch the faults
2021-09-16 15:04:23 <Ariadne> and then starts using it
2021-09-16 15:04:29 <Ariadne> because that broken CPU says it has it
2021-09-16 15:04:53 <dalias> is that the case? or are they violating the contract of how you use cpuid?
2021-09-16 15:05:08 <dalias> you can only use it after first validating that the cpu supports the version of cpuid you want to check
2021-09-16 15:05:15 <dalias> reading AT_HWCAP would be much smarter anyway
2021-09-16 15:05:22 <Ariadne> because if you do OPENSSL_ia32cmp=~0x1000000 on Box86 emulating an i586 class CPU
2021-09-16 15:05:24 <dalias> as the *kernel* must also support sse to use it
2021-09-16 15:05:26 <Ariadne> it "works"
2021-09-16 15:05:37 <Ariadne> er, ia32cap
2021-09-16 15:05:49 <dalias> if cpuid reports sse2 exists, but kernel does not support sse2, trying to use it will blow up badly
2021-09-16 15:06:04 <Ariadne> yes, of course
2021-09-16 15:06:13 <dalias> so openssl is just wrong here i think
2021-09-16 15:07:06 <Ariadne> er, not box86
2021-09-16 15:07:07 <Ariadne> 86box
2021-09-16 15:16:29 <Ariadne> dalias: i had a thought
2021-09-16 15:16:39 <Ariadne> the kernel has a hook for handling unimplemented opcodes
2021-09-16 15:16:46 <Ariadne> :)
2021-09-16 15:35:37 <dalias> yes :)
2021-09-16 15:36:07 <dalias> kernel should be controling what cpuid reports too iirc (should have a way to mask it)
2021-09-16 15:36:33 <Ariadne> why not write
2021-09-16 15:36:36 <Ariadne> vortex86shitd
2021-09-16 15:39:33 <dalias> i'm still not getting all the hostility towards the chip
2021-09-16 15:40:15 <dalias> it's vaguely plausible it's doing something wrong here but my experience with openssl suggests the latter is much more likely
2021-09-16 15:43:50 <Ariadne> its hostility towards being forced to spend 100 more hours downgrading to openssl because of some CPU which we don't really properly support anyway
2021-09-16 15:46:00 <dalias> why downgrading?
2021-09-16 15:46:17 <dalias> just patch it
2021-09-16 15:46:33 <Ariadne> anyway, this user is lucky.
2021-09-16 15:47:14 <dalias> -cpuid +hwcap
2021-09-16 15:47:16 <dalias> done
2021-09-16 15:47:57 <Ariadne> i am able to actually emulate his exact CPU
2021-09-16 15:47:58 <Ariadne> with 86box
2021-09-16 15:48:21 <Ariadne> so, that means i can just figure out whatever is going on
2021-09-16 15:48:24 <Ariadne> if it is still going on
2021-09-16 15:48:50 <Ariadne> hmmmmmmmmm
2021-09-16 15:49:02 <Ariadne> rebuilding openssl with no-sse2
2021-09-16 15:49:15 <Ariadne> it does not crash on this emulated Vortex86DX
2021-09-16 15:49:26 <Ariadne> so, that seems to confirm the theory
2021-09-16 15:49:52 <Ariadne> or 86box is emulating it anyway
2021-09-16 16:03:16 <maxice8> How do I patch a rust crate ?
2021-09-16 16:03:31 <Ariadne> haha good luck
2021-09-16 16:03:31 <maxice8> git2-rs fails to build
2021-09-16 16:03:54 <Ariadne> cargo is quite insistent about you not messing with crates
2021-09-16 16:04:35 <dalias> like what do you do if code in the crate is wrong and won't work on your system because it's wrong?
2021-09-16 16:06:29 <maxice8> suffer I guess
2021-09-16 16:08:16 <Ariadne> dalias: alcoholism
2021-09-16 16:08:54 <Ariadne> there is some way to tell it you patched the crate
2021-09-16 16:08:58 <Ariadne> but i forget what it is
2021-09-16 16:09:11 <Hello71> https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html
2021-09-16 16:10:19 <Ariadne> okay, lets figure out
2021-09-16 16:10:34 <Ariadne> now that i have cycle-accurate emulated Vortex86
2021-09-16 16:14:54 <ericonr> It's very very sad
2021-09-16 16:15:03 <ericonr> You have to patch cargo.toml to look in a folder
2021-09-16 16:15:21 <ericonr> Then download a tarball, patch it, and stuff it in the indicated path
2021-09-16 16:15:37 <ericonr> If it's a recursive dependency, the suffering is compounded 
2021-09-16 16:16:27 <dalias> ..
2021-09-16 16:17:36 <Ariadne> ericonr: like i said, alcoholism is a better use of time
2021-09-16 16:17:42 <ericonr> Debian and fedora have a local cargo registry and package *all* dependency crates
2021-09-16 16:17:53 <ericonr> But that's a whole damn lot of work
2021-09-16 16:18:05 <Ariadne> HAHA
2021-09-16 16:18:22 <Ariadne> localhost:~# apk
2021-09-16 16:18:25 <Ariadne> Illegal instruction
2021-09-16 16:18:27 <Ariadne> finally
2021-09-16 16:18:31 <Ariadne> got the right shit cpu
2021-09-16 16:20:41 <Hello71> ericonr: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#paths-overrides seems less bad
2021-09-16 16:21:33 <dalias> :)
2021-09-16 16:22:49 <Ariadne> ummm
2021-09-16 16:22:51 <Ariadne> okay
2021-09-16 16:22:59 <Ariadne> this is crashing on a cmpxchg8b instruction
2021-09-16 16:23:05 <Ariadne> is that not part of base i586?
2021-09-16 16:23:34 <Hello71> i guess not
2021-09-16 16:23:52 <Ariadne> i'm pretty sure it is>
2021-09-16 16:25:16 <dalias> i think it is baseline i586
2021-09-16 16:25:44 <dalias> so maybe this is the cpu being broken
2021-09-16 16:25:47 <Hello71> https://en.wikipedia.org/wiki/Pentium_(original)#Improvements_over_the_i486 says "New instructions: CPUID, CMPXCHG8B, RDTSC, RDMSR, WRMSR, RSM."
2021-09-16 16:27:03 <Ariadne> i am going to emulate
2021-09-16 16:27:06 <Ariadne> an actual pentium now
2021-09-16 16:27:20 <ikke> What are you using to emulate it?
2021-09-16 16:27:26 <Ariadne> i see no reason to disbelieve the accuracy of 86box's emulation
2021-09-16 16:27:32 <ikke> 86box
2021-09-16 16:27:35 <Ariadne> considering i wrote code which uses cmov
2021-09-16 16:27:38 <Ariadne> and it SIGILL'd me
2021-09-16 16:29:32 <Ariadne> on real pentium
2021-09-16 16:29:36 <Ariadne> without mmx
2021-09-16 16:29:40 <Ariadne> it works fine
2021-09-16 16:30:19 <dalias> ok so looks like you were right and this thing is broken :(
2021-09-16 16:31:02 <dalias> i can see wanting to omit cmpxchg8b -- it's expensive & largely useless. but you don't have compat with i586 if you omit it
2021-09-16 16:31:17 <dalias> and thus rather should just advertise i486 since that's the main difference
2021-09-16 16:34:17 <Ariadne> the "customer" is not right in this case
2021-09-16 16:34:22 <Ariadne> to Yocto he should go
2021-09-16 16:34:41 <Ariadne> he just got lucky and openssl 1.1 did not use cmpxchg8b
2021-09-16 16:40:31 <dalias> i mean they can try to hack to together building their own openssl package with --disable-asm
2021-09-16 16:43:54 <Ariadne> anyway, now that i was able to debug the issue myself, i can say what was going on
2021-09-16 16:43:54 <nmeum> hm, did the busybox ssl_client install_if rule broke with the openssl update? somehow it got purged from my system after the upgrade
2021-09-16 16:44:16 <Ariadne> nmeum: no, i think it is apk solver weirdness
2021-09-16 16:44:21 <Ariadne> nmeum: if you do `apk fix` it comes back
2021-09-16 16:45:15 <Ariadne> dalias: basically, openssl 3 does check hwcap if available, but it also tests to make sure the features work
2021-09-16 16:45:27 <Ariadne> why it does this is beyond me
2021-09-16 16:45:36 <Ariadne> presumably, typical openssl paranoia
2021-09-16 16:45:40 <nmeum> Ariadne: it doesn't here
2021-09-16 16:45:48 <Ariadne> nmeum: weird
2021-09-16 16:46:11 <Ariadne> ohhh
2021-09-16 16:46:13 <Ariadne> yes
2021-09-16 16:46:17 <Ariadne> we need to fix the install_if rule
2021-09-16 16:46:23 <nmeum> :)
2021-09-16 16:46:25 <Ariadne> give me a sec, i'll do it
2021-09-16 16:46:34 <nmeum> thanks
2021-09-16 16:46:42 <Ariadne> i'm putting SSE2 back on our openssl x86 builds
2021-09-16 16:46:44 <Ariadne> because
2021-09-16 16:47:07 <Ariadne> thats not the problem, the problem is that guy is using a CPU that is having an identity crisis
2021-09-16 16:47:24 <Ariadne> unfortunate, but alpine does not support i486 CPUs
2021-09-16 16:47:39 <Ariadne> and, as far as i am concerned, that thing is a 486
2021-09-16 16:48:15 <Ariadne> he should trade those chips in for the DX2
2021-09-16 16:48:22 <Ariadne> which is newer, and implements i686 fully
2021-09-16 16:48:30 <Ariadne> i guess because the patents expired
2021-09-16 16:56:15 <dalias> *nod*
2021-09-16 16:57:12 <Ariadne> Am5x86-P100, as emulated by 86box: also works
2021-09-16 16:58:00 <Ariadne> AMD K5-PR166, also as emulated by 86box: also works
2021-09-16 16:59:37 <Ariadne> Cyrix 6x86-P166+: also works
2021-09-16 17:07:37 <Ariadne> oh, huh
2021-09-16 17:09:10 <Ariadne> hahaha this is amazing
2021-09-16 17:09:33 <Ariadne> dalias: `lock cmpxchg8b` crashes, but `cmpxchg8b` without lock prefix does not
2021-09-16 17:09:43 <Ariadne> what a buggy ass CPU
2021-09-16 17:13:23 <dalias> is it testing for f00f bug ?
2021-09-16 17:13:33 <Ariadne> no
2021-09-16 17:13:44 <Ariadne> its crashing in
2021-09-16 17:13:47 <Ariadne> CRYPTO_atomic_or()
2021-09-16 17:14:14 <Ariadne> which uses `lock cmpxchg8b %esi`
2021-09-16 17:14:24 <Ariadne> but if i patch that
2021-09-16 17:14:34 <Ariadne> then it is fine
2021-09-16 17:14:44 <Ariadne> i'm going with "this is a buggy ass CPU"
2021-09-16 17:17:52 <Ariadne> apparently there is a microcode update
2021-09-16 17:17:54 <Ariadne> that fixes this
2021-09-16 17:18:21 <Ariadne> gonna guess that is delivered in the form of a new BIOS for these
2021-09-16 17:19:33 <Ariadne> welp
2021-09-16 17:19:41 <Ariadne> done with this for now
2021-09-16 17:19:48 <Ariadne> i can't fix this guy's CPU
2021-09-16 17:22:50 <psykose> the alpine devs can't even livepatch my cpu, awful customer service /s
2021-09-16 17:30:10 <ikke> Anyone knows how this should be properly quoted in a Makefile? VERSION_STRING := $(shell git describe --match v* 2>/dev/null || awk '$0="v"$0' VERSION || echo unknown)
2021-09-16 17:30:28 <ikke> The awk command works locally, but gives 'awk: cmd. line:1: Unexpected token' when executed with make
2021-09-16 17:30:43 <Hello71> $$
2021-09-16 17:31:03 <Hello71> although you could use sed instead
2021-09-16 17:31:13 <ikke> Thanks
2021-09-16 17:31:20 <ikke> It's a third-party makefile
2021-09-16 17:31:34 <ikke> but apparerently they don't excercise that part :P
2021-09-16 17:31:46 <ikke> https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/Makefile#L4
2021-09-16 17:36:03 <knuxify> could someone take a look at 
2021-09-16 17:36:04 <knuxify> ?
2021-09-16 17:36:04 <knuxify> !23851
2021-09-16 17:36:16 <knuxify> (whoops, accidentally pasted it in with newlines :p)
2021-09-16 17:41:26 <Ariadne> is the projectM stable yet :D
2021-09-16 17:42:36 <ikke> projectM?
2021-09-16 17:44:51 <Ariadne> milkdrop visualizer clone, everytime ive tried to package it for alpine, it just explodes violently
2021-09-16 17:50:16 <knuxify> seems like it :blobcatgoogly:
2021-09-16 17:50:55 <knuxify> i mean, the qt-based projectm-pulseaudio frontend works fine, the sdl one errored out iirc but i should probably test it again
2021-09-16 17:51:26 <knuxify> but visualizations in clementine are incredibly unstable, no clue if this is a projectm problem or a clementine problem but i'm convinced it's the latter
2021-09-16 17:52:07 <knuxify> (by incredibly unstable i mean they crash when you try to change the quality setting, and also none are detected, and also it runs oddly slow and i think it's broken anyways (: )
2021-09-16 17:54:37 <knuxify> oh nevermind, projectMSDL works fine
2021-09-16 17:54:53 <knuxify> it was some kind of dependency-issue-edge-case-thing iirc, seems like it's resolved now
2021-09-16 19:39:22 <maxice8> Ikke: https://gitlab.alpinelinux.org/Arnavion/aports please make public
2021-09-16 19:44:35 <ikke> maxice8: The script runs hourly to do it
2021-09-16 19:44:41 <ikke> I've now ran it manually
2021-09-16 19:45:11 <maxice8> oh
2021-09-16 19:45:15 <maxice8> that explains it
2021-09-16 19:47:21 <ikke> It could probably use webhooks as well, but I'm too lazy to set it up
2021-09-16 21:05:43 <andypost[m]> sudo upgrade is green) !25413
2021-09-16 21:06:23 <andypost[m]> it warns now about missing openssl
2021-09-16 22:35:53 <sam_> i'd rebase to _p1 if possible
2021-09-16 22:35:55 <sam_> it has some crash fixes
2021-09-16 22:56:43 <Ariadne> :D
2021-09-16 22:56:48 <Ariadne> i just accepted it
2021-09-17 06:13:40 <PureTryOut> Ariadne: I want to discuss something with the Alpine desktop team (you, Cogitri and me basically), where should I do that? Here on IRC, a Gitlab issue thread, mailing list, something else?
2021-09-17 08:55:09 <Cogitri[m]> I guess that depends on whether we want to keep the entire discussion around for the future or just its results
2021-09-17 08:55:23 <Cogitri[m]> imho using Gitlab is best since searching through IRC logs isn’t fun
2021-09-17 09:24:17 <PureTryOut> Yeah ok I'll make a thread there somewhere this weekend
2021-09-17 09:24:33 <PureTryOut> wget is broken since the openssl 3.0 migration 😢
2021-09-17 09:24:41 <PureTryOut> `wget: can't execute 'ssl_client': No such file or directory`
2021-09-17 09:25:53 <ikke> Still?
2021-09-17 09:31:01 <Ariadne> PureTryOut: should be fixed in busybox latest
2021-09-17 09:31:24 <PureTryOut> I'm using the separate wget package though, not the busybox one
2021-09-17 09:32:18 <ncopa> wget package should not use ssl_client
2021-09-17 09:32:54 <PureTryOut> Oh wait nvm this is a different laptop, here I am using the Busybox one. I'll check for an update then
2021-09-17 10:06:05 <oneinsect> hola everyone
2021-09-17 10:10:05 <nmeum> buenos días
2021-09-17 10:13:24 <oneinsect> if a package has a static library that has an assembly code object which is not position independent, to compile correctly I must specify “-no-pie” option during link stage of generating final executable binary.
2021-09-17 10:13:42 <oneinsect> however this causes some packages to be PIE enabled and some non-pie
2021-09-17 10:15:28 <oneinsect> especially this errors i saw when I use a pure glibc alpine OS
2021-09-17 10:16:55 <oneinsect> what is a best methodology for these kinds of scenarios
2021-09-17 10:22:30 <oneinsect> i mean if the dependencies are pie enabled (say zlib) and the application built on the top is non-pie, what happens then
2021-09-17 10:26:30 <ncopa> best is to fix assembly code to be position independent
2021-09-17 10:27:37 <ncopa> as I understand if you compile with -fPIC, you will till be able to link with no-pie
2021-09-17 10:27:42 <ncopa> but not vice versa
2021-09-17 10:29:22 <oneinsect> thanks ncopa:
2021-09-17 10:29:43 <oneinsect> so the suggestion would be goto for -fPIC option whenever possible and not PIE right?
2021-09-17 10:30:19 <ncopa> ideally everything should be -fPIC (i think 64 bit arches are that by default) and everything should be PIE
2021-09-17 10:30:43 <oneinsect> hmmmm
2021-09-17 10:30:53 <ncopa> -fPIC is position independent code (ie for *.o files and static libs)
2021-09-17 10:31:14 <ncopa> PIE is position independent executable, which depends on -fPIC
2021-09-17 10:31:41 <ncopa> as I understand shared libs always needs to be position independent
2021-09-17 10:31:55 <ncopa> otherwise there is no way to dynamically link to it
2021-09-17 10:33:06 <ncopa> durrendal: i have cleaned up your libfido stuff for openssh a bit
2021-09-17 10:34:50 <oneinsect> thanks
2021-09-17 10:42:34 <adhawkins> Question: I maintain a number of packages in Alpine, primarily emborg and its python dependencies. When a new version of these comes out, I package up the new version and put it in Edge. Should I be doing something to get these newer versions into 'release' Alpine versions too?
2021-09-17 10:43:44 <ikke> bugfixes / patch releases can get backported to supported releases.
2021-09-17 10:43:51 <ikke> New features we typically do not backport
2021-09-17 10:44:19 <adhawkins> Ok, understood. If I did need to update a package in an older release, what's the procedure for that?
2021-09-17 10:44:25 <ikke> To backport, you basically make commits against the <x>-stable branch
2021-09-17 10:44:38 <ikke> instead of master
2021-09-17 10:44:58 <adhawkins> Got it, thanks ikke. Will bear that in mind in future. These package primarily are updated due to new features so it probably hasn't been an issue so far.
2021-09-17 10:45:22 <adhawkins> If it ever becomes necessary, I'll come back and ask again :)
2021-09-17 12:23:35 <oneinsect> https://manpages.debian.org/testing/equivs/equivs-build.1.en.html
2021-09-17 12:23:50 <Hello71> why do i get the impression that that this ravn guy actually needs paid consulting
2021-09-17 12:24:02 <oneinsect> Do we have something similar
2021-09-17 12:24:18 <oneinsect> where we can create some dummy entries in “installed” file to make abuild think that some basic GNU programs and libraries are installed
2021-09-17 12:24:39 <Hello71> virtuals
2021-09-17 12:25:11 <oneinsect> but virtuals do not populate the each file and mentioning to which package they belong
2021-09-17 12:26:05 <oneinsect> i mean assuming I have a basic GNU package is installed, how do i track what files belong to it and populate them in "installed" file
2021-09-17 12:26:30 <oneinsect> i still have to manually do it?
2021-09-17 12:26:56 <ericonr> > Please note that this is a crude hack and if thoughtlessly used, it might possibly do damage to your packaging system. And please note as well that using it is not the recommended way of dealing with broken dependencies. Better file a bug report instead.
2021-09-17 12:26:57 <oneinsect> it will help with my bootstrap work
2021-09-17 12:27:43 <oneinsect> it will help me in progressing my boostrap work of building a pure glibc based alpine OS
2021-09-17 12:28:09 <oneinsect> any ideas?
2021-09-17 12:28:46 <oneinsect> need to compute a list of the files before the installation
2021-09-17 12:28:53 <oneinsect> probably thats one thought
2021-09-17 12:30:25 <minimal> oneinsect: Alpine is musl-based so anything glibc-based isn't Alpine
2021-09-17 12:30:42 <oneinsect> i know i know people hate me here
2021-09-17 12:30:43 <oneinsect> :D
2021-09-17 12:30:48 <minimal> at best it would be Alpine derived
2021-09-17 12:30:52 <oneinsect> indeed
2021-09-17 12:30:54 <oneinsect> agreed
2021-09-17 12:31:07 <ikke> minimal: note that they do a complete rebuild, not the glibc combined with musl
2021-09-17 12:31:53 <minimal> it you take a Ford car and replace the engine and gearbox and electronics with ones from a Chrysler then the result is no longer a Ford car
2021-09-17 12:32:00 <oneinsect> lol
2021-09-17 12:32:02 <oneinsect> agreed
2021-09-17 12:32:20 <oneinsect> thank you folks
2021-09-17 12:32:22 <minimal> so called the end result a "Alpine OS" is a misnomer
2021-09-17 12:32:34 <psykose> i believe everyone heard you the first time
2021-09-17 12:32:35 <oneinsect> my bad, i take it back
2021-09-17 12:33:29 <mps_> oneinsect: I encourage your work
2021-09-17 12:33:41 <psykose> +1
2021-09-17 12:33:53 <minimal> there's nothing wrong with a minimised glibc-based distribution
2021-09-17 12:34:08 <mps_> if you manage to make it then I expect some people will left alpine, which is good ;)
2021-09-17 12:34:14 <minimal> its just a question of terminology
2021-09-17 12:34:18 <oneinsect> i have no intention to disturb the other quiet and serene place here
2021-09-17 12:34:47 <ikke> minimal: oneinsect already has a different name for the project
2021-09-17 12:36:17 <oneinsect> its just that you all have better insights which I thought would be useful hence I tend to buzz now and then
2021-09-17 12:36:37 <ikke> It should not be a problem to ask questions about these things here
2021-09-17 12:36:59 <mps_> oneinsect: np, as we know you about two years now
2021-09-17 12:37:18 <minimal> oneinsect: please do not take my comments as negative, I was just clarifying terminology
2021-09-17 12:37:23 <mps_> I had a hope you are near at least beta release
2021-09-17 12:37:30 <oneinsect> indeed indeed
2021-09-17 12:37:41 <oneinsect> sure understood minimal:
2021-09-17 12:37:54 <mps_> minimal: this was talked with oneinsect a long ago
2021-09-17 12:38:38 <oneinsect> its just that its like a chicken or egg first problem, i need to build apks first but without installing them, which means subsequent apks wont build
2021-09-17 12:38:57 <ikke> why can't you install them?
2021-09-17 12:39:13 <oneinsect> it will destory the existing OS
2021-09-17 12:39:22 <oneinsect> i had faced that issue before
2021-09-17 12:39:47 <oneinsect> the package manager needs to come at some point in the package building process and start building its own packages 
2021-09-17 12:40:14 <oneinsect> even if its LFS or CLFS or any process
2021-09-17 12:41:05 <oneinsect> the fundamental idea is that we need to create some dummy entries in “installed” file to make abuild think that some basic GNU programs and libraries are installed (because they are). 
2021-09-17 12:41:26 <oneinsect> and then start building proper packages from then on
2021-09-17 12:41:36 <mps_> oneinsect: what about metapackages
2021-09-17 12:41:51 <oneinsect> meaning?
2021-09-17 12:41:58 <mps_> someone mentioned equivs
2021-09-17 12:42:18 <oneinsect> i did
2021-09-17 12:43:03 <oneinsect> metapackages or virtual packages, I still need to enter the file location details for each virtual package
2021-09-17 12:43:04 <mps_> apk add -t pkgname apk1 apk2 ....
2021-09-17 12:43:20 <oneinsect> meaning the libx.so file locations
2021-09-17 12:43:25 <mps_> ahm, then no
2021-09-17 12:43:36 <oneinsect> otherwise abuild will complain saying cannot find owner
2021-09-17 12:44:15 <oneinsect> i am trying to see what best way to automate it, along with apk add -t
2021-09-17 12:45:00 <oneinsect> this process is only one-time, the os will rebuild itself and packages subsequently for other releases
2021-09-17 12:45:28 <oneinsect> i dont know if i am making any sense
2021-09-17 12:45:40 <mps_> manually, touch every needed file from script?
2021-09-17 12:46:07 <oneinsect> can you please explain?
2021-09-17 12:47:07 <mps_> 'find /where > file' 'sed -i 's/^./touch /' file'
2021-09-17 12:47:21 <mps_> apk del ...
2021-09-17 12:47:27 <mps_> sh file
2021-09-17 12:47:33 <oneinsect> https://ctxt.io/2/AACgj1Y2EQ
2021-09-17 12:47:46 <mps_> just mumbling
2021-09-17 12:48:08 <oneinsect> do you notice the p, F and & R for glibc in the above
2021-09-17 12:48:16 <oneinsect> p is p:so:libc.so.6=6
2021-09-17 12:48:21 <ikke> There is no supported mechanism to associate files to packages
2021-09-17 12:48:23 <ikke> manually
2021-09-17 12:48:39 <oneinsect> i wrote those manually
2021-09-17 12:49:10 <oneinsect> i understand ikke
2021-09-17 12:49:34 <mps_> hmm, still not clear what you are trying and (maybe more important) why
2021-09-17 12:49:47 <mps_> I mean, not clear to me
2021-09-17 12:50:22 <oneinsect> hmmm, may be i will document it sometime and share the process
2021-09-17 12:52:15 <oneinsect> in short if I just manually compile glibc (without abuild) and do make install, it will install the files to say usr/lib
2021-09-17 12:52:40 <ikke> but why does apk need to know about the files?
2021-09-17 12:53:04 <oneinsect> the subsequent programs like zlib etc will be built using abuild which will complain saying i dont know to which package libc.so belong to
2021-09-17 12:53:25 <oneinsect> as dependency information is required while packaging zlib in zlib.apk
2021-09-17 12:53:43 <oneinsect> you know what i mean?
2021-09-17 12:53:50 <ikke> Oh, so it's more about provides that are missing
2021-09-17 12:53:54 <ikke> not actual files
2021-09-17 12:53:58 <oneinsect> yesssss
2021-09-17 12:54:31 <ikke> Then you could create a dummy package that provides these things
2021-09-17 12:54:54 <oneinsect> dummy package?
2021-09-17 12:54:58 <oneinsect> not a bad idea
2021-09-17 12:55:03 <oneinsect> any examples?
2021-09-17 12:55:18 <ikke> I wonder if you could even do: apk add -t p:libc.so
2021-09-17 12:55:28 <oneinsect> that would actually help a lot
2021-09-17 12:55:39 <oneinsect> i mean something like this
2021-09-17 12:55:49 <oneinsect> apk add -t glibc p:libc.so
2021-09-17 12:56:00 <ikke> no, that does not work
2021-09-17 12:56:05 <ikke> that would try to install p:libc.so
2021-09-17 12:56:14 <oneinsect> oooh
2021-09-17 12:56:25 <oneinsect> but i still need the correct package ikke
2021-09-17 12:56:29 <oneinsect> package name*
2021-09-17 12:58:35 <oneinsect> never mind
2021-09-17 12:59:19 <oneinsect> i will just take a snapshot of the contents of the install location before installing and compare it and populate the installed file with library files along with virtual packages
2021-09-17 13:00:01 <oneinsect> or may be just do make -n install which will "dry run" the install process and extract the file information from its results
2021-09-17 13:00:27 <ikke> Why can't you use abuild to create a proper package
2021-09-17 13:00:39 <oneinsect> i so much wish
2021-09-17 13:00:47 <oneinsect> which is the first package i start
2021-09-17 13:01:00 <oneinsect> say zlib? it depends on glibc
2021-09-17 13:01:04 <oneinsect> so i start glibc?
2021-09-17 13:01:07 <ikke> and glibc?
2021-09-17 13:01:14 <oneinsect> glibc depends on all crap
2021-09-17 13:01:25 <ikke> But you alreayd manage to compile it
2021-09-17 13:01:40 <ikke> just do the same in abuild without specifying all these dependencies
2021-09-17 13:01:51 <ikke> later when you have things sorted out, you can add the dependencies
2021-09-17 13:02:46 <oneinsect> packages compile, but they refuse to generate package.apk mentioning missing dependencies or orphaned files
2021-09-17 13:03:12 <ikke> You can even add options="!tracedeps" to prevent abuild from automatically adding dependencies
2021-09-17 13:03:21 <oneinsect> ooooh
2021-09-17 13:03:32 <oneinsect> darn i missed this the whole time
2021-09-17 13:03:51 <oneinsect> oooh my ....... god
2021-09-17 13:04:21 <oneinsect> ikke: thank you lord
2021-09-17 13:04:29 <oneinsect> i will try this tonight
2021-09-17 13:04:39 <oneinsect> what about during installation
2021-09-17 13:04:52 <oneinsect> can i try force install even without dependencies?
2021-09-17 13:05:02 <ikke> Just don't specify any, and it will not install any
2021-09-17 13:05:27 <oneinsect> thanks ikke:
2021-09-17 13:21:38 <janem> I'm trying to apply a patch to the linux-lts kernel package but I get the following error message whenever I try to run abuild -r : make: *** [/home/janem/aports/main/linux-lts/src/linux-5.10/Makefile:185: __sub-make] Error 2 >>> ERROR: linux-lts: build failed
2021-09-17 13:25:57 <fcolista> ok I'm still struggling in havin an awall rule with dns hostname resolved.
2021-09-17 13:25:59 <fcolista> https://tpaste.us/JqLl
2021-09-17 13:26:21 <fcolista> awall translate
2021-09-17 13:26:21 <fcolista> awall: filter 1 (glbsvc-letsencrypt): Invalid host name: acme-staging-v02.api.letsencrypt.org
2021-09-17 13:26:49 <fcolista> of course the host is able to resolve that domain
2021-09-17 13:26:49 <fcolista> ping acme-staging-v02.api.letsencrypt.org
2021-09-17 13:26:49 <fcolista> PING acme-staging-v02.api.letsencrypt.org(2606:4700:60:0:f41b:d4fe:4325:6026 (2606:4700:60:0:f41b:d4fe:4325:6026)) 56 data bytes
2021-09-17 13:26:59 <fcolista> as well as ipv4
2021-09-17 13:27:00 <fcolista> ping -4 acme-staging-v02.api.letsencrypt.org
2021-09-17 13:27:00 <fcolista> 64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=1 ttl=61 time=3.21 ms
2021-09-17 13:27:00 <fcolista> PING 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com (172.65.46.172) 56(84) bytes of data.
2021-09-17 13:27:50 <ikke> Maybe some validation in awall that is rejecting it?
2021-09-17 13:28:07 <fcolista> maybe...no idea on how to trobleshoot this :-/
2021-09-17 13:28:14 <fcolista> kunkku, any hint?
2021-09-17 13:29:40 <mps_> janem: does your patch apply manually
2021-09-17 13:31:47 <fcolista> perhaps i should declare a zone for this...
2021-09-17 13:31:50 <fcolista> ""Subnets in zone definitions can be declared using IPv4/IPv6 addresses (CIDR notation), domain names, or as references to ipsets. A domain name can resolve to one or more IP addresses. The referred ipsets may be managed manually or by some other tool. 
2021-09-17 13:32:58 <fcolista> nah. zone is linked to an iface.
2021-09-17 13:33:27 <janem> yes @mps_
2021-09-17 13:34:27 <fcolista> ikke, i think that with variable this is not possible in awall. Probably this can be done with ipset.
2021-09-17 13:35:25 <mps_> janem: run abuild with -rv to see more verbose msgs
2021-09-17 13:37:45 <mps> janem: does your patch touch Makefile or something build related
2021-09-17 13:41:27 <janem> no it doesn't
2021-09-17 13:44:48 <mps> abuild -r > build.log and see what causes error
2021-09-17 13:47:14 <Hello71> fcolista: https://gitlab.alpinelinux.org/alpine/awall/-/issues/9648
2021-09-17 13:48:15 <fcolista> Hello71, thanks a lot. 
2021-09-17 13:48:41 <Hello71> not sure why it shells out to drill, i guess maybe to avoid dependencies?
2021-09-17 13:49:24 <fcolista> yes
2021-09-17 13:49:33 <fcolista> with dig you have to install bind-tools
2021-09-17 13:50:47 <fcolista> drill is a dependency of awall
2021-09-17 14:01:57 <ikke> rnalrd: seems like proc.num in zabbix agent2 is now fixed in 5.4.5, so I suppose we can drop the patch again once it's released
2021-09-17 14:02:31 <ikke> also in 5.0.16
2021-09-17 14:06:03 <ikke> mps: someone mentions that dovecot after the latest upgrade fails to initialize SSL due to missing libproviders.so
2021-09-17 14:06:50 <Hello71> fcolista: well that's circular
2021-09-17 14:07:01 <Hello71> it needs drill for this specific purpose
2021-09-17 14:07:22 <Hello71> my point is why doesn't it use getaddrinfo
2021-09-17 14:07:43 <Hello71> and i think it's because lua doesn't come with networking libraries
2021-09-17 14:11:37 <Habbie> correct - lua-posix has it though
2021-09-17 14:19:47 <Hello71> but does awall use lua-posix
2021-09-17 14:20:16 <Habbie> huh
2021-09-17 14:20:18 <Habbie> it does
2021-09-17 14:20:31 <Habbie> for signal, sleep, stat, kill, chdir
2021-09-17 14:20:43 <Habbie> mkdir, getcwd, realpath
2021-09-17 14:32:24 <mps> ikke: hmm, where this is mentioned
2021-09-17 14:32:35 <mps> in issues?
2021-09-17 14:32:39 <Hello71> mps: #alpine-linux
2021-09-17 14:33:49 <mps> heh, who runs mail server on edge ;)
2021-09-17 14:33:53 <Hello71> no google results for "libproviders.so", i suspect they are using some nonstandard plugin or something
2021-09-17 14:33:56 <mps> must be brave one
2021-09-17 14:34:26 <mps> I didn't noticed anything in dovecot ML about this
2021-09-17 14:35:41 <Hello71> janem: it would help if you post the full error... this part is not helpful
2021-09-17 14:47:45 <rnalrd> ikke, yes, and 5.0.16 for LTS
2021-09-17 14:47:59 <ikke> yeah, mentioned it
2021-09-17 17:15:50 <dalias> ncopa, ok the reporter responded with a completely different issue from original report..
2021-09-17 17:19:09 <ncopa> yeah. i had a feeling the reporter had a different issue that got misunderstood and made some assuptions when reporting. thank you for responding to it
2021-09-17 17:20:47 <dalias> i'm guessing it's docker-for-mac being dumb again
2021-09-17 17:21:05 <dalias> "lol the user turned off ipv6 so let's ignore aaaa dns queries"
2021-09-17 17:21:35 <dalias> the whole "intercept-and-rewrite-dns" thing was such a bad idea
2021-09-17 17:30:35 <syso> im interested in using alpine as a base for my realtime audio projects. is there any kernel with preempt_rt patches?
2021-09-17 17:30:46 <syso> I need to run jack with realtime priority
2021-09-17 17:31:50 <ikke> We do not provide any kernel with preempt_rt ourselves
2021-09-17 17:31:52 <syso> if not, what is the best approach if I want to contribute?
2021-09-17 17:32:44 <syso> 5.10.61-0-lts is compatible with the patches https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.10/
2021-09-17 17:33:08 <syso> i want to target x86_64, armhf, aarch64
2021-09-17 17:33:41 <dalias> i'm not sure if anyone on alpine side will want to maintain a separate kernel unless you want to volunteer to do that long-term
2021-09-17 17:35:02 <syso> I would volunteer for that. 
2021-09-17 17:36:21 <ikke> Have a look at how the existing kernels are built and see if you can adopt that for the rt patches
2021-09-17 17:36:52 <syso> It should be fairly easy to do, because it just needs to apply the patch and append the localversion to the kernel version, but I am not yet familiar with the alpine build system.
2021-09-17 17:37:23 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/linux-lts
2021-09-17 17:37:38 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/linux-edge
2021-09-17 17:38:45 <syso> ah, so i just need to add the patch and adjust APKBUILD accordingly?
2021-09-17 17:39:00 <ikke> Well, it would have to be a different package
2021-09-17 17:39:20 <syso> but if i copy linux-lts and name it linux-lts-preempt and work on that, would that be ok?
2021-09-17 17:41:47 <ikke> yes, I would just call it linux-rt or linux-preempt, though
2021-09-17 17:42:13 <Hello71> wasn't preempt locks merged in 5.15
2021-09-17 17:42:26 <Hello71> 17:30 <syso> I need to run jack with realtime priority
2021-09-17 17:43:27 <Hello71> why do you think so
2021-09-17 17:43:43 <Hello71> https://jackaudio.org/faq/realtime_vs_realtime_kernel.html
2021-09-17 17:46:15 <syso> I was getting buffer underruns when not using preempt_rt before.
2021-09-17 17:46:24 <syso> and jitter issues
2021-09-17 17:46:58 <mps> syso: I doubt that will be accepted for alpine
2021-09-17 17:47:36 <mps> kernel 5.16 will be in better 'position' for this, but we will see when it is released
2021-09-17 17:48:07 <syso> hm, I trought it would not be a problem because it is officially supported by the linux foundation
2021-09-17 17:48:20 <mps> syso: we also have linux-edge in community which is 5.14 currently
2021-09-17 17:49:59 <dalias> ncopa, on re-reading i think they have something even more broken :-p
2021-09-17 17:50:04 <dalias> and it's their fault
2021-09-17 17:53:37 <Ariadne> dalias: they should contact docker, inc. for a support contract
2021-09-17 17:53:39 <Ariadne> :D
2021-09-17 17:54:12 <dalias> :-p
2021-09-17 17:54:18 <dalias> it's not even a docker issue
2021-09-17 17:54:36 <dalias> i'm pretty sure it's a "someone rolled a dumb dynamic firewall themselves" issue
2021-09-17 17:54:37 <Ariadne> i thought it was docker desktop
2021-09-17 17:54:39 <Ariadne> blah blah
2021-09-17 17:54:39 <Ariadne> oh
2021-09-17 17:54:41 <Ariadne> wow
2021-09-17 17:54:42 <Ariadne> :D
2021-09-17 17:54:56 <dalias> once it sees packet from port N to [prohibited-address]
2021-09-17 17:54:59 <dalias> it firewalls port N
2021-09-17 17:55:13 <dalias> and then the rest of the lookups to the allowed nameserver all fail
2021-09-17 17:55:17 <dalias> because the source port is blocked
2021-09-17 17:55:41 <Ariadne> my resourcefulness has paid off
2021-09-17 17:56:04 <Ariadne> i now have Vortex86DX industrial computer, running alpine
2021-09-17 17:56:14 <Ariadne> let the CVE hunting begin
2021-09-17 17:56:28 <dalias> because of course "let attacker create arbitrarily many iptables rules on your box" is good security practice
2021-09-17 17:56:31 <dalias> :)
2021-09-17 17:56:37 <Ariadne> that is the BEST security practice
2021-09-17 17:56:54 <jvoisin> 
ACTION coughs in the direction of fail2ban

2021-09-17 17:57:27 <dalias> yeah it's something like that
2021-09-17 17:57:53 <dalias> i love how unintentionally appropriately named fail2ban is
2021-09-17 17:57:54 <Ariadne> this machine is reasonably snappy
2021-09-17 17:58:04 <Ariadne> for being a not-really-i586
2021-09-17 17:58:21 <dalias> isn't it a lot faster than original intel machine in same class?
2021-09-17 17:58:31 <dalias> i mean just by clock, memory bus generation, etc.
2021-09-17 17:59:04 <dalias> original 586 had 60 or 66 mhz fsb (maybe even half that for dram?), no ddr or anything
2021-09-17 18:00:20 <Ariadne> yes
2021-09-17 18:00:24 <Ariadne> mine is 999mhz
2021-09-17 18:00:32 <Ariadne> that's 199mhz faster than the complainant's
2021-09-17 18:01:37 <dalias> this might actually be an awesome machine
2021-09-17 18:01:50 <syso> oh, i've just seen there is linux-octeon. does that mean it would run on the ubnt edgerouter?
2021-09-17 18:01:54 <dalias> it could be a contender for fastest non-speculative x86
2021-09-17 18:01:59 <dalias> assuming it's non-speculative
2021-09-17 18:02:22 <Ariadne> syso: yes, but i've dropped the port
2021-09-17 18:03:06 <dalias> dropped mips? or just the specific hardware target?
2021-09-17 18:03:08 <syso> Ariadne: ah ok, i have some er-x and er-pro-8 here.
2021-09-17 18:03:23 <Ariadne> er-x has mediatek cpu
2021-09-17 18:03:35 <Ariadne> dalias: mips64 entirely
2021-09-17 18:05:32 <Ariadne> the only hw we targeted was octeon
2021-09-17 18:05:42 <Ariadne> which is now dead
2021-09-17 18:05:48 <dalias> ah
2021-09-17 18:05:54 <Ariadne> i mean "octeon" still exists, but its ARM now
2021-09-17 18:07:08 <dalias> btw i know this is far-fetched..
2021-09-17 18:07:27 <dalias> but if maintaining alpine binary dist for lots of archs is as hard as it sounds..
2021-09-17 18:08:04 <mps> (:
2021-09-17 18:08:33 <dalias> is there plausibly some way to utilize repro builds and crowdsource it in a way that any target with sufficiently many interested users could have binary packages and establish consensus that they were built correctly?
2021-09-17 18:08:59 <dalias> you could even make a coin out of proving you built them </troll>
2021-09-17 18:09:12 <mps> :)
2021-09-17 18:15:05 <Hello71> "packagechain"
2021-09-17 18:21:52 <Ariadne> oh
2021-09-17 18:22:06 <Ariadne> this core from this `i686` device is SIGILL on `cmovne` instruction
2021-09-17 18:22:15 <Ariadne> so, let me get this straight
2021-09-17 18:22:26 <Ariadne> Vortex86DX i586 device lacks `lock cmpxchg8b`
2021-09-17 18:22:36 <Ariadne> Vortex86DX2 i686 device lacks fucking CMOV
2021-09-17 18:24:35 <Ariadne> can this company just stop making broken CPUs
2021-09-17 18:24:46 <Ariadne> they are as far as i can tell, sparkling 486s
2021-09-17 18:26:02 <Habbie> that is so wild i can hardly believe it
2021-09-17 18:26:34 <Habbie> i mean, i get not emulating the f00f crash bug in i586 ;)
2021-09-17 18:26:36 <Habbie> but cmov
2021-09-17 18:26:48 <Habbie> what if they're from the Intel region of France?
2021-09-17 18:28:38 <Ariadne> Habbie: `lock cmpxchg8b (%esi)` is a valid instruction though
2021-09-17 18:28:59 <Ariadne> the f00f bug is when you do it with a register instead of memory
2021-09-17 18:31:58 <Ariadne> i have to say, "lie about your processor capabilities and hope its fine" seems like a very silicon valley way of doing business
2021-09-17 18:32:07 <Ariadne> i was surprised to find out that DM&P is a Taiwanese company
2021-09-17 18:32:59 <ikke> hmm, we lost quite a few
2021-09-17 18:33:01 <ikke> RIO
2021-09-17 18:33:03 <ikke> RIP
2021-09-17 18:36:15 <syso> is abuild not respecting nproc? i have 48 cores here and kernel build takes now longer than 1h
2021-09-17 18:36:36 <Ariadne> see /etc/abuild.conf
2021-09-17 18:36:41 <Hello71> or just check ps
2021-09-17 18:38:33 <syso> ok, i see. thanks.
2021-09-17 20:12:26 <mps> https://lwn.net/Articles/869557/
2021-09-17 20:13:25 <mps> Ariadne Connil on openssl and maintainance
2021-09-17 20:13:42 <ikke> Her blogposts includes more
2021-09-17 20:14:33 <mps> yes, I know but this one is lwn
2021-09-17 20:14:58 <mps> newsboat is quite useful 'thing' ;)
2021-09-17 20:45:15 <andypost[m]> how to deal with apache2 cves for old branches?
2021-09-17 20:46:54 <ikke> can you clarify?
2021-09-17 20:49:09 <andypost[m]> should I file upgrades to 2.4.49 for 3.10 or not?
2021-09-17 20:52:34 <psykose> 3.10 is EOL
2021-09-18 00:12:48 <andypost[m]> all branches passed starting from !25464 
2021-09-18 06:50:00 <ikke> andypost[m]: if the vulnerability is high risc and it's trivial to patch it, we could opt to fix it for 3.10 as well
2021-09-18 07:10:30 <mps> ikke: risc or riscv :)
2021-09-18 07:10:38 <ikke> mps: :)
2021-09-18 07:10:40 <mps> sorry, couldn't resist
2021-09-18 07:11:51 <mps> smile instead of 'good morning'
2021-09-18 07:19:11 <ikke> good morning :)
2021-09-18 07:24:53 <mps> good morning (now serious one)
2021-09-18 07:28:55 <psykose> good morning (sarcastic)
2021-09-18 07:30:06 <ikke> good morning (ironic)
2021-09-18 07:46:06 <mps> heh, really funny morning reading this https://github.com/mTvare6/hello-world.rs
2021-09-18 07:56:15 <ikke> "This project is very minimal, it only requires 1092 crates" :D
2021-09-18 08:02:30 <maxice8> smallest rust project
2021-09-18 08:03:33 <mps> in what lang is this `." hello world!"`, though interpreted one (but could be also compiled)
2021-09-18 08:04:58 <mps> don't have Forth compiler on current machine to check size of binary
2021-09-18 08:07:10 <maxice8> gm
2021-09-18 09:22:55 <donoban> lol
2021-09-18 15:23:28 <orbea> just think how much effort that took to write, "Hello world"...
2021-09-18 15:24:12 <valerius> it is nice to see people pushing back against bloat using ridicule
2021-09-18 15:24:45 <orbea> even distros push back devs that don't know anything about distros will still put it in things like mesa or the kernel
2021-09-18 15:24:51 <orbea> *even if distros...
2021-09-18 15:25:58 <orbea> the problem is there is often very little communication between distros and devs in these instances...and if its just me I just look like that crazy guy that is hating on their "cool project"
2021-09-18 15:29:28 <valerius> core technologies should never rely on such things
2021-09-18 15:54:07 <Ariadne> alpine is not an anti-rust distribution, fwiw
2021-09-18 15:54:40 <Ariadne> alpine just wants a working relationship with the rust team that enables us to actually deliver a high enough quality rust implementation to warrant being in `main`
2021-09-18 15:54:55 <Ariadne> we are, i think, fairly close to having a deal
2021-09-18 16:19:16 <orbea> somehow I think that will not work out in practice
2021-09-18 16:19:35 <orbea> im not anti-rust, but that doesn't make it remotely well designed
2021-09-18 16:21:08 <orbea> that hello.rs basically makes the argument for me.
2021-09-18 17:16:58 <Ariadne> orbea: the SCP will be an interesting read, i think.
2021-09-18 17:17:08 <Ariadne> :)
2021-09-18 17:17:20 <ikke> link?
2021-09-18 17:19:16 <Ariadne> i haven't published it yet, we are still drafting it
2021-09-18 17:19:31 <Ariadne> but i will say jirutka believes it is possible
2021-09-18 17:19:37 <Ariadne> :)
2021-09-18 17:22:17 <orbea> I remain skeptical that rust can be fixed when the issues are so foundational, but no complaints with being shown I'm wrong :) I just wish it wasn't forced onto everyone before that happens.
2021-09-18 17:22:36 <orbea> ofc can't blame the distros for that
2021-09-18 17:23:50 <Ariadne> the plan is to make rust no worse than go
2021-09-18 17:24:10 <ikke> Personally I'd like go to be in main as well, but not sure if it's feasible
2021-09-18 17:24:12 <Ariadne> it is my hope that the model we adopt for rust can be "ported" to go
2021-09-18 17:24:32 <orbea> which is already a bit of a low bar imo, but at least go I can more or less just not use and still have a functioning computer
2021-09-18 17:24:44 <Ariadne> the rust developers have been quite cooperative, and want to engage in the same model we have proposed in this draft SCP with other distros, too
2021-09-18 17:25:12 <ikke> At least go seems to be quite stellar regarding arch support, but upstream effectively supports a release only for one year
2021-09-18 17:25:29 <ikke> N-2 releases
2021-09-18 17:25:31 <Ariadne> yes, and too many regressions in next release branch
2021-09-18 17:25:39 <Ariadne> historically
2021-09-18 17:25:55 <Ariadne> the model does work for rust, as long as upstream is responsive
2021-09-18 17:26:01 <Ariadne> since rust releases are "append-only"
2021-09-18 17:45:13 <valerius> why does it seem like Rust does not bring any benefits and only burdens?
2021-09-18 17:46:13 <valerius> it feels like a white elephant to me
2021-09-18 21:15:51 <ikke> A rust linker that says it's faster than gold and even llvm lld: https://github.com/rui314/mold
2021-09-18 21:52:21 <Ariadne> Hello71: looks fine, but /etc/ssl/cert.pem needs also to be symlinked
2021-09-18 22:39:41 <Hello71> eh right
2021-09-18 22:43:25 <psykose> ikke: this isn't a linker written in rust though
2021-09-18 22:45:11 <ikke> right, I see it's a general linker
2021-09-18 23:38:15 <smcavoy> I am trying to update ansible in Alpine. Anyone use ansible in Alpine extensivly? updating it requires a new package, 'ansible-core'. I create !25443 for that but an update to the 'ansible' package will cause conflict between the new 'ansible-core' and the existing 'ansible-base'. Just wondering how much hassle this might cause.
2021-09-19 03:41:53 <Saijin_Naib[m]> Could I get some feedback/review on this Kernel Module MR?
2021-09-19 03:41:53 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25016
2021-09-19 03:42:11 <Saijin_Naib[m]> My first contrib here, so... Yeah
2021-09-19 03:55:53 <smcavoy> I think you should squash all the commits into a single commit and maybe remove any lines that add a commented out option unless its actually changed from y or m to not set
2021-09-19 03:56:45 <Saijin_Naib[m]> Hmm
2021-09-19 03:57:28 <Saijin_Naib[m]> I took the current config-lts.x86_64 and loaded it to edit it with make menuconfig, so it should be as-is with the exception of the two modules I enabled
2021-09-19 03:57:40 <Saijin_Naib[m]> But you're saying just remove everything except what I changed?
2021-09-19 03:58:12 <Saijin_Naib[m]> Also, I'm not sure if the GitLab webUI lets me squash... gotta learn that
2021-09-19 04:06:18 <psykose> do it locally and force push it
2021-09-19 14:57:15 <Ariadne> 
ACTION debates requiring Linux 5.10 or newer for ifupdown-ng 0.12

2021-09-19 14:57:29 <Ariadne> pidfd would simplify my code a lot :(
2021-09-19 14:58:45 <ikke> I know the feeling
2021-09-19 14:59:11 <ikke> What kernel versions do the supported versions of debian use?
2021-09-19 14:59:15 <Ariadne> well, the real problem is waitid() sucks
2021-09-19 15:00:10 <Ariadne> musl also does not provide the pidfd functions yet
2021-09-19 15:01:26 <Ariadne> dalias: would you accept patches to musl adding the pidfd syscalls
2021-09-19 15:01:45 <Ariadne> (or are you concerned they lack maturity?)
2021-09-19 15:02:43 <Ariadne> hmm
2021-09-19 15:03:00 <Ariadne> you can open(2) a /proc/[pid] to get a process descriptor
2021-09-19 15:03:02 <Ariadne> so,
2021-09-19 15:03:14 <Ariadne> pidfd_open() should try to use the syscall, then fallback to that
2021-09-19 15:33:41 <sircmpwn> I was able to get an alpine iso built for RISC-V which boots via UEFI on the HiFive Unmatched without any SoC-specific changes to Alpine
2021-09-19 15:37:00 <sircmpwn> with these three patches merged:
2021-09-19 15:37:03 <sircmpwn> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/30
2021-09-19 15:37:05 <sircmpwn> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25513
2021-09-19 15:37:07 <sircmpwn> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25514
2021-09-19 15:37:18 <sircmpwn> we can generate installable alpine-standard iso images for 3.15+
2021-09-19 15:37:59 <sircmpwn> though you have to upgrade u-boot on the firmware, I'll prepare a write-up
2021-09-19 15:40:14 <ikke> sircmpwn: my understanding is that we do not want to provide a stable image untill we can build with tests enabled
2021-09-19 15:41:12 <sircmpwn> well, at least these patches will reduce the amount of work to flipping a switch
2021-09-19 15:41:19 <sircmpwn> and help with testing the port out
2021-09-19 15:41:25 <ikke> 👍
2021-09-19 15:42:00 <psykose> oh damn, that looks nice
2021-09-19 15:42:04 <Ariadne> we can include it in edge snapshots though
2021-09-19 15:43:13 <Ariadne> realistically, we could probably switch tests on in general for riscv64 now, and just disable on some packages where they are too slow
2021-09-19 15:44:42 <Ariadne> sircmpwn: i merged the aports ones, alpine-conf will require ncopa to review (but looks fine)
2021-09-19 15:44:46 <sircmpwn> cheers
2021-09-19 16:20:05 <dalias> ariadne, they're *probably* ok. does glibc expose functions now?
2021-09-19 16:21:45 <ericonr> at least on glibc master, not yet
2021-09-19 16:22:58 <ericonr> they are only exposing the syscall numbers that I can see
2021-09-19 16:31:33 <Ariadne> sure would be nice to have them
2021-09-19 16:32:05 <Ariadne> you can get by with signalfd() for monitoring a process, but its annoying by comparison
2021-09-19 16:32:14 <Ariadne> you have to write like 2x the code
2021-09-19 16:32:36 <skarnet> probably a little more :P
2021-09-19 16:33:55 <Ariadne> the process descriptors are interesting for other reasons
2021-09-19 16:34:03 <Ariadne> for example, you can transfer them around with SCM_RIGHTS
2021-09-19 16:34:14 <Ariadne> you can also transfer new rights to a process descriptor
2021-09-19 16:34:23 <Ariadne> something something sudo
2021-09-19 16:34:52 <skarnet> your scientists were so preoccupied with whether or not they could
2021-09-19 16:35:21 <Ariadne> a daemon which transfers CAP_ADMIN to an authorized process descriptor seems sound to me
2021-09-19 16:36:24 <Ariadne> i mean, all the other caveats of privileged daemons aside
2021-09-19 16:36:38 <skarnet> yeah but that has nothing to do with ifupdown-ng
2021-09-19 16:36:51 <Ariadne> no
2021-09-19 16:36:56 <skarnet> I thought you were still speaking in that context
2021-09-19 16:37:04 <Ariadne> in this case i talk in general context
2021-09-19 16:37:05 <Ariadne> :)
2021-09-19 16:37:07 <skarnet> in general, sure, process descriptors are useful in particular for that
2021-09-19 16:37:28 <skarnet> "in general in particular" I can really speak very good
2021-09-19 16:38:05 <Ariadne> you can also do reverse-SCM_RIGHTS with pidfd_getfd(2)
2021-09-19 16:38:13 <Ariadne> though i haven't any idea what a use case for that would be
2021-09-19 16:39:34 <skarnet> I'd say, more robust fd-passing than SCM_RIGHTS, but Linux's SCM_RIGHTS is already quite good
2021-09-19 16:39:44 <skarnet> it's on BSD that they're wobbly af
2021-09-19 16:40:06 <Ariadne> pidfd_getfd(2) allows you to clone an FD from a target process
2021-09-19 16:40:13 <Ariadne> its the opposite of SCM_RIGHTS
2021-09-19 16:40:40 <skarnet> yes but with the right protocol :P
2021-09-19 16:40:45 <dalias> ariadne, transferring CAP_ADMIN sounds completely unsafe
2021-09-19 16:40:47 <dalias> worse than suid
2021-09-19 16:41:48 <skarnet> dalias: why worse? because you don't know what binary you're elevating the rights of?
2021-09-19 16:42:16 <dalias> yeah. the user *necessarily* has the ability to modify that binary in-memory just as it's getting the cap
2021-09-19 16:42:23 <dalias> and then do whatever they want with the cap
2021-09-19 16:42:32 <dalias> it's like suid but without ptrace restriction
2021-09-19 16:42:41 <skarnet> ah, that makes sense
2021-09-19 16:43:35 <dalias> there is simply no condition under which *elevating* privilege anywhere in the process tree is secure. it's only a matter of "we nailed shut enough windows it's hard to exploit" or "it's a gaping hole"
2021-09-19 16:43:47 <dalias> and in this case suid is the former and passing around cap_admin is the latter
2021-09-19 16:44:34 <Ariadne> hmm, true
2021-09-19 16:44:38 <Ariadne> however
2021-09-19 16:45:03 <Ariadne> this could still be used to set up the PTY and job handling correctly
2021-09-19 16:45:47 <dalias> there were historically all sorts of vulns with user having access to a tty device root processes are running on
2021-09-19 16:46:17 <Ariadne> well, the user has access
2021-09-19 16:46:19 <Ariadne> with sudo
2021-09-19 16:46:23 <Ariadne> or ssh root@localhost
2021-09-19 16:46:24 <dalias> you really just want to proxy the tty (i.e. what ssh does) not attach root processes to the user's tty
2021-09-19 16:46:32 <dalias> with ssh they don't
2021-09-19 16:46:36 <dalias> there are 2 different ttys
2021-09-19 16:46:45 <dalias> and sshd/ssh is mediating them
2021-09-19 16:48:34 <Ariadne> well anyway
2021-09-19 16:48:41 <Ariadne> process descriptors allow you to do stupid shit
2021-09-19 16:52:05 <dalias> hheh how do they do that?
2021-09-19 16:53:06 <dalias> btw i think pidfd_getfd needs perms comparable to opening it via procfs
2021-09-19 16:58:10 <Ariadne> it does
2021-09-19 16:58:38 <Ariadne> you would need some sort of capabilities broker in any case to transfer rights and FDs around
2021-09-19 17:55:43 <sircmpwn> is there a reason we're hanging back on binutils
2021-09-19 17:56:24 <dalias> not that im aware of
2021-09-19 17:57:17 <sircmpwn> cc ncopa: binutils upgrade?
2021-09-19 17:59:26 <Ariadne> sircmpwn: we can go to 2.37, i'll work on it tomorrow
2021-09-19 18:00:01 <Ariadne> i was planning to go to 2.37 and update gcc anyway
2021-09-19 18:00:16 <Ariadne> theres some bugfixes in gcc i want to pick up relating to arm
2021-09-19 18:00:24 <Ariadne> and some fortran stuff
2021-09-19 18:04:40 <sircmpwn> will help with a minor risc-v thing also
2021-09-19 18:04:42 <sircmpwn> thanks
2021-09-19 18:14:28 <artok> another reason to jump into llvm toolchain wagon
2021-09-19 18:15:31 <dalias> ?
2021-09-19 18:15:39 <artok> risc-v and arm people seem to work with llvm more (or it was just because I watched llvm lightning talks few days ago =) )
2021-09-19 18:16:01 <sircmpwn> that doesn't make any sense
2021-09-19 18:21:21 <Misthios> mps: llvm12 is done!!, just gotta fix git history now lol (messed it up while ago when rebasing and amending)
2021-09-19 18:22:36 <ikke> Misthios: nice
2021-09-19 18:22:53 <Misthios> (unless 1 of the other arches fail rn )
2021-09-19 18:27:53 <mps> Misthios: very good news. thank you for working on it
2021-09-19 18:28:16 <Misthios> thank me when its actually done and in the repo :)
2021-09-19 18:29:04 <mps> every step in making it nearer to repo is good and deserves praise
2021-09-19 19:05:11 <Thermi_> re aports !24478, mps, are there any other devs that dislike it?
2021-09-19 20:03:27 <ikke> sneak preview for gitlab 14: https://gitlab-test.alpinelinux.org
2021-09-19 20:03:40 <sircmpwn> is it better or worse
2021-09-19 20:03:50 <ikke> decide for yourself
2021-09-19 21:13:48 <elibrokeit> I'm going to go out on a limb and say they haven't solved the "everything loads really slowly after the fact via JavaScript" problem
2021-09-19 21:47:41 <craftyguy> any chance review of this one can be prioritized a bit? it fixes broken audio during calls on the pinephone with pmOS:  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25528
2021-09-19 21:51:20 <andypost[m]> ikke: 14 looks faster in browser
2021-09-19 23:31:21 <andypost[m]> Ariadne: how it possible that botan-dev has different openssl dependencies for arches?
2021-09-19 23:31:32 <andypost[m]> just stuck with it https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/94025
2021-09-19 23:31:53 <andypost[m]> failed ones are using 1.1-compat
2021-09-20 00:35:42 <Hello71> i wonder how much of the speedup is due to less crawler background load
2021-09-20 02:45:28 <dalias> ariadne, did you find out anything more about the vortex86?
2021-09-20 02:45:43 <dalias> i've been searching for stuff on its microarchitecture but couldn't find anything
2021-09-20 03:11:32 <craftyguy> mps: thank you :)
2021-09-20 06:08:13 <ikke> morning
2021-09-20 06:17:59 <ncopa> good morning
2021-09-20 06:18:02 <mps> craftyguy: you are welcome :) (though I don't understand for what you thanks to me )
2021-09-20 06:18:29 <mps> ave Caeser ;)
2021-09-20 06:18:43 <mps> good morning
2021-09-20 06:20:14 <ikke> maybe they think you are Michael Polanski
2021-09-20 06:21:40 <ncopa> looks like something broke chromium recently
2021-09-20 06:21:42 <mps> hah, could be
2021-09-20 06:21:45 <ncopa> Error relocating /usr/lib/chromium/chrome: hb_subset_input_set_retain_gids: symbol not found
2021-09-20 06:23:14 <mps> with 'hah, could be' I mean to 'answer' to ikke 
2021-09-20 06:24:08 <sircmpwn> thanks ncopa 
2021-09-20 06:24:15 <sircmpwn> I'll ping you for a new tag later
2021-09-20 06:28:13 <ncopa> np
2021-09-20 07:46:08 <sam_> ncopa: new harfbuzz dropped an unstable API that chromium was (ab)using
2021-09-20 07:46:36 <ikke> fun
2021-09-20 08:39:11 <maribu> identify Windoofs007
2021-09-20 08:40:09 <ikke> oof :)
2021-09-20 08:44:51 <maribu> Guess it was change my password day today anyway...
2021-09-20 08:45:28 <ikke> hehe :)
2021-09-20 08:46:14 <maribu> Are the builders busy rebuilding everything against openssl? It seems that subversion needs to be rebuild against serf, but some of the dependencies seem not yet to be rebuild against openssl.
2021-09-20 08:46:26 <ikke> no
2021-09-20 08:46:57 <ikke> which dependencies?
2021-09-20 08:47:10 <ikke> some are explicitly held back to openssl1.1
2021-09-20 08:49:11 <ikke> for example, mariadb does not support openssl3.0 yet, so everything that mariadb needs also cannot be compiled against openssl3.0 yet
2021-09-20 08:49:16 <maribu> SVN fails for me with 'Error relocating /usr/lib/libserf-1.so.1: ERR_GET_FUNC: symbol not found'. `abuild -r` fails for me due to openssl1.1-compat-dev conflicting with openssl-dev, but both needed for the rebuild.
2021-09-20 08:49:38 <maribu> @ikke: I see
2021-09-20 08:50:40 <ikke> sounds like serf also needs that treatment
2021-09-20 08:50:55 <ikke> or I mean, needs to use openssl1.1-compat-dev
2021-09-20 08:56:05 <maribu> OK, rebuilding neon and serf with openssl1.1-compat-dev instead of openssl-dev as make dependency allows me to rebuild subversion.
2021-09-20 08:56:24 <Ariadne> feel free to send an MR doing it
2021-09-20 08:56:26 <Ariadne> :)
2021-09-20 08:57:39 <Ariadne> maribu1: feel free to send an MR doing it.  we are still in the shaking out dependencies in community phase of this
2021-09-20 08:59:30 <maribu1> Ah, cool. The matrix bridge seems to work again :-)
2021-09-20 09:01:32 <ikke> Ah, nice for you
2021-09-20 09:03:42 <maribu1> With https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25544 subversion should work again
2021-09-20 09:06:16 <Misthios> maribu, happened to me as well with the password :)
2021-09-20 09:08:49 <maribu1> I was in the process of switching to use a password manager even for my non-money-or-work-related stuff anyway, so it actually was a good thing ;-)
2021-09-20 09:44:34 <Ariadne> dalias: there are different models, the latest one is an i686 core that actually fully implements i686
2021-09-20 09:45:14 <Ariadne> as for uarch docs i have yet to find anything
2021-09-20 09:48:15 <Ariadne> andypost: because it needs to be rebuilt
2021-09-20 11:03:25 <caskd> Any python packagers here that know how to package python software that doesn't provide setuptools setup.py and only requirements.txt?
2021-09-20 11:10:54 <sircmpwn> send upstream a patch adding a setup.py would be my advice
2021-09-20 11:11:27 <caskd> well, ideally yeah but is there a way to convert a pip requirements list to setup.py?
2021-09-20 11:14:40 <ikke> You don't need to list all the dependencies necessarily in setup.py afaik
2021-09-20 11:19:35 <caskd> right, but i have no knowledge of the true dependencies without the chain so i don't know what the true requirements would be without trial and failure
2021-09-20 11:21:40 <ikke> Is making sure the listed dependencies in requirements.txt are installed enough?
2021-09-20 11:22:07 <caskd> yeah
2021-09-20 11:22:37 <ikke> Then what is the issue?
2021-09-20 11:23:31 <caskd> wait, i must have misunderstood. You said that i don't have to list all deps in setup.py, and i said that i don't know the top level dependencies
2021-09-20 11:23:44 <ikke> You said there was a requirements.txt
2021-09-20 11:24:06 <caskd> oh, the requirements.txt doesn't have all deps
2021-09-20 11:24:11 <caskd> my bad
2021-09-20 11:24:22 <ikke> There is no way to find out all the deps then
2021-09-20 11:24:37 <ikke> maybe some static analyzer, but I'm not aware of any
2021-09-20 11:24:47 <caskd> probably pip can provide the dep chain
2021-09-20 11:24:52 <caskd> i'll look into it
2021-09-20 11:24:55 <ikke> Why do you need the chain?
2021-09-20 11:24:59 <ikke> aren't top-level dependencies enough
2021-09-20 11:25:02 <ikke> ?
2021-09-20 11:25:21 <caskd> should be actually
2021-09-20 11:25:32 <ikke> apk can install all the transitive dependencies
2021-09-20 11:25:44 <ikke> you just need to make sure you list the direct depedencies in the APKBUILD
2021-09-20 11:25:47 <caskd> sorry for the confusion, i don't work often with python packages so i don't know how deps are managed
2021-09-20 11:25:53 <caskd> i see
2021-09-20 11:26:13 <ikke> Same with any other dependency
2021-09-20 11:43:28 <elibrokeit> caskd: a pip requirements.txt is exactly the same as a.setuo.py.which contains exactly one argument: "install_requires=[list of requirements.txt]"
2021-09-20 11:43:49 <elibrokeit> In other words it's missing nearly all the interesting stuff ;)
2021-09-20 11:44:04 <caskd> oh
2021-09-20 11:44:09 <caskd> you can just source that?
2021-09-20 11:47:29 <elibrokeit> If by sourcing it, you mean using it as the inspirational basis for writing a setup.py
2021-09-20 11:47:29 <elibrokeit> But all the hard stuff will be missing, like getting it to install onto the python path, making sure it *imports* itself using a functional import path, making sure it doesn't overly rely on tricks like finding out the directory it is running from...
2021-09-20 13:02:21 <dalias> ariadne, yeah, that's all i could find too
2021-09-20 13:02:44 <dalias> i wonder if anyone's decapped one
2021-09-20 13:06:12 <Ariadne> i dont think they speculate or anything
2021-09-20 13:08:12 <dalias> and also likely no hidden management layers
2021-09-20 13:09:02 <dalias> maybe even no SMM/SMI
2021-09-20 13:09:31 <dalias> or if it is there, it probably lacks any protection from ring0 getting rid of it
2021-09-20 13:10:13 <dalias> iow seems like it might be a decently fast, spectre-free, backdoor-free x86
2021-09-20 13:15:35 <Ariadne> x86-32 is boring tho
2021-09-20 13:19:59 <dalias> not for me, but yes for many ppl
2021-09-20 13:20:07 <dalias> still it has good tooling and software availability
2021-09-20 13:20:42 <Ariadne> i wouldn't use any of the old versions like the DX2 etc
2021-09-20 13:21:07 <Ariadne> the DX3 seems to be all there, as long as you don't care about MMX or SSE
2021-09-20 13:21:36 <Ariadne> basically like having a 1ghz pentium pro :P
2021-09-20 13:21:56 <Ariadne> which does not speculate
2021-09-20 13:22:06 <dalias> with modern ram speed
2021-09-20 13:22:09 <Ariadne> so really more like a 1ghz 486
2021-09-20 13:22:10 <dalias> that's the big difference
2021-09-20 13:22:20 <Ariadne> oh, i think those SoC are only DDR2
2021-09-20 13:22:20 <dalias> pentium/ppro is not speculative
2021-09-20 13:22:49 <dalias> still the comparable intel chips were pre-ddr
2021-09-20 13:23:31 <dalias> vendor site says ddr3
2021-09-20 13:23:31 <Ariadne> the power use is probably much lower than a ppro as well
2021-09-20 13:23:39 <dalias> and 2.5 ghz pcie bus (?)
2021-09-20 13:23:52 <Ariadne> hmm, that is tolerable
2021-09-20 13:24:00 <Ariadne> probably PCIe 1.0 or 2.0 tho
2021-09-20 13:24:14 <Ariadne> i guess the question is how many PCIe/SERDES lanes does it have
2021-09-20 13:24:45 <dalias> i think it's considerably less capable than the s1260
2021-09-20 13:24:58 <dalias> but still in production, and lacks lots of intel misfeatures
2021-09-20 13:31:29 <Ariadne> well these CPU companies like to cram in I/O to make up for the CPU story being boring
2021-09-20 13:31:39 <Ariadne> like my honeycomb is basically 4 mediocre cell phones strapped together
2021-09-20 13:33:27 <Ariadne> but it has like 24 lanes of SERDES (which can be connected to the PCIe block for PCIe)
2021-09-20 13:33:54 <Ariadne> so this cpu might not be that capable, but it could still have a boatload of SERDES lanes
2021-09-20 13:36:03 <Ariadne> also intel misfeatures?
2021-09-20 13:36:06 <Ariadne> what are you talking about
2021-09-20 13:36:10 <Ariadne> meltdown is GREAT
2021-09-20 14:00:57 <sircmpwn> ScrumpyJack: forgot to Cc you on this one https://lists.alpinelinux.org/~alpine/aports/patches/3672
2021-09-20 14:20:44 <PureTryOut> ncopa could you take a look at !24838?
2021-09-20 14:48:17 <HRio> would like some feedback on !25492, OK solution? 
2021-09-20 15:25:45 <Ariadne> looks ok
2021-09-20 16:19:06 <HRio> Ariadne: thanks for merging.
2021-09-20 16:42:22 <Misthios> Cogitri (or someone else ) can you review !25551 when you have time?
2021-09-20 16:49:17 <mps> Misthios: is it ready for merge
2021-09-20 16:49:38 <Misthios> should be
2021-09-20 16:50:17 <mps> you make it from one APKBUILD?
2021-09-20 16:50:32 <Misthios> no
2021-09-20 16:50:53 <Misthios> every package has its own commit in the mr
2021-09-20 16:51:09 <mps> ah, yes, sorry I misread MR
2021-09-20 16:52:27 <Misthios> the way it builds is kinda hacky but its the only way i found to build it in multiple apkbuilds
2021-09-20 16:53:10 <mps> ok, however you want, though I would do such things one by one
2021-09-20 16:53:32 <psykose> there's a few style issues you should fix
2021-09-20 16:54:18 <mps> style can be fixed later, when all this hmhmhm start to work
2021-09-20 16:55:11 <Ariadne> why is the patch deleted from llvm11
2021-09-20 16:57:41 <Misthios> i dindt touch llvm11 myself, just worked with cogitris commit but i messed up rebase so had to do some moving (might have missed it)
2021-09-20 16:57:45 <Misthios> lemme take a look
2021-09-20 16:58:03 <psykose> that'll do it
2021-09-20 16:59:57 <Misthios> hmm yes i missed the patch but it seems as the patch wasnt needed anymore (+++ llvm-7.0.1.src/test/BugPoint/compile-custom.ll.py	2019-03-10  + still builds fine)
2021-09-20 17:03:17 <Ariadne> ah
2021-09-20 19:23:38 <Biswa96> Just exploring abuild. Is there any script to build & test a package for all architectures in docker like GitLab CI?
2021-09-20 19:24:54 <ikke> https://gitlab.alpinelinux.org/alpine/docker-abuild
2021-09-20 19:31:07 <Biswa96> Thanks.
2021-09-21 06:42:52 <mps> trying to setup glab and have this question in gitlab.a.o 'Add a personal access token: Enter the name of your application, and we'll return a unique personal access token."
2021-09-21 06:43:15 <mps> what is this app, freely naming it?
2021-09-21 06:44:50 <ikke> yes
2021-09-21 06:44:55 <ikke> just a reminder for yourself
2021-09-21 06:50:06 <mps> thanks, done
2021-09-21 06:56:55 <ikke> ncopa: fyi, I've added export CARGO_HTTP_MULTIPLEXING=false to /etc/abuild.conf on a couple of builders that had issues with downloading crates from crates.io
2021-09-21 07:34:21 <maribu1> Is anyone using flatpak here? I have a strange bug that downloads fail. Updating the runtime org.freedesktop.Platform only gets 80 MB (+/- 2MB) of 198.4 MB until it gets stuck. The issues persists since yesterday.
2021-09-21 07:35:07 <PureTryOut> I had the same but it disappeared over time it seems
2021-09-21 07:38:21 <maribu1> I was running `timeout --foregroud 180 flatpak update -y; flatpak repair` in a shell loop yesterday for 12h. The download at 6MB/s should only take less than 40 seconds. It still failed. I reinstalled flatpak, rebuild and reinstalled flatpak, ran `flatpak update --no-deploy` to confirm it really is the download part. I think there is something seriously broken.
2021-09-21 07:39:32 <maribu1> Especially since the update freezes roughly at the same percentages every time...
2021-09-21 07:40:23 <Cogitri[m]> Maybe libcurl is acting up again?
2021-09-21 07:41:36 <maribu1> It doesn't seem to depend on libcurl according to `apk info -a flatpak`. Also the log contains entries like this: `Loading https://dl.flathub.org/repo/summaries/d6f46d4be313c298cac660543f44eed5c3a3841d11ff5c76d132ce940bd47275.idx.sig using libsoup`
2021-09-21 07:42:04 <maribu1> I did rebuild libsoup as a wild guess, but to no avail.
2021-09-21 07:45:29 <maribu1> Looks like libsoup uses glib-networking, which I cannot rebuild due to failing unit tests. Maybe that's the culprit?
2021-09-21 07:56:42 <Cogitri[m]> Hm, but glib-networking hasn’t been touched for some time now
2021-09-21 07:57:06 <Cogitri[m]> And still uses gnutls instead of OpenSSL
2021-09-21 07:57:28 <Cogitri[m]> So it couldn’t be affected if the recent OpenSSL changes I think
2021-09-21 07:57:45 <maribu1> Updating it to 2.70.0 results in one test less failing. Switching to openssl instead of gnutls (I used openssl1.1-compat-dev) results in no tests failing anymore. Still, flatpak misbehaves as before.
2021-09-21 07:58:30 <Cogitri[m]> Hm, that’s unfortunate
2021-09-21 08:00:54 <PureTryOut> Still an improvement I would say
2021-09-21 08:01:13 <maribu1> Honestly, I wonder what was the design rationale for using libsoup. If they would have just spawned wget they would even be able to resume interrupted downloads. A feature that I am really missing.
2021-09-21 08:02:18 <Cogitri[m]> Having a proper API to hook into is a fair bit nicer than just spawning some other process and trying to parse errors etc. from that
2021-09-21 08:02:37 <Cogitri[m]> And free async with GLib
2021-09-21 08:11:59 <ktprograms> Hi, can anyone please take a look at my MR that fixes lbu include not working if you're not in / ? Thanks! https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/29
2021-09-21 08:50:57 <Ariadne> maribu1: flatpak does not appear related to any of the openssl
2021-09-21 08:51:01 <Ariadne> work
2021-09-21 08:53:04 <Cogitri[m]> Yes, it currently still uses gnutls
2021-09-21 09:02:11 <PureTryOut> Ariadne: is !23363 good for you?
2021-09-21 09:02:24 <Ariadne> yes
2021-09-21 09:02:27 <Ariadne> go ahead and send it
2021-09-21 09:15:04 <PureTryOut> Thanks!
2021-09-21 09:16:44 <PureTryOut> Oh actually I can't, it includes a portaudio upgrade which is in main. Any chance you can do it Ariadne?
2021-09-21 09:17:25 <Ariadne> done
2021-09-21 09:18:15 <ikke> PureTryOut: so it's actually blocking you know?
2021-09-21 09:18:17 <ikke> now*
2021-09-21 09:18:33 <Ariadne> OpenSSH 8.8 is coming out which includes the necessary prerequisites to deprecate the legacy SCP protocol for file transfers (scp the program still exists, using sftp instead)
2021-09-21 09:18:41 <PureTryOut> ikke: sorry, I'm not sure what you're asking?
2021-09-21 09:18:42 <Ariadne> ikke: i think that PureTryOut can be given access to main
2021-09-21 09:18:55 <Ariadne> if he wants it anyway
2021-09-21 09:19:13 <ikke> Ariadne: I guess we should define via the TSC how this process goes
2021-09-21 09:19:21 <Ariadne> sure
2021-09-21 09:19:28 <Ariadne> i was just saying either way it gets an ack from me
2021-09-21 09:19:32 <PureTryOut> I don't mind either way, I don't do much stuff in main
2021-09-21 09:19:41 <Ariadne> anyway, barring any specific reason not to, i plan to upgrade all release branches to openssh 8.8
2021-09-21 09:19:57 <Ariadne> as i would really like to see the SCP protocol (and its multitude of security issues) die
2021-09-21 09:20:35 <PureTryOut> In a fire preferably
2021-09-21 09:27:50 <PureTryOut> Something is holding the ppc64le CI up...
2021-09-21 09:29:22 <ikke> You :P
2021-09-21 09:29:24 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/492585
2021-09-21 09:29:40 <PureTryOut> Damn haha
2021-09-21 09:29:59 <PureTryOut> Build is done though, not sure what it's doing
2021-09-21 09:30:07 <ikke> merge after rebases?
2021-09-21 09:30:17 <ikke> (direct merge)
2021-09-21 09:30:27 <ikke> You can cancel it
2021-09-21 09:30:41 <PureTryOut> Oh yeah, ok
2021-09-21 09:31:45 <mps> huh, 7befdd7374d9ef43c62e872083f22cb43e3ab489 '- openssh-client-default  a provider for openssh-client without krb5'. why this and especially without announce somewhere
2021-09-21 09:32:26 <ncopa> mps: it was done without announce because it shouldnt break anything
2021-09-21 09:33:28 <ncopa> the idea is that `apk add openssh-client` should give you the simple client without pulling in krb5 by default
2021-09-21 09:33:41 <mps> it doesn't break, true. but I was 'stumbled' a minute or two when I saw this in apk version 
2021-09-21 09:33:51 <ncopa> but if user wants krb5 support, user could apk add openssh-client-krb5
2021-09-21 09:34:21 <mps> it could stay named 'openssh-client'
2021-09-21 09:34:43 <ncopa> no. thats the name of the "virtual" package
2021-09-21 09:34:45 <mps> yes, yes. I understand reasoning and it is ok
2021-09-21 09:35:05 <mps> but was surprised with name
2021-09-21 09:35:32 <ncopa> you can now have a package that depends="openssh-client"
2021-09-21 09:35:43 <ncopa> and have openssl-client-krb5 installed and everything works as expected
2021-09-21 09:36:05 <mps> you mean openssh-client-krb5
2021-09-21 09:36:13 <ncopa> yes
2021-09-21 09:36:28 <mps> I understand all this
2021-09-21 09:37:20 <mps> (and wonder why anyone will use ssh with krb, but this is OT)
2021-09-21 09:39:24 <ikke> different environments have different requirements
2021-09-21 09:40:17 <mps> ncopa: I looked at void linux and arch linux, they build kernel-headers from the build as linux-xxx (PKGBUILD and template for void)
2021-09-21 09:40:37 <mps> we have separate aport for this
2021-09-21 09:41:08 <mps> thought to look at debian but still didn't (time will kill me)
2021-09-21 09:41:17 <Ariadne> debian does the same
2021-09-21 09:41:23 <mps> my thinking is we should do same
2021-09-21 09:41:34 <Ariadne> i think the idea was that we wanted "clean" kernel headers
2021-09-21 09:41:40 <Ariadne> when we were building grsec kernels
2021-09-21 09:41:43 <mps> Ariadne: thanks, you saved me some time (again)
2021-09-21 09:42:56 <mps> I plan to add linux-headers-edge, if no one have objections
2021-09-21 09:43:22 <mps> or linux-edge-headers
2021-09-21 09:44:46 <mps> also, our linux-*-dev packages are huge, I think we should 'slim' it to some degree
2021-09-21 09:45:23 <mps> already started to work on this for linux-edge
2021-09-21 09:45:36 <ncopa> why linux-edge-headers? when should linux-edge-headers be used instead of linux-headers?
2021-09-21 09:46:07 <ncopa> sounds like it just adds confusion
2021-09-21 09:46:10 <mps> as a starting point for linux-lts headers
2021-09-21 09:46:44 <mps> main reason is I don't want for now touch linux-lts on this
2021-09-21 09:46:45 <ncopa> why would we want linux-lts headers?
2021-09-21 09:47:01 <ncopa> i dont think it makes any sense at all
2021-09-21 09:47:08 <mps> no, we should keep previos name
2021-09-21 09:47:33 <mps> I just 'brainstorming'
2021-09-21 09:47:50 <ncopa> we want the linux-headers as separate, independent package
2021-09-21 09:47:52 <mps> sorry, urgent job, cul
2021-09-21 09:47:54 <ncopa> its just the headers
2021-09-21 09:48:16 <ncopa> we dont want it to be attached to any specific confgiruation or patched version flavor
2021-09-21 09:48:32 <ncopa> it should be config and kernel patch agnostic
2021-09-21 09:49:08 <ncopa> and we may want have newer version of the linux-headers than we have for the linux-lts or linux-rpi runtime kernels
2021-09-21 09:49:55 <ncopa> we want the linux-headers to be independent
2021-09-21 10:30:17 <skarnet> <mps> sorry, urgent job, cul
2021-09-21 10:30:43 <skarnet> as a French person, all I can say is "your are obviously excused, have fun!"
2021-09-21 10:31:44 <skarnet> you*
2021-09-21 10:33:53 <ikke> skarnet: just of the last word?
2021-09-21 10:33:59 <ikke> because of*
2021-09-21 10:36:31 <skarnet> yup. "cul" means "ass", and by metaphorical extension, "sex-related stuff". We absolutely understand how this can be urgent. ;)
2021-09-21 11:17:02 <mps> skarnet: if 'cul' for you mean 'ass' enjoy. for me it is shorthand for see you later
2021-09-21 11:20:34 <mps> ncopa: I'm back
2021-09-21 11:21:32 <mps> if 'we' want newer linux-headers we can always build it separately
2021-09-21 11:22:24 <mps> and yes, we don't need patched linux-headers, just those which can be built from kernel source
2021-09-21 11:23:39 <mps> by building linux-headers from kernel source with kernels we can 'remove' linux-*-dev subpackages (I hope)
2021-09-21 11:24:47 <mps> aside this, we probably need to build linux-*-docs subpackage
2021-09-21 11:25:48 <mps> how and why all this is for further discussion
2021-09-21 11:26:28 <mps> I will start all this with linux-edge and see does this makes sense
2021-09-21 11:34:41 <Ariadne> we want keep headers separate
2021-09-21 11:35:36 <mps> Ariadne: who are 'we'?
2021-09-21 11:36:12 <Ariadne> i mean, the TSC has not formally decided on it, but
2021-09-21 11:36:31 <Ariadne> both myself and ncopa did explain why its separate and why we want to keep it that way
2021-09-21 11:37:37 <mps> then at least current linux-headers should be improved
2021-09-21 11:38:29 <Ariadne> improved in what way
2021-09-21 11:38:37 <Ariadne> we are intentionally tracking 5.10 for it
2021-09-21 11:38:45 <mps> some headers file should be added
2021-09-21 11:38:59 <Ariadne> oh?
2021-09-21 11:39:31 <Ariadne> the point is to provide 5.10 UAPI headers.
2021-09-21 11:39:34 <mps> I can't tell from the head right now which ones
2021-09-21 11:39:54 <Ariadne> if there are new headers in new releases, then they are not appropriate for inclusion yet
2021-09-21 11:40:17 <mps> no, I mean from current lts kernel
2021-09-21 11:40:29 <Ariadne> are they part of the UAPI set ?
2021-09-21 11:41:00 <mps> iirc some yes, but also some other is missing
2021-09-21 11:41:54 <mps> s/is/are/
2021-09-21 11:42:29 <Ariadne> okay
2021-09-21 11:42:47 <Ariadne> well, `linux-headers` is not for building kernel modules
2021-09-21 11:42:52 <Ariadne> we only care about the UAPI ones
2021-09-21 11:43:11 <mps> btw, I don't insist on this, if alpine are hapy with current state I will not 'push' this forward
2021-09-21 11:44:35 <mps> (already loosing interest to work much on alpine)
2021-09-21 11:46:10 <Ariadne> well, i don't know if we are happy or not, if there are UAPI headers missing, that would be a bug
2021-09-21 11:48:52 <mps> apk info -L linux-headers | grep -i uapi
2021-09-21 11:51:12 <Ariadne> btw
2021-09-21 11:51:20 <Ariadne> i suspect that next LTS will be 5.16
2021-09-21 11:51:54 <mps> apk info -L linux-headers | grep -i mac8021
2021-09-21 11:52:00 <mps> etc etc ...
2021-09-21 11:53:23 <mps> Ariadne: http://phb-crystal-ball.org/
2021-09-21 11:54:09 <mps> so, it will be 5.15 probably
2021-09-21 11:54:30 <mps> which is really buggy for now
2021-09-21 13:43:41 <minimal> Ariadne: looks like openssh might be delaying the scp change: https://github.com/openssh/openssh-portable/commit/277d3c6adfb128b4129db08e3d65195d94b55fe7
2021-09-21 13:46:03 <Ariadne> minimal: they are, but they requested that people backport the extension so they can flip the switch in 8.9
2021-09-21 13:56:55 <dalias> ncopa, another layer... somehow the reporter failed to mention they're using slirp...
2021-09-21 13:57:02 <dalias> *sigh*
2021-09-21 14:17:00 <andypost[m]> ncopa: upgrade works but missing libs needs your opinion https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25610#note_181194
2021-09-21 14:47:26 <Ariadne> dalias: do you remember what the binutils ppc64 issue was about?
2021-09-21 14:48:37 <Ariadne> oh
2021-09-21 14:48:39 <Ariadne> now i remember
2021-09-21 14:48:45 <Ariadne> its about ibm long double blah blah
2021-09-21 14:48:50 <Ariadne> i guess we still need it
2021-09-21 14:49:20 <dalias> ?
2021-09-21 14:49:34 <dalias> oh did it do some stupid thing when linking libgcc?
2021-09-21 14:49:44 <dalias> wrongly flagging incompat abi or something
2021-09-21 14:52:52 <Ariadne> yeah
2021-09-21 14:55:03 <Ariadne> we need to keep it
2021-09-21 15:01:02 <mps> could 'we' add qsort_r to musl pkg
2021-09-21 15:01:58 <ikke> hasn't that come up before?
2021-09-21 15:02:14 <Ariadne> why
2021-09-21 15:02:18 <Ariadne> it is the most useless api ever
2021-09-21 15:02:39 <mps> well, yes but a lot of upstream use it
2021-09-21 15:03:27 <mps> better than patch these pkgs one by one
2021-09-21 15:03:49 <mps> and I think it is in musl 'queue' already
2021-09-21 15:04:54 <Ariadne> i think you are mistaken
2021-09-21 15:05:22 <Ariadne> the last time this came up, dalias was pretty clear that he did not want qsort_r in musl
2021-09-21 15:05:43 <mps> https://www.openwall.com/lists/musl/2021/03/09/10
2021-09-21 15:06:06 <ikke> It's a wrapper
2021-09-21 15:06:07 <Ariadne> yes, i see a patch
2021-09-21 15:06:20 <Ariadne> did it actually get accepted?
2021-09-21 15:06:47 <mps> no, it is not but also not explicitly rejected
2021-09-21 15:06:53 <mps> dalias: ^
2021-09-21 15:07:36 <ikke> https://www.openwall.com/lists/musl/2021/08/18/2
2021-09-21 15:07:43 <ikke> here he replied to a similar patch
2021-09-21 15:07:58 <mps> yes, I have it open
2021-09-21 15:08:18 <Ariadne> i am somewhat against adding new symbols to musl
2021-09-21 15:08:23 <Ariadne> without it going upstream
2021-09-21 15:08:46 <Ariadne> maybe if it is in musl git, and can be cherrypicked, we can talk
2021-09-21 15:08:48 <Ariadne> :)
2021-09-21 15:08:58 <mps> not yet in git
2021-09-21 15:09:11 <Ariadne> then, i think we should not
2021-09-21 15:09:46 <mps> ok, I don't insist
2021-09-21 15:10:05 <Ariadne> if you want to get it over the finish line and landed into git
2021-09-21 15:10:11 <Ariadne> then i have no objection to adding it to alpine
2021-09-21 15:10:45 <mps> well, I would not if dalias don't want it
2021-09-21 15:16:32 <dalias> ariadne, not at all. qsort_r is approved
2021-09-21 15:16:44 <Ariadne> ok
2021-09-21 15:16:55 <dalias> it was just just pending because of bad powerpc codegen likely causing performance regression
2021-09-21 15:17:02 <dalias> but i dont think there's anything we really should do about it
2021-09-21 15:17:04 <Ariadne> dalias: do you have any objection to alpine incorporating the current qsort_r patche?
2021-09-21 15:17:07 <dalias> it's gcc's fault and they should fix it
2021-09-21 15:17:55 <dalias> the interface is approved  and as long as the patch matches the interface, it should be fine, even if the patch has implementation issues not yet tackled
2021-09-21 15:18:19 <Ariadne> mps: okay, proceed with an MR using the latest patch
2021-09-21 15:20:39 <dalias> sorry i've just stretched this release cycle out way too long and intended to merge right after it
2021-09-21 15:21:15 <dalias> but i was feeling bleh about a lot of things, and thanks for some lovely inspiration from alpine, i've been putting energy into a side project that's making me feel un-bleh :)
2021-09-21 15:21:31 <dalias> speaking of which, is the alpine issue that inspired it fixed yet? :)
2021-09-21 15:21:45 <Ariadne> which issue are you referencing
2021-09-21 15:21:50 <dalias> the rm -rf *
2021-09-21 15:21:54 <Ariadne> oh
2021-09-21 15:22:02 <Ariadne> uhh
2021-09-21 15:22:04 <dalias> :)
2021-09-21 15:22:08 <Ariadne> i dont think so
2021-09-21 15:22:20 <Ariadne> i can discuss with WilliamH at openrc about it
2021-09-21 15:23:10 <dalias> in case you don't remember, i have no idea how that line was reached without cwd==/tmp
2021-09-21 15:23:13 <dalias> but it was :(
2021-09-21 15:23:22 <Ariadne> which line
2021-09-21 15:23:28 <dalias> the one with the rm -rf *
2021-09-21 15:23:35 <Ariadne> that doesn't tell me anything ;d
2021-09-21 15:23:37 <Ariadne> :D*
2021-09-21 15:23:59 <Ariadne> sorry i have slept since your system got hosed :(
2021-09-21 15:24:25 <dalias> bootmisc
2021-09-21 15:24:54 <dalias> cleanup_tmp_dir func
2021-09-21 15:25:41 <Ariadne> kk
2021-09-21 15:26:02 <dalias> it's called with a variable "$tmp" expanded from a complex shelll variable expansion...
2021-09-21 15:26:34 <dalias> used in a for loop
2021-09-21 15:26:52 <dalias> there are so many ways this could go wrong
2021-09-21 15:27:43 <Ariadne> yeah
2021-09-21 15:40:14 <Ariadne> testing new gcc 10.3.1 snapshot on s390x and x86_64
2021-09-21 15:40:24 <Ariadne> will push in a bit :)
2021-09-21 15:44:54 <maribu> Cogitri: rebuilding main/glib seemed to fix my issue with `flatpak update`, or it was just luck. Can any reproduce the issue and confirm that rebuilding glib fixes it?
2021-09-21 16:19:44 <Cogitri[m]> maribu: Huh, would be odd that that fixes it
2021-09-21 16:32:31 <donoban> ey Cogitri[m] , do you like to gdm switch to openembedded base PAM? I don't know if continue refactoring PAM rules until I have some feedback on it
2021-09-21 16:37:03 <Cogitri[m]> donoban: I have to admit I don’t have a too great understanding of how PAM works (and it’s a pain to debug) so I don’t really mind how we go ahead as long as it works
2021-09-21 16:40:06 <Ariadne> donoban: i think cleaning up the PAM config is fine, feel free to continue
2021-09-21 16:40:48 <donoban> well, at least I'm trying to simplify it, I tested !25178 without any problem
2021-09-21 16:41:44 <donoban> the idea is to do small MR so if there is some problem it should be easy to detect it
2021-09-21 16:42:40 <donoban> if you can take a look and merge it I will try with next one
2021-09-21 16:44:59 <donoban> Ariadne: what do you think about 'others' config? I feel that the safer is to default to pam_deny.so but it needs to create a pam config file for some aports that are currently missing
2021-09-21 17:03:40 <maribu> Cogitri Note that according to GDB flatpak got stuck in the glib main loop waiting for poll() to return. And since under the hood flatpak transferred a couple of files, it would be possible that the update just got stuck between two downloads due to a lost competition event. I still have no explanation as of why this might have happened.
2021-09-21 17:04:30 <donoban> ey maribu what problem are you talking about? it being stuck after finish uploading?
2021-09-21 17:04:35 <donoban> upgrading*
2021-09-21 17:05:12 <bl4ckb0ne> can I have a review for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24589 pls
2021-09-21 17:12:37 <Cogitri[m]> maribu: Hm, yeah might be a suboptimal async implementation but I still don’t see how a rebuild would fix this :D
2021-09-21 17:16:30 <maribu> Cogitri that's the point. Still, I tried like 1000 updates with a script with not a single one succeeding. After the rebuild, both two updates succeed on the first try. It would be good to now if that was just by chance, but the odds are not that high.
2021-09-21 17:48:17 <maribu> OK, I uninstalled a dep an `flatpak update` got stuck again. So it was just by chance.
2021-09-21 17:51:04 <Ariadne> donoban: depends on situation, but pam_deny seems reasonable
2021-09-21 18:31:58 <donoban> something like example given in 'man pam_deny'
2021-09-21 18:32:44 <donoban> Ariadne: could you check the MR and merge if don't see any problem?
2021-09-21 18:35:26 <ikke> hmm, seems like the maintainer is not responding
2021-09-21 18:38:51 <Ariadne> sure, but i will do it after i figure out lunch :p
2021-09-21 18:44:05 <donoban> ok thanks
2021-09-21 18:44:42 <ikke> donoban: btw: commit message are in imperative tense: 'move' instead of 'moved'
2021-09-21 18:45:02 <donoban> ikke: I think Cogitri[m] is agree until it doesn't break anything
2021-09-21 18:45:14 <donoban> ok let me check
2021-09-21 18:45:34 <ikke> in thise case, rename might even be better
2021-09-21 18:45:44 <donoban> what commit do you refer?
2021-09-21 18:45:58 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24589/diffs?commit_id=891cc4cacc2196042fc592e10f6b3bc083e8010c
2021-09-21 18:46:12 <ikke> oh, may be a different MR
2021-09-21 18:46:14 <donoban> ah it's not mine
2021-09-21 18:46:27 <ikke> that was bl4ckb0ne, sorry
2021-09-21 18:46:35 <donoban> hehe np
2021-09-21 18:57:36 <bl4ckb0ne> ikke: reworded the commit
2021-09-21 18:57:56 <ikke> bl4ckb0ne: 👍
2021-09-21 18:59:07 <ikke> is there a reason you removed the secfixes comment?
2021-09-21 18:59:57 <bl4ckb0ne> though it was outdated, i can put it back
2021-09-21 19:00:14 <ikke> In general, we just keep secfix comments
2021-09-21 19:00:19 <bl4ckb0ne> ill put it back
2021-09-21 19:00:27 <ikke> some scanners just rely on what's in our secfix db, which relies on these comments
2021-09-21 19:00:48 <bl4ckb0ne> ack
2021-09-21 19:01:00 <bl4ckb0ne> should I add myself as contributor since we got no news from the maintainer?
2021-09-21 19:03:38 <ikke> You can if you wish, though, in practice it does not mean a lot. You could try to adopt the package (become the maintainer yourself)
2021-09-21 19:04:35 <ikke> That could be done by sending an e-mail to the maintainer asking if you can take over the maintainership of the package and cc-ing ~alpine/devel@lists.alpinelinux.org
2021-09-21 19:04:57 <ikke> If they don't respond in a reasonable time, then you can just take it over
2021-09-21 19:05:20 <bl4ckb0ne> sure
2021-09-21 19:07:35 <ikke> But that would be separate from this MR
2021-09-21 19:08:10 <bl4ckb0ne> i pushed back the CVE comment
2021-09-21 19:10:41 <ikke> ah, nox is no X?
2021-09-21 19:11:52 <bl4ckb0ne> well, webui
2021-09-21 19:12:25 <bl4ckb0ne> thats how qbittorrent calls it
2021-09-21 19:27:30 <ikke> bl4ckb0ne: oh, jan is now responding
2021-09-21 19:28:13 <bl4ckb0ne> aye, saw that
2021-09-21 19:31:39 <ikke> bl4ckb0ne: sorry for the step-by-step review, I'm kind of doing this in between
2021-09-21 19:31:54 <bl4ckb0ne> dont worry, im doing exactly the same thing on my side
2021-09-21 19:51:28 <bl4ckb0ne> are doc subpackages for subpackages automatically done or should I make a func that calls default_doc
2021-09-21 19:52:21 <ikke> in a similar fashion to the openrc package, you just have to define the proper split function
2021-09-21 19:52:50 <ikke> $pkgname-nox-doc:doc
2021-09-21 19:53:01 <ikke> s/define/declare
2021-09-21 19:54:19 <ikke> Hmm, in this case it's different
2021-09-21 19:54:33 <ikke> Or, at least, depends on if there are other files that should be part of a different subpackage
2021-09-21 19:56:40 <ikke> Something like this could work: https://tpaste.us/8Erk 
2021-09-21 19:58:35 <bl4ckb0ne> thanks!
2021-09-21 19:58:47 <bl4ckb0ne> i was figuring out why the manpage was not copied
2021-09-21 19:59:08 <ikke> for subpackages, you need to move it from $pkgdir to $subpkgdir
2021-09-21 19:59:15 <ikke> amove is a helper that does that
2021-09-21 19:59:28 <bl4ckb0ne> i saw that when grepping other packages
2021-09-21 20:02:56 <ikke> oh, I just noticed that you are installing directly into subpkgdir
2021-09-21 20:03:01 <bl4ckb0ne> yeah
2021-09-21 20:03:05 <ikke> (which is not wrong, fyi)
2021-09-21 20:03:33 <bl4ckb0ne> should it be $pkgdir-nox?
2021-09-21 20:04:01 <ikke> bl4ckb0ne: that standard flow is: install everything in $pkgdir, then the split functions 'take' what they need
2021-09-21 20:04:38 <ikke> all the default_* functions assume that the files live in $pgkdir
2021-09-21 20:05:02 <bl4ckb0ne> even with 2 build folders?
2021-09-21 20:06:31 <ikke> If you install it in the subpkgdir, then you have to do all the file move operations yourself
2021-09-21 20:06:35 <ikke> for openrc, for doc
2021-09-21 20:11:20 <bl4ckb0ne> i see
2021-09-21 20:15:07 <bl4ckb0ne> so i should have only one build folder and make the split package pick the nox bin
2021-09-21 20:15:32 <ikke> If it's easy enough find the nox files
2021-09-21 20:15:59 <ikke> if it's a lot of work, I'd just do it like you did
2021-09-21 20:16:24 <ikke> and then in the split functions, first move from the parent subpackage to the subpackage, and then call the default functions
2021-09-21 20:17:10 <bl4ckb0ne> is there a package that does something like this?
2021-09-21 20:17:42 <ikke> not aware of any
2021-09-21 20:24:58 <bl4ckb0ne> seems like nox is only 2 files
2021-09-21 20:30:19 <bl4ckb0ne> hm enabling gui and webui builds only one file
2021-09-21 20:39:42 <bl4ckb0ne> i dont get the "move from the parent subpackage to the subpackage step"
2021-09-21 20:41:49 <ikke> for the doc subpackage
2021-09-21 20:42:14 <ikke> I assume the man page is installed in the subpkdir for nox?
2021-09-21 21:29:31 <ArMor[m]> Hey, I'm trying to understand how apk works
2021-09-21 21:30:25 <ArMor[m]> 1- how does it find a package when installing something?
2021-09-21 21:31:04 <ArMor[m]> I think it refreshes APKINDEX files first? then reads them? then it knows which packages exist
2021-09-21 21:31:24 <ArMor[m]> how does it know which APKINDEX file belongs to which mirror?
2021-09-21 21:31:41 <ArMor[m]> I mean for example I want to install 'python3-dev'
2021-09-21 21:32:30 <ArMor[m]> how does it know if the package exists? then if so how does it generate the http link for packages?
2021-09-21 21:33:05 <ArMor[m]> I want to create a tool for generating download links for apk files
2021-09-21 21:39:20 <danieli> it's in the apkindex, and the apkindexes are signed by keys that only the alpine core devs(?) have
2021-09-21 22:19:00 <Ariadne> danieli: only the builder maintainer has
2021-09-21 22:57:07 <Ariadne> libmnl is such a pleasant library compared to using netlink directly
2021-09-22 06:01:58 <mps> good morning
2021-09-22 06:04:20 <mps> dalias: do you intendto merge this one qsort_r patch to next musl https://www.openwall.com/lists/musl/2021/08/18/1
2021-09-22 06:04:39 <mps> s/intendto/intend to/
2021-09-22 06:08:59 <smcavoy> Hi there, I created !25638 and !25443 for updates to ansible. The update ansible package is in community/ but the new depenency ansible-core is in testing/ not sure how situations are dealt with..
2021-09-22 06:19:30 <ericonr> mps: https://www.openwall.com/lists/musl/2021/03/09/10
2021-09-22 06:22:21 <mps> ericonr: aha, this one. thanks
2021-09-22 06:56:42 <mps> who told that Xorg is dead!? ;) https://lists.x.org/archives/xorg/2021-September/060773.html
2021-09-22 06:57:10 <mps> (modern people :D)
2021-09-22 07:08:45 <ArMor[m]> <ArMor[m]> "I want to create a tool for..." <- Anyone has any ideas about this? 
2021-09-22 07:11:35 <mps> ArMor[m]: apk doesn't work in 'this way' afaik
2021-09-22 07:12:19 <mps> but 'use source, Luke'
2021-09-22 07:13:55 <ikke> It's just conjecture, but the indices fetched from http(s) have some kind of checksum in the name in the cached apkindex files
2021-09-22 07:14:07 <ikke> so maybe it can map that back to the repository in /etc/apk/repositories
2021-09-22 07:14:17 <ikke> For local repositories, it does not cache them
2021-09-22 07:25:56 <Misthios> mps atleast it helps nvidia users
2021-09-22 07:26:25 <ikke> ArMor[m]: an apkindex itself is not tied to a url
2021-09-22 07:26:38 <ikke> so if all you have is an index, you don't know where the packages are, unless it's local
2021-09-22 07:27:30 <mps> Misthios: nvidia users are 'poor' people
2021-09-22 07:27:51 <Misthios> no wonder after a 1k+ gpu :)
2021-09-22 07:28:25 <mps> 'f*ck you, Nvidia!' - Linus Torvalds ;)
2021-09-22 07:28:39 <Misthios> :)
2021-09-22 07:29:02 <sircmpwn> daily builds of alpine edge started to fail with apk segfaults from 2021-09-12 onwards
2021-09-22 07:29:22 <sircmpwn> on apk add -U -X http://dl-cdn.alpinelinux.org/alpine/edge/main/ -X http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted '--arch=x86_64' '--root=/mnt' --initdb acct alpine-base alpine-conf alpine-sdk linux-lts git mercurial openssh sudo syslinux tzdata gnupg haveged bash
2021-09-22 07:30:12 <sircmpwn> related to the openssl rebuild? cc Ariadne via 6c65a526f66f05158d0bef1ed385d0df1bf572d0
2021-09-22 07:36:24 <ikke> curl patch release today which fixes a couple of bugs
2021-09-22 07:47:32 <ikke> Any idea where it's segfaulting?
2021-09-22 07:47:37 <ikke> ddevault: ^
2021-09-22 07:47:58 <ikke> I figured you got your preferred name back?
2021-09-22 07:48:32 <ddevault> yeah, I must have d/c'd and my bouncer picked up the old one
2021-09-22 07:48:46 <ikke> ah
2021-09-22 07:48:51 <ddevault> I did some minimal investigation but getting debug symbols going was a pain
2021-09-22 07:48:53 <ddevault> I have a core dump
2021-09-22 07:49:34 <ddevault> https://l.sr.ht/iRrV.core
2021-09-22 07:49:45 <ddevault> the crash environment is trivially reproducible for anyone with a sr.ht account and a desire to investigate
2021-09-22 08:30:27 <Ariadne> morning
2021-09-22 08:30:35 <Ariadne> will check it
2021-09-22 08:31:26 <Ariadne> ddevault: which arch?  x86-64?
2021-09-22 08:32:01 <ddevault> yes
2021-09-22 08:44:26 <Ariadne> alright
2021-09-22 08:45:33 <Ariadne> it crashes on aarch64, too
2021-09-22 08:52:07 <Ariadne> #1  0x0000fffff7b744b8 in apk_sign_ctx_mpart_cb (ctx=0xffffffffe5e8, part=1, data=...) at src/package.c:764
2021-09-22 08:52:07 <Ariadne> #0  0x0000000000000000 in ?? ()
2021-09-22 08:52:07 <Ariadne> (gdb) bt
2021-09-22 08:52:10 <Ariadne> interesting
2021-09-22 09:16:31 <Ariadne> very strange
2021-09-22 09:16:59 <Ariadne> i don't understand it, the code is using EVP api correctly
2021-09-22 09:17:28 <ddevault> has the object perhaps entered an invalid state?
2021-09-22 09:17:33 <ddevault> use-after-free or something
2021-09-22 09:21:12 <Ariadne> could be
2021-09-22 09:22:11 <Ariadne> let me valgrind it
2021-09-22 09:22:23 <Ariadne> worst case we can take apk-tools back to 1.1 if i can't figure it out from that
2021-09-22 09:22:50 <ddevault> quite bizzare that it ends up with rip set to 0
2021-09-22 09:22:57 <ddevault> I wonder if it's a tail call
2021-09-22 09:23:18 <Ariadne> well, its EVP_DigestUpdate() which presumably calls a function pointer
2021-09-22 09:23:27 <ddevault> ah yeah that is general
2021-09-22 09:26:03 <Ariadne> valgrind not too helpful
2021-09-22 09:26:30 <Ariadne> i'm just going to take it back to 1.1 for now
2021-09-22 09:27:27 <ddevault> do you know what branch of apk_sign_ctx_init ran
2021-09-22 09:27:32 <ddevault> I wonder if this is an issue with EVP_md_null
2021-09-22 09:27:43 <Ariadne> yes
2021-09-22 09:28:23 <Ariadne> in apk_sign_ctx_mpart_cb, it immediately jumps to update_digest
2021-09-22 09:28:47 <ddevault> that doesn't actually answer the question
2021-09-22 09:28:56 <Ariadne> oh
2021-09-22 09:29:00 <Ariadne> sorry i misread
2021-09-22 09:29:03 <ddevault> np
2021-09-22 09:29:20 <Ariadne> yes, its called with APK_SIGN_VERIFY, so we wind up with EVP_md_null
2021-09-22 09:31:02 <ikke> Ariadne: would be nice if the commit message at least provided the reasoning
2021-09-22 09:31:25 <Ariadne> git push --force is not allowed :p
2021-09-22 09:31:34 <ikke> yup
2021-09-22 09:32:08 <Ariadne> ddevault: for now, -r2 switches it back to openssl 1.1, i'll try to fix this and get fabled to cut a 2.12.8
2021-09-22 09:33:14 <ddevault> aight
2021-09-22 09:33:18 <Ariadne> very strange, i've been dogfooding apk on openssl 3 since july
2021-09-22 09:33:25 <Ariadne> and i do `abuild rootbld` all the time
2021-09-22 09:33:36 <Ariadne> so, not sure why this doesn't happen there
2021-09-22 09:34:11 <Ariadne> one thought might be that legacy module is related somehow
2021-09-22 09:34:24 <Ariadne> but strace does not show any attempt to load it
2021-09-22 09:39:56 <Ariadne> going to eat breakfast prior to debugging this further
2021-09-22 09:40:45 <ddevault> thanks for looking into it
2021-09-22 09:56:40 <Ariadne> hmm
2021-09-22 09:56:47 <Ariadne> i think i figured something out
2021-09-22 09:57:14 <Ariadne> when i use rootbld it uses https://
2021-09-22 09:57:30 <Ariadne> maybe something isn’t being loaded that gets loaded as a side effect of using https
2021-09-22 09:57:55 <ikke> uses or doesn't use?
2021-09-22 09:58:05 <Ariadne> it uses https
2021-09-22 09:58:09 <Ariadne> on my setup
2021-09-22 09:59:30 <Ariadne> starlink does transparent caching, so i was using https to bypass that cache
2021-09-22 10:00:24 <Ariadne> no longer need it but still use it :)
2021-09-22 10:00:27 <ikke> So it does not happen with https, but does with http?
2021-09-22 10:01:35 <Ariadne> i think so.  not at computer right now, but it was a thought i had a minute ago
2021-09-22 10:01:38 <Ariadne> :)
2021-09-22 10:33:47 <ArMor[m]> Are there any alternative implementations for apk?
2021-09-22 10:36:26 <Ariadne> not that i’m aware of
2021-09-22 10:39:20 <ikke> Ariadne: do you happen to know how apk associates an index with the correct repository?
2021-09-22 10:57:18 <Ariadne> i do not :)
2021-09-22 10:57:28 <ikke> ok
2021-09-22 10:57:44 <ikke> I suspect it has to do with the short hashes in the cached index filenames
2021-09-22 10:59:11 <Ariadne> yes
2021-09-22 10:59:24 <Ariadne> that sounds right
2021-09-22 13:07:13 <Biswa96> I want to revive a package from unmaintained section. How can I do that? i.e. What changes do I need to do in aports repo?
2021-09-22 13:07:54 <durrendal> Quick question, I'm looking to find a way to package freedict, but I'm not certain what the best way to handle the dictionaries would be, there's about 170. Should I just add 170 subpackages and then a meta package for everything as well?
2021-09-22 13:10:02 <ikke> Biswa96: Make sure it still builds, then it's just a matter of moving it from unmaintained perhaps first to testing again
2021-09-22 13:13:34 <Biswa96> ikke: How/When should I add another package which is required to revive that unmaintained one? In that same PR or before/after?
2021-09-22 13:13:50 <ikke> In the same MR
2021-09-22 13:16:59 <Biswa96> <3
2021-09-22 13:28:39 <mkaesberger> Ariadne: I've observed the segfault with --allow-untrusted but did not have time to reproduce it. adding the key solved the problem
2021-09-22 15:31:12 <kpcyrd> hm, how would I go about backporting something to alpine 3.14? letsencrypt changed their api response which broke one of the packages I maintain.
2021-09-22 15:32:26 <dalias> hopefully the fix is a simple patch
2021-09-22 15:33:00 <ikke> kpcyrd: backporting means making merge requests against 3.14-stable
2021-09-22 15:48:04 <kpcyrd> ikke: can I just import a new patch release or should I create a patch that applies to the old version?
2021-09-22 15:48:15 <ikke> kpcyrd: new patch releases are fine
2021-09-22 15:48:36 <kpcyrd> ok cool, thanks for the pointers :)
2021-09-22 15:48:44 <ikke> np
2021-09-22 15:53:39 <dalias> i'm not objecting to what kpcyrd will do here, but i think the policy should be requiring the patch not the new patch release
2021-09-22 15:54:11 <dalias> so that the changes are visible and visibly nothing-but-the-bugfix in the aports repo, without having to get multiple upstream versions and diff them to see that
2021-09-22 16:40:37 <mps> dalias: I agree, but I'm tired of repeating such things
2021-09-22 16:42:52 <mps> I asked few times for one of previous haproxy security backports and did backport as there were no other solutions. and I could do this backport quietly and think no one will notice
2021-09-22 16:43:44 <mps> this morning I thought to declare myself as supreme TSC and council :D
2021-09-22 17:06:20 <Misthios> Lol
2021-09-22 17:07:46 <maxice8> lol
2021-09-22 17:09:51 <Ariadne> mkaesberger: fascinating
2021-09-22 17:10:14 <Ariadne> mkaesberger: so its the --allow-untrusted that causes the problem, and presumably, `rootbld` works because it copies the trust store
2021-09-22 17:11:52 <Ariadne> this does make sense, i think
2021-09-22 17:15:26 <Ariadne> (or rather, the problem is lack of key in trust store)
2021-09-22 17:15:41 <Ariadne> which means the EVP object *is* bogus
2021-09-22 17:15:47 <Ariadne> okay
2021-09-22 17:16:34 <Ariadne> hmm
2021-09-22 17:16:37 <Ariadne> there's more to it
2021-09-22 17:16:46 <Ariadne> i moved /etc/apk/keys to somewhere else
2021-09-22 17:17:31 <Ariadne> wait, wrong apk :)
2021-09-22 17:23:23 <kpcyrd> question for a different package: is there a way to ship a file that belongs to a specific group that's created by a .pre-install hook? So that a user needs to belong to this group to access the config file
2021-09-22 17:26:01 <Ariadne> what the fuck?
2021-09-22 17:26:12 <Ariadne> mkaesberger: i disabled using ENGINE api and now it is not crashing
2021-09-22 17:27:01 <ikke> kpcyrd: you can define users / groups in pkgusers / pkgroups, which means they're available during build
2021-09-22 17:27:02 <mkaesberger> I tried to reproduce it on a different machine but I can't trigger the bug...
2021-09-22 17:27:06 <Ariadne> going to verify that fixes it, but i have no explanation why that fixes it
2021-09-22 17:27:12 <ikke> kpcyrd: you can then chown files to that user / group
2021-09-22 17:27:17 <Ariadne> and that does not satisfy me
2021-09-22 17:28:35 <Ariadne> okay
2021-09-22 17:28:40 <Ariadne> ENGINE APIs enabled, it crashes
2021-09-22 17:30:06 <Ariadne> hmm
2021-09-22 17:30:08 <Ariadne> or not
2021-09-22 17:30:57 <Ariadne> ddevault: its related to EVP_md_null, after all
2021-09-22 17:32:04 <Ariadne> but that is a strange regression
2021-09-22 17:50:38 <kpcyrd> ikke: got it, thanks!
2021-09-22 17:52:06 <bl4ckb0ne> is there some rules regarding packaging directly from git?
2021-09-22 17:52:20 <bl4ckb0ne> found some software that requires submodules
2021-09-22 17:52:22 <Ariadne> figured it out
2021-09-22 17:52:33 <Ariadne> this is an incredibly stupid openssl regression
2021-09-22 17:53:54 <dalias> bl4ckb0ne, don't you have to archive a tarball of specific versions so that it's reproducible rather than the builder pulling from git?
2021-09-22 17:54:07 <bl4ckb0ne> i do, but the released tarball doesnt contain the submodules
2021-09-22 17:54:14 <bl4ckb0ne> yeah its dumb
2021-09-22 17:54:22 <dalias> well the submodule tarballs need to be archived too
2021-09-22 17:54:32 <bl4ckb0ne> even the build script fails because it fails to call `git submodule`
2021-09-22 17:55:01 <dalias> make a temp dir with a "git" shell script that does nothing and add that to the path :)
2021-09-22 17:55:14 <ikke> :D
2021-09-22 17:55:23 <ikke> or patch out the git submodule call
2021-09-22 17:55:31 <dalias> that works too i guess
2021-09-22 17:57:27 <Ariadne> god, i hate openssl
2021-09-22 17:57:33 <bl4ckb0ne> hm could I run a dummy git init and fetch the submodules
2021-09-22 17:57:45 <dalias> ?
2021-09-22 17:57:50 <Ariadne> anyway, EVP_md_null, it never sets up the legacy ->update pointer
2021-09-22 17:58:02 <Ariadne> amazing, utterly amazing
2021-09-22 17:58:13 <dalias> build process it not allowed (or shouldn't be allowed) to fetch random third party resources that might change or disappear
2021-09-22 17:58:45 <ikke> yeah, submodules should be dowloaded as source archives, just like the main project
2021-09-22 17:58:49 <Ariadne> it shouldn't be allowed, but the buildservers presently allow it for reasons ;/
2021-09-22 17:58:53 <dalias> :(
2021-09-22 17:59:17 <dalias> what ikke said. even if there's not an enforced policy against doing it wrong now, don't add more stuff doing it wrong
2021-09-22 17:59:22 <dalias> it will make it harder to fix
2021-09-22 17:59:33 <ikke> dalias: the policy is enforced through code review
2021-09-22 17:59:40 <ikke> 'enforced'
2021-09-22 17:59:41 <dalias> ultimately builders should run with no network access :)
2021-09-22 17:59:50 <Ariadne> yes, you don't say
2021-09-22 17:59:51 <ikke> (after fetching sources)
2021-09-22 18:00:02 <dalias> right
2021-09-22 18:00:06 <Ariadne> okay
2021-09-22 18:00:15 <ikke> abuild rootbld does this
2021-09-22 18:00:22 <Ariadne> hm
2021-09-22 18:00:26 <bl4ckb0ne> can abuild handle "extract X there" ?
2021-09-22 18:00:32 <Ariadne> i wonder why ->update never gets set on the MD_CTX
2021-09-22 18:00:53 <ikke> but at least when I tested it, it seemed that rootbld in lxc required extra privileges
2021-09-22 18:00:59 <ikke> but now it does not seem to require it anymore
2021-09-22 18:01:41 <ikke> bl4ckb0ne: in prepare(), you can move the submodule directories to the correct locations
2021-09-22 18:02:15 <ikke> mv "$srcdir"/dirfoo "$builddir"
2021-09-22 18:02:38 <bl4ckb0ne> neat, 26 modules to handle
2021-09-22 18:02:45 <ikke> oof
2021-09-22 18:02:57 <Ariadne> its like they just forgot about MD_null
2021-09-22 18:02:58 <Ariadne> :(
2021-09-22 18:03:23 <ikke> bl4ckb0ne: at some point we could conclude these projects are not really suited to be packaged
2021-09-22 18:03:32 <bl4ckb0ne> i would like to thansk M$ for being such a dumbass company
2021-09-22 18:03:48 <bl4ckb0ne> would make my life much more simpler
2021-09-22 18:04:02 <psykose> why don't they just make the source version tarball include the submodules
2021-09-22 18:04:15 <ikke> "why don't they just"
2021-09-22 18:04:15 <bl4ckb0ne> probably because it's M$
2021-09-22 18:04:45 <Ariadne>     /* Update function: usually copied from EVP_MD */
2021-09-22 18:04:45 <Ariadne>     int (*update) (EVP_MD_CTX *ctx, const void *data, size_t count);
2021-09-22 18:04:48 <Ariadne> but where
2021-09-22 18:04:53 <Ariadne> i don't actually *see* code doing it
2021-09-22 18:05:26 <Ariadne> did they just forget to actually write it :|
2021-09-22 18:08:00 <dalias> :-p
2021-09-22 18:08:43 <ikke> Maybe after 3.15 we could look at enabling rootbld in the builders
2021-09-22 18:09:15 <mps> 
ACTION has moto: don't package every crap on net

2021-09-22 18:09:43 <ikke> One challenge I see is that we cannot use rootbld in CI, and there it's not really necessary, but we _do_ want to disable networking after the sources are fetched
2021-09-22 18:10:23 <mps> dalias: would you mind to look !25642
2021-09-22 18:10:29 <dalias> unshare -n
2021-09-22 18:10:30 <dalias> done
2021-09-22 18:10:36 <mps> Ariadne: also 
2021-09-22 18:10:41 <Ariadne> so, we call EVP_DigestInit
2021-09-22 18:10:45 <mps> and ikke ofc
2021-09-22 18:10:56 <Ariadne> give me a minute
2021-09-22 18:11:00 <Ariadne> i'm in a mount of shit
2021-09-22 18:11:03 <Ariadne> mountain*
2021-09-22 18:11:06 <mps> Ariadne: no hurries 
2021-09-22 18:11:09 <Ariadne> aka openssl codebase
2021-09-22 18:11:29 <mps> yes, I see what a mess is it
2021-09-22 18:12:04 <Ariadne> okay, so EVP_DigestInit_ex is supposed to handle this I think
2021-09-22 18:13:39 <Ariadne> https://github.com/openssl/openssl/blob/master/crypto/evp/digest.c#L352-L355
2021-09-22 18:13:46 <Ariadne> --> evp_md_init_internal
2021-09-22 18:14:01 <Ariadne> https://github.com/openssl/openssl/blob/master/crypto/evp/digest.c#L127
2021-09-22 18:14:38 <dalias> mps, did you see my comment to the latest thread about _GNU_SOURCE?
2021-09-22 18:15:00 <dalias> the declaration in stdlib.h should be visible under _BSD_SOURCE not just _GNU_SOURCE
2021-09-22 18:15:00 <Ariadne> https://github.com/openssl/openssl/blob/master/crypto/evp/digest.c#L306
2021-09-22 18:15:08 <Ariadne> https://github.com/openssl/openssl/blob/master/crypto/evp/digest.c#L313
2021-09-22 18:15:31 <dalias> i dont care if you do that now or not, but some stuff might build better with it
2021-09-22 18:15:37 <Ariadne> ctx->digest is NULL, which would not match &md_null
2021-09-22 18:15:40 <dalias> and i'll have that change when taking it upstream
2021-09-22 18:16:08 <Ariadne> https://github.com/openssl/openssl/blob/master/crypto/evp/digest.c#L313
2021-09-22 18:16:45 <Ariadne> ctx->flags == 0, type->ctx_size == 8
2021-09-22 18:18:04 <Ariadne> line 306 is never reached
2021-09-22 18:20:19 <Ariadne> so they did write code to handle ->update
2021-09-22 18:20:23 <Ariadne> but with evp_md_null
2021-09-22 18:20:25 <Ariadne> never gets reached
2021-09-22 18:20:31 <Ariadne> time to stepi through it i guess
2021-09-22 18:21:00 <mps> dalias: probably I saw it but tbh I can't remember it now
2021-09-22 18:21:53 <mps> looking archive now
2021-09-22 18:24:59 <Ariadne> okay
2021-09-22 18:25:01 <Ariadne> figured it out
2021-09-22 18:25:06 <Ariadne> EVP_md_null needs EVP_MD_CTX_FLAG_NO_INIT
2021-09-22 18:30:49 <mps> found it https://www.openwall.com/lists/musl/2021/08/18/2
2021-09-22 18:30:55 <mps> ericonr: ^
2021-09-22 18:38:47 <Ariadne> sweet
2021-09-22 18:38:49 <Ariadne> have a reproducer
2021-09-22 18:39:33 <ikke> nice
2021-09-22 18:53:36 <Ariadne> https://github.com/openssl/openssl/issues/16660
2021-09-22 19:03:21 <Ariadne> one workaround would be to set EVP_MD_CTX_FLAG_NO_INIT on the md_null CTX
2021-09-22 19:03:27 <Ariadne> but, we really shouldn't have to do that.
2021-09-22 19:03:57 <Ariadne> oh wait, but there's more
2021-09-22 19:04:07 <Ariadne> it turns out
2021-09-22 19:04:08 <Ariadne>         EVP_MD_CTX_set_flags(mdctx, EVP_MD_CTX_FLAG_NO_INIT);
2021-09-22 19:04:16 <Ariadne> just makes it crash some other way
2021-09-22 19:04:40 <ikke> The gift that keeps on giving
2021-09-22 19:05:47 <Ariadne> in this case,
2021-09-22 19:05:50 <Ariadne> you wind up with
2021-09-22 19:05:56 <Ariadne> ctx->digest == ctx->reqdigest,
2021-09-22 19:06:02 <Ariadne> but ctx->update remains NULL
2021-09-22 19:24:49 <Ariadne> i feel like being an openssl maintainer has to be a trip
2021-09-22 19:25:04 <Ariadne> the overwhelming majority of openssl users probably actively dislike openssl
2021-09-22 19:25:24 <Ariadne> but not enough to rewrite their code to use another TLS library
2021-09-22 19:26:15 <dalias> :)
2021-09-22 19:51:09 <Hello71> 18:10 <dalias> unshare -n
2021-09-22 19:51:11 <Hello71> 18:10 <dalias> done
2021-09-22 19:51:15 <Hello71> while you're at it can you get rid of fakeroot
2021-09-22 19:53:39 <dalias> :)
2021-09-22 19:53:45 <dalias> unshare -r
2021-09-22 19:53:51 <dalias> now i'm root :)
2021-09-22 19:54:10 <dalias> however chown & stuff will still fail
2021-09-22 19:54:26 <dalias> i'd really like to see an analysis of what fakeroot is really used for
2021-09-22 19:56:15 <Ariadne> `make install DESTDIR=whatever` stuff that requires "root" for whatever reason
2021-09-22 19:58:44 <dalias> yeah i mean what it needs root for
2021-09-22 19:59:12 <ikke> chown?
2021-09-22 19:59:33 <dalias> i think most of it could be fixed with putting symlinks to true called "chown" and "chmod" in the PATH
2021-09-22 19:59:44 <dalias> erm just chown
2021-09-22 19:59:58 <ikke> but then files will not be owned by expected users
2021-09-22 19:59:58 <dalias> i guess maybe chmod should be wrapped to prevent +s too
2021-09-22 20:00:18 <dalias> well if a package has files owned by non-default users, that should probably be declared
2021-09-22 20:00:36 <ikke> it is declared by pkgusers / pkggroups
2021-09-22 20:00:36 <dalias> rather than just letting make install do its thing
2021-09-22 20:06:17 <Ariadne> my conclusion
2021-09-22 20:06:19 <Ariadne> is that
2021-09-22 20:06:24 <Ariadne> i will let openssl figure this out
2021-09-22 20:06:36 <Ariadne> this is some of the worst code ive ever worked with
2021-09-22 20:20:15 <ddevault> Ariadne: did you figure it out?
2021-09-22 20:20:40 <ddevault> yes
2021-09-22 20:20:42 <ddevault> good work
2021-09-22 20:22:08 <Ariadne> unfortunately i’m not confident in coming up with a fix locally
2021-09-22 20:22:20 <Ariadne> as there’s multiple concerns tangled together
2021-09-22 20:22:37 <Ariadne> typical openssl crap :)
2021-09-22 20:45:12 <kunkku> openssl is a mine field
2021-09-22 20:47:02 <Ariadne> we should really try to get it out of the base system, unfortunately there are people who require fips or whatever certifications
2021-09-22 20:49:46 <mps> why people don't use kernel ciphers
2021-09-22 20:50:20 <Ariadne> well people should use ktls
2021-09-22 20:50:35 <Ariadne> you can offload TLS to the NIC
2021-09-22 20:51:20 <mps> how much NICs have crypto engine
2021-09-22 20:51:44 <kunkku> well you can write an openssl engine for that :)
2021-09-22 20:51:54 <mps> hehe
2021-09-22 20:52:48 <dalias> mps, because that's not a good way to write your software. it only works on linux with kernel ciphers built
2021-09-22 20:53:47 <skarnet> that's true of a lot of mutant Linux features
2021-09-22 20:53:57 <mps> yes, I know reason but anyway
2021-09-22 20:54:04 <skarnet> which is why I don't like them: they fragment the software base
2021-09-22 20:54:13 <bl4ckb0ne> packaging drama voided, works fine with a local install
2021-09-22 20:54:20 <bl4ckb0ne> 
ACTION discards his shitty APKBUILD

2021-09-22 20:56:41 <Ariadne> mps: most of the modern mellanox 10/40/100g and intel 10/40g ones do
2021-09-22 20:57:07 <Ariadne> linux will offload the TLS to them if you use ktls
2021-09-22 20:57:34 <xordspar0> mps, re backports: "declare myself as supreme TSC" Or just write the docs at docs.a.o. :) The Dev Handbook is still blank. Whoever writes it first gets to make the rules.
2021-09-22 20:58:23 <Ariadne> the docs team is awaiting clarification from TSC on a number of issues
2021-09-22 21:00:04 <dalias> offloading TLS is a security tradeoff and only makes sense if you're dealing with extreme traffic
2021-09-22 21:00:14 <Ariadne> yes
2021-09-22 21:00:25 <Ariadne> i was not seriously suggesting it for every application :p
2021-09-22 21:00:46 <xordspar0> Nice, I look forward to it. I will help write some docs when we're ready.
2021-09-22 21:01:21 <mps> xordspar0: after thinking a little I think it will be better to declare myself new BDFL becuase this 'seat' is now empty :D
2021-09-22 21:01:49 <skarnet> more accurately, it only makes sense if your workload is cpu-bound
2021-09-22 21:02:07 <Ariadne> or if you’re netflix
2021-09-22 21:02:27 <mps> modern cpus have good crypto hardware, but should I trust them
2021-09-22 21:02:57 <Ariadne> if cpuinfo says GenuineIntel run like hell
2021-09-22 21:03:21 <skarnet> "netflix" has different types of computers and provisioning their resources is certainly a delicate balancing act
2021-09-22 21:04:11 <mps> if I want secure box I would create one based on 6502 cpu
2021-09-22 21:04:12 <skarnet> keeping the network load as close as possible to the cpu load so there's no single one limiting factor is one of those jobs
2021-09-22 21:04:48 <skarnet> if your cpu and io load are both at 100% then you can switch to ktls and your limiting factor is now the network, which is cool
2021-09-22 21:04:59 <Ariadne> mps: LUnix for C64 is a thing
2021-09-22 21:05:15 <mps> really, didn't know for this
2021-09-22 21:05:54 <Ariadne> http://www.lunix.c64.org
2021-09-22 21:08:13 <mps> if I have time and incentive maybe I would write one if forth
2021-09-22 21:08:48 <mps> in forth*
2021-09-22 21:09:23 <Ariadne> i have to say it’s pretty amazing that openssl screwed up evp_md_null
2021-09-22 21:18:38 <dalias> why does md_null even exist ???
2021-09-22 21:33:22 <Hello71> dalias: for implementing ipsec, duh
2021-09-22 21:33:45 <dalias> huh
2021-09-22 21:33:55 <psykose> lol
2021-09-22 21:45:47 <timlegge> can't remember - is there a preferred paste site?
2021-09-22 21:46:25 <mps> timlegge: tpaste.us
2021-09-22 21:46:35 <mps> apk add tpaste
2021-09-22 21:47:22 <mps> and run tpaste < filename, or 'whatever' | tpaste
2021-09-22 21:47:24 <Ariadne> dalias: so you can just no-op the digest calculation instead of having to write two routines
2021-09-22 21:48:22 <timlegge> https://tpaste.us/XKRE is something wrong in perl-test-simple should it include replaces=perl-test-tester?
2021-09-22 21:49:58 <mps> perl-test-simple should provide perl-test-tester
2021-09-22 21:50:50 <timlegge> just updateing my VM maybe I am behind
2021-09-22 21:56:01 <timlegge> I was but thats not it...
2021-09-22 22:11:40 <timlegge> I guess the simplest thing to do is change any package listing perl-test-tester and use perl-test-simple instead - APK reference doc says it won't automatically install a virtual package
2021-09-22 22:15:35 <mps> https://tpaste.us/Lmn6
2021-09-22 22:15:42 <mps> timlegge: ^
2021-09-22 22:16:27 <timlegge> abuild does not seem to do that though
2021-09-22 22:24:56 <ericonr> Ariadne: most crypto software maintainers must have a wild time. Imagine maintaining GnuTLS or GnuPG too :D
2021-09-22 22:28:40 <timlegge> sorted... not sure why I was having issues
2021-09-23 05:20:18 <bratkartoffel> the openjdk17 aport is ready to be merged and tested, can someone please merge it? !23724
2021-09-23 05:44:03 <mps> bratkartoffel: merged
2021-09-23 06:01:30 <ncopa> good morning
2021-09-23 06:01:51 <ncopa> I get this error nowdays: ERROR: binutils-2.37-r1: trying to overwrite usr/lib/bfd-plugins/libdep.so owned by mingw-w64-binutils-2.37-r0.
2021-09-23 06:09:07 <caskd> cross compilation toolchains
2021-09-23 06:09:13 <caskd> aren't they beautiful
2021-09-23 06:54:51 <bratkartoffel> thanks mps
2021-09-23 07:29:32 <mps> bratkartoffel: you are welcome, and thank you for care of such complicated pkg
2021-09-23 07:49:34 <bratkartoffel> it got much easier as oracle integrated the portola patches
2021-09-23 10:18:30 <mps> /usr/lib/xorg/modules/dri > du -sh => 630.7M
2021-09-23 10:19:00 <mps> small, simple .... :D
2021-09-23 10:20:20 <ikke> mesa-dri-gallium
2021-09-23 10:20:37 <mps> yes
2021-09-23 10:21:12 <mps> I remember that I was against making 'monolitic' pkg of it few years ago
2021-09-23 10:21:37 <mps> earlier all drivers were in separate subpkgs
2021-09-23 10:22:05 <mps> but pmOS people wanted monolitic one
2021-09-23 10:22:37 <mps> I will ask TSC to ban all pmOS devs from alpine
2021-09-23 10:23:41 <mps> not TSC, council
2021-09-23 10:24:04 <mps> I know result from TSC in advance
2021-09-23 10:24:39 <skarnet> love it when people complain about my stuff using 2 MB of disk
2021-09-23 10:24:50 <mps> :D
2021-09-23 10:25:31 <mps> anything which is not essential is too much
2021-09-23 10:28:19 <mps> now seriously, it is time to decide do 'we' still want alpine to be small, simple, secure (as possible) or user friendly distro
2021-09-23 10:31:33 <ncopa> mps: in which commit was all the drivers made monolitic?
2021-09-23 10:32:03 <mps> will look
2021-09-23 10:36:01 <mps> hmm, can't find, have to install old release to check
2021-09-23 10:37:01 <mps> holly uh, drivers are hardlinks
2021-09-23 10:37:14 <ikke> so actual size is smaller?
2021-09-23 10:37:49 <ikke> package size is only 6.7 MB
2021-09-23 10:38:05 <mps> yes
2021-09-23 10:38:26 <mps> why the du don't understand this
2021-09-23 10:39:09 <ikke> There is --count-links, which does the opposite
2021-09-23 10:39:15 <ikke> so I should expect it to not count hard links double
2021-09-23 10:41:15 <ikke> (-l for busybox du)
2021-09-23 10:42:31 <mps> this is for symlinks
2021-09-23 10:43:17 <ikke> -l      Count sizes many times if hard linked
2021-09-23 10:44:31 <mps> ahm, both bb and coreutils
2021-09-23 10:44:46 <mps> there is no 'opposite' switch
2021-09-23 11:08:25 <mps> 298e20d04fdbc33fc32a0388f645ca02e1fa3961
2021-09-23 11:08:31 <mps> this explains
2021-09-23 12:02:38 <Ariadne> 5:22 AM <mps> I will ask TSC to ban all pmOS devs from alpine
2021-09-23 12:02:41 <Ariadne> can we not?
2021-09-23 12:06:58 <Ariadne> most of the pmOS developers are also using alpine on their other infrastructure and want alpine to succeed like everyone else.  i think putting them down is not productive and just demoralizes people
2021-09-23 12:07:56 <mps> Ariadne: I thought that everyone will 'see' that was joke
2021-09-23 12:08:32 <Ariadne> i don’t think it’s good to make such jokes, punch up not down
2021-09-23 12:08:57 <Ariadne> “i will ask TSC to ban openssl from alpine” is funny, this is not :p
2021-09-23 12:09:28 <mps> it depends on the reader
2021-09-23 12:09:49 <donoban> ey Ariadne yesterday I switched my point of view about 'others', really the deny by default policy is not more secure than just default base-xxxx config (if it isn't we already have a problem), and using an "allow" others configuration has an interesting advantage, you don't need to define a config for each program that needs pam... (su, chpasswd, login, etc...) so you end with
2021-09-23 12:09:51 <donoban> less files in /etc/pam.d/ (which most are just includes to base-xxx)
2021-09-23 12:10:21 <donoban> also, if the user wants to specify some custom rules for some application, it won't get apk-new files in each upgrade
2021-09-23 12:10:35 <Ariadne> i will ask TSC to ban PAM from alpine :D
2021-09-23 12:10:44 <mps> :D
2021-09-23 12:10:45 <donoban> yeah that's another option
2021-09-23 12:11:09 <donoban> I just don't like the current mess
2021-09-23 12:11:11 <Ariadne> yeah unfortunately people want their whatever plug-ins
2021-09-23 12:11:16 <skarnet> Ariadne: I'm all for it
2021-09-23 12:11:31 <skarnet> that just requires some client rewriting
2021-09-23 12:11:44 <skarnet> to use PAM conversations instead of global state
2021-09-23 12:11:52 <skarnet> and then pamela can work :P
2021-09-23 12:12:11 <Ariadne> should make something better
2021-09-23 12:12:12 <Ariadne> call it
2021-09-23 12:12:14 <mps> Ariadne: you noticed that I wrote after joking msgs one which starts with ' now seriously, it is time to ......'
2021-09-23 12:12:17 <skarnet> well strictly speaking that wouldn't be banning pam
2021-09-23 12:12:18 <Ariadne> Better Authentication Modules
2021-09-23 12:12:23 <Ariadne> BAM
2021-09-23 12:12:26 <skarnet> I like it
2021-09-23 12:12:44 <skarnet> I'm all for designing it but I don't want to end up remaking polkit
2021-09-23 12:13:34 <ddevault> fuck PAM
2021-09-23 12:13:38 <skarnet> at *some* point we'll have to do BAM
2021-09-23 12:13:38 <ddevault> /etc/passwd is good enough
2021-09-23 12:13:58 <caskd> /etc/passwd but as a dir
2021-09-23 12:14:07 <ddevault> no
2021-09-23 12:14:09 <ddevault> just /etc/passwd
2021-09-23 12:14:18 <ddevault> and /etc/shadow I suppose
2021-09-23 12:14:21 <Ariadne> it’s /etc/shadow that you want as did
2021-09-23 12:14:22 <skarnet> ddevault: then you mean fuck PAM *and* NSS
2021-09-23 12:14:25 <Ariadne> dir*
2021-09-23 12:14:26 <ddevault> yes, I do mean that
2021-09-23 12:15:12 <Ariadne> i agree in spirit but a lot of users want to use yubikey and OTP stuff and so on
2021-09-23 12:15:13 <donoban> until it get's removed it has nonexisting options or calls to non include modules :\
2021-09-23 12:15:19 <Ariadne> which presently requires PAM
2021-09-23 12:15:23 <mps> adding layers on 'security' is false sense of security
2021-09-23 12:15:26 <ddevault> just tell them no
2021-09-23 12:16:03 <Ariadne> well alpine already has PAM for a decade so we already told them yes
2021-09-23 12:16:08 <skarnet> can't do much about PAM for now, but for NSS, next version of nsss is up at the end of the month and includes an actual switching program, so... :P
2021-09-23 12:16:23 <ddevault> we can redact that
2021-09-23 12:16:29 <ddevault> no decisions are permanent
2021-09-23 12:17:00 <mps> removing bad things are not bad
2021-09-23 12:17:00 <donoban> in the no so unrealistic case that pam remains...  what you think about 'others' config?
2021-09-23 12:17:01 <ddevault> and I would rather not install a package which accidentally brings PAM on board and then discover I have a rootkit months later
2021-09-23 12:17:24 <ddevault> or weeks, given the pace at which PAM introduces new and exciting rootkits
2021-09-23 12:17:33 <Ariadne> days really
2021-09-23 12:18:13 <mps> worst kind of security is false sense of security
2021-09-23 12:19:26 <Ariadne> i’m not saying don’t do it, i’m just saying we should look at the usecases that people are trying to enable as part of any system change proposal to remove it
2021-09-23 12:19:36 <caskd> ^
2021-09-23 12:19:39 <donoban> well if PAM is bad itself, a complex and unchecked config is even worse
2021-09-23 12:20:11 <mps> security is complex, always
2021-09-23 12:20:52 <ddevault> at least we can move it to community
2021-09-23 12:20:54 <donoban> yep but it desn't means that the pam configuration (speacially for just pasasword based login) has to be complex
2021-09-23 12:21:05 <mps> but less elements in system is easier to make more secure
2021-09-23 12:21:29 <donoban> currently it is too complex because it is a mix of other sources, like gdm that just takes archlinux configuration
2021-09-23 12:21:38 <Ariadne> ddevault: people use PAM with sshd though?
2021-09-23 12:21:48 <ddevault> give them a different sshd package with PAM support, also in community
2021-09-23 12:21:53 <ddevault> openssh-pam
2021-09-23 12:21:59 <ddevault> conflicts="openssh"
2021-09-23 12:22:42 <Ariadne> i think the openssh package is already split that way anyway
2021-09-23 12:22:58 <ddevault> aye, it seems to be
2021-09-23 12:23:04 <mps> yes it is
2021-09-23 12:23:39 <Ariadne> not having to prove N years of support for linux-pam does sound nice
2021-09-23 12:24:14 <mps> move to community
2021-09-23 12:24:45 <Ariadne> i think also opensshd is gaining support for using libfido directly so PAM can be bypassed
2021-09-23 12:25:18 <mps> maybe also this could be moved to community
2021-09-23 12:25:36 <ddevault> frankly, openssh is already too complicated
2021-09-23 12:25:41 <mps> this is mostly used as ssh clients
2021-09-23 12:25:45 <ddevault> it would be nice to have a good alternative which uses the same protocol with like 1/10th the features
2021-09-23 12:26:19 <Ariadne> tinyssh
2021-09-23 12:26:35 <mps> heh, you took my word
2021-09-23 12:26:37 <ddevault> nice
2021-09-23 12:26:57 <ddevault> community => main
2021-09-23 12:26:58 <Ariadne> it’s already packages
2021-09-23 12:27:38 <donoban> does it works with mosh?
2021-09-23 12:27:44 <ddevault> oh, yikes, it does inetd et al
2021-09-23 12:27:47 <Ariadne> no idea
2021-09-23 12:29:24 <Ariadne> yeah the inetd aspect is one i don’t like about it
2021-09-23 12:38:19 <mps> mosh have '--ssh=COMMAND', default is ssh
2021-09-23 12:38:38 <donoban> ah, thanks mps 
2021-09-23 12:39:58 <mps> but tinyssh is only server
2021-09-23 12:40:53 <jvoisin> it's sad that mosh didn't have any new release in aeons
2021-09-23 12:41:46 <ddevault> if it's done, it's done
2021-09-23 12:41:48 <ddevault> no need to churn forever
2021-09-23 12:44:39 <jvoisin> there are nice features in the master branch unfortunately.
2021-09-23 12:44:44 <jvoisin> like truecolour support ♥
2021-09-23 12:45:25 <mps> oh ;)
2021-09-23 12:46:32 <jvoisin> damn, tinyssh looks __nice__
2021-09-23 12:47:01 <donoban> and dropbear?
2021-09-23 12:57:40 <dalias> isn't tinyssh the one that doesn't support the standard set of keys etc ?
2021-09-23 12:58:17 <dalias> jvoisin, does mosh insist on doing its terminal-emulator thing or can it act as a binary-clean data path?
2021-09-23 13:19:07 <Habbie> dalias, mosh is a viewport syncer, not a pipe
2021-09-23 13:29:55 <dalias> :(
2021-09-23 13:30:16 <dalias> i want something like mosh but just a data channel that's immune to connection loss
2021-09-23 13:30:21 <dalias> (blocks until it comes back up)
2021-09-23 13:30:47 <dalias> that can run pty over it or just raw binary link over it just like ssh does
2021-09-23 13:34:17 <Habbie> ssh over openvpn or wireguard does some of that, with some effort
2021-09-23 13:34:43 <dalias> the tcp connection will still drop on timeout
2021-09-23 13:35:33 <Habbie> making it not do that is part of the effort, although i'm unsure that is doable when there is data pending
2021-09-23 13:35:43 <dalias> i want something where i could write A, then come back 10 years later and write B, and the B gets there to the process on the other end :)
2021-09-23 13:35:51 <Habbie> understood
2021-09-23 13:36:10 <Habbie> various MQ protocols can deliver this, i'm sure
2021-09-23 13:37:48 <mps> socat?
2021-09-23 13:51:53 <skarnet> jvoisin: can confirm tinyssh is really nice
2021-09-23 13:52:22 <skarnet> Ariadne: mumble mumble s6-tcpserver mumble inetd shouldn't ever be a problem mumble
2021-09-23 13:53:25 <skarnet> unless you don't like a DH exchange under inetd for cpu reasons, but that's only a concern on potato-powered boards nowadays
2021-09-23 14:36:38 <aidan55[m]> Hello guys. I figured out that Chromium's APKBUILD doesn't have is_official_build flag ! (Fortunately is_clang flag is enabled [CFI] which is good for security)... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/rQJMkzOoBKLTvybSHAqCrOKy)
2021-09-23 14:57:05 <dalias> sounds like a very poorly named option with behaviors designed around chrome as google's product and no thought for how the naming would affect open source users
2021-09-23 14:57:28 <dalias> i would definitely not think "is_official_build" is something intended to be set to true for open source distributors
2021-09-23 14:58:12 <dalias> but if it does behave as described it should probably be set -- unless it also does things that restrict what the user can do in inappripriate ways
2021-09-23 15:21:48 <aidan55[m]> <dalias> "but if it does behave as..." <- I don't think it restrict users. That flag decreases attack surface !
2021-09-23 15:24:25 <psykose> the gentoo ebuild has it as a flag and apparently seds something to use system libs after it is set
2021-09-23 15:28:24 <aidan55[m]> > <@aidan55:matrix.org> Hello guys. I figured out that Chromium's APKBUILD doesn't have is_official_build flag ! (Fortunately is_clang flag is enabled [CFI] which is good for security)... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/ujIZMtUgTgjbzpHaPlGfudCn)
2021-09-23 15:29:04 <aidan55[m]> > <@aidan55:matrix.org> Hello guys. I figured out that Chromium's APKBUILD doesn't have is_official_build flag ! (Fortunately is_clang flag is enabled [CFI] which is good for security)... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/dFURfWlCgRaiAAchngyfUdaU)
2021-09-23 15:29:41 <dalias> ..matrix bug?
2021-09-23 15:29:49 <eris[m]> whats the bug
2021-09-23 15:30:00 <eris[m]> aidan just tried to reply
2021-09-23 15:30:03 <dalias> keeps repeating same thing with full message out of band
2021-09-23 15:30:11 <dalias> oh..
2021-09-23 15:30:26 <eris[m]> oh dear
2021-09-23 15:30:27 <dalias> don't quote like that. only a truncated part of the quote is visible
2021-09-23 15:30:38 <dalias> the actual reply is truncated
2021-09-23 15:30:54 <eris[m]> 'ncopa , you are the maintainer. Right ? 😅'
2021-09-23 15:31:02 <eris[m]> i forgot how replies worked internally
2021-09-23 15:31:03 <psykose> wish the bridge told the user the message is longer than the limit and refused to send instead of whatever that is
2021-09-23 15:31:08 <dalias> the matrix bridge should really be fixed to reformat properly for irc
2021-09-23 15:31:16 <dalias> it could just break into multiple lines
2021-09-23 15:31:21 <psykose> or that, yeah
2021-09-23 15:32:59 <aidan55[m]> dalias: Ok.
2021-09-23 15:32:59 <aidan55[m]> Thank you, i didn't know that 😅👌
2021-09-23 16:03:05 <mps> uhm, why this happens 'src/processes.h:34:3: error: unknown type name 'pid_t''
2021-09-23 16:03:58 <mps> trying to build new pkg, netproc -> https://github.com/berghetti/netproc
2021-09-23 16:05:45 <mps> sys/types.h is missing?
2021-09-23 16:07:16 <mps> ah, yes
2021-09-23 16:07:46 <mps> but now, 'src/tui.c:140:20: warning: format '%d' expects argument of type 'int', but argument 3 has type 'nstats_t' {aka 'long unsigned int'} [-Wformat=]'
2021-09-23 16:10:07 <mps> huh, fixed, but have to create patches
2021-09-23 16:10:27 <dalias> need to cast types like that before passing them to printf
2021-09-23 16:11:00 <mps> I changed '%d' to '%ld' and it builds without error
2021-09-23 16:11:08 <mps> is that ok?
2021-09-23 16:11:10 <dalias> no
2021-09-23 16:11:16 <dalias> that just encoded a different wrong assumption
2021-09-23 16:11:38 <dalias> if you don't know anything about the range of the type being printed, the right thing to do is use %jd and (intmax_t) cast
2021-09-23 16:11:51 <dalias> %lld and (long long) is probably ok too if you prefer
2021-09-23 16:14:59 <mps> defined as static 'nstats_t cur_pps_tx, cur_pps_rx;'
2021-09-23 16:15:54 <mps> %lld is simple, have to test does it works
2021-09-23 16:17:28 <kpcyrd> is it considered ok to source the conf.d file from my cronjob? (both distributed in the same package)
2021-09-23 16:17:29 <mps> hmm, looks problematic
2021-09-23 16:17:58 <mps> kpcyrd: not answer to you
2021-09-23 16:18:28 <kpcyrd> mps: all good, that would've been impressively fast :)
2021-09-23 16:24:40 <psykose> kpcyrd: don't see why not
2021-09-23 16:24:46 <mps> dalias: changed line to 'wprintw ( pad, "%jd", (intmax_t) cur_pps_rx );', builds without any error
2021-09-23 16:25:21 <dalias> wprintw?
2021-09-23 16:25:50 <mps> original was 'wprintw ( pad, "%d", cur_pps_rx );'
2021-09-23 16:26:05 <dalias> not wprintf?
2021-09-23 16:26:14 <mps> right
2021-09-23 16:26:30 <dalias> i was wondering if it was some curses api or something else
2021-09-23 16:26:31 <mps> ncurses
2021-09-23 16:26:38 <dalias> ohh so maybe it is then
2021-09-23 16:26:51 <dalias> w=window?
2021-09-23 16:27:25 <mps> I think so, I didn't touched curses in C for years
2021-09-23 16:28:06 <mps> if I need curses application I write it in perl ;)
2021-09-23 16:29:28 <mps> no one commented !25642, I'll merge it as it is now
2021-09-23 16:30:28 <mps> had a hope that ericonr will post new with BSD_SOURCE instead of GNU_SOURCE
2021-09-23 16:31:34 <dalias> i'm ok with making that change
2021-09-23 16:31:47 <dalias> i also don't want to keep holding up for release because i think that's made progress stall :/
2021-09-23 16:32:17 <mps> ok, I will change this patch for alpine (for now)
2021-09-23 16:32:35 <mps> hope ericonr will do that and post to ML
2021-09-23 17:23:34 <mkaesberger> aidan55[m]: I'm not sure about is_official_build, but is_unsafe_developer_build should be set to false
2021-09-23 17:24:02 <mkaesberger> chromium is one big disaster. v94 does compile, but crashes constantly, there is no sound inside the sandbox, v8 fails to lock a mutex
2021-09-23 17:24:41 <dalias> :/
2021-09-23 17:25:04 <mkaesberger> oh, the documented method to attach gdb to the renderer does not work.
2021-09-23 18:06:26 <aidan55[m]> <mkaesberger> "aidan55: I'm not sure about..." <- Why false ?
2021-09-23 18:07:18 <psykose> because if it was true then it would be an 'unsafe developer build
2021-09-23 18:08:36 <aidan55[m]> psykose: My bad.
2021-09-23 18:08:36 <aidan55[m]> My matrix client sucks !
2021-09-23 18:08:36 <aidan55[m]> I thought he replied me and told me that it (is_official_build flag) should be false.
2021-09-23 18:08:48 <mkaesberger> base/BUILD.gn:58 -> `is_unsafe_developer_build = !is_official_build`
2021-09-23 18:12:58 <aidan55[m]> https://git.alpinelinux.org/aports/tree/community/chromium/APKBUILD
2021-09-23 18:13:30 <aidan55[m]> 
ACTION uploaded an image: (192KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/pkFcCwmCxUiWMDagzuuyNJUE/Screenshot_20210923-214246_Bromite.jpg >

2021-09-23 18:14:26 <aidan55[m]> <mkaesberger> "base/BUILD.gn:58 -> `is_unsafe_d..." <- None of them are available in the APKBUILD.
2021-09-23 18:15:54 <mps> it is really bad to use quotes from matrix here
2021-09-23 18:18:18 <dalias> mps, yes, someone should talk with admins about fixing the bridge not to do ridiculous stuff incompatible with irc
2021-09-23 18:20:22 <mkaesberger> aidan55[m]: I mixed something up with my electron build. is_official_build is false by default
2021-09-23 18:21:26 <mkaesberger> it looks like is_unsafe_developer_build has no effect/is not used...
2021-09-23 18:52:20 <nmeum> ncopa: do you still recall what this patch is about? 🤔 https://git.alpinelinux.org/aports/tree/main/mandoc/shared-libmandoc.patch
2021-09-23 18:54:55 <mps> nmeum: when you are working on it, there is 'option' to add /etc/mandoc.conf file
2021-09-23 18:55:35 <nmeum> we can do that independed of the version upgrade
2021-09-23 18:56:57 <mps> sure, I thought earlier to do that, but time is killer (and short-lived memory)
2021-09-23 20:35:21 <xordspar0> dalias, re %jd and intmax_t: That is good advice. The last time I was in that situation I tried to do something with macros and fixed width integers, but ("%jd", (intmax_t)x) is simple and correct.
2021-09-23 20:37:38 <Thermi_> ARe you doing work on the GL instance? When pulling/fetching from the abuild repo I get http error 429
2021-09-23 20:40:36 <dalias> xordspar0, :)
2021-09-23 21:39:18 <ericonr> aidan55[m]: chromium sandbox hard codes /run/user/$UID for pulseadio socket 
2021-09-23 21:39:40 <ericonr> getenv("XDG_RUNTIME_DIR") is too much for them
2021-09-23 23:07:05 <dalias> wtf
2021-09-23 23:07:09 <dalias> can we like patch that?
2021-09-23 23:22:34 <Thermi_> abuild repo still gives me http 429
2021-09-23 23:24:15 <Thermi_> Btw, it's that one. The official one. https://gitlab.alpinelinux.org/alpine/abuild
2021-09-23 23:24:33 <Thermi_> LANG=C git fetch --jobs=1 origin 
2021-09-23 23:24:33 <Thermi_> error: RPC failed; HTTP 429 curl 22 The requested URL returned error: 429
2021-09-23 23:24:33 <Thermi_> fatal: the remote end hung up unexpectedly
2021-09-23 23:53:20 <dalias> why LANG=C ? :(
2021-09-24 04:27:25 <ikke> Thermi_: not doing work atm
2021-09-24 06:53:27 <oneinsect> Diskless APKOVL loading dosn't work on btrfs and xfs filesystems, or nvme-based devices
2021-09-24 06:53:31 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11589
2021-09-24 06:53:36 <oneinsect> why not?
2021-09-24 07:02:42 <aidan55[m]> <ericonr> "aidan55: chromium sandbox hard..." <- What do you mean ?
2021-09-24 08:48:50 <ncopa> morning
2021-09-24 08:49:20 <ncopa> nmeum: im not sure but it looks like creates a shared lib
2021-09-24 08:50:02 <nmeum> ncopa: yes, I see that. I was wondering why using a shared lib instead of the static libmandoc.a is neccessary in the first place ':D
2021-09-24 08:51:16 <nmeum> 6b731eecdf600d8d435d129bf2838e3babb77c56 the patch is 6 years old, maybe it resulted in a size dcrease back then because there were many binaries using the library?
2021-09-24 08:51:45 <ncopa> i believe it did
2021-09-24 08:52:34 <nmeum> I don't think this causes a size decrease anymore because mandoc is the only binary we are shipping which actually uses this library
2021-09-24 08:52:58 <ncopa> i think that used not be the case
2021-09-24 08:53:25 <ncopa> no reason to link it shared if it is a single binary using it
2021-09-24 08:53:34 <nmeum> yeah
2021-09-24 08:53:53 <nmeum> man.cgi and such still use the library but we don't package those atm
2021-09-24 08:54:45 <ncopa> lets drop the patch
2021-09-24 08:54:53 <nmeum> ok, sure :)
2021-09-24 08:54:58 <nmeum> !25691
2021-09-24 08:55:54 <ncopa> i can try do some archeology if you want to figure out why i spent time on it back then
2021-09-24 08:57:25 <nmeum> it's not urgent. I just encountered this patch while upgrading mandoc yesterday and was wondering what the reason behind it is and if we still need it
2021-09-24 09:01:54 <ncopa> was used by mandoc, manpage, man.cgi and demandoc. 4 binaries sharing the same code. made sense back then to have it shared
2021-09-24 09:03:12 <ncopa> today its used by mandoc, man.cgi, mandocd, catman and demandoc
2021-09-24 09:07:12 <ncopa> lol
2021-09-24 09:07:22 <ncopa> the current patch is broken
2021-09-24 09:07:38 <ncopa> i actually think it makes sense to ship it shared still
2021-09-24 09:08:17 <ncopa> but the current patch is broken. it just renames the static lib to libmandoc.so and then it links to it statically
2021-09-24 09:09:18 <ncopa> i think this broke it 0f2323f228dc8714e8e1f9480fa9234ac8a276e5
2021-09-24 09:18:32 <ncopa> and i know why i did it. the size of the package was surprisingly big
2021-09-24 09:26:12 <ncopa> mandoc-1.14.6-r1 installed size:
2021-09-24 09:26:12 <ncopa> 1104 KiB
2021-09-24 09:26:12 <ncopa> mandoc-1.14.6-r0 installed size:
2021-09-24 09:26:12 <ncopa> 520 KiB
2021-09-24 09:26:26 <ncopa> almost half size with the patch
2021-09-24 09:26:43 <ncopa> im gonna push a fix for it
2021-09-24 13:17:59 <nmeum> ncopa: looks like this slipped through while rebasing the patch from the release canidate to the actual release, sorry about that
2021-09-24 13:18:53 <nmeum> still somewhat suprised that the package is bigger with static linking though when having a single binary which uses the lib
2021-09-24 13:19:42 <nmeum> ah! demandoc uses it too ok then
2021-09-24 13:20:07 <nmeum> I think I will suggest this patch upstream
2021-09-24 13:25:19 <ericonr> aidan55[m]: can you explain which part wasn't clear?
2021-09-24 14:11:56 <donoban> Ariadne: I noticed a segfault on remmina when using ssh tunnel, could it be related to openssl?
2021-09-24 14:13:28 <donoban> I'm gonna test with openssl1.1-compat
2021-09-24 14:15:24 <donoban> ouch conlficts...
2021-09-24 14:25:31 <donoban> Thread 16 "remmina" received signal SIGSEGV, Segmentation fault.
2021-09-24 14:25:33 <donoban> [Switching to LWP 18642]
2021-09-24 14:25:35 <donoban> get_meta (p=p@entry=0x7ffff1f086e0 "") at src/malloc/mallocng/meta.h:135
2021-09-24 14:26:05 <donoban> I think it's musl code
2021-09-24 14:29:06 <dalias> there's a slim chance it's a bug on musl's part but more likely heap corruption by caller
2021-09-24 14:29:36 <donoban> I would need to build remmina with debug symbols
2021-09-24 14:29:48 <dalias> run it under valgrind first
2021-09-24 14:29:52 <dalias> that might tell you something
2021-09-24 14:29:58 <donoban> ok
2021-09-24 14:31:41 <donoban> uhM, under valgrind I could see a few seconds until crashed
2021-09-24 14:32:09 <donoban> valgrind: m_mallocfree.c:278 (mk_plain_bszB): Assertion 'bszB != 0' failed.
2021-09-24 14:32:46 <donoban> valgrind: This is probably caused by your program erroneously writing past the
2021-09-24 14:32:48 <donoban> end of a heap block and corrupting heap metadata.
2021-09-24 14:38:11 <donoban> dalias: altough there are many threads valgrind output is sequenntially?
2021-09-24 14:38:44 <dalias> i'm not sure
2021-09-24 14:38:55 <dalias> sounds like this program is doing something bad tho :-p
2021-09-24 14:40:01 <donoban> there are many invalid writes and read, but the first seems realted to libcrypto/libssh
2021-09-24 14:40:10 <donoban> so the relation with openssl3 is likely
2021-09-24 14:40:33 <dalias> can you show the valgrind log?
2021-09-24 14:41:16 <donoban> yeah, let me paste somehwere
2021-09-24 14:45:36 <donoban> https://tpaste.us/MzXk
2021-09-24 14:49:30 <ericonr> libgcrypt is not OpenSSL at all
2021-09-24 14:50:33 <donoban> yeah but problems appear with libcrypto.so.3 and libssh
2021-09-24 14:50:49 <donoban> in fact, I was running it fine for months until trying today an ssh tunnel
2021-09-24 14:53:10 <dalias> this log is truncated and lacks any errors related to the crash
2021-09-24 14:53:59 <dalias> they're all libgcrypt, likely it being stupid and using uninitialized memory as "entropy"
2021-09-24 14:54:03 <donoban> uhM, why do you think it's truncated? I redirect stdout/stderr to a file before posting
2021-09-24 14:54:16 <dalias> the last line is partial:
2021-09-24 14:54:20 <dalias> ==12024==    by 0x567B3CB: ??? (in /usr/lib/libg
2021-09-24 14:54:35 <donoban> uhM
2021-09-24 14:54:57 <donoban> I refreshed it and see truncated too
2021-09-24 14:55:05 <donoban> but initally I was full
2021-09-24 14:55:11 <donoban> strange :\
2021-09-24 14:55:23 <donoban> let me cut all the entropy initalization
2021-09-24 14:55:56 <ericonr> (or use another paste that doesn't do weird things)
2021-09-24 14:56:05 <donoban> jeje ok
2021-09-24 14:56:09 <ericonr> dalias: wtf it's 2021
2021-09-24 14:56:31 <donoban> any suggestion?
2021-09-24 14:56:40 <ericonr> ix.io
2021-09-24 14:58:02 <donoban> V
2021-09-24 14:58:04 <donoban> http://ix.io/3zQ0
2021-09-24 14:58:25 <donoban> see full log now?
2021-09-24 14:59:29 <dalias> yes
2021-09-24 14:59:34 <donoban> ok
2021-09-24 14:59:36 <donoban> nice
2021-09-24 14:59:38 <dalias> ==12024==  Address 0x94fc8df is 15 bytes after a block of size 48 in arena "client"
2021-09-24 14:59:50 <dalias> this is probably the corruption
2021-09-24 15:00:06 <dalias> that would cause the crash you observed
2021-09-24 15:00:09 <donoban> and that part has relation with openssl?
2021-09-24 15:00:38 <dalias> maybe this too
2021-09-24 15:00:39 <dalias> ==12024==  Address 0x94fc8d8 is 17 bytes after a block of size 39 free'd
2021-09-24 15:01:15 <dalias> this too:
2021-09-24 15:01:16 <dalias> ==12024==  Address 0x94fc6e0 is 0 bytes after a block of size 0 alloc'd
2021-09-24 15:01:29 <dalias> it tried to write to a malloc(0) object
2021-09-24 15:01:42 <dalias> these last 2 are both explicit_bzero
2021-09-24 15:01:58 <dalias> there's some wrong memory-clearing code that's miscomputing the size of the memory to clear
2021-09-24 15:02:37 <donoban> but do you think it's more likely on remmina than other of its deps?
2021-09-24 15:02:48 <dalias> it's hard to be sure
2021-09-24 15:03:15 <dalias> these last 2 are either remmina or libssh
2021-09-24 15:03:33 <donoban> I would like to test another dependan libssh program
2021-09-24 15:03:57 <donoban> well, I will continue later
2021-09-24 15:04:04 <donoban> thanks for the help
2021-09-24 15:07:09 <dalias> i dont see an immediately obvious problem in remmina
2021-09-24 16:25:32 <donoban> well, I rebuilded libvnc and libssh with openssl1 and remmina don't crashes now
2021-09-24 16:30:19 <dalias> i suspect there was ABI breakage in one of these libraries
2021-09-24 16:30:24 <dalias> (struct size changed or something)
2021-09-24 16:30:30 <dalias> can you confirm that valgrind finds no problems now?
2021-09-24 16:30:38 <donoban> yes
2021-09-24 16:30:52 <dalias> yes = no problems found?
2021-09-24 16:31:00 <donoban> I can hehe
2021-09-24 16:31:12 <dalias> ah ok :)
2021-09-24 16:33:06 <donoban> http://ix.io/3zQL
2021-09-24 16:33:17 <donoban> it's opened and into the vnc now
2021-09-24 16:33:39 <donoban> it seems correct
2021-09-24 16:34:10 <donoban> uhM
2021-09-24 16:35:09 <donoban> http://ix.io/3zQN here is log after closing it
2021-09-24 16:35:11 <donoban> with the summary
2021-09-24 16:35:51 <donoban> so is it leaking memory?
2021-09-24 16:36:16 <dalias> looks ok
2021-09-24 16:36:19 <dalias> no
2021-09-24 16:36:28 <dalias> valgrind's definition of "leaks" is just meaningless
2021-09-24 16:36:59 <dalias> it's a box-checking definition that has no relationship to what matters
2021-09-24 16:37:25 <donoban> ok
2021-09-24 16:37:27 <dalias> by its definition, a program that had a timer appending a dummy 1k allocation to a linked list every 1 second would have no leaks as long as it walked the whole list and freed them all before exit
2021-09-24 16:37:54 <donoban> maybe Ariadne has some idea about this
2021-09-24 16:37:59 <dalias> but a program with bounded memory usage that just exit()s without performing useless, slow, disk-thrashing walk of all data structures to free() them as "omg memory leaks!"
2021-09-24 16:38:22 <donoban> hehe interesting
2021-09-24 16:38:41 <Ariadne> yes my opinion is that remmina is shit
2021-09-24 16:38:49 <donoban> ahh nice
2021-09-24 16:39:03 <Ariadne> it has never worked for me in the 10 years that it has existed
2021-09-24 16:39:11 <dalias> :-p
2021-09-24 16:39:18 <dalias> this looks like it wasn't remmina's fault
2021-09-24 16:39:28 <dalias> just version skew with libssh
2021-09-24 16:39:41 <ddevault> +1 for pkgusers and pkggroups
2021-09-24 16:39:42 <ddevault> when was that added?
2021-09-24 16:40:06 <ddevault> 2013 lol
2021-09-24 16:40:09 <ddevault> I guess it doesn't see much use
2021-09-24 16:40:12 <Ariadne> probably rebuild libvnc, libssh, remmina and see if it fixes it
2021-09-24 16:40:24 <donoban> uhM, I did it
2021-09-24 16:40:30 <donoban> rebuild them with openssl1.1-compat
2021-09-24 16:40:41 <Ariadne> yes i’m saying rebuild them with openssl3
2021-09-24 16:40:54 <Ariadne> to actually confirm the theory of abi mismatch
2021-09-24 16:40:56 <donoban> ah, but they were already with openssl3
2021-09-24 16:41:02 <Ariadne> …
2021-09-24 16:41:06 <donoban> afaik..
2021-09-24 16:41:14 <Ariadne> yes i know but libvnc was not rebuilt
2021-09-24 16:41:22 <donoban> ah I see
2021-09-24 16:41:44 <donoban> lol
2021-09-24 16:41:55 <donoban> so I broke it just because I rebuilded?
2021-09-24 16:41:56 <donoban> :\
2021-09-24 16:42:05 <donoban> makes sense
2021-09-24 16:42:14 <Ariadne> i didn’t say you broke it
2021-09-24 16:42:25 <donoban> yeah I mean that I rebuilded it locally
2021-09-24 16:42:41 <donoban> but the repo version probably works fine
2021-09-24 16:42:53 <Ariadne> maybe, maybe not
2021-09-24 16:42:57 <donoban> well
2021-09-24 16:43:06 <donoban> so let's try to rebuild all them with openssl-dev
2021-09-24 16:43:11 <donoban> right?
2021-09-24 16:43:11 <Ariadne> like i said remmina has never worked right for me :p
2021-09-24 16:43:13 <Ariadne> yes
2021-09-24 16:43:17 <donoban> ok
2021-09-24 16:43:55 <donoban> before ending with this problem, I wanted to disble some things on remmine like libsecret and avahi so do it non-dependant on dbus
2021-09-24 16:44:02 <Ariadne> it does seem possible if openssl structures are included in structures used by those libs that a silent abi break occurred
2021-09-24 16:44:13 <donoban> because there is some error with gnome-keyring and it asks for password everytime
2021-09-24 16:44:19 <Ariadne> i feel like cogitri will be upset
2021-09-24 16:44:22 <Ariadne> if you do that
2021-09-24 16:44:36 <donoban> well
2021-09-24 16:44:44 <donoban> I'm just asking :P
2021-09-24 16:45:12 <Cogitri[m]> The gnome-keyring error is an annoying one through
2021-09-24 16:45:13 <donoban> anyone here uses avahi?
2021-09-24 16:45:16 <Cogitri[m]> Couldn’t quite figure out why it isn’t unlocked during login, something is botched with our PAM config
2021-09-24 16:45:43 <Ariadne> yes sounds suboptimal
2021-09-24 16:45:56 <Ariadne> i just know you want stuff to be packaged to gnome specs
2021-09-24 16:45:59 <Ariadne> :)
2021-09-24 16:46:00 <donoban> Cogitri[m]: you mean this error? couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status 1
2021-09-24 16:52:27 <donoban> lol
2021-09-24 16:52:30 <donoban> it works fine now
2021-09-24 16:53:16 <donoban> so there are many packages running openssl1 altought have 3 on aports?
2021-09-24 16:53:54 <ikke> donoban: mariadb does not work with openssl3.0 yet
2021-09-24 16:53:56 <ikke> and some either either
2021-09-24 16:54:03 <ikke> so they use openssl1.1-compat
2021-09-24 16:54:15 <donoban> yep but I mean that they "use" openssl3
2021-09-24 16:54:24 <donoban> but they aren't rebuilded yet
2021-09-24 16:54:40 <donoban> it seems the problem that I experimented with remminna and libssh
2021-09-24 16:55:23 <ikke> afaik, everything in main and community has been rebuilt
2021-09-24 16:55:31 <donoban> uhM
2021-09-24 16:55:34 <ikke> that depends on openssl
2021-09-24 16:55:48 <donoban> maybe my mirror is outdated?
2021-09-24 17:01:56 <donoban> I dont understand what happened
2021-09-24 17:02:44 <donoban> yes
2021-09-24 17:02:59 <donoban> this is my libssh.so.4 (builded by me some minutes ago)
2021-09-24 17:03:07 <donoban>         libcrypto.so.3 => /lib/libcrypto.so.3 (0x7fda01494000)
2021-09-24 17:03:18 <donoban> and this from yesterday snapshot of /
2021-09-24 17:03:20 <Habbie> is there a list of packages that don't work with openssl3?
2021-09-24 17:03:22 <donoban>         libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x7f2624279000)
2021-09-24 17:03:47 <ikke> Habbie: not comprehensive: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13001
2021-09-24 17:04:34 <donoban> I did many apk -Ua upgrades today
2021-09-24 17:06:24 <donoban> any idea?
2021-09-24 17:06:29 <ikke> no
2021-09-24 17:07:27 <donoban> looking at http://alpine.42.fr/edge/community/x86_64/
2021-09-24 17:07:42 <donoban> libssh-0.9.6-r0.apk is from 2021-Aug-27 03:49
2021-09-24 17:08:08 <donoban> but the mirror has a lot of packages from today
2021-09-24 17:08:13 <ikke> https://mirrors.alpinelinux.org/#mirror31
2021-09-24 17:09:30 <donoban> when all the openssl related packages were rebuilded?
2021-09-24 17:10:38 <Habbie> whelp, my apk is unhappy
2021-09-24 17:10:40 <Habbie>   0%                                                                                                            140197341006664:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1914:
2021-09-24 17:11:04 <Ariadne> use —allow-untrusted to upgrade
2021-09-24 17:11:09 <Ariadne> with http repo
2021-09-24 17:11:13 <Ariadne> instead of https
2021-09-24 17:11:31 <donoban> I downloaded libssh from the repo and it's linked to openssl1
2021-09-24 17:11:34 <Ariadne> you need openssl1.1-compat 1.1.1l-r3
2021-09-24 17:11:52 <Ariadne> donoban: yes
2021-09-24 17:11:55 <donoban> Ariadne: didn't you say that not all packages are yet rebuildled?
2021-09-24 17:12:04 <Ariadne> libssh is held back because curl
2021-09-24 17:12:11 <donoban> ahh
2021-09-24 17:12:13 <donoban> ok 
2021-09-24 17:12:46 <donoban> well so switching it to ssl3 remmina works fine (to who it worked before :) )
2021-09-24 17:12:51 <Ariadne> and yes if you wind up with both openssl 1.1 and 3 in same process weird shit is gonna happen :)
2021-09-24 17:13:13 <donoban> yeah I was just worried about not getting properply updated packages
2021-09-24 17:13:19 <donoban> but all seems fine
2021-09-24 17:19:55 <ddevault> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10048
2021-09-24 17:19:59 <ddevault> actually the post-install doesn't work either
2021-09-24 17:20:01 <ddevault> the fuck
2021-09-24 17:20:32 <Ariadne> hmm i can try to reproduce it this weekend
2021-09-24 17:20:43 <Ariadne> the apkbuild is legit
2021-09-24 17:21:00 <ddevault> I can't roll this package out until 3.15 anyway
2021-09-24 17:21:04 <ddevault> depends on doas.d
2021-09-24 17:21:38 <ddevault> all of the other files have the correct ownership
2021-09-24 17:27:48 <Hello71> Habbie: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13022
2021-09-24 17:29:54 <Habbie> Hello71, thanks, i managed :)
2021-09-24 17:39:41 <Ariadne> we should cut a new image i guess :)
2021-09-24 17:40:29 <Habbie> yes please :)
2021-09-24 17:40:30 <ikke> for what?
2021-09-24 17:40:36 <Habbie> lazy docker users like me would love that
2021-09-24 17:40:41 <ikke> ah, docker
2021-09-24 17:40:44 <Habbie> i assumed docker
2021-09-24 17:40:47 <Habbie> because that's what i want ;)
2021-09-24 18:08:42 <Hello71> it won't directly fix it, you'll still need to apk add ca-certificates-bundle
2021-09-24 18:09:12 <Hello71> i'm thinking that ssl_client install_if doesn't really make sense
2021-09-24 19:39:46 <aidan55[m]> <ncopa> "i think this broke it 0f2323f228..." <- Hey bro could you please add "is_official_build" flag to Chromium APKBUILD ?? Clang is great.... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/XmpNHtWGsEHxaiyZtwZVyLVT)
2021-09-24 19:40:35 <aidan55[m]> * Hey bro could you please add "is_official_build" flag to Chromium APKBUILD ?? Clang is great.... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/YajswvtJmWSyBzQcpFsGnfSE)
2021-09-24 19:46:06 <Hello71> ffs
2021-09-24 19:47:20 <psykose> ff surgery
2021-09-24 19:53:46 <aidan55[m]> <Hello71> "ffs" <- Firefox ? Firefox sucks in case of security and privacy.
2021-09-24 19:54:03 <Hello71> *plonk*
2021-09-24 19:54:09 <aidan55[m]> Even mozilla websites use Google Analytics 😂
2021-09-24 19:55:12 <aidan55[m]> Oh you meant ffs. I thought you typed ff.
2021-09-24 19:56:12 <aidan55[m]> Hello71: Btw this is what a Chromium developer said. is_build_official is necessary for security !
2021-09-24 20:54:03 <eris[m]> 'insecure mess'
2021-09-24 20:54:28 <eris[m]> ..because it doesnt have one flag?
2021-09-24 20:54:53 <eris[m]> well
2021-09-24 20:54:59 <eris[m]> it doesnt use cfi
2021-09-24 20:55:16 <eris[m]> what makes not having cfi an insecure mess
2021-09-24 20:55:33 <eris[m]> does seL4 have CFI?
2021-09-24 20:55:41 <dalias> :)
2021-09-24 20:56:13 <dalias> i'm not clear how hardening the C calls helps anyway when all the vulns are in the awful jit..
2021-09-24 20:56:45 <eris[m]> cool it does
2021-09-24 20:56:46 <eris[m]> and yea
2021-09-24 20:56:49 <eris[m]> like
2021-09-24 20:59:03 <ericonr> supposedly CFI helps protect against virtual tables being highjacked
2021-09-24 20:59:45 <eris[m]> will it protect my physical tables?
2021-09-24 21:00:14 <dalias> why would seL4 have CFI?
2021-09-24 21:00:19 <eris[m]> it does
2021-09-24 21:00:22 <dalias> i mean why
2021-09-24 21:00:32 <eris[m]> security or some shit
2021-09-24 21:00:32 <dalias> it's just gratuitous if you've already proven correctness
2021-09-24 21:00:38 <eris[m]> yea
2021-09-24 21:00:59 <dalias> all CFI can do is put some impediment to exploiting UB
2021-09-24 21:01:04 <dalias> but they proved it didnt have UB
2021-09-24 21:01:50 <eris[m]> i dont really care about security
2021-09-24 21:02:20 <eris[m]> but im not a linux distro developer :p
2021-09-24 21:04:42 <dalias> i care about security but not about checking boxes
2021-09-24 21:05:01 <dalias> and CFI on a proven-correct program is box-checking
2021-09-24 21:05:39 <Ariadne> i'm interested in building alpine packages with CFI, but that's because we haven't proven any of these packages are free of UB :P
2021-09-24 21:06:02 <Ariadne> if you've formally proven a program to be correct, then you don't really need it
2021-09-24 21:06:59 <Ariadne> 
ACTION wonders why we don't just make `ca-certificates-bundle` part of `alpine-base`

2021-09-24 21:09:08 <dalias> *nod*
2021-09-24 21:09:20 <dalias> i guess. .. maybe you can use alpine offline without it?
2021-09-24 21:10:31 <skarnet> I think it's a granularity problem
2021-09-24 21:10:44 <skarnet> 'base' and 'not base' are too broad categories
2021-09-24 21:11:10 <skarnet> there's room for a 'kind-of-base-but-a-little-extended-with-common-functionality' set of packages
2021-09-24 21:14:31 <dalias> imo base should be the things you need to complete install and boot
2021-09-24 21:14:42 <dalias> and maybe not even boot in case it's a container :-p
2021-09-24 21:16:19 <Hello71> arch removed linux from "base" a few years ago (as part of its migration from group to metapackage)
2021-09-24 21:16:27 <dalias> :)
2021-09-24 21:17:20 <mps> heh, https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1281061-sifive-hifive-unmatched-hands-on-initial-risc-v-performance-benchmarks#post1281083
2021-09-24 21:17:28 <mps> alpine
2021-09-24 21:22:35 <Hello71> i think the best technical definition of alpine-base (and similar concepts in other distros) is that it is implicitly included in all distro package "depends". you're allowed to uninstall it if you want, but then you're on the hook for figuring out which packages implicitly require which parts. it should work the same as alpine-sdk (i assume based on arch base-devel) which is
2021-09-24 21:22:38 <Hello71> implicitly included in all distro package "makedepends". for the related concept of "packages which are not strictly necessary but are 'nice-to-have'", i think we could put them in default /etc/apk/world. imo ca-certificates-bundle falls in this category, since you can technically use apk with non-https mirrors
2021-09-25 00:51:24 <omni> I think I bumped into some bubbplewrap related issues the other day https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25621
2021-09-25 00:51:42 <omni> I'm not gonna work on this right now, but please comment if you have any
2021-09-25 05:59:55 <ikke> omni: bubblewrap does not work in docker without extra privileges
2021-09-25 08:05:19 <ddevault> Ariadne: I don't think your openssl revert for apk-tools was built and sent to the mirrors
2021-09-25 08:06:35 <Ariadne> hmm, i saw it build in #alpine-commits but there is another change we need to make
2021-09-25 08:06:55 <Ariadne> it turns out ca-certificates-bundle was being pulled in as side effect not directly
2021-09-25 08:08:59 <ikke> ahuh
2021-09-25 08:31:45 <Ariadne> which is now done
2021-09-25 08:33:25 <ikke> apk upgrade now succeeds for me in alpine:edge
2021-09-25 10:06:28 <donoban> Cogitri[m]: I looked in the source code of gnome-keyring-daemon and the error ": couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status" seems related with 'pkcs11/wrap-layer/gkm-wrap-prompt.c' but the daemon is running with '--components=secrets' (so could it handle pkcs11?)
2021-09-25 10:06:51 <donoban> if you have different error I can try to debug it
2021-09-25 10:08:04 <donoban> uhM, maybe my problem is starting the desktop with autologin/tinydm, since there is no password prompt maybe it can't unlock the keyring
2021-09-25 10:12:07 <Cogitri[m]> Yes, I think that’s required
2021-09-25 10:12:47 <donoban> but do you have problems with other session manager?
2021-09-25 10:13:36 <Cogitri[m]> Even with GDM it doesn’t unlock when I login via my password
2021-09-25 10:14:59 <donoban> ok I will test it, but I prefer to use the simplified version on !25178
2021-09-25 10:15:21 <omni> ikke: ah, at all, thanks
2021-09-25 10:22:02 <aidan55[m]> <eris[m]> "..because it doesnt have one..." <- No, because its base is an older version of chromium !
2021-09-25 10:22:23 <aidan55[m]> Known vulnerabilities that are not fixed in UGC !!
2021-09-25 10:24:21 <mps> aidan55[m]: to repeat, it is really bad to use quotes from matrix here
2021-09-25 10:25:10 <aidan55[m]> mps: I didn't. I just Replied.
2021-09-25 10:25:25 <mps> yes, you did
2021-09-25 10:25:28 <donoban> "Gnome Keyring authentication module retrieves password obtained by previous module in PAM stack and stores it for later use. When no password was obtained this module does nothing and returns success." so having pam_keyring* entries on autologin is nosense...
2021-09-25 10:26:23 <aidan55[m]> 
ACTION uploaded an image: (46KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/qHUEglETAYwmOQeCibTezhuY/Screenshot_20210925-135557_SchildiChat.jpg >

2021-09-25 10:26:26 <aidan55[m]> Reply.
2021-09-25 10:26:40 <mps> ' aidan55[m]| <eris[m]> "..because it doesnt have one..." <- No, because its base is an older version of chromium !'
2021-09-25 10:26:58 <ikke> irc does not have replies
2021-09-25 10:27:10 <mps> that is what we see here
2021-09-25 10:27:47 <mps> could we disable matrix gateway here
2021-09-25 10:32:37 <ikke> no
2021-09-25 10:34:15 <aidan55[m]> mps, no!
2021-09-25 10:35:23 <skarnet> nobody spoke up, I think you can do it
2021-09-25 10:35:29 <skarnet> >:)
2021-09-25 10:38:04 <mps> that is 'theme' for discussion, ofc. to force people to learn about irc.
2021-09-25 10:38:30 <mps> 'when you are in Rome speak as Roman'
2021-09-25 10:38:54 <ikke> Most matrix users here know that they are on IRC and behave accordingly. It's mostly new people who are not aware, and we ask them politely to not use these features
2021-09-25 10:39:08 <skarnet> you can't force people to do anything. You can *wish they would* use IRC, but you can't enforce it on them - when given an ultimatum, most people will reject it and choose to leave.
2021-09-25 10:39:41 <mps> this is best option for lazy ones, to leave
2021-09-25 10:40:27 <skarnet> a high barrier of entry is more a BSD mindset than a Linux one. :P
2021-09-25 10:40:40 <mps> right
2021-09-25 10:40:52 <mps> because that I like BSD
2021-09-25 10:41:09 <skarnet> and clearly BSD has taken over the world
2021-09-25 10:41:23 <mps> also linux :D
2021-09-25 10:41:27 <skarnet> exactly
2021-09-25 10:41:41 <skarnet> in order for a project to be successful, you need to make it *easy* for people to contribute
2021-09-25 10:41:41 <ikke> We're not a community of gatekeepers
2021-09-25 10:42:07 <skarnet> ^
2021-09-25 10:43:03 <mps> easy and correct can go together very nice
2021-09-25 10:43:30 <andypost[m]> It's mostly impossible to convince people to use dated apps (IRC client is hard to find for phone and not screw your eyes)
2021-09-25 10:44:35 <mps> andypost[m]: and you (and not only you) managed to use matrix quite properly in irc
2021-09-25 10:44:49 <ikke> so the issue is not the matrix gateway
2021-09-25 10:44:59 <mps> I'm talking about those who refuses to learn
2021-09-25 10:45:26 <andypost[m]> Basically the issue in replies and quotes
2021-09-25 10:45:35 <mps> ikke: ofc, this was provocation question
2021-09-25 10:46:39 <mps> andypost[m]: and long messages with url
2021-09-25 10:46:57 <ikke> That's mostly multi-line messages
2021-09-25 10:47:05 <mps> yes
2021-09-25 10:47:56 <mps> but iirc irc 'CoC' is realy short, van be read in less than 5 minutes
2021-09-25 10:48:08 <mps> s/van/can/
2021-09-25 10:48:25 <andypost[m]> I recall multi-line messages was issue in 90s so it's not matrix
2021-09-25 10:49:09 <mps> they were and they still are
2021-09-25 13:56:36 <Ariadne> our CoC is basically "don't be a dick"
2021-09-25 13:59:06 <Ariadne> its primary utility is continuing to exist, as projects of alpine's size and stature are expected to have one in 2021
2021-09-25 13:59:33 <Ariadne> some entities sponsoring alpine with hardware, or individual devs, or whatever, also expect a CoC to exist
2021-09-25 13:59:39 <Ariadne> thats basically the point of it
2021-09-25 13:59:59 <Ariadne> the specific concerns which lead to its creation have long since passed :P
2021-09-25 14:03:19 <mps> my 'CoC' is 'use common sense and be kind' (with a little humor)
2021-09-25 14:04:39 <mps> but looks like this become also problematic
2021-09-25 14:07:25 <Ariadne> humor is fine, as long as we aren't punching each other :)
2021-09-25 14:09:17 <mps> as I see the 'problem' is in that we are form different cultures and have different 'sense' of humor
2021-09-25 14:10:09 <mps> what is simple innocent joke for me could offend someone and vice versa
2021-09-25 14:10:29 <psykose> a tale as old as time
2021-09-25 14:10:50 <mps> also languages, most of us are not native english speakers
2021-09-25 14:15:43 <dalias> re: matrix i think we should politely engage whoever runs the gateway over making it behave right with irc
2021-09-25 14:16:04 <dalias> for example stripping the quoted text in replies and replacing it by "nick: " of the person being replied to
2021-09-25 14:16:20 <psykose> replies are fine, it's just a normal message with more context and helpful 90% of the time
2021-09-25 14:16:28 <dalias> but it's not visible on irc
2021-09-25 14:16:28 <psykose> only issues are when it converts to a text link
2021-09-25 14:16:40 <psykose> the slight context in the reply helps to see what the response is to
2021-09-25 14:16:41 <dalias> the quoted replied-to text takes up the entire irc line
2021-09-25 14:16:49 <dalias> and the reply is in the out-of-band link
2021-09-25 14:17:11 <psykose> not usually, the reply quote is like ~35 characters
2021-09-25 14:17:12 <mps> I had to write regex replace in irssi for messages from gitter
2021-09-25 14:17:15 <dalias> it also doesn't help that the out-of-band link is huge and takes up half the line buffer
2021-09-25 14:17:52 <dalias> psykose, this happened repeatedly yesterday. i thought it was a bug in the bridge because i kept seeing the same exact message except different matrix links
2021-09-25 14:17:59 <dalias> but it was the same-quoted text with no reply visible
2021-09-25 14:18:02 <mps> psykose: quote in replies are ugly, at least
2021-09-25 14:18:05 <psykose> yes, but that's what happens when it's too long
2021-09-25 14:18:12 <psykose> i mean for short ones it's perfectly fine
2021-09-25 14:18:13 <dalias> that's what should be fixed
2021-09-25 14:18:18 <psykose> yes, agree there
2021-09-25 14:18:20 <Ariadne> why do you care
2021-09-25 14:18:21 <dalias> the way you reply in irc is like this
2021-09-25 14:18:24 <dalias> <psykose> yes, agree there
2021-09-25 14:18:25 <dalias> yep
2021-09-25 14:18:31 <dalias> 2 lines, first one quoting the user
2021-09-25 14:18:45 <dalias> and the gateway could send that
2021-09-25 14:19:10 <dalias> it could also avoid reserving like 100+ bytes for the out-of-band url and instead using a link shortener
2021-09-25 14:19:17 <dalias> or even better, just split long messages to multiple lines
2021-09-25 14:19:39 <dalias> a few small changes would make this work really seemlessly
2021-09-25 14:19:50 <mps> though I usually ignore msgs with quotes, so not big issue for me, except they are still ugly
2021-09-25 14:19:54 <psykose> also, edits should not repaste the same entire message
2021-09-25 14:20:00 <dalias> yes
2021-09-25 14:20:27 <dalias> rather than requiring getting every matrix user to figure out weird rules they need to follow to be understandable by folks on irc
2021-09-25 14:20:38 <Ariadne> hmm
2021-09-25 14:20:41 <psykose> yeah, it's hardly the users fault at all
2021-09-25 14:20:49 <dalias> exactly -- i'm not blaming the users
2021-09-25 14:21:00 <Ariadne> this community/nerd-fonts thing is concerning
2021-09-25 14:21:01 <dalias> i'm blaming the bridge
2021-09-25 14:21:07 <psykose> Ariadne: what's up
2021-09-25 14:21:25 <Ariadne> are these fonts under an appropriate license
2021-09-25 14:22:11 <psykose> that is some effort to fully audit
2021-09-25 14:22:14 <psykose> there is so many fonts in there
2021-09-25 14:22:17 <dalias> :/
2021-09-25 14:22:17 <mps> anyone have issues with some of latest ncurses upgrades
2021-09-25 14:22:32 <psykose> the patches are MIT, someone has to go over the entire list of base fonts though
2021-09-25 14:23:07 <Ariadne> yes, my concern is the base fonts
2021-09-25 14:23:23 <Ariadne> patching them with an MIT patch does not change the original license
2021-09-25 14:23:41 <dalias> are the fonts shipped as part of the package? the description doesn't make that clear
2021-09-25 14:23:49 <Ariadne> yes
2021-09-25 14:23:54 <dalias> they should probably be obtained out-of-band if there are license concerns
2021-09-25 14:24:02 <dalias> and patched locally
2021-09-25 14:24:09 <psykose> most of them are probably OFL
2021-09-25 14:25:05 <Ariadne> i just don't know
2021-09-25 14:25:10 <psykose> one of the first on the list seems to be bsd-3 https://github.com/rbanffy/3270font/blob/main/LICENSE.txt
2021-09-25 14:25:15 <psykose> it's probably a soup of licences in the end
2021-09-25 14:25:22 <Ariadne> i think it needs to be audited
2021-09-25 14:25:23 <ikke> There are license files per font
2021-09-25 14:25:27 <Ariadne> ^
2021-09-25 14:25:28 <ikke> https://github.com/ryanoasis/nerd-fonts/tree/master/src/unpatched-fonts
2021-09-25 14:25:31 <psykose> mhm
2021-09-25 14:26:03 <Ariadne> some of those fonts are made by companies
2021-09-25 14:26:19 <Ariadne> and, companies have lawyers
2021-09-25 14:26:31 <Ariadne> and i think we should try to not piss off said lawyers :P
2021-09-25 14:26:43 <psykose> almost every distro has a similar nerd-fonts package somewhere
2021-09-25 14:26:48 <psykose> i wonder what the others do
2021-09-25 14:27:12 <ikke> Some seem to use the Open Font License
2021-09-25 14:27:33 <Ariadne> psykose: probably limit what they redistribute
2021-09-25 14:28:10 <dalias> i'm confused what the point of nerd-fonts is
2021-09-25 14:28:18 <dalias> why would you patch fonts to add glyphs from other fonts???
2021-09-25 14:28:44 <dalias> fallback rendering for characters not covered in the chosen font is baseline functionality for text rendering for like the past 2 decades
2021-09-25 14:29:53 <Ariadne> fancy emojis for terminals i guess
2021-09-25 14:30:38 <dalias> because the terminal lacks its own text rendering support? :/
2021-09-25 14:31:11 <Ariadne> well you know how people have .bashrc and stuff that creates fancy PS1s now
2021-09-25 14:31:22 <Ariadne> i presume the fonts are related to that
2021-09-25 14:31:46 <Ariadne> i'm not saying "learn how to use fontconfig properly" isn't the right way to solve this :P
2021-09-25 14:31:53 <ikke> https://github.com/ryanoasis/nerd-fonts/wiki#why
2021-09-25 14:33:24 <dalias> :-p
2021-09-25 14:33:55 <dalias> fontconfig is awful too :-p
2021-09-25 14:34:10 <dalias> i kinda want to make a fork or alt implementation of fontconfig with no xml dsl in it
2021-09-25 14:34:30 <ikke> lol
2021-09-25 14:35:01 <dalias> there's no reason every program that needs to display text needs to be loading some giant xml monstrosity
2021-09-25 14:35:13 <dalias> and the language is unusably bad
2021-09-25 14:37:21 <mps> I use symbola (non free for distro) fonts for 'emoji' on terminal
2021-09-25 14:48:02 <Hello71> > almost all distros
2021-09-25 14:48:08 <Hello71> > fonts:nerd-fonts Spr: 8
2021-09-25 14:48:11 <Hello71> https://repology.org/projects/?search=nerd-fonts&maintainer=&category=&inrepo=&notinrepo=&repos=&families=&repos_newest=&families_newest=
2021-09-25 19:31:02 <tomalok> gitlab.com shared builders appear to have broken a couple days ago?
2021-09-25 19:31:07 <tomalok> #9 0.507 + apk add build-base cmake cmocka-dev git libffi-dev libunwind-dev openssl-dev perl zlib-dev
2021-09-25 19:31:07 <tomalok> ERROR: Job failed: execution took longer than 3h0m0s seconds
2021-09-25 19:31:07 <tomalok> #9 0.517 fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
2021-09-25 19:58:03 <ikke> There are still jobs succeeding, so they're not generally broke
2021-09-25 19:58:20 <ikke> tomalok: do you have a link?
2021-09-25 21:38:55 <mps> ikke: yes, tzdata should be backported
2021-09-25 21:40:03 <mps> hope andypost[m] will do this, I'm too tired now.
2021-09-25 21:40:23 <mps> or if none do this  I will do tomorrow
2021-09-25 21:40:52 <ikke> I understand there are some 'interesting' tz changes
2021-09-25 21:42:15 <mps> what to say, there are always some 'strange' changes
2021-09-25 21:42:28 <Hello71> dalias: <?xml version="1.0"?><!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"><fontconfig><edit name="message" mode="assign_replace" binding="strong"><string><![CDATA[I love fontconfig!]]></string></edit></fontconfig>
2021-09-25 21:43:36 <mps> bureaucrats in different country likes to make strange changes in tz data
2021-09-25 21:52:05 <danieli> god, i hate xml
2021-09-25 21:53:17 <mps> you are not alone
2021-09-25 22:09:55 <tomalok> ikke: https://gitlab.com/jakesys/aws2/-/pipelines - seems to have been able to build once-ish after they bumped up the runner version, and it all times out since then...
2021-09-26 06:12:22 <ikke> tomalok: oh, gitlab.com, not gitlab.alpinelinux.org
2021-09-26 06:14:15 <ikke> tomalok: You mean that it's timing out on fetching from dl-cdn?
2021-09-26 06:54:55 <mps> ikke: does it looks ok !25757
2021-09-26 06:55:28 <mps> I mean, proper branch and proper 'git branch'
2021-09-26 06:55:49 <mps> and good morning
2021-09-26 06:55:57 <ikke> yes, looks fine to me
2021-09-26 06:55:59 <ikke> good morning
2021-09-26 06:56:51 <mps> thanks, rest will be done after coffee
2021-09-26 10:29:45 <adhawkins> Is there a way in an APKBUILD file to specify that a dependency just be at least a specific version?
2021-09-26 10:29:51 <adhawkins> s/just/must/
2021-09-26 10:30:38 <ikke> adhawkins: yes, but what do you do if that version is not available?
2021-09-26 10:37:34 <adhawkins> I guess the package should fail to iunstall?
2021-09-26 10:37:46 <adhawkins> In practice it shoukdnt happen, as I maintain both.
2021-09-26 10:38:12 <adhawkins> Dunno what happened to my typing there!
2021-09-26 10:39:08 <ikke> You can add dependencies like foo>x.y
2021-09-26 10:39:31 <adhawkins> Great, thanks ikke. Will look into it.
2021-09-26 10:41:49 <adhawkins> So just 'emborg>=1.27'?
2021-09-26 10:42:02 <adhawkins> Are spaces preferred around the '>='?
2021-09-26 10:45:50 <ikke> They are attached
2021-09-26 11:29:09 <JeSCaLis23-F> 
ACTION https://ilanekle.net

2021-09-26 11:32:16 <mps> spam ^
2021-09-26 15:15:45 <ikke> openssh 8.8 has been released
2021-09-26 15:54:57 <tomalok> ikke: yeah it appears that gitlab.com fetching from dl-cdn is always timing out.  the build is being done with docker-in-docker, and had been working fine for months until a few days ago.
2021-09-26 15:55:19 <ikke> tomalok: strange
2021-09-26 15:56:04 <tomalok> seems to be around the time that they bumped up the version on the runner and server
2021-09-26 15:56:31 <tomalok> but it completed once with the new one before breaking
2021-09-26 15:56:32 <ikke> Did you try a different mirror?
2021-09-26 15:58:50 <tomalok> i had to task switch away from that to work on other stuff... and avoid some frustration.  it's not critical at the moment -- will try a slimmed down less complicated build and fiddle around with knobs and buttons and mirrors at some poiint
2021-09-26 15:59:13 <ikke> Ok, I'm curious what is causing this
2021-09-26 15:59:48 <tomalok> what i'd like to accomplish today is to get an end-to-end alpine-cloud-images functional (but not necessarily producing working images yet)
2021-09-26 16:01:49 <tomalok> (so i can get some eyes on it to tell me where i've gone horribly wrong... ;) )
2021-09-26 16:37:46 <ikke> in ~20 minutes I will upgrade gitlab
2021-09-26 16:48:19 <maxice8> ok
2021-09-26 16:58:41 <skarnet> So apparently gitlab is going down for maintenance in 2 minutes >.>
2021-09-26 16:58:57 <ikke> yes
2021-09-26 16:59:08 <skarnet> just at the time I was pushing my big update XD
2021-09-26 16:59:39 <skarnet> so when it's back up, and after my pipeline has finished verifying it builds, can someone please take a look at !25678 ? :)
2021-09-26 17:00:15 <skarnet> algitbot has already gone to sleep, it looks like
2021-09-26 17:00:25 <ikke> apparently, and I did not do anything yet :P
2021-09-26 17:00:47 <skarnet> guess the reboot is warranted XD
2021-09-26 17:07:31 <ikke> skarnet: gitlab is up again
2021-09-26 17:10:01 <skarnet> thanks!
2021-09-26 17:10:10 <skarnet> got something to fix already, will start the pipeline again afterwards
2021-09-26 17:11:43 <Hello71> i guess you mean !25768
2021-09-26 17:12:55 <ikke> w00t
2021-09-26 17:12:58 <ikke> hmm
2021-09-26 17:13:04 <skarnet> yeah, that's my dxsleyia.
2021-09-26 17:14:56 <ikke> !25768
2021-09-26 17:15:09 <skarnet> wb algitbot \o/
2021-09-26 17:16:53 <maxice8> remote: GitLab: Internal API unreachable
2021-09-26 17:17:08 <ikke> maxice8: when doing what?
2021-09-26 17:17:15 <maxice8> git push origin -v
2021-09-26 17:17:36 <maxice8> also happens when pushing one commit to upstream/master
2021-09-26 17:20:19 <mps> ! [remote rejected]       master -> master (pre-receive hook declined)
2021-09-26 17:20:31 <mps> error: failed to push some refs to 'gitlab.alpinelinux.org:alpine/aports.git'
2021-09-26 17:20:54 <mps> also for me
2021-09-26 17:23:16 <ikke> hmm
2021-09-26 17:23:29 <skarnet> same
2021-09-26 17:27:46 <ikke> Only happens when pushing or also when fetching?
2021-09-26 17:28:11 <maxice8> only pushing
2021-09-26 17:28:13 <mps> push only
2021-09-26 17:34:23 <ikke> ok, fixed
2021-09-26 17:36:25 <ikke> \o/
2021-09-26 17:36:27 <mps> yes, thanks
2021-09-26 17:36:32 <ikke> I just saw you pushing :P
2021-09-26 17:42:51 <maxice8> new GitLab UI feels uncanny 
2021-09-26 17:42:55 <ikke> how so?
2021-09-26 17:43:07 <ikke> I must say that I've alreayd had time to get used to it
2021-09-26 17:43:41 <ikke> I assume you mean the top menu / side menu?
2021-09-26 17:44:29 <maxice8> https://imgur.com/a/W30IlCD 
2021-09-26 17:45:27 <ikke> I always have the left side-menu collapsed
2021-09-26 17:46:48 <skarnet> ok, please merge !25768 if the pipeline builds (which it should)
2021-09-26 17:47:09 <ikke> skarnet: I'm looking at it now
2021-09-26 17:47:18 <skarnet> thanks
2021-09-26 17:47:42 <skarnet> I had to force push to change a bad commit, which confused it for a moment, but it's all fixed now
2021-09-26 17:47:52 <skarnet> good automation recovery there
2021-09-26 17:48:38 <maxice8> Set it to auto-merge if pipeline succeeds 
2021-09-26 17:48:51 <ikke> 👍
2021-09-26 17:49:45 <maxice8> will need to do another pipeline since someone (me) pushed stuff
2021-09-26 17:50:06 <ikke> maxice8: just push it immedately after the previous pipeline succeeded
2021-09-26 17:50:28 <skarnet> maxice8: I don't have the rights to do that, which is why I'm asking here :)
2021-09-26 17:50:40 <ikke> skarnet: maxice meanth they did it
2021-09-26 17:50:46 <skarnet> ah yes
2021-09-26 17:50:57 <maxice8> would be nice to have per-maintainer rights
2021-09-26 17:51:24 <skarnet> not sure about that, you don't want a maintainer to push crap and break the builds of everything that depends on their stuff
2021-09-26 17:51:50 <ikke> Ideally you would have at least some review of every commit
2021-09-26 17:52:15 <skarnet> what is this "review" thing you speak of
2021-09-26 17:52:33 <ikke> s6-rc-0.5.2.3.tar.gz: FAILED
2021-09-26 17:52:35 <ikke> sha512sum: WARNING: 1 of 1 computed checksums did NOT match
2021-09-26 17:53:13 <skarnet> I updated the checksum ffs
2021-09-26 17:53:41 <skarnet> ah I know
2021-09-26 17:53:58 <skarnet> can you delete the current .tar.gz from the builder's distfiles?
2021-09-26 17:54:02 <skarnet> that's the wrong one
2021-09-26 17:55:02 <ikke> if it has not been pushed to the builders yet, it's not in distfiles
2021-09-26 17:55:29 <ikke> It's only the builders that use distfiles, CI does not
2021-09-26 17:55:30 <skarnet> not the builder, the CI thing that runs the pipelines
2021-09-26 17:55:47 <skarnet> it has to download the tarball somewhere to compute the checksum
2021-09-26 17:55:50 <ikke> It does not cache the source archives
2021-09-26 17:56:07 <skarnet> hm
2021-09-26 17:56:15 <skarnet> let me check but I'm sure my checksum is correct
2021-09-26 17:57:39 <ikke> It fails for me locally as well
2021-09-26 17:57:56 <ikke> https://tpaste.us/5n57 
2021-09-26 17:58:12 <skarnet> idgi, I did commit the new checksum but I still have the wrong one
2021-09-26 17:58:19 <skarnet> pushing the correct one this time
2021-09-26 17:58:24 <skarnet> sorry
2021-09-26 17:58:30 <ikke> skarnet: probably your local distfiles
2021-09-26 17:58:41 <skarnet> no I explicitly rm'd them
2021-09-26 17:58:43 <ikke> hmm
2021-09-26 17:59:40 <skarnet> anyway, new commit fixing the checksum pushed to the MR
2021-09-26 18:00:25 <ikke> btw, there is a setting in gitlab ci where you can say that it can interrupt running jobs when it becomes obsolete
2021-09-26 18:00:35 <smcavoy> hello, I am trying to update Ansible to the latest release. This requires the existing package to to be updated (!25638) and a new packge (!25443). I am wondering if it is ok to submit ansible-core to community/ as it is a requirement for ansible which is already in community/
2021-09-26 18:00:51 <skarnet> why do I need to click rebase 5 times before it's accepted?
2021-09-26 18:01:06 <ikke> skarnet: you just need to have patiences (eventual consistency :D)
2021-09-26 18:01:11 <maxice8> GitLab is special, I just use 'glab'
2021-09-26 18:01:12 <ikke> patience*
2021-09-26 18:01:28 <skarnet> I'm ok with waiting while the button is grey and spinning
2021-09-26 18:01:41 <skarnet> if the button becomes clickable again I'm gonna assume something didn't work
2021-09-26 18:02:45 <ikke> Just wait until the pipeline is green, then I rebase and merge immediately
2021-09-26 18:11:13 <ikke> skarnet: merged
2021-09-26 18:12:34 <skarnet> fantastic, thanks!
2021-09-26 18:12:49 <skarnet> did my browser just not update or did you merge before the pipeline finished?
2021-09-26 18:12:59 <ikke> It was finished for me
2021-09-26 18:13:10 <ikke> https://gitlab.alpinelinux.org/skarnet/aports/-/pipelines/94719
2021-09-26 18:13:24 <ikke> Maybe you saw the new pipeline after the rebase?
2021-09-26 18:13:25 <skarnet> cool
2021-09-26 18:13:33 <skarnet> yeah that's what I saw
2021-09-26 19:06:48 <ikke> smcavoy: sorry, wanted to answer you but got distracted
2021-09-26 19:07:05 <ikke> yes, as a new dependency you can add a package directly to community
2021-09-26 19:08:51 <minimal> linux-rpi depends on linux-firmware-brcm and linux-firmware-cypress - which is great except if you're *not* using the RPI's Wifi and Bluetooth and in the past were installing linux-firmware-none to avoid firmware packages being installed - now those 2 are installed regardless. Not a big issue (18MB installed) but wondering if there's a way to fix/avoid this...
2021-09-26 19:09:33 <smcavoy> ikke: thanks
2021-09-26 19:09:44 <minimal> wondering if perhaps the RPI images should have those 2 packages installed and then the explicit dependancies could be removed
2021-09-26 19:23:56 <JuniorJPDJ> hey donoban! are you still maintaining telegram-desktop? I could take it and maintain it as I use it frequently and I see it's not getting much updates on alpine
2021-09-26 19:29:48 <smcavoy> ikke: I closed/opened a new one for core in community: !25772
2021-09-26 19:32:34 <ikke> smcavoy: please split the commit into 2, one for each package
2021-09-26 19:54:02 <smcavoy> ikke: one for the move of py3-resolvelib and one for ansible-core, in the same mr?
2021-09-26 19:54:15 <ikke> correct
2021-09-26 19:55:23 <ikke> And you say "updated ansible", which I don't see being done
2021-09-26 19:55:50 <smcavoy> that was in !25638
2021-09-26 19:57:14 <ikke> aha, ok
2021-09-26 19:57:29 <ikke> You can combine that in a single MR
2021-09-26 19:58:42 <smcavoy> OK, 1 mr, 3 commits
2021-09-26 19:59:25 <ikke> 👍
2021-09-26 19:59:50 <Habbie> oh, the luajit port was switched to openresty, i should see if i can open up pdns&co again for arm64
2021-09-26 20:00:29 <ikke> right
2021-09-26 20:00:43 <Habbie> smcavoy, hey, ltns, unless many people share your name :)
2021-09-26 20:11:39 <smcavoy> Habbie, not sure how many ;) hello!
2021-09-26 20:11:59 <Habbie> hello!
2021-09-26 20:13:21 <smcavoy> ikke: all done in !25773
2021-09-26 23:51:52 <maxice8> would be nice if abuild detected and warned if we already depended on a package via its so:
2021-09-26 23:52:08 <maxice8> like it warns to remove an aport from depends_dev if we depend on its pc:
2021-09-27 05:43:41 <ikke> tomalok: https://github.com/gliderlabs/docker-alpine/issues/307
2021-09-27 06:44:04 <mps> is something changed with musl writev after 3.14-stable. got this '--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} ---'
2021-09-27 06:45:35 <mps> strace 'writev(1, [{iov_base="Connect    : \33[33mxx.xxxxx.xxx"..., iov_len=44}, {iov_base="\n", iov_len=1}], 2Connect    : xx.xxxx.mycpanel.xx ) = 45'
2021-09-27 06:46:22 <mps> git log in musl doesn't show anything
2021-09-27 07:15:10 <ikke> morning
2021-09-27 07:16:21 <mps> ikke: good morning
2021-09-27 07:31:00 <ddevault> 5d41e2ea8cdc634014b066e4a5594e73b8151464 appears to be causing aborts in some of my automation
2021-09-27 07:31:40 <ddevault> https://forgeperf.org/results/Bitbucket.repo-summary.log
2021-09-27 07:31:42 <ddevault> on alpine 3.14
2021-09-27 07:37:37 <ddevault> looks like this is consistently reproducible on Xvfb
2021-09-27 08:46:22 <ncopa> good morning
2021-09-27 08:46:54 <ncopa> ddevault: chromium if crashing more frequent after the update for me as well. dont know what the issue is
2021-09-27 08:47:38 <ddevault> I started a git clone of the chromium source code around the same time I mentioned the issue
2021-09-27 08:47:42 <ddevault> it seems to be almost done
2021-09-27 08:58:35 <ddevault> getting the source did not provide much in the way of answers
2021-09-27 08:58:47 <ddevault> and there's a zero percent chance of my compiling chromium and attempting to debug it seriously
2021-09-27 08:58:58 <ddevault> so I guess I'll just live with it and hope the problem solves itself in a future update
2021-09-27 09:02:03 <ncopa> in my experience, problems like this does not solve themselves. someone need to spend time on investigate what is going on and provide a fix
2021-09-27 09:02:32 <ncopa> what does help get there is a stable reproducer
2021-09-27 09:02:49 <ncopa> its hopeless without a stable way to reproduce it
2021-09-27 09:12:37 <PureTryOut> Can someone please bump libutempter in main? skalibs has been upgraded and now libutempter fails to install because of depending on the older so version still
2021-09-27 09:14:16 <ddevault> I can reproduce it, but I only use chromium for this one thing and it's not a particularly important thing
2021-09-27 09:21:38 <PureTryOut> Somebody please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/25789
2021-09-27 09:21:44 <PureTryOut> !25789
2021-09-27 09:25:06 <ikke> Hmm, it does not directly depend on skalibs(-dev)
2021-09-27 09:27:14 <PureTryOut> Oh nvm, seems I can merge stuff myself in main now 🤔
2021-09-27 09:27:23 <PureTryOut> ikke: `required by: libutempter-1.2.1-r2[so:libskarnet.so.2.10]`
2021-09-27 09:28:09 <PureTryOut> Acoording to `apk info -a libutempter` it most definitely depends directly on skalibs
2021-09-27 09:28:23 <PureTryOut> I suppose it's pulled in by utmps?
2021-09-27 09:34:31 <ikke> I guess so. Maybe we should it a direct makedepends on skalibs-dev as well
2021-09-27 10:40:26 <skarnet> and that's exactly why I advocate for static linking utmps
2021-09-27 10:41:16 <skarnet> because with dynamic linking, major upgrades (which I try to avoid as much as possible, but sometimes there's no choice) are a bit of a pain with the apk dependency model
2021-09-27 10:41:54 <ikke> It works as long as we know what to upgrade
2021-09-27 10:41:58 <ikke> /rebuild
2021-09-27 10:49:36 <donoban> JuniorJPDJ: I tried to keep it up to date but it's too much time demanding for me (near all upgrades have some new dependency from non-upstream repository... :\ ), if you want to take it let's do it :)
2021-09-27 12:23:06 <Newbyte> Cogitri: what's the status of upgrading to GNOME 41 in Alpine Edge?
2021-09-27 12:36:16 <Cogitri[m]> Newbyte: Haven’t been able to look into it yet, help welcome
2021-09-27 13:12:46 <Habbie> https://gitlab.alpinelinux.org/Habbie/aports/-/jobs/497686
2021-09-27 13:12:56 <Habbie> this MR that updates two ports got cut off at 1 hour of building time on armhf
2021-09-27 13:13:04 <Habbie> would you like me to split it into two MRs?
2021-09-27 13:13:15 <Habbie> the cutoff was halfway through building the second of the two ports, so it should help
2021-09-27 13:18:24 <JuniorJPDJ> donoban: thanks, I'll try to update it and if I success I'll take the package too ;)
2021-09-27 14:54:30 <donoban> ok
2021-09-27 15:51:48 <ddevault> what are the most frustrating packages to develop and maintain
2021-09-27 15:51:54 <ddevault> rust, llvm, chromium, what else?
2021-09-27 15:53:52 <ikke> libreoffice
2021-09-27 15:54:01 <eris[m]> qtwebegine was not well liked by the maintainers of kiss
2021-09-27 15:54:22 <ddevault> oh yeah qt, yikes
2021-09-27 15:54:47 <eris[m]> because it has the associated costs of qt
2021-09-27 15:54:50 <eris[m]> and chromium
2021-09-27 15:55:05 <eris[m]> i remember it being broken for weeks at a time
2021-09-27 15:55:45 <eris[m]> hmm
2021-09-27 15:56:17 <clandmeter> its always somehow broken
2021-09-27 15:56:18 <eris[m]> i cant think of anything else; maybe alpine devs have something specific
2021-09-27 15:56:53 <eris[m]> but those packages should be a pain no matter what distro bcos they suck
2021-09-27 15:56:58 <clandmeter> we could add a frustration flag to aports
2021-09-27 15:56:59 <eris[m]> oh!
2021-09-27 15:57:01 <eris[m]> java
2021-09-27 15:57:09 <ikke> eris[m]: I've heard it improved
2021-09-27 15:57:20 <ericonr> ikke: the trick with LibreOffice is offloading maintenance to arch :D I just copy the version changes from their updates and build my own
2021-09-27 15:57:25 <eris[m]> kiss has yet to get a working java package iirc
2021-09-27 15:57:34 <ikke> ericonr: does that work for musl?
2021-09-27 15:57:47 <eris[m]> you can talk to whoever's attempting that nowadays
2021-09-27 15:58:01 <psykose> firefox and it's derivatives probably aren't fun either
2021-09-27 15:58:08 <ikke> !11136 created one year ago
2021-09-27 15:58:26 <eris[m]> firefox isnt as bad
2021-09-27 15:58:31 <mps> psykose: FF is not to much complicated
2021-09-27 15:58:42 <eris[m]> all you need to do is wrangle the build system a little
2021-09-27 15:59:02 <eris[m]> the biggest complication is autotools, right:
2021-09-27 15:59:21 <mps> no
2021-09-27 15:59:24 <ericonr> ikke: at least the update I had to do was pretty simple. My only issue was with a deprecated class within LibreOffice itself, musl didn't affect things
2021-09-27 15:59:42 <ericonr> Their C/C++ is reasonable-ish
2021-09-27 15:59:58 <mps> ericonr: that's true
2021-09-27 16:00:29 <mps> sometimes I steal some things from arch (and sometimes from void ;) _
2021-09-27 16:01:18 <eris[m]> huh, whats the biggest complication with ff then?
2021-09-27 16:01:34 <mps> rust
2021-09-27 16:01:50 <ddevault> ff is certainly better than chromium
2021-09-27 16:01:57 <ddevault> but it is a big boy with an annoying build system
2021-09-27 16:02:06 <eris[m]> ohhh right
2021-09-27 16:02:07 <eris[m]> rust
2021-09-27 16:02:14 <eris[m]> i was in brief bliss
2021-09-27 16:02:28 <eris[m]> not knowing about rust
2021-09-27 16:03:25 <mps> of all 'big and complicated' pkgs I only care for FF (from time to time) because it is less horible and still needed browser
2021-09-27 16:07:09 <ericonr> Firefox will grudgingly accept compatibility patches, chromium hates you and your entire family line
2021-09-27 16:07:44 <eris[m]> chromium will murder you for even thinking about musl
2021-09-27 16:15:45 <mps> I'm thinking about adding some of current pkgs with less deps, for example firefox-simple, screen-simple ....
2021-09-27 16:16:28 <ddevault> context: I was going to add a hall of shame to a blog post about packaging, but thought better of it
2021-09-27 16:16:39 <ikke> mps: getting rid of all the alsa bagage? :P
2021-09-27 16:17:03 <mps> ikke: you know what I dislike, and it is not alsa ;)
2021-09-27 16:17:13 <ikke> mps: yeah, I'm just teasing you
2021-09-27 16:17:54 <mps> but I'm not sure I will have time to keep them in good shape, so didn't decided yet
2021-09-27 16:18:06 <mps> though I have some on my local build
2021-09-27 16:26:51 <maxice8> community/salt defines an ssh function
2021-09-27 16:26:58 <maxice8> completely broke my script lol
2021-09-27 16:27:06 <ikke> lol
2021-09-27 16:28:18 <ddevault> (the post: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html)
2021-09-27 16:31:17 <skarnet> maxice8: I approved your MR request, but I don't have merging rights so... :P
2021-09-27 16:31:31 <maxice8> no worries I'll just walk through them after I'm done
2021-09-27 16:31:37 <maxice8> community/salt broke my script execution
2021-09-27 16:32:26 <PureTryOut> ddevault: oh nice post! Last week I found out about https://github.com/ankitects/anki/issues/1378#issuecomment-927892171, a project using Bazel to build and is being dropped from repos and outdated everywhere because of it. Fits right in to the "Use widely adopted, standard build systems and methodologies." point
2021-09-27 16:32:42 <ddevault> yeah I'm sure that particular point rings home for many a package developer
2021-09-27 16:33:48 <ikke> ddevault: I assume you have seen the 'things that make package maintainers cry' talk? (forgot the exact title)
2021-09-27 16:33:54 <ddevault> no, but I would like to
2021-09-27 16:34:02 <ikke> Let me try to find it
2021-09-27 16:34:41 <PureTryOut> ddevault: a KDE developer had fun with it as well https://fosstodon.org/@bshah/103939879809533375
2021-09-27 16:34:43 <ikke> mps: do you happen to have the link?
2021-09-27 16:35:06 <ddevault> oh bshah is a friend
2021-09-27 16:35:50 <PureTryOut> There was also a developer of some GNOME app which literally went to chat channels of distributions and said "stop shipping my app, Flatpak is the only way people should get my shit"
2021-09-27 16:36:11 <eris[m]> lmfao
2021-09-27 16:36:15 <ikke> ddevault: https://www.youtube.com/watch?reload=9&v=NSemlYagjIU
2021-09-27 16:36:15 <ddevault> yeah, screw that nonsense
2021-09-27 16:36:23 <ddevault> same folks who wrote "stop themeing my app" and "linux is not about choice"
2021-09-27 16:36:51 <PureTryOut> As a result, a completely alternative to that application was made by the distribution maintainers (MartijnBraam) in this case and is now shipped everywhere instead
2021-09-27 16:37:00 <maxice8> ikke: that was the video I was looking for
2021-09-27 16:37:01 <ddevault> thanks ikke 
2021-09-27 16:37:03 <PureTryOut> Yup
2021-09-27 16:37:40 <psykose> PureTryOut: which app and replacement was it specifically?
2021-09-27 16:38:08 <ikke> what's up with gnome-builder?
2021-09-27 16:38:19 <martijnbraam> psykose: gnome-authenticator
2021-09-27 16:38:23 <PureTryOut> I don't recall the original app, MartijnBraam probably does, but the replacement is numberstation
2021-09-27 16:38:24 <martijnbraam> replaced by numberstation
2021-09-27 16:38:27 <maxice8> some test is failing I need to look at it
2021-09-27 16:38:42 <martijnbraam> because the gnome devs were more focussed at playing around with gtk4 and flatpak instead of making the app function
2021-09-27 16:38:53 <mps> ikke: link? about what?
2021-09-27 16:39:00 <ikke> mps: that talk
2021-09-27 16:39:02 <ikke> I just found it
2021-09-27 16:39:11 <ikke> "How to make package managers cry"
2021-09-27 16:39:21 <mps> ah, how to make devs cry :)
2021-09-27 16:40:02 <mps> https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2021-09-27 16:40:25 <ddevault> aha, better link
2021-09-27 17:02:26 <Newbyte> PureTryOut (matrix.org): by "everywhere" you mean Alpine Linux?
2021-09-27 17:08:00 <martijnbraam> all the pinephone distros, which indirectly adds it to a few of the major distros
2021-09-27 17:09:15 <martijnbraam> hmm ok not all of them
2021-09-27 17:10:06 <andypost[m]> ikke: btw gnome-builder is a part of gnome-apps https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/gnome/APKBUILD#L116
2021-09-27 17:10:45 <ncopa> we are getting close a featre freeze for 3.15 release now
2021-09-27 17:11:06 <ikke> 👍
2021-09-27 17:11:48 <ikke> ncopa: I'm working on setting up CI for abuild
2021-09-27 17:12:04 <ikke> Finding some implicit dependencies which turn up when running it in a clean docker environment
2021-09-27 17:12:07 <ncopa> anything toolchain related (gcc, binutils, cmake, make, clang, llvm, rust, autoconf/automake, abuild) needs to be stabilized in the nearest week(s)
2021-09-27 17:12:15 <ncopa> ok?
2021-09-27 17:12:27 <ncopa> like git?
2021-09-27 17:12:34 <ikke> For example
2021-09-27 17:12:40 <ikke> abuild-sign not in PATH
2021-09-27 17:12:43 <ikke> (and other helpers)
2021-09-27 17:13:01 <ncopa> aha
2021-09-27 17:13:03 <ikke> I need to set APORTSDIR to prevent it looking for a git remote
2021-09-27 17:13:47 <Misthios> hm wil try to finish llvm rebuilds this week then
2021-09-27 17:13:58 <ncopa> is it llvm12?
2021-09-27 17:14:02 <Misthios> ye
2021-09-27 17:14:05 <ncopa> llvm12 would be great to have
2021-09-27 17:14:15 <Misthios> llvm itself is done, just the rebuilds need to be tried
2021-09-27 17:14:28 <ncopa> i might be able to help on friday
2021-09-27 17:14:47 <ncopa> unless there are something else more urgent for me
2021-09-27 17:15:03 <ikke> ncopa: I also hope we get the new ppc64le builders up and running in time
2021-09-27 17:15:16 <ncopa> oh, yes. thats a priority
2021-09-27 17:15:39 <ikke> I worked on it, but after rebooting, we got back into ubuntu
2021-09-27 17:15:54 <ncopa> huh... weird
2021-09-27 17:16:07 <ikke> I just got a reply from rafael, he will look at it this week
2021-09-27 17:16:28 <PureTryOut> ncopa: "getting close". So uh, when? Got an exact datae?
2021-09-27 17:16:30 <Newbyte> would it be possible to get in GNOME 41 for Alpine 3.15 if an MR is made soon?
2021-09-27 17:16:45 <ikke> PureTryOut: when ncopa bootstrapped the builders
2021-09-27 17:17:16 <PureTryOut> Plasma 5.23.0 is being released the 7th of October (next week thursday), would be great if I could get that in
2021-09-27 17:17:28 <ikke> Most of that is in community, should not be an issue
2021-09-27 17:17:41 <Newbyte> oh yes, it could be upgraded post-release 
2021-09-27 17:17:44 <PureTryOut> Well they said feature freeze, I would assume it to be an issue 😛
2021-09-27 17:17:47 <ikke> The feature freeze is mostly about the toolchain
2021-09-27 17:18:03 <maxice8> looking at kafkacat
2021-09-27 17:18:17 <Newbyte> PureTryOut (matrix.org): call it a "bugfix" 😉
2021-09-27 17:18:56 <PureTryOut> ikke: ooh good to know thanks
2021-09-27 17:18:59 <maxice8> lol upstream renamed the kafkacat repo to kcat
2021-09-27 17:19:22 <PureTryOut> In that case it should be fine. I already have the Plasma 5.23.0 beta compiling and working just fine, so the eventual release should go just fine
2021-09-27 17:19:25 <maxice8> broke every single link and the tarball which is now "kcat-$pkgver.tar.gz" and the builddir inside is kcat-$pkgver instead of kafkacat-$pkgver
2021-09-27 17:19:33 <ikke> PureTryOut: the goal is to prevent changes to the toolchain to affect packages after they have been built and cause issues later on the stable release
2021-09-27 17:19:43 <PureTryOut> Yeah makes sense
2021-09-27 17:19:58 <ncopa> yeah
2021-09-27 17:20:03 <ikke> And also preventing having to rebuild things again
2021-09-27 17:20:15 <ncopa> if toolchain or build tools are broken we want catch that early
2021-09-27 17:20:35 <ncopa> so if we build the world for the release, and then update gcc to a new major version
2021-09-27 17:20:47 <ncopa> and this breaks stuff, we have a problem
2021-09-27 17:21:14 <ncopa> we actually had that problem with the 3.14 release, were luajit implementation was swapped out after the world was built
2021-09-27 17:21:37 <ncopa> and it didnt work for s390x or similar
2021-09-27 17:21:57 <ncopa> so we had packages built with the old luajit on the 3.14 repos
2021-09-27 17:22:03 <ncopa> and on rebuild it broke
2021-09-27 17:22:52 <ncopa> also things like automatic -dbg as example, *if* we would add that to abuild, we want do that before we build the world, not after we built half of it
2021-09-27 17:23:08 <ncopa> (we will not add automatic -dbg but you get the point)
2021-09-27 17:23:34 <Hello71> nobody replied to https://lists.alpinelinux.org/~alpine/devel/%3C1628515011.zujvcn248v.none%40localhost%3E
2021-09-27 17:23:38 <ncopa> the goal is to start work setting up the 3.15 builders early October
2021-09-27 17:27:28 <andypost[m]> would be great to finish upgrade of icu and ffi - rebuilds are so long
2021-09-27 17:28:23 <ncopa> Hello71: nice write up, sorry for not having time to investigate that
2021-09-27 17:28:58 <Hello71> i think dalias already said on irc that -fno-plt sounds ok
2021-09-27 17:29:03 <ncopa> andypost[m]: yeah, and ghc update should probably also be done before the build-world
2021-09-27 17:29:22 <Hello71> also can you look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54
2021-09-27 17:29:27 <ikke> ncopa: I frequently running against abuild-keygen -ain hanging in CI due to cp -i waiting for input
2021-09-27 17:29:32 <ncopa> Hello71: it sounds good indeed
2021-09-27 17:29:46 <ncopa> cp -i?
2021-09-27 17:29:55 <ncopa> oh, interactive copy
2021-09-27 17:30:11 <Misthios> oh andypost[m]u were doing icu already?
2021-09-27 17:30:25 <Misthios> oops. was doing some of it for firefox at school today 
2021-09-27 17:30:51 <ikke> ncopa: fixed it for now by doing yes | abuild-keygen -ain
2021-09-27 17:31:30 <ncopa> Hello71: i think i had a look at abuild MR the other day bug got distracted by something else. I dont remember why I didnt merge it
2021-09-27 17:31:40 <ncopa> ikke: is there an issue for it?
2021-09-27 17:32:11 <ikke> No, not yet
2021-09-27 17:32:16 <ikke> I'll create one for it
2021-09-27 17:36:01 <dalias> what about -fno-plt ?
2021-09-27 17:36:29 <ncopa> dalias: there is a suggestion to use that as default CFLAG for alpine on x86_64/x86
2021-09-27 17:36:41 <ncopa> dalias: https://lists.alpinelinux.org/~alpine/devel/%3C1628515011.zujvcn248v.none%40localhost%3E
2021-09-27 17:37:26 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10049
2021-09-27 17:37:28 <ncopa> ikke: i wonder how to test `abuild-keygen -ain` without having root permissions
2021-09-27 17:38:02 <dalias> i think it's a good idea especially for 32-bit
2021-09-27 17:38:12 <ikke> ncopa: allow overriding they key path?
2021-09-27 17:38:28 <dalias> it will fix the lack of tail calls on 32-bit
2021-09-27 17:38:33 <Hello71> dalias: you mean 32-bit x86?
2021-09-27 17:38:35 <dalias> yes
2021-09-27 17:39:41 <dalias> on 64-bit it should give a minor performance boost (eliminate wasted cache line) in calls that can't be resolved until ldso time too
2021-09-27 17:40:58 <Hello71> yes, i mentioned that in the email
2021-09-27 17:44:18 <ikke> ncopa: I have all tests passing now
2021-09-27 17:46:27 <ikke> ncopa: another option would be to make /etc/apk/keys writable in the test environment, but that's not a generic solution
2021-09-27 17:47:23 <dalias> ncopa, with unshare(1)
2021-09-27 17:47:51 <dalias> unshare -mr, mount a tmpfs over /etc/apk
2021-09-27 17:55:13 <Ariadne> +1 for -fno-plt
2021-09-27 18:00:39 <Newbyte> What did the size difference look like on aarch64 with no-plt?
2021-09-27 18:01:19 <dalias> i would guess maybe 3 insns instead of 1? not sure
2021-09-27 18:02:28 <dalias> yep
2021-09-27 18:02:36 <Hello71> according to my email, 2 insns per call + 1 per function
2021-09-27 18:02:57 <dalias> instead of b, ardp+ldr+br
2021-09-27 18:03:59 <dalias> that was a tail call
2021-09-27 18:04:18 <dalias> non-tail, it's same but bl/blr
2021-09-27 18:05:06 <Newbyte> Hello71: yes, but I was thinking something like what size difference you get for something like apk-tools
2021-09-27 18:05:12 <Hello71> Newbyte: i didn't check
2021-09-27 18:05:21 <Hello71> dalias: https://gcc.godbolt.org/z/r6f9Kdsxx
2021-09-27 18:06:59 <Hello71> it could be not that much bigger because many functions are called only from one location
2021-09-27 18:07:30 <Hello71> so you gain two instructions at the call site but lose... 3? for skipping plt stub
2021-09-27 18:08:17 <Hello71> Newbyte: can you check?
2021-09-27 18:09:54 <Newbyte> Hello71: I'd rather not right now. I need to prioritise other things.
2021-09-27 18:10:00 <Hello71> ok
2021-09-27 18:10:36 <dalias> ah, per callee
2021-09-27 18:10:42 <dalias> i thought you meant per caller
2021-09-27 18:11:01 <dalias> like it somehow saving an insn by caching got base or something, and i couldn't find it doing that
2021-09-27 18:11:27 <Hello71> well i thought it did that but apparently not?
2021-09-27 18:11:50 <dalias> i think it's not assuming GOT fits in 4k
2021-09-27 18:11:56 <dalias> which would be a bad assumption
2021-09-27 18:12:00 <Hello71> like i said i didn't investigate aarch64 too closely, but maybe it's still worth it?
2021-09-27 18:12:13 <dalias> i think it's a good tradeoff but it will increase size slightly
2021-09-27 18:17:35 <ikke> ncopa: nice, I forgot that -n alreayd meant non-interactive
2021-09-27 18:18:03 <ncopa> :)
2021-09-27 18:21:04 <ikke> I've just memorized abuild-keygen -ain at this point :D
2021-09-27 18:27:32 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/infra/docker/abuild-ci
2021-09-27 18:41:05 <mps> is something changed with musl writev after 3.14-stable. got this '--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} ---'
2021-09-27 18:41:16 <mps> strace 'writev(1, [{iov_base="Connect    : \33[33mxx.xxxxx.xxx"..., iov_len=44}, {iov_base="\n", iov_len=1}], 2Connect    : xx.xxxx.mycpanel.xx ) = 45'
2021-09-27 18:41:36 <mps> anyone could help
2021-09-27 18:42:15 <mps> program is testing/weex
2021-09-27 18:42:16 <ddevault> you're probably barking up the wrong tree
2021-09-27 18:42:26 <ddevault> this is probably a weex problem and has little to nothing to do with writev
2021-09-27 18:42:37 <ddevault> s/strace/gdb/
2021-09-27 18:42:45 <mps> works fine on 3.14  and previous releases
2021-09-27 18:43:00 <ddevault> some edge case or corner case probably turned up a previously unknown bug
2021-09-27 18:44:22 <mps> looks like 'edge case' but I have no idea where to search problem, musl isn't changed between 3.14 and edge much
2021-09-27 18:44:26 <ddevault> gdb
2021-09-27 18:44:33 <ddevault> find out what dereference caused the segfault
2021-09-27 18:44:49 <ddevault> maybe add a -dbg subpackage for weex to get symbols
2021-09-27 18:44:57 <ddevault> and install musl-dbg if you really suspect a musl problem
2021-09-27 18:44:59 <ddevault> but I doubt it
2021-09-27 18:45:05 <mps> hmm, that is my last option, I know
2021-09-27 18:45:16 <ddevault> last option? it should be your first option
2021-09-27 18:45:21 <ddevault> #1 cause of segfault is application bug
2021-09-27 18:45:28 <ddevault> and gdb will take you directly to the problem
2021-09-27 18:45:43 <dalias> i dont see why you think it has anything to do with writev
2021-09-27 18:46:40 <mps> well, that is last what I see in strace out
2021-09-27 18:46:47 <ddevault> strace traces syscalls
2021-09-27 18:46:50 <ddevault> segfaults happen in between syscalls
2021-09-27 18:46:59 <ddevault> use gdb
2021-09-27 18:48:29 <ddevault> if the kernel segfaults, it shows up in dmesg, not strace
2021-09-27 18:58:33 <Hello71> or you get an EFAULT
2021-09-27 19:05:08 <mps> Hello71: no, it is clearly bug in application which is 'triggered' with something in edge, and I don't have time now for this. just thought maybe someone can give 'headlight'. will look when find time for this
2021-09-27 19:46:30 <mps> hmm, interesting, copied binary from 3.13 and it works on edge without problem
2021-09-27 19:48:43 <mps> so it could be something with openssl new libs
2021-09-27 20:29:53 <Hello71> Newbyte: +2814 bytes package, +4096 bytes installed. x86_64 is -3951 pkg, -8264 installed. x86 is -6004 pkg, -4096 installed
2021-09-27 20:30:21 <Newbyte> oh :( thanks for testing!
2021-09-27 20:30:58 <Hello71> that's basically what i expected
2021-09-27 20:31:39 <Hello71> -fno-plt is almost certainly going to make things bigger on aarch64, although less than i initially thought
2021-09-27 20:32:17 <ikke> Do we have to use -fno-plt consistently on all arches?
2021-09-27 20:32:24 <Hello71> no but it makes things easier
2021-09-27 20:33:36 <Hello71> i think it could possibly be beneficial in size if external calls could be automatically marked somehow. if you use -fno-plt globally then dso-internal calls inflate in size
2021-09-27 20:34:20 <Hello71> gcc has __attribute__((noplt)) but afaik no way to apply to external calls without patching header files
2021-09-27 20:34:34 <Hello71> hm, i wonder if you could use a gcc plugin
2021-09-27 20:37:27 <Hello71> predict that functions defined in /usr/include will be externally defined, and other header files are internal. it will guess wrong for projects that ship programs linking against their own shared libraries (e.g. apk, musl)
2021-09-27 20:40:27 <Hello71> and also system static libraries
2021-09-27 20:43:27 <Hello71> ikke: in my proposal i suggested only adding it for x86 and x86_64. not sure how to actually code that though
2021-09-27 20:46:18 <Hello71> CHOST is not defined in /etc/abuild.conf, and even if it is, it's a little ugly to be putting complicated conditionals in there. but if put in abuild, not sure if there should be some way to override it. and i think on balance, -fno-plt is not suitable for default system-wide use through gcc specs
2021-09-27 22:21:23 <andypost[m]> which way better - add new aport !25846 or upgrade main/wget?
2021-09-27 22:46:31 <dalias> mps, what binary is it and what libs does it use?
2021-09-27 22:46:59 <dalias> there was some lib, possibly libssh, which had silent ABI breakage recently
2021-09-28 00:11:44 <tomalok> ikke: https://github.com/gliderlabs/docker-alpine/issues/307#issuecomment-927187574 appears to have fixed teh gitlab.com builds, thanks!
2021-09-28 00:19:40 <Hello71> andypost[m]: seems to me like upstream wants it to be separate
2021-09-28 00:19:46 <Hello71> i think other distros have had it separate for some time already
2021-09-28 00:21:31 <andypost[m]> thank you, looks like there's arguments has changes so better keep separae
2021-09-28 00:21:42 <andypost[m]> *separate
2021-09-28 00:24:24 <andypost[m]> also 2 dependencies in testing (pandoc and lzlib) and it requires libmicrohttpd-dev for tests
2021-09-28 00:24:38 <Hello71> ugh, pandoc
2021-09-28 00:24:57 <andypost[m]> yep, for man1(
2021-09-28 00:27:23 <Hello71> yeah, i know
2021-09-28 00:27:37 <Hello71> i know what people use it for but i can still hate it
2021-09-28 00:30:00 <Hello71> but the man page is bundled with tarball
2021-09-28 00:30:06 <Hello71> so you only need to install pandoc for development
2021-09-28 00:30:29 <Hello71> why did you set it to [ "$CARCH" = "x86_64" ]
2021-09-28 03:16:50 <andypost[m]> because pandoc enabled only for this arch, and without it I see no man1
2021-09-28 03:18:06 <andypost[m]> I mean usr/share/man/man1/wget2.1.gz
2021-09-28 03:20:05 <sam_> coreutils 9.0 has a regression in chmod's exit code; see https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e8b56ebd536e82b15542a00c888109471936bfda
2021-09-28 03:20:11 <sam_> we've backported it in gentoo, may want to on your end as well
2021-09-28 03:22:39 <maxice8> sam_: ty, made !25868
2021-09-28 03:23:03 <sam_> thanks maxice8!
2021-09-28 03:40:26 <andypost[m]> Hello71: thank you, it's really useless deps)
2021-09-28 05:42:11 <smcavoy> hello, if I put a module in /etc/modules should that load via /etc/init.d/modules before networking starts?
2021-09-28 05:45:19 <ikke> smcavoy: networking has "after modules"
2021-09-28 05:47:56 <smcavoy> indeed.. just having an odd issue with networking/wpa_supplicant erroring at boot but everything is fine when ssh comes up (via wired)
2021-09-28 05:49:35 <smcavoy> its the b43 module so maybe it takes a while to init.. oh well.
2021-09-28 06:04:14 <mps> dalias: binary is /usr/bin/weex which is in testing repo
2021-09-28 06:04:58 <mps> it is built using openssl-dev only in makedepends
2021-09-28 06:06:39 <mps> 'ldd /usr/bin/weex' shows only libc
2021-09-28 06:07:32 <mps> last night I stole 10 mins from my sleep time and built it with debug symbols and run with gdb
2021-09-28 06:08:16 <mps> but was too much tired to post backtrace and ask for further help
2021-09-28 06:08:45 <mps> it failed in some ssl_connect function
2021-09-28 06:35:29 <mps> ncopa: yesterday you asked what needs to be fixed for freeze. #12936 
2021-09-28 06:36:01 <mps> it is about protobuf
2021-09-28 06:46:37 <mps> dalias: this is result of 'bt full' https://tpaste.us/KMnB
2021-09-28 07:00:44 <ericonr> huh, what's up with those pointers :o
2021-09-28 07:02:21 <mps> ericonr: this is too cryptic to me
2021-09-28 07:03:38 <mps> I forgot to tell this is on aarch64
2021-09-28 07:09:13 <ericonr> The "aaaaaaa" sequence in them is a bit weird to me, but i might be missing some context
2021-09-28 07:10:45 <mps> source of weex is not changed, so it 'must' be related to something in openssl, or (what I doubt) in gcc
2021-09-28 08:13:17 <adhawkins> I'll eventually remember some of the relationships between gitlab names and people on here! Is Michal Polanski here?
2021-09-28 08:13:37 <adhawkins> Is that mps maybe?
2021-09-28 08:13:59 <adhawkins> Ah, doesn't look like. Sorry mps!
2021-09-28 09:14:50 <maribu> Could it be that https://wiki.alpinelinux.org/wiki/Vlan is out of date, or is vlan support broken in edge?
2021-09-28 09:27:26 <ikke> maribu: it might be out-of-date. Alpine uses ifupdown-ng nowadays, so things might have changed slightly
2021-09-28 09:27:32 <ikke> adhawkins: Michael is not on irc
2021-09-28 09:27:40 <ikke> Michal*
2021-09-28 09:28:33 <clandmeter> maribu: Ariadne might know, she wrote the new implementation.
2021-09-28 09:30:05 <ikke> It should still work in edge
2021-09-28 09:34:16 <adhawkins> ikke: Ok, no worries. I've made the changes so will wait for him to see them in the MR.
2021-09-28 09:34:37 <adhawkins> On a related note, looks like I've been using the wrong format of URL for github downloads, meaning I needed to specify the builddir as a result.
2021-09-28 09:34:51 <adhawkins> Just dropping a 'v' from the URL removes the need for the builddir to be specified.
2021-09-28 09:35:01 <adhawkins> This affects quite a few of my packages, but is probably worth fixing.
2021-09-28 09:35:05 <adhawkins> Couple of questions:
2021-09-28 09:35:14 <adhawkins> 1. Can I do these all in one MR, with a commit for each package?
2021-09-28 09:35:23 <maribu> Ariadne: I get `execute '/usr/libexec/ifupdown-ng/link': No file descriptors available` when trying to get a vlan up. I'm using DHCP to configure that interface.
2021-09-28 09:35:39 <adhawkins> 2. Should the pkgrel be incremented for each package as the APKBUILD has changed?
2021-09-28 09:38:00 <ikke> adhawkins: A single MR suffices. 2 I don't think that's necessary, it should not materially affect the end result, packages do not really need to be rebuilt on the builders
2021-09-28 09:38:13 <adhawkins> Ok
2021-09-28 09:42:17 <PureTryOut> ncopa: could you take a loot at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54 when you have time?
2021-09-28 10:55:25 <kpcyrd> hi! is there something I can do here to resolve this or should I just wait for things to settle? :) https://paste.debian.net/plainh/7bbdec79
2021-09-28 10:55:39 <kpcyrd> happens during `abuild -r` of a package I'm trying to update
2021-09-28 10:58:34 <ikke> seems like either that package, or one if it's dependencies needs to be built against sha512sums="
2021-09-28 10:58:36 <ikke> 07a068119105559a79f42093bd5c1ec97323b24b485b837ed61f771180143c58715bd22137064639cdda0081e2b294255b5555ddbef98f399c47e2a67c74b058 test.initd
2021-09-28 10:58:38 <ikke> "
2021-09-28 10:58:40 <ikke> openssl1.1-compat-dev
2021-09-28 11:05:30 <kpcyrd> hm, I'm using `makedepends="cargo libgit2-dev"` both libgit2 and cargo depend on so:libssl.so.1.1
2021-09-28 11:20:38 <ikke> Those dependencies install without issue for me
2021-09-28 11:22:44 <kpcyrd> `doas apk add libgit2-dev` seems to be the problem on my system, libgit2 itself installs fine
2021-09-28 11:22:49 <clandmeter> kpcyrd: have you tried rootbld?
2021-09-28 11:23:18 <kpcyrd> clandmeter: haven't heard of it yet, looking into it now :)
2021-09-28 11:23:45 <clandmeter> it builds in an clean chroot
2021-09-28 11:24:43 <kpcyrd> do I need to use different commands? it seems the package is empty
2021-09-28 11:25:38 <clandmeter> apk add abuild-rootbld
2021-09-28 11:25:54 <clandmeter> and then: abuild rootbld
2021-09-28 11:32:30 <kpcyrd> thanks! the dependencies install correctly with rootbld, seems to be something wrong with my system then
2021-09-28 11:33:37 <kpcyrd> rootbld also enforces that network is unavailable during prepare(), right?
2021-09-28 11:33:53 <kpcyrd> (I've added `options="net"` now)
2021-09-28 11:37:18 <donoban> clandmeter: so abuild-rootbld is something similar to dabuild? (in the sense of keeping host system clean of build dependencies etc...)
2021-09-28 11:37:36 <clandmeter> yes kind off 
2021-09-28 11:38:07 <donoban> nice, I will try it
2021-09-28 11:38:17 <clandmeter> one is based on docker, other is based on bubblewrap
2021-09-28 11:47:49 <Hello71> ericonr: that's just aarch64. remember that aslr is disabled in gdb
2021-09-28 11:52:03 <fcolista> would be coll to have a doc explaining how to use these tools (rootbld abuild-docker etc) for a developer setup
2021-09-28 11:52:28 <fcolista> I'm still stucked to lxc with a container for each alpine ver..
2021-09-28 11:52:34 <PureTryOut> rootbld is amazing tbh, even allows cross-compilation nowadays
2021-09-28 11:53:15 <fcolista> I never used it
2021-09-28 11:53:44 <fcolista> alpine build tools ecosystem has a lot of undocumented tools :(
2021-09-28 11:54:22 <PureTryOut> `abuild rootbld` in the same directory as the APKBUILD inside the aports tree is the only thing you need to do to build for your host arch, basically like dabuild
2021-09-28 11:55:51 <donoban> fcolista: dabuild is pretty simple, just set up docker, get dabuild and put it PATH and use 'dabuild' command instead abuild
2021-09-28 11:55:52 <fcolista> so you have your abuild.conf in home directory, aports dir shared among different containers, and you run abuild rootbld $dir/$package/APKBUILD
2021-09-28 11:56:30 <fcolista> what's the difference between dabuild, abuild-docker, abuild-rootbld ?
2021-09-28 11:57:01 <fcolista> When I would use one, when another? 
2021-09-28 11:57:18 <donoban> uhM, it's a question of preferences
2021-09-28 11:57:31 <fcolista> this kind of things would be good to have it written somewhere
2021-09-28 11:57:39 <fcolista> donoban, yes. 
2021-09-28 11:57:49 <fcolista> Depends on how you want to create your building evnironment
2021-09-28 11:58:16 <fcolista> e.g. I was thinking to qemu running different arches, with aports dir shared via NFS
2021-09-28 11:58:45 <PureTryOut> I only use dabuild on non-Alpine systems
2021-09-28 11:58:46 <fcolista> then with a single "abuild -r " I want it triggered to different arches
2021-09-28 11:58:49 <donoban> I'm happy with dabuild but currently I'm using docker on my desktop just for it, so if I switch to 'abuild rootbld' and can remove docker... I suppose that I will be happier :)
2021-09-28 11:58:58 <PureTryOut> On native Alpine systems I only use rootbld
2021-09-28 11:58:59 <fcolista> and there are several ways to accomplish this. 
2021-09-28 11:59:20 <fcolista> e.g. docker, gitlab runners, script with mqtt-exec
2021-09-28 11:59:23 <PureTryOut> for cross-compiling I only do that on native Alpine systems, `CBUILD=<target arch> abuild rootbld`
2021-09-28 12:00:01 <PureTryOut> tbh I only do Alpine stuff on Alpine machines nowadays, I only have a RPi still with Raspbian, everywhere else is Alpine now
2021-09-28 12:00:40 <fcolista> I've my workstation running alpine, with buildenv in different lxc-containers. Aports dir shared from host with the various containers.
2021-09-28 12:01:35 <fcolista> I'm still wondering the most efficient setup to have crosscompile package for different alpine versions
2021-09-28 12:01:46 <fcolista> s/versions/releases
2021-09-28 12:04:37 <clandmeter> PureTryOut: thats not cross compilation
2021-09-28 12:05:41 <clandmeter> fcolista: dabuild is docker based, with all the options that docker brings.
2021-09-28 12:07:13 <clandmeter> i didnt have much time recently to work on it, would be nice if somebody else could take it over as richard also seems to stopped maintaining it.
2021-09-28 12:08:02 <PureTryOut> Ok true it uses Qemu user, but I meant "compiling for a non-host architecture"
2021-09-28 12:08:19 <clandmeter> fcolista: rootbld is kind of just abuild but the build is run in a new chroot/container
2021-09-28 12:09:22 <clandmeter> rootbld is less flexible, but for the enduser its more simple to use.
2021-09-28 12:12:01 <clandmeter> PureTryOut: we dont provide cross compilation on alpine. even mentioning it here will trigger Ariadne ;-)
2021-09-28 12:15:40 <PureTryOut> Lol
2021-09-28 12:16:02 <PureTryOut> I realize it's not cross-compilation, but it's easier to call that than saying "compiling for a non-host architecture"
2021-09-28 12:18:34 <Hello71> running under emulator
2021-09-28 12:20:50 <fcolista> clandmeter, so rootbld added the alpine-sdk, gcc stuff etc automatically
2021-09-28 12:35:43 <adhawkins> ikke: Turns out the builddir is required after all, as most of the packages are called 'py3-modulename', whereas on github they're just 'modulename'.
2021-09-28 12:39:12 <Ariadne> maribu: config ?
2021-09-28 12:41:01 <clandmeter> fcolista: its all automatically
2021-09-28 12:41:11 <clandmeter> automagically even 
2021-09-28 12:42:56 <adhawkins> clandmeter: What's the relationship / difference between rootbld and dabuild?
2021-09-28 12:43:05 <adhawkins> Currently I maintain my alpine packages using dabuild on Debian.
2021-09-28 12:46:17 <clandmeter> rootbld is currently only available on a alpine host
2021-09-28 12:46:52 <clandmeter> so if you want to do cross distribution development dabuild would be easier.
2021-09-28 12:49:06 <clandmeter> if you want to do rootbld on another distribution, you would need to install abuild on your distribution including its dependencies.
2021-09-28 13:11:51 <fcolista> thx clandmeter for your explanation
2021-09-28 13:14:30 <PureTryOut> clandmeter: I see you add a riscv64 target to `community/rust` in 17f7ce38addaabf8a2617adf42f99c5faf9ab153, have you had any luck in making Rust available for riscv64?
2021-09-28 13:15:28 <Ariadne> no
2021-09-28 13:15:36 <Ariadne> it needs libc crate and std enablement
2021-09-28 13:16:18 <Ariadne> ddevault worked on it last year i’ll try to finish it asap.  focusing on s390x bootstrap first since all the pieces are there now :)
2021-09-28 13:17:26 <Ariadne> bringing rust to new arch+libc combo is worse than even openssl 3 migration :)
2021-09-28 13:19:49 <PureTryOut> oh s390x is close? That is nice too 😄
2021-09-28 13:20:03 <PureTryOut> I guess we'll see Rust for riscv64 in 3.16 then
2021-09-28 13:20:39 <Ariadne> i do not really want to do rust on riscv until we have a fast builder
2021-09-28 13:20:59 <Ariadne> even the current one we are getting is too crap to do rust builds they will take 24 hours plus
2021-09-28 13:21:02 <Ariadne> :p
2021-09-28 13:25:21 <Ariadne> kpcyrd: you can’t have openssl 1.1 headers and 3 headers installed at same time.
2021-09-28 13:32:34 <PureTryOut> Makes sense
2021-09-28 13:32:43 <PureTryOut> Any word on getting physical hardware?
2021-09-28 13:33:04 <PureTryOut> Or did you mean some physical hardware with "the current one we are getting"?
2021-09-28 13:33:17 <maribu> Ariadne: iface vlan305 inet dhcp
2021-09-28 13:33:17 <maribu>     vlan-raw-device eth0
2021-09-28 13:33:39 <Ariadne> can you paste the full configure
2021-09-28 13:33:43 <Ariadne> thanks
2021-09-28 13:33:45 <PureTryOut> maribu: since this is an IRC first channel, try to refrain from using Matrix-specific features like multi-line messages
2021-09-28 13:33:47 <Ariadne> to like
2021-09-28 13:33:52 <Ariadne> tpaste
2021-09-28 13:34:32 <maribu> I think that the matrix bridge will create a link if I create a fenced code block. Let's try this out.
2021-09-28 13:34:41 <PureTryOut> It will yes
2021-09-28 13:35:01 <maribu> 	vlan-raw-device eth0
2021-09-28 13:35:01 <maribu> iface eth0 inet dhcp
2021-09-28 13:35:01 <maribu> iface vlan305 inet dhcp
2021-09-28 13:35:30 <Ariadne> why is eth0 configured to use dhcp if you are trunking ?
2021-09-28 13:35:41 <Hello71> can someone move https://gitlab.alpinelinux.org/alpine/aports/-/issues/10796 to mkinitfs
2021-09-28 13:37:20 <Ariadne> can you do ifquery -P —auto | tpaste
2021-09-28 13:38:19 <maribu> I'm currently working from home. I can do so tomorrow.
2021-09-28 13:40:45 <maribu> ifquery -P --auto however prints me help, same does ifquery --auto
2021-09-28 13:44:20 <PureTryOut> I always forget, how do the builders figure out what packages to build again? Some shell functions to get packages changed from git and what not
2021-09-28 14:00:56 <Ariadne> ifquery -LP | tpaste perhaps
2021-09-28 14:02:20 <maribu> https://tpaste.us/jNbV
2021-09-28 14:06:35 <ikke> PureTryOut: no, the builders purely compare what's in git with what's in the built repo
2021-09-28 14:06:48 <ikke> PureTryOut: it uses lua-aports for that
2021-09-28 14:07:00 <ikke> + buildrepo
2021-09-28 14:07:59 <PureTryOut> Ok CI then? I know something somewhere does that 😛
2021-09-28 14:08:19 <Hello71> .gitlab-ci.yml
2021-09-28 14:08:37 <ikke> Yes, CI looks at the diff between the target branch and the current branch
2021-09-28 14:09:22 <ikke> PureTryOut: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L115
2021-09-28 14:10:03 <ikke> And then uses ap builddirs to build them in the correct order
2021-09-28 14:10:05 <PureTryOut> Thanks that's the one I was looking for
2021-09-28 14:10:28 <PureTryOut> I would love to have that in a single command, but I guess I'll need to script something for that myself
2021-09-28 14:26:54 <Ariadne> maribu: cat /etc/network/interfaces | tpaste
2021-09-28 14:30:49 <donoban> Cogitri[m]: I was trying to debug the gnome-keyring problem but I now get a black screen when starting gdm, it seems related with: [   120.335] (EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied)
2021-09-28 14:33:28 <maribu> https://tpaste.us/DXZl
2021-09-28 14:42:39 <Ariadne> maribu: which alpine version?
2021-09-28 14:44:03 <maribu> edge, updated today. (I haven checked the vlan for quite some time, though)
2021-09-28 14:51:19 <Ariadne> hmm ok
2021-09-28 14:55:20 <minimal> maribu: I use vlans but with static IP config in /e/n/i. In addition to the "vlan-raw-device eth0" entry I also specify "vlan_id 2" to indicate the VLAN number"
2021-09-28 14:58:51 <Ariadne> yes
2021-09-28 14:58:54 <Ariadne> try that
2021-09-28 14:59:02 <maribu> minimal: That makes sense. I wonder if I just broke the config without noticing some time ago, or whether it was deduced from the name of the interface previously. I still get the "No file descriptors available" error with the ID given specifically, though.
2021-09-28 14:59:03 <Ariadne> the problem is there’s a dependency loop
2021-09-28 14:59:38 <Ariadne> so it’s trying to bring up itself as dependency
2021-09-28 14:59:52 <Ariadne> we should add a check for that as that is a little silly
2021-09-28 15:00:24 <minimal> maribu: I don't name my interfaces including the VLAN number - so what if you add the "vlan_id" entry and change the name, maybe that will break the dependancy loop?
2021-09-28 15:01:53 <maribu> I renamed the interface to foo and added vlan_id 305. ifquery -LP now says that foo requires foo.
2021-09-28 15:11:59 <ikke> tomalok: more context: https://github.com/kubernetes/test-infra/issues/23741
2021-09-28 15:17:14 <Ariadne> maribu: okay i’ll see if i can reproduce and move from there
2021-09-28 15:18:43 <maribu> Thanks a lot :-)
2021-09-28 18:13:41 <Cogitri[m]> donoban: Are you using elogind?
2021-09-28 18:25:53 <Hello71> Ariadne: is mips64 gone for good?
2021-09-28 18:27:05 <ikke> Hello71: It was back for a short while, but now disappeared again
2021-09-28 20:42:14 <Ariadne> Hello71: thoughts on automatic -Wstack-size=128000?
2021-09-28 20:42:42 <Hello71> what's that
2021-09-28 20:43:02 <Hello71> -Wstack-usage?
2021-09-28 20:43:06 <Ariadne> makes GCC emit warnings when it detects cases where stack is exhausted
2021-09-28 20:43:07 <Ariadne> yes
2021-09-28 20:43:12 <Ariadne> sorry, -Wstack-usage=128000
2021-09-28 20:44:16 <Hello71> what's kernel at now?
2021-09-28 20:46:24 <ericonr> Ariadne: I imagine a lot of false positives on non threaded programs, possibly
2021-09-28 20:46:53 <Hello71> i don't really have an opinion on -Wstack-usage/-Wframe-larger-than
2021-09-28 20:46:55 <Hello71> maybe dalias does
2021-09-28 20:47:31 <dalias> i dont think it's a bad idea
2021-09-28 20:48:04 <dalias> aside: i wish the kernel crash logger would tell you stack overflows are stack overflows
2021-09-28 20:48:23 <dalias> but it fails to even report the address of the crash right :/
2021-09-28 20:53:08 <Hello71> you mean the ip or the fault?
2021-09-28 20:53:13 <Hello71> (or both? :p)
2021-09-28 20:53:30 <dalias> ip is what it gets wrong
2021-09-28 20:53:46 <dalias> it's confused about how file offsets correspond to virtual addresses or something
2021-09-28 20:53:50 <dalias> and typically off by one page
2021-09-28 21:03:02 <Ariadne> i still think that increasing the default stack size to 256KB on 64-bit systems is probably fine :P
2021-09-28 21:25:41 <Ariadne> dalias: what do you think about increase default stack to 256kb on 64-bit?  e.g. make stack size 32 * sizeof(void *)
2021-09-28 21:27:49 <Hello71> not sure if this was raised before, but i guess the problem with doing it per-arch is that some programs will then only work on 64-bit. arguably it is better if they consistently fail everywhere so can be fixed
2021-09-28 21:28:21 <Ariadne> they wont consistently fail everywhere
2021-09-28 21:28:46 <Ariadne> i mean, really, people should not need 128kb of stack per thread
2021-09-28 21:40:16 <mps> for 64bit is ok but for 32bit I'm not sure
2021-09-28 21:41:15 <mps> but as you say it should be same on all so, hmmm 128 is ok
2021-09-28 22:11:27 <dalias> the point of 128 is being same as kernel
2021-09-28 22:14:25 <dalias> whenever the topic of changing it came up before, my objection was that if it's to be considered there should be some reasonable analysis to establish that a small one-time increase would actually fix a large portion of applications
2021-09-28 22:14:39 <dalias> so that it doesn't just become a game of inching it up further and further each time another one is discovered
2021-09-28 22:14:58 <dalias> (same as the 'adding just a few functions for systemd' principle)
2021-09-28 22:15:43 <dalias> there is some merit to treating 64-bit different, but i'm not even sure that makes sense -- aren't most of these large buffers char[] ?
2021-09-28 22:16:05 <dalias> like file or network io buffers, not data structures or recursive frames
2021-09-28 22:42:41 <skarnet> arguably the problem is different, because "adding a few functions for systemd" is catering to *one* project that has extensively shown disregard for POSIX, whereas default thread stack size involves a lot of projects and there's no reason to believe they'll all coordinate and decide to use more stack size just to be malicious to musl
2021-09-28 22:43:21 <skarnet> I think Alpine has proven that yes, bumping the default stack size once would, indeed, fix a large number of applications
2021-09-28 23:01:54 <Hello71> dalias: i think the premise behind setting it different for 64-bit is that there is more address space to waste, not that more stack space is legitimately required
2021-09-28 23:23:20 <dalias> skarnet, indeed, it's not quite the same, but it's a moving-goalposts situation
2021-09-28 23:23:37 <dalias> just arising organically rather than by malice
2021-09-28 23:36:49 <danieli> i hope alpine won't move in the direction where it blocks support for software just for the sake of it (or for correctness, or any other arbitrary reason)
2021-09-28 23:39:02 <Hello71> danieli: in this context you are "behind the curve" then
2021-09-28 23:39:42 <danieli> i get the argument about moving the goal posts and i agree about that, it was a bit of a digression
2021-09-28 23:40:17 <Hello71> dalias: on this subject, i've long wondered why gdb doesn't print $_siginfo in a useful format when breaking due to SIGSEGV
2021-09-28 23:41:58 <dalias> danieli, ?
2021-09-28 23:42:04 <dalias> there's no blocking support for anything
2021-09-28 23:42:24 <dalias> software needing large stack just needs to request it or be linked with the right PT_GNU_STACK setting
2021-09-28 23:42:43 <dalias> i already went to a lot of trouble to make this easy and for some reason it still keeps coming up :(
2021-09-28 23:43:54 <Hello71> i guess part of the problem is like you said that the kernel just says "segfault"
2021-09-28 23:44:01 <Hello71> and even gdb just says "segfault"
2021-09-28 23:44:19 <dalias> really stupid observation:
2021-09-28 23:44:59 <dalias> a 50-line c program that just runs a program under ptrace and reports the likely type of a segfault would be a huge improvement to bug reporting
2021-09-28 23:45:17 <dalias> "null pointer dereference", "stack overflow", "truncated pointer dereference", etc.
2021-09-28 23:45:35 <dalias> there are all really trivial heuristics
2021-09-28 23:47:18 <Hello71> you could probably do a decent job just from strace output
2021-09-28 23:48:51 <Hello71> actually this would be a perfect application of gdb scripting, except that then you have to use gdb scripting
2021-09-28 23:57:11 <dalias> :-p
2021-09-29 01:28:23 <ericonr> If it's due to a huge buffer and not recursion, you can usually get the info from where GDB points out the segfault, since it's the line where the buffer is declared
2021-09-29 01:46:50 <Ariadne> dalias: the question is how do we educate these people that they need to use -Wl,-z,stack-size
2021-09-29 02:23:15 <smcavoy> its the b43 module so maybe it takes a while to init.. oh well.
2021-09-29 05:17:44 <ikke> Why does zoneminder complain about not knowing strerror only on ppc64le?
2021-09-29 05:30:24 <ikke> string.h does define strerror
2021-09-29 05:30:34 <ikke> or declare
2021-09-29 06:20:25 <ncopa> good morning
2021-09-29 06:21:07 <ncopa> strerror is nasty. there are two variants. one posix and one GNU. they return different things
2021-09-29 06:21:35 <ncopa> what app is it that crashed due to out of stack?
2021-09-29 06:22:29 <ncopa> re bigger default thread stack on 64 bit arches, i think it at least makes sense on s390x which has a calling convention that eats lots of stack
2021-09-29 06:23:08 <ncopa> so s390x is the arch that will run out of thread stack space first for recursion issues
2021-09-29 06:26:21 <Misthios> Good morning
2021-09-29 06:51:26 <mps> !25921
2021-09-29 06:53:38 <mps> #13043
2021-09-29 06:54:41 <mps> should wpa_S build with openssl1.1-compat-dev?
2021-09-29 07:37:50 <Newbyte> If I'm not interested in maintaining a package any more, is it better to just remove myself from the maintainer line, or should I also move it to unmaintained? 
2021-09-29 07:40:55 <mps> depends on pkg imo. if it is not important move it
2021-09-29 07:57:05 <Newbyte> What makes a package important?
2021-09-29 07:57:35 <mps> some pkgs depends on it, as first
2021-09-29 07:57:54 <mps> and it is used with a lot of users
2021-09-29 07:58:13 <mps> s/with/by/
2021-09-29 08:18:18 <ikke> ie, impact by removal
2021-09-29 08:18:38 <clandmeter> i think you can just remove yourself as maintainer via an MR, if one of our developers thinks its useless to keep, he/her can suggest for removal.
2021-09-29 08:45:02 <Newbyte> sounds reasonable, thanks
2021-09-29 09:05:37 <ddevault> god I hate python
2021-09-29 09:05:42 <ddevault> er, wrong buffer
2021-09-29 09:07:40 <PureTryOut> I feel insulted
2021-09-29 09:08:18 <Newbyte> I feel so much sympathy 
2021-09-29 09:10:31 <skarnet> no such thing as a wrong buffer when the heart is crying out like that
2021-09-29 09:21:23 <caskd> let the world know about your pain
2021-09-29 09:22:06 <ddevault> getting academic python garbage to work is much like taking a box full of bricks and shaking it until they more or less lie flat, or until one of them falls out and drops on your foot
2021-09-29 09:22:20 <ddevault> "it works on my machine", they say, neglecting to mention that their machine is a toxic waste dump
2021-09-29 09:28:27 <mps> I don't know for any good 'thing' from any academy
2021-09-29 09:29:37 <mps> most inventions are done by stubborn and eccentrics 
2021-09-29 09:39:35 <skarnet> academics are some of the most clueless people wrt good programming and engineering practices
2021-09-29 09:39:52 <skarnet> second only to tech corporation executives
2021-09-29 09:44:47 <mps> 'dead race' between them, imo
2021-09-29 09:45:14 <PureTryOut> Ah the clue is in the "academic" I would say, not so much the Python 😛
2021-09-29 10:36:23 <DylanVanAssche> Not all academics are the same, the garbage side is some cases true, but not always.... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/ZZLAqXobsTGgqyjYmpoxGrAF)
2021-09-29 10:44:40 <donoban> Cogitri[m]: (are you using elogin?) theorically yes
2021-09-29 10:53:04 <Cogitri[m]> And practically?
2021-09-29 10:54:22 <donoban> hehe I'm using it now "supervise-daemon elogind --start /usr/libexec/elogind/elogind --", but I started with tinydm, theorically if I try to run gdm it should use elogind too
2021-09-29 10:55:38 <donoban> I can debug it with my other laptop
2021-09-29 10:57:23 <ikke> > I have updated the documentation on the native transports to note that musl is not officially supported: https://github.com/netty/netty/wiki/Native-transports; I think that's the best we can do for now.
2021-09-29 10:57:26 <ikke> https://github.com/netty/netty/issues/11701
2021-09-29 10:57:55 <donoban> Cogitri[m]: it's on the black screen now, elogin-daemon seems running
2021-09-29 11:01:18 <donoban> https://tpaste.us/gBjd
2021-09-29 11:01:23 <donoban> here is the xorg log from gdm
2021-09-29 11:07:55 <donoban> just for trying I modified /dev/tyy* permissions and xf86OpenConsole: Cannot open virtual console 1 (Permission denied) error changed to xf86CloseConsole: KDSETMODE failed: Bad file descriptor xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
2021-09-29 11:08:14 <mps> DylanVanAssche: I didn't told that all academic _people_ are bad, but 'entity' as such
2021-09-29 11:09:49 <DylanVanAssche> mps: I know, my message was more of a comment, not aimed at anyone 😉 But I really understand the annoyance!
2021-09-29 11:10:00 <DylanVanAssche> 
ACTION deals with these things himself

2021-09-29 12:05:29 <Cogitri[m]> donoban: You may have to add yourself to some groups since your setup seems to be a bit different than usual
2021-09-29 12:07:41 <dalias> ariadne, is it for users building their own stuff or distro packages?
2021-09-29 12:10:03 <donoban> uhM, Cogitri[m] but I'm starting gdm as rc-service
2021-09-29 12:10:38 <donoban> I remember it working, some upgrade should broke it
2021-09-29 12:11:39 <dalias> ikke, declaration visibility should not differ by arch. maybe gcc just has different warning level defaults for some archs due to abi being more finnicky and it's an issue on all archs?
2021-09-29 12:12:12 <donoban> Cogitri[m]: I mean, the blank screen is on gdm starting, not on my user login
2021-09-29 12:12:34 <donoban> well, I will keep digging into it, have to go now, see you
2021-09-29 12:29:55 <Saijin_Naib[m]> donoban  same behavior for me with RC-update GDM default, elogind, and my user in audio, video, input groups. Other dm work fine to get to non-GNOME sessions, but GDM won't start right, just black screen ignoring input with an underline in top left spot
2021-09-29 12:53:45 <Hello71> ikke: https://github.com/netty/netty/blob/4.1/transport-native-unix-common/src/main/c/netty_unix_errors.c#L41 :|
2021-09-29 12:54:24 <Hello71> actually, hm, in this case #ifdef _GNU_SOURCE actually turns out to happen to be right
2021-09-29 12:54:36 <Hello71> by accident
2021-09-29 14:35:27 <Ariadne> dalias: own stuff
2021-09-29 14:48:00 <Hello71> dalias: huh, lldb is nice enough to print * thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
2021-09-29 14:48:28 <Hello71> and a stack trace, and a function disassembly
2021-09-29 14:49:07 <Hello71> stallman strikes again...
2021-09-29 14:51:46 <Hello71> (lldb probably wouldn't exist if not for stallman insisting that gcc be non-extensible, and if there was no lldb then these usability improvements would probably accrue to gdb instead of lldb)
2021-09-29 15:01:40 <donoban> Saijin_Naib[m]: "good" to know :)
2021-09-29 15:53:39 <ikke> I'm puzzled
2021-09-29 15:56:27 <ikke> Ok, note to self: make sure you use an up-to-date source
2021-09-29 16:01:10 <Ariadne> regarding iwd: i propose we do it now, wpa_supplicant is unlikely to see further releases
2021-09-29 16:01:24 <Ariadne> but we are running out of time to do it
2021-09-29 16:01:30 <Ariadne> we need eiwd too, for non-dbus
2021-09-29 16:01:35 <Hello71> i don't have strong opinion either way
2021-09-29 16:01:36 <Ariadne> both should go to main
2021-09-29 16:01:48 <Hello71> iwd+dbus looks smaller than wpa_supplicant
2021-09-29 16:02:09 <Ariadne> yes, but some have ... religious convictions ... against dbus ;)
2021-09-29 16:02:25 <Hello71> it would definitely be good to delete all that setup-interfaces crap. it doesn't even connect to wpa3
2021-09-29 16:02:40 <Ariadne> right
2021-09-29 16:03:02 <Ariadne> and in ifupdown-ng with native executors coming, we can just make a dbus call to iwd to set up the wifi
2021-09-29 16:03:05 <Ariadne> :)
2021-09-29 16:04:05 <dalias> huh? wpa_supplicant is deprecated?
2021-09-29 16:04:07 <Ariadne> anyway, i prefer iwd, but we need to get this done if we are doing it for 3.15
2021-09-29 16:04:15 <dalias> or just mature and lacking need for any change?
2021-09-29 16:04:42 <mps> iwd doesn't work with wext drivers
2021-09-29 16:04:47 <Ariadne> nobody cares
2021-09-29 16:05:03 <mps> tell this to TSC :D
2021-09-29 16:05:17 <dalias> isn't iwd geared towards interactive users and likely unsuitable for server configs?
2021-09-29 16:05:38 <ikke> how common is wifi on server setups?
2021-09-29 16:05:40 <Ariadne> it exposes the same APIs as wpa_supplicant and can be driven with ifupdown-ng the same way
2021-09-29 16:05:44 <mps> dalias: iwd can be configured and set manually
2021-09-29 16:05:49 <dalias> ikke, any reasonable use of rpi
2021-09-29 16:06:03 <Ariadne> wpa_supplicant will probably never get WPA3 support
2021-09-29 16:06:16 <mps> dalias: by creating file with needed parameters
2021-09-29 16:06:17 <Hello71> Ariadne: eh?
2021-09-29 16:06:20 <Misthios> And its way slower as iwd
2021-09-29 16:06:21 <dalias> 
ACTION isn't missing WPA3

2021-09-29 16:06:45 <Ariadne> but more importantly, the last wpa_supplicant release was 2 years ago
2021-09-29 16:06:51 <dalias> i really dont know much about iwd so i dont know if i'd have any objection to it (wext issue seems like it might matter tho)
2021-09-29 16:06:54 <mps> because this I put eiwd (iwd without dbus) in testing
2021-09-29 16:07:08 <dalias> but i'm perfectly happy with wpa_supplicant and from a "don't break things that work" standpoint it seems unnecessary to change it
2021-09-29 16:07:33 <Ariadne> dalias: not proposing removing wpa_supplicant, just using iwd for new installs
2021-09-29 16:07:47 <mps> we discussed this previous year before 3.13 release, iirc
2021-09-29 16:07:50 <dalias> fwiw "last release was 2 years ago" is a positive to me
2021-09-29 16:07:57 <dalias> it means it's not moving fast and breaking things
2021-09-29 16:08:05 <Ariadne> well, we are up to 2.9-r17 and half of those are CVE fixes so
2021-09-29 16:08:06 <Ariadne> :p
2021-09-29 16:08:12 <dalias> :-p
2021-09-29 16:08:17 <Hello71> wpa_supplicant has a huge security surface (unfortunately...)
2021-09-29 16:08:32 <dalias> uhg, why does it? :(
2021-09-29 16:08:45 <Ariadne> because it does everything in single process
2021-09-29 16:08:58 <dalias> yes but it doesn't need access to anything but the wlan0 device
2021-09-29 16:09:02 <Ariadne> the architecture was from the WPA1 era
2021-09-29 16:09:08 <Hello71> to get wpa, basically what you do is take ipsec and then make everything twice as complicated
2021-09-29 16:09:44 <Hello71> also i'm assuming that you actually want to take wifi security *somewhat* seriously. otherwise you can just make your wifi unencrypted and use iw to connect
2021-09-29 16:10:02 <dalias> i don't. the network layer is completely untrusted
2021-09-29 16:10:09 <Hello71> then you can uninstall wpa_supplicant and also iwd
2021-09-29 16:10:14 <dalias> however most ap's you want to connect to use WPA
2021-09-29 16:10:22 <dalias> so you need it
2021-09-29 16:10:45 <dalias> also WPA is a nice mitigation to *nuisance* use of the network
2021-09-29 16:10:55 <dalias> it's not access control and not supposed to be
2021-09-29 16:11:18 <Hello71> yes, obviously you use mac address verification for that (grumblegrumble)
2021-09-29 16:11:19 <mps> dalias: 'user friendly' :)
2021-09-29 16:11:29 <dalias> mps, ? :)
2021-09-29 16:11:56 <mps> people wants user freindly system, not secure
2021-09-29 16:12:28 <mps> Hello71: faking mac address is simple (and I think you know this)
2021-09-29 16:12:39 <Hello71> yes, that's the joke
2021-09-29 16:12:48 <mps> ah ok :)
2021-09-29 16:13:00 <Hello71> actually mac address whitelist would be decent if not for the fact that mac addresses are all in plaintext on wifi
2021-09-29 16:13:38 <Ariadne> yes, my AP uses WPA, but only to stop unauthorized access from people who don't know or don't have time to crack the PSK
2021-09-29 16:13:39 <Ariadne> :P
2021-09-29 16:13:49 <mps> I use wifi as it is and run wireguard over it
2021-09-29 16:14:10 <Hello71> basically "shared key authentication" except normally in that case you're not supposed to broadcast the key for everybody to see
2021-09-29 16:14:19 <dalias> i rather dislike mac address allowlist because it requires logging in to privileged access to add a device
2021-09-29 16:14:37 <dalias> giving out a low-value authentication token is a much friendlier workflow with no risk
2021-09-29 16:15:01 <Hello71> i mean it still wouldn't be *good* but at least it would be plausible instead of a total piece of shit like it actually is
2021-09-29 16:16:08 <Ariadne> anyway, working on rust/s390x bootstrap
2021-09-29 16:16:10 <Hello71> it could even be integrated into push-button WPS, which is actually great
2021-09-29 16:16:31 <Ariadne> will update wpa_supplicant to load legacy provider in openssl later today, or we can take it back to 1.1 for now
2021-09-29 16:16:46 <Ariadne> i'm not picky either way, but i think at some point we will have to update wpa_supplicant regardless
2021-09-29 16:16:53 <Ariadne> so now seems better than later
2021-09-29 16:17:42 <mps> I just commented MR and issue report, but don't have strong opinion what should be done.
2021-09-29 16:18:18 <minimal> is there any suitable alternative to using wpa_supplicant (802.1x) for wired networks on servers?
2021-09-29 16:18:34 <mps> actually I put MR on hold till it is discussed more
2021-09-29 16:19:01 <mps> minimal: did you looked at 'ead', part of iwd
2021-09-29 16:19:18 <Hello71> yes, i think ead is supposed to be "modern implementation"
2021-09-29 16:19:46 <mps> it is not yet 'well tested' but I think it works
2021-09-29 16:20:20 <mps> jirutka added openrc script and conf.d
2021-09-29 16:20:53 <mps> maybe he could give more info
2021-09-29 16:21:23 <minimal> mps: wasn't aware of ead, I'll have a look
2021-09-29 16:21:59 <dalias> what is ead??
2021-09-29 16:22:10 <mps> ethernet auth daemon
2021-09-29 16:22:25 <dalias> yes the name itself is confusing to me
2021-09-29 16:22:33 <dalias> since when does ethernet have authentication -- and why??
2021-09-29 16:23:13 <Ariadne> in Oklahoma, it is used to identify subscribes to the shared broadband network and associate them with the right ISP
2021-09-29 16:23:20 <mps> ethernet per se doesn't, but it is used on some switches to activate port after auth
2021-09-29 16:23:47 <Ariadne> assuming we are talking about 802.1x
2021-09-29 16:23:53 <mps> yes
2021-09-29 16:24:18 <mps> I don't have testbed for ead, else I would test it long ago
2021-09-29 16:24:28 <Ariadne> you need something like that for any sort of shared broadband system
2021-09-29 16:25:03 <Ariadne> otherwise, users have to mess with VLAN tags, etc
2021-09-29 16:25:14 <minimal> mps: I have some switches here that support 802.1x, have been meaning to test it for some time
2021-09-29 16:25:34 <mps> 
ACTION is surprised what I see on my docsis ethernet port

2021-09-29 16:26:01 <dalias> i dont see why the isp's modem doesn't do the vlan tag or whatever
2021-09-29 16:26:04 <Ariadne> hmm, DOCSIS 3.0 was supposed to fix that
2021-09-29 16:26:21 <Ariadne> dalias: what ISP modem?
2021-09-29 16:26:35 <dalias> (shared broadband network)
2021-09-29 16:26:45 <minimal> dalias: imagine network security in a corporate environment where if you bring in your own kit (RPI) and connect it to a network port it won't work
2021-09-29 16:26:55 <Ariadne> i mean, the default CPE *does* do all of that.
2021-09-29 16:27:04 <Ariadne> but you are allowed to use your own CPE
2021-09-29 16:27:28 <dalias> the device modulating ethernet (or likely ATM) over whatever actual cable/dsl/fiber media it's going over
2021-09-29 16:27:35 <Ariadne> in which case, your provider just issues you a certificate
2021-09-29 16:27:43 <dalias> ah
2021-09-29 16:28:40 <Ariadne> also, they want to present untagged interface to the customer, so that the customer cannot potentially mess with other VLANs
2021-09-29 16:29:20 <dalias> i see, so it's the cryptographic layer for the modem to use
2021-09-29 16:29:26 <Ariadne> yep
2021-09-29 16:31:25 <Ariadne> well CPE
2021-09-29 16:31:30 <Ariadne> there is no "modem", its just ethernet
2021-09-29 16:31:37 <Ariadne> up to 10gbps :)
2021-09-29 16:34:40 <dalias> there's actual cat6 or whatever 10gbit runs on from off-premise to on-premise?
2021-09-29 16:35:44 <Ariadne> the network is presently 10GBASE-PR40
2021-09-29 16:35:48 <Ariadne> ...
2021-09-29 16:35:52 <Ariadne> okay :D
2021-09-29 16:36:10 <Ariadne> https://en.wikipedia.org/wiki/10G-EPON
2021-09-29 16:36:43 <Ariadne> so, you have a media converter, but that is not really an "active" device
2021-09-29 16:37:34 <ikke> A passive media converter to ethernet?
2021-09-29 16:37:43 <dalias> neat
2021-09-29 16:38:08 <Ariadne> ikke: well, it is plugged into mains, but there's nothing like you would have in a modem
2021-09-29 16:38:19 <Ariadne> e.g. no CPU of any kind :P
2021-09-29 16:38:28 <ikke> ah, ok, in that way
2021-09-29 16:39:24 <Ariadne> SFP+ module goes in one side, copper goes out the other
2021-09-29 16:40:08 <dalias> in theory it just needs power for the outgoing optical i think
2021-09-29 16:40:29 <Ariadne> yes
2021-09-29 16:40:30 <dalias> incoming you can probably convert into ethernet just from the energy at the sensor
2021-09-29 16:40:57 <dalias> altho maybe it needs some minor amp
2021-09-29 16:43:31 <ikke> technically you could use PoE to power it from the copper side
2021-09-29 16:43:35 <dalias> :)
2021-09-29 16:44:13 <Ariadne> that is what most of the RGs do, they supply power to the media converter (ONT)
2021-09-29 16:44:27 <ikke> RG?
2021-09-29 16:44:33 <Ariadne> residential gateway
2021-09-29 16:44:35 <ikke> ah
2021-09-29 16:44:38 <Ariadne> the CPE
2021-09-29 16:50:54 <Ariadne> some of those gateways have an SFP slot that takes the fiber directly
2021-09-29 17:08:39 <HRio> can we merge !25784, or should we wait more for maintainer review? I can not use the package at all without this change.
2021-09-29 17:39:32 <minimal> Ariadne: GPON (what we have here) security potentially doesn't seem so good, e.g. https://pierrekim.github.io/blog/2016-11-01-gpon-ftth-networks-insecurity.html#ont-used-in-this-research
2021-09-29 17:40:46 <Ariadne> yes EAPOL is used to mitigate this
2021-09-29 17:41:45 <minimal> between the ONT and the central side? otherwise someone potentially could modify their ONT to see other people's traffic
2021-09-29 17:43:42 <Ariadne> the ONT just provides layer 2 loop here
2021-09-29 17:44:07 <Ariadne> actual traffic goes between CPE and the ISP via encrypted EAPOL frames
2021-09-29 17:44:21 <JuniorJPDJ> but you need router with eapol support
2021-09-29 17:44:21 <JuniorJPDJ> yup
2021-09-29 17:44:27 <Ariadne> a person who wanted to snoop would have to acquire your certificate
2021-09-29 17:45:15 <Ariadne> at which point they can probably just beat whatever secrets you have out of you with a $5 pipe from harbor freight
2021-09-29 17:45:17 <Ariadne> :)
2021-09-29 17:46:11 <JuniorJPDJ> some ISPs are just using pppoe over fiber
2021-09-29 17:46:16 <JuniorJPDJ> which is good enough imo
2021-09-29 17:46:48 <Ariadne> PPPoE sucks because of MTU loss
2021-09-29 17:47:02 <Ariadne> though i guess they control the physical layer MTU
2021-09-29 17:47:07 <Ariadne> so maybe not an issue
2021-09-29 17:49:22 <JuniorJPDJ> it is an issue but minor enough that noone cares
2021-09-29 17:49:32 <dalias> pppoe is awful just because it's ppp
2021-09-29 17:50:09 <JuniorJPDJ> it is awful but it is in use
2021-09-29 17:50:11 <JuniorJPDJ> ¯\_(ツ)_/¯
2021-09-29 17:51:22 <JuniorJPDJ> pppoe is at least supported by openwrt, i haven't seen anything about eapol over ethernet on openwrt tho
2021-09-29 17:51:27 <dalias> it's almost always dynamic ip because it's built on dialup infrastructure
2021-09-29 17:51:47 <dalias> it's not really amenable to routing and multiple addresses or ipv6 (altho apparently there's some way to do it)
2021-09-29 17:52:27 <dalias> it has significant outage time from every blip and connection reestablishment rather than just ignorable packet loss
2021-09-29 17:54:11 <minimal> Ariadne: I was referring to GPON here where its just PPPoE based to your router and, as its GPON the splitters pass multiple houses traffic to *each* of the ONTs (with each ONT filtering out all the other properties' traffic)
2021-09-29 17:55:43 <minimal> dalias: IPv6 with PPPoE? that works fine using OpenWRT
2021-09-29 17:56:01 <JuniorJPDJ> so you can see other's pppoe traffic which is encrypted
2021-09-29 17:56:15 <JuniorJPDJ> not a problem i think
2021-09-29 17:58:31 <Ariadne> eapol over ethernet is supported on openwrt
2021-09-29 17:59:59 <minimal> JuniorJPDJ: PPPoE encryption? In this context (like xDSL) I'd assumed PPPoE awas just being used for authnetication. If it is also used for encryption I wonder how bruteforcable the username/password might be
2021-09-29 18:00:21 <JuniorJPDJ> ppp is used to do both
2021-09-29 18:01:19 <JuniorJPDJ> Ariadne: I'm googling for a while and can't find info about it. Saw people complaining about that they can't make it working. (802.1x over wired)
2021-09-29 18:01:51 <Ariadne> i have a glinet device which runs openwrt and can do it
2021-09-29 18:04:24 <JuniorJPDJ> https://forum.openwrt.org/t/setting-up-wired-802-1x/4595/17
2021-09-29 18:04:44 <JuniorJPDJ> Ariadne: could you show anything about it? i'm curious
2021-09-29 18:06:09 <dalias> minimal, how does it work when (at least aiui) ppp only has one address for each endpoint?
2021-09-29 18:07:10 <minimal> dalias: with OpenWRT you have a wan and a wan6 interface.
2021-09-29 18:07:48 <dalias> lol so it uses 2 separate ppp links, one for each? :-p
2021-09-29 18:08:31 <dalias> is it still just one v6 address, rather than a whole /64 or something like you'd expect from an isp with v6
2021-09-29 18:09:26 <minimal> dalias: forget the exact details (have been using it for years). Its detailed here: https://openwrt.org/docs/guide-user/network/ipv6/start in the "PPP-based protocols and option ipv6" section
2021-09-29 18:09:48 <minimal> dalias: nope, I get a /48 prefix from my ISP
2021-09-29 18:11:45 <dalias> interesting
2021-09-29 18:13:08 <minimal> yes a /48 is "generous", many ISPs give only a /56 if you're lucky
2021-09-29 18:15:16 <psykose> they could give a /16 and basically nobody would be complaining
2021-09-29 18:15:23 <mps> I had /64 but disabled ipv6 because can't set routing properly
2021-09-29 18:18:16 <minimal> psykose: I believe the RIPE (for Europe) docs specify /48 -> /64 can be allocated to end-user networks
2021-09-29 18:18:30 <minimal> why an ISP would ever allocate a /64 makes no sense to me
2021-09-29 18:19:10 <psykose> even a /16 is 65k ips/devices, idk what the point of these ginormous allocations is
2021-09-29 18:20:02 <Hello71> you have your cidr backwards.
2021-09-29 18:20:40 <minimal> Google in their "anonymisation" of end-user addresses used by Google Analytics use a /24 for IPv4 addresses and a /48 for IPv6 addresses - which as a /48 is valid for end-user networks mean that effectively Google do *not* anonymise IPv6 addresses
2021-09-29 18:21:00 <JuniorJPDJ> psykose:  /16 is bigger than /48
2021-09-29 18:21:13 <psykose> yes, other way around
2021-09-29 18:21:16 <JuniorJPDJ> and /16 is muuuch more than 65k devices on v6
2021-09-29 18:21:29 <ikke> 2^112 addresses
2021-09-29 18:21:33 <JuniorJPDJ>  /56 is something like 65k afair
2021-09-29 18:22:09 <ikke> 65k subnets, you mean?
2021-09-29 18:22:13 <minimal> JuniorJPDJ: no end-user would be allocated a /16 though, if a /16 is allocated then it would be an ISP or a large enterprise for example
2021-09-29 18:22:31 <JuniorJPDJ> yup, i was just trying to correct psykose 
2021-09-29 18:23:14 <ikke> a /32 is more common
2021-09-29 18:23:42 <JuniorJPDJ> my god, i was sure v6 is 64b
2021-09-29 18:23:43 <JuniorJPDJ> and it's 128
2021-09-29 18:23:43 <JuniorJPDJ> nvm
2021-09-29 18:23:56 <JuniorJPDJ> my head hurts
2021-09-29 18:23:59 <ikke> ahuh
2021-09-29 18:24:10 <psykose>  /112 then :p
2021-09-29 18:24:38 <ikke> In the ipv6 ideal world, the smallest subnet is /64
2021-09-29 18:24:46 <minimal> JuniorJPDJ: you mean a /56 is 256 subnets? a /64 is the smallest possible subnet size
2021-09-29 18:24:58 <ikke> well, not possible, you can easily make them smaller
2021-09-29 18:25:36 <minimal> ikke: possible = defined in specs as smallest allocation unit
2021-09-29 18:25:44 <ikke> yes, due to slaac
2021-09-29 18:25:53 <ikke> but in practice you see smaller subnets
2021-09-29 18:25:55 <psykose> that's what big ietf wants you to think
2021-09-29 18:26:09 <minimal> ikke: do many IPv6 stack support smaller than /64?
2021-09-29 18:26:15 <ikke> sure
2021-09-29 18:26:23 <ikke> they do not care
2021-09-29 18:26:48 <JuniorJPDJ> when you are subnetting internals you do smaller subnets, but /64 is smallest allocated to one enterprise/person/whatever
2021-09-29 18:27:17 <JuniorJPDJ> I'm curious how fast they will make it smaller and smaller like with v4
2021-09-29 18:27:33 <JuniorJPDJ> they will give most of IPs away and then cry about no v6 xD
2021-09-29 18:27:44 <minimal> I was always "taught" that smaller than /64 subnets were not supported (i.e. by OSes, routers, etc)
2021-09-29 18:28:56 <ikke> I have a /112 that my vps gives out
2021-09-29 18:29:02 <JuniorJPDJ> I'd show you but my vlans all have /64
2021-09-29 18:29:05 <ikke> I think my vps has a /96
2021-09-29 18:29:58 <ikke> minimal: you also still have point-to-point connections
2021-09-29 18:30:05 <minimal> e.g. RFC 7421: "using an IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications, so results may vary"
2021-09-29 18:30:59 <minimal> so not guaranteed to work
2021-09-29 18:32:08 <minimal> ikke: often ptp links are unnumbered
2021-09-29 18:33:19 <JuniorJPDJ> what exactly does it mean?
2021-09-29 18:37:19 <minimal> ikke: for your VPS isn't that allocating multiple addresses though to the VPS within a /64 subnet rather than defining a routable /96? Is the IPv6 address used for your default route within that /96 or within a (larger) /64?
2021-09-29 18:38:19 <ikke> minimal: I have a separate single address in /64, but a /96 then I can use myself
2021-09-29 18:38:31 <ikke> (in a different subnet)
2021-09-29 18:45:05 <minimal> ikke: not saying it can't be done, just that as the RFC mentioned subnets smaller than /64 are defined by the standards and so may or may not work with various network kit, OSes etc
2021-09-29 18:45:22 <minimal> s/defined/not defined/
2021-09-29 19:36:00 <Ariadne> ERROR: binutils-s390x-2.37-r3: trying to overwrite usr/lib/bfd-plugins/libdep.so owned by binutils-2.37-r0.
2021-09-29 19:36:02 <Ariadne> hmmm
2021-09-29 19:36:22 <Ariadne> i guess in cross toolchain we just skip the plugins.
2021-09-29 19:40:45 <Ariadne> hmm
2021-09-29 19:58:39 <ikke> restarting gitlab real quick
2021-09-29 21:10:21 <ikke> cool, release with binary asset attached with predictable url: https://gitlab.alpinelinux.org/kdaudt/hello-world/-/releases
2021-09-29 21:12:09 <dalias> :)
2021-09-29 21:27:25 <Hello71> https://github.com/netty/netty/pull/11722/files#diff-72dc4fd5806a453cee43bec2f648522cb256ae37bca69fd9134f5d4884d82be1R108
2021-09-29 21:27:30 <Hello71> 
ACTION bangs head on table

2021-09-29 21:27:44 <Hello71> > Pattern gnulibcPattern = Pattern.compile(".*/lib/.*-linux-gnu/libc-.*\\.so");
2021-09-29 21:27:46 <Hello71> > boolean gnulibcFound = false;
2021-09-29 21:29:40 <ikke> (╯°□°）╯︵ ┻━┻
2021-09-29 21:34:57 <Hello71> just use ubuntu, mmkay?
2021-09-29 22:16:29 <dalias> hmm what even is the issue tracker entry for the bootmisc rm -rf ?
2021-09-29 22:16:32 <dalias> i can't find it
2021-09-30 06:28:05 <ncopa> good morning
2021-09-30 06:28:36 <ncopa> Ariadne: i bumped into same conflict with mingw
2021-09-30 07:08:39 <ikke> morning
2021-09-30 07:10:48 <caskd> o/
2021-09-30 07:29:16 <Misthios> gm
2021-09-30 10:59:47 <Misthios> does anyone know why abuild rootbld cannot find packages in a local repo when abuild -r can?
2021-09-30 11:16:26 <donoban> Misthios: you mean a local repo diferent that the rootbld is using for build the package?
2021-09-30 11:16:58 <Misthios> should be the same? it worked fine but then it just stopped working
2021-09-30 11:17:17 <Misthios> like clang found llvm, but lld did not
2021-09-30 11:21:10 <donoban> I looking at abuild.in (I didn't use rootbld yet), and it seems properly bind the repo destination (where I suppose that there are other packages built with same configuration)
2021-09-30 11:21:38 <donoban> but if you mean another repository which was not used with local abuild.. maybe the rootbld is missing it
2021-09-30 11:25:11 <Misthios> hmm will take a better look after school today, ty anyway
2021-09-30 11:25:59 <donoban> ok, later I could try to reproduce your problem, I would like to swith to abuild rootbld
2021-09-30 12:08:26 <ddevault> is there a recommended approach to tweaking kernel configs in aports
2021-09-30 12:25:44 <Hello71> for upstream submission or local use? in either case not afaik
2021-09-30 12:27:51 <ddevault> either
2021-09-30 12:40:13 <ddevault> 
ACTION shrugs

2021-09-30 12:40:16 <ddevault> just did menuconfig manually
2021-09-30 12:52:46 <adhawkins> While trying to test my package (borg-space) I seem to have managed to mess things up. When I try to install the 'real' version, I get https://paste.debian.net/1213854/
2021-09-30 12:53:07 <adhawkins> The 1.0-r0 is a 'test' package I build locally and installed. How can I remove this? Everything I try says it doesn't exist.
2021-09-30 12:53:23 <adhawkins> Oh. 
2021-09-30 12:53:25 <adhawkins> 
ACTION blushes

2021-09-30 12:53:31 <adhawkins> But it works if I spell it right...
2021-09-30 12:53:37 <adhawkins> 
ACTION goes to hide in the corner.

2021-09-30 12:54:16 <adhawkins> I'm not getting this:
2021-09-30 12:54:26 <adhawkins> https://paste.debian.net/1213855/
2021-09-30 12:54:38 <adhawkins> I think it's because the installed version of emborg is too old, but there's nothing in the error that says this.
2021-09-30 12:57:30 <ikke> adhawkins: `apk fix`
2021-09-30 13:06:47 <adhawkins> ikke: (1/1) [APK unavailable, skipped] Reinstalling borg-space (0.0-r0)
2021-09-30 13:07:19 <adhawkins> Ah, didn't add the 'testing' repo.
2021-09-30 13:07:31 <adhawkins> That's a surprise, it seems to be installed now.
2021-09-30 13:08:11 <adhawkins> Whoops, seems that may have buggered up my container.
2021-09-30 13:08:16 <adhawkins> emborg won't run now...
2021-09-30 13:08:48 <ikke> is version 0.0-r0 expected?
2021-09-30 13:08:57 <adhawkins> For borg-space, yes.
2021-09-30 13:09:06 <adhawkins> It depends on emborg-1.27, and I only had 1.26 installed.
2021-09-30 13:10:24 <adhawkins> https://paste.debian.net/1213858/
2021-09-30 13:11:06 <adhawkins> Looks like 'inform' might be out of date.
2021-09-30 13:11:20 <adhawkins> That's better.
2021-09-30 13:11:39 <adhawkins> Looks like I should have some version dependencies in emborg too perhaps.
2021-09-30 13:11:43 <adhawkins> That'll be a pain to maintain.
2021-09-30 14:02:43 <mps> hah, with new GL we got better wiki editor https://gitlab.alpinelinux.org/alpine/infra/infra/-/wikis/Alpine-wireguard-VPN/edit
2021-09-30 14:03:05 <mps> looks easier to use
2021-09-30 14:06:25 <ikke> How do you insert a code-block without mouse?
2021-09-30 14:06:33 <ikke> ``` does not work
2021-09-30 14:07:56 <mps> you mean copy-paste?
2021-09-30 14:08:02 <ikke> No
2021-09-30 14:08:07 <ikke> insert a new code block
2021-09-30 14:08:46 <mps> there is icon
2021-09-30 14:08:54 <ikke> So I have to click on it with a mouse
2021-09-30 14:09:02 <mps> insert code block
2021-09-30 14:09:10 <mps> ah, yes. modern times
2021-09-30 14:09:26 <mps> you have to click a lot there
2021-09-30 14:10:13 <mps> but Ctrl-Z works ;)
2021-09-30 14:11:26 <ikke> I get a big MS teams vibe, which is not good
2021-09-30 14:11:37 <ikke> slack does it better
2021-09-30 14:12:57 <mps> ' MS teams vibe'? what is it
2021-09-30 14:13:19 <ikke> MS teams also has a wysiwyg editor
2021-09-30 14:13:25 <mps> ah
2021-09-30 15:04:51 <PureTryOut> Huh, Gitlab uses Markdown which supports code blocks with \`\`\`. That should really "just work" ™️
2021-09-30 15:12:11 <ikke> PureTryOut: Was talking about their new WYSIWYG wiki editor
2021-09-30 15:18:04 <PureTryOut> I realize that
2021-09-30 15:20:31 <ikke> then if you'd try it, you'd realize that it doesn't work
2021-09-30 15:23:58 <PureTryOut> I understand that haha. I'm not saying "it works", I'm saying "it _should_ work".
2021-09-30 17:09:47 <eschwartz> ikke: 90% of the time, slack miscalculated the end of an inline code block for me, resulting in the whitespace following it being considered part of the code block. So: `this is code `this is prose
2021-09-30 17:29:37 <xordspar0> eschwartz: Yes, that always happens :(
2021-09-30 17:30:56 <eschwartz> I I don't trust any wysiwyg editor tbh. At least discord just formats the text while leaving in the markdown characters for you to edit
2021-09-30 17:41:15 <minimal> just talked to someone in the docker channel on Libera who had TLS certs error in an Alpine docker image - one of the LetsEncrypt chain certs expired today........he was on Alpine 3.7.1 (so ancient OpenSSL) as their org's "support" don't provide anything newer....doh!
2021-09-30 17:41:59 <ikke> oof
2021-09-30 17:45:07 <minimal> I guess there might be some Alpine gitlab issues raised over the next few days by people (both docker users and other) encountering "stuff" that stops working due to the same issue of old Alpine versions in use
2021-09-30 17:46:05 <ikke> I was aware of the LE issue
2021-09-30 17:53:19 <mps> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
2021-09-30 18:11:57 <ikke> maxice8: seems like the assign bug is fixed
2021-09-30 18:51:49 <ddevault> I was hoping to have riscv64 desktop bits going this evening, until I ran headfirst into an AMDGPU oops
2021-09-30 18:52:26 <Ariadne> minimal: so their org only supports an alpine release that has been EOL for like 4 years now?
2021-09-30 18:52:51 <Ariadne> what a strange org :)
2021-09-30 18:53:09 <Ariadne> ddevault: on unleashed?
2021-09-30 18:53:15 <ddevault> unmatched
2021-09-30 18:53:22 <Ariadne> oh right unmatched
2021-09-30 18:53:23 <ddevault> unleashed doesn't have PCIe unless you use that awful expansion board
2021-09-30 18:53:28 <Ariadne> sorry i get the two mixed up
2021-09-30 18:53:30 <ddevault> np
2021-09-30 18:53:35 <ddevault> https://gitlab.freedesktop.org/drm/amd/-/issues/1725
2021-09-30 18:53:37 <Ariadne> i have the unleashed without expansion board
2021-09-30 18:53:39 <ddevault> will investigate when I'm not tired
2021-09-30 18:54:11 <minimal> Ariadne: indeed, that's basically what I said to them (also mentioned about timezone changes, GPS-related issue in Oct, other potential cert expiry issues in certstore, etc)
2021-09-30 18:55:16 <minimal> don't think they're a company, he didn't mention what exactly they are, sounded like a volunteer org
2021-09-30 18:59:43 <ikke> https://gitlab.alpinelinux.org/kdaudt/apk-tools/-/releases
2021-09-30 19:00:26 <ikke> :-)
2021-09-30 19:01:16 <jvoisin> >  This tag has no release notes. 
2021-09-30 19:01:18 <jvoisin> </3
2021-09-30 19:01:31 <ikke> It's just a test :-)
2021-09-30 19:02:05 <Ariadne> all the CVEs were fixed obviously
2021-09-30 19:02:08 <ikke> :
2021-09-30 19:02:11 <ikke> :D
2021-09-30 19:02:11 <Ariadne> even the ones not in apk
2021-09-30 19:03:12 <ikke> The noteworthy thing is that the release contains static apk binaries, something which was missing since we moved to gitlab
2021-09-30 19:07:45 <minimal> ikke: v1.2.3? I guess that's a dummy version number as well rather than the expected v2.13.0?
2021-09-30 19:08:01 <ikke> yes
2021-09-30 19:08:06 <ikke> check the project namespace
2021-09-30 19:08:31 <ikke> It's not an official release, this was just me testing to see if / how it works
2021-09-30 19:08:34 <minimal> doh! right, your own repo :-)
2021-09-30 20:24:37 <JuniorJPDJ> what should I do if community package needs new dep not being in repo?
2021-09-30 20:24:50 <JuniorJPDJ> move package to testing and add new dep to testing?
2021-09-30 20:25:06 <JuniorJPDJ> as new version of telegram-desktop needs rnnoise which is not in repo now
2021-09-30 20:33:40 <clandmeter> you can add a new pkg to community in the same MR as you upgrade the other pkg.
2021-09-30 20:53:54 <JuniorJPDJ> so entirely skipping testing is a good idea? cool :D
2021-09-30 20:55:02 <clandmeter> in this situation its acceptable
2021-09-30 20:55:23 <dalias> *nod*
2021-09-30 20:58:52 <maxice8> Ikke: nice