2020-02-01 13:08:20 <tboerger[m]> Funny, discovered the adoptopenjdk booth at fosdem in Brussel, wanted to talk about musl support, and directly had another one talking to them about exactly the same. πŸ˜‚
2020-02-01 13:09:56 <tboerger[m]> I will join the adoptopenjdk slack to kick off some conversation how to get it rolling for musl
2020-02-01 13:56:40 <Cogitri> Ah heh, just wanted to write the same thing :P
2020-02-01 14:47:25 <north1> Someone with good understanding of English grammar please take a look at https://wiki.alpinelinux.org/wiki/Bootloaders#systemd-boot
2020-02-01 14:49:29 <mps> north1: I read it, and don't have think it is not understandable
2020-02-01 14:50:25 <mps> and I'm not native (and not good at the end) English speaker
2020-02-01 16:46:00 <dsmster> so is anyone here cross compiling to alpine on rpi4 with either rust or dlang ?   or have a example of setting up the environment; just starting myself and thinking the only issue i might run into w/alpine is the musl difference ?
2020-02-01 16:51:24 <mps> dsmster: alpine aarch64 runs on different arm64 computers
2020-02-01 16:52:30 <mps> do you want to cross build on some arch (x86_64) programs for aarch64 or?
2020-02-01 16:52:55 <dsmster> mps: ack ; right now I am setting up the tools so I can build my own rust programs for rpi without building them on rpi
2020-02-01 16:53:31 <mps> alpine doesn't support cross build (yet)
2020-02-01 16:53:52 <mps> you can try with qemu
2020-02-01 16:54:00 <dsmster> ahh okay, I'm going to try the build from fedora and see if I can at least get a binary to run on alpine/rpi4 / aarch64
2020-02-01 16:55:11 <mps> if it is worth for you, I build a lot of aarch64 programs on alpine but on arm64 box
2020-02-01 16:55:50 <dsmster> mps: which hardware is your arm64 box?
2020-02-01 16:56:37 <mps> samsung chromebook, rockchip rk3399 with 4GB ram and usb ssd
2020-02-01 16:57:52 <dsmster> mps: oh cool, thanks for the ideas
2020-02-01 16:58:44 <Cogitri> Crossbuilding Rust should probably work if you don't need native C deps though
2020-02-01 17:00:08 <mps> Cogitri: what about 'D'
2020-02-01 17:01:17 <dsmster> Cogitri: yep, that's what I'm trying right now, just trivial program ; i installed the toolchains and first build just failed due to crti.o and Scrt1.o as expected but at least it compiled, now to get it to link :-)
2020-02-01 17:01:56 <dsmster> the ldc version of D appears to also be easy to cross compile but I will try that after seeing about rust first
2020-02-01 17:02:02 <mps> dsmster: for simple programs you can try with musl-cross-make, it is on github
2020-02-01 17:02:19 <dsmster> mps: cool, hadn't heard of that, thx
2020-02-01 17:02:23 <mps> and not only simple
2020-02-01 17:12:50 <dsmster> got rust working :-)
2020-02-01 17:13:02 <dsmster> from x86/fedora -> rpi4/aarch64
2020-02-01 17:23:52 <Cogitri> mps: D should be the same as for C since you can compile with ldc (so like clang) or GDC (so like gcc)
2020-02-01 17:24:55 <Cogitri> Sadly ldc isn't in such great shape for armv7& aarch64 apparently (at least on musl), but I suppose there's work being done for that
2020-02-01 17:25:44 <mps> it is new in gcc tools, hope it will be better in (not distant) future
2020-02-01 17:28:14 <Cogitri> D support was merged in GCC 9 so yeah, it's kinda new
2020-02-01 17:34:10 <dsmster> yeah i heard they were happy they made it in gcc9 last year
2020-02-01 17:36:26 <dsmster> this is all i did here, pretty simple for rust at least for trivial stuff:  https://gitlab.com/snippets/1935492
2020-02-01 21:43:23 <^7heo> so, why is syslinux only built for x86(_64)?
2020-02-01 21:44:58 <north1> I think upstream only supports those arches
2020-02-01 21:45:00 <_ikke_> 22feca30239cd13efe86d93219da12dbb4e9d9ca
2020-02-01 21:45:07 <_ikke_> not really documented why
2020-02-01 21:45:31 <north1> Use systemd-boot :D they support all but s390x, armhf and ppc64le
2020-02-01 21:45:57 <mps> :)
2020-02-01 21:46:15 <mps> what's next systemd-home?
2020-02-01 21:46:34 <north1> no, because that is part of systemd and needs systemd to run
2020-02-01 21:46:47 <north1> while systemd-boot can run without systemd, and i am in fact running it, without systemd.
2020-02-01 21:46:55 <_ikke_> it's just a bootloader
2020-02-01 21:47:02 <_ikke_> that has been adopted by systemd
2020-02-01 21:47:07 <_ikke_> it used to be called gummiboot
2020-02-01 21:47:16 <north1> yes, don't we have gummitboot still ?
2020-02-01 21:47:21 <_ikke_> dunno
2020-02-01 21:47:27 <mps> eh, good reason to package complete systemd ;)
2020-02-01 21:47:45 <^7heo> mps: ------>[]
2020-02-01 21:47:50 <mps> _ikke_: yes, i know history
2020-02-01 21:48:39 <north1> it is in main/gummiboot :D
2020-02-01 21:49:08 <mps> yes, yes ......
2020-02-01 21:51:57 <north1> @mps you joke but NixOS and OpenEmbedded have patches for systemd on musl
2020-02-01 21:54:41 <mps> huh, really? didn't know
2020-02-01 21:54:55 <north1> yes
2020-02-01 21:55:20 <north1> NixOS has a whole musl RFC
2020-02-01 21:56:09 <mps> (all roads leads to Rome^WBSD)
2020-02-01 23:22:10 <north1> Any objections to !3511 ?
2020-02-01 23:24:59 <clandmeter> any specific reason to add it?
2020-02-01 23:27:40 <north1> It works nicer than gummiboot, works, and has patches by OpenEmbedded and NixOS
2020-02-01 23:28:25 <clandmeter> I think we can remove gummiboot, i dont think it works on all arches we need.
2020-02-01 23:28:39 <clandmeter> at least not when i tried
2020-02-01 23:29:28 <north1> gummiboot is set only on x86_64 and x86 i think they work on x86_64
2020-02-01 23:29:53 <clandmeter> well its not maintained.
2020-02-01 23:30:23 <north1> systemd-boot works on all arches gnu-efi works and i think systemd 244
2020-02-01 23:30:40 <north1> gummiboot also works on aarch64 and arm32 from what i remember
2020-02-01 23:30:59 <clandmeter> i think i tried it, it has issues to build or similar.
2020-02-01 23:31:35 <clandmeter> those patches for systemd-boot will not be accepted upstream right?
2020-02-01 23:32:04 <north1> Most of them no
2020-02-01 23:32:56 <clandmeter> I have no problem with it, but i think it will be hard to maintain in the long run.
2020-02-01 23:32:56 <mps> it is not good idea to depend on such bootloader, imo
2020-02-01 23:33:55 <clandmeter> but its a bootloader, so its anybody's choice to use it or not.
2020-02-01 23:34:31 <mps> yes, if it not become default
2020-02-01 23:34:44 <clandmeter> i dont think so
2020-02-01 23:35:00 <north1> It won't, i don't plan on it passing from community ever
2020-02-01 23:35:15 <clandmeter> would be nice to have support for efibootmgr
2020-02-01 23:35:24 <clandmeter> user kernel stub directly
2020-02-01 23:35:31 <clandmeter> use*
2020-02-01 23:35:32 <mps> I'm not against to put it in testing and we will see later
2020-02-01 23:36:17 <mps> maybe community, as north1 proposed
2020-02-01 23:38:02 <mps> my fears are mostly from seeing such number of patches
2020-02-01 23:38:31 <clandmeter> check grub on other distros :)
2020-02-01 23:38:39 <clandmeter> not sure how many we ship now
2020-02-01 23:38:39 <mps> heh
2020-02-01 23:39:02 <clandmeter> gazillion platform fixes
2020-02-01 23:39:11 <north1> I just cherry-picked all patches from NixOS musl
2020-02-01 23:39:13 <mps> we have 3 for grub
2020-02-01 23:40:32 <north1> I believe those are enough for everything, not just sd-boot
2020-02-01 23:41:51 <mps> well, we have a packages with a lot of patches, so sd-boot is not special in that case
2020-02-01 23:42:56 <mps> afaik, main issue with anything systemd is that upstream is reluctant to accept them
2020-02-01 23:43:25 <clandmeter> i dont think we have a lot of pkgs that are needed which are not accepted by upstream.
2020-02-01 23:44:08 <north1> Yes, there are just lot where nobody upstreams it or upstream doesn't accept because they don't really exist anymore
2020-02-01 23:44:24 <mps> I would prefer less of them
2020-02-01 23:46:46 <clandmeter> i think chromium is one of them.
2020-02-01 23:46:52 <clandmeter> its also a headache to maintain
2020-02-01 23:47:12 <mps> yes
2020-02-01 23:47:30 <clandmeter> there were some users who wanted to add an additional patch set. ungoogle it or whatever it was.
2020-02-01 23:47:38 <clandmeter> adds another layer or madness
2020-02-01 23:47:48 <mps> year ago I tried and after week or two ceased
2020-02-01 23:48:18 <clandmeter> I added it initially with help of dalias.
2020-02-01 23:48:45 <clandmeter> but it gets boring real quick due to fast moving parts and incompatible with musl.
2020-02-01 23:49:15 <clandmeter> so now ncopa handles all the fun :)
2020-02-01 23:49:17 <mps> yes, understand you
2020-02-01 23:50:29 <mps> chromium currently have 23 patches
2020-02-01 23:50:43 <clandmeter> was there a known issue with python3 tests, or is it just terrible slow?
2020-02-01 23:52:04 <mps> don't know much about python, but few days ago were discussion on #mus about it
2020-02-01 23:52:33 <mps> looks like ncopa found solution for so called 'slow python on alpine'
2020-02-01 23:52:48 <clandmeter> i remember something was discussed. not sure what it was about.
2020-02-01 23:53:05 <clandmeter> but test_asyncio takes ages
2020-02-01 23:54:40 <clandmeter> north1: did you see any issue with python3 tests?
2020-02-01 23:54:51 <mps> I didn't had time to closely follow discussion but as I understood solution is on horizon
2020-02-01 23:55:51 <north1> @clandemeter they would take a lot of time but i usually resolved that by leaving my stuff open while i play Hearts of Iron IV
2020-02-01 23:56:00 <mps> I'm more concentrated on time64 for new musl
2020-02-01 23:56:39 <clandmeter> i dont play games, so that is pita :)
2020-02-02 00:22:50 <north1> Anyways, so the main objection is that there are lots of patches that are not going to be upstream any time in the future ?
2020-02-02 00:34:26 <clandmeter> im not against it, i would simply not advise it. maybe others have different or more detailed arguments.
2020-02-02 00:37:18 <clandmeter> the patches tell the story about upstream, who does not want to support us.
2020-02-02 00:39:01 <clandmeter> its late, time for bed.
2020-02-02 00:39:43 <mps> also here, good night :)
2020-02-02 04:45:01 <north1> Hmm, maybe i can go without systemd-boot by just using EFISTUB
2020-02-02 04:46:09 <north1> Also DELL EFI implementation on Inpiron 5566 is super good
2020-02-02 05:52:11 <north1> yeah, decided to use gummiboot EFI stub loader.
2020-02-02 07:48:36 <pltrz> pickfire: tlp is broken [https://gitlab.alpinelinux.org/alpine/aports/issues/11181]
2020-02-02 07:53:48 <pltrz> nevermind, it's broken upstream
2020-02-02 08:20:30 <pickfire> pltrz: Huh? broken?
2020-02-02 08:20:54 <pickfire> Looks like I did not test whether it works since I am not using tlp on alpine anymore.
2020-02-02 08:21:15 <pickfire> https://github.com/linrunner/TLP/issues/459
2020-02-02 08:22:39 <pickfire> Now I mainly run alpine on raspberry pi which is not able to use tlp. If you want, you may like to take ownership of the package since I cannot test it?
2020-02-02 08:23:09 <pickfire> I used to use alpine linux on laptop but I stopped since I am not able to use any IME to insert chinese or japanese characters.
2020-02-02 09:27:19 <AinNero> pickfire: i cant reproduce that issue
2020-02-02 09:29:26 <AinNero> ah, got it
2020-02-02 09:29:45 <AinNero> the alpine package `tlp` has an unregistered dependency on perl
2020-02-02 09:30:12 <AinNero> ah, north1 wrote the same in the ticket
2020-02-02 10:14:41 <Cogitri> ncopa: We need some sweet Alpine merch for next year's FOSDEM :P
2020-02-02 10:15:51 <^7heo> Guys, there's a bug in the setup-interfaces script.
2020-02-02 10:16:32 <^7heo> if it fails to scan the WiFi, and you keep going, it will add one interface block per try, at the end of the procedure.
2020-02-02 10:16:35 <^7heo> let
2020-02-02 10:16:51 <^7heo> let's say, for example, that the WiFi scan failed 5 times, succeeded on the 6th.
2020-02-02 10:17:54 <^7heo> then, at the end of the procedure, you will have 6 times the two lines: auto wlan0\niface wlan0 inet dhcp
2020-02-02 10:19:17 <^7heo> terror-: can you please fix your connection?
2020-02-02 10:19:33 <^7heo> actually, it seems you will have 6 times ALL the blocks. Including auto loand auto eth0
2020-02-02 10:20:18 <^7heo> just to be clear, I'm reporting that here, feel free to open a bug, I won't.
2020-02-02 10:38:37 <markand> hmmm, I have hplip failing to build with
2020-02-02 10:38:42 <markand> install: will not overwrite just-created '/home/markand/dev/aports/testing/hplip/pkg/hplip/usr/share/ppd/HP/apollo-2100.ppd.gz' with 'ppd/hpcups/apollo-2100.ppd.gz'
2020-02-02 11:09:23 <AinNero> pickfire: can i take the tlp package from you?
2020-02-02 11:09:51 <AinNero> most of my stuff is thinkpads, and i use them mobile becaue i dont have a smartphone
2020-02-02 11:10:01 <AinNero> havent heard of tlp until now tho
2020-02-02 13:25:07 <pickfire> AinNero: Sure, I do use thinkpad here too but I stopped because no IME. T_T
2020-02-02 13:25:50 <pickfire> There is some possibilities to fix that but we need to change quite some core stuff, very troublesome to do.
2020-02-02 13:25:55 <AinNero> does IME have some specific requirements?
2020-02-02 13:26:06 <pickfire> AinNero: Do you know what is IME?
2020-02-02 13:26:12 <AinNero> no
2020-02-02 13:26:25 <pickfire> Input Method
2020-02-02 13:26:38 <pickfire> Something that you are required to use to insert CJK characters.
2020-02-02 13:26:46 <AinNero> okay, then its not the Intel Management Engine
2020-02-02 13:26:52 <pickfire> Yeah
2020-02-02 13:26:58 <AinNero> does it have special requirements?
2020-02-02 13:27:02 <AinNero> to the hardware?
2020-02-02 13:27:29 <pickfire> No
2020-02-02 13:27:32 <pickfire> Software
2020-02-02 13:27:53 <pickfire> That is why china using the same keyboard as US.
2020-02-02 13:28:04 <AinNero> ah, and you stopped using alpine, not stopped using thinkpads because of IME?
2020-02-02 13:28:05 <pickfire> But I use ANSI here, I prefer ISO.
2020-02-02 13:28:12 <pickfire> Yeah
2020-02-02 13:28:31 <pickfire> There is one musl-based distro is able to get that working.
2020-02-02 13:28:34 <pickfire> noname-linux
2020-02-02 13:29:47 <pickfire> Ah, the requirement is to use native intl instead of the one in gettext IIRC
2020-02-02 13:39:35 <pickfire> https://github.com/xhebox/noname-linux/blob/master/ports/gettext-tiny/Pkgfile#L13
2020-02-02 14:22:23 <north1> @mps there won't be a systemd-boot, decided to go with EFISTUB Unified Kernel Images with gummiboot https://www.cogitri.dev/post/04-secure-boot-with-unified-kernel-image/
2020-02-02 14:25:10 <markand> oh this flood
2020-02-02 14:27:18 <mps> north1: yes, I see. but again don't take my opinion to heart
2020-02-02 14:29:11 <mps> to repeat, I'm not against it in testing (or maybe community) but I still have fear that it will be hard to maintain not because of you but because of upstream
2020-02-02 14:33:25 <Cogitri> Yes, keeping the patches up to date would probably be a massive pain
2020-02-02 14:34:45 <north1> I just cherry-picked from NixOS musl
2020-02-02 15:05:23 <pltrz> pickfire: sure, I can take over maintainership. I will update the package template. fyi it was just missing a dependency on perl :P
2020-02-02 15:08:42 <pickfire> Ah
2020-02-02 15:09:00 <pickfire> pltrz: AinNero also want to take over the ownership too.
2020-02-02 15:09:19 <AinNero>  /want/, i was considering it because it seems useful for me
2020-02-02 15:09:23 <AinNero> running it rn
2020-02-02 15:13:23 <pltrz> doesn't matter to me, I am just cleaning up the APKBUILD now
2020-02-02 16:48:14 <vkrishn> hi
2020-02-02 16:48:36 <vkrishn> how can I get api of notes, eg https://gitlab.alpinelinux.org/api/v4/projects/1/issues/3282/notes
2020-02-02 16:49:25 <vkrishn> tried generating PRIVATE-TOKEN, but does not work
2020-02-02 16:50:09 <vkrishn> api link https://gitlab.alpinelinux.org/help/api/notes.md#get-single-issue-note
2020-02-02 17:03:41 <_ikke_> testing has 113 packages depending on extra-cmake-modules that are not disabled on armhf yet
2020-02-02 17:07:13 <Cogitri> Oof
2020-02-02 17:07:52 <_ikke_> apparently armhf is quite behind
2020-02-02 17:08:00 <_ikke_> testing built:  207
2020-02-02 17:08:08 <_ikke_> 207 packages still need to be build
2020-02-02 17:08:12 <_ikke_> for testing
2020-02-02 17:10:03 <Cogitri> Yeah, it has been stuck due to qtdeclarative for some time
2020-02-02 17:16:07 <_ikke_> https://tpaste.us/0PoK
2020-02-02 17:20:18 <vkrishn> ok got it :)
2020-02-02 17:26:12 <Cogitri> _ikke_: thanks for taking care of that
2020-02-02 18:40:34 <_ikke_> armhf seems to be running now
2020-02-02 18:40:40 <_ikke_> lets see what it fails on next
2020-02-02 18:40:57 <_ikke_> 70 packages to go
2020-02-02 18:41:17 <Cogitri> So a maximum of 70 failures + dependencies :P
2020-02-02 18:44:04 <_ikke_> heh
2020-02-02 18:50:33 <Cogitri> PSA: I'd like to merge !3542 later this evening which will block the builders for a little
2020-02-02 18:52:35 <Cogitri> Also, what's the status of stable CI?
2020-02-02 19:01:25 <_ikke_> Cogitri: in my todolist :D
2020-02-02 19:02:13 <Cogitri> Ah, okay :9
2020-02-02 19:02:22 <Cogitri> Well, I guess the builders shall be my CI then :P
2020-02-02 19:05:26 <mps> could be good idea :)
2020-02-02 19:06:36 <mps> though not full CI
2020-02-02 20:23:20 <_ikke_> new sudo CVE: https://www.sudo.ws/alerts/pwfeedback.html (only vulnerable if you have pwfeedback enabled)
2020-02-02 20:29:28 <_ikke_> Cogitri: gprbuild cannot be built becuase mirrors.cdn.adacore.com does not resolve
2020-02-02 20:30:44 <Cogitri> Yes, seems like the site is down right now
2020-02-02 20:31:00 <_ikke_> dns is 'down'
2020-02-02 21:43:56 <clandmeter> north1: ping
2020-02-02 21:48:41 <clandmeter> north1: 78e034feccb9cac171e950b4832d4e2d1395226f breaks some things which depends on libtasn1
2020-02-02 22:28:53 <PureTryOut[m]> The aarch64 Gitlab CI is stuck
2020-02-02 22:31:40 <clandmeter> PureTryOut[m]: are you sure?
2020-02-02 22:31:50 <clandmeter> aarch64 is really busy
2020-02-02 22:34:52 <PureTryOut[m]> Well the CI says on my MR that it's stuck
2020-02-02 22:41:19 <clandmeter> PureTryOut[m]: ah i found it
2020-02-02 22:41:33 <clandmeter> it crashed due to oom
2020-02-02 22:41:54 <clandmeter> sigh, it has 128G and still ooms
2020-02-02 22:42:03 <clandmeter> what a world we live in
2020-02-02 22:44:09 <clandmeter> PureTryOut[m]: should be back again
2020-02-02 23:01:45 <mps> 'brave new world' - Miranda - Thempest, Shakespeare
2020-02-02 23:02:35 <mps> interesting, here father is name Prospero. coincidence?
2020-02-02 23:08:54 <clandmeter> Cogitri: did ceph pass on CI?"
2020-02-02 23:09:43 <mps> her father* (sorry for OT)
2020-02-02 23:50:07 <clandmeter> bb xz does not support -z?
2020-02-02 23:51:04 <AinNero> might be the default
2020-02-02 23:51:21 <clandmeter> it is, but it bails out if used
2020-02-03 00:15:53 <north1> @clandmeter ack, should revert ?
2020-02-03 00:50:32 <craftyguy> is it possible to define the 'provides' for a subpackage? something like 'depends_dev'-->depends for -dev subpackage, but 'provides_dev' --> provides for -dev package
2020-02-03 00:50:52 <north1> dev() { provides= ; default_dev ; }
2020-02-03 00:51:37 <craftyguy> ah, so instead of unsetting provides there, I could define it as something else too
2020-02-03 00:52:00 <north1> yes, that is just a quick example to show you can set variables inside their subpkg function
2020-02-03 00:52:12 <craftyguy> north1: awesome, thanks a lot :)
2020-02-03 00:52:38 <north1> see the _py3() in community/xxhash/APKBUILD for an example
2020-02-03 00:53:47 <craftyguy> 
ACTION looks

2020-02-03 06:49:53 <Cogitri> clandmeter: Can't tell since CI always runs out of memory with ceph and so do all of my machines :c
2020-02-03 06:50:26 <Cogitri> Pinged J0WI about it already
2020-02-03 07:15:58 <_ikke_> And it's not that these CI builders are short on memory
2020-02-03 07:57:46 <mps> gnuchess is in main, games in main? (besides it buggy and have not needed uclibc patch)
2020-02-03 07:59:34 <north1> probably added before there were different repos ?
2020-02-03 07:59:40 <north1> but yeah, it should be in community/
2020-02-03 08:01:26 <mps> ncopa: ^
2020-02-03 08:01:54 <north1> imo main/ should be much much smaller than community
2020-02-03 08:02:03 <mps> agree
2020-02-03 08:02:43 <mps> few times I asked why we have irc clients in main
2020-02-03 08:03:26 <_ikke_> same answer
2020-02-03 08:03:36 <_ikke_> still there from before the split
2020-02-03 08:04:16 <mps> though I understand that someone want to have irc (text mode) client on server and use it over ssh
2020-02-03 08:04:38 <mps> (as i do)
2020-02-03 08:05:01 <_ikke_> It should not be an issue to get that from community, though
2020-02-03 08:05:31 <mps> yes, just wanted to say that, but you are faster (as usual) :)
2020-02-03 08:10:54 <clandmeter> north1: i think watch out for failures do to the change.
2020-02-03 08:11:02 <clandmeter> -dev does not pull in -progs
2020-02-03 08:12:55 <north1> I see, i thought it was the upgrade itself making bad libraries
2020-02-03 08:15:14 <clandmeter> Cogitri: yes this is why the aarch64 runner crashed
2020-02-03 08:15:27 <clandmeter> because of ceph memory madness
2020-02-03 08:16:35 <north1> @clandmeter !3657
2020-02-03 08:19:13 <clandmeter> that would solve the issue
2020-02-03 08:19:33 <north1> Yes
2020-02-03 08:19:45 <clandmeter> im not sure what the progs do, are they usable without -dev anyways?
2020-02-03 08:20:32 <clandmeter> do we currently have a best practices document?
2020-02-03 08:21:05 <north1> Only a coding style that is subject to change
2020-02-03 08:21:20 <north1> !4
2020-02-03 08:21:29 <clandmeter> one thing which would be nice to add is naming of regular pkgs
2020-02-03 08:21:38 <clandmeter> we see lots of -progs and -utils :)
2020-02-03 08:21:39 <north1> There is some sorta of agreement
2020-02-03 08:21:55 <north1> prefer -libs over lib<libname>, which i disagree in some cases.
2020-02-03 08:22:02 <north1> i don't remember about -progs and -utils
2020-02-03 08:22:31 <clandmeter> right, i dont care much, but having them similar would be less confusing
2020-02-03 08:22:41 <mps> and -static for libs is questionable
2020-02-03 08:22:52 <clandmeter> -static is defined in abuild
2020-02-03 08:23:01 <clandmeter> like -dev -doc -openrc
2020-02-03 08:23:18 <clandmeter> but it can be included in the list.
2020-02-03 08:23:23 <mps> yes, I know, but still think it is not good
2020-02-03 08:23:37 <clandmeter> ah i read you wrong
2020-02-03 08:23:44 <clandmeter> its questionable you say
2020-02-03 08:24:08 <mps> imo, static libs should go in -dev
2020-02-03 08:24:34 <clandmeter> did you add an issue about it?
2020-02-03 08:24:58 <north1> @mps static libs going into -static saved my ass when  packaging a s6 upgrade
2020-02-03 08:25:21 <north1> on Void we keep it in -dev because you might as well
2020-02-03 08:26:20 <mps> it is confusing, at least
2020-02-03 08:26:51 <clandmeter> for fun i was trying to rebuild world and it seems im bumping into samurai issues
2020-02-03 08:28:44 <clandmeter> https://tpaste.us/MbEv
2020-02-03 08:29:02 <clandmeter> wonder if its some circular dependency
2020-02-03 08:31:09 <_ikke_> fg
2020-02-03 08:32:25 <clandmeter> ?
2020-02-03 08:33:57 <clandmeter> Cogitri: the ceph update also removed the boost fix from src but patch is still in the tree.
2020-02-03 08:34:12 <clandmeter> i think that patch is needed to solve the build error
2020-02-03 08:41:55 <_ikke_> clandmeter: apparently this is not a terminal
2020-02-03 08:47:57 <clandmeter> Cogitri: maybe it makes sense to temporary disable ceph as it will hammer builders.
2020-02-03 08:48:56 <clandmeter> _ikke_: you can try, type sudo and afterwards your password. i will confirm if it worked.
2020-02-03 08:49:06 <_ikke_> sudo
2020-02-03 08:49:08 <_ikke_>  
2020-02-03 08:49:13 <clandmeter> *****
2020-02-03 08:49:20 <_ikke_> hunter9
2020-02-03 08:49:20 <clandmeter> yes it matched :)
2020-02-03 09:37:33 <^7heo> I read '53cr37'
2020-02-03 09:37:37 <^7heo> that's weird.
2020-02-03 09:41:41 <PureTryOut[m]> Hmm the openrct2 package gives me a "BAD signature" warning. Why does that happen?
2020-02-03 09:41:59 <_ikke_> PureTryOut[m]: dl-cdn?
2020-02-03 09:42:34 <_ikke_> can confirm btw
2020-02-03 09:43:50 <_ikke_> Not sure if that's the issue (I would not expect so), but I see the last push did not increase pkgrel
2020-02-03 09:43:57 <PureTryOut[m]> yes
2020-02-03 09:44:20 <_ikke_> so it would not have been rebuilt
2020-02-03 09:44:51 <PureTryOut[m]> Shouldn't give a bad signature though
2020-02-03 09:45:00 <_ikke_> nope, I would not expect so
2020-02-03 09:45:37 <_ikke_> normally this happens when a package is reverted without increasing pkgrel
2020-02-03 09:47:09 <^7heo> I managed to install alpine to a rpi "on disk" with a modified install script (will send you the patch later when I'm at such a point that it works well enough); but I now am dropping to shell in the initramfs, as it complains that "Mounting boot media failed"
2020-02-03 09:47:23 <_ikke_> PureTryOut[m]: I purged the package on dl-cdn, now it's ok again
2020-02-03 09:47:28 <^7heo> Any idea what the initramfs is executing that prompts me with this error and drops a shell?
2020-02-03 10:00:59 <north1> @clandmeter I'm at german class, won't be coming back for 7 hours.
2020-02-03 10:01:15 <_ikke_> Nach sowas
2020-02-03 10:02:44 <clandmeter> Grüß Gott
2020-02-03 10:03:57 <^7heo> north1: mindestens
2020-02-03 10:04:20 <^7heo> north1: viel spass!
2020-02-03 10:04:29 <^7heo> spaß*
2020-02-03 10:04:40 <^7heo> (forgot I set compose up)
2020-02-03 10:04:46 <_ikke_> ß
2020-02-03 10:04:47 <_ikke_> heh
2020-02-03 10:05:21 <^7heo> _ikke_: great that you have it, so when I don't, do you mind being at my command and outputting it every time I need to copy it?
2020-02-03 10:05:24 <^7heo> 
ACTION hides

2020-02-03 10:05:29 <north1> I found out only very recently you can write ß by using Alt-gr + s
2020-02-03 10:05:45 <_ikke_> For me it's Alt-gr + s s
2020-02-03 10:06:04 <_ikke_> setxkbmap -option compose:ralt
2020-02-03 10:06:07 <north1> I used to have it in a file and I would have a keybind to do wl-copy on the file so I could paste it
2020-02-03 10:06:36 <clandmeter> im going to upgrade gitlab
2020-02-03 10:06:39 <minecrell> ẞ
2020-02-03 10:07:02 <^7heo> _ikke_: I set the compose key to menu
2020-02-03 10:07:13 <^7heo> but basically, same idea.
2020-02-03 10:07:17 <^7heo> say, guys
2020-02-03 10:07:53 <^7heo> I dunno if you've read what I wrote above; but: I mount my root partition in /sysroot of the initramfs, I mount the boot partition in /sysroot/boot, and continue booting
2020-02-03 10:08:02 <^7heo> it still does NOT find the /sysroot/etc/inittab
2020-02-03 10:08:06 <^7heo> while I can definitely ls it.
2020-02-03 10:08:11 <^7heo> that is weird, no?
2020-02-03 10:09:18 <^7heo> and now, there's a tmpfs mounted on /sysroot
2020-02-03 10:09:25 <^7heo> I really need to find what's doing this
2020-02-03 10:10:00 <^7heo> that's fucking nuts.
2020-02-03 10:10:07 <^7heo> I managed to boot
2020-02-03 10:10:11 <^7heo> but it's shanky AF.
2020-02-03 10:10:42 <north1> What is shanky?
2020-02-03 10:10:48 <^7heo> the boot process.
2020-02-03 10:10:54 <^7heo> the initramfs or whatever script it runs.
2020-02-03 10:11:01 <north1> I mean, what does shanky means?
2020-02-03 10:11:29 <^7heo> https://www.merriam-webster.com/dictionary/skanky
2020-02-03 10:11:48 <north1> Oh, it was a typo
2020-02-03 10:12:23 <north1> I googled shanky and it gave me a urban dictionary definition and a Wikipedia page for an Indian professional wrestler
2020-02-03 10:13:33 <^7heo> ahahah nice.
2020-02-03 10:13:37 <^7heo> care to share that page?
2020-02-03 10:22:31 <north1> Just Google shanky and It should appear
2020-02-03 10:23:01 <^7heo> I don't google.
2020-02-03 10:23:38 <^7heo> _ikke_: do you know who's in charge of that rpi stuff?
2020-02-03 10:23:47 <^7heo> _ikke_: ncopa? clandmeter?
2020-02-03 10:25:11 <clandmeter> afaik nobody is "in charge" or similar.
2020-02-03 10:25:18 <_ikke_> right
2020-02-03 10:25:33 <^7heo> so who do I ask to know what script is doing the initramfs setup?
2020-02-03 10:25:47 <mps> ^7heo: create bug report with logs and your changes
2020-02-03 10:26:06 <^7heo> mps: no, that's the sheep version, I don't wanna waste so much time.
2020-02-03 10:26:10 <^7heo> mps: I fix my own problems.
2020-02-03 10:26:19 <clandmeter> its the same for regular alpine
2020-02-03 10:26:25 <^7heo> clandmeter: fine
2020-02-03 10:26:25 <clandmeter> the only diff is the kernel
2020-02-03 10:26:36 <clandmeter> alpine runs from ram by default
2020-02-03 10:26:41 <^7heo> yeah, if there's no disk found.
2020-02-03 10:26:45 <clandmeter> until you specify root device
2020-02-03 10:26:49 <^7heo> and if you find a disk, it prompts you to use it.
2020-02-03 10:26:51 <^7heo> if not, ram.
2020-02-03 10:26:53 <^7heo> got it.
2020-02-03 10:27:05 <^7heo> I patched the install scripts for that task, so I know what it is doing.
2020-02-03 10:27:23 <^7heo> but the question is: initramfs is running something at boot, I would love to know what it is.
2020-02-03 10:27:29 <clandmeter> a lof of rpi users will be happy to have a disk install option
2020-02-03 10:27:30 <mps> add 'mmcblk' devices to setup--disk
2020-02-03 10:27:42 <^7heo> clandmeter: it works with the RPI3+ atm.
2020-02-03 10:27:57 <clandmeter> there are docs on wiki how to kind of hack it
2020-02-03 10:27:59 <^7heo> clandmeter: I need to manually mount stuff at boot tho, the boot script does not do that right.
2020-02-03 10:28:15 <^7heo> clandmeter: no, I patched setup-disk so you don't need to.
2020-02-03 10:28:32 <clandmeter> i know, im just pointing you to all i know what we have now.
2020-02-03 10:28:33 <^7heo> clandmeter: as I wrote above, I will send my patch when this works fine.
2020-02-03 10:28:36 <^7heo> clandmeter: ok :P
2020-02-03 10:28:54 <clandmeter> and all ive seen until now is a big hack :)
2020-02-03 10:29:01 <^7heo> yeah, I get that.
2020-02-03 10:29:11 <^7heo> but so, if you're aware of what script initramfs fires, I'd be super happy.
2020-02-03 10:29:20 <^7heo> until then, I'll read the list of files in initramfs.
2020-02-03 10:30:03 <^7heo> I guess it is running /init first.
2020-02-03 10:30:08 <^7heo> just a guess but...
2020-02-03 10:30:13 <mps> yes
2020-02-03 10:30:33 <mps> did you recreated initramfs after install
2020-02-03 10:30:39 <^7heo> mps: no.
2020-02-03 10:30:46 <^7heo> mps: the install script is supposed to, no?
2020-02-03 10:30:56 <mps> yes
2020-02-03 10:31:01 <^7heo> I mean, I am seeing it doing it, so the question is pretty pointless.
2020-02-03 10:31:09 <^7heo> but sanity check.
2020-02-03 10:31:21 <^7heo> ok well
2020-02-03 10:31:28 <^7heo> I'll debug that later.
2020-02-03 10:31:34 <mps> but if you did something with patched install script maybe it didn't
2020-02-03 10:32:01 <mps> just giving hint, not a solution
2020-02-03 10:32:06 <^7heo> clandmeter: also, one meta question: when doing an install script for alpine, is it acceptable to require people to read a doc' and copy a bunch of files over themselves (firmwares, dtb files, etc)?
2020-02-03 10:32:27 <^7heo> clandmeter: or shall the script do that to avoid a sea of noobs on #alpine-linux asking all the damn time?
2020-02-03 10:32:51 <^7heo> mps: my patch for the install script is only for the bootloader part so far, so it does not crash.
2020-02-03 10:32:59 <clandmeter> would be nice if the script can handle it.
2020-02-03 10:32:59 <^7heo> mps: it works almost entirely out of the box.
2020-02-03 10:33:02 <^7heo> clandmeter: ok.
2020-02-03 10:33:05 <_ikke_> If a script *can* do it, why require users to figure it out themselves?
2020-02-03 10:33:09 <clandmeter> are you preparing a new script?
2020-02-03 10:33:15 <clandmeter> or adding it to current one
2020-02-03 10:33:20 <^7heo> _ikke_: because it would require to modify the setup-disk script even further.
2020-02-03 10:33:33 <^7heo> clandmeter: modifying the setup-* ones.
2020-02-03 10:33:52 <mps> kernel pkg by default installs all modules, dtb's, dtbo's
2020-02-03 10:34:06 <clandmeter> ^7heo: https://gitlab.alpinelinux.org/alpine/mkinitfs/blob/master/initramfs-init.in
2020-02-03 10:34:13 <clandmeter> thats the init we use
2020-02-03 10:34:19 <^7heo> yeah foud it.
2020-02-03 10:34:21 <clandmeter> not sure you refer to this one?
2020-02-03 10:34:21 <^7heo> found it*
2020-02-03 10:34:35 <^7heo> well, I'm reading it as we speak
2020-02-03 10:34:35 <clandmeter> it will do the switchroot
2020-02-03 10:35:27 <^7heo> but I got it doing: cp /boot/initramfs-rpi .; mv initramfs-rpi initramfs-rpi.gz; gunzip initramfs-rpi.gz; cpio -i init initramfs-rpi
2020-02-03 10:35:47 <^7heo> I guess that's the same script tho.
2020-02-03 10:36:00 <^7heo> anyhow.
2020-02-03 10:36:14 <^7heo> will read that, and will come back to you when I have found what fucks up.
2020-02-03 10:37:17 <^7heo> the Entry Point of the script is line 301, correct?
2020-02-03 10:37:32 <^7heo> (I'm reading it in a tty, it's slow af and refreshes badly, so I'd love if you could confirm :))
2020-02-03 10:37:49 <clandmeter> i thjink so
2020-02-03 10:37:53 <^7heo> thx
2020-02-03 10:38:04 <clandmeter> i wonder how you will run the installer?
2020-02-03 10:38:08 <clandmeter> from usb?
2020-02-03 10:38:10 <clandmeter> and instll to sd?
2020-02-03 10:38:22 <^7heo> basically, the RPI3+ can boot straight up from usb
2020-02-03 10:38:34 <clandmeter> yes, but thats only for recent versions
2020-02-03 10:38:35 <^7heo> but yeah, for the other versions, I'll work later on a way to set a sdcard up so it boots usb.
2020-02-03 10:39:09 <^7heo> for now, I have a RPI3+ I need to do last week with "something" on it that runs well enough so since netbsd can't run x64 on that yet, alpine it is.
2020-02-03 10:39:19 <clandmeter> i have not touched rpi since rpi4 is introduced
2020-02-03 10:39:34 <^7heo> basically, there's this: https://github.com/pbatard/RPi3
2020-02-03 10:39:50 <^7heo> so I am thinking of using this to allow people to run the usb key from the sdcard boot
2020-02-03 10:39:53 <^7heo> OR
2020-02-03 10:40:04 <^7heo> use/code a simple bootstrap bin.
2020-02-03 10:40:19 <^7heo> but I'm not there yet.
2020-02-03 10:40:24 <^7heo> for now I want to make it work for the RPI3+
2020-02-03 10:40:49 <^7heo> which it does, given that you input the right mount commands at boot when you get maintenance shells.
2020-02-03 10:40:57 <^7heo> but that's not cool.
2020-02-03 10:41:33 <clandmeter> maybe for rpi,, shipping a disk image would be nice.
2020-02-03 10:41:43 <clandmeter> similar to what other rpi based projects do
2020-02-03 10:41:45 <^7heo> that is what other systems do.
2020-02-03 10:41:55 <mps> is it possible to run x64 on any RPi
2020-02-03 10:41:57 <^7heo> with an auto-resize of the partition.
2020-02-03 10:42:01 <^7heo> mps: no.
2020-02-03 10:42:01 <clandmeter> when it boots it would resize root
2020-02-03 10:42:11 <^7heo> mps: only RPI3B and above.
2020-02-03 10:42:12 <clandmeter> reboot and be done
2020-02-03 10:42:33 <^7heo> clandmeter: that is exactly what netbsd does.
2020-02-03 10:42:35 <AinNero> could be done as part of the regular boot process i think
2020-02-03 10:42:44 <mps> you mean arm64 and not x64?
2020-02-03 10:42:50 <^7heo> clandmeter: wget file.img; dd if=file.img of=/dev/mmcblk0
2020-02-03 10:43:01 <^7heo> mps: sorry, I meant 64 bit, you're correct.
2020-02-03 10:43:08 <clandmeter> i think ncopa has talked about shipping disk images before
2020-02-03 10:43:10 <^7heo> mps: so used to work on x86*
2020-02-03 10:43:23 <^7heo> clandmeter: it would be extra work on your end to set them up tho.
2020-02-03 10:43:31 <^7heo> clandmeter: but sure, it would be a lot easier for users.
2020-02-03 10:43:46 <mps> netbsd announced that it will have full arm64 support in next release
2020-02-03 10:44:09 <clandmeter> having it in setup-xxx would be nice too, except with the above limitations/issues
2020-02-03 10:44:51 <^7heo> mps: yes, but the problem with that is that they don't have hugo built for that arch so...
2020-02-03 10:45:05 <clandmeter> AinNero: if we ship them with new releases, including it in the regular boot process sounds sane.
2020-02-03 10:45:09 <^7heo> mps: I'm basically stuck with that hugo problem, I need a *cheap* machine that it can run on, for a customer.
2020-02-03 10:45:15 <mps> clandmeter: yes, we discussed idea about disk images but after some time I started to think it would require a lot more people than we have for arm
2020-02-03 10:45:19 <^7heo> mps: and that has been the problem for a long time now (two weeks?)
2020-02-03 10:45:26 <^7heo> so, yeah, fuck go and amateur devs.
2020-02-03 10:45:32 <^7heo> go was made by google, FOR GOOGLE.
2020-02-03 10:45:39 <^7heo> everyone else, please stay clear of it.
2020-02-03 10:45:46 <^7heo> </rant>
2020-02-03 10:46:08 <clandmeter> im not here for rants, so please keep them for offtopic
2020-02-03 10:46:30 <^7heo> so back, to the topic (yes), it seems that nlplug-findfs is doing the mounting of the boot media
2020-02-03 10:46:54 <clandmeter> yes for tmpfs it will fidn the magic file
2020-02-03 10:47:00 <^7heo> well it does not.
2020-02-03 10:47:11 <clandmeter> does the kernel know the fs?
2020-02-03 10:47:13 <mps> well, I installed manually alpine armhf, armv7 aarch64 on some number of boxes, sys mode
2020-02-03 10:47:15 <clandmeter> fstype
2020-02-03 10:47:26 <^7heo> clandmeter: not sure how the kernel is supposed to know the fstype.
2020-02-03 10:47:29 <^7heo> clandmeter: so I can't answer that.
2020-02-03 10:47:40 <clandmeter> it should have t he modujle in initramfs
2020-02-03 10:47:50 <^7heo> it definitely has the vfat module, no?
2020-02-03 10:47:54 <mps> in '/etc/mkinitifs/mkinitfs.conf'
2020-02-03 10:47:58 <clandmeter> and you can load it with modules=
2020-02-03 10:48:11 <^7heo> I'd be flabbergasted if the initramfs didn't load vfat.
2020-02-03 10:48:25 <^7heo> or do you need to explicitely set it?
2020-02-03 10:48:26 <clandmeter> findfs will search devices, check if it can mount it, mounts it and searches for magic file x deep.
2020-02-03 10:48:31 <mps> why it would
2020-02-03 10:48:33 <clandmeter> first match with be mounted afaik
2020-02-03 10:48:45 <^7heo> mps: because it literally is the simplest and most common "fs" aroud.
2020-02-03 10:48:49 <^7heo> around*
2020-02-03 10:48:58 <^7heo> clandmeter: k
2020-02-03 10:49:03 <^7heo> but maybe that's it.
2020-02-03 10:49:13 <clandmeter> turn on logging of findfs
2020-02-03 10:49:20 <clandmeter> and grab popcorn
2020-02-03 10:49:24 <^7heo> clandmeter: where?
2020-02-03 10:49:33 <clandmeter> check initramfs opts
2020-02-03 10:49:35 <^7heo> maybe the setup scripts are supposed to set the vfat module to load, and don't.
2020-02-03 10:49:38 <^7heo> clandmeter: ok
2020-02-03 10:49:58 <^7heo> clandmeter: I guess I need to modify my initramfs?
2020-02-03 10:50:09 <clandmeter> i think the setup scripts try to be smart
2020-02-03 10:50:14 <mps> my current u-boot extlinux.conf line for one box with linux-lts 'APPEND modules=sd-mod,usb-storage,ext4,f2fs,sunxi-mmc root=/dev/mmcblk0p2 rw rootwait console=${console}'
2020-02-03 10:50:22 <clandmeter> they will check what is currently loaded and include it.
2020-02-03 10:50:36 <mps> no vfat
2020-02-03 10:51:01 <^7heo> clandmeter: hmm
2020-02-03 10:51:47 <^7heo> ok so, there's a file called cmdline.txt and it lists a list of modules.
2020-02-03 10:52:01 <^7heo> literally loop,squashfs,sd-mod,usb-storage
2020-02-03 10:52:04 <^7heo> and nothing else.
2020-02-03 10:52:09 <^7heo> I guess I'll edit that.
2020-02-03 10:52:26 <clandmeter> thats the regular rpi bootloader config
2020-02-03 10:52:38 <AinNero> it definitely has the vfat module
2020-02-03 10:52:40 <^7heo> yeah but if that loads it, won't the initramfs also do so?
2020-02-03 10:52:45 <^7heo> nope.
2020-02-03 10:52:53 <AinNero> otherwise it couldnt mount the boot partition with the repository
2020-02-03 10:52:57 <AinNero> and it could never boot diskless
2020-02-03 10:53:28 <^7heo> I was hoping for something magical here.
2020-02-03 10:53:33 <^7heo> ah well.
2020-02-03 10:54:11 <AinNero> modules=loop,squashfs,sd-mod,usb-storage and booting into diskless from FAT32
2020-02-03 10:54:17 <AinNero> here
2020-02-03 10:54:37 <mps> also here on RPi zero
2020-02-03 10:55:31 <mps> though I changed it to 'modules=loop,squashfs,sd-mod,usb-storage dwc_otg.lpm_enable=0 console=tty1 console=ttyAMA0,115200'
2020-02-03 10:55:42 <mps> to use serial console
2020-02-03 10:55:53 <^7heo> I don't want to use serial, I don't have a cable for it yet.
2020-02-03 10:56:33 <mps> it is 'rescue' console, with this it still use display
2020-02-03 10:57:13 <^7heo> ok it boots.
2020-02-03 10:57:21 <^7heo> I was right, modifying the cmdline.txt is magical.
2020-02-03 10:57:44 <AinNero> the rpi bootloader binary reads the cmdline.txt during boot
2020-02-03 10:58:13 <AinNero> comparable to exlinux.conf
2020-02-03 10:58:28 <mps> AinNero: true
2020-02-03 10:59:17 <clandmeter> only the boot partition needs to be fat
2020-02-03 10:59:26 <^7heo> yeah the root is ext4.
2020-02-03 10:59:51 <^7heo> clandmeter: the only thing is, the setup-disk does not fdisk the proper type when setting vfat for a partition.
2020-02-03 10:59:58 <^7heo> clandmeter: I believe this is a bug and should be patched.
2020-02-03 11:00:22 <clandmeter> probably due to EFI?
2020-02-03 11:00:54 <^7heo> also there is that bug that I mentionned the other day that when you have an existing network config, the installer appends stuff to it, which means: if you rerun setup-interfaces multiple times, you end up with bogus data input and a bogus config file.
2020-02-03 11:01:07 <^7heo> you may want to create the relevant bug reports
2020-02-03 11:01:28 <Cogitri> clandmeter: ah yes, I can take care of it once I'm home
2020-02-03 11:01:29 <^7heo> I'll now try to nuke my sd card.
2020-02-03 11:01:37 <^7heo> and reinstall from scratch with the new method I got.
2020-02-03 11:04:37 <minecrell> the CI lint runner seems to have not enough space to clone aports
2020-02-03 11:05:02 <clandmeter> _ikke_: ^
2020-02-03 11:14:43 <Cogitri> Which runner?
2020-02-03 11:14:59 <Cogitri> Or rather, could you send the URL to the job?
2020-02-03 11:15:01 <^7heo> clandmeter: so, I just nuked my sdcard and installed it once again with that patch + a TODO list of 7 items, and it boots just fine.
2020-02-03 11:15:43 <^7heo> basically the rpi bootloader does a lot.
2020-02-03 11:15:44 <minecrell> Cogitri: delta.ikke.info (https://gitlab.alpinelinux.org/Minecrell/aports/-/jobs/44416)
2020-02-03 11:17:16 <Cogitri> Thanks
2020-02-03 11:17:40 <clandmeter> Cogitri: somebody already reported it in infra
2020-02-03 11:18:03 <clandmeter> but i think _ikke_ was confused about which step
2020-02-03 11:18:22 <clandmeter> the idea is to move it to "official" runners
2020-02-03 11:18:33 <clandmeter> the one that crash all the time /o\
2020-02-03 11:23:01 <Cogitri> Ah, okay
2020-02-03 11:26:41 <_ikke_> clandmeter: what did I confuse?
2020-02-03 11:30:18 <clandmeter> _ikke_: you mention it was x86 build which had enough space
2020-02-03 11:30:26 <clandmeter> but its your linter that has ran out
2020-02-03 11:31:13 <_ikke_> ah, oops
2020-02-03 11:31:29 <clandmeter> run that script :)
2020-02-03 11:32:10 <_ikke_> The cleanup scripts?
2020-02-03 11:33:16 <clandmeter> yeah
2020-02-03 11:33:19 <clandmeter> from cron
2020-02-03 11:33:27 <clandmeter> docker system prune
2020-02-03 11:33:31 <_ikke_> yea
2020-02-03 12:24:17 <clandmeter> kaniini: i had issues yesterday download pkgconf releases
2020-02-03 12:24:22 <clandmeter> not sure it has been solved already
2020-02-03 12:40:12 <_ikke_> Cogitri: fyiqt5-qtwebkit is failing on most builders
2020-02-03 12:40:21 <_ikke_> s/fyi/fyi /
2020-02-03 12:40:21 <alpine-meetbot> _ikke_ meant to say: Cogitri: fyi qt5-qtwebkit is failing on most builders
2020-02-03 12:42:48 <Cogitri> Ah yes, just in the process of fixing thst
2020-02-03 12:43:01 <_ikke_> thanks
2020-02-03 12:43:16 <Cogitri> PureTryOut[m]: Does KDE still need qt5-webkit?
2020-02-03 12:43:24 <Cogitri> It'd be nice if we could purge it
2020-02-03 12:43:40 <PureTryOut[m]> No it hasn't for a long time.
2020-02-03 12:43:48 <PureTryOut[m]> Why purge it though? It's being updated again nowadays
2020-02-03 12:45:09 <Cogitri> Oh, it is? I thought it was as dead as it gets
2020-02-03 12:46:16 <Cogitri> And at least our aport seems to be of concerning age considering it's a browser engine
2020-02-03 12:47:36 <alexeymin> there is KDEWebkit framework in "porting aids" section of https://api.kde.org/frameworks/index.html that still uses QtWebkit I think: https://cgit.kde.org/kdewebkit.git/tree/CMakeLists.txt#n19
2020-02-03 12:48:19 <alexeymin> The question is if kdewebkit is packaged and is something really using it
2020-02-03 12:48:38 <Cogitri> It us packaged, I saw that when greping for qtwebkit
2020-02-03 12:48:42 <Cogitri> s/us/is/
2020-02-03 12:48:42 <alpine-meetbot> Cogitri meant to say: It is packaged, I saw that when greping for qtwebkit
2020-02-03 12:48:52 <Cogitri> Which is why I've asked if KDE still needs qtwebkit
2020-02-03 12:49:19 <Cogitri> Seems like the last commit to the qtwebkit repo has been in December 2019
2020-02-03 12:51:03 <alexeymin> porting aids are deprecated, so I don't know how to answer "does KDE need qtwebkit".
2020-02-03 12:51:06 <alexeymin> qtwebkit is not very alive I think
2020-02-03 12:52:01 <alexeymin> in general, no doesn't need, but if there is some old software that still uses it, then yes?
2020-02-03 12:53:35 <alexeymin> I think I heard various kde4 porting aid frameworks should be removed with KF6 release
2020-02-03 12:56:35 <Cogitri> The build should be fixed for now, but it'd be nice if we got rid of qtwebkit by 3.12 I suppose
2020-02-03 13:13:14 <tboerger[m]> ncopa: are the current icedtea openjdk patches taken from https://openjdk.java.net/projects/portola/?
2020-02-03 13:13:41 <ncopa> tboerger[m]: dont know
2020-02-03 13:13:50 <ncopa> check git log
2020-02-03 13:13:54 <ncopa> it could also be the other way around
2020-02-03 13:15:43 <tboerger[m]> if i get it right these had been the efforts to get openjdk working on musl/alpine.
2020-02-03 13:44:17 <Cogitri> ncopa: Could you take a look at the abuild MRs?
2020-02-03 13:57:58 <clandmeter> Cogitri: your jobs are now running on the new ci runner
2020-02-03 13:58:16 <clandmeter> let me know if you see issues, i think the performance should increase a bit.
2020-02-03 14:01:24 <tboerger[m]> https://github.com/AdoptOpenJDK/openjdk-build is used to build adoptopenjdk, i will try to get used to it and start building it manually on alpine, than we will see if it's getting working easily or not. after that it's hopefully possible to see how well this can get integrated as a realy package,
2020-02-03 15:15:57 <Cogitri> clandmeter: Ah, thanks
2020-02-03 15:16:19 <Cogitri> tboerger[m]: Feel free to ask here if you need help with packaging :)
2020-02-03 15:16:50 <tboerger[m]> i will do when i start with it
2020-02-03 15:34:49 <tboerger[m]> many parts i could copy from the other openjdk packages, first it must get musl compatible.
2020-02-03 15:47:18 <clandmeter> kaniini: im having troubles with samurai
2020-02-03 15:47:43 <kaniini> what troubles?
2020-02-03 15:48:33 <kaniini> clandmeter: ^
2020-02-03 15:48:53 <clandmeter> https://tpaste.us/MbEv
2020-02-03 15:53:19 <clandmeter> kaniini: if i have both local and remote repos in repos file, it will get above result.
2020-02-03 15:53:50 <kaniini> not loading for me
2020-02-03 15:54:27 <clandmeter> http://dpaste.com/0V8NXGR.txt
2020-02-03 15:55:00 <kaniini> looks like
2020-02-03 15:55:04 <kaniini> apk bug
2020-02-03 15:55:14 <kaniini> cuz there's 2 samurai packages
2020-02-03 15:55:17 <kaniini> 1 in your local repo
2020-02-03 15:55:18 <kaniini> 1 remote
2020-02-03 15:58:20 <clandmeter> so its a provides (virtual) issue?
2020-02-03 16:00:47 <kaniini> ya
2020-02-03 16:01:05 <kaniini> i'll dig into it
2020-02-03 16:01:07 <kaniini> tonight
2020-02-03 16:01:14 <kaniini> right now i am dealing with some bullshit
2020-02-03 16:04:45 <clandmeter> i talked to ncopa, he would prefer direct dependency to samurai instead of using provides (having ninja as an alternative option)
2020-02-03 17:42:51 <clandmeter> kaniini: if you are going to look into apk internals, mind adding a different return code to apk search -x?
2020-02-03 17:44:04 <clandmeter> would be nice to do apk search -x foobar || echo foobar not found
2020-02-03 17:53:41 <craftyguy> when submitting a MR to add some packages where some are dependencies for others in the group of new packages, do folks generally prefer 1 MR per package or submit them all (~4) in one MR since you can't really build some without the others?
2020-02-03 17:54:23 <Cogitri> Please submit all of them in one MR if they're required for each other
2020-02-03 18:04:17 <craftyguy> Cogitri: thanks
2020-02-03 18:29:43 <AinNero> it recently came to my mind that the busybox coreutils/util-linux applets dont really have documentation or a manpage
2020-02-03 18:29:53 <AinNero> except for the busybox --help text itself
2020-02-03 18:30:07 <dalias> i'm having a font rendering problem i just noticed, not sure how long it's been there but now i can't unsee it
2020-02-03 18:31:33 <dalias> Dejavu @ 16px with hinting (any kind at all) enabled is rendering the points at the tops of the 1 and 4 glyphs to extend significantly (maybe 2 pixels) above the tops of other numerals
2020-02-03 18:32:02 <dalias> this is happening in firefox; haven't tested other applications
2020-02-03 18:32:45 <mps> hm, I don't have this problem, anyone else can test this
2020-02-03 18:33:54 <AinNero> is this in the firefox chrome or in a website?
2020-02-03 18:33:55 <mps> what is your (hm) 'DE'
2020-02-03 18:34:20 <dalias> i have antialiasing enabled, no subpixel
2020-02-03 18:34:55 <dalias> xfce but with everything forced from .fonts.conf (tested with or without it) makes no diff
2020-02-03 18:35:02 <dalias> in a website
2020-02-03 18:35:14 <dalias> simple html, no font markup at all
2020-02-03 18:35:19 <mps> my .Xresources 'Xft.antialias:  True'
2020-02-03 18:35:21 <dalias> (default font & size)
2020-02-03 18:35:47 <mps> and 'Xft.hinting:  True'
2020-02-03 18:36:25 <dalias> i'm not using .Xresources; i have them in my .fonts.conf but the defaults in /etc/fonts do the same
2020-02-03 18:36:37 <AinNero> i just typed the following into my url bar and now i see it as well, data:text/html,<p>1234567890</p>
2020-02-03 18:36:46 <mps> my wife uses xfce, will look on her notebook when I come back to home
2020-02-03 18:37:20 <dalias> at first i thought the font had been modified to have those hideous styled numerals like old printed books
2020-02-03 18:37:21 <AinNero> https://w1r3.net/paste/RkCsCU.png
2020-02-03 18:37:27 <dalias> with mismatched ascent/descent
2020-02-03 18:37:37 <dalias> but nope, with hinting disabled it all goes away
2020-02-03 18:38:04 <dalias> yep that's what i see
2020-02-03 18:38:07 <mps> but she didn't told me anything, and I know she will if she isn't pleased with her notebook :)
2020-02-03 18:39:06 <dalias> maybe it's some UB in freetype that got optimized by newer gcc...
2020-02-03 18:39:49 <mps> 'UB'?
2020-02-03 18:40:00 <Cogitri> Undefined Behaviour
2020-02-03 18:40:13 <mps> heh, thanks
2020-02-03 18:43:28 <mps> hmm, right. something is really wrong with fonts in some cases
2020-02-03 18:49:12 <mps> it looks better with ttf-freefont
2020-02-03 18:50:54 <dalias> well i *like* dejavu and want it. i just dont want it being misrendered so painfully.
2020-02-03 18:58:29 <_ikke_> Cogitri: I've merged the MR for CI on stable branches. Please let me know whether it's fixed or not
2020-02-03 18:59:01 <mps> dalias: you are using serif fonts
2020-02-03 19:01:16 <dalias> yes
2020-02-03 19:01:57 <mps> first thing when installing firefox I change all fonts to sans
2020-02-03 19:02:51 <mps> in FF 'fonts and colors' settings
2020-02-03 19:10:41 <AinNero> im with the serifs her
2020-02-03 19:10:44 <AinNero> *here
2020-02-03 19:11:01 <dalias> mps, thats nice. anyway about the bug...
2020-02-03 19:11:05 <dalias> any idea what it could be?
2020-02-03 19:13:09 <mps> I have no idea, guessing probably something font renderer
2020-02-03 19:13:48 <mps> or some option for xft
2020-02-03 19:14:32 <mps> subpixel or hinting, or lcd settings
2020-02-03 19:14:58 <Cogitri> Well, the rendering library would be Pango for FF
2020-02-03 19:16:28 <mps> Cogitri: does pango reneders fonts for evince also
2020-02-03 19:17:14 <mps> I'm 'irritated' with some fonts in evince
2020-02-03 19:21:38 <dalias> pango lays text out; it doesn't do the rendering
2020-02-03 19:21:52 <dalias> and i dont think it's used anymore by firefox
2020-02-03 19:21:58 <dalias> at least not for document
2020-02-03 19:22:09 <dalias> i have no subpixel or lcd settings at all
2020-02-03 19:22:23 <dalias> as originally reported, with any hinting on the bug happens
2020-02-03 19:22:30 <dalias> with hinting fully disabled it goes away
2020-02-03 19:28:48 <mps> hm, we have subpixel.patch in freetype pkg
2020-02-03 19:29:02 <mps> anyone know why
2020-02-03 19:31:49 <dalias> not sure but i doubt it's related
2020-02-03 19:36:30 <mps> hmm, it is introduced long time ago, with cc0e1d47180c780dec1424b4030842710a9dac74
2020-02-03 19:37:13 <mps> Sat Jul 28 12:35:12 2018
2020-02-03 20:06:53 <PureTryOut[m]> Ok on postmarketOS we just _can't_ get the logic right on how to fork a package, but only pull it in when actually required and specified as a dependency, and otherwise just pull in the main package from the Alpine repos. We've been messing with `provides` and `replaces` way too much. Could somebody explain us how to do it properly? See this comment on a MR for details on how it breaks currently
2020-02-03 20:06:54 <PureTryOut[m]> https://gitlab.com/postmarketOS/pmaports/-/merge_requests/924#note_281115043
2020-02-03 20:08:30 <vkrishn> how is gitlab.a.o being installed, al pkgs are available ?
2020-02-03 20:09:15 <vkrishn> gee! seems algibot is evolving everyday
2020-02-03 20:10:30 <vkrishn> i heard someone mention "im going to upgrade gitlab" :)
2020-02-03 20:11:34 <_ikke_> No, not as packages
2020-02-03 20:11:38 <_ikke_> it's a docker image (multiple)
2020-02-03 20:11:56 <mps> vkrishn: algitbot learned about gitlab.a.o for some time
2020-02-03 20:12:18 <_ikke_> vkrishn: https://github.com/alpinelinux/alpine-docker-gitlab
2020-02-03 20:12:55 <vkrishn> thanks, looking at it
2020-02-03 20:13:25 <vkrishn> mps: I mean smart equation ' => ' ;)
2020-02-03 20:14:06 <mps> that's long time ago
2020-02-03 20:15:49 <vkrishn> hmm, ok, algibot kinda hides in log files, so did not notice
2020-02-03 20:17:02 <mps> someone should teach it 'gl.a.o', I dislike to type 'gitlab' :)
2020-02-03 20:17:58 <_ikke_> heh
2020-02-03 20:30:01 <PureTryOut[m]> Is it possible to skip a Python unit test? πŸ€”
2020-02-03 20:30:22 <_ikke_> Depends on what framework is used
2020-02-03 20:30:24 <_ikke_> usually yes
2020-02-03 20:30:47 <_ikke_> I generally just google the <framework> skip test
2020-02-03 20:31:09 <_ikke_> sometimes you have to patch it to skip it
2020-02-03 20:31:46 <PureTryOut[m]> Well it's just setup.py, pytest is not in the deps
2020-02-03 20:32:10 <_ikke_> setup.py is like a makefile in that regard
2020-02-03 20:32:27 <_ikke_> you can look inside to find out what it's calling
2020-02-03 20:36:08 <mps> north1: I see you upgraded libinput. do you know should be xf86-input-libinput rebuilt with upgraded libinput version
2020-02-03 20:37:25 <mps> oh, sorry it was J0WI
2020-02-03 20:41:06 <PureTryOut[m]> Hmm seems this package doesn't have a way to skip tests... Guess I have to disable them entirely then...
2020-02-03 20:41:22 <_ikke_> PureTryOut[m]: what package?
2020-02-03 20:41:59 <PureTryOut[m]> https://github.com/psf/black
2020-02-03 20:42:03 <PureTryOut[m]> I have it packaged locally
2020-02-03 20:43:26 <mps> anyone can help me to add tarball from gitweb to source in APKBUILD
2020-02-03 20:43:48 <_ikke_> PureTryOut[m]: seems to by standard python unittest
2020-02-03 20:43:50 <mps> this one https://git.ozlabs.org/?p=ppp.git;a=summary
2020-02-03 20:44:18 <PureTryOut[m]> _ikke_: I don't see a way to skip one in unittest though
2020-02-03 20:44:31 <_ikke_> PureTryOut[m]: You can add (with a patch) @unittest.skip("..") decoration
2020-02-03 20:44:48 <_ikke_> https://docs.python.org/3.8/library/unittest.html#skipping-tests-and-expected-failures
2020-02-03 20:47:35 <PureTryOut[m]> I don't really want to patch it though 😭
2020-02-03 21:41:04 <_ikke_> fyi, I'm trying to adjust the gitlab ci build so that it's less heavy. If you notice anything broken, please let me know
2020-02-03 21:53:03 <craftyguy> PureTryOut[m]: thanks for asking here about the 'support multiple versions of the same package' thing, I was going to ask but saw you beat me to it :P
2020-02-03 21:53:35 <PureTryOut[m]> Well, nobody really responded sadly πŸ˜›
2020-02-03 21:55:06 <craftyguy> I was looking at what Arch Linux does in AUR (mesa-git effectively replaces mesa), they use 'conflicts', which sounds analogous to APKBUILD's 'provides' in some ways
2020-02-03 21:55:28 <_ikke_> conflicts is more like depends="!mesa"
2020-02-03 21:55:35 <craftyguy> so there must be some implementation details in Arch's pacman vs apk that cause one to cleanly replace the other?
2020-02-03 21:55:47 <craftyguy> oh I see
2020-02-03 21:56:32 <_ikke_> I think if you do provides="mesa=$pkgver-$pkgrel", than it should automatically replace it
2020-02-03 21:56:42 <minecrell> craftyguy: Arch Linux has it somewhat easier, it doesn't have so sophisticated subpackages
2020-02-03 21:56:53 <_ikke_> PureTryOut[m]: do you know about install_if?
2020-02-03 21:56:55 <minecrell> you just replace mesa with mesa-git, not all subpackage combinations
2020-02-03 21:57:05 <PureTryOut[m]> Yes, what about it?
2020-02-03 21:57:18 <_ikke_> PureTryOut[m]: was reading about your question earlier
2020-02-03 21:57:45 <PureTryOut[m]> _ikke_: thing is, we want to specify only in certain device packages that mesa-git has to be used. Every other device has to use regular mesa
2020-02-03 21:57:59 <PureTryOut[m]> And when packages get built (that are not device packages), they should use mesa-dev, not mesa-git-dev
2020-02-03 21:58:14 <craftyguy> in cases where mesa-git is installed, if someone wants to install mesa-dev, ideally it would install mesa-git-dev
2020-02-03 21:58:37 <craftyguy> but right now it pulls in mesa-dev, which requires mesa, which conflicts with mesa-git
2020-02-03 21:59:03 <_ikke_> I don't think replaces would help with that
2020-02-03 21:59:12 <_ikke_> that only has to do with file ownership
2020-02-03 21:59:15 <craftyguy> yeah, it doesn't, as we've found out
2020-02-03 22:00:32 <craftyguy> so we (or, definitely me) are kind of at a loss as to how to support a repo that has both mesa (+ mesa- subpackages) and mesa-git (+ mesa-git- subpackages) and have the right subpackage pulled in depending on what version of the main package is installed
2020-02-03 22:00:54 <_ikke_> So I think in the first place you want to create a virtual package that can be satisfied by either mesa or mesa-git
2020-02-03 22:01:02 <_ikke_> (just thinking out load)
2020-02-03 22:01:07 <_ikke_> s/load/loud/
2020-02-03 22:01:07 <alpine-meetbot> _ikke_ meant to say: (just thinking out loud)
2020-02-03 22:02:22 <_ikke_> provides basically has 2 modes
2020-02-03 22:02:44 <_ikke_> provides="foo" creates a virtual package foo
2020-02-03 22:03:11 <_ikke_> if some kind of package depends on foo, that package will fulfill that
2020-02-03 22:05:39 <craftyguy> I see, so are we in some undefined territory by setting 'provides="mesa"' for mesa-git, since mesa is a real package?
2020-02-03 22:06:13 <_ikke_> Yes, I think so. I'm not certain how apk will react to that
2020-02-03 22:06:22 <_ikke_> would be better to create some kind of meta package name
2020-02-03 22:06:27 <craftyguy> in the repo, there would effectively be 2 'mesa' packages, the real one and the virtual one created by mesa-git using provides
2020-02-03 22:07:15 <craftyguy> I'm not sure what that would look like though, because 'mesa' and its subpackages would need to maintain those same names, so we don't have to change every single APKBUILD that depends on mesa, right?
2020-02-03 22:07:34 <craftyguy> but our virtual package would also want to have those names, since it can get picked up
2020-02-03 22:07:44 <MartijnBraam> I think one of our mesa-git issues is that provides="mesa-dev" doesn't fix packages that have a requirement on mesa-dev=18.9
2020-02-03 22:11:36 <_ikke_> If packages depend on mesa, I'm not sure if it's possible to selectively have mesa or mesa-git
2020-02-03 22:12:29 <craftyguy> yeah that's kind of what I was afraid of
2020-02-03 22:13:13 <craftyguy> that's also why I'm curious how pacman seems to be OK with supporting this situation
2020-02-03 22:13:17 <_ikke_> is it possible to rename mesa, and then provides=mesa
2020-02-03 22:13:44 <craftyguy> yeah I was thinking of doing something like that when you mentioned having a virtual
2020-02-03 22:14:17 <craftyguy> might not be too much effort if all we do is rename the package.. it'll just have to be sync'd to upstream aports periodically
2020-02-03 22:14:48 <_ikke_> Someone knowing more about the apk internals might have a better solution
2020-02-03 22:15:15 <craftyguy> _ikke_: fair enough. I appreciate the ideas
2020-02-03 22:15:15 <_ikke_> Have you considered asking this on the mailing list? (perhaps even the apk-tools mailing list)
2020-02-03 22:15:56 <craftyguy> I can do that
2020-02-03 22:17:39 <craftyguy> nice, I didn't realize the lists were running on a self hosted(?) sr.ht
2020-02-03 22:17:56 <craftyguy> oof, registration is closed
2020-02-03 22:18:33 <_ikke_> craftyguy: you don't need to register to subscribe though
2020-02-03 22:18:51 <_ikke_> craftyguy: note that ddevault set it up himself
2020-02-03 22:18:58 <craftyguy> nice :)
2020-02-03 22:19:06 <craftyguy> do I need to subscribe to post?
2020-02-03 22:19:53 <_ikke_> nope
2020-02-03 22:28:37 <craftyguy> _ikke_: ok I fired a mail off on the list. thanks for the help
2020-02-03 22:30:21 <_ikke_> yw
2020-02-04 08:12:22 <kmmndr> Hi all :-)
2020-02-04 08:13:05 <kmmndr> I'm playing with alpine packages, and I was wondering how to dump information about a package
2020-02-04 08:13:19 <kmmndr> apk info is nice for packages on repositories
2020-02-04 08:14:38 <kmmndr> but if I want to dump informations about a local apk file, is there a way to do it with apk command ?
2020-02-04 08:19:30 <mps> kmmndr: tar xf filename.apk -O .PKGINFO
2020-02-04 08:20:44 <mps> not same as 'apk info' but can be useful
2020-02-04 08:25:25 <kmmndr> Thanks mps :-)
2020-02-04 11:02:15 <mps> ncopa: ppp upgrade to 2.4.8 passed under my radar although I'm subscribed to their ML
2020-02-04 11:02:39 <mps> it needs some work before push to aports
2020-02-04 11:04:03 <ddevault> an op should probably redirect terror to ##fixyourconnection
2020-02-04 11:04:04 <mps> I started but want to ask you (maintainer) if you don't have time I can continue to work on it and test
2020-02-04 11:04:41 <ddevault> /mode +b *!*@192.184.69.111$##fixyourconnection
2020-02-04 11:04:44 <ddevault> like so^
2020-02-04 11:06:40 <mps> heh, looks lime my '/ignore * JOINS PARTS QUITS NICKS' works well, didn't noticed anything :)
2020-02-04 11:07:03 <ddevault> I ignore those too, but they show up when I reconnect and I'm on a shoddy network
2020-02-04 11:08:22 <Cogitri> Just curious: When should we upgrade to what Qt version?
2020-02-04 11:08:38 <Cogitri> I guess 5.14 is the new hotness?
2020-02-04 11:09:32 <mps> ddevault: I noticed that the nick 'terror' kicked from some other channels unrelated to alpine
2020-02-04 11:10:12 <ddevault> perhaps they keep annoying everyone for their lack of a bouncer :)
2020-02-04 11:11:35 <mps> yes, because join, quit and not because of behavior
2020-02-04 12:16:08 <clandmeter> kaniini: did you find time yesterday to look at that apk-tools issue?
2020-02-04 12:16:32 <kaniini> not yet, but i will get to it as soon as i can.  maybe ask fabled to investigate in meantime?
2020-02-04 12:17:04 <kaniini> we just got an email from a big customer saying they want our alpine-based CPE deployed in like a gazillion sites by close of business friday
2020-02-04 12:17:13 <kaniini> so i am sitting here configuring and configuring and configuring and configuring
2020-02-04 13:10:17 <ncopa> clandmeter: can you try set provides_priority=1 in samurai and see if that sovles your problem?
2020-02-04 13:10:21 <ncopa> eg http://tpaste.us/xkrD
2020-02-04 13:10:33 <clandmeter> i thoughty about that
2020-02-04 13:10:44 <clandmeter> but that would introduce it for boht pkgs
2020-02-04 13:11:27 <clandmeter> you want me to commit that to aports?
2020-02-04 13:16:45 <clandmeter> ncopa: i mean it will initially probably work, but when the package gets updated in remote repo both will have similar priority.
2020-02-04 13:18:01 <clandmeter> i think apk does not care about repo order, else it could prefer one higher in the list.
2020-02-04 13:36:45 <kaniini> clandmeter: would it be possible to add iPXE floppy image for alpinelinux.org netboot server btw
2020-02-04 13:36:58 <kaniini> we are dealing with equinix today and they are quite useless
2020-02-04 13:37:41 <clandmeter> need to check if its packaged
2020-02-04 13:37:46 <kaniini> write an image to a USB ? lol!!!!
2020-02-04 13:38:29 <kaniini> please mail us a USB to plug into your server ok
2020-02-04 13:38:33 <kaniini> thx for using equinix
2020-02-04 13:40:03 <clandmeter> kaniini: are you serious about floppy?
2020-02-04 13:40:10 <kaniini> yes
2020-02-04 13:40:33 <kaniini> for whatever reason, our IPMI solution only lets you upload a floppy image
2020-02-04 13:40:42 <kaniini> or mount an ISO over SMB
2020-02-04 13:40:44 <dalias> eew
2020-02-04 13:41:02 <kaniini> this is a new server from a company known as Supermicro
2020-02-04 13:41:02 <dalias> why is managed-server stuff so awful
2020-02-04 13:41:06 <kaniini> you may have heard of them
2020-02-04 13:41:33 <kaniini> new as in literally built in 2020
2020-02-04 13:41:41 <dalias> yes they also disable nice integrated intel video and add on some hideous mga g200 card to hookup to their nasty bmc shit
2020-02-04 13:41:51 <kaniini> supermicro in 2015: you can stream an ISO in their java thing
2020-02-04 13:41:53 <AinNero> kaniini: i think the kernel does not fit on any popular floppy geometry
2020-02-04 13:42:05 <kaniini> AinNero: i'm talking about iPXE
2020-02-04 13:43:44 <xerireu> kaniini: have you looked into if your UEFI firmware support HTTP boot?
2020-02-04 13:44:03 <kaniini> xerireu: oh that is a good idea
2020-02-04 13:44:31 <clandmeter> yeah that should work too, if your firmware is a little sane.
2020-02-04 13:46:46 <kaniini> how would one do an HTTP Boot in UEFI shell then
2020-02-04 13:49:39 <clandmeter> i never used it, i just read that depending on spec it should support it.
2020-02-04 13:50:04 <mps> andypost[m]: do you plan to 'backport' postfix 3.4.9 to 3.11-stable? if you don't have time I can
2020-02-04 13:50:39 <clandmeter> so ipxe has a new stable release
2020-02-04 13:50:47 <clandmeter> thats a new one
2020-02-04 13:52:52 <andypost[m]> mps I'd like to but better ask maintainers
2020-02-04 13:52:52 <clandmeter> kaniini: i just pushed new ipxe
2020-02-04 13:53:03 <clandmeter> you need it on boot server?
2020-02-04 13:53:48 <mps> andypost[m]: well, create MR and assing it to maintainer, that is how I usually do
2020-02-04 13:55:30 <andypost[m]> mps thanks a lot, I will do next time this way
2020-02-04 13:58:05 <mps> andypost[m]: maintainer is ncopa and he is busy these days. usually he ack such 'things'
2020-02-04 13:58:58 <dalias> hmm, i noticed that projects built with cmake want to install crap in /usr/local/lib64
2020-02-04 13:59:16 <dalias> should alpine's cmake package be fixing this so that the libdir is lib instead of lib64?
2020-02-04 13:59:23 <dalias> i just made a symlink to solve it but it's nasty
2020-02-04 13:59:27 <Cogitri> You probably forgot to set the right things during co figure things
2020-02-04 13:59:51 <dalias> well aiui the packages being built get the default paths from cmake
2020-02-04 13:59:53 <Cogitri> Something ala -DCMAKE_INSTALL_LIBDIR
2020-02-04 14:00:02 <dalias> i'm saying the default shouldn't be wrong
2020-02-04 14:00:27 <dalias> cmake has the wacky redhat paths baked into it as defaults rather than the proper ones
2020-02-04 14:01:33 <Cogitri> Well, to be frank, those paths probably apply to more users
2020-02-04 14:02:02 <Cogitri> Setting a sane(r) default seems like a good idea to me, but I'm unsure how much effort this is since I don't know CMake too well
2020-02-04 14:03:29 <dalias> regardless of which makes sense for upstream cmake, distros that don't use whatever upstream cmake does should patch it to do what's right for their fs layout
2020-02-04 14:04:09 <mps> dalias: this sounds as good idea
2020-02-04 14:04:13 <ncopa> i'm open to patch cmake
2020-02-04 14:05:10 <north1> That being, making cmake install to /usr/lib by default?
2020-02-04 14:05:18 <dalias> goodness no
2020-02-04 14:05:24 <dalias> self-compiled stuff can never go in /usr
2020-02-04 14:05:43 <dalias> that's how you clobber (and get your stuff clobbered by) package management
2020-02-04 14:05:58 <ncopa> make it use default CMAKE_INSTALL_LIBDIR to be 'lib' instead of lib64
2020-02-04 14:06:00 <dalias> default prefix is always supposed to be /usr/local, libdir=$prefix/lib
2020-02-04 14:06:08 <dalias> right, what ncopa said
2020-02-04 14:06:24 <ncopa> i think that is what north1 meant :)
2020-02-04 14:06:25 <dalias> note: autoconf does not do this lib64 thing; it does the right $prefix/lib regardless of bitness of arch
2020-02-04 14:06:31 <dalias> ah ok
2020-02-04 14:06:52 <north1> Ah, OK, I'm also open to making it install to prefix/lib
2020-02-04 14:06:58 <dalias> for some reason cmake adopted wacky redhat policy instead of standard  :-p
2020-02-04 14:07:30 <dalias> also i guess aports is overriding this for all the packaged software built by cmake...?
2020-02-04 14:07:40 <dalias> because there's no /usr/lib64
2020-02-04 14:07:46 <north1> Problably RedHat people or people that used RedHat systems that were contributing to cmake to make it happen
2020-02-04 14:07:53 <north1> Yes we set libdir lib
2020-02-04 14:08:25 <ncopa> mps, andypost[m]: i think backporting postifx 3.4.9 sounds like a good idea. (I havent checked the relase notes but i assume it does not break anything)
2020-02-04 14:10:00 <andypost[m]> Yep, few bugfixes
2020-02-04 14:10:49 <Cogitri> dalias: Yes, we specify this for all aports but we do the same thing with other build systems which install into $prefix/lib by default
2020-02-04 14:11:20 <Cogitri> Since newapkbuild takes care of generating the APKBUILDs it's not much of a problem, I suppose
2020-02-04 14:22:02 <dalias> i see
2020-02-04 14:23:12 <mps> ncopa: for some time I want to ask (but forgetting too soon) what is it the reason to make drbd as separate pkg and not use that which is in kernel
2020-02-04 14:24:05 <ncopa> mps: iirc, the upstream maintainer sent patches for that some time ago
2020-02-04 14:24:24 <mps> I used this in kernel tree for more about 15 years and never had issue with it
2020-02-04 14:24:25 <ncopa> its possible that we could use the driver in kernel now
2020-02-04 14:26:18 <mps> one less pkg to maintain and backport, which is upgraded often
2020-02-04 14:45:27 <kmmndr> I'm trying to build a bootable sdcard image for my nas. So far, I've packaged u-boot and linux kernel. It boots but logs on tty stop at one of the first openrc's processes invocation. Any idea ?
2020-02-04 14:49:31 <Cogitri> As in it gets stuck there or goes to a black screen?
2020-02-04 14:49:32 <Cogitri> (Oh also, please ask that in alpine-linux)
2020-02-04 14:52:45 <kmmndr> Cogitri: It's stuck there (no more message on ttyS0 (serial line))
2020-02-04 14:53:10 <kmmndr> Cogitri: (sorry, I'll ask the question on alpine-linux channel)
2020-02-04 16:17:12 <telmich> Good evening
2020-02-04 16:17:55 <north1> hello
2020-02-04 16:18:02 <telmich> On multiple hosts that I wanted to run keepalived on I ran into problems, because the default sysctl sets net.ipv4.conf.default.rp_filter = 1 and net.ipv4.conf.all.rp_filter = 1, basically preventing keepalived from working
2020-02-04 16:18:06 <telmich> I was wondering if it is an option to disable / not set those sysctls by default?
2020-02-04 16:18:40 <north1> Are they unchangeable after being set ?
2020-02-04 16:19:10 <telmich> No, but they have quite ugly site effects: once set all interfaces inherit this value
2020-02-04 16:19:43 <telmich> I've posted the way to reverse it on https://redmine.ungleich.ch/issues/7688
2020-02-04 16:20:21 <north1> Why not have it set the value to 0 again after 00-alpine in /etc/sysctl.d ?
2020-02-04 16:20:24 <telmich> Because one doesn't know which interface exist until they do, everything that is there while it's set to 1 inherits the setting
2020-02-04 16:21:14 <north1> Guess you'll have to edit it by hand then
2020-02-04 16:21:22 <telmich> That would indeed work, but everyone else who tries to run keepalived will run again into the same problem
2020-02-04 16:21:31 <telmich> Also, when the system is one booted, you cannot easily undo it
2020-02-04 16:22:16 <telmich> i.e. let's say I install a new router, it boots up, I configure it by cdist and it sets sysctls correctly - there will be a race condition depending on when the bonding devices are created that they will come up with the wrong rp_filter settings
2020-02-04 16:22:23 <Cogitri> Why do we even install that to /etc/sysctl.s and not /usr/lib/sysctl.d ?
2020-02-04 16:23:42 <north1> @Cogitri alpine didn't catch up to the convention of using stuff in /usr
2020-02-04 16:23:49 <mps> it belongs to /etc/sysctl.d
2020-02-04 16:23:58 <north1> there is still a separate /lib and /bin and /sbin
2020-02-04 16:25:09 <telmich> he - nice follow up discussion, not what I wanted to trigger, but still interesting.
2020-02-04 16:35:48 <Cogitri> Ah right, /lib/sysctl.d or something then
2020-02-04 16:36:15 <Cogitri> mps: Not really, /etc/sysctl.d is for user configuration, distros should install to /usr/lib or similar
2020-02-04 16:36:32 <Cogitri> So users can overwrite that
2020-02-04 16:37:58 <mps> Cogitri: no, it config files should go in /etc
2020-02-04 16:38:03 <telmich> hmm, if I could fully get rid of ipv4, I would not even have that problem... hmm
2020-02-04 16:40:22 <north1> test
2020-02-04 16:40:39 <north1> hmm, my message got blackholed ?
2020-02-04 16:40:49 <mps> north1: I see 'test'
2020-02-04 16:40:58 <north1> yes, that test went well
2020-02-04 16:41:04 <north1> but i sent 2 messages before but they disappeared
2020-02-04 16:41:05 <north1> let me try again
2020-02-04 16:41:23 <north1> @mps /etc is for local admin config which can override upstream or distro configuration present in /usr
2020-02-04 16:42:35 <mps> maybe I'm old fashioned then
2020-02-04 16:42:48 <north1> apologies in advance
2020-02-04 16:42:49 <north1> you're vintage
2020-02-04 17:23:27 <clandmeter> Heh vintage
2020-02-04 17:25:52 <mps> 'vintage'? my dictionary doesn't give sensible answer
2020-02-04 17:27:08 <clandmeter> Lol
2020-02-04 17:29:32 <clandmeter> I guess it means something that's is old but still cool
2020-02-04 17:29:39 <clandmeter> Like you
2020-02-04 17:30:03 <mps> hmm, am I old?
2020-02-04 17:30:15 <_ikke_> You tell us :)
2020-02-04 17:30:31 <mps> 'old fashioned' doesn't mean old :P
2020-02-04 18:27:48 <ncopa> north1: did you see this? e06ca4046c190d734ebea361ba11d6c4b3fb60af im not conviced that was the best solution
2020-02-04 22:11:40 <Cogitri> FWIW, if GNOME packages fail to fetch, there's currently a major outage in GNOME land: https://status.gnome.org/
2020-02-05 00:06:50 <ron__> hello!
2020-02-05 00:07:46 <mps> ron__: hi
2020-02-05 02:35:38 <north1> @ncopa well, i was just transitioning it to python3, if most distros call it python3 gevent3 then so be it. Although i don't see a why to keep compatible between releases.
2020-02-05 02:35:52 <north1> As far as i can tell the only mistake was me not writing on the changelog that breaking change
2020-02-05 02:36:12 <north1> speaking of changelog can it be updated to remove the mention of dxvk ? it is in testing and so it didn't make it into 3.11
2020-02-05 03:44:26 <north1> @Cogitri !3721
2020-02-05 03:44:56 <dalias> :)
2020-02-05 03:45:29 <north1> @dalias :D
2020-02-05 07:57:58 <north1> @ncopa there is a new version of osinfo-db
2020-02-05 07:58:07 <north1> might be worth it to add alpine-3.11
2020-02-05 08:25:26 <clandmeter> morning
2020-02-05 08:25:52 <north1> Morning
2020-02-05 08:27:12 <clandmeter> wie gehts?
2020-02-05 08:28:58 <mps> \o
2020-02-05 08:30:59 <_ikke_> Nicht schlecht
2020-02-05 08:31:24 <mps> looks like we are 'losing' systemd :)
2020-02-05 08:32:06 <_ikke_> We never had systemd
2020-02-05 08:32:14 <_ikke_> :)
2020-02-05 08:33:15 <clandmeter> losing?
2020-02-05 08:33:35 <clandmeter> are you referring to something?
2020-02-05 08:33:51 <mps> _ikke_: reading #alpine-commits this morning I god impression that we had it
2020-02-05 08:34:09 <mps> got*
2020-02-05 08:34:12 <_ikke_> just some systemd unit files
2020-02-05 08:34:37 <_ikke_> inert files
2020-02-05 08:34:53 <mps> _ikke_: you lost sense of humor overnight :)
2020-02-05 08:35:51 <_ikke_> well, some people make a big deal out of systemd :)
2020-02-05 08:39:08 <mps> I see, it is nice to read such number of msgs which says "removing" systemd :)
2020-02-05 08:45:18 <clandmeter> if unit files are properly sub packaged then i see no reason to remove it.
2020-02-05 08:46:20 <north1> They have no right appearing in the first place, they appear because upstream doesn't check for systemd.pc
2020-02-05 08:46:48 <clandmeter> north1: im not talking about your commits, i didnt look at them.
2020-02-05 08:47:11 <_ikke_> they just do rm -r $pkgdir/var/lib/systemd
2020-02-05 09:17:15 <PureTryOut[m]> north1: in regards to https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3621#note_66304, calling `py.test-3` directly didn't help much
2020-02-05 09:34:03 <north1> @PureTryOut i see
2020-02-05 10:59:30 <ncopa> mps: #10874 was closed without stable branches got the fixes
2020-02-05 10:59:46 <ncopa> apparently jirutka is fixing them now
2020-02-05 11:00:11 <_ikke_> yeah, I was wondering that this morning
2020-02-05 11:00:21 <_ikke_> someone asked about the sudo CVE
2020-02-05 11:03:10 <mps> ah, I see. I forgot it. sorry :(
2020-02-05 11:05:16 <mps> looks like I need to use some tools for such things and don't rely only on brain to remember
2020-02-05 11:15:49 <ncopa> mps: i think the problem was that the commit message had "fixes #...." and was pushed to master
2020-02-05 11:15:59 <ncopa> gitlab will close the issue when that happens
2020-02-05 11:16:28 <ncopa> i wish gitlab wouldnt close it if there is open todo-list
2020-02-05 11:19:31 <ncopa> its good it got sorted out and the issue got fixed
2020-02-05 11:26:40 <kmaxwell> is there an easy way to ask apk if a package is in main, community or testing?
2020-02-05 11:26:53 <mps> ncopa: yes, probably I forgot it because 'fixes:' closed it
2020-02-05 11:27:06 <kmaxwell> I thought `apk list --origin py3-bottle` might be right, but it isn't
2020-02-05 11:27:13 <mps> kmaxwell: apk policy pkgname
2020-02-05 11:27:37 <kmaxwell> mps: amazing, thank you!
2020-02-05 11:27:43 <_ikke_> origin is the package main package it came from
2020-02-05 11:27:46 <mps> np :)
2020-02-05 11:27:54 <_ikke_> ie, for subpackages
2020-02-05 11:28:05 <_ikke_> s/package main//
2020-02-05 11:28:05 <alpine-meetbot> _ikke_ meant to say: origin is the  package it came from
2020-02-05 11:28:14 <kmaxwell> _ikke_: great that makes sense as well, thanks!
2020-02-05 11:30:13 <mps> ncopa: _ikke_: it is good idea to somehow setup gitlab to not close bug report if not fixed in all taged releases
2020-02-05 11:30:52 <mps> I mean, if git commit have 'fixes: #nr'
2020-02-05 11:43:41 <ncopa> yeah. not sure how though
2020-02-05 11:44:36 <ncopa> i'd like to write a webhook that will check if "fixes #nr", and if there is a todo-list it will edit the description, and mark the branch fixed
2020-02-05 11:45:11 <ncopa> if all are fixed, it will if security issue, remove confidiential, and then close it
2020-02-05 11:48:24 <_ikke_> mps: I don't think that's possible
2020-02-05 11:48:35 <_ikke_> it responds to when a commit lands in the default branch
2020-02-05 11:49:43 <mps> _ikke_: understand
2020-02-05 11:50:54 <mps> not that I have idea how to solve this
2020-02-05 11:51:23 <_ikke_> Use a custom fix tag and build something that responds to that
2020-02-05 11:51:34 <_ikke_> like ncopa proposed
2020-02-05 11:52:05 <_ikke_> CVE-Issue: #1234
2020-02-05 11:52:10 <_ikke_> for example
2020-02-05 11:53:17 <_ikke_> (pur chance that it's actually a CVE ticket :D)
2020-02-05 11:54:37 <mps> heh
2020-02-05 11:55:28 <mps> 'by shoting in the dark you always have chance to shot something'
2020-02-05 11:58:21 <_ikke_> s/chance/coincidence/
2020-02-05 11:58:21 <alpine-meetbot> _ikke_ meant to say: (pur coincidence that it's actually a CVE ticket :D)
2020-02-05 14:24:05 <mps> s390x CI is stuck
2020-02-05 14:24:27 <north1> As is tradition :D
2020-02-05 14:25:31 <mps> supercomputers 'superstucks' ;)
2020-02-05 14:43:51 <ncopa> me and clandmeter are working on #10678
2020-02-05 14:44:26 <ncopa> one problem is that our ca-certificates package needs python at buildtime
2020-02-05 14:44:38 <ncopa> which makes python a part of the bootstrap chain
2020-02-05 14:44:51 <ncopa> i think it would be nice to get rid of the python dep
2020-02-05 14:45:14 <ncopa> so i have found the mk-ca-bundle.pl script, that curl uses
2020-02-05 14:45:28 <ncopa> it will generate a bundle in pem format
2020-02-05 14:45:52 <_ikke_> I assume perl is already part of the bootstrap chain?
2020-02-05 14:45:57 <ncopa> yes
2020-02-05 14:45:59 <dalias> yeah this is a bad problem not just for alpine
2020-02-05 14:46:20 <dalias> and perl is bad there too
2020-02-05 14:46:33 <dalias> i dont understand why ca-certificates needs to be "built" at all
2020-02-05 14:46:41 <dalias> it's not arch-specific binaries
2020-02-05 14:46:50 <dalias> it's pure data that should just be distributed in the form for use
2020-02-05 14:46:59 <ncopa> correct
2020-02-05 14:47:04 <_ikke_> dalias: people want to be able to add to the bundle though
2020-02-05 14:47:20 <dalias> well then *they* can deal with the tooling mess to add to it
2020-02-05 14:47:23 <_ikke_> and remove fo that matter
2020-02-05 14:47:24 <ncopa> its data that just need to be converted into different formats
2020-02-05 14:47:40 <dalias> normal users who don't want malicious root CAs added should just be able to get an authoritative trusted prebuilt set of files in a non-distro-specific way
2020-02-05 14:48:35 <ncopa> this one does that: https://curl.haxx.se/docs/caextract.html
2020-02-05 14:49:31 <ncopa> we need to store the certs splitted, and re-generate the cert bundle
2020-02-05 14:49:41 <ncopa> so users can add their own certs
2020-02-05 14:50:02 <ncopa> without losing their own cert from the bundle when the ca-certificates is updated
2020-02-05 14:51:20 <ncopa> anyway, i wrote a small shell script to split the ca-bundle.pem
2020-02-05 14:51:47 <ncopa> and compared with the currenly splitted out certs from our ca-certificates package
2020-02-05 14:52:05 <ncopa> there are a handful certs that are excluded
2020-02-05 14:52:18 <ncopa> and i wonder why
2020-02-05 14:53:19 <ncopa> this is the list of excluded certs: http://tpaste.us/V491
2020-02-05 14:54:06 <_ikke_> symantic/verisign due to security issues?
2020-02-05 14:55:22 <ncopa> this is the script https://github.com/curl/curl/blob/master/lib/mk-ca-bundle.pl
2020-02-05 14:55:42 <ncopa> this is the indata: https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
2020-02-05 14:56:05 <ncopa> what i wonder is, why does not our current python script exclude those?
2020-02-05 14:58:04 <clandmeter> fedora also uses it: https://src.fedoraproject.org/rpms/ca-certificates/blob/master/f/certdata2pem.py
2020-02-05 14:58:14 <clandmeter> but maybe it has some fixes
2020-02-05 15:14:56 <ncopa> yeah, its likely this: https://src.fedoraproject.org/rpms/ca-certificates/c/6aec97d9bdcbb92ef912a60b86060f4bc6481b1a?branch=master
2020-02-05 15:16:14 <_ikke_> Distrusted
2020-02-05 15:51:52 <nmeum> terror_: could you fix your irc setup in a way that it does not constantly rejoin?
2020-02-05 16:27:57 <_ikke_> north1: upx fails on x86
2020-02-05 16:28:29 <nmeum> could someone close https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/18 for me?
2020-02-05 16:29:04 <_ikke_> done
2020-02-05 16:29:08 <nmeum> thanks
2020-02-05 16:30:52 <nmeum> did we workout our gitlab permissions model yet? I mean: I can push to the repo is there any specific reason why I can't close MRs then?
2020-02-05 16:31:12 <_ikke_> nmeum: did you push to gitlab or to git.a.o?
2020-02-05 16:31:38 <_ikke_>  assume git.a.o
2020-02-05 16:31:55 <nmeum> yep
2020-02-05 16:32:27 <_ikke_> We did not consolidate permissions on gitlab yet, right now we just manually add members when necessary
2020-02-05 16:32:41 <nmeum> ah, ok
2020-02-05 16:33:47 <mps> north1: upx fails because of test, and this test file is added to APKBUILD inline
2020-02-05 16:34:48 <mps> for previous alpine release I asked why this is added there and does it still need to be there, but didn't got answer
2020-02-05 16:35:15 <mps> I'm not sure is this still correct test
2020-02-05 16:35:20 <_ikke_> oh, that one again
2020-02-05 16:35:57 <mps> yes, would be nice if we can get explanation why it is there
2020-02-05 16:38:21 <nmeum> that check() code was originally added by alpine-mips-patches in 6939846374536c336db296d39b37981336028558
2020-02-05 16:38:40 <nmeum> the commit text explicitly says "add basic check() -- passes on x86_64 and mipseln8hf, may need tweak for other architectures;"
2020-02-05 16:38:51 <nmeum> if it fails I would just disable / remove it tbh
2020-02-05 16:39:25 <mps> nmeum: thanks
2020-02-05 16:39:46 <mps> I lost my hair with last time :D
2020-02-05 16:39:56 <mps> with it*
2020-02-05 16:40:28 <_ikke_> I think the policy says not to add custom checks
2020-02-05 16:41:33 <nmeum> I also think that it doesn't make much sense to add a testsuite downstream if upstream doesn't provide one
2020-02-05 16:41:47 <mps> maybe we could, but with separate patch and 'readme' which explains these special cases
2020-02-05 16:42:01 <nmeum> I would rather prefer proposing it upstream
2020-02-05 16:42:13 <nmeum> though it doesn't seem to be that advanced anyhow
2020-02-05 16:42:16 <mps> ofc, that is first thing to do
2020-02-05 16:43:04 <mps> but if upstream doesn't response or package is unmaintained then maybe, but carefully
2020-02-05 16:59:14 <ncopa> clandmeter: re ca-certificates, i think the cert.pem should be a symlink to ca-certificates.crt or opposite
2020-02-05 16:59:27 <nmeum> mps: do we want to remove the upx check function for now or just disable the test? just to stop the x86 builder from failing constantly
2020-02-05 17:02:39 <mps> nmeum: I'm for remove, and enable on all arch then
2020-02-05 17:03:02 <mps> I tested it last night on armv7, it builds fine
2020-02-05 17:03:38 <nmeum> mps: will write a quick MR to see on which CI arches it passes
2020-02-05 17:03:48 <mps> ok
2020-02-05 17:07:32 <nmeum> !3753 let's see if it passes on all arches …
2020-02-05 17:25:09 <ncopa> hum
2020-02-05 17:25:23 <ncopa> why not just remove upx all together?
2020-02-05 17:25:40 <ncopa> I mean, if it does not work
2020-02-05 17:25:55 <nmeum> I have no reason to believe that it doesn't work
2020-02-05 17:26:15 <nmeum> someone just wrote non-portable custom tests
2020-02-05 17:26:24 <ncopa> the tests was introduced in 6939846374536c336db296d39b37981336028558 because it was broken even on x86_64
2020-02-05 17:26:33 <ncopa> according commit message
2020-02-05 17:27:50 <mps> maybe remove this test and move it to testing
2020-02-05 17:28:47 <nmeum> upstream still seems to be active (last commit from 14 days ago) if its really broken I would just report that upstream
2020-02-05 17:29:27 <mps> ah, agree
2020-02-05 17:29:38 <nmeum> just invoked it on a simple C binary I had lying around and it seems to have compressed that succesfully
2020-02-05 17:29:48 <nmeum> so basic usage seems to work
2020-02-05 17:31:05 <nmeum> stuff like cp /bin/busybox . && upx busybox && ./busybox also works
2020-02-05 17:31:16 <ncopa> does it work with static compiled binary?
2020-02-05 17:31:20 <ncopa> eg busybox.static
2020-02-05 17:32:00 <nmeum> https://tpaste.us/9NL6 does seem to work
2020-02-05 17:41:29 <nmeum> ncopa: are you convinced of the original plan, i.e. removing the check() and keeping the package or would you still like to remove it entirely?
2020-02-05 17:42:06 <ncopa> i think some sort of check would be nice
2020-02-05 17:42:40 <mps> nmeum: did you looked issue report for upx about 5 hours ago
2020-02-05 17:43:17 <nmeum> mps: hm? no, which one?
2020-02-05 17:43:43 <mps> it is not public, you have to login to see it
2020-02-05 17:43:56 <mps> secfixes
2020-02-05 17:44:02 <nmeum> ncopa: sure, I agree that a testsuite would be nice but I think as downstream we don't really have the capacity / knowledge of the software to really write a decent test suite for it
2020-02-05 17:44:07 <nmeum> ah
2020-02-05 17:44:44 <nmeum> upstream does seem to have a CI but I did not manage to find any test suite document (yet?)
2020-02-05 17:44:53 <nmeum> 792150
2020-02-05 17:44:57 <nmeum> oops
2020-02-05 17:46:11 <mps> 11190
2020-02-05 17:46:13 <nmeum> re: upx issue. looks like we should apply the patches linked in that issue but that would require fixing the build first, wouldn't it?
2020-02-05 17:46:23 <nmeum> #11190
2020-02-05 17:46:39 <mps> yes, agree
2020-02-05 17:47:04 <mps> these issues can't be seen publicly
2020-02-05 17:47:55 <nmeum> also requires backports as it is in community … meh
2020-02-05 17:48:33 <mps> yes
2020-02-05 17:49:48 <mps> I hope backport will be simple once all is done on master
2020-02-05 18:13:00 <ncopa> somethign is wrong with upx 3.96
2020-02-05 18:13:16 <ncopa> i get upx.out: upxtest: CantPackException: bad DT_GNU_HASH n_bucket=0x1  n_bitmask=0x1  len=0x18
2020-02-05 18:13:53 <dalias> eew upx..
2020-02-05 18:14:18 <ncopa> dalias: encouraging... :)
2020-02-05 18:14:33 <dalias> just the whole idea of upx is very very backwards
2020-02-05 18:15:00 <dalias> and it's used by people who don't understand virtual memory, filesystems, etc.
2020-02-05 18:15:29 <ncopa> i tend to agree
2020-02-05 18:15:32 <dalias> i guess to track down the cause tho you should probably look for diff from last version
2020-02-05 18:16:15 <dalias> the right way to get same supposed benefit as upx without massive costs of upx is compressed filesystem not compressed executable file
2020-02-05 18:16:55 <kaniini> hey
2020-02-05 18:17:01 <kaniini> upx is a staple of the demoscene
2020-02-05 18:17:05 <kaniini> dont knock it
2020-02-05 18:17:32 <kaniini> those 64kb demos have to work somehow
2020-02-05 18:19:05 <ncopa> kaniini: was it you who added the tests for upx?
2020-02-05 18:19:36 <ncopa> its broken on x86 and -no-pie is also broken i think
2020-02-05 18:19:43 <ncopa> i guess we should report those things upstream
2020-02-05 18:20:13 <dalias> kaniini, upx in demoscene is silly
2020-02-05 18:20:52 <dalias> if contest rules allow upx they should just measure the compressed size of the binary rather than uncompressed size
2020-02-05 18:21:55 <kaniini> ncopa: i dont think i would add tests for upx
2020-02-05 18:21:59 <kaniini> ncopa: much less package upx
2020-02-05 18:22:06 <kaniini> ncopa: much less use upx
2020-02-05 18:23:10 <dalias> :)
2020-02-05 18:23:22 <dalias> well the test found something broken so.. :)
2020-02-05 18:24:08 <kaniini> i would like to congratulate ubiquiti on shipping hardware with counterfeit flash modules and then quietly brushing it under the rug with a firmware update that just underclocks the SDIO bus
2020-02-05 18:24:15 <kaniini> truly impressive stuff
2020-02-05 18:24:37 <kaniini> if UBNT were a publicly traded company, I would short them, honestly
2020-02-05 18:25:05 <kaniini> ohh
2020-02-05 18:25:06 <kaniini> shit
2020-02-05 18:25:07 <kaniini> they are
2020-02-05 18:25:54 <dalias> haha
2020-02-05 18:26:05 <kaniini> how the hell is their stock performing so well
2020-02-05 18:26:14 <kaniini> if it performed like their hardware, it would be on the pink sheets
2020-02-05 18:27:11 <dalias> what are they making money from? (if anything)
2020-02-05 18:27:31 <kaniini> presumably, the wifi segment
2020-02-05 18:27:54 <kaniini> EdgeOS is a total joke
2020-02-05 18:28:15 <kaniini> we literally ported Alpine to ubiquiti kit to get away from EdgeOS at work
2020-02-05 18:28:31 <kaniini> and then we discovered other people want this as well, and even want support contracts for it
2020-02-05 18:28:34 <kaniini> go fucking figure
2020-02-05 18:28:44 <dalias> :-p
2020-02-05 18:28:46 <kaniini> (that port is coming in Alpine 3.12)
2020-02-05 18:29:35 <ncopa> upx is totally non-working on s390x
2020-02-05 18:29:39 <ncopa> i guess nobody cares
2020-02-05 18:29:54 <kaniini> imagine being a network vendor whose OS is so awful that people will literally pay to have anything else installed in place of it
2020-02-05 18:30:00 <kaniini> that's ubiquiti in a nutshell
2020-02-05 18:32:09 <dalias> i dont understand
2020-02-05 18:32:16 <dalias> if not their software, wtf is the point of their hardware?
2020-02-05 18:32:47 <dalias> i thought ppl bought network appliances for the software configuration on them not for hardware that's essentially generic
2020-02-05 20:38:24 <PureTryOut[m]> north1: I just don't see a way to make it run the tests...
2020-02-05 21:04:54 <wsinatra> Just out of curiosity, if I wrote a piece of software, would there be anything preventing me from packaging it for Alpine? It's not frowned upon to package your own stuff right?
2020-02-05 21:05:11 <_ikke_> nope
2020-02-05 21:05:18 <mps> wsinatra: no, ofc
2020-02-05 21:05:24 <dalias> i'm not speaking for alpine, but i think it's fine as long as you're not trying to skirt around policy
2020-02-05 21:05:27 <_ikke_> as long as it has a floss license
2020-02-05 21:05:31 <mps> if it is under free license
2020-02-05 21:05:37 <wsinatra> GPLv3 :)
2020-02-05 21:05:46 <_ikke_> Then no, there should be no issue
2020-02-05 21:05:55 <wsinatra> I might actually go ahead and do that then since I'm still hitting roadblocks with SBCL on aarch64
2020-02-05 21:10:08 <kmaxwell> I'm glad you asked the question wsinatra, I'm working on an Apache licensed db that I should maybe package :-)
2020-02-05 21:10:47 <wsinatra> I just finished up a stable build of an asynchronous runner (kinda like ansible) that I use at work
2020-02-05 21:11:21 <wsinatra> Figured I might as well ask since I already have an APKBUILD for it, glad I'm not the only person who wants to give back to Alpine users too!
2020-02-05 21:11:24 <mps> kmaxwell: not that I insist, but GPL or BSD is better imo
2020-02-05 21:12:23 <kmaxwell> mps: in your view why is BSD better?
2020-02-05 21:12:49 <mps> I see BSD nearly as 'public domain'
2020-02-05 21:15:13 <mps> so, if I would to release some piece of code which I would like to be free for all I would put BSD license
2020-02-05 21:15:17 <kmaxwell> ahh OK, IANAL but my preference is for Apache because of the explicit drafting
2020-02-05 21:15:55 <wsinatra> So MIT would be just as good mps?
2020-02-05 21:16:09 <mps> if I would it to be 'secured' from hijacking then I would put some GPL
2020-02-05 21:16:09 <kmaxwell> mps: sure, I understand if we do look at re-licencing I'll bear that in mind
2020-02-05 21:16:48 <mps> wsinatra: MIT is (maybe) just after BSD
2020-02-05 21:17:11 <mps> but, IANAL, so don't take my opinion seriously
2020-02-05 21:17:25 <kmaxwell> this is a big topic! I also recently started to look at/use the MPL
2020-02-05 21:17:47 <kmaxwell> it has some of those hijacking protections maybe without being a scary to some or "viral"
2020-02-05 21:18:16 <mps> I wouldn't care is some corporate shills are scared
2020-02-05 21:18:40 <mps> if*
2020-02-05 21:19:39 <kmaxwell> I have written very little free software for money, but we do all need to eat!
2020-02-05 21:20:58 <mps> kmaxwell: also I wrote (and still write) software for money, but I don't pretend that it is free
2020-02-05 21:22:33 <kmaxwell> I think Apache or MPL licensed code is free by a lot of people's definitions
2020-02-05 21:23:19 <kmaxwell> but I'm glad there are different licenses to choose from, and I understand you and others have different preferences
2020-02-05 21:23:45 <mps> again, you are one to decide, not I
2020-02-05 21:25:14 <wsinatra> hmm I'm for some reason getting a checksum failure..
2020-02-05 21:26:17 <_ikke_> When?
2020-02-05 21:26:45 <wsinatra> When running the the package through the CI, doesn't happen on my build server though
2020-02-05 21:26:53 <wsinatra> MR is !3755
2020-02-05 21:27:54 <wsinatra> I'm wondering if maybe it's how I have my release set in gitlab, first time trying to do that honestly
2020-02-05 21:30:26 <_ikke_> fails for me as well
2020-02-05 21:31:33 <wsinatra> Very peculiar, I don't see the same issue on my CI or building it manually
2020-02-05 21:31:37 <wsinatra> I wonder what I missed..
2020-02-05 21:31:51 <kmaxwell> is it something about gitlab not producing stable artifacts? I have a hazy memory
2020-02-05 21:32:07 <_ikke_> This is the sum I get: b3d04931dbc3fd8af54b304071f4921cf4089f109f487ad0424c2b015ec2d968a34640e83104018d600a42630271c593191921377a6ab696a3d7a8af17623b6f
2020-02-05 21:32:21 <_ikke_> (just by piping it to sha512sum
2020-02-05 21:32:23 <_ikke_> )
2020-02-05 21:32:41 <wsinatra> Oh yeah definitely different from what's in the APKBUILD
2020-02-05 21:33:26 <wsinatra> Maybe I should just make a mirror on github, and then use a release from there. I don't think I've see anything like this when working with github
2020-02-05 21:33:52 <_ikke_> We have or own instance, but we do get releases from gitlab
2020-02-05 21:34:25 <kmaxwell> I get the same checksum as _ikke_
2020-02-05 21:34:56 <wsinatra> There are definitely other projects using gitlab too, so it must be something I did wrong somewhere
2020-02-05 21:35:11 <_ikke_> wsinatra: does it still succeed for you on your build server?
2020-02-05 21:36:12 <wsinatra> huh no now for some reason it produces an error, but it doesn't complain about the sha, it complains about a path
2020-02-05 21:36:50 <wsinatra> I might need to do a little more work on the APKBUILD
2020-02-05 21:38:36 <wsinatra> This is just peculiar now. If I change the path to Paraexec-paraexec-$pkgver in build and install, it runs on my end
2020-02-05 21:41:08 <wsinatra> Still get a sha error though, despite it being able to build locally. So I must have something broken in the release or the apk
2020-02-05 21:41:58 <_ikke_> wsinatra: apart from the checksum, it builds fine here
2020-02-05 21:42:48 <wsinatra> So the apk is fine, it's just the checksum that's weird
2020-02-05 21:43:59 <kmaxwell> I couldn't remember if gitlab lets you upload a file that you know the checksum of to a release
2020-02-05 21:44:08 <kmaxwell> that feature is coming soon :-) https://docs.gitlab.com/ee/user/project/releases/#release-assets
2020-02-05 21:44:19 <wsinatra> Oh interesting, if I don't rename the tarball then I get the b3d04931 checksum
2020-02-05 21:44:56 <wsinatra> kmaxwell: I'll keep my eyes out for that release, would be really useful!
2020-02-05 21:45:10 <kmaxwell> wsinatra: how curious!
2020-02-05 21:47:17 <wsinatra> Extremely curious, that seems to have fixed the issue
2020-02-05 21:47:33 <_ikke_> just by not renaming it?
2020-02-05 21:47:56 <wsinatra> :@_ikke_ yep that fixed the issue
2020-02-05 21:48:09 <_ikke_> how is that even possible
2020-02-05 21:48:25 <wsinatra> I had $pkgname.tar.bz2::https://gitlab...paraexec-$pkgver.tar.bz2 as the source
2020-02-05 21:48:27 <_ikke_> or did you force to download a new archive
2020-02-05 21:48:52 <_ikke_> s/you/you just/
2020-02-05 21:48:52 <alpine-meetbot> _ikke_ meant to say: or did you just force to download a new archive
2020-02-05 21:49:15 <_ikke_> try to restore that, and return abuild cleancache
2020-02-05 21:49:43 <wsinatra> so set the $pkgname rename back, run cleancache, and see what it returns?
2020-02-05 21:50:06 <_ikke_> yes, then run abuild fetch verify
2020-02-05 21:52:04 <wsinatra> Set it back, ran cleancache, then verify and it failed. Ran checksum, then cleancache, then verify and it passed
2020-02-05 21:53:05 <_ikke_> Did you do something that might have caused the archive on gitlab to be regenerated perhaps?'
2020-02-05 21:53:12 <mps> we don't have policy for release notes on pkg upgrade?
2020-02-05 21:53:17 <_ikke_> no
2020-02-05 21:54:03 <mps> how to inform user of important changes in pkg on upgrade?
2020-02-05 21:54:19 <mps> write to STDOUT
2020-02-05 21:54:28 <wsinatra> I deleted the initial tag, because I named it incorrectly. That might be where the conflict came from
2020-02-05 21:54:31 <_ikke_> I don't think we have an facility for that
2020-02-05 21:54:37 <wsinatra> but that was before I even asked about packaging it
2020-02-05 21:55:33 <mps> _ikke_: pkg.post-upgrade => echo 'something important'
2020-02-05 21:55:51 <_ikke_> mps: there is a policy against that
2020-02-05 21:55:59 <mps> ah
2020-02-05 21:56:38 <wsinatra> :@_ikke_ might have been that, looks like it runs through the CI just fine now
2020-02-05 21:56:50 <mps> huh, than I will silently change config file for iwd
2020-02-05 21:56:56 <_ikke_> wsinatra: I tried it several times and I did not see the hash changing
2020-02-05 21:57:36 <_ikke_> mps: it would place the file as apknew and users are expected to consolidate that themselves
2020-02-05 21:58:18 <wsinatra> I think the error occurred somewhere between my chair and my computer :)
2020-02-05 21:59:52 <mps> _ikke_: yes, I'm doing this right now
2020-02-05 22:00:36 <mps> but think users will be 'surprised' by segfault of iwd daemon on upgrade
2020-02-05 22:08:07 <kmaxwell> where is the right place to read about policies like that? is it the wiki?
2020-02-05 22:10:44 <_ikke_> kmaxwell: We are trying to document these things
2020-02-05 22:11:00 <_ikke_> mostly this has been from discussions in irc and mailing lists
2020-02-05 22:11:08 <_ikke_> But it should be documented
2020-02-05 22:11:24 <kmaxwell> _ikke_: don't worry I can be patient and wait, there is no pressure from me
2020-02-05 22:11:50 <kmaxwell> I wasn't able to pay much attention to alpine for a while
2020-02-05 22:12:10 <_ikke_> nice to see you back at least :)
2020-02-05 22:12:42 <kmaxwell> ty!
2020-02-05 22:17:13 <mps> _ikke_: what version of linux-headers are used on CIs
2020-02-05 22:18:22 <_ikke_> just the latest version?
2020-02-05 22:19:03 <mps> ohm, !3756 fails on WSC not eapol
2020-02-05 22:19:57 <_ikke_> http://tpaste.us/Xg8J
2020-02-05 22:20:11 <_ikke_> this is in the alpine-gitlab-ci container that is used
2020-02-05 22:20:26 <mps> I see, 5.4.5
2020-02-05 22:21:01 <_ikke_> "FAIL: unit/test-wsc"
2020-02-05 22:21:41 <mps> yes, maybe this can't work on CIs
2020-02-05 22:21:57 <mps> it builds fine locally in 3 arch
2020-02-05 22:22:38 <_ikke_> maybe because the linux-headers are different from the host kernel?
2020-02-05 22:24:04 <mps> from my previous experience, it shouldn't be, important are linux-headers
2020-02-05 22:24:45 <_ikke_> no, lxc would presumably have the same issue
2020-02-05 22:25:18 <mps> it is, Wi-Fi* Simple Config (WSC)
2020-02-05 22:25:44 <mps> I will try now in lxc
2020-02-05 22:27:15 <mps> pass on armv7 lxc
2020-02-05 23:52:05 <kaey> i saw a breakage notification recently when upgrading nftables
2020-02-05 23:52:36 <kaey> also whats the problem with notifiyng in post-upgrade?
2020-02-05 23:54:16 <kaey> https://git.alpinelinux.org/aports/tree/main/nftables/nftables.post-upgrade
2020-02-06 00:03:16 <mps> probably because of unattended upgrade
2020-02-06 00:20:31 <kaey> if youre on edge or upgrading to next release you should expect breakage
2020-02-06 00:23:20 <kaey> and obviously you mustn't backport breaking change into release
2020-02-06 00:28:40 <mps> I'm not sure what option is better (or worse), alert user or quietly add breaking changes
2020-02-06 05:58:13 <iggy> how bad is it to override MAKEFLAGS in the build function?
2020-02-06 08:53:32 <_ikke_> morning
2020-02-06 08:53:42 <north1> morning
2020-02-06 08:59:56 <mps> \o
2020-02-06 09:03:47 <clandmeter> those away and reconnect messages are terrible.
2020-02-06 09:03:57 <clandmeter> i have them disabled but when not its crazy
2020-02-06 09:06:31 <_ikke_> I have them filtered out as well
2020-02-06 09:06:56 <clandmeter> i think we should warn terror one more time
2020-02-06 09:06:59 <_ikke_> We could redirect terror until this problem is fixed?
2020-02-06 09:07:18 <clandmeter> redirect?
2020-02-06 09:07:38 <_ikke_> "You can append $#channel to any ban to redirect banned users to another channel."
2020-02-06 09:08:12 <clandmeter> where do you read that?
2020-02-06 09:08:16 <_ikke_> https://freenode.net/kb/answer/channelmodes
2020-02-06 09:08:24 <_ikke_> there is a channel called #fix_your_connection
2020-02-06 09:08:38 <clandmeter> i can never find information from fn website :)
2020-02-06 09:08:51 <_ikke_> I just search freenode modes
2020-02-06 09:08:59 <_ikke_> first hit
2020-02-06 09:09:11 <_ikke_> oh, it's called ##fix_your_connection
2020-02-06 09:09:34 <_ikke_> mind if I do?
2020-02-06 09:09:57 <north1> What's the deal?
2020-02-06 09:10:24 <_ikke_> north1: try to turn off any join/part filter
2020-02-06 09:10:25 <clandmeter> go ahead
2020-02-06 09:10:50 <north1> @_ikke_ I don't have a filter for that
2020-02-06 09:11:28 <_ikke_> north1: do you see joins/parts?
2020-02-06 09:11:32 <mps> turning of join/part/nick filters are for masochists :)
2020-02-06 09:11:51 <_ikke_> I can switch it with a hotkey
2020-02-06 09:11:55 <north1> @_ikke_ yes
2020-02-06 09:12:57 <_ikke_> do you see terror joining / parting all the time?
2020-02-06 09:13:10 <_ikke_> (connection timeout)
2020-02-06 09:13:33 <north1> Yes
2020-02-06 09:13:53 <_ikke_> north1: some people perceive that as noise
2020-02-06 09:14:26 <_ikke_> arg, my filter does not work
2020-02-06 09:15:10 <clandmeter> you cannot ban on hostname?
2020-02-06 09:15:42 <clandmeter> mps: exactly
2020-02-06 09:15:58 <_ikke_> now it works
2020-02-06 09:16:07 <clandmeter> i dont see a thing :)
2020-02-06 09:16:19 <_ikke_> me neither, until someone pointed it out
2020-02-06 09:17:12 <clandmeter> i just upgraded thelounge
2020-02-06 09:17:29 <clandmeter> so it has a bug that does not hide them in backlog
2020-02-06 09:17:43 <clandmeter> so backlog is like scrolling 5 pages
2020-02-06 09:19:15 <_ikke_> clandmeter: it's a dynamic ip, so I figured a registered nick name would be more stable
2020-02-06 09:19:32 <north1> @ikke i guess it would be annoying to have them on normal irc clients
2020-02-06 09:19:48 <_ikke_> yes, which is what most people use here
2020-02-06 09:20:01 <clandmeter> define normal irc client :)
2020-02-06 09:20:03 <north1> i use riot with an IRC bridge and it makes join/part small gray messages that do not trigger message counts
2020-02-06 09:20:36 <_ikke_> north1: but doesn't it still push away normal conversation?
2020-02-06 09:21:10 <north1> no, it jumbos them together if there are lots of joins/parts
2020-02-06 09:21:43 <north1> like, terror (or whoever) joined and left 10 times, and i can click on his little circle-icon to see exactly when
2020-02-06 09:27:28 <clandmeter> yes this is also an option for thelounge, keep, condense, hide.
2020-02-06 09:28:54 <clandmeter> i think i mention it before, but anyone on our alpine team can have an account on our thelounge if they want one.
2020-02-06 09:34:51 <north1> What is that ?
2020-02-06 09:35:03 <_ikke_> web based irc client/bouncer
2020-02-06 09:35:51 <north1> I see
2020-02-06 10:08:24 <clandmeter> north1: https://thelounge.chat/
2020-02-06 10:09:21 <clandmeter> ncopa: any conclusion about cacert?
2020-02-06 10:10:14 <clandmeter> is there any drawback to using cacert.pem?
2020-02-06 10:11:34 <ncopa> so cacert.pem and ca-certificates.crt are the same thing
2020-02-06 10:11:38 <ncopa> just different locations
2020-02-06 10:11:53 <ncopa> i wonder why we call it ca-certificates.crt in the first place
2020-02-06 10:11:57 <ncopa> its probably from debian
2020-02-06 10:12:41 <ncopa> i think we can have a symlink cert.pem > certs/ca-certificates.crt
2020-02-06 10:12:42 <clandmeter> yes
2020-02-06 10:12:58 <ncopa> and ship a pre-genertated ca-certificates
2020-02-06 10:13:14 <ncopa> the way it is designe is that we should not ship a pregenerated bundle
2020-02-06 10:13:29 <clandmeter> wouldnt it make sesne to put the cert in /usr/...?
2020-02-06 10:13:35 <ncopa> instead evertying should depend on ca-certificates
2020-02-06 10:13:52 <ncopa> ca-certificates installs the seprated certs in /usr/share/
2020-02-06 10:14:16 <ncopa> but im looking at the other issue(s) while at it
2020-02-06 10:14:31 <mps> ncopa: you mean each in their separate file
2020-02-06 10:14:37 <clandmeter> other as in other cert issues?
2020-02-06 10:14:57 <clandmeter> or just busy with more important things :)
2020-02-06 10:15:01 <mps> ah, I see
2020-02-06 10:15:03 <ncopa> no other cert issues
2020-02-06 10:15:20 <clandmeter> nod
2020-02-06 10:15:24 <ncopa> I have  a fix for #8379
2020-02-06 10:15:35 <ncopa> but i think i will ship that separately
2020-02-06 10:15:47 <ncopa> so it can be backported to 3.11
2020-02-06 10:15:50 <clandmeter> so we still keep ca-certificates in git.a.o?
2020-02-06 10:15:56 <clandmeter> or compleetely swtich?
2020-02-06 10:15:56 <ncopa> yes
2020-02-06 10:16:06 <ncopa> i think it makes sense to keep it
2020-02-06 10:16:10 <clandmeter> grr... this keyboard is...
2020-02-06 10:16:24 <ncopa> basically we have two options
2020-02-06 10:17:01 <ncopa> 1) we do debian style, split out the certs and have a trigger to bundle them (this is how ca-certificates packe is designed)
2020-02-06 10:17:24 <ncopa> 2) we only ship a pre-generated bundle and let user manually deal with it
2020-02-06 10:17:35 <clandmeter> my two patches already make a symlijnk from cacert.pem to ca-certificates.crt
2020-02-06 10:18:10 <clandmeter> and uses provides to kill cacert when ca-certificates is installed
2020-02-06 10:18:26 <ncopa> i think the whole ca-certificate is a mess
2020-02-06 10:18:36 <ncopa> because it is a mix of the two options
2020-02-06 10:18:49 <clandmeter> it is
2020-02-06 10:18:56 <ncopa> the only thing we need, technically, is a symlink
2020-02-06 10:19:01 <clandmeter> but if you want to make it user configurable, thats the only way i guess.
2020-02-06 10:19:08 <ncopa> and we could get rid of the pregenerated bundle
2020-02-06 10:19:37 <clandmeter> i dont get that part
2020-02-06 10:19:42 <ncopa> we could get rid of ca-certificates-cacert
2020-02-06 10:19:53 <ncopa> and only ship ca-certificates
2020-02-06 10:20:13 <ncopa> the only thing needed is a symlink /etc/ssl/cert.pem
2020-02-06 10:20:17 <clandmeter> yes but then we need to depend on it for base system
2020-02-06 10:20:44 <clandmeter> i would like to know what apk uses when using https repos
2020-02-06 10:20:46 <ncopa> right, so technically, we should let libssl package depend on ca-certificates
2020-02-06 10:20:58 <ncopa> let me check
2020-02-06 10:21:10 <ncopa> but my guess iss that it uses libssl default
2020-02-06 10:21:16 <clandmeter> but for basic system, i dont think we want to pull in more than only the base cert
2020-02-06 10:21:25 <ncopa> which i believe is /etc/ssl/cert.pem
2020-02-06 10:21:29 <_ikke_> the base cert?
2020-02-06 10:21:40 <clandmeter> yes cert.pem
2020-02-06 10:21:47 <clandmeter> cacert.pem
2020-02-06 10:21:51 <clandmeter> which is the same
2020-02-06 10:21:52 <_ikke_> that's a cert bundle, right
2020-02-06 10:21:56 <clandmeter> yes
2020-02-06 10:22:03 <clandmeter> base as no users certs added
2020-02-06 10:22:16 <clandmeter> mozillas source
2020-02-06 10:22:41 <_ikke_> What if they connect to a private https mirror that uses a custom root cert?
2020-02-06 10:22:47 <clandmeter> libressl ships it as /etc/ssl/cert.pem
2020-02-06 10:23:01 <clandmeter> the would have an issue
2020-02-06 10:23:15 <clandmeter> you would need to revert to http
2020-02-06 10:23:18 <clandmeter> install ca-certificates
2020-02-06 10:23:22 <clandmeter> setup yhour own cert
2020-02-06 10:23:27 <clandmeter> and switch back to https
2020-02-06 10:23:38 <ncopa> open("/etc/ssl/cert.pem", O_RDONLY)     = 8
2020-02-06 10:23:46 <ncopa> apk uses /etc/ssl/cert.pem as i though
2020-02-06 10:23:50 <clandmeter> right
2020-02-06 10:24:05 <clandmeter> would be nice if we have a single source?
2020-02-06 10:24:15 <ncopa> yes
2020-02-06 10:24:25 <clandmeter> most applications will use /etc/ssl/certs/ca-certificates.crt by default
2020-02-06 10:24:50 <clandmeter> at least linux based ones
2020-02-06 10:24:58 <ncopa> they won't use openssl default? /etc/ssl/cert.pem?
2020-02-06 10:25:05 <clandmeter> i guess freebsd will use /etc/ssl/cert.pem
2020-02-06 10:25:56 <clandmeter> maybe other distros use symlinks>?
2020-02-06 10:26:09 <clandmeter> but the main cert is in certs/ca-cer...
2020-02-06 10:26:41 <clandmeter> i just checked an older ubuntu
2020-02-06 10:26:48 <_ikke_> archlinux uses /etc/ssl/cert.pem -> /etc/ca-certificates/extracted/tls-ca-bundle.pem
2020-02-06 10:26:48 <clandmeter> it has no /etc/ssl/cert.pem
2020-02-06 10:27:11 <ncopa> technically, the cleanest thing to do woudl be to: delte the ca-certificates-cacert package, make ca-certificates ship a /etc/ssl/cert.pem symlink (or the other way around), make libssl depend on ca-certificates
2020-02-06 10:27:33 <clandmeter> but that depends on python
2020-02-06 10:27:38 <clandmeter> which we wnat to kill
2020-02-06 10:27:45 <ncopa> we can do that separately
2020-02-06 10:27:47 <ncopa> well
2020-02-06 10:27:49 <ncopa> i already did :)
2020-02-06 10:27:54 <clandmeter> not from a single pkg
2020-02-06 10:28:10 <ncopa> python is not needed for update-ca-certificates
2020-02-06 10:28:24 <clandmeter> its a build dep for ca-certificates
2020-02-06 10:28:24 <ncopa> its only needed to split the bundle to separate cert files
2020-02-06 10:28:30 <ncopa> correct build dep
2020-02-06 10:28:44 <clandmeter> which is the thing i wanted to fix  :)
2020-02-06 10:28:54 <ncopa> but i already replaced that in upstream ca-certificates git repo
2020-02-06 10:29:19 <ncopa> https://git.alpinelinux.org/ca-certificates/commit/?id=6674063331cc37a6a496e44577d9be434cbfc9a2
2020-02-06 10:29:29 <clandmeter> ah ok
2020-02-06 10:29:31 <ncopa> that is a different problem
2020-02-06 10:29:32 <clandmeter> good
2020-02-06 10:29:40 <clandmeter> you didnt tell me :)
2020-02-06 10:29:48 <ncopa> im telling you now :)
2020-02-06 10:30:03 <ncopa> the shell script is a bit fragile
2020-02-06 10:30:06 <clandmeter> send me a postcard :p
2020-02-06 10:30:23 <ncopa> but shoudl work with the mk-ca-bundle.pl script
2020-02-06 10:30:45 <clandmeter> that script makes no sense?
2020-02-06 10:30:55 <clandmeter> why do you define a function mkcert which is not used?
2020-02-06 10:31:11 <ncopa> ugh
2020-02-06 10:31:14 <ncopa> i was tired i suppose
2020-02-06 10:31:29 <clandmeter> i didnt tell you yesterday
2020-02-06 10:31:35 <clandmeter> cause i thought you would clean it up :)
2020-02-06 10:31:46 <clandmeter> also =*= sounds dangerous?
2020-02-06 10:32:09 <clandmeter> ah no i htink it could be ok
2020-02-06 10:34:20 <clandmeter> and the if could be a oneliner, but who cares :)
2020-02-06 10:36:00 <ncopa> i think an "if" statement is easier to read
2020-02-06 10:36:32 <clandmeter> i dont agree, its user pref i guess.
2020-02-06 10:37:15 <ncopa> i thikn we should have some sort of safety check too
2020-02-06 10:37:31 <ncopa> so we dont end up with a BEGIN without END
2020-02-06 10:41:49 <ncopa> the only thing i am in doubt with at this point, is if we should ship a pre-generated ca-certificates.crt or not
2020-02-06 10:41:55 <clandmeter> ncopa: what is the reason to keep the pl script when we can also just download it from curl website?
2020-02-06 10:42:45 <ncopa> to not get surprises
2020-02-06 10:42:55 <clandmeter> which are?
2020-02-06 10:43:23 <ncopa> unexpected modifications of the script
2020-02-06 10:43:31 <clandmeter> i mean the pl script is also maintained by the same project
2020-02-06 10:43:37 <clandmeter> so the outcome is the same
2020-02-06 10:44:03 <ncopa> no, i think its maintained by curl
2020-02-06 10:44:32 <ncopa> oh, you mean why we dont simply fetch the bundle from curl
2020-02-06 10:44:37 <ncopa> yes, we could do that too
2020-02-06 10:44:37 <clandmeter> https://curl.haxx.se/docs/caextract.html
2020-02-06 10:44:45 <clandmeter> same source
2020-02-06 10:44:48 <clandmeter> just different format
2020-02-06 10:44:57 <ncopa> i guess we could do that too
2020-02-06 10:45:27 <ncopa> we'd still need a version of update-ca.c stored some where
2020-02-06 10:45:30 <clandmeter> i guess we could add the script to aports as a failsafe
2020-02-06 10:46:02 <clandmeter> yes and c_rehash
2020-02-06 10:46:05 <ncopa> i think it makes sense to have the upcate-ca.c tracked in separate git repo
2020-02-06 10:46:37 <clandmeter> maybe have 3 projects
2020-02-06 10:48:36 <clandmeter> update-ca-certificates (c based stuff), mk-ca-bundle (perl script), cacert which holds the versioned bundle.
2020-02-06 10:50:06 <ncopa> what im still in doubt with is if we should ship a pregenerated bundle
2020-02-06 10:50:09 <ncopa> i think we should
2020-02-06 10:51:07 <ncopa> the reason is that it woudl be a light way to make things work out of the box
2020-02-06 10:51:22 <clandmeter> yes thats what we do now
2020-02-06 10:51:43 <ncopa> and you would technically only need the full ca-certificates package in case you add your own certs
2020-02-06 10:52:02 <clandmeter> yes, but maybe also in other cases
2020-02-06 10:52:18 <ncopa> openjdk also needs ca-certificates i think
2020-02-06 10:52:32 <clandmeter> some projects will use cacertdir
2020-02-06 10:52:40 <ncopa> cacertdir?
2020-02-06 10:52:53 <clandmeter> instead of file you can specify the dir
2020-02-06 10:53:02 <clandmeter>  /etc/ssl/certs
2020-02-06 10:53:08 <ncopa> ah
2020-02-06 10:53:12 <ncopa> indeed
2020-02-06 10:53:24 <clandmeter> these proejcts should depend on ca-certificates
2020-02-06 10:53:26 <ncopa> those would also need to depend on ca-certificates
2020-02-06 10:53:28 <clandmeter> we do that already
2020-02-06 10:53:47 <clandmeter> i think curl will also pull in ca-certificates
2020-02-06 10:54:15 <ncopa> i think we need the bundle for the minirootfs
2020-02-06 10:54:28 <clandmeter> yes for ssl_client and apk
2020-02-06 10:54:48 <clandmeter> or whatever the bb thingy is called
2020-02-06 10:54:57 <ncopa> i dont think thoush shoudl depend on that
2020-02-06 10:55:04 <ncopa> i think only libssl shoudl depend on the bundle
2020-02-06 10:55:26 <ncopa> then it should get pulled in whenever needed
2020-02-06 10:55:46 <clandmeter> not depend but use
2020-02-06 10:56:04 <clandmeter> currently it depend in libtls_standalone iirc
2020-02-06 10:56:26 <ncopa> libtls-candalone should be linked to libssl
2020-02-06 10:56:37 <clandmeter> yes
2020-02-06 10:56:55 <clandmeter> but currently it uses /etc/ssl/cert.pem
2020-02-06 10:56:57 <clandmeter> as default
2020-02-06 10:57:19 <ncopa> i think we shoudl rename ca-certificates-cacert to ca-certificates-bundle, which is a better name
2020-02-06 10:57:37 <ncopa> and it should ship both ca-certificates.crt and cert.pem symlink
2020-02-06 10:57:54 <clandmeter> now that the python dep is gone, its fine by me
2020-02-06 10:58:00 <ncopa> and libssl should depend on ca-certificates-bundle
2020-02-06 10:58:34 <ncopa> that way we get the bundle into minirootfs (without crosscompile/crossarch issues)
2020-02-06 10:59:01 <clandmeter> so what will be the default system certiicate?
2020-02-06 10:59:25 <clandmeter> or we dont care due to the symlink?
2020-02-06 10:59:25 <ncopa> openssl uses /etc/ssl/cert.pem by default
2020-02-06 10:59:38 <ncopa> so we add asymlink
2020-02-06 10:59:47 <clandmeter> so when i add my own cert?
2020-02-06 10:59:59 <clandmeter> ca-certificates.crt gets generated
2020-02-06 11:00:13 <clandmeter> but libssl still takes cert.pem
2020-02-06 11:00:17 <ncopa> then you add ca-certificates package and run update-ca-certificates
2020-02-06 11:00:45 <ncopa> cert.pem is a symlink that points to ca-certificates.crt
2020-02-06 11:00:50 <ncopa> shoudl be i mean
2020-02-06 11:01:15 <clandmeter> so what does ca-certificates-bundle?
2020-02-06 11:01:24 <clandmeter> it must be the bundle
2020-02-06 11:01:47 <clandmeter> and it will be ca-certificates.crt?
2020-02-06 11:01:49 <ncopa> provides /etc/ssl/certs/ca-certificates.crt and a /etc/ssl/cert.pem symlink
2020-02-06 11:02:04 <clandmeter> ok so what happens when apk upgrade happens?
2020-02-06 11:02:10 <clandmeter> you will tet apk-new?
2020-02-06 11:03:08 <ncopa> you get the updated ca-certificates package, + the trigger will regenerate the bundle (overwrite the one from the pkg) and your local cert will get included
2020-02-06 11:04:01 <clandmeter> so ca-certificates provides bundle?
2020-02-06 11:04:19 <ncopa> no, ca-certificates-bundles provides the bundle
2020-02-06 11:04:35 <ncopa> ca-certificates provides the scripts to regenerate and ovwerite the precompiled bundle
2020-02-06 11:04:47 <clandmeter> else on a version upgrade of bundle will see an exiting cert and rename the new one to apk-new
2020-02-06 11:06:23 <clandmeter> i will let you solve it :)
2020-02-06 11:06:55 <ncopa> i think if you have a local cert you will end up with an .apk-new
2020-02-06 11:07:12 <ncopa> due to the ca-certificates-bundle
2020-02-06 11:07:29 <clandmeter> i just think a static file should not belong in /etc?
2020-02-06 11:09:00 <ncopa> its not a static file
2020-02-06 11:09:14 <ncopa> or you would not not be able to add your own certs
2020-02-06 11:12:27 <clandmeter> ca-certificates-bundle ships a static file right?
2020-02-06 11:12:52 <ncopa> it ships a precompiled bundle
2020-02-06 11:13:12 <clandmeter> which is static coming from apk
2020-02-06 11:13:28 <clandmeter> as its in the apk db
2020-02-06 11:13:48 <ncopa> that is why i previously said that technically, it would be cleaner if we didnt ship any precompiled bundle, but generated it from the trigger only
2020-02-06 11:14:01 <ncopa> which is the way the ca-certificates package was originally designed
2020-02-06 11:14:12 <clandmeter> yes, but that adds more files to base
2020-02-06 11:14:33 <clandmeter> and for a simple docker container you dont need cert management.
2020-02-06 11:14:49 <clandmeter> or any container
2020-02-06 11:15:04 <ncopa> correct, thats is why i think we ca provide a precompiled bundle as a hack
2020-02-06 11:20:02 <ncopa> i thikn we have 3 options:
2020-02-06 11:20:48 <ncopa> 1) remove update-ca-certificates tools and only ship a pregenerated bundle (openbsd style)
2020-02-06 11:21:44 <ncopa> 2) remove ca-certificates-cacert(bundle) and only provide ca-certificates (debian style). libssl shoudl depend on this, so ca-certificates will end up in base
2020-02-06 11:22:34 <clandmeter> i dont think its needed in base
2020-02-06 11:22:39 <clandmeter> and i think lots of ppl will complain
2020-02-06 11:22:51 <clandmeter> some ppl even try to get 10kbs outof base..
2020-02-06 11:23:01 <clandmeter> 10kb
2020-02-06 11:23:33 <ncopa> 3) we do both, a mix of the two above, we provide a ca-certificates-bundle package + ca-certificates. the bundle will end up in base. ca-certificates will "override" the bundle
2020-02-06 11:24:05 <clandmeter> funny thing is, some ppl dont want to add it but just copy ca-certificates to certs dir in container although cert.pem already exist.
2020-02-06 11:25:20 <clandmeter> if we do 3, please be aware if bundle gets upgraded it will see the generated bundle and copy it as ...apk-new which i think is not elegant.
2020-02-06 11:27:36 <ncopa> option 1 is simplest for us, but wil not be backwards compat. and will make it difficult for users to upgrade the cert. its a big change (which is good to avoid)
2020-02-06 11:28:20 <ncopa> option 2 will result in double size of certs in base, and may cause problems in generating minirootfs crossarch
2020-02-06 11:28:36 <ncopa> we'd depend on the trigger to generate the bundle
2020-02-06 11:28:59 <ncopa> i think certs/bundle is around 240k or similar
2020-02-06 11:29:21 <ncopa> so we'd end up with the double 400-500k extra
2020-02-06 11:29:27 <ncopa> thats the price
2020-02-06 11:29:59 <clandmeter> thats like a 10% increase of minirootfs?
2020-02-06 11:30:09 <clandmeter> nah less
2020-02-06 11:30:28 <ncopa> option 3 will result in .apk-new when user have its own certs, but should not result in .apk-new when there are no local certs
2020-02-06 11:31:16 <ncopa> the .apk-new is the price
2020-02-06 11:31:28 <clandmeter> you could work around it by putting the cert somewhere in usr/..
2020-02-06 11:32:03 <clandmeter> symlink it from post-install based on rule
2020-02-06 11:32:17 <ncopa> i dont think its worth it
2020-02-06 11:32:27 <ncopa> it will create new problems
2020-02-06 11:32:54 <clandmeter> we do not have a switch to disable apk-new per file?
2020-02-06 11:33:04 <ncopa> i dont think we do
2020-02-06 11:33:12 <ncopa> but you get .apk-new for alot
2020-02-06 11:33:28 <ncopa> for /etc/passwd, /etc/group etc
2020-02-06 11:33:36 <clandmeter> yes but they are not 250k
2020-02-06 11:34:53 <clandmeter> update-conf will also show it :)
2020-02-06 11:35:58 <ncopa> as i said, it will only happen if you have local certs
2020-02-06 11:36:07 <ncopa> so its not a big problem
2020-02-06 11:36:26 <ncopa> and i think its good to do small incremental changes
2020-02-06 11:36:40 <ncopa> if it becomes a problem in the future, then we deal with it
2020-02-06 11:36:48 <ncopa> this is what i propose: http://tpaste.us/dEdj
2020-02-06 11:42:03 <ncopa> clandmeter: would that be acceptable?
2020-02-06 11:43:08 <ncopa> i think i'd like to modify update-ca-certificates so it can be used to generate the bundle, but this is a quicker way to solve it
2020-02-06 11:43:55 <ncopa> after that, i think we can update the deps for a few packages, to depend on ca-certificates-bundle, direct or indirect via libssl
2020-02-06 11:46:07 <clandmeter> ok
2020-02-06 11:47:21 <clandmeter> so you are still including the perl script?
2020-02-06 11:48:17 <ncopa> its already pushed to git.a.o
2020-02-06 11:48:22 <clandmeter> i would prefer it to be a seperate pkg, so it also gets upgraded in a sane matter
2020-02-06 11:49:59 <ncopa> then we need add safety checks to verify that the format does not change in the shell script
2020-02-06 11:50:31 <clandmeter> it does not matter nor chang imho
2020-02-06 11:50:39 <clandmeter> the result we get is the same
2020-02-06 11:50:55 <clandmeter> home made or pulled from curl
2020-02-06 11:51:36 <clandmeter> but a safety check would be nice.
2020-02-06 11:51:52 <clandmeter> after you split it could could verify each cert
2020-02-06 11:52:14 <ncopa> how?
2020-02-06 11:52:19 <ncopa> with openssl?
2020-02-06 11:52:22 <clandmeter> openssl?
2020-02-06 11:52:32 <ncopa> then we get circular dependency
2020-02-06 11:52:52 <ncopa> build time
2020-02-06 11:53:12 <clandmeter> c_rehash will also read it
2020-02-06 11:53:12 <ncopa> openssl (libssl) -> ca-certificates-bundle -> openssl
2020-02-06 11:53:22 <clandmeter> and complain if something is wrong
2020-02-06 11:53:43 <clandmeter> but its run from trigger not in build atm
2020-02-06 11:54:25 <clandmeter> c_rehash does not need openssl?
2020-02-06 11:54:49 <ncopa> oh, it does
2020-02-06 11:54:50 <AinNero> it needs openssl
2020-02-06 11:54:51 <ncopa> bummer
2020-02-06 11:55:49 <ncopa> then we cannot let libssl depend on ca-certificates-bundle
2020-02-06 11:57:43 <clandmeter> ok i need to run to the barber or she will get mad at me.
2020-02-06 11:57:59 <ncopa> i give up
2020-02-06 11:58:13 <ncopa> i shoudl have done 3.11.5 release today
2020-02-06 11:58:23 <ncopa> and upstream my python patch
2020-02-06 12:23:43 <mps> ncopa: before 3.11.5 please check did you added lbu fix (which I posted) for openssl
2020-02-06 12:42:09 <mps> kernel 5.4 is finally declared as LTS
2020-02-06 12:42:24 <mps> after 5.4.18 released :)
2020-02-06 13:09:32 <Thermi> Hrrmpf. I tried bootstrap.sh in a new alpine VM and it fails when building the full GCC because it can't fullfill the dependency on musl and musl-dev
2020-02-06 13:11:11 <Thermi> tag v3.11.4 and tag v3.11.0 don't build either, but they already fail at binutils
2020-02-06 15:08:03 <ncopa> mps: i dont think i will have time for 3.11.5 today :-/
2020-02-06 15:16:18 <mps> ncopa: ok, np
2020-02-06 15:16:51 <mps> I'm for sure not in any hurry for it
2020-02-06 15:18:12 <mps> just mentioned this lbu fix so we do not forget it for next release
2020-02-06 15:20:36 <ncopa> mps: you mean this? 8712dcd5fa3b1f8e62e49504128a29f60bce5485
2020-02-06 15:21:51 <mps> sorry, I'm outside now and can confirm, will look when come back to home
2020-02-06 15:23:28 <mps> but, mkinitfs is fixed in 3.11.3 (4) already
2020-02-06 16:16:28 <mps> ncopa: yes, 8712dcd5fa3b1f8e62e49504128a29f60bce5485
2020-02-06 16:16:58 <mps> but why it is not fixed in 3.11.3 release
2020-02-06 16:18:02 <mps> do you need to make new alpine-conf release
2020-02-06 16:19:12 <mps> ah, no. you added patch to fix this, I see
2020-02-06 16:50:56 <kmaxwell> I think this is old news but the CI for s390 is failing for me repeatedly
2020-02-06 16:51:10 <north1> ah yes
2020-02-06 16:51:13 <north1> s390x is like that
2020-02-06 16:51:16 <kmaxwell> what's the right thing to do? ask someone to add a lable to my MR? https://gitlab.alpinelinux.org/keith.maxwell/aports/pipelines/6793
2020-02-06 16:52:32 <kmaxwell> that was not the right link https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3745
2020-02-06 17:02:45 <clandmeter> kmaxwell: sorry, the s390x has networking issues
2020-02-06 17:02:58 <clandmeter> i will try to reach out to the sysadmin
2020-02-06 17:03:44 <kmaxwell> clandmeter: thank you!
2020-02-06 17:15:43 <_ikke_> PureTryOut[m]: kaccounts-providers fails to build. fix-online-accounts-google.patch fails to apply
2020-02-06 17:18:12 <_ikke_> north1: broot fails to build on x86 due to linking errors
2020-02-06 17:25:36 <PureTryOut[m]> I mean, I did put the MR on WIP for a reason. It wasn't supposed to be merged yet...
2020-02-06 17:25:49 <_ikke_> d'oh
2020-02-06 17:26:35 <_ikke_> north1: ^ :)
2020-02-06 17:52:42 <PureTryOut[m]> _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3776
2020-02-06 17:53:40 <_ikke_> PureTryOut[m]: forgot to update checksums (remove the ones for the patch)
2020-02-06 17:54:17 <PureTryOut[m]> Woops
2020-02-06 17:54:35 <PureTryOut[m]> I'm doing this a bit hasty, sorry for that
2020-02-06 17:54:39 <_ikke_> np
2020-02-06 17:54:45 <_ikke_> luckily CI caught it :)
2020-02-06 17:54:52 <PureTryOut[m]> I have more time in like an hour
2020-02-06 17:55:00 <_ikke_> sure, np
2020-02-06 17:55:42 <_ikke_> I can fix it
2020-02-06 17:56:02 <PureTryOut[m]> Fixed
2020-02-06 17:56:17 <_ikke_> ok, thanks
2020-02-06 19:19:06 <mps> anyone know why drbd is not enabled for ppc64le kernel, # CONFIG_BLK_DEV_DRBD is not set
2020-02-06 19:19:31 <mps> also for mips64
2020-02-06 19:19:56 <mps> kaniini: ping
2020-02-06 19:42:03 <kaniini> I can enable it
2020-02-06 19:46:13 <mps> for both arch?
2020-02-06 20:04:24 <kaniini> yes
2020-02-06 20:05:06 <mps> ok, thanks
2020-02-06 20:34:49 <_ikke_> broot fails to build on x86 with "hidden symbol `__stack_chk_fail_local' isn't defined"
2020-02-06 20:34:52 <_ikke_> it's a rust project
2020-02-06 20:35:12 <_ikke_> If I look around it seems to be a common issue, where most of the time, it's solved by using gcc instead of ld to link
2020-02-06 21:13:19 <Cogitri> Don't we usually just disabled fstack-protector on x86 for that?
2020-02-06 21:13:46 <Cogitri> (Not that that's a good thing, would be nice if there was a different way to fix it)
2020-02-06 21:14:26 <Cogitri> (Although post-FOSDEM flu infected me probably wouldn't be useful with fixing that)
2020-02-06 21:17:45 <_ikke_> Last change was an update, so I assume it did build before
2020-02-06 21:24:21 <Cogitri> Seeing how all Rust packages that link to native libraries experience those failures I'm fairly confident to say that it's on the fstack-protector thingie
2020-02-06 21:24:50 <_ikke_> yeah, you're probably right
2020-02-06 21:39:06 <dalias> _ikke_, the compiler driver knows it needs to pass -lssp_nonshared whenever linking
2020-02-06 21:39:20 <dalias> bypassing that and running ld directly is going to break in lots of other bad ways too
2020-02-06 21:57:01 <_ikke_> dalias: thanks, but not really sure what I can do with that information
2020-02-06 21:59:38 <dalias> if rustc runs ld itself, it needs to be taught to pass -lssp_nonshared
2020-02-06 22:01:37 <_ikke_> dalias: alright, thanks
2020-02-06 22:07:04 <Cogitri> Huh, somehow I was under the impression that Rust does use GCC though
2020-02-06 22:07:29 <_ikke_> Cogitri: I read somewhere the default is "cc"
2020-02-06 22:08:05 <_ikke_> https://stackoverflow.com/a/57817848
2020-02-06 22:13:29 <_ikke_> heh https://git.alpinelinux.org/aports/commit/?id=ed42835662421a72dbc1c47397a2805306203860
2020-02-06 22:15:37 <dalias> _ikke_, what release is that?
2020-02-06 22:16:17 <_ikke_> of broot?
2020-02-06 22:16:34 <_ikke_> 0.13.0
2020-02-06 22:19:22 <dalias> _ikke_, the above musl package fix -- i guess that's one of the stable branches of alpine?
2020-02-06 22:19:41 <dalias> oh nm
2020-02-06 22:19:44 <dalias> it's just an old commit
2020-02-06 22:19:47 <dalias> i was confused
2020-02-06 22:20:21 <_ikke_> yea
2020-02-06 22:20:52 <_ikke_> I found it because it contained "__stack_chk_fail_local.c"
2020-02-06 22:22:26 <dalias> ah
2020-02-06 23:17:07 <mps> !3782 MR need review and test before push
2020-02-07 08:42:14 <russkel> is the s390 CI instance broken?
2020-02-07 08:46:30 <russkel> https://gitlab.alpinelinux.org/russkel/aports/-/jobs/46191
2020-02-07 08:46:45 <russkel> all the s390x pipelines stall here
2020-02-07 08:50:43 <clandmeter> yes its broken
2020-02-07 08:57:54 <russkel> is that instance an actual s390 machine?
2020-02-07 08:58:15 <russkel> worker*
2020-02-07 08:58:43 <clandmeter> yes
2020-02-07 09:15:10 <russkel> alright, thanks clandmeter
2020-02-07 12:55:57 <mps> ncopa: are you around?
2020-02-07 12:56:43 <mps> did you had time to look at these two MRs !3344 and !3482, which are actually same
2020-02-07 13:46:41 <Thermi> I think I got the annoying strip problem solved, testing right now
2020-02-07 13:51:04 <Thermi> fabled: I think I got that strip problem figured out. I'm testing right now.
2020-02-07 13:58:17 <fabled> Thermi, nice
2020-02-07 14:07:05 <seraxis> Are the Creating an Alpine package instructions at https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package still valid?
2020-02-07 14:07:46 <_ikke_> yes, should be mostly ok
2020-02-07 14:20:46 <bl4ckb0ne> iirc the link to the mailing list is not up to date
2020-02-07 14:20:50 <bl4ckb0ne> but it might not be this page
2020-02-07 14:21:36 <Thermi> fabled: https://gitlab.alpinelinux.org/Thermi/abuild/merge_requests/1
2020-02-07 14:21:44 <Thermi> Wait
2020-02-07 14:21:50 <Thermi> I think I did it wrong. x)
2020-02-07 14:25:39 <Thermi> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/22
2020-02-07 14:25:41 <Thermi> yaaaaay.
2020-02-07 14:27:56 <seraxis> Nice, thanks!
2020-02-07 14:30:08 <fabled> Thermi, what is the input value when the current code fails?
2020-02-07 14:31:04 <Thermi> fabled: These are the variable values at the time the switch is called: https://bpaste.net/HVWA
2020-02-07 14:31:17 <Thermi> When cross compiling zlib as part of bootstrap.sh
2020-02-07 14:31:50 <Thermi> Here's gcc: https://bpaste.net/TPIA
2020-02-07 14:32:14 <fabled> that does not look right. all the *ARCH are aarch64
2020-02-07 14:32:46 <Thermi> Yeah, not right at all. I completely built gcc (both passes) with my code change so this should be okay
2020-02-07 14:33:06 <Thermi> I am going after some other problems right now. :)
2020-02-07 14:33:11 <Thermi> All having to do with the bootstrap
2020-02-07 14:33:26 <fabled> why are *ARCH setup wrong?
2020-02-07 14:33:31 <Thermi> Hell if I knew
2020-02-07 14:33:55 <fabled> i am also dubious about stripcmd="$(arch_to_hostspec ${CTARGET_ARCH})-strip"
2020-02-07 14:34:07 <Thermi> All other stuff is 100% upstream
2020-02-07 14:34:22 <fabled> why not then just stripcmd="$(arch_to_hostspec ${subpkgarch:-$pkgarch})-strip" ?
2020-02-07 14:34:23 <Thermi> it's also running in a clean Alpine VM, so no docker in play or any other fancy things
2020-02-07 14:34:38 <fabled> but i think something is broken earlier
2020-02-07 14:34:58 <fabled> if CBUILD_ARCH is not set properly, there's probably other stuff breaking
2020-02-07 14:35:00 <Thermi> fabled: Because the -strip, -gcc for the other arch has the prefix of the hostspec, not the arch
2020-02-07 14:35:09 <Thermi> there's no aarch64-strip
2020-02-07 14:35:24 <fabled> but i called arch_to_hostspec for it
2020-02-07 14:35:32 <fabled> just replaced CTARGET_ARCH with the subpkgarch:-$pkgarch
2020-02-07 14:35:56 <Thermi> there's aarch64-alpine-linux-musl-strip though
2020-02-07 14:36:45 <Thermi> fabled: Do you mind replicating your own code change in a clean VM, please?
2020-02-07 14:37:02 <Thermi> I think there might be some changes in your own setup that could make this work
2020-02-07 14:38:15 <fabled> what's the command you launch abuild with?
2020-02-07 14:38:23 <Thermi> It's what bootstrap.sh does
2020-02-07 14:39:21 <fabled> the prolem is that CBUILD_ARCH=aarch64 for you, but it should equal $(arch)
2020-02-07 14:39:39 <Thermi> As I wrote earlier, it's the same code as upstream
2020-02-07 14:40:52 <Thermi> CHOST=$TARGET_ARCH BOOTSTRAP=bootimage APKBUILD=$(apkbuildname $PKG) abuild -r
2020-02-07 14:40:57 <Thermi> There's what in the bootstrap.sh is
2020-02-07 14:41:27 <fabled> is CC set in environment?
2020-02-07 14:41:33 <Thermi> No
2020-02-07 14:41:50 <fabled> CBUILD defaults to ${CC:-gcc} -dumpmachine
2020-02-07 14:42:02 <Thermi> https://bpaste.net/QP6Q
2020-02-07 14:42:20 <fabled> gcc -dumpmachine ?
2020-02-07 14:42:28 <Thermi> fabled: Couldn't you just run the bootstrap script in a clean VM and see the whole thing for yourself?
2020-02-07 14:42:38 <Thermi>  gcc -dumpmachine
2020-02-07 14:42:38 <Thermi> x86_64-alpine-linux-musl
2020-02-07 14:43:08 <fabled> i wonder if something broke in abuild/functions.sh
2020-02-07 14:44:46 <Thermi> 🀷
2020-02-07 14:47:17 <Thermi> I'm happy if I got this problem fixed for now. The next one is with lua and the mv
2020-02-07 14:47:44 <Thermi> I'm going to bury you in PRs for every single one of these issues
2020-02-07 14:48:10 <Thermi> Don't even care if you merge any of them. πŸ˜‚
2020-02-07 14:50:17 <fabled> anything suspicious in $HOME/.abuild/abuild.conf, /etc/abuild.conf, or $aports/.abuild ?
2020-02-07 14:50:57 <Thermi> all defaults
2020-02-07 14:51:05 <Thermi> (except the key stuff obv)
2020-02-07 14:51:13 <Thermi> As I wrote, this is a clean VM
2020-02-07 14:51:20 <Thermi> I put it together yesterday without any shenanigans
2020-02-07 14:59:39 <fabled> what's the package/build stage where it fails?
2020-02-07 14:59:45 <fabled> just started build..
2020-02-07 14:59:51 <fabled> in clean chroot
2020-02-07 15:03:54 <omni> I'll say it here too
2020-02-07 15:04:07 <omni> hi, I noticed that the only way to load microcode provided by the intel-ucode package, when using syslinux and running as a Xen Dom0, is to extract the blob from /boot/intel-ucode.img and put it, with the full path, in the initramfs and have 'ucode=scan' at the Xen command line
2020-02-07 15:05:53 <omni> I'll try to come around and file a report in the issue tracker, but wanted to mention it at least
2020-02-07 15:08:30 <omni> it's at gitlab.alpinelinux.org and this would go in alpine/mkinitfs, no?
2020-02-07 15:12:40 <clandmeter> fabled: regarding the apk change of index and making the build time decide which pkg is being installed. does this make the pkgrel disappear?
2020-02-07 15:13:19 <fabled> i think we decided not to go build time. at least not yet, there's unsolved problems
2020-02-07 15:13:37 <clandmeter> ok, sorry i didnt read up on all of it
2020-02-07 15:13:47 <clandmeter> i think removing the pkgrel will cause issues
2020-02-07 15:13:50 <_ikke_> I think having a pkgrel is still important
2020-02-07 15:13:52 <_ikke_> right
2020-02-07 15:14:02 <clandmeter> cdn will need unique pkgnames
2020-02-07 15:14:27 <_ikke_> But even without cdn, I think if you make changes to a package, you need to be able see that it's a new release
2020-02-07 15:14:57 <_ikke_> Unless you make the buildtime part of the package version
2020-02-07 15:15:05 <fabled> sometimes it's same pkgver + pkgrel but from different branch so the file content is different
2020-02-07 15:17:28 <clandmeter> fabled: i think we did modify function.sh recently
2020-02-07 15:17:33 <clandmeter> not sure you saw the change
2020-02-07 15:17:37 <clandmeter> regarding arch
2020-02-07 15:18:31 <clandmeter> ncopa added a workaround when gcc is not available, the arch would be set to unknown.
2020-02-07 15:18:48 <fabled> i think it's not correct for cross-compile, but probably ok in regular setups
2020-02-07 15:18:54 <_ikke_> wouldn't it use apk --arch then?
2020-02-07 15:19:04 <_ikke_> at least, that's why I recall the commit message being
2020-02-07 15:19:11 <clandmeter> it is now
2020-02-07 15:19:11 <_ikke_> s/why/what
2020-02-07 15:19:11 <alpine-meetbot> _ikke_ meant to say: at least, that's what I recall the commit message being
2020-02-07 15:19:13 <_ikke_> ok
2020-02-07 15:19:26 <clandmeter> but its a fix which could break cross
2020-02-07 15:19:33 <clandmeter> like fabled mentioned
2020-02-07 15:19:35 <_ikke_> right
2020-02-07 15:19:57 <clandmeter> he is our crosscompile master so he probably knows better how to fix it in both worlds
2020-02-07 15:20:04 <fabled> but you need to set the targets manually for crosscompile anyway
2020-02-07 15:20:33 <clandmeter> i have not played with boostrap.sh before, its on my todo
2020-02-07 15:24:54 <clandmeter> fabled: what i worked on was to have a proof of concept to have a builder in docker. it would bootstrap the builder from edge to stable and start building world. so i bumped into a few issues like functions depends on gcc but abuild does not, and ca-certificates has build dep on python which makes the deplist of alpine base much larger (python3
2020-02-07 15:24:54 <clandmeter> pulls in a lof of things).
2020-02-07 15:27:54 <Thermi> Also broken when cross compiling: https://gitlab.alpinelinux.org/alpine/aports/issues/11198
2020-02-07 15:28:11 <clandmeter> fabled: regrading pkgrel, i wondered if it was sane to have the builder dedice the pkgrel based on previous number.
2020-02-07 15:30:27 <fabled> uhm. gcc9 ada has cross-compile issue
2020-02-07 15:31:58 <fabled> i mean, creating the cross compiler fails in some weird message related to libatomic and other stuff
2020-02-07 15:33:46 <_ikke_> clandmeter: but then you completely decouple the pkgrel from commits
2020-02-07 15:33:51 <_ikke_> as source
2020-02-07 15:36:19 <fabled> Thermi, the split should not be run
2020-02-07 15:36:29 <fabled> APKBUILD has if [ "$CBUILD" = "$CHOST" ]; then ....
2020-02-07 15:36:38 <fabled> but since your CBUILD is setup wrong, it'll blow up everything
2020-02-07 15:37:12 <fabled> we really need to figure out why CBUILD is wrong for you
2020-02-07 15:38:54 <fabled> Thermi, how do you call bootstrap.sh? maybe it inherits CBUILD from somewhere?
2020-02-07 15:41:07 <fabled> maybe print CBUILD in start of bootstrap.sh to see what it produces. you can also try export CBUILD=$(aarch) there if it'd fix things
2020-02-07 15:42:34 <clandmeter> _ikke_: yes but you have the commit in the pkg
2020-02-07 15:43:32 <fabled> pkgrel has had two purposes: to trigger build by incrementing it (when version did not change), and to help apk-tools to decide which package build is latest
2020-02-07 15:44:00 <fabled> git could give number of versions modified if we wanted, but that changes if eg. just comments added or something else not requiring comming
2020-02-07 15:44:16 <fabled> also recompile might be needed when dependency library changes ABI
2020-02-07 15:46:14 <Thermi> scripts/bootstrap.sh aarch64
2020-02-07 15:46:44 <Thermi> fabled: ^
2020-02-07 15:46:46 <fabled> in the environment
2020-02-07 15:47:16 <Thermi> That's the env: https://bpaste.net/QP6Q
2020-02-07 15:48:07 <fabled> does it help if you explicitly export CBUILD=$(arch) or so
2020-02-07 15:49:18 <Thermi> "CHOST=aarch64-alpine-linux-musl" appears in trace of abuild
2020-02-07 15:49:36 <fabled> yes, that's set by bootstrap.sh
2020-02-07 15:49:46 <fabled> CBUILD is broken
2020-02-07 15:49:52 <Thermi> We're looking for CBUILD or CHOST?
2020-02-07 15:49:54 <Thermi> CBUILD?
2020-02-07 15:49:55 <fabled> CBUILD
2020-02-07 15:50:05 <fabled> CBUILD == the machine running
2020-02-07 15:50:13 <fabled> CHOST == the machine the code will run on
2020-02-07 15:50:23 <fabled> CTARGET == the machine the gcc compiler generate code for
2020-02-07 15:50:26 <Thermi> is set after -dumpmachine ruzns
2020-02-07 15:50:28 <Thermi> *runs
2020-02-07 15:50:35 <Thermi> I got -x output for abuild here
2020-02-07 15:50:59 <fabled> CTARGET is only useful for compiling gcc
2020-02-07 15:51:44 <Thermi> That's setting it wrongly then: https://gitlab.alpinelinux.org/Thermi/abuild/blob/master/functions.sh.in#L120
2020-02-07 15:51:59 <Thermi> Maybe we need to export CBUILD=$1 in bootstrap.sh?
2020-02-07 15:52:07 <Thermi> errr
2020-02-07 15:52:11 <Thermi> CBUILD=$(arch) or something
2020-02-07 15:52:28 <fabled> functions.sh should default it to gcc -dumpmachine
2020-02-07 15:52:30 <fabled> which should be right
2020-02-07 15:52:40 <fabled> so maybe something overwrites it later?
2020-02-07 15:52:45 <Thermi> + aarch64-alpine-linux-musl-gcc -dumpmachine
2020-02-07 15:52:52 <Thermi> + CBUILD=aarch64-alpine-linux-musl
2020-02-07 15:52:56 <fabled> ok
2020-02-07 15:52:57 <Thermi> That's what it does in fact
2020-02-07 15:53:03 <fabled> that's the problem
2020-02-07 15:53:06 <Thermi> + '[' -z  ]
2020-02-07 15:53:33 <fabled> hum
2020-02-07 15:53:46 <fabled> ah
2020-02-07 15:54:23 <fabled> ok, make bootstrap.sh just export CBUILD after it has executed functions.sh
2020-02-07 15:54:26 <fabled> the problem is
2020-02-07 15:54:32 <fabled> function.sh exports CC too
2020-02-07 15:54:45 <fabled> i wonder why it used to work
2020-02-07 15:55:22 <fabled> ah
2020-02-07 15:55:28 <fabled> commit 95cd15c02501ec178a69333d136207f695550044 broke it
2020-02-07 15:55:35 <fabled> -       [ -z "$CBUILD" ] && CBUILD="$(gcc -dumpmachine)"
2020-02-07 15:55:35 <fabled> +       [ -z "$CBUILD" ] && CBUILD="$(${CC:-gcc} -dumpmachine 2>/dev/null || true)"
2020-02-07 15:55:39 <fabled> makes it use $CC
2020-02-07 15:55:48 <fabled> which is not we want in cross compile
2020-02-07 15:55:49 <Thermi> Please be specific, you lost me
2020-02-07 15:56:00 <Thermi> So just export CBUILD=WHAT?
2020-02-07 15:57:04 <fabled> http://sprunge.us/CRXYPs
2020-02-07 15:57:58 <fabled> ncopa, https://git.alpinelinux.org/abuild/commit/?id=95cd15c02501ec178a69333d136207f695550044 broke bootstrap.sh
2020-02-07 15:58:12 <fabled> namely:
2020-02-07 15:58:12 <Thermi> How many lashes with the whip is that?
2020-02-07 15:58:12 <fabled>  
2020-02-07 15:58:12 <fabled> -	[ -z "$CBUILD" ] && CBUILD="$(gcc -dumpmachine)"
2020-02-07 15:58:12 <fabled> +	[ -z "$CBUILD" ] && CBUILD="$(${CC:-gcc} -dumpmachine 2>/dev/null || true)"
2020-02-07 15:58:23 <fabled> wondering if we can revert that?
2020-02-07 15:58:37 <fabled> or do we need to fix bootstrap.sh or something else
2020-02-07 16:00:37 <clandmeter> fabled: if you revert it it will set arch to unknown when gcc is not available
2020-02-07 16:00:49 <fabled> but gcc is in build-base
2020-02-07 16:00:49 <clandmeter> i mean the whole commit
2020-02-07 16:01:05 <clandmeter> function.sh is in abuild
2020-02-07 16:01:10 <clandmeter> abuild does not depend on gcc
2020-02-07 16:01:31 <fabled> but build-base is implicit dependency
2020-02-07 16:01:36 <fabled> so it's assumed present
2020-02-07 16:01:39 <fabled> but yeah
2020-02-07 16:01:44 <clandmeter> in which case?
2020-02-07 16:01:49 <fabled> always. on builders.
2020-02-07 16:01:58 <fabled> abuild should depend on build-base instead
2020-02-07 16:02:03 <clandmeter> abuild will pull in build-base
2020-02-07 16:02:14 <clandmeter> if its not available
2020-02-07 16:02:33 <fabled> yeah. it was hack to get bootstrap building work somehow
2020-02-07 16:03:13 <clandmeter> if i have a container that needs to build a package, does it need build-base?
2020-02-07 16:03:22 <clandmeter> or shall abuild take care of it
2020-02-07 16:03:42 <fabled> it speeds up things if you have build-base there
2020-02-07 16:03:42 <clandmeter> so the container has minimal depencencies
2020-02-07 16:03:52 <fabled> abuild will otherwise try to install it always
2020-02-07 16:04:00 <clandmeter> right
2020-02-07 16:04:55 <fabled> hmm.. seems the idea was that abuild-sign would work without gcc
2020-02-07 16:05:20 <clandmeter> yeah, but it does not know which arch
2020-02-07 16:05:35 <fabled> so that's why the "apk --print-arch" was added
2020-02-07 16:05:44 <clandmeter> exactly
2020-02-07 16:06:09 <fabled> maybe use that then explicitly?
2020-02-07 16:06:39 <clandmeter> this is what i suggested to ncopa, but he had some doubts or he did not understand me.
2020-02-07 16:06:55 <fabled> mmm
2020-02-07 16:07:20 <clandmeter> i think he does not know much about the boostrap process
2020-02-07 16:07:38 <fabled> he does. but it's very fragile and easy to get wrong without quite a bit of testing
2020-02-07 16:07:52 <clandmeter> he mention to me he doesnt :)
2020-02-07 16:08:40 <clandmeter> im just trying to repeat what he said in private. not sure i remember it all correctly.
2020-02-07 16:09:03 <fabled> how about then use 'arch' or 'uname -m' output to decide build architecture?
2020-02-07 16:09:28 <clandmeter> is that sane?
2020-02-07 16:09:48 <clandmeter> i think you will have issues with arm
2020-02-07 16:09:52 <fabled> we'd need new mapping
2020-02-07 16:09:59 <clandmeter> right
2020-02-07 16:10:15 <fabled> the existing arch_to_hostspec expectes alpine APKBUILD arch; not the command arch output
2020-02-07 16:10:24 <clandmeter> what is wrong with apk --print-arch?
2020-02-07 16:11:23 <fabled> i think originally it was not present during early bootstrap without packaging (aka gentoo derivative days decades ago)
2020-02-07 16:11:29 <fabled> but now it should be
2020-02-07 16:11:40 <fabled> possibly the idea was that abuild could run on non-alpine hosts too
2020-02-07 16:13:09 <[[sroracle]]> if that's the case you can just use --print-arch and allow overriding the variable in which it's stored for bootstrapping purposes imo
2020-02-07 16:13:59 <[[sroracle]]> and die if it's unset because apk is not on the host system, then the bootstrapper sets it manually
2020-02-07 16:14:05 <fabled> yeah
2020-02-07 16:14:14 <fabled> that's about what was coming to also
2020-02-07 16:14:32 <fabled> use apk --print-arch; if not available fail with error message saying to set CBUILD
2020-02-07 16:14:47 <fabled> or fallback to use $(arch)
2020-02-07 16:15:03 <clandmeter> is arch always available?
2020-02-07 16:15:19 <Thermi> fabled: Now bootstrap.sh fails at building go-bootstrap because there's a makedepend on go
2020-02-07 16:15:19 <fabled> it's busybox built-in, and i think in coreutils or similar
2020-02-07 16:15:41 <clandmeter> i think i noticed it was missing on some other dists
2020-02-07 16:15:46 <[[sroracle]]> well idk if it should be stored directly in CBUILD since most things will expect a tuple there
2020-02-07 16:16:31 <clandmeter> i dont think we ship arch with coreutils.
2020-02-07 16:17:10 <fabled> Thermi, that should be ok; it makedepends on go being available on the build computer
2020-02-07 16:17:26 <Thermi> fabled: But why doesn't it auto install them then?
2020-02-07 16:17:48 <Thermi> *that
2020-02-07 16:21:12 <clandmeter> if you boostrap the pkg is not available? and after boostrap you dont want circular deps.
2020-02-07 16:21:34 <fabled> Thermi, maybe something is broken in the go apkbuild then
2020-02-07 16:21:43 <Thermi> 
ACTION heavily sighs

2020-02-07 16:21:50 <Thermi> installing go on the host system works though
2020-02-07 16:22:12 <Thermi> After enabling the community repo of course
2020-02-07 16:24:23 <clandmeter> oh go-bootstrap, does that still work for recent go version?
2020-02-07 16:25:26 <minecrell> fabled: Since you added the HOSTCC variable to kernel APKBUILDs, can you take a brief look at https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3781 ?
2020-02-07 16:28:23 <Thermi> fabled: Btw, gcc config in linux-lts is incomplete and prompts the user for stuff
2020-02-07 16:28:55 <fabled> minecrell, looks ok to me
2020-02-07 16:29:02 <fabled> Thermi, sounds like outdated kernel config
2020-02-07 16:29:09 <minecrell> fabled: thanks
2020-02-07 16:29:11 <Thermi> Fresh from aports
2020-02-07 16:29:20 <fabled> need to go
2020-02-07 16:33:30 <mps> Thermi: can you tell when it prompts user
2020-02-07 16:35:45 <mps> did you change kernel config file?
2020-02-07 18:23:44 <ncopa> fabled: sorry been busy with other stuff
2020-02-07 19:05:05 <Thermi> mps: No all upstream. I'm on battery right now, so I don't want to run a kernel build RN
2020-02-07 19:07:20 <Thermi> literally just built what is in aports
2020-02-07 19:07:24 <Thermi> no changes to anything
2020-02-07 19:07:38 <mps> with 'abuild -r'?
2020-02-07 19:08:36 <Thermi> Yes
2020-02-07 19:08:57 <Thermi> cross compiled though, obviously, because it was as part of bootstrap.sh
2020-02-07 19:08:58 <mps> ok, np. when you come back and try again you can post build log
2020-02-07 19:09:31 <Thermi> It's in a clean VM, so it's 100% reproducible
2020-02-07 19:09:57 <mps> ah, you were person from few days ago when we talked about bootstrap issues?
2020-02-07 19:10:20 <Thermi> Yes, and the same person from 3 hours ago
2020-02-07 19:10:26 <Thermi> Just scroll up
2020-02-07 19:10:33 <mps> I see
2020-02-07 19:11:14 <mps> ok, when you come back to dev box we can try to look if I can help somehow
2020-02-07 19:30:21 <fabled> ncopa, no worries. just wondering how to properly fix https://gitlab.alpinelinux.org/alpine/abuild/issues/9974
2020-02-07 19:56:51 <fabled> ncopa, how about something like http://sprunge.us/NEixG5 ?
2020-02-07 20:18:09 <Thermi> I'm building right now and it seems that the virtual dependencies are not uninstalled correctly after building the packet
2020-02-07 20:18:26 <Thermi> that breaks later builds because of conflicting packets and already existing files
2020-02-07 20:18:30 <Thermi> ncopa: fabled ^
2020-02-07 20:28:51 <ncopa> fabled: probably ok. its weekend here and im tired. feel free to push it if it is blocking you
2020-02-07 20:29:02 <ncopa> i can have a closer look next week
2020-02-07 21:12:14 <Thermi> Also linux-headers doesn't build because some of the patches that are applied create files that already exist
2020-02-07 21:22:54 <Thermi> and >>> pkgconf-doc*: Running split function doc...
2020-02-07 21:22:55 <Thermi> mv: can't rename '/home/buildozer/aports/main/pkgconf/pkg/pkgconf/usr/share/doc': Directory not empty
2020-02-07 21:24:30 <Thermi> Same for zlib
2020-02-07 21:24:30 <Thermi> >>> zlib-dev*: Running split function dev...
2020-02-07 21:24:30 <Thermi> mv: can't rename '/home/buildozer/aports/main/zlib/pkg/zlib/usr/include': Directory not empty
2020-02-07 21:34:39 <Thermi> analogue for linux-lts: patching file arch/s390/purgatory/Makefile
2020-02-07 21:34:40 <Thermi> The next patch would create the file arch/s390/purgatory/string.c,
2020-02-07 21:34:40 <Thermi> which already exists!  Skipping patch.
2020-02-07 21:34:40 <Thermi> 1 out of 1 hunk ignored
2020-02-07 21:50:32 <fabled> Thermi, seems i can't get arch64 cross-compiler of gcc 9.2 built. which gcc version you have?
2020-02-07 21:59:48 <fabled> oh, it' the D-language support
2020-02-08 08:23:52 <craftyguy> I would like to run the aports linting stuff locally, gitlab CI seems to be using a script called 'changed-aports' but I don't see it in the aports repo. Where can I find this, or how can I run the same linting that the CI runs locally?
2020-02-08 08:24:42 <craftyguy> oh, maybe this is something in Alpine
2020-02-08 08:26:39 <russkel> craftyguy, https://gitlab.alpinelinux.org/alpine/infra/gitlab-ci-templates
2020-02-08 08:27:16 <_ikke_> russkel: that's just the gitlab-ci templates
2020-02-08 08:27:18 <_ikke_> heh
2020-02-08 08:27:20 <_ikke_> it's in the name
2020-02-08 08:27:46 <_ikke_> craftyguy: https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/blob/master/overlay/usr/local/bin/changed-aports
2020-02-08 08:28:07 <_ikke_> craftyguy: there is also a docker image you can use
2020-02-08 08:28:11 <russkel> it was supposed to be a link to infra
2020-02-08 08:29:39 <craftyguy> thanks!
2020-02-08 08:30:34 <craftyguy> ah yeah that's a bit involved, to the point where doing it in docker is probably 'easier', in which case, I'll just abuse the gitlab CI :P
2020-02-08 08:34:48 <_ikke_> note that you can just install atools to get the codestyle linting
2020-02-08 08:37:45 <minecrell> craftyguy: you can also download apkbuild-lint from https://gitlab.alpinelinux.org/Leo/atools/blob/master/apkbuild-lint and pretty much run it on any distro
2020-02-08 08:38:23 <craftyguy> _ikke_: yeah I'm not using alpine on the system I am tracking changes/pushing patches
2020-02-08 08:38:37 <craftyguy> minecrell: nice, I'll take a look at that
2020-02-08 08:40:11 <russkel> craftyguy, takes a few minutes to get a docker image up and running with alpine ;)
2020-02-08 08:40:38 <craftyguy> yeah yeah :P
2020-02-08 08:41:25 <craftyguy> but my workflow would be weird (push changes to a docker thing, lint, fix, push changes to docker thing, lint, etc)
2020-02-08 08:41:41 <craftyguy> ideally linting would happen in my editor (vim) :D
2020-02-08 08:42:08 <craftyguy> I haven't looked into that possibility at all though, and don't expect anyone here to either
2020-02-08 08:42:31 <minecrell> craftyguy: should be possible to integrate it into vim I guess?
2020-02-08 08:43:48 <craftyguy> yeah I'm sure it is
2020-02-08 08:53:06 <craftyguy> hmm I think the 'build-*" CI jobs are broken. ">>> No packages found to be built."
2020-02-08 08:53:17 <craftyguy> https://gitlab.alpinelinux.org/craftyguy/aports/pipelines/6941
2020-02-08 09:12:46 <_ikke_> craftyguy: you can install a tools even outside of alpine
2020-02-08 09:13:27 <_ikke_> The output should be suitable to integrate into editors, but AFAIK there no existing ones yet
2020-02-08 09:15:08 <mps> interesting idea, have apkbuild-lint as vim plugin
2020-02-08 09:16:01 <craftyguy> well, or a standalone linter that vim 'lint' plugins (e.g. ale?) can use
2020-02-08 09:16:46 <craftyguy> anyways, my most pressing matter is that the aports CI doesn't seem to actually build anything in merge requests
2020-02-08 09:16:58 <_ikke_> Integrating one ALE would make sense
2020-02-08 09:17:19 <mps> ALE?
2020-02-08 09:18:53 <_ikke_> Vim plugin that integrates a lot of linting tools
2020-02-08 09:20:11 <mps> ah, yes, remember now that I read about it but didn't installed. to big for me
2020-02-08 09:21:38 <mps> i use just few plugins and select small ones if I can
2020-02-08 09:21:53 <russkel> or vs-code ;) ;) ;)
2020-02-08 09:22:11 <mps> oh, no
2020-02-08 09:22:36 <craftyguy> yeah! we should run everything in electron!
2020-02-08 09:22:39 <russkel> 
ACTION pokes mps

2020-02-08 09:22:41 <mps> typing lag annoys me
2020-02-08 09:23:09 <craftyguy> every application ever should have a fully featured web browser that doesn't receive updates behind it!
2020-02-08 09:23:23 <craftyguy> 
ACTION out

2020-02-08 09:24:15 <russkel> hahaha
2020-02-08 09:25:33 <mps> well, I prefer small (and sharp) tools (in spirit of alpine) not big and heavy ones
2020-02-08 09:25:44 <russkel> not going to lie I actually quite like vscode, but the idea behind electron sucks
2020-02-08 09:29:32 <mps> installed it once for daughter when she needed it for university classes, what a pain
2020-02-08 09:30:14 <mps> vscode, I mean
2020-02-08 09:30:26 <russkel> it's very much the sum of the parts that makes it good rather than the tech it uses
2020-02-08 09:32:19 <mps> long time ago I read Mijamoto Musashi book 'Five rings' (gorin no shyo) and especially liked part about knowing and keeping tools, small and sharp
2020-02-08 09:32:42 <mps> good book to read for those who want to be good craftsman
2020-02-08 09:49:01 <russkel> I wonder if that metaphor can carry across when the modern computer is as complicated as it is haha
2020-02-08 09:53:28 <mps> imo, computers are not complicated but 'we' make it complicated. featurism and marketing
2020-02-08 09:56:13 <mps> (at the end not only computers, 'we' like to complicate everything :) )
2020-02-08 09:59:25 <russkel> yeah maybe
2020-02-08 10:03:40 <mps> 'perfection is not when you don't have anything to add, but when you don't have anything to take of' (Leonardo da Vinchi, iirc)
2020-02-08 10:06:24 <russkel> I feel featurism is a result of people having different use cases though
2020-02-08 12:06:05 <north1> @craftguy apkbuild-lint has a defined output for errors that should not be hard to integrate into other tools
2020-02-08 12:07:44 <fabled> Thermi, pushed few abuild, gcc and bootstrap.sh fixes. and all looks pretty good now. doing final linux-lts cross-compile.
2020-02-08 12:08:02 <fabled> there was few recent gcc changes that broke things several ways
2020-02-08 12:27:52 <_ikke_> north1: can something be done about broot?
2020-02-08 12:27:57 <_ikke_> it's keeping x86 stuck
2020-02-08 12:29:07 <north1> Disabling
2020-02-08 12:29:16 <north1> Im not at PC atm and won't be for several hours
2020-02-08 12:29:34 <_ikke_> I can disable it, but would be nice if we could at least put some effort into finding how to get it to work
2020-02-08 12:38:10 <Cogitri> Still the fstack-protector thingie?
2020-02-08 12:38:14 <_ikke_> yes
2020-02-08 12:38:21 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/11201
2020-02-08 12:39:05 <Cogitri> Ah yes
2020-02-08 12:39:33 <Cogitri> Well, either add what you've mentioned to the LDFLAGS or add -fno-stack-protector as other packages such as rust do
2020-02-08 12:41:45 <_ikke_> right, the main issue for me was finding out where to even supply that :)
2020-02-08 12:41:54 <_ikke_> I'm not too familiar with rust / cargo
2020-02-08 12:42:10 <_ikke_> well, FDFLAGS is just environment ofcourse
2020-02-08 12:42:15 <_ikke_> LDFLAGS*
2020-02-08 12:44:19 <Cogitri> LDFLAGS is the right place :)
2020-02-08 12:52:10 <mps> how to 'interpret' in SPDX this license https://git.kernel.dk/cgit/liburing/tree/LICENSE
2020-02-08 12:54:12 <mps> (we need to be a lawyers also)
2020-02-08 13:18:50 <fabled> Cogitri, we should instead patch rust to add libssp_nonshared.a (-lssp_nonshared) to linker
2020-02-08 13:19:05 <fabled> _ikke_, ^
2020-02-08 13:20:21 <_ikke_> fabled: sounds good
2020-02-08 13:21:29 <fabled> see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509 and https://www.openwall.com/lists/musl/2020/01/30/2
2020-02-08 14:16:40 <kaey> mps: looks like ISC
2020-02-08 14:19:02 <kaey> MIT actually https://opensource.org/licenses/MIT
2020-02-08 14:40:52 <mps> kaey: sorry, was afk
2020-02-08 14:42:08 <mps> in tree there is LGPL 2.1 Copying file
2020-02-08 14:42:26 <mps> so, made MR with just LGPL
2020-02-08 14:43:11 <mps> here it is !3849
2020-02-08 14:43:26 <mps> hope that will be ok
2020-02-08 14:48:02 <Cogitri> fabled: Sure, that'd be nice, but I can't help with that right now, still sick in bed due to flu I caught at FOSDEM
2020-02-08 14:51:48 <Thermi> fabled: which branch?
2020-02-08 14:53:04 <Thermi> nvm, pulled from gitlab instead of github. Now I got a whole lot of new branches. :)
2020-02-08 15:07:41 <Thermi> fabled: How's the cross compile doing?
2020-02-08 15:07:56 <fabled> Thermi, completed successfully
2020-02-08 15:08:03 <Thermi> In a clean VM?
2020-02-08 15:10:29 <fabled> Thermi, in (mostly) new chroot
2020-02-08 15:10:41 <fabled> _ikke_, wondering if http://sprunge.us/shvrK6 is enough for rust patching
2020-02-08 15:10:52 <Thermi> Okay, I'll double check that then later
2020-02-08 17:14:31 <fabled> _ikke_, Cogitri : pushed rust fix, test built locally, and it also seems to fix broot build issue on x86
2020-02-08 17:15:03 <_ikke_> fabled: thanks!
2020-02-08 17:15:12 <_ikke_> Once it's built, I'll try broot again
2020-02-08 17:34:24 <Cogitri> Neat. If that works you can remove the fno-stack-protector thingie from the LDFLAGS of all the APKBUILDS which use Rust and conditionally enable it on x86.
2020-02-08 17:36:44 <dalias> could you instead just add -lssp_nonshared ??
2020-02-08 17:37:03 <dalias> turning off ssp is not nice
2020-02-08 17:37:14 <fabled> Cogitri, yes, please remove all -fno-stack-protector
2020-02-08 17:37:19 <fabled> we want that
2020-02-08 17:37:31 <fabled> that is - we want to build stuff with stack protector turned on
2020-02-08 17:37:53 <fabled> dalias, just patched rust to add it; but yes, adding that to LDFLAGS should've worked too
2020-02-08 18:09:22 <craftyguy> vim users: what formatting rules do you use for APKBUILDs?
2020-02-08 18:09:53 <_ikke_> noet ai
2020-02-08 18:12:52 <craftyguy> thanks
2020-02-08 18:36:04 <_ikke_> fabled: broot builds now on x86 :)
2020-02-08 18:57:13 <dalias> what is broot?
2020-02-08 18:57:36 <_ikke_> an interactive directory viewer
2020-02-08 19:04:15 <Cogitri> fabled: Will do once I'm healthy again I suppose
2020-02-08 20:49:06 <_ikke_> Cogitri: hope it's not too bad
2020-02-08 21:05:20 <_ikke_> Cogitri: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3854
2020-02-08 21:10:11 <_ikke_> CI is certainly bugged :(
2020-02-08 21:10:52 <[[sroracle]]> "Now you can access the merge request navigation tabs at the top, where they’re easier to find."
2020-02-08 21:10:55 <[[sroracle]]> please leave me alone already
2020-02-09 05:13:17 <north1> How is !4 going ?
2020-02-09 05:31:28 <russkel> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3634
2020-02-09 05:31:32 <russkel> woo finally, two green ticks!
2020-02-09 06:53:31 <north1> Nice
2020-02-09 08:37:23 <Danct12[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3864
2020-02-09 08:50:01 <Cogitri> Why upgrade to an unstable release?
2020-02-09 09:22:40 <Danct12[m]> didn't know it was unstable, just saw it in the gnome ftp
2020-02-09 09:29:50 <north1> Yeah, that is gnome thing
2020-02-09 09:30:54 <mps> always unstable ? ;)
2020-02-09 09:31:24 <north1> No, uneven numbers are unstable, even ones stable
2020-02-09 09:33:16 <mps> I know, but a small morning joke :)
2020-02-09 09:33:49 <mps> north1: btw, thanks for note about liburing
2020-02-09 09:34:36 <mps> newapkbuild, apkbuild-lint and CI lint were quiet
2020-02-09 09:34:51 <north1> They were because they are not in the official document
2020-02-09 09:35:17 <north1> If you set APKBUILD_STYLE envvar to leo it will warn
2020-02-09 09:35:41 <north1> If the alternative document on !4 passes then it will be made default
2020-02-09 09:36:38 <mps> uh, I forgot to comment !4
2020-02-09 12:59:10 <minecrell> CI doesn't really seem to build any packages anymore... "No packages found to be built." in a lot of MRs
2020-02-09 13:15:53 <_ikke_> minecrell: Yes, I'm looking at it
2020-02-09 13:52:59 <PureTryOut[m]> Cogitri: I'm wondering, how do you mass update GNOME when a new release is out? Stuff like changing the `$pkgver`, updating checksums, test build them all in order, etc?
2020-02-09 13:53:22 <PureTryOut[m]> I've been using a shitty shell script for now to do that but want to rewrite and improve it in Python. But before I do, maybe there is something else out there already?
2020-02-09 13:55:56 <Cogitri> I don't really have much of a shell script for that
2020-02-09 13:57:17 <Cogitri> Since GNOME stuff isn't all released at the exact same time (it tries to release everything at one day but usually it's more of a period of 3-7 days until everything catched up) it's not that much of a problem
2020-02-09 13:57:43 <Cogitri> And most stuff doesn't have such strict version requirements that they need a just released thing
2020-02-09 13:58:01 <Cogitri> (Other than a new GLib maybe)
2020-02-09 13:58:33 <Cogitri> So the GNOME release process is pretty relaxed in that sense (and I don't think it's as frequent as KDEs?)
2020-02-09 13:58:36 <PureTryOut[m]> Oh interesting. KDE releases lots of stuff at the same time. E.g. all KDE Frameworks at same time, all KDE Plasma at same time, and all KDE release-service at same time
2020-02-09 13:58:43 <PureTryOut[m]> Guess I'll write my own stuff then
2020-02-09 13:58:57 <Cogitri> Ah yes, seems like KDE does a lot more of splitting for stuff too
2020-02-09 13:58:58 <PureTryOut[m]> Well KDE has different release schedules depending on what the package is
2020-02-09 13:59:06 <Cogitri> Oh
2020-02-09 13:59:21 <PureTryOut[m]> E.g. KDE Frameworks updates every month, KDE Plasma every 2-3 or so months, and KDE release-service every 4 months
2020-02-09 13:59:29 <PureTryOut[m]> Well, bare point releases then
2020-02-09 14:00:07 <Cogitri> Ah, GNOME just makes major releases every ~6 months
2020-02-09 14:00:45 <Cogitri> And point stable releases every 2 weeks for 1-3 times, depending on package's needs
2020-02-09 14:01:24 <Cogitri> So GNOME isn't that bad to upgrade so I didn't really need to pour much effort into some elaborate scripting thingie to automate it
2020-02-09 14:01:38 <Cogitri> I use maxice8's tools like ax though, those are super useful
2020-02-09 14:02:40 <PureTryOut[m]> ax? πŸ€”
2020-02-09 14:04:41 <mps> PureTryOut[m]: https://github.com/maxice8/meltryllis.git
2020-02-09 14:06:24 <mps> bin/ax there
2020-02-09 16:30:49 <_ikke_> minecrell: CI should be working again
2020-02-09 16:30:56 <_ikke_> minecrell: Was my bad
2020-02-09 16:37:08 <minecrell> _ikke_: Indeed, thank you!
2020-02-10 08:05:03 <mps> \o
2020-02-10 08:05:21 <mps> anyone know is Stuart Cardall here
2020-02-10 08:08:51 <_ikke_> I dont think they are on irc
2020-02-10 08:10:28 <mps> can we find if the someone for whom we know name have account on our gitlab
2020-02-10 08:12:05 <mps> I would like to assing #11203 to him
2020-02-10 08:13:11 <_ikke_> @itoffshore
2020-02-10 08:13:22 <clandmeter> yep thats the one
2020-02-10 08:13:26 <mps> thanks
2020-02-10 08:16:32 <mps> hmm, gitlab can't find it when writing this username
2020-02-10 08:17:06 <_ikke_> It does not autocomplete when the user never interacted with the project
2020-02-10 08:18:02 <mps> aha, understand
2020-02-10 08:18:04 <Cogitri> Huh, so apparently kernel.org lists 5.5 as LTS now and not 5.4 ?
2020-02-10 08:18:17 <Cogitri> Ah nevermind I can't read apparently
2020-02-10 08:18:49 <mps> Cogitri: :)
2020-02-10 08:19:12 <mps> hope you are better now
2020-02-10 08:19:33 <Cogitri> Ah yes,thanks :)
2020-02-10 08:20:20 <mps> _ikke_: if I assign issue 'blindly' to @itoffshore will the mail be sent to his email address?
2020-02-10 08:20:58 <_ikke_> I think to be able to assign users they need to be a member of the project
2020-02-10 08:22:16 <mps> ah, ok. what about write username in message/comment in issue report
2020-02-10 08:22:26 <_ikke_> That should work
2020-02-10 08:22:41 <clandmeter> thats the only way atm
2020-02-10 08:22:58 <mps> ok, will try. thanks for help
2020-02-10 08:24:27 <_ikke_> clandmeter: I think we should be able to add more people as reporter to the project
2020-02-10 08:25:01 <mps> ah, interesting to know, typed @itoffshore in msg box and in preview it shows full name
2020-02-10 08:27:08 <clandmeter> we need to setup a list
2020-02-10 08:27:18 <clandmeter> do we want to add more than only commiters?
2020-02-10 08:27:41 <_ikke_> I think as reporters, yes
2020-02-10 08:27:49 <_ikke_> developers should be only committers
2020-02-10 08:27:55 <_ikke_> (when we are ready to do that)
2020-02-10 08:28:17 <clandmeter> i think we can start adding them
2020-02-10 08:28:27 <clandmeter> even if we dont yet allow pushing
2020-02-10 08:28:47 <_ikke_> adding them as developer gives them access to push
2020-02-10 08:29:04 <_ikke_> unless we make all branches protected
2020-02-10 08:30:38 <clandmeter> im ok in branch protecting
2020-02-10 08:31:20 <clandmeter> does it give any issues?
2020-02-10 08:31:41 <_ikke_> Ok, I protected all branches and tags
2020-02-10 08:31:55 <_ikke_> master and stable branches already were protected, so afaik, it won't
2020-02-10 09:31:01 <Danct12[m]> https://lists.alpinelinux.org/~alpine/aports/patches/3268
2020-02-10 09:49:23 <Cogitri> Is that patch upstream?
2020-02-10 09:57:11 <Thermi> The linux-headers package is still outdated
2020-02-10 10:00:22 <Thermi> perl, texinfo, gawk, mpfr-dev, mpc1-dev, zlib-dev BAD signature
2020-02-10 10:22:03 <Thermi> ncopa4: mps fabled ^
2020-02-10 10:22:20 <Thermi> sorry for mass highlight, this might be an indicator of bigger problems
2020-02-10 10:23:07 <Thermi> community repo contents file also has a bad sig
2020-02-10 10:23:32 <Thermi> some main repo contents (APKINDEX), too
2020-02-10 10:29:23 <clandmeter> which mirror which files?
2020-02-10 10:29:29 <Danct12[m]> <Cogitri "Is that patch upstream?"> it's a workaround for mozjs60 crashing
2020-02-10 10:29:31 <Danct12[m]> > <@freenode_Cogitri:matrix.org> Is that patch upstream?
2020-02-10 10:29:31 <Danct12[m]>  * it's a workaround for mozjs60 crashing on gnome
2020-02-10 10:29:34 <Danct12[m]> until mozjs60 gets fixed, regex will still be broken
2020-02-10 10:30:28 <PureTryOut[m]> Danct12: try to not use non-IRC features like replies here. They are  converted quite ugly/badly and this is a majority IRC channel
2020-02-10 10:30:50 <Danct12[m]> alright
2020-02-10 10:31:08 <Danct12[m]> cogitri: ^ yeah, that's basically what it does
2020-02-10 10:33:32 <Thermi> clandmeter: APKINDEX of http://mirror1.hs-esslingen.de/pub/Mirrors/alpine/v3.11/community http://mirror.leaseweb.com/alpine/v3.11/main: http://ftp.halifax.rwth-aachen.de/alpine/v3.11/community: http://dl-cdn.alpinelinux.org/alpine/v3.11/community: http://mirrors.ircam.fr/pub/alpine/v3.11/main: http://mirror.yandex.ru/mirrors/alpine/v3.11/main:
2020-02-10 10:33:54 <Thermi> http://dl-8.alpinelinux.org/alpine/v3.11/community: too
2020-02-10 10:33:57 <clandmeter> Thermi: can you try our official mirror dl-cdn?
2020-02-10 10:33:57 <PureTryOut[m]> But his question was if the patch was upstream πŸ˜‰
2020-02-10 10:34:10 <Thermi> perl-5.30.1-r0: bad sig
2020-02-10 10:34:50 <Thermi> so is git-perl-2.24.1-r0:
2020-02-10 10:36:42 <clandmeter> Thermi: git-perl on 3.11 has issues?
2020-02-10 10:38:01 <clandmeter> Thermi: like this? http://tpaste.us/b4qX
2020-02-10 10:52:19 <Thermi> clandmeter: please repaste on other site, can't access tpase
2020-02-10 10:52:20 <Thermi> *tpase
2020-02-10 10:52:57 <_ikke_> Thermi: strange, why not?
2020-02-10 10:53:09 <clandmeter> http://dpaste.com/3BHKMAT.txt
2020-02-10 10:53:15 <clandmeter> i think its ipv6 issue
2020-02-10 10:53:21 <_ikke_> yeah, was thinking the same
2020-02-10 10:53:33 <clandmeter> i need to remove or udpate the aaa record
2020-02-10 10:54:55 <_ikke_> yeah, ipv6 address apparently does not work
2020-02-10 10:55:17 <Cogitri> Danct12: Please include that in the commit message and the patch header then, without any reasoning it's really more of a guessing game if we need that
2020-02-10 10:55:28 <Cogitri> But great that you've been able to figure that out
2020-02-10 10:57:48 <Danct12[m]> Cogitri: this isn't my patch, it's MartijnBraam 's
2020-02-10 10:57:59 <Danct12[m]> just asking you to check it out though
2020-02-10 10:58:56 <Cogitri> Ah right
2020-02-10 10:59:21 <Cogitri> Well, I'd ask to put it on the Gitlab then since I don't use the ML for patches, sorry about that
2020-02-10 10:59:35 <Thermi> _ikke_: Yes, IPv6 issue and I have a proxy in between. :)
2020-02-10 11:01:11 <MartijnBraam> Eh what, the ml is not for patches?
2020-02-10 11:01:46 <Cogitri> Well, you're certainly free to use it, but only Maxice8 looks at it from time to time and _ikke_ sometimes, Gitlab is where the main action is
2020-02-10 11:01:51 <Cogitri> ML doesn't have CI and reviewing on it sucks IMHO so I only look at Gitlab these days
2020-02-10 11:02:08 <Cogitri> I see the use of the ML for discussion but it's such a massive pain for patches
2020-02-10 11:03:27 <Cogitri> Frankly, I'd be on favour of just plain out shutting down ~alpine/aports, it's really a shame how many contributions we let rot over there in the name of allowing people to contribute the way they want to
2020-02-10 11:04:01 <Cogitri> When we clearly can't handle it
2020-02-10 11:05:43 <Cogitri> Heh, maybe that'd be a topic for the ML :P
2020-02-10 11:06:04 <Thermi> (4/10) Installing perl (5.30.1-r0)
2020-02-10 11:06:04 <Thermi> ERROR: perl-5.30.1-r0: BAD signature
2020-02-10 11:06:13 <Thermi> clandmeter: ^
2020-02-10 11:07:10 <Cogitri> Anyway, maybe someone else will merge it on the ML, I can take a look if you put it on Gitlab. I'd recommend you add reasoning to your patch though (just mention that this avoids crashes in polkitd/mozjs60)
2020-02-10 11:07:12 <clandmeter> Thermi: which file is that?
2020-02-10 11:07:20 <Cogitri> MartijnBraam: ^
2020-02-10 11:07:25 <clandmeter> we have multiple mirrors branches arches
2020-02-10 11:07:46 <clandmeter> Thermi: did you see my dpaste above?
2020-02-10 11:08:00 <clandmeter> what is in your repositories file?
2020-02-10 11:09:22 <Thermi> clandmeter: Yes I did. Trying the CDN now
2020-02-10 11:09:27 <Thermi> CDN the same problem
2020-02-10 11:09:36 <clandmeter> pastebin your repo file
2020-02-10 11:09:46 <MartijnBraam> clandmeter: it's the polkit policy for modem manager
2020-02-10 11:10:45 <clandmeter> MartijnBraam: ?
2020-02-10 11:10:59 <clandmeter> Thermi: pastebin your repo file
2020-02-10 11:11:09 <MartijnBraam> clandmeter: sorry wrong discussion
2020-02-10 11:12:10 <Thermi> clandmeter: https://bpaste.net/2VMA
2020-02-10 11:18:11 <Thermi> clandmeter: Thoughts?
2020-02-10 11:35:33 <clandmeter> Thermi: thats your /etc/apk/repositories file?
2020-02-10 11:46:40 <mps> Thermi: linux-headers are 5.4.5, so not outdated
2020-02-10 11:47:22 <mps> do you work on 3.11 or edge
2020-02-10 11:49:56 <mps> Thermi: for 3.11 release linux-headers are 4.19.xx and it should be used on 3.11
2020-02-10 12:05:57 <Thermi> mps: headers need to match the kernel version, not be newer or older. I checked aports master and it's older than the kernel version
2020-02-10 12:06:00 <Thermi> clandmeter: yes
2020-02-10 12:06:40 <Thermi> mps: I want to work on 3.11, but am willing to backport things here and there to get a well working system
2020-02-10 12:07:41 <clandmeter> Thermi: kill all lines and only keep the first 2
2020-02-10 12:07:43 <clandmeter> dl-cdn
2020-02-10 12:08:39 <Thermi> clandmeter: and then?
2020-02-10 12:08:40 <Thermi> ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.11/main: BAD signature
2020-02-10 12:08:44 <Thermi> Still get that^
2020-02-10 12:08:53 <clandmeter> did you run apk update first?
2020-02-10 12:09:06 <Thermi> alpine-linux:/etc/apk/keys# ls
2020-02-10 12:09:06 <Thermi> alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub  alpine-devel@lists.alpinelinux.org-5261cecb.rsa.pub
2020-02-10 12:09:07 <Thermi> alpine-devel@lists.alpinelinux.org-5243ef4b.rsa.pub  buildozer-5e3c0259.rsa.pub
2020-02-10 12:09:16 <Thermi> Yes, that's what I did to get thaz error
2020-02-10 12:10:11 <clandmeter> Thermi: https://pkgs.alpinelinux.org/contents?branch=v3.11&name=alpine-keys&arch=x86_64&repo=main
2020-02-10 12:11:16 <Thermi> https://bpaste.net/XFGA
2020-02-10 12:13:14 <mps> Thermi: all userspace for 3.11 are built with linux-headers 4.19.xx (forgot exact minor version) and becasue of this it will not be good idea to backport linux-headers 5.4.5 to 3.11
2020-02-10 12:14:07 <Thermi> mps: Why? kernel version is 5.4.12 already, so they don't match already anyway
2020-02-10 12:14:53 <mps> userspace pkgs are built ussing old kernel headers
2020-02-10 12:15:21 <mps> that is the reason
2020-02-10 12:16:04 <clandmeter> Thermi: is there something special in your setup?
2020-02-10 12:16:15 <clandmeter> what does apk --print-arch say?
2020-02-10 12:16:58 <Thermi> x86_64
2020-02-10 12:22:43 <clandmeter> Thermi: are you sure the alpine-keys are all intact?
2020-02-10 12:22:48 <clandmeter> network is working correctly?
2020-02-10 12:23:02 <Thermi> network is obv. working correctly, the problem is 100% reproducible for the same files and mirrors
2020-02-10 12:23:08 <clandmeter> what if you first download the package local and try to install from disk?
2020-02-10 12:23:09 <Thermi> I already reinstalled alpine-keys twice
2020-02-10 12:23:31 <clandmeter> how did you reinstall alpine-keys?
2020-02-10 12:24:15 <clandmeter> as I show you, here in docker it works fine.
2020-02-10 12:24:47 <Thermi> apk fix alpine-keys
2020-02-10 12:24:53 <Thermi> https://bpaste.net/WLOA
2020-02-10 12:24:57 <Thermi> The plot thickens
2020-02-10 12:25:51 <Thermi> https://bpaste.net/NEOA
2020-02-10 12:25:53 <Thermi> virtualbox
2020-02-10 12:25:56 <Thermi> t f are you doing
2020-02-10 12:26:01 <Thermi> this runs in virtualbox
2020-02-10 12:36:51 <Thermi> oh OH NO
2020-02-10 12:37:24 <Thermi> There's a HTTP proxy inbetween
2020-02-10 12:39:29 <Thermi> Same problem without the proxy
2020-02-10 12:45:55 <Thermi> https://bpaste.net/6DTA
2020-02-10 12:46:08 <Thermi> clandmeter: ^ that's in a completely new docker container
2020-02-10 12:46:19 <Thermi> So there's definitely something broken with the CDN
2020-02-10 12:47:56 <clandmeter> Thermi: sounds more like you have network issues
2020-02-10 12:48:07 <Thermi> It works fine in the browser
2020-02-10 12:48:15 <Thermi> likely IPv6 <=> IPv4
2020-02-10 12:48:30 <Thermi> Through an IPsec tunnel, too
2020-02-10 12:52:22 <Thermi> If this was a network issue, it would have been caught by the TCP checksums first
2020-02-10 12:53:12 <Thermi> It'd be extremely unlikely that repeatedly a combination of bit errors would occur for the same files over different networks for the same servers with different drivers and through TLS, too
2020-02-10 12:53:28 <Thermi> using HTTPS gives me BAD archive for the same files
2020-02-10 13:01:09 <Thermi> Manually downloaded files check out fine with `apk verify`
2020-02-10 13:04:44 <Thermi> Anyway, you have been informed.
2020-02-10 13:14:22 <Thermi> test
2020-02-10 13:14:39 <Thermi> I figured out that there is some problem with the NIC on this laptop
2020-02-10 13:14:51 <Thermi> It was only inermittent though and very specific to the workload
2020-02-10 13:24:00 <Cogitri> Huh :)
2020-02-10 13:24:23 <Thermi> WLAN works fine
2020-02-10 13:24:43 <Thermi> It might also be some other problem with the cable or the switch, but that's not checked yet
2020-02-10 13:29:56 <Thermi> fabled: with default bootstrap.sh, I get errors when cleaning up srcdir that some dirs weren't empty
2020-02-10 13:46:08 <Danct12[m]> can these get merged?
2020-02-10 13:46:09 <Danct12[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3881
2020-02-10 13:46:20 <Danct12[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3866
2020-02-10 13:46:34 <north1> not yet for the first one
2020-02-10 13:46:59 <Danct12[m]> what's wrong with it now?
2020-02-10 13:47:08 <north1> CI isn't done
2020-02-10 13:47:40 <Danct12[m]> oh right
2020-02-10 13:49:22 <PureTryOut[m]> Danct12: upgrade commit should be named with "upgrade", not "update"
2020-02-10 13:50:38 <Danct12[m]> ok
2020-02-10 13:52:47 <Thermi> There's something wrong with rm and docker volumes. It fails to properly recursively delete directories if they are in a volume
2020-02-10 13:53:13 <Thermi> first it complains that some dirs weren't empty and the second pass (second invocation of rm --rf manually) succeeds in deleting it
2020-02-10 13:53:29 <Thermi> Take a look: https://bpaste.net/AVEA
2020-02-10 13:56:38 <Thermi> fabled 3.11-stable branch openssl fails to build with https://bpaste.net/FYCA
2020-02-10 13:59:49 <Thermi> This is really weird, the second invocation works
2020-02-10 14:00:11 <Thermi> I had the file open in an editor though during the second invocation
2020-02-10 14:06:26 <Thermi> This is all so bizarre
2020-02-10 14:06:46 <Thermi> Almost like the past part of this year
2020-02-10 14:09:49 <Danct12[m]> north1: both of them are done
2020-02-10 14:11:32 <north1> Gonna drive a bit
2020-02-10 14:15:26 <PureTryOut[m]> Anyone here have experience with LibreOffice? I'm trying to enable the KDE/Qt UI and although I got it working locally, I don't see any difference in files and don't know what to split out of the base package.
2020-02-10 14:19:48 <[[sroracle]]> PureTryOut[m]:Β i do but i haven't tried enabling qt5 vclplug in some time
2020-02-10 14:20:07 <[[sroracle]]> last time i tried the configure option wasn't even available :p
2020-02-10 14:21:08 <PureTryOut[m]> Well it is now lol.
2020-02-10 14:21:15 <PureTryOut[m]> I do see some Qt5 related files for LO on my Gentoo installation, but they're just not there on Alpine for some reason
2020-02-10 14:21:37 <[[sroracle]]> double check your configure log maybe
2020-02-10 14:21:53 <[[sroracle]]> if you want you can paste it here
2020-02-10 14:24:46 <PureTryOut[m]> Hmm? I mean, I know it worked, as I now have a Qt5 themed LibreOffice lol
2020-02-10 14:25:31 <[[sroracle]]> still it's helpful to look at
2020-02-10 14:26:14 <Cogitri> Tried the same thing a while ago but I also didn't see a way to split that off
2020-02-10 14:30:48 <PureTryOut[m]> Cogitri: weird thing is that on Gentoo I do have some Qt specific files. But they just don't exist when I enable it on Alpine for some reason
2020-02-10 14:30:59 <PureTryOut[m]> I guess I'll open a MR and we can discuss in more detail there
2020-02-10 14:33:44 <PureTryOut[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3885/diffs
2020-02-10 14:33:46 <PureTryOut[m]> [[sroracle]]: ^
2020-02-10 15:10:28 <dalias> https://git.alpinelinux.org/aports/tree/community/openjdk11/x86.patch looks sketchy
2020-02-10 15:10:57 <dalias> if jre is setting x87 control word precision control to nondefault values it's probably breaking ability to call libc functions (unless it switches it back to do so)
2020-02-10 15:11:20 <[[sroracle]]> PureTryOut[m]:Β is there no file in file-lists/ for the vclplug?
2020-02-10 15:11:23 <[[sroracle]]> it may have some weird name
2020-02-10 15:11:35 <[[sroracle]]> other than that i'm not sure
2020-02-10 15:11:47 <[[sroracle]]> perhaps because of all the vclplugs enabled it mashes things together in a weird way
2020-02-10 15:15:39 <PureTryOut[m]> Well the GTK related vclplugs are still there.
2020-02-10 15:15:59 <PureTryOut[m]> The file-lists thing is compiled at build time right? I haven't really found that directory somewhere
2020-02-10 15:28:38 <[[sroracle]]> afaik yes
2020-02-10 15:35:11 <afontain_> do we have a /etc/network/interfaces.d or equivalent?
2020-02-10 15:51:01 <PureTryOut[m]> [[sroracle]]: so I guess I have to make abuild compile the whole thing, but make it fail in packaging state or something to be able to see the file-lists directory without abuild having wiped it before?
2020-02-10 15:54:43 <north1> You can use apk fetch | tar -t to see the file list
2020-02-10 15:55:22 <north1> i do stuff like that with this http://ix.io/2bkc
2020-02-10 15:55:59 <clandmeter> --stdout is needed i think
2020-02-10 16:03:15 <[[sroracle]]> no this is an actual file in the builddir, not the final file list
2020-02-10 16:03:37 <[[sroracle]]> but yes PureTryOut[m] that's what i would do if you're trying to do it all through gitlab CI
2020-02-10 16:04:09 <[[sroracle]]> otherwise you could just stop after abuild build/rootpkg (i forget when file-lists is generated, it might actually be during package())
2020-02-10 16:05:31 <_ikke_> PureTryOut[m]: abuild has an option -K to not delete everything
2020-02-10 16:05:40 <_ikke_> abuild -rK
2020-02-10 16:07:23 <PureTryOut[m]> ah cool thanks
2020-02-10 16:08:18 <PureTryOut[m]> north1: you don't understand, in this case file-lists is a folder generated by the LibreOffice build system. I don't need to see the files within an Alpine package, I would just use https://pkgs.alpinelinux.org for that πŸ˜‰
2020-02-10 17:32:10 <craftyguy> Cogitri: thanks for reviewing my openmw MR for aports repo, and sorry you had to repeat a lot of the same feedback. I haven't made many APKBUILDs (or in this case, largely ported from Arch's PKGBUILD, which I've now learned it probably not worth the effort without being very familiar with the APKBUILD nuances you pointed out in the review)
2020-02-10 18:09:08 <craftyguy> Cogitri: I am confused about something though. your comments seem to suggest that setting builddir would result in the automatic creation of some directory that doesn't exist (but this doesn't seem to be the case)
2020-02-10 18:10:33 <craftyguy> e.g. with building something that uses cmake, there's generally a sub directory (e.g. 'build') that doesn't exist in the source that is created at build time, then cd'd into. setting builddir=<source>/build errors out because there is no 'build'. I have to explicitly 'mkdir $srcdir/build' in the APKBUILD
2020-02-10 18:18:39 <_ikke_> craftyguy: if you run abuild -r, the srcdir is removed before it's created again
2020-02-10 18:18:51 <_ikke_> so you always start with a clean slate
2020-02-10 18:19:34 <_ikke_> by doing it this way, you make it harder to debug building the package (by forcing a complete rebuild every time)
2020-02-10 18:19:57 <craftyguy> _ikke_: I don't think that's my problem
2020-02-10 18:20:29 <_ikke_> I was going off on what I saw on the MR
2020-02-10 18:20:39 <_ikke_> I looked at the wrong comment
2020-02-10 18:21:40 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n691
2020-02-10 18:22:05 <craftyguy> the problem is I pretty much have to 'mkdir build && cd build' in build() before running cmake, if I set the builddir to $srcdir/<package>-<ver>/build (which doesn't exist in the source..) and expect it to be there in build(), it doesn't work
2020-02-10 18:22:53 <craftyguy> I have no idea why this isn't working then
2020-02-10 18:23:07 <_ikke_> Do it in prepare()
2020-02-10 18:24:31 <craftyguy> so I *do* need to explicitly mkdir
2020-02-10 18:24:35 <craftyguy> just in prepare
2020-02-10 18:24:36 <_ikke_> yes, indeed
2020-02-10 18:24:40 <_ikke_> for build, that is
2020-02-10 18:24:50 <craftyguy> ok I see, thanks!
2020-02-10 18:24:53 <_ikke_> ie, you want "$srcdir/.../build" to exist
2020-02-10 18:25:36 <_ikke_> but the cd is not necessary
2020-02-10 18:25:40 <craftyguy> yeah, exactly
2020-02-10 18:25:47 <craftyguy> thanks for the help :)
2020-02-10 18:27:14 <_ikke_> no problem
2020-02-10 18:27:17 <clandmeter> i think builddir is mostly _not_ set to ./build?
2020-02-10 18:27:25 <_ikke_> yea
2020-02-10 18:27:43 <clandmeter> build exists inside $builddir
2020-02-10 18:28:35 <_ikke_> Love how the review comments get terser and terser :P
2020-02-10 18:30:33 <craftyguy> heh. yeah, probably could have spent less time if they had just assumed I had at least half a brain and would apply previous comments to other APKBUILDs in the MR :D
2020-02-10 18:31:09 <_ikke_> Some people just fix the comments
2020-02-10 18:31:16 <_ikke_> so if you would not comment, they would not fix it
2020-02-10 18:31:24 <craftyguy> but hey there's a special kind of excitement over receiving ~15 gitlab notifications for 1 MR
2020-02-10 18:31:30 <_ikke_> haha :)
2020-02-10 18:31:47 <craftyguy> "omg what have I done?!"
2020-02-10 18:35:48 <kmaxwell> does anyone have any suggestions about my beancount MR please? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3745
2020-02-10 18:36:13 <kmaxwell> it did get one review comment, but I'd say it was terse too :-)
2020-02-10 18:39:05 <_ikke_> That's why it's a pitty that solutions like gitlab/github hide commits in merge requests
2020-02-10 18:39:16 <_ikke_> no one tends to read / look at commits anymore
2020-02-10 18:40:47 <_ikke_> looks like the author added some helper code to the normal codebase
2020-02-10 18:42:02 <kmaxwell> _ikke_: I agree that it a disadvantage of MR / PR workflows
2020-02-10 18:42:19 <kmaxwell> I am a big fan of commit messages to give context
2020-02-10 18:42:25 <_ikke_> Me too
2020-02-10 18:42:27 <_ikke_> https://gitlab.com/gitlab-org/gitlab-foss/issues/32313
2020-02-10 18:42:35 <kmaxwell> possibly it was even you linked a good article on the point recently
2020-02-10 18:43:14 <_ikke_> maybe, don't recall it
2020-02-10 18:44:32 <kmaxwell> that's awesome! I've seen the prev / next buttons in the github UI, but never used them
2020-02-10 18:44:58 <kmaxwell> will definitely in future
2020-02-10 18:47:50 <kmaxwell> This commit message article is an old one but made me think again - https://chris.beams.io/posts/git-commit/
2020-02-10 19:00:11 <craftyguy> what's the recommended way to run tests in a APKBUILD when upstream provides a script to execute tests but has targeted bash?
2020-02-10 19:00:55 <Cogitri> Run that script and add bash to the checkdepends
2020-02-10 19:00:57 <_ikke_> craftyguy: you can add bash to checkdepends
2020-02-10 19:01:24 <craftyguy> ok, that was what I was thinking but just wanted to double check
2020-02-10 19:34:36 <craftyguy> what about tests that go and download a bunch of random stuff from some dropbox thing?
2020-02-10 19:35:40 <craftyguy> https://github.com/twogood/unshield/blob/master/test/v0/baldurs_gate_patch_v1_1_4315_international.sh#L16
2020-02-10 19:38:48 <Danct12[m]> can we have https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3881 merged?
2020-02-10 19:51:22 <zfoo_> I get the following error when running 'cd /aports/main/xz && abuild -r': ERROR: Unable to lock database: Bad file descriptor
2020-02-10 19:52:02 <zfoo_> this is from a new alpine chroot
2020-02-10 20:36:06 <Cogitri> Danct12: Merged.
2020-02-10 20:36:47 <Cogitri> I guess #11207 can be closed then?
2020-02-10 21:31:12 <Cogitri> Could someone with main/ access give !3891 a tow maybe? That'd unbreak ZFS on edge :)
2020-02-10 21:46:44 <craftyguy> I saw the note in the wiki for APKBUILD check() that mentions using xvfb-run for tests that require X.. but what about tests that require glx?
2020-02-10 21:47:07 <craftyguy> e.g. glxinfo doesn't work with xvfb-run
2020-02-10 21:47:18 <_ikke_> Don't think that will work
2020-02-10 21:47:27 <craftyguy> (the tests I'm trying to run are not glxinfo, but that's an easy way to reproduce the issue)
2020-02-10 21:47:46 <craftyguy> ok yeah, didn't think so. what's the recommendation in this case?
2020-02-10 21:47:57 <_ikke_> at some point there is a limit to what we can test on the builders
2020-02-10 21:48:14 <craftyguy> the wiki is very strongly worded towards "fix the test, or make new tests" :/
2020-02-10 21:48:34 <mps> I usually make patch to skip test which can't be run
2020-02-10 21:48:54 <craftyguy> I in this case, it's all of them. the package is a GUI framework that uses opengl
2020-02-10 21:48:56 <_ikke_> craftyguy: afaik, we don't advise to build new tests ourselves
2020-02-10 21:49:52 <craftyguy> I was perhaps reading too deeply into this statement: "If a unit test is known not to work, you may need to patch it to omit that test or fix it;"
2020-02-10 21:50:09 <_ikke_> patch it to omit it
2020-02-10 21:50:15 <_ikke_> like mps was saying
2020-02-10 21:50:37 <craftyguy> _ikke_: in this case, it would result in no tests running, since they all require glx
2020-02-10 21:50:50 <_ikke_> craftyguy: yeah, not much to do about it
2020-02-10 21:50:57 <craftyguy> so I can 'options="!check"' with a comment about why ("need glx")
2020-02-10 21:51:01 <_ikke_> yes
2020-02-10 21:51:09 <craftyguy> ok great. just wanted to make sure that was acceptable
2020-02-10 21:51:28 <_ikke_> We don't expect the impossible :)
2020-02-10 21:51:48 <craftyguy> :)
2020-02-10 21:52:04 <_ikke_> PureTryOut[m]: knotifition seems to fail due to missing dependency
2020-02-10 21:52:14 <_ikke_> (version)
2020-02-10 21:52:20 <PureTryOut[m]> I know
2020-02-10 21:52:22 <_ikke_> Could not find a package configuration file provided by "KF5WindowSystem" (requested version 5.67.0) with any of the following names:
2020-02-10 21:52:24 <PureTryOut[m]> doesn't make sense though
2020-02-10 21:52:24 <_ikke_> ok
2020-02-10 21:52:30 <PureTryOut[m]> It got ported away form that dep
2020-02-10 21:52:36 <PureTryOut[m]> And I tested it, ran through CI fine at first
2020-02-10 21:56:03 <PureTryOut[m]> Well, guess I'll just re-add it anyway
2020-02-10 21:56:11 <PureTryOut[m]> _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3892
2020-02-10 21:57:23 <_ikke_> (y)
2020-02-10 21:57:50 <_ikke_> https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/47697#L292
2020-02-10 21:58:17 <PureTryOut[m]> Well yes of course
2020-02-10 21:58:31 <PureTryOut[m]> That's cause the 5.67 packages are stuck on the builders still
2020-02-10 21:58:45 <_ikke_> circular depend
2020-02-10 21:58:46 <_ikke_> ok
2020-02-10 21:59:20 <PureTryOut[m]> Not circular, it would be fine if the dep was there first time
2020-02-10 21:59:24 <_ikke_> yeah
2020-02-10 22:00:12 <PureTryOut[m]> The builders need it to go through
2020-02-10 22:00:26 <PureTryOut[m]> I don't understand why the MR got merged though if CI were still failing
2020-02-10 22:00:33 <PureTryOut[m]> Then what is the point of the CI?
2020-02-10 22:00:40 <_ikke_> PureTryOut[m]: beats me :)
2020-02-10 22:12:14 <PureTryOut[m]> Guess I need to read investigate more after reading changelogs. Yes knotifications got ported away from kwindowsystem, but only on Android lol
2020-02-10 22:12:46 <_ikke_> oh, haha
2020-02-10 22:27:42 <_ikke_> bluez-qt is now failing
2020-02-10 22:28:47 <_ikke_> /home/buildozer/aports/community/bluez-qt/src/bluez-qt-5.67.0/build/autotests/bluezadapter1_tst.cpp:18:1: error: 'OrgBluezAdapter1Interface' does not name a type
2020-02-10 22:51:52 <Ariadne> i would like to enable eBPF in alpine 3.12 for root only. (users who want to expose themselves to unprivileged users using eBPF could remove the sysctl.conf setitng)
2020-02-10 23:43:32 <craftyguy> Cogitri: if what you say here is true, then what's the point of even having a 'depends' if apk will automagically resolve linked libs to packages it needs to install? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3845?diff_id=6747#note_67075
2020-02-10 23:43:51 <craftyguy> s/apk/abuild/
2020-02-10 23:43:51 <alpine-meetbot> craftyguy meant to say: Cogitri: if what you say here is true, then what's the point of even having a 'depends' if abuild will automagically resolve linked libs to packages it needs to install? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3845?diff_id=6747#note_67075
2020-02-10 23:46:52 <craftyguy> I also don't see the harm in explicitly listing out dependencies I know the package needs :(
2020-02-10 23:47:04 <craftyguy> is there a reason why I wouldn't want to do that?
2020-02-10 23:48:01 <mps> craftyguy: mostly not needed, because abuild scans for deps
2020-02-10 23:50:06 <mps> that is for binary pkgs, scanelf does hard work
2020-02-10 23:51:08 <mps> Ariadne: looks like it is inevitable (eBPF) but still I'm not excited about it
2020-02-10 23:58:32 <craftyguy> mps: I see, thanks
2020-02-10 23:58:44 <craftyguy> 
ACTION trying now to see if things still work :P

2020-02-11 00:06:55 <craftyguy> ok I have to admit, that auto dep thing is really nice
2020-02-11 02:12:32 <Danct12[m]> Cogitri: #11207 should be changed to "regex causes polkitd to segfault"
2020-02-11 02:12:33 <Danct12[m]> Since the actual issue is not fixed yet
2020-02-11 02:13:17 <Danct12[m]> But yes, wifi and brightness slider is fixed
2020-02-11 02:22:53 <dalias> ...
2020-02-11 02:23:15 <dalias> alpine should really have a way to rip polkit out from stuff that wants it
2020-02-11 07:14:23 <Cogitri> dalias: I much rather have Polkit than setuid
2020-02-11 07:14:46 <Cogitri> And I very much oppose downstream patches for such massive changes
2020-02-11 09:40:03 <Ariadne> craftyguy: abuild uses sonames for the deps, which result in more portable packages
2020-02-11 09:41:02 <_ikke_> And to add to that, the depends field is for other run-time dependencies that cannot be discovered that way
2020-02-11 09:41:07 <Ariadne> mps: well unfortunately the vrf support in iproute2 requires it
2020-02-11 09:41:40 <Ariadne> and I think vrf is a huge security and usability win for alpine
2020-02-11 09:42:00 <Ariadne> because you can do things like isolate your management network entirely
2020-02-11 09:42:08 <Ariadne> without the complexity of netns or containers
2020-02-11 09:42:49 <Ariadne> so I think allowing root (and only root) to use eBPF is worth it
2020-02-11 09:43:05 <_ikke_> Yes, vrfs are nice
2020-02-11 09:43:07 <Ariadne> if you're root, you already won the security situation
2020-02-11 09:43:31 <_ikke_> And I think requiring root for ebpf does not give you additional access
2020-02-11 09:43:42 <Ariadne> precisely.
2020-02-11 09:43:58 <Ariadne> and if you want to take the risk you can edit sysctl
2020-02-11 09:44:41 <Ariadne> I think the first step is to set the disable sysctl to 1 by default with a warning
2020-02-11 09:44:48 <Ariadne> then we introduce into kernel
2020-02-11 09:44:53 <Ariadne> will write a mail about it
2020-02-11 09:46:02 <_ikke_> I would even go so far that when root is a requirement, ebpf can be even safer than anything you try to build into a kernel module
2020-02-11 09:53:16 <craftyguy> lesson learned.
2020-02-11 09:54:13 <craftyguy> even the APKBUILD reference wiki page says SO deps are auto detected. I missed it :(
2020-02-11 09:56:33 <Cogitri> Well, no worries :)
2020-02-11 09:59:07 <Ariadne> it would be nice to write additional auto detectors btw
2020-02-11 09:59:11 <Ariadne> python modules, for example
2020-02-11 10:00:13 <north1> I did some work in the past for python modules in the same way of so: providers/depends but it has flaws that can't really be fixed as far as i understand
2020-02-11 10:01:05 <Ariadne> well, i mean, RPM has autodetection
2020-02-11 10:01:10 <north1> i know
2020-02-11 10:01:12 <Ariadne> maybe we can see what they do
2020-02-11 10:01:20 <north1> https://github.com/alpinelinux/abuild/pull/103
2020-02-11 10:02:02 <AinNero> Ariadne: eBPF is just some changes in kconfig?
2020-02-11 10:02:05 <AinNero> is there an MR?
2020-02-11 10:03:45 <markand> auto deps are convenient for the package writer but they also hide implementation details
2020-02-11 10:03:59 <north1> It is pretty easy to get the runtime dependencies of the python package, just look at the .egg directory. Problem to solve is adding them to depends=""
2020-02-11 10:04:18 <markand> adding too much auto detectors could lead to unpredictible packages deps, at a glance, you won't see what are the dependencies behind
2020-02-11 10:04:34 <markand> especially since some deps may be optional
2020-02-11 10:04:36 <kmaxwell> norht1: that's cool, I hadn't seen that PR
2020-02-11 10:04:46 <north1> what you mean ?
2020-02-11 10:05:01 <Ariadne> AinNero: i will take care of it later in the week.
2020-02-11 10:05:17 <north1> if you're doing it for python then the deps are generated by parsing setup.py files that produces .egg directories with a requires.txt file with one dep per-line.
2020-02-11 10:07:08 <mps> Ariadne: I wrote it is inevitable but I have fear we are opening door for unpredictable (corporate beasts already waits to push binary blobs through this 'door')
2020-02-11 10:07:42 <Ariadne> corporate beasts already push binary blobs into the kernel
2020-02-11 10:08:05 <mps> and, fact is that I made first patches for linux-lts.armv7 with bpf enabled, which ncopa merged
2020-02-11 10:09:13 <mps> so I understand pros and cons, I hope at least
2020-02-11 10:12:15 <mps> hm, no, I wasn't first, sorry, didn't looked carefully
2020-02-11 10:12:57 <Ariadne> north1: provides="py3:modulename" ?
2020-02-11 10:13:48 <Ariadne> mps: yes, well, i think being able to isolate services to specific VRFs is worth it
2020-02-11 10:14:02 <north1> @Adriane that is done automatically like with so: providers
2020-02-11 10:14:44 <north1> the problem is that in so: providers/depends packages you add the -dev packages into makedepends=, but in python packages you add what the package requires in depends="" already.
2020-02-11 10:14:47 <Ariadne> north1: yes, that is the idea.  and then you use the .egg dependencies to depend on those py3: depends
2020-02-11 10:15:17 <Ariadne> ah
2020-02-11 10:15:24 <Ariadne> well
2020-02-11 10:15:38 <mps> Ariadne: ofc
2020-02-11 10:15:44 <Ariadne> we could just deprecate that practice as we did when so: dependencies were introduced
2020-02-11 10:19:19 <north1> @Adriane then we will just have to list them in checkdepends="" to have the testsuite works, and if we are putting them there might as well put them in depends=""
2020-02-11 10:19:43 <north1> which is why i think we need a separate small applet that checks an .egg and writes the depends="" to the APKBUILD
2020-02-11 10:32:43 <Ariadne> of course, openrc people are useless as always
2020-02-11 10:38:01 <AinNero> should we enable overlayfs for the modloop per default?
2020-02-11 10:38:16 <AinNero> right now it doesnt seem like its configurable from the kernel command line
2020-02-11 12:07:52 <dalias> cogitri, i'd rather have neither. i think a stub replacement that just does nothing would work
2020-02-11 12:16:03 <dalias> part of being a security oriented distro is having no gratuitous suids (or equivalents)
2020-02-11 12:16:26 <dalias> at least having their presence be opt-in
2020-02-11 12:20:03 <mps> hm, am I out of news, someone wants polkit installed by default?
2020-02-11 12:28:52 <Cogitri> I kind of like a functional system, yes
2020-02-11 12:29:49 <Cogitri> And you can avoid Polkit if you want to - that'll mean a pretty stripped down environment for you though, I suppose
2020-02-11 12:30:11 <AinNero> is this for unauthorized `poweroff` ?
2020-02-11 12:30:19 <AinNero> s/unauthorized/non-root/
2020-02-11 12:30:19 <alpine-meetbot> AinNero meant to say: is this for non-root `poweroff` ?
2020-02-11 12:30:39 <Cogitri> For stuff like that, or hibernation, connection to WiFi/Bluetooth and so on
2020-02-11 12:31:50 <mps> all these works on my boxes without polkit
2020-02-11 12:33:02 <AinNero> i do wpa_cli via `wheel` group
2020-02-11 12:33:06 <AinNero> mps: how do you do poweroff?
2020-02-11 12:33:58 <AinNero> and suspend
2020-02-11 12:33:58 <mps> doas poweroff
2020-02-11 12:34:18 <mps> suspend works over acpid
2020-02-11 12:34:34 <AinNero> mh, i used sudo poweroff, but acpid suspend as well
2020-02-11 12:34:38 <AinNero> react on lid close
2020-02-11 12:34:40 <mps> for wifi I'm using iwd
2020-02-11 12:35:04 <mps> yes, lid and power button
2020-02-11 12:35:41 <mps> I could use acpid for poweroff with power button but I rarely do poweroff
2020-02-11 13:07:57 <Ariadne> north1: perhaps the solution is to autodetect providers and specify dependencies via the autodetected name
2020-02-11 13:09:24 <north1> it might be possible to unpack the tarball, run the  setup.py to generate an .egg with a requires.txt and then use that to get a list of dependncies. then it won't be necessary to specify them in makedepends=
2020-02-11 14:44:07 <PureTryOut[m]> Huh, a package I made locally installs lots of `-dev` packages, even though `$depends` is empty
2020-02-11 14:46:21 <north1> Depends on the APKBUILD?
2020-02-11 14:47:44 <PureTryOut[m]> That's what I said, no there aren't
2020-02-11 14:47:51 <PureTryOut[m]> I don't even have `$depends` set
2020-02-11 15:29:06 <north1> See what it depends on with apk info
2020-02-11 15:36:44 <PureTryOut[m]> Just some so stuff abuild reported as well, nothing weird
2020-02-11 15:37:29 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/fvvCVLKcqkvSbjFZJwURXyJF >

2020-02-11 16:17:57 <dalias> cogitri, system is 100% functional without polkit
2020-02-11 16:18:12 <dalias> there is nothing that user processes need to be requesting actions from root to do on my system
2020-02-11 16:18:43 <dalias> if i want a particular usb device or something to be accessible by user i will make a udev rule to chown or chmod it
2020-02-11 16:19:15 <dalias> i don't want some opaque javascript rules written by fdo folks deciding for me if i should be able to bypass the unix permissions system
2020-02-11 16:25:05 <Cogitri> Well, then don't use it I suppose, but loads and loads of people find it useful
2020-02-11 16:25:43 <mps> and a lot people find it problematic
2020-02-11 16:26:20 <Cogitri> I also find the choice of using JS pretty questionable, but other than that Polkit is pretty nifty
2020-02-11 16:27:02 <minecrell> ^ +1
2020-02-11 16:27:24 <dalias> i've never encountered something polkit does that i even plausibly wanted to happen
2020-02-11 16:28:23 <mps> I removed it as dependency from slim and now thinking to remove it also from xfce
2020-02-11 16:28:58 <Cogitri> I understand wanting to avoid it and if chowing stuff is an OK system for you that's fine but most users like using their external storage or shutting down without firing up a terminal
2020-02-11 16:29:06 <mps> iirc, only xfce4-power-manager depend on it
2020-02-11 16:29:17 <Cogitri> mps: Feel free to do that, but please make it optional
2020-02-11 16:30:43 <dalias> sweet!
2020-02-11 16:30:56 <dalias> i just manually apk added the xfce4 packages i actually use and now
2020-02-11 16:31:02 <dalias> apk del -s xfce4
2020-02-11 16:31:04 <mps> and, we shouldn't do what our users wants but that what we think is 'right thing'
2020-02-11 16:31:07 <dalias> (4/6) Purging xfce4-power-manager (1.6.3-r0)
2020-02-11 16:31:07 <dalias> (5/6) Purging polkit (0.116-r0)
2020-02-11 16:31:10 <dalias> ! :_)
2020-02-11 16:31:24 <dalias> xfce4-power-manager doesn't even work btw
2020-02-11 16:32:43 <mps> if we start to follow users wishes dalias will have to add systemd support for musl :)
2020-02-11 16:32:46 <_ikke_> mps: the most secure system is not usable
2020-02-11 16:33:17 <Cogitri> Right
2020-02-11 16:33:20 <mps> _ikke_: that depends, at least
2020-02-11 16:34:00 <_ikke_> It always depends
2020-02-11 16:34:04 <_ikke_> it's always a trade-off
2020-02-11 16:34:44 <_ikke_> The key is finding the right balance between security and usability
2020-02-11 16:34:56 <mps> security is complex, true. but we can more or less secure our systems deciding our priorities
2020-02-11 16:35:59 <_ikke_> mps: The problem is that we that we get more and more users with different priorities
2020-02-11 16:36:35 <_ikke_> the question is, do we want to provide a working but secure system, or do we say, go somewhere else
2020-02-11 16:37:26 <mps> yes, but then we can lost (well) more users because of 'lowering' security by adding things which is not safe
2020-02-11 16:38:03 <mps> I started to use alpine because of moto 'small, simple, secure'
2020-02-11 16:38:34 <mps> else, why would I switch from debian
2020-02-11 16:39:10 <mps> if I get 'debian on alpine' again
2020-02-11 16:41:23 <dalias> *nod*
2020-02-11 16:43:17 <PureTryOut[m]> !3900 is ready for merging. Since it's quite needed at pmOS, could it be merged as soon as possible? CI passes on all arches
2020-02-11 16:43:37 <north1> @PureTryOut i'll merge after i'm done with py3-humanize
2020-02-11 16:44:46 <PureTryOut[m]> Thanks! πŸ‘οΈ
2020-02-11 16:47:20 <PureTryOut[m]> There we go, thanks for merging!
2020-02-11 16:49:51 <minecrell> north1: Have you seen https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3781? Or is that something for n.copa?
2020-02-11 16:51:03 <north1> Yes, but it is something for ncopa or ikke
2020-02-11 16:51:20 <minecrell> Ok :)
2020-02-11 16:52:14 <_ikke_> Where is AL31 based on?
2020-02-11 16:52:54 <_ikke_> Ok, see naming convention in the current codestyle document
2020-02-11 16:53:08 <mps> !3781
2020-02-11 16:53:42 <north1> There is an alternative codestlye document in !4
2020-02-11 16:55:30 <_ikke_> Yes, I'm aware
2020-02-11 16:55:37 <_ikke_> hence calling it the current codestyle document
2020-02-11 16:57:45 <dalias> ...if i chose alpine because it's small, simple, and secure, then when i do find rare occasion to want something outside the scope of small, simple, and secure, i want it to integrate in a way that's least invasive to that
2020-02-11 16:57:56 <dalias> rather than turning my whole system into something debian-like
2020-02-11 16:58:17 <dalias> so like, not installing stuff that imposes system-wide insecure policy
2020-02-11 16:58:58 <_ikke_> The problem is that it's impossible to cater for both situations atm
2020-02-11 16:59:19 <_ikke_> We have to enable or disable polkit for everyone
2020-02-11 17:01:18 <mps> _ikke_: would you mind to look at https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3909/diffs did I put CVE data properly?
2020-02-11 17:02:01 <_ikke_> yes, looks good
2020-02-11 17:02:04 <_ikke_> 2 spaces for indentation
2020-02-11 17:02:09 <mps> thanks :)
2020-02-11 17:02:20 <north1> Maybe i should lint that
2020-02-11 17:02:32 <_ikke_> yeah, that's still on some CI todolist even
2020-02-11 17:02:48 <mps> north1: do you have linter for this?
2020-02-11 17:02:54 <north1> No
2020-02-11 17:02:58 <mps> heh
2020-02-11 17:04:09 <dalias> imo polkit and such invasive stuff should be like busybox
2020-02-11 17:04:17 <dalias> a default package that installs a dummy version that does nothing
2020-02-11 17:04:26 <dalias> and if you want the full thing you can manually install it
2020-02-11 17:04:43 <dalias> (same way you can install gnu grep, find, coreutils, etc. to replace part of all of busybox if you want)
2020-02-11 17:05:28 <_ikke_> yes, that sounds reasonable
2020-02-11 17:05:52 <north1> So a polkit that just denies everything ?
2020-02-11 17:09:10 <dalias> north1, yep
2020-02-11 17:09:37 <north1> Sounds fair, then gnome can just pull in polkit
2020-02-11 17:10:03 <dalias> "pull in polkit" = pull in the fake/harmless one or the real one?
2020-02-11 17:10:32 <north1> The real one
2020-02-11 17:10:45 <dalias> *sigh* no
2020-02-11 17:10:50 <dalias> the whole point is NOT to do that
2020-02-11 17:10:58 <_ikke_> north1: dalias point is that the user has to opt-in to polkit
2020-02-11 17:11:16 <dalias> if i install gnome, i want by defaul a gnome that does not have any backdoors to root
2020-02-11 17:12:02 <dalias> if i want it to takeover mounting filesytsems, reconfiguring my network, etc. i want to have to explicitly install the package that gives it access to do that
2020-02-11 17:13:25 <_ikke_> north1: '^# secfixes:\s(?:^#.+\s)+' This seems to match secfixes for me
2020-02-11 17:16:01 <Cogitri> No can do with opt-in polkit for GNOME
2020-02-11 17:16:08 <Cogitri> It'll break a lot
2020-02-11 17:16:18 <Cogitri> If you don't want polkit, don't use GNOME to be honest
2020-02-11 17:16:40 <mps> Cogitri: this sounds fair
2020-02-11 17:17:29 <Cogitri> I've setup GNOME so that the thing actually works when you install it without having to guess some amount of packages you need to install for it to be actually functional
2020-02-11 17:19:20 <dalias> cogitri, what does "break a lot" mean?
2020-02-11 17:19:46 <mps> user expectations, I presume
2020-02-11 17:19:50 <dalias> imo it just means the file manager won't auto-mount/eject/etc filesystems and similar
2020-02-11 17:20:14 <dalias> which is the right default expectation: user cannot change system stuff
2020-02-11 17:20:46 <Cogitri> No shutdown, no user management, likely limited network control, no bluetooth possibly (?), no file system management, no running any privileged GUI apps
2020-02-11 17:21:02 <dalias> all sounds fine to me
2020-02-11 17:21:04 <Cogitri> Well, if that's what you consider a right default expectation that's on you
2020-02-11 17:21:50 <dalias> "privileged gui apps" = you're already pwned
2020-02-11 17:22:08 <Cogitri> Let's not keep arguing if it's to no use anyway, I think the user numbers of easy to use distros make it clear what side most people have voted for
2020-02-11 17:22:19 <dalias> there should never be privileged gui apps, only apps which communicate with minimal-surface privileged backends
2020-02-11 17:23:02 <Cogitri> That'd be a better architecture, but there's stuff like GParted which interfaces with libparted directly
2020-02-11 17:23:14 <mps> Cogitri: remember 'small, simple, secure' or the motto should be changed
2020-02-11 17:23:45 <AinNero> i dont feel like Alpine is the best distro to run GNOME on
2020-02-11 17:23:52 <Cogitri> Then don't :)
2020-02-11 17:23:57 <dalias> gparted doesn't need root just needs +rw for the device you want to edit
2020-02-11 17:24:09 <dalias> so chmod +rw the usb drive you plugged in
2020-02-11 17:25:20 <dalias> the gnome/polkit model is "give this program a root backdoor to access one hardware device"
2020-02-11 17:25:21 <mps> AinNero: also I don't feel it, but I don't want to judge this
2020-02-11 17:25:38 <dalias> the unix model is "chown/chmod the device you want to operate on or pass a fd to it over a socket"
2020-02-11 17:26:12 <Cogitri> Turns out most users do the former since it's easier to pull off though
2020-02-11 17:26:13 <dalias> former was not stated clearly;should be:
2020-02-11 17:26:25 <dalias> the gnome/polkit model is "give this program a full root backdoor just for the ake of accessing one hardware device"
2020-02-11 17:26:33 <Cogitri> I don't think you're running GParted in high security environments anyway
2020-02-11 17:26:48 <Cogitri> And you might as well partition all the devices of your system and not just one
2020-02-11 17:27:43 <dalias> those are completely different operations
2020-02-11 17:28:07 <dalias> i explicitly DON'T WANT permission to accidentally nuke my hd when i'm paritioning an SD card or usb flash drive
2020-02-11 17:28:38 <dalias> this is why we don't run as root and constantly yell at ppl who insist on doing it not to do so
2020-02-11 17:29:13 <Cogitri> Well, it'd be quite an accident indeed if you did that over two confirmation dialogues, this isn't shell where it's game over after enter
2020-02-11 17:29:29 <dalias> you always want to operate with least privilege so that in the event of making a mistake -- whether that mistake is just mis-issuing a command yourself or mistakenly trusting some malicious file received from an attacker -- the scope of damage is limited
2020-02-11 17:30:06 <Cogitri> So you can use polkit rules for fine grained access :^)
2020-02-11 17:31:17 <dalias> in college i accidentally formatted a floppy full of important files on a sun workstation because CDE had idiotic keyboard bindings for a format command in its file manager that overlapped with keys you'd reasonably type in a terminal, and the file manager took forever to load and didn't seem to actually be loading until it suddenly appeared and stole focus
2020-02-11 17:31:28 <dalias> there are ALL SORTS of good reasons you should always have least-privilege
2020-02-11 17:33:33 <_ikke_> focus stealing is so anoying
2020-02-11 18:19:16 <PureTryOut[m]> Could somebody merge !3915 once CI completes? The Plasma 5.18 upgrade broke an applet which is fixed this way
2020-02-11 18:19:35 <_ikke_> PureTryOut[m]: I can
2020-02-11 18:20:10 <PureTryOut[m]> Thanks
2020-02-11 18:38:54 <PureTryOut[m]> _ikke_: could you do the same for !3916?
2020-02-11 18:39:08 <_ikke_> sure
2020-02-11 18:39:09 <north1> oof
2020-02-11 18:39:17 <north1> was just waiting for CI for 3916 to end to merge both
2020-02-11 18:39:25 <_ikke_> north1: oh
2020-02-11 18:39:56 <PureTryOut[m]> Lol
2020-02-11 18:43:45 <north1> @ncopa any changes required on !4 ?
2020-02-11 18:44:57 <_ikke_> north1: it passed now :)
2020-02-11 18:49:52 <Cogitri> mps: Can you test the new nss upgrade on arm?
2020-02-11 18:50:29 <Cogitri> To make sure I didn't mess up the neon thingie for it
2020-02-11 18:51:54 <north1> @ikke pushed, thanks
2020-02-11 18:52:11 <mps> Cogitri: nss-3.49.1-r0 ?
2020-02-11 18:53:57 <Cogitri> !3917
2020-02-11 18:54:20 <mps> you mean to build it?
2020-02-11 18:54:46 <Cogitri> Build and test runtime please
2020-02-11 18:54:58 <Cogitri> Not sure how to test the neon thingie, no idea about arm
2020-02-11 18:55:06 <mps> ok
2020-02-11 18:55:25 <mps> your wish is my command :)
2020-02-11 18:56:58 <mps> fired 'abuild -r' but going for one coffee, I feel tired
2020-02-11 18:57:19 <mps> uh, failed build
2020-02-11 18:57:36 <Cogitri> Huh, worked fine on my side, maybe I did a bad push
2020-02-11 18:58:10 <mps> I need some upgrades on builder, sorry
2020-02-11 18:58:39 <mps> now it is going, lets see
2020-02-11 18:58:46 <Cogitri> Seems like it only happens on armv7 https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/48022 πŸ€”
2020-02-11 18:59:11 <mps> ah, no luck. 'gcm.c:(.text.gcmHash_Reset+0x50): undefined reference to `gcm_HashZeroX_hw'
2020-02-11 18:59:33 <Cogitri> Yes, seems like the same thing happens on CI :/
2020-02-11 19:00:17 <mps> I started again to create build log in case you need it
2020-02-11 19:00:52 <mps> here is it http://tpaste.us/Jxa1
2020-02-11 19:31:04 <Cogitri> Thank you :)
2020-02-11 19:35:35 <mps> Cogitri: no, and sorry I don't have time to help more with it
2020-02-11 19:35:56 <mps> s/no,/np,/
2020-02-11 19:35:56 <alpine-meetbot> mps meant to say: Cogitri: np, and sorry I don't have time to help more with it
2020-02-11 19:37:59 <Cogitri> No worries
2020-02-11 19:42:53 <Cogitri> Ugh, 32GB RAM really weren't the best idea for a 3950X :^)
2020-02-11 19:42:59 <Cogitri> Just OOM'ed FF
2020-02-11 19:43:21 <_ikke_> wut
2020-02-11 19:51:31 <Cogitri> Unsure if FF just has such a beastly need for RAM or if most packages need that much with 32 build jobs
2020-02-11 19:51:54 <Cogitri> (Nothing other than GNOME Shell and the FF build is running)
2020-02-11 19:52:34 <mps> just preparing esr backport for 3.11, will look on aarch64
2020-02-11 19:55:14 <mps> but yes, it needs RAM
2020-02-11 19:57:31 <Cogitri> Building both C++ and Rust stuff at the same time isn't fun :P
2020-02-11 20:00:57 <mps> iirc, few months ago I build FF on box with 6 or 8 GB ram with 8GB swap
2020-02-11 20:01:06 <mps> x86_64
2020-02-11 20:01:32 <mps> maybe I should try now again
2020-02-12 08:35:33 <PureTryOut[m]> ddevault_: any chance we could enable https://git.alpinelinux.org/aports/tree/community/ibus/APKBUILD#n40 ?
2020-02-12 09:15:55 <Cogitri> mps: Can you test !3917 again? Seems to build on CI now, unsure if it works during runtime due to neon autodetection during runtime.
2020-02-12 09:21:40 <mps> Cogitri: building
2020-02-12 09:27:35 <Cogitri> Thanks
2020-02-12 09:43:35 <mps> Cogitri: build passed
2020-02-12 09:46:21 <Cogitri> If you install it, does FF still work?
2020-02-12 09:47:37 <mps> which version of FF?
2020-02-12 09:48:13 <mps> to build new from your MR or some old version
2020-02-12 09:49:15 <mps> on my aarc64 box I have ff-esr 68.4.2
2020-02-12 09:51:16 <mps> and on armv7 ff-esr 68.5.0, on armv7 FF >= 72. doesn't work, i.e. abort due (iirc) unaligned instruction
2020-02-12 09:53:44 <Cogitri> Oh, right
2020-02-12 09:54:15 <Cogitri> I guess Chromium should do the trick for testing too
2020-02-12 09:54:38 <Cogitri> I just want to make sure nss doesn't explode on armv7
2020-02-12 09:54:46 <mps> aha
2020-02-12 09:55:15 <mps> ok, I can try later (in a few hours)
2020-02-12 09:56:17 <mps> will now build it on armv7 also
2020-02-12 10:02:36 <Cogitri> Thanks
2020-02-12 10:09:08 <mps> np, we work on same goal
2020-02-12 10:14:31 <PureTryOut[m]> north1: in https://git.alpinelinux.org/aports/commit/testing/cldr-emoji-annotation?id=5e6a9a6b0d054ed5af309a5411817e348d859b66 you said that the pkgconfig file has a weird version so it causes some problems. Indeed, while trying to upgrade the package, abuild now complains about an invalid version string and errors out. Are there any specifications on how the version should be formatted so I can link the upstream
2020-02-12 10:14:32 <PureTryOut[m]> dev to it?
2020-02-12 10:14:36 <PureTryOut[m]> Other distributions (e.g. Arch Linux) don't seem to have much trouble with the version file
2020-02-12 10:35:50 <north1> If i remember correctly it is because it has _0 at  the end
2020-02-12 10:37:28 <PureTryOut[m]> Yeah probably, but why would that be invalid?
2020-02-12 10:37:35 <north1> not accepted by abuild
2020-02-12 10:37:47 <north1> http://ix.io/2buD
2020-02-12 10:38:25 <mps> Cogitri: apk version nss => nss-3.49.2-r0     > 3.49.1-r0
2020-02-12 10:38:48 <PureTryOut[m]> But why?
2020-02-12 10:38:50 <PureTryOut[m]> north1: ah thanks that'll do
2020-02-12 10:38:57 <mps> firefox-esr 68.5.0 works fine, this is on armv7 edge
2020-02-12 10:40:16 <north1> no clue why
2020-02-12 10:42:03 <Cogitri> Good, I guess the new nss and ff are good to go then
2020-02-12 10:42:16 <mps> ncopa: ncurses 6.2 is released
2020-02-12 10:43:31 <mps> about year ago we talked about switching our versioning scheme for fixing it to (maybe) 6.2 and adding some kind of sub version id
2020-02-12 10:44:07 <mps> currently we have 6.1 and release date as version in aports
2020-02-12 10:44:45 <mps> when you find some time, please
2020-02-12 10:53:09 <north1> @ikke Can you take a quick look at !3947 ?
2020-02-12 10:54:30 <north1> It should make openrc respect the /usr/lib -> /etc -> /run separation of configuration
2020-02-12 12:01:58 <PureTryOut[m]> Ok it happened again. Why the hell does this package depend on a -dev subpackage?
2020-02-12 12:06:13 <PureTryOut[m]> (I just realized I didn't send a link) https://pkgs.alpinelinux.org/package/edge/testing/x86_64/signon-plugin-oauth2
2020-02-12 12:08:42 <north1> oh, you have a .pc file in the mainpackage
2020-02-12 12:09:08 <north1> signon-oauth2plugin.pc which Requires: signon-plugins
2020-02-12 12:09:19 <PureTryOut[m]> Oh, forgot to add a -dev then? Normally abuild complains about it
2020-02-12 12:09:23 <north1> signon-plugins.pc which Requires: libsignon-qt5
2020-02-12 12:09:37 <north1> and then libsignon-qt5.pc which Requires: Qt5Core
2020-02-12 12:09:46 <north1> yes
2020-02-12 12:14:38 <PureTryOut[m]> north1: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3964
2020-02-12 12:17:32 <north1> merged
2020-02-12 12:21:51 <PureTryOut[m]> north1: unbreaks the armhf builder: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3965
2020-02-12 12:25:03 <north1> merged
2020-02-12 12:50:26 <north1> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/24 any opinions ?
2020-02-12 13:08:42 <mps> PureTryOut[m]: tried to start spectral on armv7 and got: QQmlApplicationEngine failed to load component
2020-02-12 13:09:08 <mps> do I need to install something?
2020-02-12 13:09:39 <PureTryOut[m]> Uh, idk. Works fine for me on x86_64. Could you paste the full log somewhere?
2020-02-12 13:11:09 <mps> http://tpaste.us/reJL
2020-02-12 13:14:53 <Thermi> ncopa: mpfr.org is down, so mpfr4 doesn't build, there's a mirror of the source files at https://ftp.gnu.org/gnu/mpfr/, maybe point at that in the source array instead
2020-02-12 13:15:02 <Thermi> checksum is the same
2020-02-12 13:30:46 <north1> @PureTryOut is !3948 good to go ?
2020-02-12 13:32:09 <PureTryOut[m]> Yes
2020-02-12 14:15:42 <dalias> ok, so removing polkit/xfce4-power-manager seems to have significantly increased my battery life :-P
2020-02-12 14:15:51 <dalias> but killed backlight-adjustment keys
2020-02-12 14:16:34 <dalias> in theory acpid should be all you need to make the keys work but the busybox one seems underfeatured and alpine doesn't seem to have an alternative one..?
2020-02-12 14:35:40 <mps> dalias: for me most keys (those I need) works with busybox acpid
2020-02-12 14:36:55 <dalias> how do you configure them?
2020-02-12 14:37:40 <dalias> in busybox source i could only find lid and power button
2020-02-12 14:38:06 <mps> in /etc/acpi/KEY_NAME
2020-02-12 14:38:21 <mps> for example /etc/acpi/LID
2020-02-12 14:39:59 <dalias> how do i find the right KEY_NAME ?
2020-02-12 14:39:59 <mps> cat /etc/acpi/VOLUMEUP/00000080 => light -A 50
2020-02-12 14:40:24 <mps> evtest helped me
2020-02-12 14:40:48 <dalias> thanks
2020-02-12 14:42:40 <mps> though I use awesome WM (not any DE) and programmed some keyboard shortcuts with lua applets
2020-02-12 14:43:22 <dalias> hmm can't find it on any of them
2020-02-12 14:43:45 <mps> you select device from list evtest show
2020-02-12 14:43:52 <dalias> right
2020-02-12 14:44:00 <dalias> i tried keyboard, extra buttons, ...
2020-02-12 14:44:36 <mps> hmm, strange, here is one example '/dev/input/event9:      Lid Switch'
2020-02-12 14:45:03 <AinNero> on my thinkpad, i also only get the PWRF and LID events
2020-02-12 14:45:09 <dalias> ah it's video bus
2020-02-12 14:45:29 <AinNero> there is an input device for the lid as well, but thats not causing any noticable xorg inputs
2020-02-12 14:45:34 <dalias> Event: time 1581518725.537535, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
2020-02-12 14:45:54 <dalias> so is it /etc/acpid/BRIGHTNESSUP ?
2020-02-12 14:46:11 <mps> here is better example http://tpaste.us/PMax
2020-02-12 14:48:05 <mps> evtest can find whatever event exists, if the drivers are loaded ofc
2020-02-12 14:48:28 <AinNero> mps: thats something different from the acpid handlers, right?
2020-02-12 14:48:48 <mps> AinNero: yes, but most works fine
2020-02-12 14:49:59 <dalias> evtest found it but i dont know what name acpid would be looking for
2020-02-12 14:50:41 <mps> dalias: yes, it should be /etc/acpid/KEY_NAME but without 'KEY_' prefix
2020-02-12 14:51:49 <mps> I don't have brightness set so can't show example
2020-02-12 14:53:30 <AinNero> mps: im still not convinced that busybox acpid can do more than LID/00000080 and PWRF/00000080
2020-02-12 14:53:46 <AinNero> and acpid and evtest work on different sources
2020-02-12 14:54:12 <AinNero> acpid on /proc/acpi/event, and evtest on /dev/input/...
2020-02-12 14:54:25 <mps> I have volumeup/down mapped to set light with acpid
2020-02-12 14:54:30 <dalias> from busybox source it looks like you need an action file and/or map file for anything other than those two
2020-02-12 14:54:38 <dalias> but i can't find any example
2020-02-12 14:59:18 <mps> hmm, have to find some time for this to check and test thoroughly (but don't where is supermarket with time to buy)
2020-02-12 15:05:02 <mps> AinNero: right, stylus events does not work with BB acpid
2020-02-12 15:05:40 <AinNero> also, i found that evtest displays some events that dont get passed to xorg and are not visible from xev
2020-02-12 15:05:49 <mps> probably also some other (I didn't tested much of them)
2020-02-12 15:06:39 <mps> with xev I only search keys to remap
2020-02-12 15:07:43 <mps> re acpid, year ago I started to port 'real' acpid to alpine but never finished
2020-02-12 15:10:52 <dalias> i dont understand why all the mainstream distro crap wants these events to go thru the X server/desktop env :(
2020-02-12 15:11:08 <dalias> is it so they can display pretty visual feedback like windows/mac do?
2020-02-12 15:11:25 <dalias> i've always been really annoyed that the brightness keys didn't work without X running
2020-02-12 15:11:56 <dalias> Fn+* are "supposed to" behave like they're implemented in hardware
2020-02-12 15:12:23 <dalias> not be shortcut keys for desktop-software-controlled features
2020-02-12 15:15:53 <mps> because users who abandon windows want it back on unix/linux
2020-02-12 15:17:03 <dalias> yay map file was what i need
2020-02-12 15:17:50 <dalias> and scripts work
2020-02-12 15:18:01 <dalias> including on console
2020-02-12 15:22:54 <afontain_> Oh, can you share what you did?
2020-02-12 15:25:40 <afontain_> something like the custom keymap in https://wiki.archlinux.org/index.php/Linux_console/Keyboard_configuration ?
2020-02-12 15:29:39 <dalias> http://ix.io/2bw4 - exiting lines were copied from source to preserve original behavior
2020-02-12 15:29:50 <dalias> the builtin actions file remaps them to the usual names
2020-02-12 16:54:48 <mps> heh, on this site https://gitlab.com/spectral-im/spectral in screenshots is the PureTryOut[m]
2020-02-12 17:55:27 <Cogitri> Hm, what's the variable for the distdir in abuild? I want to cache cargo downloads in abuild
2020-02-12 17:57:31 <[[sroracle]]> distfiles? i think SRCDEST
2020-02-12 17:58:04 <[[sroracle]]> caching them is kinda tricky without putting them in $source though i imagine
2020-02-12 17:59:27 <Cogitri> I'd just set CARGO_HOME to some permanent dir and it'd work presumably
2020-02-12 17:59:42 <Cogitri> Alrighty, SRCDEST it is then, thanks
2020-02-12 18:23:43 <Cogitri> mps: Can you test !3978 please?
2020-02-12 18:45:32 <mps> Cogitri: ofc, on both arch?
2020-02-12 18:46:38 <Cogitri> Would be nice, but one of them is sufficient for now
2020-02-12 18:46:48 <Cogitri>  I guess aarch64 would be best so you can test runtime too
2020-02-12 18:48:26 <mps> I will run first on armv7 because don't like to abuse builders (both my dev lxcs are on one box which is at the same time official builder)
2020-02-12 18:48:54 <mps> ah, to late, started on armv7
2020-02-12 18:49:33 <mps> now will stop and move to aarch64
2020-02-12 18:49:49 <Cogitri> Ah okie, thanks :)
2020-02-12 18:51:31 <mps> started, now have to wait about 40 minutes
2020-02-12 18:52:17 <mps> if we are lucky, hope it will not break early
2020-02-12 19:00:46 <Cogitri> Yup :)
2020-02-12 21:13:38 <mps> Cogitri: FF 73.0 built and work on aarch64
2020-02-12 21:13:52 <Cogitri> Great :)
2020-02-12 21:14:12 <mps> takes time to build
2020-02-12 21:14:28 <mps> now I will try on armv7
2020-02-12 21:15:20 <mps> hmm, freenode press me to change nick :(
2020-02-12 21:15:54 <_ikke_> mps: whut, why?
2020-02-12 21:15:59 <Cogitri> Huh? :o
2020-02-12 21:16:58 <mps> 'This nickname is registered. Please choose a different nickname, or identify via /msg Nickserv'
2020-02-12 21:17:12 <_ikke_> And you didn't register it?
2020-02-12 21:17:44 <mps> no, I'm registered under different nickname
2020-02-12 21:19:16 <mps> I mean, account name
2020-02-12 21:19:24 <Cogitri> Huh, I thought this room only allowed registered nicknames
2020-02-12 21:19:33 <north1> rip mps
2020-02-12 21:20:04 <mps> I can register new nick, thinking about 'leo' :)
2020-02-12 21:20:09 <_ikke_> lol
2020-02-12 21:21:04 <Cogitri> Heh
2020-02-12 21:21:11 <clandmeter> what is an account name?
2020-02-12 21:22:04 <mps> freenode account
2020-02-12 21:22:31 <clandmeter> ah you can assign more than one nick right?
2020-02-12 21:22:33 <_ikke_> You can have multiple nicks under one account
2020-02-12 21:22:35 <_ikke_> yes
2020-02-12 21:22:59 <mps> yes, what _ikke_ says
2020-02-12 21:23:01 <north1> @mps I'll email you a list of answers to commonly asked questions so you can answer for me :D
2020-02-12 21:23:11 <mps> :D
2020-02-12 21:23:11 <_ikke_> :D
2020-02-12 21:23:48 <clandmeter> so somebody else registered that nick recently?
2020-02-12 21:23:58 <clandmeter> or it has been registered long time by somebody else?
2020-02-12 21:24:08 <_ikke_> long time ago
2020-02-12 21:24:12 <_ikke_> 2012/2013
2020-02-12 21:24:24 <mps> I don't know, this is first time I got this msg from freenode
2020-02-12 21:25:00 <clandmeter> if nobody uses it maybe you can claim it.
2020-02-12 21:25:23 <clandmeter> i cannot live without mps on my screen
2020-02-12 21:25:28 <mps> yes, just thought about that
2020-02-12 21:26:10 <mps> probably will contact them in day or two
2020-02-12 21:27:07 <clandmeter> Registered nicknames and accounts will expire if they're not used for a long time, after which they'll be available for another user to take over. See our policies for details of when this occurs.
2020-02-12 21:27:29 <clandmeter> https://freenode.net/policies
2020-02-12 21:27:55 <mps> thanks, I remember that I read that loooong time ago
2020-02-12 21:28:09 <clandmeter> me too, thats why i looked for it :)
2020-02-12 21:28:10 <_ikke_> We will vouch for you being the real mps :P
2020-02-12 21:28:27 <clandmeter> will the real mps stand up
2020-02-12 21:28:45 <mps> thanks for support
2020-02-12 21:29:29 <_ikke_> apparently Sobhan has registered mps
2020-02-12 21:31:43 <mps> what command is used to get this data
2020-02-12 21:31:56 <_ikke_> info mps to nickserv
2020-02-12 21:32:56 <_ikke_> maybe I can get ikke :P
2020-02-12 21:34:41 <clandmeter> if mps can get it, you should too
2020-02-12 21:36:47 <mps> and mps can get _mps_
2020-02-12 21:36:55 <clandmeter> :)
2020-02-12 21:37:15 <clandmeter> previously_known_as_mps
2020-02-12 21:37:34 <mps> this is better
2020-02-12 21:45:27 <Guest90427> @mps leo is already taken
2020-02-12 21:45:53 <_ikke_> lol
2020-02-12 21:46:12 <mps> Guest90427: I know, it was joke for someone here
2020-02-12 21:46:33 <_ikke_> mps: Guest90427 is north1
2020-02-12 21:46:42 <clandmeter> :)
2020-02-12 21:46:58 <Guest90427> Hey, mps is free :D
2020-02-12 21:47:12 <_ikke_> north1 is now known as leo
2020-02-12 21:47:14 <_ikke_> leo is now known as Guest90427
2020-02-12 21:47:34 <clandmeter> i have that disabled.
2020-02-12 21:47:39 <_ikke_> me too
2020-02-12 21:47:46 <mps> also I ignore this
2020-02-12 21:47:50 <clandmeter> but whois can tell enough :)
2020-02-12 21:48:01 <_ikke_> but I disabled the filter temporarily when I saw Guest90427 responding to mps
2020-02-12 21:48:53 <north1> idk why but the matrix irc bridge is very dumb when it comes to changing name
2020-02-12 21:49:04 <north1> i do !nick maxice8 and it lands me on maxice32392 or something
2020-02-12 21:49:56 <clandmeter> i think you need to register your nick auth into the bridge right?
2020-02-12 21:50:18 <clandmeter> i remember i did that before when we tried matrix
2020-02-12 21:58:30 <kFL5lAYUbp6a> Cogitri: > Huh, I thought this room only allowed registered nicknames nope, this restriction has been lifted luckily. otherwise i would not be able to do this <-
2020-02-12 22:00:51 <_ikke_> We only had that for a while due to the excessive spam at that time
2020-02-12 22:01:14 <Cogitri> Ah, alrighty
2020-02-12 23:08:43 <mps> Cogitri: are you around? FF 73.0 built on armv7, but didn't had time to test if it works
2020-02-12 23:08:56 <north1> @mps no, it is 00:08 in CET
2020-02-12 23:09:17 <mps> also here :)
2020-02-13 08:20:12 <PureTryOut[m]> mps: I'm just that awesome that everyone includes me in their screenshots 😏
2020-02-13 08:44:40 <mps> PureTryOut[m]: obviously :)
2020-02-13 09:19:38 <nmeum> ncopa: 9e450874c8064d59e87132576fc6bd76fc598e75 is there a specific reason why parrallel builds of main/bison are important to you?
2020-02-13 09:20:07 <nmeum> the patch does no longer apply cleanly, I don't think rebasing it is really worth it as the time consuming part of building that aport is the check() and not the build() function
2020-02-13 09:25:56 <Cogitri> Probably, dev time is way more expensive than builder time anyway
2020-02-13 09:29:22 <_ikke_> But sometimes they are coupled :)
2020-02-13 09:42:41 <Cogitri> Fair :P
2020-02-13 10:53:47 <_ikke_> dejadup is failing to build (test failure)
2020-02-13 10:53:58 <north1> I  have notified cogitri already
2020-02-13 10:54:34 <Cogitri> Yes, weird that it fails on the builders but works just fine on CI and my machine
2020-02-13 11:02:09 <nmeum> happens occasionally
2020-02-13 11:15:27 <markand> 
ACTION wonders why profanity (xmpp ncurses clients) depends on gtk 

2020-02-13 11:18:40 <nmeum> markand: https://github.com/profanity-im/profanity/commit/dc0c3cc699c1b91fbf3c9724f5039f3bd1ed0d95 they support a tray icon
2020-02-13 11:18:53 <markand> 
ACTION facepalms

2020-02-13 11:20:00 <markand> 1. tray icon; 2. tray icon for a terminal app
2020-02-13 11:20:06 <markand> I'm done with it
2020-02-13 13:02:33 <PureTryOut[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4032 fixes py3-language-server on the builders, not sure how that slipped through CI
2020-02-13 13:04:38 <_ikke_> it still fails on CI?
2020-02-13 13:04:47 <_ikke_> missing deps
2020-02-13 13:05:41 <_ikke_> That seems like an issue with fetching the repos
2020-02-13 13:11:39 <PureTryOut[m]> CI fails because the packages it depends on are still stuck on the builders
2020-02-13 13:11:47 <_ikke_> ah
2020-02-13 13:11:51 <PureTryOut[m]> CI always fails when fixing the builders πŸ˜‰
2020-02-13 13:51:30 <markand> β€œRecompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.”
2020-02-13 13:51:34 <markand> xz vs zstd
2020-02-13 13:51:36 <markand> wise choice
2020-02-13 13:52:09 <_ikke_> That was from Archlinux, right?
2020-02-13 13:53:30 <markand> yes
2020-02-13 13:53:45 <markand> I see more and more people switching to zstandard those days
2020-02-13 13:55:26 <mps> markand: is that tested on single CPU machines
2020-02-13 14:08:12 <clandmeter> single cpu or single core?
2020-02-13 14:09:36 <PureTryOut[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3848 is now ready for merging, thanks afontain!
2020-02-13 14:10:29 <mps> single CPU, core can have more 'virtaul' CPUs
2020-02-13 14:11:52 <clandmeter> no core is a core
2020-02-13 14:11:56 <clandmeter> those are threads
2020-02-13 14:12:20 <clandmeter> in my book :)
2020-02-13 14:12:54 <mps> right, call it according your book :)
2020-02-13 14:14:23 <clandmeter> i have a single cpu with 64 cores which provide 128 threads.
2020-02-13 14:14:28 <mps> then, single HT
2020-02-13 14:15:00 <clandmeter> HT is intel afaik AMD call it differently
2020-02-13 14:15:17 <clandmeter> sorry for all the info...
2020-02-13 14:15:33 <clandmeter> you can tell me to stfu
2020-02-13 14:15:39 <mps> yes, I know but nevermaind
2020-02-13 14:16:22 <mps> nitpicking is nice fun
2020-02-13 14:16:33 <clandmeter> but i guess that performance gain is also based on multi threaded performance
2020-02-13 14:16:56 <mps> also I, that is why asked
2020-02-13 14:46:28 <Thermi> The `rm` in busybox doesn't correctly handle recursively removing files on a bind mount
2020-02-13 14:46:43 <mps> do we add CVE info to pkgs in testing?
2020-02-13 14:46:52 <north1> yes
2020-02-13 14:47:01 <Thermi> Breaks cleaning up and all calls to rm or abuild-rmtemp if the package is in a dir of a volume mount, e.g. docker
2020-02-13 14:47:14 <mps> north1: you answered to me or?
2020-02-13 14:47:16 <Thermi> it just fails with saying some sub directory wasn't empty
2020-02-13 14:47:26 <Thermi> Where do I report that to?
2020-02-13 14:47:29 <north1> @mps yes i did answer you
2020-02-13 14:47:37 <mps> aha, ok
2020-02-13 14:48:01 <mps> looks like testing/thunderbird is quite safe till now :)
2020-02-13 14:48:38 <mps> np, I will add current CVEs
2020-02-13 14:48:41 <north1> Or nobody added the CVEs
2020-02-13 14:48:58 <mps> yes, because that I asked
2020-02-13 14:50:35 <mps> last two times when upgraded it I didn't check :|
2020-02-13 15:36:02 <Thermi> Is there an actual dependency on linux-firmware for building linux-lts?
2020-02-13 15:36:11 <Thermi> Like, on the firmware files themselves?
2020-02-13 15:36:58 <_ikke_> https://git.alpinelinux.org/aports/tree/main/linux-lts/APKBUILD#n15
2020-02-13 15:37:48 <Thermi> Yes I know that
2020-02-13 15:37:52 <Thermi> I mean during the build process
2020-02-13 15:42:16 <_ikke_> look at the line I linked to
2020-02-13 15:42:51 <_ikke_> it's makedepends
2020-02-13 15:42:56 <_ikke_> which are installed during building
2020-02-13 15:53:12 <Thermi> _ikke_: Yes, I am aware of that. I am asking if the linux code at buildtime requires them to be present
2020-02-13 15:53:17 <Thermi> not the APKBUILD
2020-02-13 15:53:20 <_ikke_> ah
2020-02-13 15:53:22 <Thermi> The Makefiles
2020-02-13 15:53:31 <Thermi> and whatever they do with their preprocessor directives and whatnot
2020-02-13 15:53:51 <Thermi> Installing all the packages requires a little bit too much time for my taste. :)
2020-02-13 15:54:08 <_ikke_> Thermi: You could try to apk add linux-firmware-none
2020-02-13 15:54:19 <_ikke_> then it should not pull in any firmware packages
2020-02-13 15:54:30 <Thermi> ty, I'll look
2020-02-13 16:46:11 <opal> >* To get rid of the SHA-1 based "package identity".
2020-02-13 16:46:16 <opal> what's apk going to move to for hashing
2020-02-13 16:46:23 <opal> has blake3 been considered
2020-02-13 16:46:42 <opal> or do people want to stick to sha family
2020-02-13 16:48:41 <_ikke_> I think you should ask fabled that, as he's doing the work on it
2020-02-13 16:49:06 <_ikke_> afaik, there has been no discussion about that yet
2020-02-13 16:49:11 <opal> mm
2020-02-13 16:49:33 <opal> well consider that my 2Β’ to suggest blake family instead :p
2020-02-13 16:49:56 <_ikke_> Posting that to the mailing list would probably have more result
2020-02-13 16:50:09 <_ikke_> here it will just be forgotten
2020-02-13 16:50:11 <opal> yeah, wanted to bring it up here first
2020-02-13 16:50:39 <opal> i'll reply to that thread
2020-02-13 16:53:27 <opal> oh, may it be a better idea to file an issue on gitlab
2020-02-13 16:53:39 <mps> is the blake3 standardized
2020-02-13 16:53:56 <opal> theres a spec at https://github.com/BLAKE3-team/BLAKE3-specs
2020-02-13 16:54:18 <mps> no, I mean official standard
2020-02-13 16:54:31 <opal> official by whose blessing
2020-02-13 16:54:49 <mps> some organization
2020-02-13 16:55:05 <opal> hold on let me create an organisation right now and standardise it :)
2020-02-13 16:55:23 <opal> in seriousness, i dont see where youre aiming with your question
2020-02-13 16:55:47 <north1> @mps no it isn't part of POSIX as far as i am aware
2020-02-13 16:56:06 <_ikke_> I don't think posix standardizes cryptographic hashes
2020-02-13 16:56:06 <PureTryOut[m]> Cogitri: there are requests to have gnome-software with the Flatpak backend available on pmOS. I know it won't work with apk yet, but could you package it with just the Flatpak backend for now?
2020-02-13 16:56:10 <mps> RFC
2020-02-13 16:56:15 <opal> does posix ... yeah what ikke said
2020-02-13 16:56:42 <mps> ISO/IEC
2020-02-13 16:56:44 <mps> ?
2020-02-13 16:57:38 <opal> BLAKE2b and BLAKE2s are specified in RFC 7693
2020-02-13 16:57:42 <opal> unsure about blake3 yet
2020-02-13 16:57:49 <Lucas8037> depends on  a lot of stuff. There are crypto standards by FIPS, by IETF, ..
2020-02-13 16:58:00 <mps> NIST
2020-02-13 16:58:08 <_ikke_> blake3 was anounced last month
2020-02-13 16:58:09 <Lucas8037> that one too
2020-02-13 16:58:39 <_ikke_> "It was announced on January 9th, 2020 at Real World Crypto. "
2020-02-13 16:58:47 <opal> certifications dont speak strongly about a hash's durability in the future
2020-02-13 17:00:43 <mps> true, but alpine project have to care which standard to use for long standing work
2020-02-13 17:02:41 <opal> i think blake2 would be a safe compromise
2020-02-13 17:03:00 <opal> my web browser froze up else i'd quote something to here
2020-02-13 17:03:10 <opal> gotta love the web lol
2020-02-13 17:04:43 <opal> (speaking of, wonder if netsurf's finally stable on alpine, but im not holding my breath)
2020-02-13 17:06:10 <opal> here we go: "BLAKE2b is faster than MD5, SHA-1, SHA-2, and SHA-3, on 64-bit x64 and ARM architectures. BLAKE2 provides security superior to SHA-2 and similar to that of SHA-3: immunity to length extension, indifferentiability from a random oracle, etc. "
2020-02-13 17:06:25 <opal> cited https://eprint.iacr.org/2013/322.pdf
2020-02-13 17:07:04 <opal> i'll contribute to the https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10670 issue
2020-02-13 17:07:36 <opal> (seems someone already suggested blake2)
2020-02-13 17:11:57 <mps> speed is good factor to have in mind but there are more factors when selecting 'something' for thing as package manager
2020-02-13 17:19:47 <opal> from what im reading, blake (not blake2) was not chosen for sha3 because keccak won for being "different enough from sha2" and more performant on asics
2020-02-13 17:23:51 <opal> thanks for pushing me to research a bit more into this
2020-02-13 17:35:13 <opal> btw https://gitlab.alpinelinux.org/alpine/aports/issues/10233 is an old issue that i think should be closed
2020-02-13 17:35:23 <opal> i believe the issue's been fixed
2020-02-13 17:42:01 <Cogitri> PureTryOut[m]: Sure thing
2020-02-13 17:44:31 <Cogitri> opal: And right, that has been taken care of
2020-02-13 17:45:32 <opal> thakns
2020-02-13 17:45:36 <opal> thanks, even
2020-02-13 19:32:14 <fabled> opal, blake and sha have both be suggested. i'd rather stick to standard formats. i believe that blake is not supported for e.g. ecdsa signatures yet. however, it might be usable for some other hashes like the file integrity hash.
2020-02-13 19:38:41 <opal> ack
2020-02-13 19:48:42 <dalias> <-- also a vote for standard formats
2020-02-13 19:56:05 <reidrankin> qq: I haven't contributed to aports before, is a gitlab.a.o MR the appropriate venue?
2020-02-13 19:56:26 <reidrankin> (tiny 1-line quality-of-life fix to /etc/init.d/modloop)
2020-02-13 19:56:54 <_ikke_> yes
2020-02-13 20:04:07 <north1> !4047 Any opinions on ?
2020-02-13 20:13:20 <reidrankin> ok, I've just put up !4056; since this is my first time, would someone mind giving me a second set of eyes on it real quick?
2020-02-13 20:13:38 <_ikke_> reidrankin: looking
2020-02-13 20:13:43 <reidrankin> thanks
2020-02-13 20:14:15 <_ikke_> reidrankin: commit message style for summary is: <repo>/<package>: short summary
2020-02-13 20:14:52 <reidrankin> will fix
2020-02-13 20:14:56 <_ikke_> thanks
2020-02-13 20:15:29 <_ikke_> For the rest it looks ok
2020-02-13 20:15:41 <_ikke_> I like that you put an explanation in the commit message
2020-02-13 20:16:45 <reidrankin> ..are you cogitri, or it the response time just that good?
2020-02-13 20:17:08 <_ikke_> No, I'm not cogitry
2020-02-13 20:17:19 <_ikke_> but I had the MR open, and I got a notificiation about the pipeline running
2020-02-13 20:17:33 <_ikke_> cogitri*
2020-02-13 20:23:37 <reidrankin> _ikke_: fixed up -- is it a problem that there's no issue to go with the fix?
2020-02-13 20:24:06 <_ikke_> no, that's not an issue ;-)
2020-02-13 20:24:17 <mps> any guide/policy/notes how to override busybox initd and confd for apk which replaces BB applet
2020-02-13 20:24:41 <clandmeter> say what?
2020-02-13 20:25:03 <mps> making acpid replacement for BB acpid
2020-02-13 20:25:28 <clandmeter> ah ok
2020-02-13 20:25:32 <clandmeter> now i get it :)
2020-02-13 20:25:41 <mps> have to override its /etc/conf.d/acpid and /etc/init.d/acpid
2020-02-13 20:26:46 <mps> I'm not in a hurry
2020-02-13 20:26:56 <clandmeter> im not 100% sure about that
2020-02-13 20:27:05 <clandmeter> maybe have it with another name?
2020-02-13 20:27:12 <clandmeter> which provides the same?
2020-02-13 20:27:49 <mps> will it move somewhere current BB files?
2020-02-13 20:28:18 <_ikke_> NO, it won't
2020-02-13 20:28:18 <clandmeter> you mean the symlink?
2020-02-13 20:28:22 <mps> we have dcron but it is not good example
2020-02-13 20:28:27 <_ikke_> s/NO/No/
2020-02-13 20:28:27 <alpine-meetbot> _ikke_ meant to say: No, it won't
2020-02-13 20:28:44 <_ikke_> /etc/init.d/acpid
2020-02-13 20:29:34 <mps> /usr/sbin/crond is BB symlink and I think apk auto fix it
2020-02-13 20:29:46 <mps> but not initd and confd files
2020-02-13 20:29:55 <_ikke_> correct
2020-02-13 20:30:20 <_ikke_> there is a trigger run
2020-02-13 20:30:35 <_ikke_> that after packages are installed, will instruct BB to create symlinks
2020-02-13 20:30:51 <_ikke_> but it will skip the symlink if something already exists
2020-02-13 20:31:04 <_ikke_> but that only works for applets, it does not know anything about openrc service files
2020-02-13 20:31:20 <clandmeter> i think they are not shipped with busybox?
2020-02-13 20:31:27 <_ikke_> there is a separate package
2020-02-13 20:31:27 <mps> yes
2020-02-13 20:31:30 <clandmeter> but busybox-initscrips or something
2020-02-13 20:31:33 <_ikke_> yes
2020-02-13 20:31:55 <clandmeter> if you want to provide an alternative, probably better to rename the initd
2020-02-13 20:32:03 <clandmeter> or you need to use replaces
2020-02-13 20:32:22 <_ikke_> But then you need to replace *all* init scripts that are provided by that package
2020-02-13 20:33:22 <mps> post-install pre-remove hacks?
2020-02-13 20:34:04 <clandmeter> is acpid a dep service or explicitly added to a runlevel?
2020-02-13 20:35:01 <mps> acpid is in default runlevel
2020-02-13 20:36:18 <mps> I don't see any dep/need for it
2020-02-14 00:38:48 <dalias> libimobiledevice package sseems broken. all the utils wand a "usbmuxd" utility but it's not packaged
2020-02-14 00:41:10 <dalias> fcolista, you're the maintainer -- do you know anything about this?
2020-02-14 00:45:20 <north1> @dalias can you test if installing !4068 fixes it ?
2020-02-14 01:11:53 <dalias> oh it's @testing maybe that's why
2020-02-14 01:12:20 <dalias> oh no it's newly added?
2020-02-14 01:12:52 <north1> It is an MR, it is not in the repo
2020-02-14 01:12:56 <dalias> oh
2020-02-14 01:12:58 <dalias> i see
2020-02-14 01:12:59 <north1> you can download the apk from the CI for your arch
2020-02-14 01:13:04 <north1> and install it with apk add <FILE>
2020-02-14 01:13:15 <dalias> ohhh nice
2020-02-14 01:13:23 <dalias> i didnt know there was download from CI
2020-02-14 01:13:43 <north1> It was implemented very recently
2020-02-14 01:14:00 <dalias> where is it?
2020-02-14 01:14:51 <dalias> ah i see, pipelines
2020-02-14 01:18:43 <north1> Yes, check the pipeline for your arch
2020-02-14 01:18:53 <north1> They are deleted after, I think, 9 hours
2020-02-14 01:20:27 <dalias> well, it doesn't seem to work still but at least it's there
2020-02-14 06:58:18 <craftyguy> one of the packages I submitted for aports uses some glibc extensions to realpath to protect against directory traversal attacks. this doesn't work on musl, and I do *not* want my merge request to be merged until this is resolved. unfortunately the upstream maintainer doesn't seem too interested in figuring it out
2020-02-14 06:59:19 <craftyguy> I can't help but think that this is not the first project ever to implement some 'do not allow traversal attacks' using musl.. does anyone know of other projects that have this implemented that could provide an example to help move things along?
2020-02-14 06:59:36 <craftyguy> C/libc/musl are not my strong areas :(
2020-02-14 07:02:10 <_ikke_> craftyguy: mark that MR as work in progress
2020-02-14 07:02:29 <craftyguy> _ikke_: I added WIP to the title
2020-02-14 07:02:38 <_ikke_> alright
2020-02-14 07:02:57 <_ikke_> for th rest I'm not aware personally of how this might have been solved in the past
2020-02-14 07:03:05 <craftyguy> I just wanted to make it clear that I wasn't entertaining the idea of pushing for something with a security flaw to be merged :)
2020-02-14 07:03:30 <_ikke_> How does that realpath extension look like?
2020-02-14 07:07:28 <craftyguy> the application is an archive extraction tool. from what I can tell, the second arg to glibc realpath is set to the tested path if it doesn't exist (this is the path the archive wants to extract to, with expanded .., etc), and that's used to compare against the path in the archive to detect if there's a traversal issue
2020-02-14 07:07:41 <craftyguy> here's the check: https://github.com/twogood/unshield/blob/f097b07571bdbc8cae2b710dadc9ce27630ac7bc/src/unshield.c#L518
2020-02-14 07:08:11 <craftyguy> if this is offtopic here, I can try to find the right musl place to ask away. I didn't even check to see if they're on IRC (sorry about that)
2020-02-14 07:09:17 <craftyguy> I think glibc expands the 1st arg and returns it in the 2nd arg, allowing the comparison to be a 'valid' check against traversal attacks
2020-02-14 07:10:37 <craftyguy> musl libc seems to just raise EACCES or EINVAL, and 2nd arg is NULL if it doesn't exist. (which it probably won't exist, because you sometimes don't extract archives to replace existing files..)
2020-02-14 07:11:09 <craftyguy> it's like they are using realpath to do the equivalent of os.path.expanduser in python :P
2020-02-14 07:11:15 <_ikke_> craftyguy: this is certainly not offtopic here
2020-02-14 07:20:31 <mps> craftyguy: musl irc channel is #musl on freenode
2020-02-14 07:21:18 <craftyguy> mps: go figure. I'll go ask there, thanks :)
2020-02-14 07:21:45 <mps> np
2020-02-14 09:52:05 <mps> craftyguy: what pkg you are trying to fix with musl
2020-02-14 09:52:55 <PureTryOut[m]> unshield, check the link he sent
2020-02-14 09:54:17 <mps> ah, yes, missed it in backlog
2020-02-14 12:18:42 <north1> @MY-R 184355fdc44bc2e12976d65518fe029d8a6e459d
2020-02-14 13:27:36 <mps> gjabell: did you posted mdp new aport patch
2020-02-14 13:53:24 <mps> gjabell: I cleaned it a little (look diff with your patch) and pushed
2020-02-14 14:25:40 <gjabell> mps: yeah that was me, thanks for the cleanup!
2020-02-14 14:42:28 <mps> gjabell: no problem, I looked at it some time ago and thought make aport but forgot (as I forgot some other useful packages :) )
2020-02-14 14:52:05 <mps> if you create new aport it would be good idea to create merge request on gitlab.a.o where it will be check with linter and built, so anyone who want to commit it can have more information about 'quality' of pkg
2020-02-14 14:53:34 <mps> personally, I'm easy to push packages from MR than mailing list because I see any (potential) issue/bug/problem
2020-02-14 15:03:37 <gjabell> mps: oh, good to know! I'm guessing I need to create that separately / in addition to mailing the mailing list?
2020-02-14 15:03:51 <gjabell> ie there's no automatic connector or something between the two?
2020-02-14 15:04:14 <north1> No, there is no automatic connector, most of the time i fetch the Patch from the patchlist and make an MR to get CI to validate stuff for me
2020-02-14 15:06:22 <_ikke_> similar for me
2020-02-14 15:08:18 <gjabell> gotcha, I'll go resubmit my open patches as MRs
2020-02-14 15:08:34 <gjabell> thanks for the help y'all :)
2020-02-14 15:09:46 <mps> some people worked hard for us to have this (gitlab) as primary development system, many thanks to them
2020-02-14 15:49:17 <dalias> craftyguy, "from what I can tell, the second arg to glibc realpath is set to the tested path if it doesn't exist" <-- this is not documented glibc behavior and is just a consequence of the contents of the buffer being undefined on failure and glibc happening to use it as working space
2020-02-14 15:49:33 <dalias> if your program is relying on that even on glibc, it's a bug in your program
2020-02-14 15:50:08 <dalias> and you really really really should stop experimenting with interfaces to determine their behavior and instead read the documentation for them, or you're going to end up with dangerous code
2020-02-14 15:50:48 <dalias> experimenting is basically useful only for one thing: developing exploits (poc for a bug report, or real weaponized ones)
2020-02-14 16:02:57 <gjabell> is it possible to have `abuild rootbld` allow network requests?
2020-02-14 16:03:12 <clandmeter> options=net
2020-02-14 16:04:13 <sbts_> Hi all, with latest stable I'm seeing an issue running setup-alpine when configuring ntp.
2020-02-14 16:04:33 <clandmeter> this is not a support channel
2020-02-14 16:04:39 <sbts_> It appears to be trying to configure it too early and reports an error (I'll paste this in a minute)
2020-02-14 16:04:59 <sbts_> clandmeter: agreed, but this is an issue for the dev's to check on
2020-02-14 16:05:33 <sbts_> ERROR: unsatisfiable constraints:
2020-02-14 16:05:33 <sbts_>   openntpd (missing):
2020-02-14 16:05:33 <sbts_>     required by: world[openntpd]
2020-02-14 16:05:33 <sbts_>  * rc-update: service `openntpd' does not exist
2020-02-14 16:05:33 <sbts_>  * rc-service: service `openntpd' does not exist
2020-02-14 16:05:57 <gjabell> clandmeter: thanks, should that be included in the final apkbuild or is that only for local testing?
2020-02-14 16:06:11 <clandmeter> please create an issue for issues on gitlab.a.o
2020-02-14 16:06:13 <north1> please use a paste service for 3 or more lines @sbts_
2020-02-14 16:06:46 <sbts_> Once the initial run of setup is complete (and before a reboot) you can run setup-ntp without trouble
2020-02-14 16:06:53 <clandmeter> gjabell: should to in the apkbuild
2020-02-14 16:07:16 <clandmeter> there has been talk about switching to rootbld
2020-02-14 16:07:22 <clandmeter> so it makes sense to add it
2020-02-14 16:07:46 <gjabell> gotcha
2020-02-14 16:08:00 <gjabell> is the wiki open for edits? it's not listed in options on the apkbuild reference page
2020-02-14 16:08:17 <clandmeter> yes please
2020-02-14 16:08:19 <north1> I believe you need to make an account
2020-02-14 16:10:04 <gjabell> cool, I'll look into that real quick
2020-02-14 16:10:41 <mps> sbts_: use chrony, it works o'ut of the box'
2020-02-14 16:11:18 <mps> openntpd is unmaintained, practically
2020-02-14 16:12:59 <mps> dalias: I made aport and built 'real' acpid (not busybox applet) and testing it now
2020-02-14 16:13:28 <gjabell> clandmeter: is "Allows network access when run in fakeroot" a reasonable description? also is there a !net option? (guessing not since that'd be default behavior :P)
2020-02-14 16:13:45 <mps> hope will finish it's conflicts with BB acpid in a day or two
2020-02-14 16:14:33 <dalias> mps, fwiw the busybox one works well if you rtfs to find the undocumented config files it supports
2020-02-14 16:15:09 <mps> 'rtfs' mean read the 'fine' source?
2020-02-14 16:15:14 <dalias> :)
2020-02-14 16:15:37 <dalias> yes
2020-02-14 16:15:38 <clandmeter> fine or the other f words
2020-02-14 16:15:51 <dalias> because the busybox source is extremely fine ;-)
2020-02-14 16:16:00 <mps> yes, but we are fine people
2020-02-14 16:16:17 <clandmeter> especially mps
2020-02-14 16:16:25 <dalias> fwiw it should really be "read the friendly source"
2020-02-14 16:16:29 <dalias> because the source is so friendly
2020-02-14 16:17:01 <dalias> obviously having the user read the source is the most user-friendly way of documenting functionality :)
2020-02-14 16:17:17 <mps> there is saying 'with such friends do I need enemies'
2020-02-14 16:18:26 <_ikke_> dalias: the source can never be wrong though :P
2020-02-14 16:18:49 <dalias> _ikke_, as documentation is kinda can; see my comments to craftyguy above :-P
2020-02-14 16:18:56 <dalias> it*
2020-02-14 16:19:06 <mps> but, 'real' acpid can be useful, it have kacpimon utility to monitor events, debug and such works
2020-02-14 16:19:14 <dalias> mps, yeah
2020-02-14 16:24:00 <mps> acpi button driver which signals init (process 1) directly https://lore.kernel.org/lkml/cover.1581463668.git.josh@joshtriplett.org/
2020-02-14 16:24:44 <mps> soon we will not need acpid if this continues
2020-02-14 16:28:04 <dalias> ...
2020-02-14 16:52:46 <Ariadne> https://wiki.alpinelinux.org/wiki/VRF
2020-02-14 16:52:50 <Ariadne> coming to Alpine 3.12 :p
2020-02-14 16:53:28 <_ikke_> thanks for the example
2020-02-14 16:53:35 <north1> @Adriane might want to write it here https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0
2020-02-14 16:54:20 <_ikke_> fyi, upgrading gitlab, might be unavailable for a minute
2020-02-14 16:55:15 <Ariadne> why is telegram desktop newsworthy :D
2020-02-14 16:56:33 <north1> People asked for it to be moved to communnity
2020-02-14 16:56:37 <north1> community*
2020-02-14 16:57:20 <Ariadne> Error: This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: New users are not allowed to add ip addresses and phone numbers within 5 hrs of account creation
2020-02-14 16:57:21 <mps> Ariadne: VRF - F is not Function, Forwarding?
2020-02-14 16:57:28 <_ikke_> Yes
2020-02-14 16:57:33 <_ikke_> Virtual Routing and Forwarding
2020-02-14 16:57:42 <Ariadne> oh
2020-02-14 16:57:48 <Ariadne> ironware calls them virtual routing functions
2020-02-14 16:59:30 <mps> kernel tree Documentation/networking/vrf.txt
2020-02-14 17:00:08 <mps> anyway, nice
2020-02-14 17:00:21 <Ariadne> yes well
2020-02-14 17:00:28 <Ariadne> still need to upstream the eBPF work
2020-02-14 17:12:19 <mps> we need to enable more options/drivers in kernel, iwd doesn't work rpi kernels
2020-02-14 17:12:48 <Ariadne> mps: if you can handle the kernel side of enabling eBPF and those additional drivers, i will be happy to do a review
2020-02-14 17:13:28 <mps> I don't have rights to upload to dev.a.o so can't fix this for rpi kernels
2020-02-14 17:14:11 <mps> I can only enable this for linux-lts and linux-virt
2020-02-14 17:48:22 <ncopa> hi friends! how are thing going?
2020-02-14 17:48:41 <mps> \o
2020-02-14 17:48:58 <mps> good, as usual
2020-02-14 17:49:19 <dalias> hi
2020-02-14 17:49:31 <mps> a lot of bugs and issues :)
2020-02-14 17:49:48 <mps> and MRs, ofc
2020-02-14 17:50:01 <ncopa> i have had the week completely alpine free. real vacation iow
2020-02-14 17:50:11 <ncopa> but i miss you ppl :)
2020-02-14 17:53:24 <_ikke_> o/
2020-02-14 17:53:25 <_ikke_> hi
2020-02-14 17:53:47 <afontain_> hi
2020-02-14 17:55:02 <afontain_> mps: about MR, are you okay with merging the anbox one?
2020-02-14 17:55:22 <minecrell> fabled: I was looking at https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3781 again, but actually I'm not sure why we need the HOSTCC=... stuff at all. AFAICT, the purpose of the two lines is set HOSTCC to CC with the cross compiler prefix stripped. But isn't it already set correctly in
2020-02-14 17:55:22 <minecrell> https://gitlab.alpinelinux.org/alpine/abuild/blob/master/functions.sh.in#L152?
2020-02-14 17:55:22 <minecrell> I'm not really familiar with abuild cross compiling
2020-02-14 17:55:37 <afontain_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3848 :P
2020-02-14 17:56:21 <minecrell> afontain_: "This is a temporary file that should not end up in master!"
2020-02-14 17:56:30 <mps> afontain_: sorry, I'm against idea to have ready made files (img) to add to alpine
2020-02-14 17:56:54 <afontain_> we could add a -bin suffix to warn people
2020-02-14 17:57:13 <mps> we prefer to build everything from source
2020-02-14 17:57:36 <afontain_> or I could also remove that package to leave only anbox itself
2020-02-14 17:58:05 <mps> it would be better to create script which install anbox for users who want it
2020-02-14 17:58:23 <mps> script out of aports, I mean
2020-02-14 17:58:48 <mps> or, to move it to non-free
2020-02-14 18:00:58 <afontain_> the thing is, I fear Android isn't going to compile on Alpine. Between the absence of upstream source tarballs, the shear size of the source tree (15G once you remove the vcs files) and the glibc binairies everywhere (clang, protobuf, bison!), it seems pretty complicated
2020-02-14 18:01:28 <afontain_> now, maybe with some container or chroot build we could, but that's not great either
2020-02-14 18:01:41 <Ariadne> if anbox itself is free software, package anbox itself
2020-02-14 18:01:50 <Ariadne> and have a script to fetch the non-free android image
2020-02-14 18:02:07 <fabled> minecrell, quite possible. it might be remnant before the cross-compile stuff was done in abuild
2020-02-14 18:02:19 <afontain_> I'm fine with having anbox-image not being in Alpine
2020-02-14 18:02:34 <Ariadne> afontain_: okay make the prerequisite changes and i will review it
2020-02-14 18:02:59 <afontain_> do I go with a post-install telling people to put an image to /var/lib/anbox/android.img?
2020-02-14 18:03:11 <Ariadne> yes
2020-02-14 18:03:12 <minecrell> fabled: What would be a simple way to test if it builds fine without it? I don't actually know how to test cross compilation
2020-02-14 18:03:14 <mps> afontain_: you can look at some APKBUILDs in non-free as examples
2020-02-14 18:03:37 <Ariadne> mps: if anbox itself is free software, it is fine to have it in community.
2020-02-14 18:03:48 <Ariadne> mps: but we cannot legally distribute android itself obviously.
2020-02-14 18:04:36 <afontain_> isn't AOSP open-source?
2020-02-14 18:04:42 <minecrell> Ariadne: Why is the Android image non-free? It's prebuilt, but does that make it non-free?
2020-02-14 18:04:48 <minecrell> you can build it yourself, it's just complicated
2020-02-14 18:04:57 <Ariadne> the android image presumably includes google services
2020-02-14 18:05:00 <Ariadne> which are non-free
2020-02-14 18:05:07 <mps> Ariadne: yes, I trying to tell just this
2020-02-14 18:05:11 <afontain_> it doesn't
2020-02-14 18:05:13 <Ariadne> if it did not, then many apps will not work
2020-02-14 18:05:20 <afontain_> well, there isn't any gapps at least
2020-02-14 18:05:37 <Ariadne> gapps != google services
2020-02-14 18:05:44 <afontain_> Do you know of an app that uses GPlay services?
2020-02-14 18:05:49 <Ariadne> like all of them
2020-02-14 18:06:00 <minecrell> I don't think anbox would be allowed to redistribute google services
2020-02-14 18:06:07 <mps> some years ago I built android-x86 on debian
2020-02-14 18:06:13 <Ariadne> they aren't, but probably do anyway
2020-02-14 18:06:49 <Ariadne> at any rate, this is Not Our Problem if we simply tell the user to go download the image herself
2020-02-14 18:07:43 <mps> there is replacement for google gapps somewhere on the net
2020-02-14 18:08:06 <afontain_> microG?
2020-02-14 18:08:31 <mps> can't remember, stopped to use android 3-4 years ago
2020-02-14 18:09:55 <Ariadne> yes, but something like anbox won't use microG as it is not fully compatible
2020-02-14 18:11:22 <minecrell> Doesn't look like there are play services in the Anbox image
2020-02-14 18:13:54 <afontain_> (I was actually serious, I haven't used apps with google play services for a long time, so I really don't know any which need it)
2020-02-14 18:15:50 <afontain_> mps: APKBUILDs in non-free look pretty much like regular ones?
2020-02-14 18:16:06 <afontain_> just in the non-free folder
2020-02-14 18:17:21 <_ikke_> Why should they look different?
2020-02-14 18:18:13 <mps> there is one which downloads .zip but forgot which one
2020-02-14 18:19:47 <mps> chromium-widevine
2020-02-14 18:21:37 <afontain_> it's still in sources
2020-02-14 18:21:58 <mps> yes
2020-02-14 18:22:13 <afontain_> I remove the depends on anbox-image, right?
2020-02-14 18:22:28 <mps> I thought (wrongly) it is for download by user
2020-02-14 18:24:13 <mps> I'm not sure how it should be done, but think to create apk which install prerequisite file and script which user can use to download ready-made images
2020-02-14 18:24:27 <mps> files*
2020-02-14 18:25:13 <craftyguy> dalias: it's not my application, it's one I would like to use and was wanting to try and patch to make the same functionality (protect against dir traversal attacks) work on musl. I didn't implement anything in that application yet
2020-02-14 18:29:29 <dalias> craftyguy, ok, i wasn't clear if it was yours or someone else's
2020-02-14 18:29:43 <dalias> but either way I think this is a bug -- that's not behavior that glibc promises as far as i can tell
2020-02-14 18:30:22 <minecrell> fabled: Hmm, do I need to use bootstrap.sh to test cross compilation? or is there an easier way?
2020-02-14 18:31:29 <afontain_> an alternative is to make package anbox-image into postmarketos instead
2020-02-14 18:32:02 <craftyguy> dalias: agreed. the goal is to perform some path resolution and they found some hackish way in glibc, but I can't find anything in posix c that would also do path resolution in a similar way
2020-02-14 18:32:15 <mps> hmm, why pmOS want android on pmOS
2020-02-14 18:32:29 <craftyguy> so it would seem my only other option is to implement something like that. which seems weird. does no one else protect against this type of attack?
2020-02-14 18:32:46 <afontain_> giving a script isn't very convinient. It's also worse than a simple wget line
2020-02-14 18:33:09 <craftyguy> mps: there are lots of apps that run on android. apps that are optimized for mobile.. pmos is primarily targeting mobile devices :)
2020-02-14 18:33:24 <dalias> craftyguy, can you explain clearly what you're trying to prevent?
2020-02-14 18:33:24 <Ariadne> apps that require google play services
2020-02-14 18:34:05 <minecrell> Ariadne: There are also many apps that can run, to some extend, without it
2020-02-14 18:34:07 <afontain_> there are tons of apps on FDroid, you know
2020-02-14 18:34:13 <dalias> generally forbidding intentional symlinks is considered a bad thing, but an archive util does need to detect cases where the archive extraction both creates the symlink then uses it to write outside its tree
2020-02-14 18:34:33 <dalias> so normally i would not use realpath for this and would just reject path components of ".." at the string level
2020-02-14 18:34:58 <afontain_> I genuinely don't know, in the Android apps I'm living with, any that require google play services
2020-02-14 18:35:01 <mps> still don't understand, why then use android on bare metal
2020-02-14 18:35:10 <dalias> but for archive extraction things are more complicated
2020-02-14 18:35:27 <craftyguy> dalias: sure. something like this: "tar xf foo.tar -C bar" should never extract anything to "bar/../../etc/passwd" or whatever
2020-02-14 18:35:35 <mps> still don't understand, why then don't use android on bare metal
2020-02-14 18:36:07 <dalias> craftyguy, right. preventing that directly is trivial. the problem is extracting a symlink bar->../.. then extracting bar/etc/passwd
2020-02-14 18:36:07 <craftyguy> because apparently you can build archives with files that have paths like '../../somewhere/else', etc
2020-02-14 18:36:38 <afontain_> because it's better to have only one android app for say, commute train than a whole OS that tries a bit too much to spy on you?
2020-02-14 18:37:10 <afontain_> I think it makes sense to try to ease the transition
2020-02-14 18:37:18 <Ariadne> this is a pointless thing anyway because alpine disallows such symlinks
2020-02-14 18:37:21 <dalias> i think you can replicate the intended original logic just by doing realpath without the final component you're about to create
2020-02-14 18:37:35 <dalias> ariadne, ?
2020-02-14 18:37:36 <mps> this doesn't fit fine in my POV
2020-02-14 18:38:00 <dalias> ariadne, i dont think that's accurate
2020-02-14 18:38:07 <Ariadne> dalias: alpine disallows a user to create a symlink to something that they do not have write permission to
2020-02-14 18:38:20 <dalias> no it doesn't
2020-02-14 18:38:26 <dalias> doing that would be horribly world-breaking
2020-02-14 18:38:44 <dalias> it disallows it only in mode +t dirs (/tmp) and that's still breaking but less-so
2020-02-14 18:39:10 <dalias> but it has nothing to do with craftyguy's topic at hand
2020-02-14 18:39:12 <afontain_> there are plenty of free as in freedom apps on Android, and the base system is free.
2020-02-14 18:39:16 <dalias> which is not about different users but same user
2020-02-14 18:39:35 <dalias> and wanting to be able to safely extract an archive in a dir without worrying that it will clobber files outside that dir
2020-02-14 18:39:53 <Ariadne> hmm
2020-02-14 18:39:56 <afontain_> having that part seems fine
2020-02-14 18:39:58 <mps> afontain_: yes, I run some time ago android in qemu for this
2020-02-14 18:40:09 <dalias> craftyguy, to continue from..
2020-02-14 18:40:13 <dalias> <dalias> i think you can replicate the intended original logic just by doing realpath without the final component you're about to create
2020-02-14 18:40:42 <dalias> (doing that instead of realpath on the full final pathname)
2020-02-14 18:40:56 <Ariadne> dalias: i must misunderstand the purpose of fs.protected_symlinks=1 then
2020-02-14 18:41:07 <dalias> ariadne, yes, it's just for /tmp
2020-02-14 18:41:26 <dalias> (rather all +t dirs, so dev/shm, /var/tmp, etc too)
2020-02-14 18:42:37 <dalias> craftyguy, because if the pathname with the final component doesn't exist, the creation will fail anyway, so you can assume it does exist
2020-02-14 18:43:06 <craftyguy> dalias: I'm not sure I understand. how do you decide when to stop testing the prefix? take this path: "bar/bazz/blah/file". none of those could exist, so realpath would return null. like in the case that the archive contains a dir structure
2020-02-14 18:43:16 <dalias> (or if you do a "mkdir -p" type thing to handle the case where it doesn't exist, just add realpath at the path level where the "mkdir -p" starts)
2020-02-14 18:43:38 <dalias> if you're about to create "bar/bazz/blah/file", then "bar/bazz/blah" must already exist or it's an error
2020-02-14 18:43:43 <dalias> so readpath bar/bazz/blah
2020-02-14 18:43:44 <dalias> done
2020-02-14 18:43:57 <dalias> if your archiver recursively creates paths that don't exist like mkdir -p
2020-02-14 18:44:07 <dalias> then you just need to do the same logic at steps where it mkdirs the missing ones
2020-02-14 18:44:55 <craftyguy> that won't help if the argument to 'mkdir -p'-like functionality includes 'bar/bazz/blah/../../../../etc'
2020-02-14 18:55:14 <craftyguy> anyways, I appreciate the help/ideas. I think this might be something I need to ponder on some more. my original question of 'is there something in posix libc that would help' has pretty much been answered, now it's just a matter of what to implement instead
2020-02-14 19:01:01 <gjabell> is there a way to skip checks for specific architectures rather than the entire package?
2020-02-14 19:01:18 <gjabell> or is it better practice to just ignore tests completely if they fail for some architectures
2020-02-14 19:02:05 <mps> skip checks should be last thing if package have it
2020-02-14 19:03:04 <mps> package could be disabled on arch on which its test fail
2020-02-14 19:03:34 <gjabell> ok
2020-02-14 19:04:02 <mps> you can try to contact upstream to fix issue
2020-02-14 19:50:36 <PureTryOut[m]> mps: afontain: for now I'd say just put anbox-image in pmOS, not in Alpine. We can discuss more about that later
2020-02-14 23:02:52 <mps> nice, 5.4.20 kernel is released, starting to dislike weekends :)
2020-02-14 23:28:56 <Ariadne> why is it
2020-02-14 23:29:06 <Ariadne> that as soon as i build the current kernel
2020-02-14 23:29:10 <Ariadne> a new one comes out same day
2020-02-14 23:31:18 <mps> !3902
2020-02-14 23:31:45 <mps> this is from few days ago, updated to 5.4.20
2020-02-14 23:37:49 <mps> CONFIG_BPF_JIT_ALWAYS_ON ?
2020-02-14 23:38:44 <Ariadne> yes
2020-02-14 23:39:20 <mps> thought so, but I think ncopa should confirm
2020-02-14 23:39:53 <mps> and we have CONFIG_RD_BZIP2 => Support loading of a bzip2 encoded initial ramdisk or cpio buffer
2020-02-14 23:40:08 <mps> who use bzip2 for such things?
2020-02-14 23:43:24 <mps> Ariadne: CONFIG_CGROUP_BPF also
2020-02-14 23:43:36 <Ariadne> yes
2020-02-14 23:43:51 <Ariadne> i enabled the relevant ones in linux-octeon already.
2020-02-14 23:45:15 <mps> where it is?
2020-02-14 23:45:37 <Ariadne> main/linux-octeon/config-octeon.mips64
2020-02-14 23:45:58 <mps> eh, missed its inclusion
2020-02-14 23:46:47 <mps> hmm, there is this: # CONFIG_BPF_SYSCALL is not set
2020-02-15 00:14:53 <Ariadne> needs to be enabled yeah
2020-02-15 10:18:35 <minecrell> fabled: OK, I managed to cross compile linux-lts using bootstrap.sh and it worked just fine without additionally setting HOSTCC in the APKBUILD. I'll make a MR to remove it
2020-02-15 10:28:37 <minecrell> fabled: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4127
2020-02-15 10:31:59 <mps> minecrell: is the previous MR applied
2020-02-15 10:32:05 <minecrell> no
2020-02-15 10:32:12 <minecrell> Was never merged :)
2020-02-15 10:32:36 <mps> I think so, so this new MR is not needed
2020-02-15 10:33:33 <mps> and why there is 'make -j1'
2020-02-15 10:34:04 <mps> ah, modules
2020-02-15 10:34:36 <mps> was not obvious from diff
2020-02-15 10:34:54 <minecrell> either way, wasn't me who added -j1 ;)
2020-02-15 10:35:23 <minecrell> I just removed all mentions of HOSTCC
2020-02-15 10:45:01 <mps> that's ok for modules_install
2020-02-15 11:21:18 <_ikke_> why does py3-language-server need qt5 dependencies?
2020-02-15 11:22:29 <_ikke_> ah, checkdepends
2020-02-15 12:14:27 <mps> north1: I see your awesome work on upgrading mate
2020-02-15 12:15:01 <mps> did you forgot atril or there is some problems with it
2020-02-15 12:22:31 <north1> I forgot it, the mate-desktop-environment package doesn't depend on all mate stuff and mate stuff aren't named like gnome where it is gnome-X and gnome-Y, which makes it easier
2020-02-15 12:22:43 <north1> rather than forgot, i missed it entirely
2020-02-15 12:24:27 <mps> np
2020-02-15 17:16:37 <dalias> <craftyguy> that won't help if the argument to 'mkdir -p'-like functionality includes 'bar/bazz/blah/../../../../etc'
2020-02-15 17:16:49 <dalias> craftyguy, you simply hard-reject anything with a .. component. it's not valid in an archive
2020-02-15 17:17:53 <dalias> but in any case, realpath of "bar/bazz/blah/../../../.." would show that it's outside the extraction root
2020-02-15 17:18:09 <dalias> so i'm not sure what your concern was
2020-02-15 19:54:04 <nmeum> hm, community/go is really in a bad shape
2020-02-15 19:54:22 <_ikke_> nmeum: what's up with it?
2020-02-15 19:55:38 <nmeum> outdated and most test do not pass due to the default-buildmode-pie.patch
2020-02-15 19:56:31 <nmeum> should actually be easy to cleanup, remove default-buildmode-pie.patch and pass the -buildmode=pie cflags using the GOFLAGS environment variable that should allow all (?) or at least most test to pass
2020-02-15 19:56:38 <nmeum> wanted to do that for a while but never got around to it
2020-02-15 19:58:17 <_ikke_> relevant: https://lists.alpinelinux.org/~alpine/devel/%3C20191129221308.hy6ybayxu2nsu5dy%40wolfsden.cz%3E
2020-02-15 19:58:43 <nmeum> yep I am aware of this
2020-02-15 19:58:46 <_ikke_> nod
2020-02-15 19:59:05 <nmeum> I worked on a "fix" in the past 9686793792a2c40a872ebbb2b86fa537f22491ad
2020-02-15 19:59:35 <nmeum> though that fix breaks aports which explictly disable cgo
2020-02-15 20:00:04 <_ikke_> I think many packages disable CGO just because of that warning
2020-02-15 20:00:29 <nmeum> fabled: would you be ok with activating PIE for go using the GOFLAGS environment variable (which is contrary to CFLAGS) actually picked up by the compiler
2020-02-15 20:03:39 <Cogitri> We need that in every aport then though, which is a little annoying
2020-02-15 20:03:45 <nmeum> no we don't
2020-02-15 20:03:50 <nmeum> we simply add it to /etc/abuild.conf
2020-02-15 20:04:21 <Cogitri> We could do that too if aports are careful not to overwrite it, right
2020-02-15 20:04:51 <nmeum> we make the same assumption for CFLAGS so I would be willing to take that risk
2020-02-15 20:05:25 <_ikke_> Cogitri: maybe we can make an apkbuild-lint check for that
2020-02-15 20:06:05 <Cogitri> Yup, and it should be easy to make sure no aport does that
2020-02-15 20:06:08 <Cogitri> Yup, that'd be nice
2020-02-15 20:06:09 <_ikke_> though, there might be legitimate reasons to overwrite it
2020-02-15 20:06:17 <_ikke_> are there?
2020-02-15 20:06:24 <nmeum> I can't think of any
2020-02-15 20:07:18 <Cogitri> I don't know Go well, but I don't think we've had stuff failing with PIE as of now
2020-02-15 20:08:08 <nmeum> well…we currently have the go compiler testsuite partially failing due to the way we enable by default at the moment
2020-02-15 20:08:29 <nmeum> but apart from that I cannot recall any go PIE failures either
2020-02-15 20:18:12 <Cogitri> Ah right
2020-02-15 20:18:53 <Cogitri> The nice thing about setting the flag directly in go is that users who build outside of aports get the advantages of PIE automatically
2020-02-15 20:19:11 <Cogitri> But on the other hand we might also introduce weird breakages with it
2020-02-15 20:19:48 <nmeum> yeah, that's the only drawback I can think of (re: users need to enable it manually then)
2020-02-15 20:39:58 <_ikke_> north1: ping
2020-02-15 20:41:28 <north1> pong
2020-02-15 20:41:49 <_ikke_> north1: so I'm trying to write a new test for atools
2020-02-15 20:42:22 <_ikke_> that checks if CLFAGS is overwritten, and same for GOFLAGS
2020-02-15 20:42:54 <_ikke_> but currently it fails because it says custom variables should start with an _ and variables should not be capitalized
2020-02-15 20:44:04 <north1> you can set environment variables to disable certain checks
2020-02-15 20:44:08 <_ikke_> the first problem is solved by adding it to variables
2020-02-15 20:44:10 <_ikke_> right
2020-02-15 20:44:29 <_ikke_> but won't it complain anyway in APKBUILDS that you cannot use CFLAGS?
2020-02-15 20:45:04 <north1> yes
2020-02-15 20:46:34 <_ikke_> strange thing is, if I have a test APKBUILD file, then it does not complain at all
2020-02-15 20:56:05 <_ikke_> ok, the issue is that somehow more then the first tab is removed from the test APKBUILD
2020-02-15 21:00:27 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4138
2020-02-15 21:00:42 <nmeum> these are the changes to switch from the default-buildmode-pie.patch to GOFLAGS
2020-02-15 21:01:15 <nmeum> I will work on improving the go test suite separatly if this is merged
2020-02-15 21:05:21 <_ikke_> north1: hmm, bash heredocs are not working like we expect
2020-02-15 21:17:03 <_ikke_> It's removing all preceding tabs, not just the first level (or same level as the closing tag, as I expected
2020-02-15 21:21:13 <nmeum> hm, looks like compiling go itself with -buildmode=pie does not work on all arches
2020-02-15 22:09:33 <kaey> btw set-external-linker patch can be removed, fixed upstream
2020-02-15 22:10:21 <kaey> and it makes sense to set -trimpath goflag for reproducible binaries
2020-02-15 22:13:19 <nmeum> do you have a link regarding the upstream set-external-linker fix?
2020-02-15 22:15:32 <kaey> github issue in patch descr
2020-02-15 22:15:39 <nmeum> mps: if you have some free time on your hands, could you test !4138 on aarch64? it fails on the CI with `Getrlimit: save failed: operation not permitted` I wonder if that's a limitation of the CI container setup …
2020-02-15 22:15:51 <nmeum> kaey: oh, never mind then. will look into it. thanks!
2020-02-15 22:16:45 <kaey> https://github.com/golang/go/blob/master/src/make.bash#L133
2020-02-15 22:17:37 <kaey> so we dont even have to set go_ldso
2020-02-15 22:20:07 <nmeum> kaey: !4139 created a seperate PR for it, let's se how this does on the CI
2020-02-15 22:24:39 <nmeum> also fails on aarch64. I guess the syscall test doesn't work on the LXC aarch64 setup then
2020-02-15 22:27:29 <nmeum> kaey: pushed, thanks for pointing this out!
2020-02-15 22:44:40 <mps> nmeum: I was afk, will try now
2020-02-15 22:45:42 <nmeum> mps: thanks!
2020-02-15 22:45:49 <mps> hm, you have another one
2020-02-15 22:46:04 <mps> which 4138 or 4139
2020-02-15 22:46:19 <mps> which one to test
2020-02-15 22:47:34 <nmeum> !4138
2020-02-15 22:48:07 <mps> ok
2020-02-15 23:24:55 <mps> nmeum: sorry, for slow work, http://tpaste.us/0PaE
2020-02-15 23:25:42 <nmeum> hehe, no problem
2020-02-15 23:25:49 <nmeum> thanks for testing it, looks good
2020-02-15 23:26:56 <north1> @ncopa ping
2020-02-15 23:41:45 <Cogitri> Do we do gpg verification of sources? !4131
2020-02-15 23:42:14 <Cogitri> IMHO we don't need to do it in unpack(), devs can just verify it themselves and the aport itself is safe due to the shasum
2020-02-15 23:42:24 <mps> no
2020-02-15 23:43:36 <Cogitri> Alrighty then
2020-02-15 23:44:26 <mps> I see, this check with gpg is not needed
2020-02-16 00:13:02 <mps> <grumpy hat on> !3991
2020-02-16 00:14:26 <mps> <grumpy hat off>
2020-02-16 10:05:40 <nmeum> mps: merged sqlar with a few local additions
2020-02-16 10:08:16 <Cogitri> πŸ‘
2020-02-16 10:14:38 <mps> nmeum: I see, but pkgname and pkgdesc are still quoted
2020-02-16 10:15:21 <mps> and, apkbuild-lint didn't catched this
2020-02-16 10:21:12 <mps> no pkgdesc, what I'm talking about, need another morning coffee
2020-02-16 10:35:06 <Cogitri> apkbuild-lint doesn't complain about quoted pkgname and pkgver since newapkbuild currently outputs that
2020-02-16 10:36:20 <mps> anyway it should
2020-02-16 10:39:59 <Cogitri> Yes, it should, but first we should strip that behaviour of newapkbuild
2020-02-16 10:59:43 <nmeum> mps: oopps, indeed probably should also get a morning coffee before reviewing prs ':)
2020-02-16 11:00:06 <nmeum> we should also remove the quoted pkgname stuff from the newapkbuild template because that's where it is coming from
2020-02-16 11:00:46 <Cogitri> Yes
2020-02-16 11:00:54 <Cogitri> Not sure why we even added that
2020-02-16 11:01:16 <nmeum> what does the current codingstyle.md say about quoted pkgname?
2020-02-16 11:01:29 <nmeum> I believe I definitly addressed this in !4 though
2020-02-16 11:01:45 <Cogitri> Yes, it's addressed in !4 and the current codingstyle isn't used anyway
2020-02-16 11:02:01 <Cogitri> We'd need someone to finally merge abuild stuff again though :^)
2020-02-16 11:02:13 <Cogitri> Right now that stuff just rots
2020-02-16 11:02:27 <nmeum> I can merge abuild stuff
2020-02-16 11:04:52 <Cogitri> Well, we have a volunteeer for looking through all the abuild MRs then :P
2020-02-16 11:05:09 <nmeum> haha
2020-02-16 11:06:08 <nmeum> north1: what's the advantage of doing cmake out-of-source builds by default?
2020-02-16 11:09:12 <Cogitri> No file conflicts I suppose
2020-02-16 11:09:58 <nmeum> also often recommeded by upstream
2020-02-16 11:10:08 <Cogitri> Yes
2020-02-16 11:10:13 <nmeum> in any case it would be nice to document a reason for this change in the commit message
2020-02-16 11:10:35 <Cogitri> Ah yes, that's always nice
2020-02-16 11:16:18 <Cogitri> Oh wow, I was curious why I didn't get a proper backtrace for gnome-shortwave SIGSEGVing, maybe not stripping the debug symbols would help with that :^)
2020-02-16 11:18:13 <Cogitri> mps: Could you maybe prefix the title of MRs for stable branches with [branch name] ?
2020-02-16 11:18:25 <Cogitri> Like how I've done it in !4160
2020-02-16 11:18:57 <mps> Cogitri: I don't this is needed
2020-02-16 11:19:02 <nmeum> _ikke_: how do you want to proceed with the GOFLAGS change we discussed yesterday. IMHO it could just be merged as is though someone would need to merge /etc/abuild.conf with /etc/abuild.conf.apk-new on the builders then.
2020-02-16 11:19:50 <Cogitri> mps: That way it's easier to filter out what MR is for what branch though
2020-02-16 11:19:51 <mps> branch is already named with 3.11-stable prefix
2020-02-16 11:20:01 <_ikke_> nmeum: I don't have access to ppc64le or s390x builders, so someone else would need to do that.
2020-02-16 11:20:48 <nmeum> maybe clandmeter? If possible I would also like to get some input from fabled but not sure if he actually reads the IRC backlog or the gitlab notifications
2020-02-16 11:20:48 <mps> Cogitri: and milestone is added
2020-02-16 11:21:58 <mps> hmm, forgot 'think' word in 'I don't this is needed' => I don't think this is needed
2020-02-16 11:30:55 <nmeum> _ikke_: just send a reply to the ML thread you linked yesterday. maybe fabled will reply there...
2020-02-16 11:38:14 <clandmeter> nmeum: why would it be apk-new?
2020-02-16 11:40:08 <clandmeter> _ikke_: is abuild.conf locally modified?
2020-02-16 11:40:08 <nmeum> clandmeter: I was under the impression that some builders have modified /etc/abuild.conf files. Previously, some builders had -l24 added to MAKEFLAGS for instance https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10665
2020-02-16 11:43:44 <clandmeter> I'm not sure how ncopa manages those files
2020-02-16 11:44:05 <clandmeter> I can only check for non x86
2020-02-16 12:03:43 <_ikke_> clandmeter: afaik the yare
2020-02-16 12:03:45 <_ikke_> they are
2020-02-16 12:03:55 <clandmeter> I remember ncopa tried to prevent modifying those files so it's easier to upgrade. Not sure about abuild.conf
2020-02-16 12:04:23 <clandmeter> Easier to modify user abuild.conf
2020-02-16 12:05:32 <_ikke_> But harder to troubleshoot if some settings are in user abuild.conf and others in system abuild.con
2020-02-16 12:05:58 <clandmeter> Why?
2020-02-16 12:06:29 <clandmeter> You debug the env
2020-02-16 12:06:35 <_ikke_> Because you have to remember that settings can come from either of those files
2020-02-16 12:06:44 <_ikke_> env does not tell you where it is coming from
2020-02-16 12:07:12 <clandmeter> Sorry I don't see that as an issue
2020-02-16 12:07:46 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10665
2020-02-16 12:08:17 <clandmeter> I read it
2020-02-16 12:08:35 <_ikke_> took us long enough to figure it came from /etc/abuild.conf
2020-02-16 12:09:12 <_ikke_> I would never have thought to even look at user abuild.conf
2020-02-16 12:09:22 <clandmeter> Is that a config or a user issue?
2020-02-16 12:09:37 <clandmeter> We even do that in ci
2020-02-16 12:12:34 <clandmeter> Exposing env could be dangerous
2020-02-16 12:13:15 <nmeum> do we store confidental data in the environment of the buildozer user? because if so: that can also be extracted by package buildsystems
2020-02-16 12:13:21 <_ikke_> afaik we dont
2020-02-16 12:13:53 <clandmeter> We don't
2020-02-16 12:14:53 <clandmeter> I'm just careful with official builders
2020-02-16 12:15:42 <clandmeter> nmeum: in our current setup I don't think it's easy to allow ssh to or builders
2020-02-16 12:15:53 <nmeum> yeah, I thought so
2020-02-16 12:15:56 <nmeum> just an utopian idea of mine
2020-02-16 12:16:15 <clandmeter> In a container it should be easy
2020-02-16 12:19:50 <clandmeter> I was going to implement such feature in dabuild. Where you can reuse a previous container and debug or restart the build.
2020-02-16 12:20:13 <nmeum> what's dabuild?
2020-02-16 12:20:28 <clandmeter> Docker abuild
2020-02-16 12:20:51 <nmeum> ah
2020-02-16 12:21:01 <_ikke_> gitlab also offers something ike that
2020-02-16 12:21:03 <_ikke_> like that
2020-02-16 12:22:03 <clandmeter> https://gitlab.alpinelinux.org/alpine/docker-abuild/blob/master/README.md
2020-02-16 12:24:05 <clandmeter> _ikke_: link?
2020-02-16 12:25:14 <_ikke_> https://docs.gitlab.com/ee/ci/interactive_web_terminal/
2020-02-16 12:25:41 <_ikke_> Does not work well with docker runners apparently (because the container is shutdown)
2020-02-16 12:26:01 <nmeum> can we just activate that for the ci?
2020-02-16 12:26:22 <_ikke_> We need to properly setup the runners for that
2020-02-16 12:27:17 <nmeum> right. I ocassionally encounter build failures which cannot be reproduced locally and not on the offical builders but on the ci, that interactive web terminal would allow debugging those
2020-02-16 12:27:35 <_ikke_> Yes
2020-02-16 12:27:42 <nmeum> would also be nice to debug build failures on arches one does not directly have access to
2020-02-16 12:28:10 <nmeum> though I would prefer real ssh access over a web terminal but a web terminal is still better than having no access at all (:
2020-02-16 12:28:15 <_ikke_> This still applies though: https://gitlab.com/gitlab-org/gitlab-runner/issues/3605
2020-02-16 12:28:54 <_ikke_> Would be nice if we could have some ssh -> docker container interface
2020-02-16 12:30:12 <_ikke_> Maybe it's not even that hard to do so
2020-02-16 12:31:05 <nmeum> don't know enough about docker, so no idea how difficult this would be but it would be extremly nice to have something like that
2020-02-16 12:32:12 <_ikke_> I think ssh authorized keys with a forced command to run a container with an interactive shell
2020-02-16 12:32:48 <_ikke_> let me try to see if it works
2020-02-16 12:34:54 <_ikke_> ssh root@ppc64le-ci.alpinelinux.org -t 'docker run --rm -it alpinelinux/build-base'
2020-02-16 12:34:59 <_ikke_> that works
2020-02-16 12:35:40 <_ikke_> clandmeter: any opinion in offering something like that? ^
2020-02-16 12:35:57 <_ikke_> ofcourse, it would have a dedicated user that can only execute that command
2020-02-16 12:37:15 <clandmeter> Need to think about it
2020-02-16 12:37:18 <nmeum> drew explained in a blog post how you can get sshd to just execute commands like that on login https://drewdevault.com/2019/09/02/Interactive-SSH-programs.html
2020-02-16 12:37:21 <nmeum> just fyi
2020-02-16 12:37:48 <clandmeter> It's not a solution to our current problem
2020-02-16 12:37:55 <clandmeter> The env is different
2020-02-16 12:38:04 <nmeum> sure
2020-02-16 12:38:17 <_ikke_> this is pure for CI / testing builds on arches you don't have access to
2020-02-16 12:38:33 <_ikke_> not for finding out why builds fail on the builders
2020-02-16 12:38:38 <clandmeter> We provide containers
2020-02-16 12:38:41 <nmeum> ah
2020-02-16 12:39:39 <_ikke_> nmeum: yes, ssh forced commands is what I was thinking of
2020-02-16 12:39:45 <clandmeter> If there issue is related to lxc you won't find it in docker
2020-02-16 12:42:23 <clandmeter> If any of our devs need a container on different arch, the can request it.
2020-02-16 12:46:20 <mps> Cogitri: sorry, I didn't explained this [3.11] (and other releases) tags
2020-02-16 12:47:14 <mps> we discussed this some months ago and conclusion (informal, as usual on irc) was that we should not use them
2020-02-16 12:53:53 <Cogitri> Hm, but I feel like it makes it easier to navigate the MRs when you have a big fat [$stable-branch] in the title
2020-02-16 12:54:43 <_ikke_> What about labels?
2020-02-16 12:55:17 <Cogitri> That would work too, but I guess the milestone works too at that point
2020-02-16 12:56:25 <_ikke_> Milestones have a due-date, don't think that works for ongoing development
2020-02-16 12:57:03 <_ikke_> For security issues it might make sense: this should be merged before the next minor release
2020-02-16 12:57:16 <mps> _ikke_: yes, we talked about adding labels but without conclusion about them
2020-02-16 12:57:54 <_ikke_> It already does show the target branch, but not very emphasized
2020-02-16 12:57:59 <mps> but security labels should be visible publicly
2020-02-16 12:58:19 <mps> should not*
2020-02-16 12:59:27 <_ikke_> Issues can be marked confidential
2020-02-16 12:59:29 <_ikke_> (and are)
2020-02-16 12:59:41 <_ikke_> Once merged, the they can be made public
2020-02-16 13:00:11 <_ikke_> There is no such thing for merge requests though
2020-02-16 13:00:45 <mps> yes, but would be nice
2020-02-16 13:01:47 <_ikke_> milestones are meant for grouping issues which should make a certain release
2020-02-16 13:02:01 <_ikke_> So for example ncopa can look at a milestone to find out what needs to be done still
2020-02-16 13:02:21 <_ikke_> but that does not include most merge requests
2020-02-16 13:04:49 <mps> I think all MRs for previous releases should have milestones
2020-02-16 13:44:12 <mps> uhm, this connman upgrade was fast
2020-02-16 13:45:05 <_ikke_> mps: I think I agree, but at some point, that milestone should be 'frozen', not added to indefinitely
2020-02-16 13:46:14 <mps> _ikke_: I agree, they should have some upper limit
2020-02-16 13:46:34 <_ikke_> It depends on the release cycle
2020-02-16 13:47:02 <mps> if it can be applied to one milestone and work on it, doesn't mean it will work on some of the next
2020-02-16 13:48:14 <mps> maybe we should have some planned minor release dates
2020-02-16 13:53:48 <_ikke_> I need to backport the CI fixes for 3.11
2020-02-16 13:56:35 <_ikke_> mps: sorry to ask you again, but could you rebase your dovecot MR for 3.11?
2020-02-16 13:57:26 <mps> it is already pushed
2020-02-16 13:57:50 <_ikke_> ok, the CI job is still running
2020-02-16 13:57:55 <_ikke_> on s390x
2020-02-16 13:58:00 <mps> ah
2020-02-16 13:58:24 <mps> so, I can push it to mps on gitlab?
2020-02-16 13:58:36 <mps> with --force ?
2020-02-16 13:58:41 <_ikke_> yes
2020-02-16 13:58:58 <mps> ok
2020-02-16 14:00:56 <mps> git push --force mps => Everything up-to-date
2020-02-16 14:03:18 <mps> I 'hacked' commit msg, looks like it works
2020-02-16 14:03:59 <mps> hmm, no. this will be new MR
2020-02-16 14:04:54 <mps> reopen maybe will work
2020-02-16 14:08:25 <mps> _ikke_: managed to restart it somehow (don't ask how :) )
2020-02-16 18:08:28 <nmeum> north1: I know this nitpicking but imho be useful to also include a reason for setting CARGO_HOME / GOCACHE in the commits messages of https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/25
2020-02-16 18:08:36 <nmeum> s/this/this is/
2020-02-16 18:08:36 <alpine-meetbot> nmeum meant to say: north1: I know this is nitpicking but imho be useful to also include a reason for setting CARGO_HOME / GOCACHE in the commits messages of https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/25
2020-02-16 18:14:11 <vkrishn> hi, could someone help, as what pkgs are needed to generate .png file from 'apk dot' command ?
2020-02-16 18:23:23 <nmeum> vkrishn: apk dot vim | dot -Tpng -o vim.png
2020-02-16 18:24:50 <vkrishn> nmeum: yes, but what pkgs to install ? "apk add graphviz ... ?"
2020-02-16 18:25:03 <nmeum> yes, graphviz
2020-02-16 18:25:19 <vkrishn> I tried above in v3.10.2(i386) install but cannot get to fonts ok
2020-02-16 18:25:38 <vkrishn> the* fonts
2020-02-16 18:26:39 <vkrishn> try https://tpaste.us/Yp4w
2020-02-16 18:27:02 <vkrishn> save the file to a.dot, then dot -Tpng a.dot -o a.png
2020-02-16 18:30:59 <vkrishn> this is what I get https://pasteboard.co/IUZ2WH3.png
2020-02-16 18:44:26 <north1> @nmeum done
2020-02-16 18:46:10 <north1> Thanks for merging cmake out of source
2020-02-16 18:47:52 <Cogitri> vkrishn: See #11144
2020-02-16 18:52:16 <vkrishn> ok, thanks
2020-02-16 19:08:56 <kaey> guys GOCACHE is a build cache, not src
2020-02-16 19:09:50 <kaey> if you want to cache go packages the best way is to set up goproxy somewhere in alpine infra
2020-02-16 19:10:10 <kaey> and use by setting GOPROXY in abuild.conf
2020-02-16 19:11:10 <kaey> https://github.com/goproxy/goproxy this is example implementation. dont know how good it is though
2020-02-16 20:49:42 <_ikke_> north1: ping
2020-02-16 20:50:01 <north1> pong
2020-02-16 20:50:32 <_ikke_> any idea how we could include a check to verify that when someone sets CFLAGS, it also includes $CFLAGS?
2020-02-16 20:50:43 <_ikke_> Not sure that's possible with regular expressions
2020-02-16 20:51:06 <_ikke_> so CFLAGS="-O3" is wrong, CFLAGS="$CFLAGS -O3" is good
2020-02-16 20:51:31 <north1> hmm, sed -r -e 's|CFLAGS="(.*)"|\1|' | grep -F '$CFLAGS'
2020-02-16 20:51:37 <north1> that won't work on multiline CFLAGS though
2020-02-16 20:52:31 <_ikke_> hmm, right
2020-02-16 20:54:47 <_ikke_> I don't see any example of multiline CFLAGS in aports atm
2020-02-16 20:57:05 <_ikke_> Did you got my note re (ba)sh heredocs btw?
2020-02-16 20:57:19 <north1> I did but i didn't understand what went wrong
2020-02-16 20:57:27 <_ikke_> heredocs eat all initial tabs
2020-02-16 20:57:37 <_ikke_> when you use <<-EOF
2020-02-16 20:57:52 <_ikke_> so if you indent a function with tabs in heredocs, the indentation is eaten
2020-02-16 20:58:19 <north1> oh
2020-02-16 20:58:29 <north1> small detour: busybox grep -o -n 'CFLAGS=".*$CFLAGS.*"'
2020-02-16 20:59:57 <_ikke_> so in our atools test suite, a lot of examples are kind of broken (though mosts tests don't rely on indentation)
2020-02-16 21:00:42 <_ikke_> But one of the checks does make a difference
2020-02-16 21:01:09 <_ikke_> Would it be an option to use spaces for indentation, and then run unexpand to convert them to tabs again?
2020-02-16 21:01:35 <north1> Out of the top of my head i have no clue if that works
2020-02-16 21:01:41 <_ikke_> I tried it, it did
2020-02-16 21:01:50 <north1> so yeah it is an option
2020-02-16 21:02:02 <_ikke_> <<-EOF | unexpand -t4 --first-only >$apkbuild
2020-02-16 21:02:10 <_ikke_> (I created a function for the unexpand command)
2020-02-16 21:02:23 <north1> --first-only seems to be GNU only
2020-02-16 21:02:26 <north1> and busybox has unexpand
2020-02-16 21:03:35 <_ikke_> unexpand without --first-only could add tabs where they shouldn't though (because the whitespace turns out to align with a tabstop)
2020-02-16 21:06:13 <north1> i see
2020-02-16 21:06:35 <Cogitri> How does provider priority work again?
2020-02-16 21:06:55 <north1> @ikke so can we have this unexpand function in our tests ?
2020-02-16 21:07:15 <Cogitri> I'm working on the libsecret situtation (any keyring can provide the libsecret dbus API so we can't depend on one of them), but now the builders can't decide what provider to choose
2020-02-16 21:07:17 <_ikke_> "A numeric value which is used by apk-tools to break ties when choosing a virtual package to satisfy a dependency. Higher values have higher priority. The primary use case is to specify the primary package that satisfies a virtual "
2020-02-16 21:07:37 <Cogitri> Ah, so it'll choose what has the highest value by default
2020-02-16 21:07:39 <mps> _ikke_: https://linuxhint.com/bash-heredoc-tutorial/
2020-02-16 21:07:55 <mps> 'HereDoc uses β€˜β€“β€˜ symbol to suppress any tab space from each line of heredoc text'
2020-02-16 21:08:15 <Cogitri> What's the default?
2020-02-16 21:08:42 <_ikke_> mps: yes, that's the issue
2020-02-16 21:09:27 <_ikke_> mps: See for example this: https://gitlab.alpinelinux.org/Leo/atools/blob/master/tests/apkbuild-lint.bats#L36
2020-02-16 21:09:35 <_ikke_> Cogitri: I don't know what the default is
2020-02-16 21:10:39 <_ikke_> mps: the first indentation level is part of the test case
2020-02-16 21:10:54 <mps> ah, I see
2020-02-16 21:11:35 <mps> I misunderstood your issue
2020-02-16 21:12:54 <_ikke_> no worry
2020-02-16 21:14:34 <_ikke_> north1: http://tpaste.us/vJV5
2020-02-16 21:18:24 <north1> Oh, if we do that won't we add a dependency on coreutils ?
2020-02-16 21:18:43 <north1> Some are opposed to that, there is also an issue for removing the dependency on GNU Grep
2020-02-16 21:18:46 <_ikke_> yes, I'm looking for an alternative now
2020-02-16 21:18:51 <_ikke_> was just to show the idea
2020-02-16 21:19:30 <north1> Yes, when you said you made a function i thought you made a function that emulated GNU's unexpand's --first-only
2020-02-16 21:20:41 <_ikke_> Quite anoying that bb does not implement --first-only
2020-02-16 21:20:48 <_ikke_> while you could argue it's broken without it
2020-02-16 21:21:57 <_ikke_> hmm
2020-02-16 21:21:59 <_ikke_> " -f      Convert only leading blanks"
2020-02-16 21:22:46 <_ikke_> so now we need to figure out whether coreutils unexpand is used or bb unexpand
2020-02-16 21:24:28 <_ikke_> never knew coreutils was a multicall binary as well
2020-02-16 21:25:41 <north1> It can be built as such
2020-02-16 21:26:07 <north1> and it is built as such in AL, nice
2020-02-16 21:26:58 <_ikke_> yeah, that's how I found out
2020-02-16 21:27:02 <_ikke_> north1: What about: http://tpaste.us/Qnaz
2020-02-16 21:28:51 <north1> I think we can just call busybox unexpand directly
2020-02-16 21:29:17 <_ikke_> north1: would be nice if it also works without bb present
2020-02-16 21:29:37 <north1> Is there a reason to not have bb ? i think bb is an essential part of AL
2020-02-16 21:29:56 <_ikke_> some people run atools outside of AL
2020-02-16 21:30:09 <north1> hmmm, makes sense
2020-02-16 21:30:35 <north1> yeah sounds good, i only run it in AL and expect it to be that way but if people want to put support for not having bb in it i don't mind.
2020-02-16 21:31:06 <_ikke_> Yeah, I also run in AL, but I test atools outside of AL
2020-02-16 21:47:33 <_ikke_> grep -o -n -e 'CFLAGS="[^"]*"' APKBUILD_CFLAGS | sed -r -e 's|CFLAGS="([^"]*)"|\1|' | grep -vF '$CFLAGS'
2020-02-16 21:58:53 <north1> woah, that is complicated
2020-02-16 22:02:33 <_ikke_> improvements welcome :)
2020-02-16 22:04:07 <north1> Best case would have it in a single call so we can use the scan function
2020-02-16 22:04:34 <_ikke_> Yes, but I cannot think how to check if $CFLAGS is missing that way
2020-02-16 22:04:53 <north1> your 3 calls handle multi-line ?
2020-02-16 22:04:56 <_ikke_> no
2020-02-16 22:04:57 <mps> use perl regex, Luke :)
2020-02-16 22:05:09 <north1> @mps not available on busybox grep
2020-02-16 22:05:13 <north1> we don't want to depend on GNU grep
2020-02-16 22:05:16 <mps> I know
2020-02-16 22:05:44 <mps> but I'm pretending that I'm master Yoda now
2020-02-16 22:05:48 <north1> @_ikke_ 'CFLAGS=".*$CFLAGS.*"' is a good start i think
2020-02-16 22:06:00 <_ikke_> doesn't that check *if* it's present?
2020-02-16 22:06:08 <_ikke_> ie, the good case
2020-02-16 22:06:21 <north1> it returns nothing if it is not present
2020-02-16 22:06:21 <_ikke_> That won't match if they forgot $CFLAGS
2020-02-16 22:06:25 <_ikke_> yes
2020-02-16 22:06:32 <_ikke_> but those cases we want to catch
2020-02-16 22:06:37 <_ikke_> where it's not present
2020-02-16 22:07:30 <_ikke_> I could just get rid of the sed though
2020-02-16 22:07:50 <_ikke_> grep -oHn 'CFLAGS="[^"]*"' APKBUILD_CFLAGS | grep -vF '$CFLAGS' | sed "s/^\([^:]*:[^:]*:\)\(.*\)/MC:[AL33]:\1CFLAGS should not be overwritten/"
2020-02-16 22:08:17 <north1> grep -n "CFLAGS=".*" | grep -F -v '$CFLAGS'
2020-02-16 22:08:31 <_ikke_> yes
2020-02-16 22:08:48 <north1> @algitbot s/-n/-n -o/
2020-02-16 22:08:57 <_ikke_> you also need -H to get the filename
2020-02-16 22:09:21 <north1> yeah yours with sed looks good enough to me
2020-02-16 22:37:33 <nmeum> north1: merged the CARGO_HOME abuild patch, the go thing should probably be discussed separatly
2020-02-16 22:37:41 <nmeum> also not sure how the go thing really works atm
2020-02-16 22:37:46 <north1> Alright
2020-02-16 22:38:14 <nmeum> should i close the PR in the meantime?
2020-02-16 22:38:55 <_ikke_> north1: https://gitlab.alpinelinux.org/Leo/atools/merge_requests/26
2020-02-16 22:47:38 <north1> @nmeum sure, I won't be working on it
2020-02-16 22:48:03 <north1> @_ikke_ am out eating, will check later
2020-02-16 22:48:12 <_ikke_> sure, np
2020-02-16 22:48:53 <north1> Might want to make it also for CXXFLAGS and FFLAGS (Fortran)
2020-02-16 23:05:19 <kaey> nmeum: i can explain tomorrow how go works and point to relevant docs
2020-02-16 23:09:51 <nmeum> kaey: that would be more than welcome, would be useful to know if it is possible to cache dependency downloads somehow without changing GOPATH so we can don't need to redownload the same dependency for each new abuild invocation
2020-02-16 23:10:23 <nmeum> s/can//
2020-02-16 23:10:23 <alpine-meetbot> nmeum meant to say: kaey: that would be more than welcome, would be useful to know if it is possible to cache dependency downloads somehow without changing GOPATH so we  don't need to redownload the same dependency for each new abuild invocation
2020-02-17 04:58:56 <maxice8> @Cogitri https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0#set_CARGO_HOME_to_cache_dependencies_of_rust_packages please write more here
2020-02-17 06:00:52 <Cogitri> Not sure if that's so significant
2020-02-17 08:40:34 <vkrishn> why those ambiguous files keep appearing in distfiles !
2020-02-17 08:40:50 <vkrishn> now there is Makefile.in, ah!
2020-02-17 08:50:04 <vkrishn> few more, https://tpaste.us/onVq
2020-02-17 08:50:30 <vkrishn> checked in v3.11/
2020-02-17 08:54:18 <mps> vkrishn: /var/cache/distfiles ?
2020-02-17 08:54:56 <vkrishn> yes, if you build full main, but this is http://distfiles.alpinelinux.org/distfiles/v3.11/
2020-02-17 08:55:23 <mps> wrong source in APKBUILDs
2020-02-17 08:55:44 <vkrishn> this is /var/cache/distfiles for buildozer
2020-02-17 08:56:17 <mps> wherever
2020-02-17 08:57:01 <vkrishn> source is ok, only needs renaming after download
2020-02-17 08:57:04 <mps> it is not important where they are, these source variables need to be rewritten
2020-02-17 08:57:55 <mps> source="pkgname-$pkgve.tar.gz::rear url"
2020-02-17 08:58:18 <mps> source="pkgname-$pkgver.tar.gz::rear url"
2020-02-17 08:58:29 <mps> (bad keyboard)
2020-02-17 08:58:35 <vkrishn> yes
2020-02-17 09:00:41 <mps> this rewriting is not in APKBUILD man page
2020-02-17 09:01:12 <mps> local rename, bah
2020-02-17 09:04:55 <clandmeter> im doing maintenance on the x86* runners
2020-02-17 09:38:27 <vkrishn> for those who want to read alpine issues in terminal, https://tpaste.us/jx85
2020-02-17 09:45:03 <mps> vkrishn: apk add lab, issues and MR. view, list etc
2020-02-17 09:45:35 <mps> anyway, your script is also useful
2020-02-17 09:47:42 <mps> paired with json_pp
2020-02-17 09:48:02 <vkrishn> new in apk v3 ?
2020-02-17 09:49:06 <mps> no, lab is separate pkg
2020-02-17 09:49:50 <vkrishn> ok, I am still on v3.10.x
2020-02-17 09:50:26 <mps> upgrade :)
2020-02-17 09:50:35 <mps> or backport it
2020-02-17 09:50:39 <vkrishn> ok its in testing
2020-02-17 10:10:00 <vkrishn> and it "require configured GitLab account with SSH keys"
2020-02-17 10:10:56 <mps> hmm, yes. I thought you have account
2020-02-17 10:10:58 <vkrishn> will stick with 'api' for viewing the issue
2020-02-17 10:11:46 <vkrishn> yes, I have can login gitlab
2020-02-17 10:12:10 <vkrishn> just trying to avoid 'golang'
2020-02-17 10:12:20 <mps> ask north1, he have some tools which uses api
2020-02-17 10:12:26 <vkrishn> and with api, you can do it from any OS
2020-02-17 10:12:40 <mps> agree fully
2020-02-17 10:12:46 <vkrishn> ok
2020-02-17 10:13:17 <mps> if i have time I would make something in perl
2020-02-17 10:13:33 <mps> true cross platform :)
2020-02-17 10:33:06 <fcolista> any plan to upgrade to qt5 5.14 ?
2020-02-17 11:49:52 <Cogitri> Would be nice to upgrade to it, especially now that Qt isn't going to support LTS for us anymore anyway
2020-02-17 11:50:20 <Cogitri> PureTryOut: Do we need to sync up KDE and Qt bumps or something?
2020-02-17 11:50:40 <Cogitri> (Or maybe you'd even be the one who does the bump? I don't really know Qt at all)
2020-02-17 11:51:11 <PureTryOut[m]> Not sure actually. I'm pretty sure at least kwin should be bumped but I'm not sure about the rest
2020-02-17 11:52:27 <PureTryOut[m]> I would say "let's test it"
2020-02-17 11:52:41 <PureTryOut[m]> I do agree that it would be great to upgrade Qt from 5.12.5
2020-02-17 11:53:09 <PureTryOut[m]> "let's test it" as in make a MR that upgrades Qt, I'll build and install the packages and try it out.
2020-02-17 11:57:25 <Cogitri> Uhhh, I didn't mean to volunteer for upgrading Qt :P
2020-02-17 12:04:48 <_ikke_> It sure did look like you did :P
2020-02-17 12:12:53 <mps> upgrade QT, other have to fix rest
2020-02-17 12:28:19 <PureTryOut[m]> Well I didn't say you would have to do it lol. Just "someone else than me" as I'm probably not the most knowledgeable person for this for when something breaks
2020-02-17 12:43:40 <Cogitri> Well, I guess I can look into it, but the private API Qt uses isn't fun to fix
2020-02-17 12:50:28 <fcolista> what's the ETA for 3.12 ?
2020-02-17 12:56:18 <_ikke_> I think May, right?
2020-02-17 12:56:37 <_ikke_> Yes
2020-02-17 12:57:25 <fcolista> ok
2020-02-17 12:57:35 <fcolista> so we have time to upgrade qt5 to 14 for 3.12
2020-02-17 12:57:40 <fcolista> *5.14
2020-02-17 12:58:11 <clandmeter> fcolista: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-02-17 12:59:01 <fcolista> am I blind, or is not written 3.12 ?
2020-02-17 12:59:11 <_ikke_> Correct, because it's not released yet
2020-02-17 12:59:18 <_ikke_> but it's basically every 6 months
2020-02-17 12:59:25 <_ikke_> May and November
2020-02-17 13:00:03 <fcolista> basically when 3.8 becomes unsupported
2020-02-17 13:00:20 <_ikke_> yes, they're kind of coupled
2020-02-17 13:00:35 <fcolista> ok. Thx!
2020-02-17 13:00:36 <_ikke_> When 3.12 is released, 3.8 is no longer supported
2020-02-17 13:07:54 <clandmeter> the idea is to provide this info on our www
2020-02-17 13:08:09 <clandmeter> when we find time...
2020-02-17 15:03:18 <minecrell> fabled: I just realized that the description of my HOSTCC MR was not entirely correct. It works fine, but we actually end up no longer setting HOSTCC for the kernel build. The kernel Makefile contains "HOSTCC = gcc" and apparently that is only replaced by explicitly overriding it on the command line (i.e. make HOSTCC=...), not from the environment
2020-02-17 15:03:18 <minecrell> variable.
2020-02-17 15:03:18 <minecrell> Nevertheless, it should not be needed for Alpine because the default ("gcc"), without any prefix should be the host compiler we want. And as I mentioned in the MR I tested that cross compilation of linux-lts works fine.
2020-02-17 15:03:20 <minecrell> just as FYI :)
2020-02-17 15:38:47 <mps> what about splitting ttf-liberation to two packages, ttf-liberation and ttf-liberation-narrow
2020-02-17 15:54:19 <dalias> mps, reason?
2020-02-17 15:58:44 <Ariadne> size reduction
2020-02-17 15:58:50 <Ariadne> most people don't need ttf-liberation-narrow
2020-02-17 16:06:58 <mps> yes, both, size and not much people use narrow
2020-02-17 16:18:05 <dalias> ah, i wasnt aware the size was significant
2020-02-17 16:18:23 <dalias> anyway it'll be annoying having to catch when the change happens and add the package manually to add it back..
2020-02-17 16:18:30 <dalias> but i can understand removal being appealing
2020-02-17 16:19:23 <mps> it is split upstream already
2020-02-17 16:28:20 <maxice8> Should the sysctl service fail to start if it fails to apply a file or just warn and continue with success ?
2020-02-17 16:29:16 <mps> warn
2020-02-17 16:30:19 <mps> some people run headless boxes
2020-02-17 16:30:45 <maxice8> ok
2020-02-17 16:31:01 <mps> you changed nick back?
2020-02-17 16:31:06 <maxice8> yes
2020-02-17 16:31:16 <maxice8> i managed to get the IRC bridge to correctly change my nick back
2020-02-17 16:31:35 <maxice8> i usually do !nick maxice8 but it changes 8 to any number between 0 and 255 for some reason
2020-02-17 16:31:36 <maxice8> really annoying
2020-02-17 16:32:29 <Cogitri> Is it possible for the sysctl service to error out but apply everything but the faulty entry?
2020-02-17 16:32:47 <Cogitri> IMHO an error is preferable so it shows up in rc-status
2020-02-17 16:33:06 <maxice8> that would require us to read every single file line by line, currently we call sysctl -p FILE
2020-02-17 16:33:25 <Cogitri> Ah, that's unfortunate
2020-02-17 16:51:03 <mps> maxice8: if I see correctly you added main/openrc/sysctl.initd in !3947
2020-02-17 16:51:32 <maxice8> yes
2020-02-17 16:51:51 <mps> what with sysfsconf.initd
2020-02-17 16:52:30 <maxice8> not related
2020-02-17 16:52:48 <mps> true
2020-02-17 16:54:45 <mps> you split it in more blocks
2020-02-17 16:54:55 <mps> for loops, I mean
2020-02-17 16:55:02 <maxice8> Yes
2020-02-17 16:56:13 <mps> this one: 'for f in /etc/sysctl.conf; do' for is not needed for one file
2020-02-17 16:56:43 <maxice8> that's true
2020-02-17 16:57:26 <mps> and do we have systcl conf files in /run?   'for f in /run/sysctl.d/*.conf; do'
2020-02-17 17:03:01 <mps> except that last (/run), it looks ok though look it is too chatty for _my_ preferences, veinfo's
2020-02-17 17:03:20 <maxice8> veinfo is only appears when EINFO_VERBOSE is set
2020-02-17 17:04:10 <mps> fine then
2020-02-17 17:05:04 <mps> only didn't know that sysctl confs are introduced to /run
2020-02-17 17:05:17 <mps> I think you know what you are doing
2020-02-17 17:06:08 <mps> my last suggestion is to also ask ncopa about this MR
2020-02-17 17:11:57 <Cogitri> clandmeter: Mind checking out !4169?
2020-02-17 17:56:02 <clandmeter> Cogitri: I'm not at phone
2020-02-17 17:56:09 <clandmeter> Lol
2020-02-17 17:56:13 <clandmeter> I'm on phone
2020-02-17 19:48:01 <_ikke_> nmeum: the check for overwriting CFLAGS/GOFLAGS has been merged in atools, will be part of the next release
2020-02-17 20:45:13 <clandmeter> mps: ping
2020-02-17 20:45:28 <mps> clandmeter: pong
2020-02-17 20:45:43 <clandmeter> i guess that lts MR is not merged yet?
2020-02-17 20:45:56 <mps> no, afaik
2020-02-17 20:46:17 <clandmeter> could you rebase it?
2020-02-17 20:46:23 <clandmeter> just to start CI again
2020-02-17 20:46:34 <clandmeter> I wonder if x86 CI is faster now
2020-02-17 20:46:38 <mps> I'm out of home right now, will be back in about 20 min
2020-02-17 20:46:49 <clandmeter> np, im not in a hurry
2020-02-17 20:46:55 <mps> ok
2020-02-17 20:47:14 <clandmeter> just compare build times for x86*
2020-02-17 20:47:32 <clandmeter> it has double the threads now
2020-02-17 20:47:48 <mps> your wish is my order :)
2020-02-17 20:55:27 <clandmeter> build to order :)
2020-02-17 20:57:04 <mps> s/order/command/
2020-02-17 20:57:04 <alpine-meetbot> mps meant to say: your wish is my command :)
2020-02-17 21:04:00 <nmeum> _ikke_: re GOFLAGS, great. the GOFLAGS changed was also ok'ed by timo https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4138#note_68440
2020-02-17 21:04:30 <_ikke_> Yeah, I read it
2020-02-17 21:04:34 <nmeum> however, he mentioned that it might be a good idea to set environment variables such as CFLAGS / GOFLAGS in functions.sh (in case abuild.conf isn't updated) not sure if I fully agree with that proposal though
2020-02-17 21:05:13 <nmeum> maybe merge it as is and discuss changes to functions.sh separatly?
2020-02-17 21:05:54 <_ikke_> I guess so
2020-02-17 21:06:02 <nmeum> currently we don't set any build configuration environment variables (e.g. CFLAGS) there
2020-02-17 21:06:04 <_ikke_> i'm just wondering why aarch64 CI fails
2020-02-17 21:06:14 <nmeum> that's a CI only fail
2020-02-17 21:06:23 <nmeum> mps tested it on his machine and it passed there
2020-02-17 21:06:26 <_ikke_> yes, understood, still wondering why:)
2020-02-17 21:07:10 <nmeum> it's that getrlimit error message, right?
2020-02-17 21:07:30 <_ikke_> yes, indeed
2020-02-17 21:07:45 <_ikke_> strange that it only fails on one arch
2020-02-17 21:07:53 <nmeum> > syscall_unix_test.go:332: Getrlimit: save failed: operation not permitted
2020-02-17 21:08:23 <nmeum> hm, the ERRORS section in getrlimit states the following for EINVAL:
2020-02-17 21:08:36 <nmeum> > The value specified in resource is not valid; or, for setrlimit() or prlimit(): rlim->rlim_cur was greater than rlim->rlim_max.
2020-02-17 21:09:06 <nmeum> is setrlimit used for the CI build process?
2020-02-17 21:09:23 <_ikke_> No, not that I'm aware of
2020-02-17 21:09:27 <nmeum> ah, it's not an EINVAL error it's an EPERMS error
2020-02-17 21:10:06 <nmeum> https://tpaste.us/5ER0 that's from the errors section of getrlimit
2020-02-17 21:11:41 <nmeum> the interactive web console we talked about yesterday would be nice for debugging this ;)
2020-02-17 21:11:46 <_ikke_> heh
2020-02-17 21:12:33 <nmeum> I guess just running the offending test in strace and checking how it invokes getrlimit would help getting to the root of this issue
2020-02-17 21:12:55 <_ikke_> Ok, let's see
2020-02-17 21:13:24 <nmeum> will probably be a bit annoying though to do that
2020-02-17 21:13:30 <nmeum> as go really issues an awful lot of system calls
2020-02-17 21:13:53 <_ikke_> You can filter syscals though
2020-02-17 21:14:20 <nmeum> right, you would still need to hope that the runtime doesn't use getrlimit though
2020-02-17 21:15:40 <nmeum> maybe as a first step: is the value of /proc/sys/fs/nr_open significantly lower on the aarch64 CI than on the other CIs?
2020-02-17 21:16:05 <_ikke_> 1048576
2020-02-17 21:16:07 <_ikke_> seems equal
2020-02-17 21:16:11 <nmeum> yep
2020-02-17 21:19:12 <_ikke_> I made your aports project public btw
2020-02-17 21:20:22 <nmeum> sure, there should be nothing secret in there
2020-02-17 21:20:57 <nmeum> you still planning on debugging this?
2020-02-17 21:21:01 <_ikke_> yes
2020-02-17 21:21:03 <_ikke_> working in it
2020-02-17 21:21:05 <_ikke_> on it
2020-02-17 21:21:18 <nmeum> ok, I will try to figure out if there is a way to only invoke the syscall test then
2020-02-17 21:21:34 <_ikke_> building go now to see if it triggers in the first place
2020-02-17 21:21:54 <_ikke_> but I guess it can take some time
2020-02-17 21:22:59 <nmeum> yeah, go takes a while to build
2020-02-17 21:24:46 <mps> clandmeter: build-x86 => Duration: 12 minutes 28 seconds
2020-02-17 21:25:08 <_ikke_> nmeum: should i still see cgo warnings?
2020-02-17 21:27:08 <nmeum> _ikke_: yes those are from the bootstraping process
2020-02-17 21:27:39 <_ikke_> ok
2020-02-17 21:27:49 <_ikke_> all tests passed, typical
2020-02-17 21:27:52 <nmeum> haha
2020-02-17 21:28:05 <mps> clandmeter: build-x86_64 => Duration: 16 minutes 4 seconds
2020-02-17 21:28:31 <mps> would be nice to have such machine here :)
2020-02-17 21:29:11 <clandmeter> mps: its faster as before?
2020-02-17 21:29:17 <clandmeter> the previous CI job
2020-02-17 21:29:22 <nmeum> _ikke_: you can only run the syscalls test using `PATH="$builddir/bin:$PATH" ./run.bash -no-rebuild -run "syscall"` btw
2020-02-17 21:29:26 <mps> iirc it slower
2020-02-17 21:29:39 <clandmeter> hmm
2020-02-17 21:29:42 <clandmeter> thats interesting
2020-02-17 21:30:18 <_ikke_> nmeum: ok, thanks
2020-02-17 21:30:26 <_ikke_> might be my mistake that it succeeded
2020-02-17 21:30:57 <mps> it was ppc64le '2020-02-15 15:15........... mps| heh, ppc64le built kernel in => Duration: 9 minutes 30 seconds'
2020-02-17 21:31:25 <mps> '2020-02-15 15:16....@clandmeter| what about x86?'
2020-02-17 21:31:39 <mps> '2020-02-15 15:17........... mps| 12:53'
2020-02-17 21:32:09 <clandmeter> could be that Cogitri pushed at the same time
2020-02-17 21:32:19 <clandmeter> i see activity from him
2020-02-17 21:32:38 <mps> so, I was wrong, now it is faster on x86 about 20 secs
2020-02-17 21:32:53 <_ikke_> nmeum: I was lazy and started the container with --privileged because I wanted to do a systrace, but that might circumvent the issue
2020-02-17 21:32:55 <mps> ban Cogitri from CI :)
2020-02-17 21:33:05 <_ikke_> I now started it with --cap-add SYS_PTRACE
2020-02-17 21:33:54 <clandmeter> i can retry the x86_64 build
2020-02-17 21:33:55 <mps> clandmeter: yes, I thought something else run in parallel
2020-02-17 21:34:13 <nmeum> _ikke_: I think it needs to be started with CAP_SYS_RESOURCE (see the EPERM error documentation in getrlimit)
2020-02-17 21:34:30 <nmeum> though suprising that it passes on the other arches then
2020-02-17 21:34:31 <_ikke_> I wanted to reproduce it :)
2020-02-17 21:34:38 <nmeum> ah
2020-02-17 21:35:00 <clandmeter> mps i pressed retry :)
2020-02-17 21:35:06 <mps> ok
2020-02-17 21:35:46 <_ikke_> nmeum: ok, got it
2020-02-17 21:35:56 <_ikke_> repro
2020-02-17 21:37:38 <Cogitri> mps: Oops :P
2020-02-17 21:37:52 <nmeum> _ikke_: so you can reproduce it?
2020-02-17 21:38:07 <_ikke_> yes
2020-02-17 21:38:16 <_ikke_> just trying to find the run.bash script
2020-02-17 21:38:18 <mps> Cogitri: it was joke
2020-02-17 21:38:25 <nmeum> _ikke_: src/run.bash iirc
2020-02-17 21:38:28 <Cogitri> Heh, I know ^^
2020-02-17 21:38:43 <nmeum> _ikke_: but just modify the check() if you want to run the tests, that's easier
2020-02-17 21:39:29 <nmeum> Cogitri: while you are here the termbox addition you pushed contains a binary waf upgrade is that really intended?
2020-02-17 21:39:37 <_ikke_> nmeum: ok, that works, still repro
2020-02-17 21:40:43 <Cogitri> nmeum: Huh, how did Gitlab display a diff count for a binary
2020-02-17 21:40:45 <_ikke_> nmeum: what strace output are we interested in?
2020-02-17 21:41:03 <_ikke_> nmeum: there is a lot :)
2020-02-17 21:41:59 <nmeum> Cogitri: well it's a git format patch but it contains binary changes if I am not mistaken, look at the last few modified lines
2020-02-17 21:42:14 <nmeum> _ikke_: yeah that's from the go runtime, as I said it does a lot of syscalls :)
2020-02-17 21:42:30 <nmeum> _ikke_: I guess just filter for getrlimit and see if that's sufficient?
2020-02-17 21:42:33 <_ikke_> ok
2020-02-17 21:42:36 <Cogitri> Yes, seems like that's some sort of gpg thingie?
2020-02-17 21:42:52 <Cogitri> The upstream binary also contains it: https://github.com/nsf/termbox/blob/master/waf#L168
2020-02-17 21:43:17 <nmeum> strange
2020-02-17 21:43:54 <_ikke_> just adding strace makes the test take ages apparently
2020-02-17 21:44:00 <nmeum> yep
2020-02-17 21:44:05 <_ikke_> the limit helps
2020-02-17 21:45:08 <_ikke_> 31689 getrlimit(RLIMIT_NOFILE, 0x40001376d8) = -1 EPERM (Operation not permitted)
2020-02-17 21:45:14 <nmeum> aha
2020-02-17 21:45:20 <nmeum> you found it
2020-02-17 21:45:48 <nmeum> ahahm
2020-02-17 21:46:20 <nmeum> I was hoping strace would pretty print the rlimit struct magically
2020-02-17 21:46:32 <Cogitri> Anyway, time to sleep for me, good luck with your debugging :)
2020-02-17 21:46:37 <_ikke_> o/
2020-02-17 21:46:40 <nmeum> thanks, sleep well :)
2020-02-17 21:47:59 <clandmeter> mps: finished
2020-02-17 21:48:07 <mps> yes
2020-02-17 21:48:14 <nmeum> _ikke_: is there any easy way to get further information about 0x40001376d8 just using strace?
2020-02-17 21:48:26 <mps> Duration: 12 minutes 27 seconds
2020-02-17 21:49:02 <clandmeter> ah thats not fair, x86 also runs on it but not now :)
2020-02-17 21:49:19 <clandmeter> i guess the speed is similar
2020-02-17 21:49:52 <mps> not big difference
2020-02-17 21:50:43 <_ikke_> nmeum: wondering how
2020-02-17 21:53:40 <nmeum> hmhm
2020-02-17 21:55:51 <nmeum> I guess debugging this further would require attaching a debugger
2020-02-17 21:55:59 <_ikke_> yeah, was already going that route
2020-02-17 21:56:45 <nmeum> not sure how that would work with go though
2020-02-17 21:57:22 <nmeum> the trail and error method would be finding out if the other CIs have any capabilities the aarch64 does not I guess …
2020-02-17 21:57:39 <nmeum> *trial
2020-02-17 22:05:30 <_ikke_> I don't think any docker ci hosts sets any capabilities for containers
2020-02-17 22:05:52 <nmeum> nod
2020-02-17 22:07:56 <nmeum> I am a bit out of ideas to be honest
2020-02-17 22:20:08 <nmeum> _ikke_: will go to sleep now, let me know if you find out more
2020-02-17 22:20:50 <_ikke_> 
ACTION too :)

2020-02-18 02:49:08 <maxice8> lots of CI builders are dead
2020-02-18 05:37:21 <_ikke_> hmm
2020-02-18 05:38:35 <_ikke_> maxice8: they might have been busy, they seem healthy now
2020-02-18 07:29:51 <mps> #11215 imo is not alpine issue and should be closed
2020-02-18 08:48:47 <AinNero> the openssl 8.2 release states that the ssh-rsa key algorithm (as it is used now) will be deprecated in the future
2020-02-18 08:48:55 <AinNero> still, today i got my first userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]
2020-02-18 08:49:57 <AinNero> ssh connect from OpenSSH_7.4p1 Debian-10+deb9u7 to OpenSSH_8.2p1 (alpine edge)
2020-02-18 08:53:37 <mps> AinNero: you mean openssh, not openssl ?
2020-02-18 08:53:45 <AinNero> yes.
2020-02-18 08:54:36 <mps> this is explained in release notes, and how to use it in such cases
2020-02-18 08:55:28 <mps> and lwn.net have long thread about this
2020-02-18 08:55:29 <AinNero>  * ssh(1), sshd(8): the above removal of "ssh-rsa" from the accepted CASignatureAlgorithms list.
2020-02-18 08:55:38 <AinNero> i think this is my usecase
2020-02-18 08:56:29 <mps> I'm on 'phone' now and can't remember from the head exact option how to overcome this
2020-02-18 08:58:00 <AinNero> i think ill have to rotate my ca key
2020-02-18 09:08:36 <danieli> yup, that's specific to SSH CAs, and it's probably the issue if you use one
2020-02-18 09:22:47 <_ikke_> danieli: o/
2020-02-18 10:08:22 <danieli> \o
2020-02-18 10:42:48 <nmeum> mps: yes, I wanted to add another comment to the issue you linked above but didn't get around to it yet
2020-02-18 11:03:36 <mps> nmeum: np, I didn't added comment (to tell that question is better for musl ML) there because I saw your comment
2020-02-18 11:08:49 <nmeum> mps: added my comment and closed it
2020-02-18 11:11:29 <mps> good :)
2020-02-18 11:39:34 <_ikke_> nmeum: running gdb on go doesn't seem to go as planned indeed
2020-02-18 11:40:26 <nmeum> _ikke_: yep, you need a go debugger but it might be easier to just find the getrlimit invocation by lcoking at the source
2020-02-18 11:40:31 <nmeum> currently busy with work, sorry
2020-02-18 11:41:24 <_ikke_> no worry
2020-02-18 14:42:32 <maxice8> Our /etc/sysctl.d/00-alpine.conf fails
2020-02-18 14:43:31 <maxice8> http://ix.io/2c2K
2020-02-18 14:43:42 <maxice8>  * Configuring kernel parameters ...sysctl: cannot stat /proc/sys/kernel/unprivileged_bpf_disabled: error code 2
2020-02-18 14:44:05 <_ikke_> nmeum: ^
2020-02-18 14:44:27 <nmeum> yep
2020-02-18 14:44:35 <nmeum> I already complained to the person who pushed this about it
2020-02-18 14:44:52 <nmeum> 4e286992d5ed751f6ca60eb18d77313bb0868513
2020-02-18 14:45:17 <maxice8> Maybe we should just ewarn  and consider it a success ?
2020-02-18 14:46:11 <nmeum> own my system it's just a warning not an error
2020-02-18 14:46:18 <nmeum> as in the: the openrc services doesn't fail
2020-02-18 14:47:02 <nmeum> anyway: I would personally like to get rid of this warning
2020-02-18 14:47:20 <_ikke_> AH, I misremembered, it was Ariadne who wanted that
2020-02-18 14:47:22 <maxice8> it is an error by sysctl, it is just ignored by the sysctl service
2020-02-18 14:47:23 <nmeum> don't like having arbitrary warnings output during the boot process
2020-02-18 14:47:33 <nmeum> yep
2020-02-18 14:48:13 <nmeum> I would just revert the commit but didn't hear back from ariadne why this was enabled in the first place
2020-02-18 14:53:04 <maxice8> I see
2020-02-18 14:53:40 <_ikke_> It's enabled to support executing services in a vrf in linux
2020-02-18 14:53:57 <_ikke_> ip vrf exec <program> requires ebpf
2020-02-18 14:54:34 <_ikke_> the sysctl is to make sure only root can execute bpf
2020-02-18 14:56:23 <mps> someone was to fast with this eBPF
2020-02-18 14:57:25 <maxice8> @mps !3947 i made it so sysctl .conf files in /usr/lib and /lib only warn when verbose and don't make the service error out
2020-02-18 14:58:04 <mps> maxice8: yes, I remember. I didn't want to say anything bad about you
2020-02-18 14:58:27 <_ikke_> does this error because people updated, but don't have an ebpf enabled kernel yet?
2020-02-18 14:58:40 <mps> I even don't know who pushed this change
2020-02-18 14:58:51 <mps> _ikke_: I think so
2020-02-18 14:59:04 <_ikke_> Ariadne, because she asked the mailing list, and no one complained, and some agreed
2020-02-18 14:59:19 <mps> I prepared patch for eBPF but waiting for 5.4.20 push to post it
2020-02-18 14:59:54 <mps> here is what I prepared for this http://tpaste.us/pKw4
2020-02-18 15:00:11 <mps> x86_64 only for now
2020-02-18 15:00:53 <mps> but it can be easily 'propagated' to other arches where it needs to applied
2020-02-18 15:02:09 <mps> maxice8: no worries, edge breaks and that is (well) ok sometimes
2020-02-18 15:03:03 <_ikke_> mps: But it's important that that sysctl is set to true
2020-02-18 15:03:17 <_ikke_> otherwise all users can access it
2020-02-18 15:03:51 <mps> true
2020-02-18 15:04:29 <_ikke_> So right now we have a little bit more noise, in exchange for better security
2020-02-18 15:04:41 <mps> but, looks like BDFL is busy these days
2020-02-18 15:04:55 <_ikke_> mps: He kind of is :)
2020-02-18 15:05:20 <_ikke_> He's enjoying some nice time off
2020-02-18 15:05:21 <maxice8> @mps i wasn't the one that pushed the 00-alpine.conf change.
2020-02-18 15:06:08 <mps> maxice8: well, I didn't told anywhere that you did, I told I don't know who pushed that change
2020-02-18 15:07:31 <mps> _ikke_: and I don't who can push complete kernel (out of tree modules and RPs kernel) upgrade except ncopa
2020-02-18 15:07:51 <mps> RPis*
2020-02-18 15:09:54 <_ikke_> The kernel change has not been pushed yet, except for the kernel that Ariadne maintains
2020-02-18 15:10:23 <mps> yes, I saw it
2020-02-18 15:28:06 <maxice8> So in the meantime it errors out but the current sysctl service just says 'OK' while my changes make it error out
2020-02-18 15:29:05 <_ikke_> This is a general issue
2020-02-18 15:41:56 <brawer> Hi all, I’m trying to package a project and wonder where the cmake files (for developers) should go; does Alpine Linux place them into /usr/lib/cmake or /usr/share/cmake? Currently this doesn’t always seem to be handled consistently; compare https://pkgs.alpinelinux.org/contents?file=*.cmake&path=&name=eigen-dev&branch=edge&repo=community&a...
2020-02-18 15:41:57 <brawer> with https://pkgs.alpinelinux.org/contents?file=*.cmake&path=&name=llvm8-dev&branch=edge&repo=main&arch=x...
2020-02-18 15:43:34 <maxice8> I think both have been made OK recently
2020-02-18 15:45:29 <maxice8> In the past /usr/share/cmake was ignored
2020-02-18 15:47:11 <brawer> Thank you!
2020-02-18 16:19:11 <wsinatra> maxice8: thanks for the merge!
2020-02-18 16:19:24 <maxice8> welcome, i did some minor changes
2020-02-18 16:21:23 <brawer> Actually, /usr/share/cmake doesn’t seem to work; filed a bug: https://gitlab.alpinelinux.org/alpine/aports/issues/11233
2020-02-18 16:21:36 <wsinatra> I appreciate it :)
2020-02-18 17:14:41 <Ariadne> the sysctl service should be adjusted to not error out if an unknown sysctl is found
2020-02-18 17:16:59 <Cogitri> maxice8: You broke docker-compose with the py3-idna upgrade
2020-02-18 17:18:03 <Cogitri> Oh actually it's py3-setuptools that broke I think
2020-02-18 17:18:17 <Ariadne> I will investigate fixing the sysctl service
2020-02-18 17:18:54 <Ariadne> as for the kernel, yes it is not yet done, I think mps has done some kernel work so I'll review it
2020-02-18 17:20:20 <Cogitri> Ah actually it's py3-requests that's broken by the py3-idna upgrade, so that breaks the majority of python packages I suppose
2020-02-18 17:20:58 <mps> Ariadne: here is what I prepared for this http://tpaste.us/pKw4
2020-02-18 17:21:18 <Ariadne> cool
2020-02-18 17:21:24 <mps> x86_64 only, for review
2020-02-18 17:21:54 <Ariadne> mps: looks good to me.  can you do the other archs?
2020-02-18 17:22:01 <mps> if you and ncopa agree we can add this to other arches where we need this
2020-02-18 17:22:09 <mps> eh :)
2020-02-18 17:22:21 <mps> we think same
2020-02-18 17:22:30 <Ariadne> well
2020-02-18 17:22:36 <Ariadne> I can call ncopa and ask
2020-02-18 17:22:40 <Ariadne> but I think it is fine
2020-02-18 17:22:47 <Ariadne> he hasn't said no :)
2020-02-18 17:23:12 <mps> I didn't created MR waiting first 5.4.20 to be pushed
2020-02-18 17:23:28 <Ariadne> just go ahead and bump to .20
2020-02-18 17:23:31 <Ariadne> I'll merge it
2020-02-18 17:23:51 <Ariadne> if ncopa is mad we can work it out later :)
2020-02-18 17:24:06 <mps> well, last time we discussed BPF he and I were against, few months ago iirc
2020-02-18 17:24:22 <dalias> what about bpf? :-p
2020-02-18 17:24:28 <Ariadne> that was unprivileged bpf
2020-02-18 17:24:37 <Ariadne> this is root only bpf
2020-02-18 17:24:41 <dalias> someone wants bpf added to kconfig?
2020-02-18 17:24:51 <Ariadne> yes
2020-02-18 17:24:53 <Ariadne> I do
2020-02-18 17:24:58 <Ariadne> for root only
2020-02-18 17:25:52 <mps> yes, despite I dislike whole idea, I think it is inevitable to enable it as Ariadne says
2020-02-18 17:26:07 <dalias> i dont even understand what's being switched? is there no bpf without it? or is this just switching on jit? iirc bpf was needed for seccomp to work but maybe i'm wrong
2020-02-18 17:26:32 <dalias> imo jit is pure useless attack surface...
2020-02-18 17:28:57 <mps> dalias: useless? I wonder do I understand it as 'usable attack surface'
2020-02-18 17:29:29 <dalias> ok, useless except to attackers :)
2020-02-18 17:29:37 <mps> hehe :D
2020-02-18 17:30:39 <mps> problem is VRF (Virtual Routing and Forwarding) need it
2020-02-18 17:30:41 <Ariadne> dalias: there is a lot of useful things bpf can do actually.
2020-02-18 17:31:16 <Ariadne> we can replace iptables with something that generates bpf bytecode, for example
2020-02-18 17:32:03 <dalias> can it be hard-disabled with sysctl?
2020-02-18 17:32:06 <Ariadne> yes
2020-02-18 17:32:16 <Ariadne> which is what alpine does by default now
2020-02-18 17:32:19 <dalias> if default is disabled i'm not strongly against
2020-02-18 17:32:20 <Ariadne> well
2020-02-18 17:32:29 <Ariadne> it can be restricted to root with sysctl
2020-02-18 17:32:45 <dalias> does that include root in namespace? :-p
2020-02-18 17:32:45 <Ariadne> which, in practical terms, removes the attack surface
2020-02-18 17:32:48 <Ariadne> yes
2020-02-18 17:32:52 <dalias> ....
2020-02-18 17:32:54 <dalias> then that's not root
2020-02-18 17:32:56 <dalias> it's all users
2020-02-18 17:32:59 <Ariadne> no
2020-02-18 17:33:01 <Ariadne> i mean
2020-02-18 17:33:08 <Ariadne> it does NOT include namespaces
2020-02-18 17:33:13 <Ariadne> if you do them properly
2020-02-18 17:33:19 <Ariadne> e.g. unprivileged namespaces
2020-02-18 17:34:32 <dalias> anyway how does this relate to seccomp bpf? because i thought that already worked unprivileged?
2020-02-18 17:34:51 <Ariadne> it doesn't related to seccomp bpf at all
2020-02-18 17:34:55 <Ariadne> seccomp bpf has its own syscall
2020-02-18 17:35:48 <dalias> and they don't use the same kernel component?
2020-02-18 17:43:41 <Ariadne> they do
2020-02-18 17:43:51 <Ariadne> this is about enabling the more generic bpf(2) syscall
2020-02-18 17:44:07 <Ariadne> which, we are doing, but only for root
2020-02-18 17:44:18 <Ariadne> (and root in privileged containers)
2020-02-18 17:45:14 <Ariadne> mps: anyway, link me to an MR that upgrades to .20 and enables eBPF and i'll merge it asap
2020-02-18 18:01:29 <nmeum> Ariadne: just FYI ncopa was explicitly against enabling BPF in the past https://gitlab.alpinelinux.org/alpine/aports/issues/7984#note_56725
2020-02-18 18:01:56 <Ariadne> i've read it
2020-02-18 18:02:07 <Ariadne> thank you for linking me to things i have already read
2020-02-18 18:02:23 <_ikke_> Ariadne: nmeum cannot know what you've read :)
2020-02-18 18:03:03 <dalias> i think merging this behind ncopa's back and challenging to revert is something that's probably going to blow up, regardless of merit of it...
2020-02-18 18:03:11 <nmeum> exactly
2020-02-18 18:03:30 <Ariadne> nobody is merging anything behind ncopa's back
2020-02-18 18:03:48 <Ariadne> i announced this change on the mailing list before ncopa went on holiday
2020-02-18 18:04:02 <mps> that is the reason I didn't posted it
2020-02-18 18:04:15 <Ariadne> and the design of this change
2020-02-18 18:04:21 <mps> Ariadne: we shouldn't do this in rush
2020-02-18 18:04:38 <Ariadne> okay
2020-02-18 18:04:40 <Ariadne> great
2020-02-18 18:04:44 <mps> we have enough time for next release
2020-02-18 18:04:50 <Ariadne> i will call ncopa right now
2020-02-18 18:05:59 <Ariadne> if that is how we want to do things
2020-02-18 18:06:11 <nmeum> why not wait until he returns from his holiday?
2020-02-18 18:06:22 <Ariadne> because i have things to do
2020-02-18 18:06:27 <mps> we can do all these changes in few days, I think
2020-02-18 18:06:27 <_ikke_> afaik, most of the security concerns around ebpf are when allowing it for unpriviliged users. Am I missing something there?
2020-02-18 18:07:18 <Ariadne> _ikke_: correct, which are resolved by the addition of the sysctl disabling unprivileged ebpf
2020-02-18 18:07:29 <Ariadne> but whatever
2020-02-18 18:07:33 <Ariadne> i am not going to debate this
2020-02-18 18:08:01 <nmeum> ?
2020-02-18 18:08:56 <mps> personally I dislike idea of the door through which can enter binary blobs, but I think we will have to enable BPF sooner or later
2020-02-18 18:09:07 <Ariadne> great
2020-02-18 18:09:12 <Ariadne> shalll we disable kernel module support
2020-02-18 18:09:22 <mps> hehe
2020-02-18 18:09:37 <mps> you are to fast
2020-02-18 18:09:42 <nmeum> openbsd actually did that for this reason
2020-02-18 18:09:43 <Ariadne> that is a door through which binary blobs can enter (see also: nvidia)
2020-02-18 18:09:54 <Ariadne> great
2020-02-18 18:09:56 <Ariadne> good for openbsd
2020-02-18 18:10:21 <Ariadne> did you know that we are not openbsd ?
2020-02-18 18:10:27 <mps> I wanted to add to my previous sentence, if we have to enable it we should do that in most possible way, as you proposed
2020-02-18 18:10:48 <nmeum> whow. what's up with your passive agressive vibes Ariadne?
2020-02-18 18:11:05 <Ariadne> nmeum: because i have shit to do, that is dependent on this being done
2020-02-18 18:12:32 <Ariadne> and that comment you link is NOT the smoking gun you think it is
2020-02-18 18:12:40 <Ariadne> what he is against is UNPRIVILEGED bpf
2020-02-18 18:12:49 <nmeum> I never intended it to be a smoking gun
2020-02-18 18:12:55 <nmeum> I don't have any opinion on bfp whatsoever
2020-02-18 18:13:02 <Ariadne> it does not matter if root can JIT spray their own kernel
2020-02-18 18:13:04 <nmeum> I just wanted to point out that he had an opinion on it in the past
2020-02-18 18:13:06 <nmeum> that's all
2020-02-18 18:13:06 <Ariadne> they have already rooted it
2020-02-18 18:13:12 <nmeum> it was just intended to be a friendly heads up
2020-02-18 18:13:24 <Ariadne> uh huh
2020-02-18 18:14:55 <Ariadne> anyway, i will just deal with all of this myself
2020-02-18 18:15:02 <Ariadne> and if ncopa is mad, i will deal with ncopa myself
2020-02-18 18:15:04 <Ariadne> simple as that
2020-02-18 18:15:17 <Ariadne> he wont be, because it does not change the security calculus at all, but okay
2020-02-18 18:16:25 <Ariadne> but the portrayal of this being some "behind the back" thing is bullshit
2020-02-18 18:19:40 <Ariadne> oh and by the way, yet another person is asking for this on the tracker as of yesterday
2020-02-18 18:19:45 <Ariadne> so fuck it
2020-02-18 18:19:50 <Ariadne> i will drop everything and deal with this myself
2020-02-18 18:26:27 <Ariadne> maxice8: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3947
2020-02-18 18:26:32 <Ariadne> maxice8: what is the current state of this?
2020-02-18 18:27:50 <maxice8> Needs to decide whether to error out prematurely when we fail to apply the configuration from a .conf file
2020-02-18 18:28:03 <maxice8> at the moment it will warn but continue for files in /usr/lib and /lib since they are distro/package provided configuration
2020-02-18 18:28:29 <maxice8> and error out on /etc/sysctl.conf  and /etc/sysctl.d/.conf because it is local admin configuration and /run/sysctl.d/.conf as well for the same-ish reasons
2020-02-18 18:29:09 <Ariadne> that seems like the best way to go
2020-02-18 18:29:26 <Ariadne> can you remove the now no longer needed patch i pointed out in 3947?
2020-02-18 18:30:23 <maxice8> Yeah sure
2020-02-18 18:31:13 <maxice8> I think the 0003 patch is already removed
2020-02-18 18:31:21 <maxice8> it says after the name of the file 'deleted'
2020-02-18 18:31:22 <Ariadne> it is in the MR
2020-02-18 18:31:28 <Ariadne> oh
2020-02-18 18:31:29 <Ariadne> i see
2020-02-18 18:31:31 <Ariadne> yes, it is
2020-02-18 18:31:35 <Ariadne> weird that it shows a diff then
2020-02-18 18:31:47 <maxice8> Yes it is weird, it shows an all minus (red) diff
2020-02-18 18:33:11 <Ariadne> maxice8: and 00-alpine.conf should be moved to /lib/sysctl.d/00-alpine.conf ?
2020-02-18 18:33:24 <maxice8> yes, i can add a commit to do it
2020-02-18 18:33:39 <Ariadne> perhaps it would be good to split 00-alpine.conf up
2020-02-18 18:33:44 <Ariadne> we can do that later
2020-02-18 18:34:01 <Ariadne> 3947 pushed
2020-02-18 18:34:06 <maxice8> ah ok
2020-02-18 18:34:11 <_ikke_> checksum failure
2020-02-18 18:34:26 <Ariadne> ....
2020-02-18 18:34:30 <maxice8> derp, i modified the files a bit
2020-02-18 18:34:31 <maxice8> sorry
2020-02-18 18:34:38 <maxice8> i'll push a fix
2020-02-18 18:34:49 <maxice8> done
2020-02-18 18:34:55 <Ariadne> i already fixed it
2020-02-18 18:34:58 <maxice8> ok not done, someone else pushed
2020-02-18 18:35:01 <_ikke_> hah
2020-02-18 18:35:22 <maxice8> after moving back to Brazil my git pushes have become noticeably slower than when i was in Germany
2020-02-18 18:35:29 <_ikke_> more latency
2020-02-18 18:35:33 <maxice8> yes
2020-02-18 18:35:52 <maxice8> I wasn't annoyed by it before moving to Germany, now it is super annoying.
2020-02-18 18:41:06 <Ariadne> and when does ncopa get back from his holiday anyway
2020-02-18 18:41:25 <clandmeter> i think in 2 weeks
2020-02-18 18:41:50 <Ariadne> that is too long
2020-02-18 18:41:59 <Ariadne> what timezone is he presently in
2020-02-18 18:43:19 <clandmeter> i would prefer not bothering him too much
2020-02-18 18:43:34 <clandmeter> is it soemthing we can solve?
2020-02-18 18:43:44 <clandmeter> sorry i have not beeing following much
2020-02-18 18:43:50 <clandmeter> im about to go into a meeting
2020-02-18 18:44:10 <_ikke_> Ariadne needs ebpf enabled
2020-02-18 18:44:23 <_ikke_> in the kernel
2020-02-18 18:44:25 <clandmeter> on the kernel side?
2020-02-18 18:44:28 <_ikke_> yes
2020-02-18 18:44:37 <Ariadne> yes we can solve it
2020-02-18 18:44:40 <Ariadne> and the design
2020-02-18 18:44:48 <clandmeter> you need it in edge?
2020-02-18 18:44:50 <Ariadne> resolves the issues ncopa had
2020-02-18 18:44:55 <Ariadne> but people are like
2020-02-18 18:45:01 <Ariadne> OOOOoOoOOOOoOOOOOooOOOo but NCOPA
2020-02-18 18:45:11 <Ariadne> and that is the sort of thing that really irritates me
2020-02-18 18:45:21 <clandmeter> well ncopa does kernels, this is why ppl say that.
2020-02-18 18:45:34 <Ariadne> yes, i know
2020-02-18 18:45:51 <Ariadne> however i am 99.9999999999999% certain the design of this change resolves his concern
2020-02-18 18:46:11 <clandmeter> if you bump kernel you need to also bump out of tree modules
2020-02-18 18:46:25 <Ariadne> yes i know
2020-02-18 18:46:30 <Ariadne> i have all the stuff to do it
2020-02-18 18:47:03 <Ariadne> but considering eBPF is restricted to root only
2020-02-18 18:47:15 <Ariadne> and you have to REBOOT YOUR SYSTEM to make it not restricted to root only
2020-02-18 18:47:43 <Ariadne> i am pretty sure this satisfactorily resolves the concern that eBPF can be used to root a kernel
2020-02-18 18:47:48 <Ariadne> considering by default you have to be root
2020-02-18 18:47:54 <Ariadne> to use the thing that can root a kernel
2020-02-18 18:48:18 <_ikke_> http://tpaste.us/WRON
2020-02-18 18:48:19 <Ariadne> everything else is reduced to "doctor, it hurts when i do this"
2020-02-18 18:48:25 <Ariadne> to which the answer is "don't do that"
2020-02-18 18:48:27 <_ikke_> apkbuilds which contain _kver
2020-02-18 18:48:40 <clandmeter> i would like to get ncopa's ack as he is the maintainer.
2020-02-18 18:48:51 <clandmeter> i can try get it today
2020-02-18 18:49:01 <clandmeter> would that be ok for you?
2020-02-18 18:49:12 <Ariadne> yes, that is fine
2020-02-18 18:49:22 <Ariadne> by all means, blow up his phone
2020-02-18 18:49:26 <Ariadne> or whatever you need to do
2020-02-18 18:49:56 <Ariadne> i don't want to blow his phone up and cause him to have a huge bill
2020-02-18 18:50:00 <Ariadne> if he is not in norway
2020-02-18 18:51:04 <Ariadne> there is the argument that
2020-02-18 18:51:10 <Ariadne> some service running as root
2020-02-18 18:51:17 <Ariadne> could have eBPF code in it
2020-02-18 18:51:24 <Ariadne> that could be manipulated by non-root user
2020-02-18 18:51:28 <Ariadne> to root the kernel
2020-02-18 18:51:33 <Ariadne> but i think this is a red herring really
2020-02-18 18:51:44 <Ariadne> because if you are running a service like that, you're already compromised anyway
2020-02-18 18:56:13 <Ariadne> in the meantime, i am preparing 5.4.20 bump and these changes
2020-02-18 18:58:23 <clandmeter> Ariadne: its ok go ahead
2020-02-18 18:58:35 <Ariadne> yes, because
2020-02-18 18:58:38 <Ariadne> i already discussed this
2020-02-18 18:58:52 <Ariadne> 89@*&(&@%&(*@%(*&&@%(*&9875
2020-02-18 18:59:06 <Ariadne> i do not appreciate being accused of doing shit behind peoples backs
2020-02-18 18:59:19 <_ikke_> Ariadne: please try to calm down a bit
2020-02-18 18:59:36 <Ariadne> i'm perfectly calm
2020-02-18 18:59:39 <Ariadne> this is all theatrics
2020-02-18 18:59:48 <Ariadne> haha just kidding
2020-02-18 19:00:05 <Ariadne> i actually did not appreciate that accusation
2020-02-18 19:00:17 <danieli> not this again
2020-02-18 19:00:34 <Ariadne> lol
2020-02-18 19:02:43 <maxice8> @Cogitri fixed py3-requests, sorry for the inconvenience
2020-02-18 19:03:01 <Ariadne> mps: actually i do think we should add a sysctl which locks down loading new kernel modules
2020-02-18 19:03:04 <Ariadne> mps: fwiw :)
2020-02-18 19:03:41 <Ariadne> mps: and i am open to extending the sysctl for bpf to have a similar full-disable mode
2020-02-18 19:07:11 <mps> Ariadne: 5.4 have lockdown option
2020-02-18 19:07:27 <Ariadne> neat
2020-02-18 19:07:33 <Ariadne> we should integrate that into alpine
2020-02-18 19:07:36 <Ariadne> i'll add it to my todo list
2020-02-18 19:07:53 <mps> we didn't enabled it because I forgot to mention it to ncopa
2020-02-18 19:08:13 <mps> it is in my todo list also
2020-02-18 19:08:17 <maxice8> How that lockdown option works ?
2020-02-18 19:08:22 <maxice8> you set it once and it can't be unset until reboot ?
2020-02-18 19:08:30 <Ariadne> yes
2020-02-18 19:08:55 <mps> there are three option, no activate, activate at user will and forcefully activate
2020-02-18 19:10:06 <mps> I think we should enable but left to user to activate in kernel boot parameter if s/he want it
2020-02-18 19:10:55 <mps> my todo list for kernel is long, though :)
2020-02-18 20:05:10 <Ariadne> mps: test building kernels on all hardware (yes, including s390x, i have access to one)
2020-02-18 20:05:18 <Ariadne> wish i could afford one
2020-02-18 20:05:24 <Ariadne> unfortunately they start at high 6 figures
2020-02-18 20:05:53 <_ikke_> Ariadne: I think the allow you to request access to one
2020-02-18 20:05:57 <_ikke_> for opensource
2020-02-18 20:06:04 <Ariadne> yes
2020-02-18 20:06:12 <Ariadne> i have superior access to a different one
2020-02-18 20:06:15 <_ikke_> ok
2020-02-18 20:07:04 <Ariadne> but
2020-02-18 20:07:10 <Ariadne> should i become a millionaire
2020-02-18 20:07:13 <Ariadne> i tell you what
2020-02-18 20:07:16 <maxice8> If we are doing the "don't load modules thing' then the 'sysctl' OpenRC service needs to be after 'modules' OpenRC service, correct ?
2020-02-18 20:07:25 <Ariadne> i am putting an IBM zEnterprise system
2020-02-18 20:07:28 <Ariadne> in my fucking garage
2020-02-18 20:07:29 <Ariadne> :D
2020-02-18 20:07:31 <_ikke_> heh
2020-02-18 20:07:54 <Ariadne> sometimes you can find them on ebay, local pickup only
2020-02-18 20:07:59 <Ariadne> for like $20k
2020-02-18 20:08:29 <Ariadne> maxice8: hmm that raises some quesitons
2020-02-18 20:08:34 <Ariadne> because a module could add sysctl
2020-02-18 20:09:21 <Ariadne> _ikke_: the open source option gives you two cores and 4GB of RAM
2020-02-18 20:09:23 <Ariadne> in my case
2020-02-18 20:09:30 <Ariadne> i have all the cores and all the ram
2020-02-18 20:09:34 <_ikke_> nice
2020-02-18 20:09:39 <Ariadne> but i can only use it
2020-02-18 20:09:43 <Ariadne> when other people aren't using it
2020-02-18 20:09:52 <_ikke_> nod
2020-02-18 20:09:54 <_ikke_> shared
2020-02-18 20:09:55 <Ariadne> because people run complex simulations on it
2020-02-18 20:12:08 <mps> maxice8: what you think about !4242 atril now need texlive-dev and it is disabled on ppc64le
2020-02-18 20:12:34 <mps> Ariadne: :)
2020-02-18 20:14:43 <mps> I would prepare all needed upgrades but I don't have ssh access to dev.a.o so can't make RPi kernels
2020-02-18 20:15:08 <mps> I think you have access there, so go ahead
2020-02-18 20:15:21 <maxice8> @mps is there an option to disable the dependency on texlive ?
2020-02-18 20:15:41 <Ariadne> mps: i do not think i do
2020-02-18 20:15:47 <mps> I didn't found it though looked for it
2020-02-18 20:16:04 <_ikke_> If necessary, I can upload to dev.a.o
2020-02-18 20:16:33 <mps> _ikke_: yes, I know but don't like to bother you
2020-02-18 20:17:05 <mps> enough is to bother you and c_landmeter with crystal
2020-02-18 20:17:28 <Ariadne> soon
2020-02-18 20:17:34 <Ariadne> you will get to bother me as well with that for mips64
2020-02-18 20:17:44 <Ariadne> once the builders arrive anyway
2020-02-18 20:17:55 <Ariadne> the current mips64 builder has no hope in keeping up with the others
2020-02-18 20:18:12 <Ariadne> that's why i haven't requested official inclusion yet
2020-02-18 20:18:33 <Ariadne> we have a set of 48-core ones on the way
2020-02-18 20:18:43 <_ikke_> nice
2020-02-18 20:19:09 <Ariadne> right now
2020-02-18 20:19:12 <Ariadne> we are building on
2020-02-18 20:19:20 <Ariadne> dual-core 1ghz ubiquiti edgerouter-8 PRO
2020-02-18 20:19:22 <Ariadne> and qemu
2020-02-18 20:19:40 <_ikke_> I can imagine it cannot keep up
2020-02-18 20:19:48 <Ariadne> the qemu is not too bad
2020-02-18 20:19:51 <Ariadne> but
2020-02-18 20:20:01 <Ariadne> it cannot build everything
2020-02-18 20:20:09 <Ariadne> for example, go does not work with qemu-user
2020-02-18 20:20:20 <_ikke_> ok, so it's not full qemu?
2020-02-18 20:20:27 <_ikke_> qemy-system
2020-02-18 20:20:28 <Ariadne> yeah, qemu-user
2020-02-18 20:20:40 <_ikke_> We have CI in qemu for aarch64 and armv7
2020-02-18 20:20:49 <Ariadne> qemu-system is fine
2020-02-18 20:21:03 <Ariadne> qemu-user does not like the signaling tricks go does
2020-02-18 20:21:28 <Ariadne> but qemu-user on 192 thread power9 box
2020-02-18 20:21:37 <Ariadne> is quite workable for building most things
2020-02-18 20:22:05 <Ariadne> you have to fake it til you make it sometimes
2020-02-18 20:22:12 <Ariadne> that's what we have been doing with qemu-user
2020-02-18 20:22:52 <Ariadne> but now that we have demonstrated the viability of the port from a business perspective, we are able to buy the hardware needed to do it properly
2020-02-18 20:22:53 <Ariadne> ;)
2020-02-18 20:23:33 <Ariadne> basically, the whole mips64 business started with somebody approaching me going
2020-02-18 20:23:36 <Ariadne> EdgeOS really sucks
2020-02-18 20:23:42 <_ikke_> Ariadne: didn't you forget to relbump the out-of-tree modules?
2020-02-18 20:23:44 <Ariadne> please help me replace it with Alpine
2020-02-18 20:23:48 <Ariadne> _ikke_: no
2020-02-18 20:23:53 <Ariadne> _ikke_: pkgver is kernel version
2020-02-18 20:24:02 <_ikke_> ah ok
2020-02-18 20:24:14 <Ariadne> when bumping kernel version
2020-02-18 20:24:17 <Ariadne> you increment _kver
2020-02-18 20:24:20 <Ariadne> and set _krel to 0
2020-02-18 20:24:48 <Ariadne> i'm not sure what this monster patch file is on dev.a.o for rpi
2020-02-18 20:24:58 <Ariadne> is that the rpi tree rebased against 5.4.18 ?
2020-02-18 20:25:16 <_ikke_> Then I have to fix https://git.alpinelinux.org/aports/tree/community/rtl8821ce-lts/APKBUILD?id=3bf2313adc57fe6b36bf459ddca6d65a392609db
2020-02-18 20:26:51 <Ariadne> _ikke_: yeah $pkgver should be the kernel version
2020-02-18 20:27:23 <mps> Ariadne: look at linux-rpi APKBUILD genpatch()
2020-02-18 20:27:49 <Ariadne> ah
2020-02-18 20:28:29 <Ariadne> well i can gen a patch
2020-02-18 20:28:30 <Ariadne> no biggie
2020-02-18 20:29:10 <Ariadne> this is
2020-02-18 20:29:14 <Ariadne> an interesting system
2020-02-18 20:29:16 <Ariadne> for managing config
2020-02-18 20:29:21 <Ariadne> we should apply  it to linux-lts :)
2020-02-18 20:29:24 <mps> yes :)
2020-02-18 20:29:48 <mps> but, well, who will test all that
2020-02-18 20:30:09 <Ariadne> i can test most of it
2020-02-18 20:30:23 <mps> on all 4 RPi variant?
2020-02-18 20:33:01 <Ariadne> hmm
2020-02-18 20:33:19 <Ariadne> mps: no i mean, i can test the linux-lts kernels with that config system
2020-02-18 20:33:31 <Ariadne> i only have an RPi 3
2020-02-18 20:33:37 <Ariadne> but this abuild genpatch
2020-02-18 20:33:39 <Ariadne> is not doing anything
2020-02-18 20:34:39 <Ariadne> doing it by hand
2020-02-18 20:34:39 <Ariadne> :D
2020-02-18 20:34:48 <mps> hmm
2020-02-18 20:35:00 <mps> didn't tried for some time
2020-02-18 20:37:33 <mps> Ariadne: you disabled stack protector on ppc64le
2020-02-18 20:37:41 <Ariadne> no
2020-02-18 20:38:02 <mps> '-CONFIG_STACKPROTECTOR=y'
2020-02-18 20:38:04 <Ariadne> oh
2020-02-18 20:38:06 <Ariadne> what the fuck
2020-02-18 20:39:01 <_ikke_> mps: good catch!
2020-02-18 20:39:04 <Ariadne> its because CONFIG_HAVE_STACKPROTECTOR=y disappeared
2020-02-18 20:39:10 <Ariadne> i will dig into it in a bit
2020-02-18 20:39:24 <Ariadne> i'm working on 5.4.20 rpi bump
2020-02-18 20:40:58 <mps> _ikke_: yes, this one 'irritated' me in last few upgrade cycles, not hard to remember it :)
2020-02-18 20:41:04 <Cogitri> Pushing to g.a.o is so slooooowwww
2020-02-18 20:41:42 <_ikke_> is it?
2020-02-18 20:42:17 <Ariadne> move out of brazil
2020-02-18 20:42:18 <Ariadne> duh
2020-02-18 20:42:42 <Cogitri> I'm located in Germany :P
2020-02-18 20:42:43 <_ikke_> maxice8 was in Brazil, I don't think Cogitri is
2020-02-18 20:42:56 <Cogitri> It often takes some ~30 seconds until I can push or pull
2020-02-18 20:43:02 <Ariadne> move into the DC
2020-02-18 20:43:06 <Ariadne> next to alpine git server
2020-02-18 20:43:10 <Cogitri> I think ncopa mentioned a rather limited amount of SSH sessions?
2020-02-18 20:43:10 <Ariadne> just get a couch from IKEA
2020-02-18 20:43:30 <Ariadne> just jack right in
2020-02-18 20:44:05 <_ikke_> awall configures ratelimitting
2020-02-18 20:44:08 <_ikke_> on iptables
2020-02-18 20:44:20 <mps> rate limit ?
2020-02-18 20:44:42 <Cogitri> Ah yes, maybe it's that
2020-02-18 20:44:45 <mps> ah, I need read previous msgs more carefully
2020-02-18 20:44:56 <Cogitri> It just tends to lead to me staring at my screen for some 30 secs waiting for things to happen :P
2020-02-18 20:45:15 <_ikke_> do you make more than 1 connections per second to ssh?
2020-02-18 20:45:21 <Ariadne> _ikke_: https://distfiles.dereferenced.org/rpi-5.4.20.patch
2020-02-18 20:45:59 <Ariadne> mps: you mention this happens previously.  do you know why it happened?
2020-02-18 20:46:03 <mps> _ikke_: !4253 fail on CI armv7 (not only) and I just tried in armv7 lxc and it pass fine
2020-02-18 20:46:34 <Cogitri> I don't think so? It usually happens when I do mass pushes though (ala git checkout $branch && git pull upstream master --rebase && git push upstream), so maybe I do it just quickly enough to hit the limit
2020-02-18 20:47:04 <Ariadne> i've never hit this limit
2020-02-18 20:47:15 <Cogitri> I think maxice8 tends to hit it sometimes too
2020-02-18 20:47:26 <Ariadne> maybe we should increase it
2020-02-18 20:47:28 <mps> Ariadne: abuild oldconfig reset stack protector for ppc64le config
2020-02-18 20:47:30 <Ariadne> to 5 conn/s
2020-02-18 20:47:38 <Cogitri> Or maybe I should be more gentle to g.a.o :P
2020-02-18 20:48:05 <Cogitri> Also, does someone know providers and feels like taking a look at !4182 ?
2020-02-18 20:48:21 <Ariadne> yes i will review 4182 in a moment
2020-02-18 20:48:38 <Ariadne> _ikke_: let me know when that patch is on dev.a.o pls
2020-02-18 20:48:42 <_ikke_> it is
2020-02-18 20:48:42 <Cogitri> Thank you :)
2020-02-18 20:48:51 <Ariadne> _ikke_: thanks
2020-02-18 20:48:53 <_ikke_> Just wondering why the patch contains a github contributers document
2020-02-18 20:49:03 <_ikke_> --- /dev/null
2020-02-18 20:49:05 <_ikke_> +++ b/.github/ISSUE_TEMPLATE/bug_report.md
2020-02-18 20:49:12 <Ariadne> :D
2020-02-18 20:49:13 <_ikke_> but the previous one does as well
2020-02-18 20:50:10 <Ariadne> _ikke_: the RPI kernel is on github is why
2020-02-18 20:50:25 <_ikke_> ah ok
2020-02-18 20:50:51 <_ikke_> so basically an export from github formatted as a patch
2020-02-18 20:51:20 <Cogitri> Oh, build.a.o only displays busy builders now? Nice
2020-02-18 20:51:50 <_ikke_> Cogitri: no
2020-02-18 20:51:57 <_ikke_> it's just that msg.a.o rebooted
2020-02-18 20:52:07 <_ikke_> so it has no retained message from the other builders anymore
2020-02-18 20:52:21 <Cogitri> Oh
2020-02-18 20:52:34 <Cogitri> I kinda like it only displaying busy builders to be honest
2020-02-18 20:52:55 <_ikke_> We should restart msg.a.o more often :P
2020-02-18 20:53:04 <Cogitri> Yes please :P
2020-02-18 20:53:07 <Ariadne> well
2020-02-18 20:53:07 <Ariadne> tbh
2020-02-18 20:53:10 <Ariadne> this restart
2020-02-18 20:53:13 <Ariadne> was kind of a clusterfuck
2020-02-18 20:53:16 <Ariadne> from what i saw in -infra
2020-02-18 20:53:17 <Ariadne> ;)
2020-02-18 20:53:18 <_ikke_> yup
2020-02-18 20:53:26 <_ikke_> but it was a kernel upgrade as well
2020-02-18 20:53:43 <Cogitri> https://build.alpinelinux.org/buildlogs/build-3-11-armv7/community/webkit2gtk/webkit2gtk-2.26.4-r0.log Was gst-plugins-bad not rebuilt on armv7 for some reason? x265 is available on armv7 so I'm not quite sure why this only pops up on armv7
2020-02-18 20:54:41 <_ikke_> https://pkgs.alpinelinux.org/contents?file=libx265.so.*&path=&name=&branch=edge&arch=armv7
2020-02-18 20:54:50 <_ikke_> oh, 3-11
2020-02-18 20:54:58 <_ikke_> https://pkgs.alpinelinux.org/contents?file=libx265.so.*&path=&name=&branch=v3.11&arch=armv7
2020-02-18 20:55:19 <_ikke_> so on 3.11, it's .179
2020-02-18 20:56:07 <Cogitri> But how is gst-plugins-bad built against .181 then
2020-02-18 20:56:28 <Ariadne> mps: i don't want to just put STACKPROTECTOR back and hope it doesn't get blasted away again
2020-02-18 20:56:41 <Ariadne> mps: so let me figure out why oldconfig blasted it away please :)
2020-02-18 20:56:41 <_ikke_> You mean .188?
2020-02-18 20:57:01 <Ariadne> mps: here is something interesting
2020-02-18 20:58:07 <Cogitri> Right, 188
2020-02-18 20:59:08 <mps> Ariadne: I think it is not default in arch/powerpc/configs/ppc64_defconfig
2020-02-18 20:59:20 <Ariadne> yes but that does not matter
2020-02-18 21:00:07 <Ariadne> hmmm
2020-02-18 21:00:10 <Ariadne> 5.4.18 does have it set
2020-02-18 21:00:42 <mps> it is set somewhere around 5.4.6-10 IRC
2020-02-18 21:00:45 <Ariadne> just checked my box
2020-02-18 21:00:59 <Ariadne> well
2020-02-18 21:01:05 <Ariadne> i did abuild clean unpack prepare oldconfig
2020-02-18 21:01:10 <Ariadne> so it should be fully patched ?
2020-02-18 21:01:45 <mps> 5.4.7
2020-02-18 21:02:05 <mps> yes, it should but it doesn't
2020-02-18 21:02:24 <mps> s/IRC/iirc/
2020-02-18 21:02:25 <alpine-meetbot> mps meant to say: it is set somewhere around 5.4.6-10 iirc
2020-02-18 21:03:37 <Ariadne>         select HAVE_STACKPROTECTOR              if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
2020-02-18 21:03:40 <Ariadne> aha
2020-02-18 21:03:46 <_ikke_> Cogitri: I can install gst-plugins-bad in a 3.11 docker container on armv7
2020-02-18 21:04:10 <mps> I don't have ppc64le box to check what happens actually
2020-02-18 21:04:15 <_ikke_> oh, that's aarch64
2020-02-18 21:04:22 <Ariadne> mps: what happens is
2020-02-18 21:04:30 <Ariadne> mps: it silently tries to check gcc
2020-02-18 21:04:52 <Ariadne> but what we do when we rebase kernel config is
2020-02-18 21:04:57 <Ariadne> we do CARCH=...
2020-02-18 21:05:09 <Ariadne> so thats why it gets blown away
2020-02-18 21:05:28 <Ariadne> i think it is worthwhile to defang this
2020-02-18 21:05:38 <mps> ah, I see
2020-02-18 21:05:57 <_ikke_> Cogitri: x265-libs-3.2.1-r0 provides:
2020-02-18 21:05:59 <mps> now I'm not in a dark about this :)
2020-02-18 21:05:59 <_ikke_> so:libx265.so.179=179
2020-02-18 21:06:16 <Ariadne> mps: i think we just select HAVE_STACKPROTECTOR always
2020-02-18 21:06:25 <_ikke_> Cogitri: so apparently in the repos gst-plugins-bad is compiled against 179
2020-02-18 21:07:30 <Ariadne> mps: do you agree with defanging this gcc check?
2020-02-18 21:09:08 <mps> it will save me some hassle in case I do upgrade
2020-02-18 21:11:30 <mps> this is only in arch/powerpc
2020-02-18 21:11:54 <Cogitri> ikke: Huh, that makes it even weirder, why would apk say it needs .188 then?
2020-02-18 21:13:18 <_ikke_> good question
2020-02-18 21:13:24 <_ikke_> this is on 3.11, right?
2020-02-18 21:13:52 <mps> 
ACTION is to tired, goes for fresh air

2020-02-18 21:14:36 <Cogitri> Yes, it's on 3.11
2020-02-18 21:14:45 <Cogitri> Almost seems like an edge package somehow ended up on 3.11
2020-02-18 21:17:25 <_ikke_> Cogitri: Sounds about right
2020-02-18 21:18:04 <_ikke_> someone added edge repository to the 3.11 builder
2020-02-18 21:18:55 <_ikke_> clandmeter: Any idea why 3.11-armv7 builder has edge/community in /etc/apk/repositories?
2020-02-18 21:20:44 <Ariadne> mps: ok sorted
2020-02-18 21:20:56 <_ikke_> Cogitri: should work now
2020-02-18 21:23:07 <_ikke_> sounds like it was used for bootstrapping but forgotten to be removed again
2020-02-18 21:23:57 <Ariadne> rebasing kernel config for ppc64le should no longer kill stackprotector :)
2020-02-18 21:27:31 <maxice8> I hit the limit a lot of times
2020-02-18 21:29:01 <Cogitri> ikke: Alright, thanks
2020-02-18 21:42:31 <Cogitri> Also, does someone know Go a bit? Singularity fails hard on the builders but works locally and also worked on CI
2020-02-18 21:42:32 <Cogitri> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/singularity/singularity-3.5.3-r0.log
2020-02-18 22:19:10 <Ariadne> that build looks successful
2020-02-18 22:19:15 <Ariadne> but there is some serious policy violations
2020-02-18 22:19:22 <Ariadne> namely, it is fetching go dependencies inside the build
2020-02-19 05:54:01 <Ariadne> 5.4.21 is going to drop tomorrow or friday
2020-02-19 05:56:24 <Cogitri> Were point releases always so frequent?
2020-02-19 05:57:24 <Cogitri> Also, apparently I'll have to read up on how to do anything in Go :P
2020-02-19 06:06:06 <Cogitri> Also, I've heard that we're going to switch to rootbld on the builders at some point, so we'll have to add `options="net"` to everything that uses cargo or go, right?
2020-02-19 07:07:05 <mps> Ariadne: heh, why so outdated kernel, here is: Linux zarya 5.6.0-rc2-1-gru #1 SMP PREEMPT Sun Feb 16 22:49:08 CET 2020 aarch64 GNU/Linux
2020-02-19 07:07:24 <mps> :)
2020-02-19 07:07:37 <Ariadne> because that one isn't longterm
2020-02-19 07:07:42 <Ariadne> but I agree
2020-02-19 07:07:50 <Ariadne> we should have lts and mainline
2020-02-19 07:08:11 <Ariadne> but we need to clean up our kernel mess first imo
2020-02-19 07:08:33 <mps> hey, you lost sense of humor
2020-02-19 07:09:20 <mps> ofc, I don't run -rc on servers and important boxes
2020-02-19 07:27:12 <Cogitri> I think we'd have to switch to using DKMS for modules before we can introduce more kernel flavours
2020-02-19 07:32:54 <mps> Cogitri: +1
2020-02-19 07:34:00 <Cogitri> Otherwise it'd be way too much maintainance effort to keep all kernel modules up-to-date for all kernels
2020-02-19 08:26:22 <clandmeter> i thought we were going to keep linux-vanilla to follow latest kernel?
2020-02-19 08:26:58 <clandmeter> but without out of tree module support
2020-02-19 08:27:08 <mps> clandmeter: no, ncopa decided to use -lts
2020-02-19 08:27:21 <clandmeter> this is not my question
2020-02-19 08:27:36 <mps> ah
2020-02-19 08:42:45 <clandmeter> mps: maybe you want to maintain a linux-vanilla in community?
2020-02-19 08:43:06 <clandmeter> i think you play with kernels often
2020-02-19 08:43:35 <clandmeter> it would also be nice for ncopa to pull changes from vanilla to lts
2020-02-19 08:59:12 <mps> clandmeter: what you mean by 'vanilla'? latest stable and not long term stable?
2020-02-19 08:59:31 <clandmeter> _ikke_: i have no idea, if i bootstrap go or similar i download the pkg, not add a repo.
2020-02-19 08:59:51 <mps> or long term stable without out-of-tree modules
2020-02-19 09:01:08 <clandmeter> mainline or latest stable, im not sure which one is more suitable.
2020-02-19 09:02:32 <mps> latest stable, I think (which is mostly same as mainline)
2020-02-19 09:02:58 <mps> I even use them as synonyms
2020-02-19 09:04:15 <clandmeter> maybe call it linux-latest
2020-02-19 09:04:23 <mps> actually I have local branch for armv7, with support for more SOCs and drivers, but didn't pushed because I don't see much interest for it
2020-02-19 09:05:39 <mps> ncopa 'puled' updates some things from it (I posted it on tpaste) when upgraded to 5.4
2020-02-19 09:06:53 <clandmeter> would be similar if you would maintain linux-latest, he could pull that config.
2020-02-19 09:07:09 <clandmeter> i guess you would have done lts before it becomes lts
2020-02-19 09:07:17 <_ikke_> clandmeter: I think ncopa just adds repos
2020-02-19 09:07:21 <mps> yes, I did
2020-02-19 09:07:38 <clandmeter> _ikke_: thats scary
2020-02-19 09:07:39 <_ikke_> clandmeter: for go a single pkgs is enough, but others (like ghc) require more
2020-02-19 09:07:56 <clandmeter> i think you can add repos on the cmdline
2020-02-19 09:08:39 <_ikke_> but not for abuild I guess
2020-02-19 09:08:43 <clandmeter> i also do a: apk add xxx; abuild -r; apk del xxx
2020-02-19 09:08:52 <clandmeter> just to make sure its removed again
2020-02-19 09:09:51 <mps> and, I have local branch linux-lts-ws, LTS tweaked for workstation workload
2020-02-19 09:10:01 <_ikke_> would nice if abuild supports specifying a bootstrap repo
2020-02-19 09:11:26 <clandmeter> how many different pkgs does ghc need?
2020-02-19 09:12:43 <_ikke_> Hmm, just realized that you only need to manually add ghc-bootstrap, the rest can just come from the existing repos
2020-02-19 09:17:52 <clandmeter> i think it's probably not worth the time to implement such feature. we just need to be more careful when bootstrapping those languages.
2020-02-19 13:05:31 <Cogitri> I think the ZFS module for 5.4.20-r1 is broken
2020-02-19 13:05:37 <Cogitri> Has loads of unresolved symbols
2020-02-19 13:09:02 <clandmeter> Cogitri: on edge?
2020-02-19 13:11:28 <Cogitri> Yes, on edge
2020-02-19 13:11:38 <Cogitri> Just upgraded
2020-02-19 13:11:38 <Cogitri> And everything blew up
2020-02-19 14:44:19 <PureTryOut[m]> Interesting, https://build.alpinelinux.org/ doesn't show the builders for Alpine versions older than 3.11 anymore
2020-02-19 14:44:32 <_ikke_> PureTryOut[m]: mqtt has been restarted
2020-02-19 14:44:38 <_ikke_> it lost the retained messages for older builders
2020-02-19 14:44:49 <_ikke_> they will reappear when something is pushed for those builders
2020-02-19 14:51:10 <PureTryOut[m]> Ah cool
2020-02-19 14:51:52 <_ikke_> We want to move this part one day from mqtt to redis or something like that
2020-02-19 15:07:20 <maxice8> @Ariadne can  you write the preamble for BPF JIT in https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0 ?
2020-02-19 15:08:20 <Ariadne> sure
2020-02-19 15:08:25 <maxice8> Thank you
2020-02-19 16:35:53 <PureTryOut[m]> ncopa: could you merge !3848?
2020-02-19 16:36:20 <Cogitri> (Or someone else who feels comfortable merging linux-lts changes)
2020-02-19 16:36:24 <_ikke_> PureTryOut[m]: ncopa is on holiday for some time now
2020-02-19 16:36:29 <_ikke_> s/now/still
2020-02-19 16:36:29 <alpine-meetbot> _ikke_ meant to say: PureTryOut[m]: ncopa is on holiday for some time still
2020-02-19 16:37:00 <PureTryOut[m]> Oh. Well, anyone else that can merge a linux-lts change would be fine πŸ˜‰
2020-02-19 16:37:59 <_ikke_> I recall there being some controversy around it?
2020-02-19 16:40:30 <PureTryOut[m]> I'm not sure what you're talking about. The linux-lts change specifically is just enabling some kernel stuff
2020-02-19 16:40:58 <PureTryOut[m]> *some config options
2020-02-19 16:44:07 <_ikke_> Maybe it was a different related MR
2020-02-19 16:49:11 <_ikke_> I think it's best to wait until ncopa is back. In the end, he's the kernel maintainer, so we defer these decissions to him.
2020-02-19 16:49:39 <_ikke_> He is on a long deserved holiday
2020-02-19 16:50:59 <_ikke_> I hope it's not so urgent that it cannot wait 2 weeks
2020-02-19 16:56:55 <Cogitri> Huh, so apparently zfs was purged on my two machines after an upgrade and that's what broke it on my machine
2020-02-19 16:56:58 <Cogitri> That's interesting
2020-02-19 17:04:51 <PureTryOut[m]> _ikke_: not _that_ urgent but I'd like Anbox support in some form in before the launch of the PinePhone really
2020-02-19 17:05:54 <mps> _ikke_: strongly agree with you
2020-02-19 17:06:33 <mps> though also I need some changes, but well I can wait, world will not end in a few weeks
2020-02-19 17:14:19 <PureTryOut[m]> I guess till that time we'll put it in pmOS
2020-02-19 17:36:18 <mps> anyone have ppc64le real box, qemu or lxc to try to build texlive
2020-02-19 17:36:55 <mps> well, it failed in builder so lxc not needed
2020-02-19 17:37:52 <walbon> mps: ol, can I run it in a docker inside a ppckvm guest?
2020-02-19 17:38:25 <mps> walbon: it failed in docker on gitlab CI
2020-02-19 17:39:18 <mps> it failed on our CI also on armv7 but build quite fine in armv7 lxc
2020-02-19 17:39:33 <mps> our CI is docker
2020-02-19 17:40:20 <mps> it fails because can't find mplib.h which is generated during build
2020-02-19 17:40:53 <walbon> mps: shoul I use a edge repos? with latest upstream texlive?
2020-02-19 17:41:11 <mps> walbon: yes
2020-02-19 17:41:33 <mps> no, sorry, current texlive in edge
2020-02-19 17:41:44 <mps> git master branch
2020-02-19 17:42:24 <walbon> bulding...
2020-02-19 17:42:57 <mps> thanks
2020-02-19 18:02:57 <walbon> mps, works, texlive built
2020-02-19 18:03:38 <mps> on ppc64le?
2020-02-19 18:04:04 <walbon> mps: yes, it's a powerpc machine
2020-02-19 18:04:16 <mps> thanks again
2020-02-19 18:04:36 <walbon> y'r welcome
2020-02-19 18:04:50 <mps> so, something is wrong on our CIs and builders, probably
2020-02-19 18:05:32 <walbon> mps: do you have a log ?
2020-02-19 18:06:02 <mps> yes, https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/texlive/texlive-20190410-r6.log
2020-02-19 18:06:20 <mps> this is official builder log
2020-02-19 18:09:31 <walbon> well, I can't see the difference , sorry
2020-02-19 18:10:29 <mps> can't find mplib.h
2020-02-19 18:10:48 <mps> in error log above
2020-02-19 18:56:37 <mps> walbon: by some magic texlive passed build on ppc64le builder
2020-02-19 18:56:58 <mps> it is in repo http://dl-cdn.alpinelinux.org/alpine/edge/community/ppc64le/texlive-20190410-r6.apk
2020-02-19 18:57:43 <mps> so, AI finally works :)
2020-02-19 18:58:05 <walbon> yeap, it's magic
2020-02-19 20:08:44 <_ikke_> If there is something wrong, I'd love to know what :)
2020-02-19 20:11:23 <mps> _ikke_: if I have crystal ball I would send it to you :)
2020-02-19 20:14:41 <mps> would someone (brave enough) to review (and merge) !3482
2020-02-19 20:15:22 <mps> because n_copa will not be back soon, I think
2020-02-19 21:00:54 <_ikke_> ugh, gcc is always challenging with CI
2020-02-19 21:01:05 <_ikke_> We need to find a way around that
2020-02-19 21:02:11 <_ikke_> maxice8: why were darkhttpd checksums worng?
2020-02-19 21:02:30 <maxice8> Merged a commit that didn't change them properly
2020-02-19 21:03:00 <_ikke_> ah, it was a initd file that was changed, right
2020-02-19 21:03:06 <maxice8> yes
2020-02-19 21:08:48 <mps> _ikke_: I pushed same patch for community/gcc6 already about two weeks ago, e3a482b2a425cd00944052204ca015b9a7fd36bb
2020-02-19 21:09:22 <mps> and for 3.11-stable
2020-02-19 21:12:48 <mps> btw, I tested it in x86, x86_64, armv7 and aarch64 lxc, worked without issue, ofc by adding gcc-gnat manually
2020-02-19 21:41:13 <mps> kernel 5.4.21 is out
2020-02-19 21:42:11 <_ikke_> mps: I discussed it with clandmeter, and we will add gcc-gnat to the base image
2020-02-19 21:42:35 <mps> yes, I followed your discussion
2020-02-19 21:43:17 <mps> didn't wanted to interfere
2020-02-19 21:51:54 <_ikke_> build-base is building, after it is ready, I rebuild alpine-gitlab-ci, then it should work on gitlab
2020-02-19 22:03:56 <_ikke_> mps: checking gcc in ci now
2020-02-19 22:06:25 <_ikke_> it's building now
2020-02-19 22:35:46 <mps> _ikke_: I don't see that the CI is working on it
2020-02-19 22:37:12 <mps> ah, it failed again
2020-02-20 01:42:28 <Ariadne> mps: i will review it in the morning
2020-02-20 01:45:54 <Ariadne> umm
2020-02-20 01:45:55 <Ariadne> https://git.alpinelinux.org/aports/commit/main/pkgconf/APKBUILD?id=52984a5bea48215bb260e973f47575e49a61c317
2020-02-20 01:45:58 <Ariadne> this url is wrong :D
2020-02-20 01:46:00 <Ariadne> it is
2020-02-20 01:46:05 <Ariadne> https://git.sr.ht/~kaniini/pkgconf
2020-02-20 08:58:46 <_ikke_> mps: it succeeded
2020-02-20 08:58:49 <_ikke_> https://gitlab.alpinelinux.org/mps/aports/-/jobs/52930
2020-02-20 08:59:05 <_ikke_> I just started x86_64, so the mail probably says it failed because the other jobs did not run yet
2020-02-20 09:25:19 <mps> _ikke_: good. will look later (and rebase probably). thanks
2020-02-20 09:26:40 <_ikke_> armv7 and ppc64le are still running, the rest succeeded
2020-02-20 09:29:15 <mps> I see
2020-02-20 09:29:35 <mps> there is also same patch for edge, !3344
2020-02-20 09:30:13 <mps> fix*
2020-02-20 09:30:44 <mps> you added gcc-gnat to CI dockers?
2020-02-20 09:31:18 <_ikke_> yes
2020-02-20 09:31:44 <_ikke_> But as you've read in -infra, we try to see if we can solve it within the APKBUILD
2020-02-20 09:32:54 <mps> yes, that would be better if possible
2020-02-20 09:40:28 <AinNero> wee
2020-02-20 09:40:32 <AinNero> https://github.com/paulusmack/ppp/commit/8d7970b8f3db727fe798b65f3377fe6787575426
2020-02-20 09:40:42 <AinNero> i think this affects our pppd package
2020-02-20 09:41:38 <_ikke_> sounds like a potential cve?
2020-02-20 09:42:16 <mps> I looked at it when prepared ppp upgrade
2020-02-20 09:42:52 <AinNero> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8597
2020-02-20 09:43:32 <mps> tought to add it as patch, but didn't because n_copa is busy and I wasn't sure if it is ok to add it without his approval
2020-02-20 09:44:03 <AinNero> id vouch for you to just do it
2020-02-20 09:44:09 <_ikke_> yes, I tend to agree
2020-02-20 09:44:16 <mps> AinNero: ah, thanks. now it is clear it should be added
2020-02-20 09:44:31 <mps> didn't know for this CVE
2020-02-20 09:44:34 <AinNero> i run pppd on edge, so im hopefully the first to get the potential breakage
2020-02-20 09:44:58 <mps> also I run it
2020-02-20 09:45:14 <mps> 3-4 weeks now
2020-02-20 09:46:26 <mps> I will try to fix it in a hour and if it went ok will create MR
2020-02-20 09:47:24 <mps> AinNero: you run ppp 2.4.8 ?
2020-02-20 09:48:29 <AinNero> not yet
2020-02-20 09:49:01 <AinNero> the laptop is not my daily driver
2020-02-20 09:49:11 <AinNero> but still running permanently
2020-02-20 09:49:35 <mps> ok
2020-02-20 09:49:47 <mps> on edge ppp is 2.4.8
2020-02-20 09:49:53 <AinNero> its on edge
2020-02-20 09:50:48 <mps> I installed it on 3.11 from edge
2020-02-20 09:51:26 <mps> to test does it work ok before created MR for upgrade
2020-02-20 09:58:07 <AinNero> 
ACTION scratches head

2020-02-20 09:58:23 <AinNero> the update for 2.4.8 (without the extra patch) already broke it
2020-02-20 09:58:32 <AinNero> ill investigate later, got a meeting now
2020-02-20 10:05:11 <mps> 2.4.8 builds with patch applied
2020-02-20 10:06:12 <mps> _ikke_: should I 'secfixes' in APKBUILD. currently ppp doesn't have it
2020-02-20 10:07:40 <_ikke_> yes
2020-02-20 10:07:57 <mps> ok
2020-02-20 10:11:33 <mps> here it is !4309
2020-02-20 10:11:55 <mps> now 3.11-stable
2020-02-20 10:14:09 <Cogitri> fwiw I think `main/ppp: fix CVE-2020-8597` is a way better commit message
2020-02-20 10:14:44 <Cogitri> Also, bump pkgrel isn't something I'd include in a commit description, that is an obvious consequence of your change and not noteworthy
2020-02-20 10:15:38 <_ikke_> agreed
2020-02-20 10:18:15 <mps> Cogitri: I started to write it as such but changed mind
2020-02-20 10:19:07 <mps> what if we in one commit change more CVEs, first line in commit msg will be cumbersome, at least
2020-02-20 10:20:09 <mps> about bump, there are different 'schools of thinking' about it
2020-02-20 10:20:18 <Cogitri> At that point you can make the commit message `main/package: fix multiple CVEs` and then make a list of the CVEs in the description
2020-02-20 10:20:35 <Cogitri> But if you only fix one CVE I'd just mention it in the message and not the description
2020-02-20 10:20:43 <mps> also I think it is not needed but some devs adviced me to add it
2020-02-20 10:20:54 <Cogitri> And I think in 99% of cases we don't mention pkgrel bumps in the commit message
2020-02-20 10:24:49 <mps> ppp 3.11-stable fix !4310
2020-02-20 10:28:19 <nmeum> _ikke_: btw did you debug the aarch64 CI go failure further?
2020-02-20 10:29:24 <_ikke_> nmeum: no, not yet
2020-02-20 10:30:03 <nmeum> but it's not really a blocker for the merging the GOFLAGS change, is it?
2020-02-20 10:30:37 <nmeum> imo the primary problem with it is that someone needs to adjust abuild.conf on the builders
2020-02-20 10:31:44 <_ikke_> nmeum: no, it shouldn't be
2020-02-20 10:32:45 <mps> Cogitri: removed 'bump', (for your eyes only :) )
2020-02-20 10:33:21 <Cogitri> Thanks :)
2020-02-20 10:33:48 <_ikke_> mps: just a general advise, the commit message benefits more from explaining why certain things are done than listing what has been done.
2020-02-20 10:34:22 <Cogitri> nmeum:  Could you take a look at abuild!13 ?
2020-02-20 10:34:24 <nmeum> _ikke_: do we have anyone with access to all builders who isn't on vacation currently? the go change is not high priority at all but I would like to cleanup the go check() soonish and that depends on the GOFLAGS change
2020-02-20 10:34:36 <Cogitri> Huh, that didn't work as expected
2020-02-20 10:35:08 <mps> _ikke_: you want me to explain all possible attacks in commit msg? or I misunderstood your note?
2020-02-20 10:35:30 <nmeum> Cogitri: yes, I have some further comments regarding that MR but I don't have time atm. Could you assign it to me and maybe remind me later this evening?
2020-02-20 10:36:03 <Cogitri> Sure, thanks :)
2020-02-20 10:36:32 <Cogitri> I don't have the bits to assign people in the abuild repo though
2020-02-20 10:36:53 <nmeum> no problem, I don't think anyone else will merge it in the meantime anyhow
2020-02-20 10:38:07 <Cogitri> Probably not, no
2020-02-20 10:43:35 <_ikke_> mps: no, in case of a cve, the reason is clear enough. Optionally you could add a link to a page with more information, but the patch already includes a commit message with the details
2020-02-20 10:44:24 <mps> ok, understand
2020-02-20 10:45:56 <_ikke_> same with a trivial upgrade. Unless the upgrade has a lot of impact, just a single line commit message is enough context
2020-02-20 10:47:06 <_ikke_> but in many other cases, you want to communicate to others (and your future self) why a change is being made
2020-02-20 16:27:08 <nmeum> Cogitri: added a comment to your abuild mr. tl;dr i am mostly concerned about cflags (other then -g) potentially activated by these build types (debugoptimized does switch to -O1 on some arches for instance)
2020-02-20 16:33:08 <Cogitri> maxice8: I think 48c97755d4f227807514b392a139fc3e01304a28 broke the booting on my systems
2020-02-20 16:33:36 <Cogitri> Upgrading purges the kmod package since stuff only depends on kmod-libs now
2020-02-20 16:33:46 <Cogitri> So initramfs generation goes wron
2020-02-20 16:33:52 <Cogitri> s/wron/wrong/
2020-02-20 16:33:53 <alpine-meetbot> Cogitri meant to say: So initramfs generation goes wrong
2020-02-20 16:34:20 <Cogitri> mkinitfs throws `modinfo: can't open '/lib/modules/5.4.18-0-lts/modules.dep': No such file or directory` without kmod, once I install kmod it goes through fine
2020-02-20 16:35:05 <maxice8> seems like mkinitfs is missing a dep on kmod
2020-02-20 16:35:13 <Cogitri> Probably
2020-02-20 16:35:19 <maxice8> certainly
2020-02-20 16:35:38 <_ikke_> I don't see how that upgrade would case kmod to be purged
2020-02-20 16:35:42 <_ikke_> s/case/cause/
2020-02-20 16:35:42 <alpine-meetbot> _ikke_ meant to say: I don't see how that upgrade would cause kmod to be purged
2020-02-20 16:35:52 <Cogitri> Because things only pulled in kmod due to the libs before
2020-02-20 16:36:01 <Cogitri> And now it installs kmod-libs and purges the now not required kmod
2020-02-20 16:36:31 <maxice8> @ikke nothing depends on kmod itself but rather on libkmod and assume it brings cmd:kmod as well
2020-02-20 16:36:48 <Cogitri> nmeum: Well, `release` adds loads of CFLAGS too. If we're concered about that we should probably just switch to the plain buildtype for everything
2020-02-20 16:36:49 <_ikke_> ah, node, autodeps
2020-02-20 16:40:54 <nmeum> Cogitri: if the release buildtype also overwrites our -Os we should imho move away from it, yes
2020-02-20 16:42:01 <maxice8> @Cogitri !4316
2020-02-20 16:42:06 <Cogitri> Thanks
2020-02-20 16:42:22 <Cogitri> nmeum: It certainly does, I think it usually sets -O2 or even -O3
2020-02-20 16:42:35 <Cogitri> Some upstreams enable additional flags too at least for meson stuff, no clue about CMake
2020-02-20 16:42:44 <Cogitri> Plain certainly is the way to go for distros
2020-02-20 16:43:06 <Cogitri> Was wondering why we used non-plain already but somehow I didn't get around to asking someone I suppose :/
2020-02-20 16:46:37 <nmeum> Cogitri: I was always under the assumption that the non-plain cflags would be overwritting by our CFLAGS but I suppose that's not the case?
2020-02-20 16:47:19 <nmeum> but it's good that we ran into this issue now because if my assumption are incorrect it might be worhit to sed the existing cmake/meson build types with a plain one?
2020-02-20 16:47:50 <Cogitri> Yes, will do so
2020-02-20 16:48:01 <Cogitri> And no, they're not overwritten
2020-02-20 16:48:14 <nmeum> well that's sucks then
2020-02-20 16:48:30 <Cogitri> And loads of upstreams do something ala `if $buildtype == release; then; CFLAGS="$CFLAGS $OUR_OWN_FLAGS";fi`
2020-02-20 16:48:46 <Cogitri> Well, it's expected behaviour, the plain build types are there for a reason
2020-02-20 16:48:50 <nmeum> yeah, I mostly patch buildsystem that do that
2020-02-20 16:48:54 <nmeum> make-based buildsystems that is
2020-02-20 16:51:02 <nmeum> https://gitlab.alpinelinux.org/search?group_id=&project_id=1&repository_ref=master&scope=commits&search=respect+our+cflags :)
2020-02-20 16:52:16 <Cogitri> Hehe
2020-02-20 16:53:01 <Cogitri> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/29
2020-02-20 16:53:21 <Cogitri> I'll go ahead and test this on aports and then we can merge this once it works in aports
2020-02-20 16:53:22 <ncopa> hi! how are things going?
2020-02-20 16:53:30 <nmeum> hello ncopa \o
2020-02-20 16:54:07 <ncopa> nice to see that alpine still exist :)
2020-02-20 16:54:31 <nmeum> Cogitri: great, though it would probably be preferable to discuss this a bit, e.g. on the ml? so people are aware of this issue, adjust their aports, et cetera?
2020-02-20 16:54:51 <nmeum> ncopa: already back from vacation?
2020-02-20 16:55:28 <ncopa> no
2020-02-20 16:55:49 <Cogitri> Have fun then :)
2020-02-20 16:55:57 <ncopa> im just taking a break from vacation
2020-02-20 16:56:18 <Cogitri> nmeum: I don't see the point of "adjust their aport", I really don't want to ping individual maintainers about this
2020-02-20 16:56:49 <Ariadne> uhhh
2020-02-20 16:56:52 <Ariadne> (16/16) Installing .makedepends-mozjs60 ()
2020-02-20 16:56:58 <Cogitri> I can draft a ML post later on, I'll first test if this works
2020-02-20 16:56:59 <nmeum> Cogitri: right, neither do I. I am just saying it would be good to document this somewhere so new aports don't make this mistake et cetera
2020-02-20 16:57:04 <Ariadne> since apk-tools 2.10.5 i keep having to fix my builder
2020-02-20 16:57:11 <Ariadne> because of this
2020-02-20 16:57:26 <Cogitri> nmeum: Yes, will make a ML post and I suppose adjust the wiki
2020-02-20 16:57:47 <nmeum> Cogitri: ok, thanks!
2020-02-20 16:58:03 <nmeum> (you don't have to adjust the wiki if don't agree that it is a good idea, just a pruposal of mine)
2020-02-20 16:58:07 <nmeum> *you
2020-02-20 17:01:12 <Ariadne> i see
2020-02-20 17:01:16 <Ariadne> the version field
2020-02-20 17:01:23 <Ariadne> patch was dropped with 2.10.5 ?
2020-02-20 17:03:44 <Ariadne> i think the version field is replaced by uninitialised memory
2020-02-20 17:04:10 <Ariadne> fabled: ping
2020-02-20 17:21:05 <Cogitri> nmeum: Sent a post to the ML, let's hope I didn't mess it up
2020-02-20 17:21:19 <Cogitri> https://lists.alpinelinux.org/~alpine/devel/%3C2896c13070c508a49cbaa72c8fb7f34ea947358b.camel%40cogitri.dev%3E Seems to have worked
2020-02-20 17:21:49 <Cogitri> Also included some numbers which show the differences between the buildmodes (they're significant)
2020-02-20 17:21:52 <Ariadne> fixed it
2020-02-20 17:21:55 <Ariadne> nvm
2020-02-20 17:37:51 <Cogitri> How do I reply to my own mail on the ML?
2020-02-20 17:38:16 <_ikke_> reply to the one in your sent e-mails
2020-02-20 17:38:52 <Cogitri> Ah alrighty, thanks
2020-02-20 17:42:17 <mps> Cogitri: do you have 'reply-to-list' option in your mail client
2020-02-20 17:43:40 <Cogitri> Yes, Evolution displays that when I get a mail from someone else on the ML
2020-02-20 17:43:50 <Cogitri> That replies to both the person and the ML
2020-02-20 17:45:58 <_ikke_> If I use list-reply in mutt, it only sends it to the list back, not the person that sent it
2020-02-20 17:46:04 <mps> hmm, why to reply to both?
2020-02-20 17:46:21 <_ikke_> etiquette in at least some mailin lists
2020-02-20 17:46:54 <Ariadne> new idea: get rid of the damn mailing lists entirely
2020-02-20 17:46:55 <_ikke_> It means people don't have to be subscribed to see replies
2020-02-20 17:47:02 <Ariadne> replace with forum
2020-02-20 17:47:03 <Ariadne> :D
2020-02-20 17:47:05 <_ikke_> :D:D
2020-02-20 17:47:17 <maxice8> Unironically would be better
2020-02-20 17:47:22 <Ariadne> 
ACTION is very tired of hearing about mailing lists

2020-02-20 17:47:24 <mps> etiquette is to not reply to original sender but just to ML, afaik
2020-02-20 17:47:30 <Cogitri> I dislike both MLs and forums
2020-02-20 17:47:53 <MY-R> mps, that is how I thought too
2020-02-20 17:48:01 <Ariadne> Cogitri: great, but we need a single source of truth and gitlab is too busy for that
2020-02-20 17:48:40 <_ikke_> it does mean outside people cannot easily use the mailing list without requiring them to subscribe
2020-02-20 17:48:52 <Cogitri> I think a seperate gitlab repo for such things would be the way to go
2020-02-20 17:49:03 <_ikke_> ie, if you just want to report one issue
2020-02-20 17:49:04 <Ariadne> smells very fedora
2020-02-20 17:49:07 <Ariadne> with their FESCo
2020-02-20 18:06:26 <mps> Ariadne: I agree, IRC is enough :)
2020-02-20 18:06:36 <Ariadne> i have to disagree there
2020-02-20 18:06:44 <Ariadne> that is not acceptable
2020-02-20 18:07:01 <Ariadne> because 2 years from now, some decision you make in IRC is going to mess me up
2020-02-20 18:07:18 <mps> well, at the end nothing is acceptable
2020-02-20 18:07:19 <Ariadne> and i am going to be looking everywhere to find out more about this decision
2020-02-20 18:07:44 <MY-R> #6000
2020-02-20 18:07:47 <MY-R> :D
2020-02-20 18:08:43 <Ariadne> if mailing lists are not what people want to use, fine but we need some way of recording major changes and their associated discussions
2020-02-20 18:08:54 <Ariadne> because those are used for future reference
2020-02-20 18:09:10 <Ariadne> i really do not care what that mechanism is
2020-02-20 18:09:22 <Ariadne> if people want to do it fedora-style and use tracking bugs
2020-02-20 18:09:27 <Ariadne> that sounds good to me
2020-02-20 18:09:39 <MY-R> isnt Issues GL page for that?
2020-02-20 18:10:02 <Ariadne> gitlab issues is for smaller scope
2020-02-20 18:10:15 <Ariadne> this would involve creating a new issue type i guess
2020-02-20 18:10:17 <Ariadne> or a new repo
2020-02-20 18:10:23 <Ariadne> that is strictly a tracker
2020-02-20 18:11:14 <Ariadne> _ikke_: ping
2020-02-20 18:11:43 <_ikke_> Pong
2020-02-20 18:12:00 <Ariadne> _ikke_: https://distfiles.dereferenced.org/rpi-5.4.21.patch
2020-02-20 18:14:01 <Cogitri> 
ACTION votes for having a tracking repo

2020-02-20 18:14:39 <_ikke_> Ariadne: done
2020-02-20 18:15:50 <Ariadne> _ikke_: thanks
2020-02-20 18:23:45 <_ikke_> mps: ping
2020-02-20 18:24:15 <_ikke_> n/m
2020-02-20 18:31:24 <_ikke_> Ariadne: can this be closed or commented on? https://gitlab.alpinelinux.org/alpine/aports/issues/9856
2020-02-20 18:31:40 <Ariadne> _ikke_: it can be closed
2020-02-20 18:31:50 <Ariadne> i'll take care of it
2020-02-20 18:31:53 <_ikke_> Ok
2020-02-20 18:31:55 <mps> _ikke_: pong
2020-02-20 18:31:56 <Ariadne> once i finish 5.4.21 bump
2020-02-20 18:32:02 <_ikke_> nod
2020-02-20 18:37:01 <_ikke_> PureTryOut[m]: Would it make sense to remove the 3.12 milestone from https://gitlab.alpinelinux.org/alpine/aports/issues/10735? As it doesn't seem something that necessarily needs to make 3.12
2020-02-20 18:38:05 <PureTryOut[m]> Yeah sure
2020-02-20 18:38:54 <_ikke_> (y)
2020-02-20 18:42:20 <mps> _ikke_: I saw ping from you?
2020-02-20 18:42:32 <_ikke_> mps: yes, but no longer necessary
2020-02-20 18:42:45 <_ikke_> I realized I have an aarch64 lxc containerm myself
2020-02-20 18:42:49 <mps> ok
2020-02-20 18:43:23 <Ariadne> hmm
2020-02-20 18:52:03 <Ariadne> welp, i have poked the bear, hopefully i don't get mauled
2020-02-20 18:53:12 <_ikke_> what?
2020-02-20 18:54:51 <Ariadne> qemu-openrc LXC fixes
2020-02-20 19:13:26 <Ariadne> ok
2020-02-20 19:13:28 <Ariadne> why does python3
2020-02-20 19:13:30 <Ariadne> depend on bluez
2020-02-20 19:17:03 <Ariadne> 
ACTION git blame

2020-02-20 19:17:18 <maxice8> bluetooth support
2020-02-20 19:17:43 <Ariadne> yes, i get that part
2020-02-20 19:17:50 <Ariadne> but it introduces a circular dependency
2020-02-20 19:18:01 <Ariadne> because bluez depends on glib, which depends on meson, which depends on python3
2020-02-20 19:18:10 <maxice8> I see
2020-02-20 19:18:14 <maxice8> time to write meson-c :D
2020-02-20 19:18:43 <Ariadne> so we need to split the bluetooth from python3 somehow
2020-02-20 19:19:32 <Ariadne> alternatively
2020-02-20 19:19:37 <Ariadne> we make glib use autoconf again
2020-02-20 19:19:41 <Ariadne> that would also break the cycle
2020-02-20 19:19:50 <maxice8> I think that is being removed upstream
2020-02-20 19:19:56 <Ariadne> yes, it is
2020-02-20 19:20:00 <maxice8> @Cogitri should know
2020-02-20 19:20:12 <Ariadne> at any rate
2020-02-20 19:20:21 <Ariadne> the distribution cannot be bootstrapped because of this circular dep
2020-02-20 19:20:41 <Ariadne> because git depends on python3
2020-02-20 19:20:48 <Ariadne> and alpine-sdk depends on git
2020-02-20 19:21:35 <Ariadne> so while a meson-c sounds nice
2020-02-20 19:21:43 <Ariadne> it's not going to exist in the next day or two
2020-02-20 19:21:55 <Ariadne> meanwhile this circular dep is a release critical bug
2020-02-20 19:24:58 <Cogitri> Let's not use autocpnft
2020-02-20 19:24:59 <Cogitri> autoconf*
2020-02-20 19:25:00 <Cogitri> It's terrible
2020-02-20 19:25:40 <Cogitri> Also, doesn't it only need the headers?
2020-02-20 19:25:52 <Ariadne> i don't know
2020-02-20 19:26:02 <Ariadne> you're the one who introduced the circular dep by making python3 depend on bluez-dev
2020-02-20 19:26:05 <Cogitri> I don't think it links against bluez
2020-02-20 19:26:06 <Ariadne> you tell me :)
2020-02-20 19:26:13 <Ariadne> that is great
2020-02-20 19:26:16 <Ariadne> but i cannot build bluez
2020-02-20 19:26:21 <Ariadne> because i do not have python3
2020-02-20 19:26:26 <Cogitri> So we can just include the tarball if we need to
2020-02-20 19:26:35 <Ariadne> well
2020-02-20 19:26:43 <Ariadne> if you can figure out how to break the circular dep by doing so
2020-02-20 19:26:46 <Ariadne> please do so :)
2020-02-20 19:27:02 <Cogitri> Will do later
2020-02-20 19:27:07 <Ariadne> then i revert it now
2020-02-20 19:27:11 <Ariadne> and we fix later
2020-02-20 19:37:04 <Cogitri> Sure
2020-02-20 19:43:52 <Ariadne> Cogitri: i'll dig into it this weekend if you've not found a solution by then.  thanks for your understanding :)
2020-02-20 19:45:00 <Cogitri> Alrighty then
2020-02-20 19:45:23 <Ariadne> there is another circular dep that i think makes no sense
2020-02-20 19:45:35 <Ariadne> tcl depends on sqlite-dev, sqlite depends on tcl-dev
2020-02-20 19:46:02 <Ariadne> i think we need a CI script that can check for circular deps
2020-02-20 19:59:18 <vkrishn> andypost[m]: hi, if your at upgrading php7, would it be possible to look at https://www.php.net/manual/en/dba.installation.php and see if adding lmdb is possible ?
2020-02-20 19:59:33 <vkrishn> if you are*
2020-02-20 20:01:14 <andypost[m]> vkrishn: goot idea, please file issue to explore
2020-02-20 20:02:21 <fabled> Ariadne, I thought I picked up all the neeeded patches on the virtual package side of things... sigh.
2020-02-20 20:02:31 <Ariadne> you did
2020-02-20 20:02:33 <Ariadne> it turned out
2020-02-20 20:02:36 <vkrishn> ok
2020-02-20 20:02:44 <fabled> ok
2020-02-20 20:02:44 <Ariadne> my builder was on some broken 2.10.4
2020-02-20 20:02:54 <Ariadne> i'm not sure why that happened exactly
2020-02-20 20:33:25 <_ikke_> Ariadne: ci for circular deps is planned
2020-02-20 20:34:44 <Ariadne> _ikke_: sick
2020-02-20 20:35:27 <_ikke_> Just to think of a good way to detect it
2020-02-20 21:07:06 <_ikke_> Ariadne: seems like you forgot to update checksums for rtl8821ce-lts
2020-02-20 21:07:45 <_ikke_> or mayby I should make sure the archive name is not dependent on the kernel version
2020-02-20 21:17:24 <_ikke_> Anyone knows a posix shell way to get the first n characters of a string without using external commands?
2020-02-20 21:20:13 <maxice8> --repositories-file from fetch doesn't accept a relative path, is that by design ?
2020-02-20 21:20:46 <maxice8> apk fetch --repositories-file remote-repos redo-c fails but apk fetch --repositories-file $PWD/remote-repos redo-c works
2020-02-20 21:22:45 <Ariadne> yes
2020-02-20 21:22:53 <_ikke_> Ariadne: fixed it
2020-02-20 21:23:55 <Ariadne> there's other issues with that package
2020-02-20 21:25:42 <_ikke_> ah ok
2020-02-20 21:26:30 <_ikke_> ugh, I changed something and forgot to update checksums
2020-02-20 22:15:13 <dsmster> is it safe to change the -j1 in kernel apk to -j ?
2020-02-20 22:15:51 <Cogitri> Ariadne: !4327
2020-02-20 22:16:20 <Cogitri> dsmster: Probably
2020-02-20 22:16:24 <mps> dsmster: not sure, though I do it when I build 'my' kernels
2020-02-20 22:16:43 <mps> it is for some reason in APKBUILD
2020-02-20 22:17:13 <Ariadne> Cogitri: i would rather just include bluetooth.h in the port
2020-02-20 22:18:00 <Cogitri> I don't see the advantage other than saving a few kb to download
2020-02-20 22:18:16 <Cogitri> And that'd be more effort and make the git history not as nice
2020-02-20 22:18:39 <Ariadne> let me correct what i mean
2020-02-20 22:18:44 <Ariadne> i would rather there be a package
2020-02-20 22:18:49 <Ariadne> that contains bluetooth.h
2020-02-20 22:18:54 <Ariadne> that is not built from bluez sources
2020-02-20 22:19:01 <Ariadne> since it defines a "kernel interface"
2020-02-20 22:19:09 <dsmster> thanks, will prob give it a try next time im in a hurry :-)
2020-02-20 22:19:23 <Ariadne> and then python and bluez
2020-02-20 22:19:26 <Cogitri> It's only required for python3, so I don't see the point of a package either
2020-02-20 22:19:30 <Ariadne> both depend on this bluetooth-headers package
2020-02-20 22:19:47 <Cogitri> Why would bluez depend on its own headers?
2020-02-20 22:19:52 <Ariadne> Cogitri: then i would rather patch the appropriate constants
2020-02-20 22:19:56 <Ariadne> Cogitri: into python3 directly
2020-02-20 22:20:13 <Ariadne> i don't like this hacking the CFLAGS thing
2020-02-20 22:20:18 <Cogitri> Then I'd suggest you add that in python3 upstream
2020-02-20 22:20:28 <Ariadne> sure
2020-02-20 22:20:34 <Ariadne> what i am saying is
2020-02-20 22:20:35 <Cogitri> How is setting an include path a hack?
2020-02-20 22:20:39 <Ariadne> lets just patch python
2020-02-20 22:20:41 <Ariadne> and then
2020-02-20 22:20:44 <Ariadne> upstream the patch
2020-02-20 22:21:07 <Cogitri> If you're comfortable patching python that's fine by me
2020-02-20 22:21:55 <Ariadne> i don't see what the problem is
2020-02-20 22:22:08 <Ariadne> i am comfortable not having AF_BLUETOOTH
2020-02-20 22:22:10 <Ariadne> (:
2020-02-20 22:22:22 <Cogitri> Well, so am I, but users apparently want it
2020-02-20 22:22:35 <Cogitri> And I really don't see the problem with setting the include path
2020-02-20 22:22:59 <Ariadne> because its hacks on hacks
2020-02-20 22:23:20 <Ariadne> what if there are other things
2020-02-20 22:23:23 <Ariadne> that do not use bluez
2020-02-20 22:23:26 <Ariadne> but need the headers
2020-02-20 22:23:36 <Cogitri> I don't know of any
2020-02-20 22:23:38 <Ariadne> i really think a standalone bluez headers package makes most sense
2020-02-20 22:23:48 <Ariadne> or alternatively
2020-02-20 22:23:53 <Ariadne> what if we just put
2020-02-20 22:23:56 <Ariadne> bluetooth/bluetooth.h
2020-02-20 22:24:01 <Ariadne> in linux-headers
2020-02-20 22:24:04 <Cogitri> We only need that package for things that cause circular deps in the base
2020-02-20 22:24:16 <Cogitri> Other things can depend on bluez-dev just fine
2020-02-20 22:24:24 <Cogitri> So nothing but python3 will depend on that headers package
2020-02-20 22:24:29 <Ariadne> well
2020-02-20 22:24:30 <Ariadne> whatever
2020-02-20 22:24:36 <Ariadne> just fucking merge it
2020-02-20 22:24:39 <Ariadne> if it breaks anything
2020-02-20 22:24:42 <Ariadne> you get to fix it
2020-02-20 22:49:12 <Ariadne> oh wait
2020-02-20 22:49:18 <Ariadne> Cogitri: you need me to merge this don't you
2020-02-20 22:49:25 <Ariadne> i'll do it once CI finishes
2020-02-20 22:49:32 <Cogitri> Thanks
2020-02-20 22:49:36 <maxice8> He already went to sleep
2020-02-20 22:49:36 <Ariadne> i am not enthusiastic about this solution tho
2020-02-20 22:49:36 <maxice8> oh
2020-02-20 22:50:35 <Cogitri> It's not amazing, but the alternatives don't seem great either
2020-02-21 02:22:48 <fabreeze> hello
2020-02-21 02:22:55 <maxice8> hello
2020-02-21 02:23:46 <fabreeze> I was trying to build Wazuh agent from source. Ran into a problem with pthread.h. I'm wondering if it's because of a difference between glibc and musl libc
2020-02-21 02:24:09 <fabreeze> implicit declaration of function 'pthread_rwlockattr_setkind_np'; did you mean 'pthread_rwlockattr_setpshared'?
2020-02-21 02:25:01 <fabreeze> It's also missing: PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
2020-02-21 02:28:18 <Ariadne> those are glibc extensions
2020-02-21 02:28:30 <Ariadne> most likely you can just remove the calls to pthread_rwlockattr_setkind_np
2020-02-21 02:28:36 <Ariadne> as it just sets a hint
2020-02-21 02:30:45 <fabreeze> Oh, I see. Thanks for the tip!
2020-02-21 03:00:31 <Danct12[m]> powerpc runner seems to be down
2020-02-21 03:07:28 <fabreeze> I was able to get wazuh-agent installed and connected to a wazuh server successfully
2020-02-21 03:13:49 <Ariadne> fabreeze: you should contribute the package to alpine :)
2020-02-21 05:29:13 <maxice8> @ikke ping
2020-02-21 05:33:51 <_ikke_> maxice8: pong
2020-02-21 05:34:06 <maxice8> I'm working on the secfixes check script;
2020-02-21 05:34:12 <_ikke_> ok
2020-02-21 05:37:45 <maxice8> @ikke http://ix.io/2chl
2020-02-21 05:38:35 <_ikke_> nice
2020-02-21 05:38:47 <maxice8> It also loads up the yaml (after some fixes) to validate it
2020-02-21 05:38:50 <_ikke_> maybe also check if they provided a map instead of a list? (ie, missing -)
2020-02-21 05:43:36 <maxice8> it triggers an  assert
2020-02-21 05:44:57 <maxice8> @ikke https://raw.githubusercontent.com/maxice8/meltryllis/master/bin/secfixes-check Here is the script
2020-02-21 05:46:44 <_ikke_> s/color/colon :P
2020-02-21 05:46:54 <maxice8> yeah i can fix typos later
2020-02-21 05:46:55 <maxice8> :D
2020-02-21 05:53:15 <_ikke_> Those comments on the end, are they remnants?
2020-02-21 05:53:33 <maxice8> the last 2 comments ?
2020-02-21 05:53:44 <_ikke_> yes
2020-02-21 05:53:55 <maxice8> No
2020-02-21 05:54:17 <maxice8> I have no actual checks i can think of in the # secfixes: header
2020-02-21 05:55:56 <_ikke_> Ok, becuase jut uncommenting that if would lead to invalid syntax, but I guess the implication is that you would then provide the rest I guess
2020-02-21 05:58:15 <maxice8> Updated, please refresh
2020-02-21 05:59:56 <maxice8> Do we want a separate AL for each type of violation or just one AL ?
2020-02-21 06:05:51 <_ikke_> I guess separate
2020-02-21 06:07:03 <_ikke_> Maybe one for the the different CVE formatting issues
2020-02-21 06:07:25 <maxice8> Maybe one for each type of field
2020-02-21 06:07:35 <maxice8> All of the errors basically mean, malformed value
2020-02-21 06:08:19 <maxice8> Have 3 ALs one for secfixes, one for pkgver-pkgrel and one for CVE Identifiers
2020-02-21 06:53:53 <mps> dalias: congrats :)
2020-02-21 07:02:33 <maxice8> @ikke http://ix.io/2chB
2020-02-21 07:02:36 <maxice8> :D
2020-02-21 07:03:41 <reidrankin> can I get somebody to look at !4056? I've just had to rebase for like the 5th time
2020-02-21 07:31:21 <Cogitri> Sadly I don't have the bits for main/
2020-02-21 07:31:34 <Cogitri> So maxice8: ^ maybe?
2020-02-21 07:32:03 <maxice8> No, I'm going to take a nap
2020-02-21 08:42:31 <AinNero> the weechat 2.7.1 upgrade had a unmentioned secfix, https://weechat.org/doc/security/
2020-02-21 08:42:42 <AinNero> i wish for it to be backported to the stable branches
2020-02-21 08:42:59 <AinNero> a30886e9a on master
2020-02-21 08:44:01 <AinNero> ping maxice8
2020-02-21 08:50:23 <_ikke_> can be backported to 3.11
2020-02-21 08:51:47 <_ikke_> AinNero: do you need it on older versions?
2020-02-21 08:52:00 <AinNero> on 3.10
2020-02-21 08:52:19 <_ikke_> That probably would require extracting a patch
2020-02-21 08:52:36 <AinNero> then ill upgrade the machine to 3.11 instead
2020-02-21 10:06:28 <_ikke_> Heh, clandmeter is spelunking
2020-02-21 10:06:35 <_ikke_> fixing packages in 3.2
2020-02-21 10:06:51 <_ikke_> secfixes
2020-02-21 10:21:13 <clandmeter> splwhat?
2020-02-21 10:22:46 <_ikke_> https://duckduckgo.com/?t=ffab&q=spelunking&atb=v171-1&iax=images&ia=images
2020-02-21 10:24:40 <clandmeter> its nice to have it correct even if not supported anymore.
2020-02-21 10:25:35 <_ikke_> nod
2020-02-21 11:08:47 <Danct12[m]> how to get current arch from apkbuild?
2020-02-21 11:09:47 <Danct12[m]> how do i get current arch from apkbuild?
2020-02-21 11:10:11 <Cogitri> $CARCH
2020-02-21 11:10:43 <Cogitri> Not sure if you got that since you joined again apparently: You can get that via $CARCH
2020-02-21 11:13:50 <Danct12[m]> thank you, will try
2020-02-21 11:19:20 <Danct12[m]> Cogitri: is this the same for post-install as well, right?
2020-02-21 11:27:25 <_ikke_> Danct12[m]: No, post-install runs in a different context
2020-02-21 11:40:08 <_ikke_> Trying to build minio (to try to troubleshoot something) on my aarch64 container, but I keep getting this error: can't load package: package github.com/minio/minio: build constraints exclude all Go files in /home/build/aports/testing/minio/src/minio-RELEASE.2020-02-07T23-28-16Z
2020-02-21 11:40:18 <_ikke_> Anyone know why / how to get around that?
2020-02-21 11:43:23 <_ikke_> ok, pebkac, had set my edge container to a stable release
2020-02-21 11:57:41 <AinNero> _ikke_: did something happen with the weechat upgrade?
2020-02-21 12:03:40 <_ikke_> AinNero: no, not yet
2020-02-21 12:03:50 <_ikke_> I can do it this evening if Cogitri didn't get to it yet
2020-02-21 12:15:36 <Cogitri> I think you meant maxice8?
2020-02-21 12:15:50 <Cogitri> Danct12[m]: Not sure what's the best way to do it, but I guess uname would work then?
2020-02-21 12:17:45 <_ikke_> Cogitri: yes, I meant maxice8.
2020-02-21 12:49:04 <Danct12[m]> is ppc and ppc64, ppc64api32 compatible?
2020-02-21 12:49:21 <Danct12[m]> no idea about ppc platform
2020-02-21 12:57:04 <PureTryOut[m]> Is any effort being done to upstream the patches required to make Chromium work on Alpine?
2020-02-21 13:12:23 <Cogitri> Since ncopa drafts most of those I suppose he'd know
2020-02-21 13:16:26 <PureTryOut[m]> I'm asking as most patches that are applied to qt5-qtwebengine are patches to the internal Chromium, and 9 out of 10 just apply as is to qt5-qtwebengine 5.14.1 as well. Basically indicating they have not been upstreamed
2020-02-21 13:34:45 <maxice8> @ikke atools-18.12.0 'Grani' is out
2020-02-21 13:34:57 <_ikke_> (y)
2020-02-21 13:35:52 <maxice8> ?
2020-02-21 13:37:19 <_ikke_> Sorry, that's the shortcut for a thumbs-up emoticon
2020-02-21 13:37:27 <maxice8> oh, like +1
2020-02-21 13:48:27 <clandmeter> It doesn't work for my client
2020-02-21 13:49:04 <_ikke_> :)
2020-02-21 13:49:20 <clandmeter> That one does
2020-02-21 13:52:21 <Danct12[m]> i'm upstreaming a binfmt_misc config file..
2020-02-21 13:52:27 <Danct12[m]> which license should be used for a config file?
2020-02-21 14:25:26 <clandmeter> maxice8: i guess you dont need my help anymore for the sec checker?
2020-02-21 14:40:54 <Danct12[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4337
2020-02-21 14:40:57 <Danct12[m]> can anyone check out this merge request?
2020-02-21 14:42:04 <_ikke_> Danct12[m]: https://gitlab.alpinelinux.org/Danct12/aports/-/jobs/53545 first feedback :)
2020-02-21 14:42:36 <_ikke_> Oh, it's an existing APKBUIDL
2020-02-21 14:42:38 <Danct12[m]> that's nice, it's not even my fault
2020-02-21 14:42:38 <_ikke_> APKBUILD
2020-02-21 14:42:41 <_ikke_> right
2020-02-21 14:43:03 <Danct12[m]> yes, it's an already existing one
2020-02-21 14:43:11 <Danct12[m]> you can already tell by looking at the changes
2020-02-21 14:43:40 <_ikke_> Yes, I did that after looking at the CI output
2020-02-21 15:39:19 <maxice8> @clandmeter I didn't write a test suite
2020-02-21 15:40:02 <_ikke_> maxice8: I can do that if you want
2020-02-21 15:40:16 <maxice8> Ah good
2020-02-21 15:40:22 <maxice8> As long as someone does it :D
2020-02-21 16:26:47 <_ikke_> maxice8: did you get to backporting weechat?
2020-02-21 16:26:58 <maxice8> Nope
2020-02-21 16:27:03 <maxice8> i did get into forgetting to do it, successfully :D
2020-02-21 16:27:10 <_ikke_> hehe
2020-02-21 16:27:15 <_ikke_> until know ;-)
2020-02-21 16:27:19 <_ikke_> I'll do it
2020-02-21 16:27:21 <_ikke_> then
2020-02-21 16:27:32 <maxice8> o-oh
2020-02-21 16:27:34 <maxice8> ok then
2020-02-21 16:27:44 <_ikke_> Unless you insist in doing it :)(
2020-02-21 16:27:52 <maxice8> I don't
2020-02-21 16:27:54 <_ikke_> ok
2020-02-21 16:28:39 <_ikke_> s/know/now
2020-02-21 16:28:40 <alpine-meetbot> _ikke_ meant to say: until now ;-)
2020-02-21 16:29:28 <afontain_> ninja'd
2020-02-21 16:38:19 <xrs> hey guys, please have a look at this: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1907
2020-02-21 16:41:28 <maxice8> There are 27 commits, please reduce them to 1 per-package
2020-02-21 16:42:37 <Cogitri> I still think launching a process for each user via openrc is pretty bad
2020-02-21 16:43:07 <_ikke_> agreed
2020-02-21 16:43:10 <Cogitri> I think a pam module to start it on login would be a good way to solve this (but upstream would have to support that)
2020-02-21 16:43:13 <_ikke_> openrc should only be used for system processes
2020-02-21 16:43:26 <_ikke_> system services
2020-02-21 16:43:34 <Cogitri> Yes
2020-02-21 16:43:40 <_ikke_> openrc has no notion of user services
2020-02-21 16:43:48 <Cogitri> Sadly not, no
2020-02-21 16:45:41 <_ikke_> xrs: fyi, we try to be helpful, but packages that are added to aports should adhere to certain standards / policies
2020-02-21 16:46:20 <Cogitri> nmeum: So, how are you feeling about !4317 ? To be honest I don't expect more replies on the ML since that's pretty dead
2020-02-21 16:49:29 <Cogitri> Also, does it make sense to apply the fixes of that MR to packages in unmaintained?
2020-02-21 16:49:49 <_ikke_> I think it can make sense
2020-02-21 16:49:52 <Cogitri> I mean we don't build them anymore, but just in case that they're moved to testing/ again it'd make them correct from the get-go
2020-02-21 16:49:57 <_ikke_> yes
2020-02-21 16:50:00 <_ikke_> exactly
2020-02-21 16:50:11 <nmeum> Cogitri: feeling very good about. I am personally always a bit careful with merging larger changes without proper discussions. _ikke_ what's your opinion on this? imho it could just be pushed as is
2020-02-21 16:50:18 <nmeum> s/about/about it/
2020-02-21 16:50:19 <alpine-meetbot> nmeum meant to say: Cogitri: feeling very good about it. I am personally always a bit careful with merging larger changes without proper discussions. _ikke_ what's your opinion on this? imho it could just be pushed as is
2020-02-21 16:51:08 <_ikke_> nmeum: I don't know a lot about the intrincasies of all these build systems, but I agree with the premise that they should not override the flags we provide
2020-02-21 16:51:43 <nmeum> i mean: so you don't think that further discussion is needed?
2020-02-21 16:53:14 <_ikke_> Difficult for me to say, I'm not sure what the impact will be or potential drawbacks
2020-02-21 16:53:37 <Cogitri> A potential drawback is that we'll lose performance because we don't use such aggressive flags anymore
2020-02-21 16:53:40 <nmeum> the worst case impact is that some packages will run slower as they are compiled with -Os instead of -O2 now
2020-02-21 16:53:42 <xrs> _ikke_: yes, I know. I followed those standards and making differnt loops by following further instructions of the alpine devs
2020-02-21 16:53:46 <Cogitri> But in return packages will be smaller due to -Os
2020-02-21 16:54:11 <Cogitri> I guess we'll have a limited amount of packages which will fail due to not liking -Os
2020-02-21 16:54:25 <Cogitri> But that should be easily fixable in the APKBUILD
2020-02-21 16:54:29 <_ikke_> And I think that always was Alpine's policy, right? Prefer smaller packages over potential marginal speed improvements?
2020-02-21 16:54:35 <Cogitri> Yes
2020-02-21 16:54:36 <nmeum> I think it is more likely that we have failing packages because they haven't been rebuild in the past
2020-02-21 16:54:44 <Cogitri> Or that, yes
2020-02-21 16:54:46 <nmeum> e.g. packages which do not compile with a recent gcc et cetera
2020-02-21 16:55:01 <_ikke_> Maybe we could do it in phases?
2020-02-21 16:55:01 <Cogitri> Shouldn't such stuff be caught in stable releases?
2020-02-21 16:55:07 <_ikke_> start with testing or something like that?
2020-02-21 16:55:11 <nmeum> not for testing
2020-02-21 16:55:12 <Cogitri> Yes
2020-02-21 16:55:17 <Cogitri> Oh right, not for testing
2020-02-21 16:55:27 <nmeum> I can guarantee you that we will run into a bunch of build failures
2020-02-21 16:55:27 <Cogitri> Starting with testing sounds good, but those are the most packages I think
2020-02-21 16:55:35 <nmeum> but we can just fix those
2020-02-21 16:55:36 <_ikke_> nmeum: yes, that's bound to happen
2020-02-21 16:55:41 <nmeum> so that shouldn't keep us from merging this
2020-02-21 16:55:53 <Cogitri> Oh well, I'm free to fix those until later tonight :P
2020-02-21 16:56:06 <nmeum> how exactly did you generate the changes?
2020-02-21 16:56:21 <nmeum> did you automate the process?
2020-02-21 16:56:31 <Cogitri> http://dpaste.com/2Q9WZGH
2020-02-21 16:57:40 <Cogitri> Probably not the most amazing shell script, but AFAICS it did the trick
2020-02-21 16:58:20 <_ikke_> one-off shellscripts most of the time don't warant being written nice :)
2020-02-21 16:58:34 <Cogitri> Fair :P
2020-02-21 17:00:30 <nmeum> hmhm
2020-02-21 17:00:41 <nmeum> _ikke_: I would just go ahead and push it then I guess…
2020-02-21 17:02:05 <Cogitri> Let's see how the builders burn on testing/ :P
2020-02-21 17:04:04 <mps> so, alpine losing speed
2020-02-21 17:04:17 <nmeum> well not neccessarly
2020-02-21 17:04:28 <Ariadne> -Os is usually faster than -O2 on most hardware
2020-02-21 17:04:30 <nmeum> -Os isn't -O0
2020-02-21 17:04:36 <Ariadne> because of cache coherency
2020-02-21 17:04:46 <Ariadne> and -O3 is stupid
2020-02-21 17:04:50 <nmeum> hehe
2020-02-21 17:05:24 <Ariadne> alpine was once -O2 actually.
2020-02-21 17:05:45 <nmeum> also: our general assumption was that -Os is used as this is what we set in /etc/abuild.conf currently so moving the CMake / meson stuff to -Os is actually coherent with /etc/abuild.conf
2020-02-21 17:05:48 <Ariadne> some optimizations done by -Os did not work well with uClibc on amd64
2020-02-21 17:06:25 <Ariadne> +1 for moving cmake/meson to -Os
2020-02-21 17:06:27 <xrs> maxice8: how do I reduce 27 commits to 1 per package?
2020-02-21 17:06:35 <Ariadne> xrs: git rebase --interactive
2020-02-21 17:06:36 <_ikke_> xrs: interactive rebase
2020-02-21 17:06:40 <maxice8> git rebase --interactive
2020-02-21 17:06:48 <xrs> oki :-)
2020-02-21 17:06:50 <_ikke_> or reset reset the commits and recommit
2020-02-21 17:06:58 <Ariadne> i am committing some serious crimes right now
2020-02-21 17:07:04 <_ikke_> s/reset the/the/
2020-02-21 17:07:04 <alpine-meetbot> _ikke_ meant to say: or reset the commits and recommit
2020-02-21 17:07:21 <Ariadne> OpenWRT kernels have hacks on hacks, can't be fucked with it
2020-02-21 17:07:24 <Cogitri> mps: If we want higher speed we can always add "-O3 -funroll-loops -flto" to our CFLAGS :P
2020-02-21 17:07:31 <Ariadne> so going to combine OpenWRT kernel with Alpine userspace
2020-02-21 17:07:39 <mps> actually I don't have strong opinion about compiler optimization, sometimes even think it is not needed at all
2020-02-21 17:07:50 <Cogitri> It certainly is required
2020-02-21 17:08:03 <Cogitri> You wouldn't believe how slow an unoptimized, debugging kernel is :P
2020-02-21 17:08:04 <Ariadne> Cogitri: i actually want to enable -flto by default someday
2020-02-21 17:08:18 <nmeum> yeah, enabling link time optimization by default would be great
2020-02-21 17:08:25 <nmeum> though I assume that will break some builds
2020-02-21 17:08:29 <nmeum> *it
2020-02-21 17:08:31 <Ariadne> these things did not work well with uClibc though
2020-02-21 17:08:31 <Cogitri> Yes
2020-02-21 17:08:34 <Ariadne> musl seems fine with it :)
2020-02-21 17:08:37 <maxice8> mesa i know it breaks
2020-02-21 17:08:39 <Cogitri> But LTO introduces loads of build failures
2020-02-21 17:08:43 <Cogitri> And even some runtime failures
2020-02-21 17:08:53 <Cogitri> At some point we should really enable Polly and LTO though
2020-02-21 17:08:54 <_ikke_> https://gcc.gnu.org/wiki/LinkTimeOptimization
2020-02-21 17:09:00 <_ikke_> What is polly?
2020-02-21 17:09:01 <Cogitri> Even reduces size, so it's a win on all fronts
2020-02-21 17:09:05 <nmeum> pushed the newapkbuild meson / cmake change to abuild.git
2020-02-21 17:09:07 <Ariadne> _ikke_: math optimization
2020-02-21 17:09:12 <Cogitri> LLVM's way of doing Graphite
2020-02-21 17:09:13 <maxice8> Me or @Cogitri enabled -b_lto for meson in Void Linux some time ago and Mesa was one of the broken ones
2020-02-21 17:09:29 <Cogitri> I think we want to switch to CLang before flicking on LTO though
2020-02-21 17:09:40 <Ariadne> -1 for clang
2020-02-21 17:09:42 <Cogitri> CLang generally starts becoming pretty nice
2020-02-21 17:10:05 <nmeum> clang would also ease cross compilation
2020-02-21 17:10:10 <Cogitri> Yes
2020-02-21 17:10:15 <Ariadne> nmeum: not as much as you may think
2020-02-21 17:10:34 <Cogitri> And CLang has about equal code optimization these days and more advanced LTO
2020-02-21 17:10:35 <xrs> _ikke_: concerning gnunet services: maybe this is a confusion. the user services are services with less privileges.  they are still "system services" which the user should not see or operate with.
2020-02-21 17:10:43 <Ariadne> besides, i fixed qemu-binfmt service
2020-02-21 17:10:58 <Ariadne> if you want to cross compile just spin up an LXC container for the target arch
2020-02-21 17:10:59 <xrs> I could rename them..
2020-02-21 17:10:59 <Ariadne> ;)
2020-02-21 17:11:45 <nmeum> Ariadne: tell me about it, tried setting up a clang cross compiler for riscv recently. that was slightly annoying
2020-02-21 17:12:04 <Ariadne> riscv is also coming soon
2020-02-21 17:12:14 <nmeum> anyways: regarding the meson/cmake bulk change: I will just push it now. we'll do it live
2020-02-21 17:12:21 <Ariadne> the main blocker is that riscv boot sucks
2020-02-21 17:12:25 <Ariadne> majorly
2020-02-21 17:12:29 <_ikke_> xrs: but why is there a service per user?
2020-02-21 17:12:30 <nmeum> yep
2020-02-21 17:12:46 <nmeum> Cogitri: pushed
2020-02-21 17:13:11 <nmeum> did you just push your branch?
2020-02-21 17:13:41 <_ikke_> and regarding mailing list: people are more likely to respond (quickly) when they are opposed
2020-02-21 17:13:47 <xrs> _ikke_: you are right. these are services per user but not ment to be operated by them. They simply handle different datasets and those services can't be shared like the "system services".
2020-02-21 17:14:13 <Ariadne> _ikke_: right, that's why proposals are done on a "if nobody objects by $deadline" basis
2020-02-21 17:14:47 <nmeum> let's see how long it takes until it encounters the first build failure
2020-02-21 17:15:02 <Ariadne> i would like to eventually move to clang, but there are still a number of packages which do not build with it
2020-02-21 17:15:20 <nmeum> does the kernel build with clang nowadays?
2020-02-21 17:15:22 <_ikke_> what about hte linux kernel?
2020-02-21 17:15:24 <_ikke_> lol
2020-02-21 17:15:34 <Ariadne> i think it does, actually.
2020-02-21 17:15:37 <nmeum> wow
2020-02-21 17:15:43 <Cogitri> nmeum: I pushed some 10 minutes to rebase
2020-02-21 17:15:43 <nmeum> progress!
2020-02-21 17:15:45 <Ariadne> there are stuff in kconfigs about CLANG
2020-02-21 17:15:45 <_ikke_> But they don't officially support it, right?
2020-02-21 17:16:17 <nmeum> Cogitri: hm, merged it into my local master a while ago so not sure if those changes actually made it in. just push them separatly i guess
2020-02-21 17:16:18 <Cogitri> They do
2020-02-21 17:16:21 <_ikke_> ok
2020-02-21 17:16:22 <Ariadne> gcc still generates better bytecode density in many cases
2020-02-21 17:16:33 <Ariadne> -Os on clang is not so great
2020-02-21 17:16:35 <_ikke_> CI is failing atm apparently
2020-02-21 17:16:43 <mps> _ikke_: some people have success but it is still gcc
2020-02-21 17:16:45 <_ikke_> for Linux on clang
2020-02-21 17:17:05 <Cogitri> Ah, quite possibly, but upstream not at least cares a bit about it
2020-02-21 17:17:07 <Ariadne> and gcc has gotten a lot better
2020-02-21 17:17:09 <_ikke_> oh, failures are certain targets only
2020-02-21 17:17:14 <Cogitri> I think it did work for 5.4 or 5.5 though
2020-02-21 17:17:16 <Cogitri> Ah neat
2020-02-21 17:17:33 <_ikke_> https://travis-ci.com/ClangBuiltLinux/continuous-integration
2020-02-21 17:18:13 <Cogitri> nmeum: No worries, I only rebased to fix a few merge conflicts
2020-02-21 17:18:19 <Cogitri> Nothing of significants was added
2020-02-21 17:18:42 <nmeum> ok
2020-02-21 17:19:26 <Ariadne> root@GL-AR300M:/mnt/sda2/root/alpine-mips32# dd if=/dev/mtdblock3 of=kernel.bin bs=4096
2020-02-21 17:19:29 <Ariadne> crimes in progress
2020-02-21 17:19:32 <Ariadne> lol
2020-02-21 17:20:46 <_ikke_> Look officer, this person right here :)
2020-02-21 17:21:04 <Ariadne> root@GL-AR300M:/# file root/kernel.bin
2020-02-21 17:21:04 <Ariadne> root/kernel.bin: u-boot legacy uImage, MIPS OpenWrt Linux-4.9.120, Linux/MIPS, OS Kernel Image (lzma), 1549810 bytes, Thu Aug 16 07:51:15 2018, Load Address: 0x80060000, Entry Point: 0x80060000, Header CRC: 0xD0BFA581, Data CRC: 0x56638C0A
2020-02-21 17:21:12 <Ariadne> looks like my assumption is accurate
2020-02-21 17:22:14 <mps> I think I have one mips32 box in garage, not sure if it can work still
2020-02-21 17:22:38 <Ariadne> mps: http://as57335.net/static/alpine-mips64/packages/main/mips
2020-02-21 17:22:40 <Ariadne> have fun
2020-02-21 17:22:45 <mps> maybe I could try openwrt first on it
2020-02-21 17:23:50 <Ariadne> thats boring
2020-02-21 17:23:56 <Ariadne> do things the hard way
2020-02-21 17:25:45 <mps> I'm not sure if it can work at all
2020-02-21 17:26:10 <Cogitri> 
ACTION remembers that I should probably upgrade my router

2020-02-21 17:26:24 <Cogitri> Oh my, it's on OpenWRT 18.0.4 and 19.0.7.1 is the newest version
2020-02-21 17:26:26 <Ariadne> kernel.bin:  u-boot legacy uImage, MIPS OpenWrt Linux-4.9.120, Linux/MIPS, OS Kernel Image (lzma), 1549810 bytes, Thu Aug 16 07:51:15 2018, Load Address: 0x80060000, Entry Point: 0x80060000, Header CRC: 0xD0BFA581, Data CRC: 0x56638C0A
2020-02-21 17:26:26 <Ariadne> squash1.bin: Squashfs filesystem, little endian, version 1024.0, compressed, 4922325541064802304 bytes, -452198400 inodes, blocksize: 1024 bytes, created: Mon Mar 17 09:43:57 1919
2020-02-21 17:26:26 <Ariadne> squash2.bin: Linux jffs2 filesystem data big endian
2020-02-21 17:26:28 <Ariadne> fascinating
2020-02-21 17:26:40 <Ariadne> Cogitri: upgrade to AlpineWRT
2020-02-21 17:27:01 <Cogitri> I think I'm fine with OpenWRT for now :P
2020-02-21 17:27:02 <nmeum> Cogitri: openwrt actually had in rce in opkg in the meantime (iirc) ;)
2020-02-21 17:27:05 <Cogitri> I like my router to just work
2020-02-21 17:27:20 <Cogitri> Oh huh, so good job me avoiding that by not upgrading in time :P
2020-02-21 17:30:19 <reidrankin> maybe now that it's daytime someone's on that can look at !4056? (pretty please?)
2020-02-21 17:33:13 <Cogitri> By the way, do we have some plans for time64_t on 32-bit already w/ musl 1.2?
2020-02-21 17:33:17 <reidrankin> very small change, lets you use install packages with kernel modules (read: wireguard) on run-from-RAM installs
2020-02-21 17:34:27 <mps> Cogitri: https://wiki.adelielinux.org/wiki/Project:Time64 good intro
2020-02-21 17:36:11 <Cogitri> Ah neat, thanks
2020-02-21 17:36:38 <Cogitri> maxice8: Mind taking a look at the change of reidrakin ?
2020-02-21 17:37:13 <mps> awilfox from adelie linux already tested lot of 'things'
2020-02-21 17:38:02 <_ikke_> AinNero: weechat is upgraded on 3.11
2020-02-21 17:40:43 <Danct12[m]> I've opened a issue on this qemu recvmsg: message too long thing
2020-02-21 17:40:44 <Danct12[m]> https://gitlab.alpinelinux.org/alpine/aports/issues/11243
2020-02-21 17:41:13 <Danct12[m]> right now the x86 chroot on arm64 works, but it's not fun because you can't use networking
2020-02-21 17:42:04 <Danct12[m]> networking seems to work fine on glibc distro (arch linux) though
2020-02-21 17:43:14 <maxice8> @ikke shouldn't we use 2 spaces indentation for - CVE ?
2020-02-21 17:43:27 <maxice8> i mean 2 more than then pkgver-pkgrel: header ?
2020-02-21 17:43:48 <_ikke_> maxice8: I was doubting, but using the same style as was already present
2020-02-21 17:44:11 <maxice8> Both seem to be valid yaml as far as i can tell
2020-02-21 17:44:27 <_ikke_> yes, they are
2020-02-21 17:44:41 <_ikke_> checking if there is a semantic difference
2020-02-21 17:47:32 <_ikke_> semantically they appear to be the same
2020-02-21 17:47:35 <_ikke_> so it's a matter of style then
2020-02-21 17:51:46 <maxice8> secfixes-check expects - CVE-YYYY-XXXX... to have 4 whitespaces
2020-02-21 17:52:10 <_ikke_> Nod, but we should normalize that everywhere then
2020-02-21 17:52:21 <_ikke_> or relax that
2020-02-21 17:52:49 <maxice8> Someone will have to write the lua to deal with same whitespace between pkgver-pkgrel headers and CVE identifiers
2020-02-21 18:07:22 <nmeum> is it just me or is the build-edge{aarch64,armv7,ppc64le,s390x} builder displayed as "failed" on build.alpinelinux.org without further information?
2020-02-21 18:11:11 <Cogitri> Same here
2020-02-21 18:11:13 <Cogitri> Just wanted to ask about that
2020-02-21 18:11:26 <nmeum> did they fail while upgrading the system? (CC: _ikke_, clandmeter)
2020-02-21 18:15:59 <_ikke_> hmm, not sure
2020-02-21 18:16:11 <_ikke_> normally it should show a failed pacakge
2020-02-21 18:18:26 <nmeum> _ikke_: but what if running "apk upgrade" fails?
2020-02-21 18:18:51 <Cogitri> Yup
2020-02-21 18:18:53 <_ikke_> I'll check
2020-02-21 18:18:57 <nmeum> thanks
2020-02-21 18:20:26 <Ariadne> it would be nice if we could eliminate the ncurses-terminfo dependency
2020-02-21 18:22:06 <_ikke_> sh: ./APKBUILD: line 17: syntax error: unexpected redirection
2020-02-21 18:22:30 <_ikke_> Not sure which one
2020-02-21 18:22:45 <nmeum> wow
2020-02-21 18:22:51 <nmeum> which aport?
2020-02-21 18:23:03 <_ikke_> trying to find out
2020-02-21 18:24:48 <Cogitri> I guess my script didn't handle pkgver being a variable itself
2020-02-21 18:25:43 <nmeum> I didn't notice any broken pkgvers
2020-02-21 18:26:14 <Cogitri> Neither did I, but the builders don't like it  apparently
2020-02-21 18:27:31 <nmeum> Cogitri: I think you commited testing/gnome-fragments by accident with 539c11eaf78c3222296d07f8ef36572563ffd918
2020-02-21 18:28:33 <Cogitri> Oof
2020-02-21 18:28:34 <Cogitri> Rigjt
2020-02-21 18:28:48 <Cogitri> I should stop keeping things I don't want to commit right now in the dir
2020-02-21 18:28:51 <nmeum> that abuild looks ok though
2020-02-21 18:28:58 <nmeum> as in: it shouldn't cause the failure
2020-02-21 18:29:49 <Cogitri> Yup
2020-02-21 18:30:02 <Cogitri> I did build it, so it's not that much of a problem that it's in now
2020-02-21 18:33:10 <nmeum> found it
2020-02-21 18:33:26 <Cogitri> Oh?
2020-02-21 18:33:33 <Cogitri> Curious what it is now
2020-02-21 18:33:39 <nmeum> merge commit marker
2020-02-21 18:33:43 <nmeum> merge conflict marker
2020-02-21 18:34:51 <Cogitri> Oh
2020-02-21 18:35:02 <Cogitri> So who of us introduced that? :P
2020-02-21 18:35:22 <_ikke_> calindori
2020-02-21 18:35:32 <nmeum> dcf16f1d23d6ed300d529d0cbdfc5c9061dcef70
2020-02-21 18:35:33 <nmeum> fixed
2020-02-21 18:35:45 <Cogitri> Nice
2020-02-21 18:36:06 <nmeum> _ikke_: thanks! :)
2020-02-21 18:36:10 <_ikke_> np
2020-02-21 18:36:54 <_ikke_> git diff --check checks for conflict markers btw
2020-02-21 18:37:03 <nmeum> I didn't have any merge conflicts
2020-02-21 18:37:29 <_ikke_> I guess Cogitri already committed them with conflict markers
2020-02-21 18:37:48 <nmeum> maybe
2020-02-21 18:38:00 <_ikke_> well, *somebody* must :P
2020-02-21 18:39:44 <_ikke_> xrs: This is how archlinux does it: https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/gnunet
2020-02-21 18:39:46 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4317/diffs?commit_id=bf9ac021ffb8ff1d0c7fe65333f3b7f2c0f595e3#43af3ec94ee3248e73bcc4f225d09d53718df7e1_17_17
2020-02-21 18:39:50 <nmeum> was already in the mr
2020-02-21 18:39:57 <nmeum> but doesn't matter really now that it is fixed
2020-02-21 18:40:32 <_ikke_> nope
2020-02-21 18:40:48 <nmeum> whhopp first build failure
2020-02-21 18:40:55 <nmeum> kconfig fails on s390x with a test failure :S
2020-02-21 18:42:14 <Cogitri> Oh huh, apparently I did introduce those merge conflicts but I do remember fixing those
2020-02-21 18:42:22 <Cogitri> I think I forgot to git add :^)
2020-02-21 18:42:57 <nmeum> happens
2020-02-21 18:45:10 <mps> maxice8: _ikke_: re secfixes yaml, I noticed extra space long time ago but thought it is for some reason there
2020-02-21 18:46:29 <_ikke_> it's just a matter of style
2020-02-21 18:46:34 <_ikke_> some like it indented, some like it flush
2020-02-21 18:46:44 <xrs> _ikke_: thanks for the archlinux hint, but they are only going half of the way.
2020-02-21 18:47:01 <mps> yaml is 'two space' indentation
2020-02-21 18:47:30 <mps> btw, secfixes should be somewhere else and not in APKBUILD, imo
2020-02-21 18:47:37 <xrs> I'm trying to package gnunet like it is supposed to run. I'm know that because IΓ'm a member of the gnunet project. ^^
2020-02-21 18:48:08 <xrs> archlinux is only installing and running the system services.
2020-02-21 18:48:11 <_ikke_> mps: it's the source of the secfixes, but they are compiled into a database
2020-02-21 18:48:26 <mps> maybe separate file in aports, secfixes.yml
2020-02-21 18:48:31 <Ariadne> i succeeded in booting on this mips board
2020-02-21 18:48:53 <maxice8> I wouldn't mind having more files inside an APKBUILD directory
2020-02-21 18:49:02 <maxice8> Already did it for Void Linux
2020-02-21 18:49:05 <mps> better would be some DB somewhere on infra
2020-02-21 18:49:51 <maxice8> No, people must be able to add secfixes
2020-02-21 18:49:52 <_ikke_> That's what's happening now
2020-02-21 18:50:16 <xrs> _ikke_: it's called multi-user setup, please see here: https://docs.gnunet.org/handbook/gnunet.html#Create-user-and-groups-for-the-system-services
2020-02-21 18:50:17 <mps> maxice8: yes, even if they are files in aports it will not take more disk space
2020-02-21 18:50:18 <_ikke_> a process that is listening on mqtt and updating the DB
2020-02-21 18:50:29 <Cogitri> xrs: If you're part of the GNUnet project, then do the trick thing and add a PAM module
2020-02-21 18:50:38 <Cogitri> s/trick/right/
2020-02-21 18:50:38 <alpine-meetbot> Cogitri meant to say: xrs: If you're part of the GNUnet project, then do the right thing and add a PAM module
2020-02-21 18:50:43 <Cogitri> Huh, how did that happen, autocorrect
2020-02-21 18:51:22 <Cogitri> Nothing but systemd has user service management, so a pam module is the way to go for autostarting user services IMHO
2020-02-21 18:51:30 <xrs> Cogitri: mhh, I'm not sure if this is the right thing.
2020-02-21 18:52:30 <_ikke_> xrs: "user services which can be started by every user who wants to use GNUnet applications."
2020-02-21 18:52:40 <_ikke_> seems to mean users start those
2020-02-21 18:53:01 <_ikke_> not started automatically for each user defined on the system when you start the system service
2020-02-21 18:54:12 <nmeum> mps: +1 for using a separate file for secfixes, don't like storing metadata information in comments anyhow
2020-02-21 18:54:17 <xrs> _ikke_: okay, let me recheck this..
2020-02-21 18:54:26 <_ikke_> xrs: Maybe do it like this:
2020-02-21 18:54:35 <_ikke_> one system service that just starts the system one
2020-02-21 18:54:49 <_ikke_> then one service that can be instantiated per user
2020-02-21 18:55:52 <xrs> _ikke_: please explain "instantiated". Is this possible in openrc?
2020-02-21 18:56:06 <_ikke_> yes
2020-02-21 18:56:15 <_ikke_> was looking for the reference
2020-02-21 18:57:25 <Cogitri> xrs: What's not right about PAM? That way you can easily start the service the moment the user is logged in and shut it down once they're logged out
2020-02-21 18:57:45 <_ikke_> xrs: so the idea is that you can symlink services in /etc/init.d
2020-02-21 18:58:06 <_ikke_> so for example /etc/init.d/gnunet-user.foo -> /etc/init.d/gnunet-user
2020-02-21 18:58:29 <_ikke_> then in the initd file, you can use RC_SVCNAME
2020-02-21 18:59:25 <xrs> Cogitri: This a an idea, but we'd need to discuss this in the project because it would affect the security model designed so far.
2020-02-21 19:00:00 <maxice8> @mps @ikke i can write a luascript based on secfixes.lua to do the transition to a separate  secfixes.yaml file
2020-02-21 19:00:13 <xrs> _ikke_: and how will the service be started in the user kontext automatically?
2020-02-21 19:00:22 <_ikke_> xrs: it won't be automatically
2020-02-21 19:00:22 <xrs> and per user?
2020-02-21 19:00:33 <_ikke_> The user needs to opt-in
2020-02-21 19:00:54 <_ikke_> You design the gnunet-user initd file that it starts for that user
2020-02-21 19:01:02 <xrs> do you have some example?
2020-02-21 19:01:06 <mps> maxice8: nice, and nice tht you learned lua :)
2020-02-21 19:01:12 <mps> that*
2020-02-21 19:01:29 <_ikke_> Lua is so small you can learn it in about 30 minutes (when you have experience with programming)
2020-02-21 19:02:05 <mps> yes, but I use it only for awesome applets, nothing else
2020-02-21 19:02:14 <_ikke_> nod
2020-02-21 19:02:32 <_ikke_> But that covers already 75% of the language ;)
2020-02-21 19:02:41 <mps> so don't have much experience for something more serious in lua
2020-02-21 19:02:53 <xrs> _ikke_: so you mean, the user needs to manually symlink and then start the service, if he/she/it likes?
2020-02-21 19:03:00 <_ikke_> correct
2020-02-21 19:03:16 <xrs> mhh... :-) ok, will think about it
2020-02-21 19:03:19 <mps> didn't had incentive, probably
2020-02-21 19:03:35 <_ikke_> It's not ideal, in that the user needs either sudo access or ask someone to do it
2020-02-21 19:04:03 <_ikke_> but I find that a better alternative to automatically spawning the service for every (non-system) user present
2020-02-21 19:05:16 <xrs> _ikke_: gnunet is a networking stack, the idea is to have an alternative for TCP/IP in the future.. that's why it's not just an application.. just to explain it a bit :)
2020-02-21 19:06:08 <_ikke_> right, was just reading into it a bit
2020-02-21 19:07:00 <xrs> it's really not ment to be used by users. In the future GNUnet applications just like TCP/UDP application will run on the system and interface with the stack.
2020-02-21 19:10:25 <_ikke_> Alpine Linux is known because of it's small foot-print. Users expect to have a lot of control to what is happening on theirs systems
2020-02-21 19:10:26 <xrs> oh, my commits include gnunet-gtk. This one is a user space application which uses GNUnet.
2020-02-21 19:11:03 <xrs> I understand.
2020-02-21 19:15:54 <xrs> _ikk_: I'm thinking about what somebody said before, to source out the multi-user setup in a wiki and just have the system services setup.
2020-02-21 19:16:10 <_ikke_> maxice8: I think this should be not done to quickly and communicated clearly. Probably lots of projects already expect secfix information to be present in the commits
2020-02-21 19:16:28 <maxice8> in the commits ?
2020-02-21 19:16:37 <_ikke_> APKBUILDS sorry
2020-02-21 19:16:42 <maxice8> oh
2020-02-21 19:17:01 <maxice8> well, we can do it on edge for 3.12.0 ?
2020-02-21 19:17:30 <_ikke_> after 3.12 is tagged I guess
2020-02-21 19:17:37 <_ikke_> and then announce it in the release notes perhaps?
2020-02-21 19:17:39 <_ikke_> or somewhere
2020-02-21 19:17:39 <maxice8> That is a bummer
2020-02-21 19:18:11 <_ikke_> It's kind of an interface people rely on atm
2020-02-21 19:18:59 <maxice8> Ok, i'll write on the 3.12.0 release notes wiki
2020-02-21 19:19:40 <nmeum> also something i would not change without discussing it with ncopa first, he initially came up with the secfixes comment thingy iirc
2020-02-21 19:19:48 <_ikke_> nmeum: totally agree
2020-02-21 19:20:07 <maxice8> I'll write out the benefits in the release notes
2020-02-21 19:24:25 <maxice8> A good thing is that it will allow people to use either 2 whitespace or 4 whitespace for the indentation of the CVE identifier since we won't be extracting the values from the APKBUILD
2020-02-21 19:25:02 <maxice8> the bad thing is that i'll have to find another way to get the exact lines of the policy violations, i did that by recording linenumbers from the APKBUILD and storing them inside a table inside another table
2020-02-21 19:25:23 <Ariadne> moving mtd-utils from community to main
2020-02-21 19:25:34 <maxice8> ok
2020-02-21 19:38:30 <xrs> _ikke_: I make a decision. Let's start small, only GNUnet system services. I still need to learn more about the alpine linux philosophy :)
2020-02-21 19:38:41 <xrs> s/make/made/
2020-02-21 19:38:41 <alpine-meetbot> xrs meant to say: _ikke_: I made a decision. Let's start small, only GNUnet system services. I still need to learn more about the alpine linux philosophy :)
2020-02-21 19:41:07 <Ariadne> xrs: that is really probably the way to go to start
2020-02-21 19:56:54 <_ikke_> kconfig test failure on s390x
2020-02-21 20:12:10 <xrs> okay, next try: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1907
2020-02-21 20:12:26 <xrs> please have another look at it :)
2020-02-21 20:43:02 <_ikke_> Cogitri: you still seem to have jobs in CI running related to these buildtypes. Are they still required? They keep the runners busy
2020-02-21 20:51:33 <Cogitri> Ah no, they could be cancelled I suppose
2020-02-21 21:12:18 <Cogitri> PureTryOut[m]: You know what's up with libphonenumber? https://build.alpinelinux.org/buildlogs/build-edge-x86/community/libphonenumber/libphonenumber-8.11.4-r1.log
2020-02-21 21:27:18 <AinNero> _ikke_: thanks
2020-02-21 21:38:49 <Cogitri> Do we have some tool to mass build other than something ala `for x in <package list>;do;cd $repo/$x && abuild -r;done`
2020-02-21 21:39:29 <_ikke_> There is buildrepo, but not sure if you can give it a list of packags
2020-02-21 21:39:33 <_ikke_> packages
2020-02-21 21:52:35 <PureTryOut[m]> <Cogitri "PureTryOut: You know what's up w"> It tends to have a lot of race conditions
2020-02-21 21:53:06 <Cogitri> Ah, that's unfortunate
2020-02-21 21:53:10 <Cogitri> But thanks for the info
2020-02-21 21:56:53 <Cogitri> And we got our first actual failure due to the CMAKE_BUILD_TYPE=None change https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/emscripten-fastcomp/emscripten-fastcomp-1.39.0-r1.log
2020-02-21 22:02:56 <Cogitri> https://github.com/emscripten-core/emscripten-fastcomp/blob/master/CMakeLists.txt#L269 Well, I guess upstream asked for it
2020-02-21 22:04:07 <Cogitri> https://github.com/emscripten-core/emscripten-fastcomp/commit/91d509f4fc0997a792fd0ab2ad869d9cbfbc082e Well, I guess we can just patch it out then
2020-02-21 23:33:50 <nmeum> fixed a few failures due to the recent cmake build type change
2020-02-21 23:34:38 <nmeum> the aports with tests failing now should be closely investigated. if the code works with -O2 but doesn't with -Os we most likely found a bug
2020-02-21 23:34:39 <mps> nmeum: I saw, nice that someone care
2020-02-21 23:35:20 <Ariadne> if people have patches to resolve those failures
2020-02-21 23:35:21 <Ariadne> ping me
2020-02-21 23:35:23 <Ariadne> (:
2020-02-21 23:35:35 <nmeum> the ones remaining atm are either due to tests or due to c++ fuckups I am not in the mood of dealing with right now
2020-02-21 23:36:16 <reidrankin> hey all, back again hoping for some feedback on !4056
2020-02-21 23:41:29 <Ariadne> heh
2020-02-21 23:43:18 <mps> community/libphonenumber =>  cc1plus: all warnings being treated as errors
2020-02-21 23:52:46 <nmeum> it's not just that, there also some fatal errors
2020-02-21 23:52:50 <nmeum> > geocoding_data.cc:53853:64: error: expected ')' at end of input
2020-02-21 23:52:58 <nmeum> for instance, not sure how that's related to the cmake change though
2020-02-21 23:53:02 <nmeum> will look into that some other time
2020-02-21 23:53:31 <nmeum> reidrankin: looks good, I don't use modloop though
2020-02-21 23:53:52 <reidrankin> if you run from ram you basically gotta
2020-02-21 23:54:41 <nmeum> sure, I am just saying: I don't have a ready-to-use setup to test this with
2020-02-21 23:55:10 <reidrankin> understandable
2020-02-21 23:55:37 <nmeum> clandmeter: you did some modloop changes recently, didn't you? would you be willing to take a look at this ^?
2020-02-21 23:56:03 <reidrankin> any idea what I should do to move this forward though? I've had to rebase that like 5 times and have asked several times on IRC and gotten nowhere
2020-02-21 23:56:44 <reidrankin> (obviously, though, part of that might be that I'm not following the right process -- this is my first aports contribution)
2020-02-21 23:58:11 <reidrankin> FWIW I've run this edit for several years on my own personal systems, but I've got a client that needs to deploy some IoT devices with wireguard connections and that currently means they gotta ship a replacement for /etc/init.d/modloop as part of their apkovl, which sucks
2020-02-21 23:58:47 <nmeum> re: getting this merged. good question, I understand your frustration. I mentioned someone in the PR and assigned it to him, let's see if that helps (:
2020-02-21 23:59:10 <reidrankin> also important to note that this does nothing if you haven't added "overlay" to modules= on the kernel command line
2020-02-22 00:00:40 <mps> reidrankin: well, I keep package which I can commit for more than a 3 months, but didn't because waiting for maintainer confirmation
2020-02-22 00:00:45 <nmeum> i personally just don't know enough about modloop, anyway gotta go now
2020-02-22 00:00:56 <reidrankin> nmeum: appreciate it. aports is a very busy repo with a lot of important stuff going on all the time, and I wouldn't even know who to ask
2020-02-22 00:00:58 <nmeum> will hopefully find some time to fix more of the cmake / meson stuff tomorrow
2020-02-22 00:03:29 <reidrankin> and all that said it does give me some confidence in alpine to see that noone's gonna merge a PR to the core of the system without actually testing it all-up
2020-02-22 08:02:38 <maxice8> atools now uses lua for one of its scripts! :D
2020-02-22 08:04:41 <_ikke_> nice :)
2020-02-22 10:02:29 <nmeum> why is so much c++ stuff failing? takes ages to build that crap :(
2020-02-22 10:16:54 <nmeum> Cogitri: just a heads up: I removed testing/gnome-fragments for now as it does not build atm
2020-02-22 10:17:06 <Cogitri> Ah, sure. Just disable it on all arches
2020-02-22 10:17:11 <Cogitri> Will fix
2020-02-22 10:17:14 <nmeum> already removed it
2020-02-22 10:17:19 <nmeum> just commit it again if you fixed it
2020-02-22 10:17:40 <Cogitri> Ah, sure
2020-02-22 10:17:46 <Cogitri> I think we usually just makes arch=""
2020-02-22 10:17:46 <nmeum> it's also a bit cleaner as that clarifies that it wasn't committed by accident
2020-02-22 10:17:52 <Cogitri> Fair
2020-02-22 10:18:40 <Cogitri> Tell me if I can help with stuff, I don't want to clash with your work and do stuff twice
2020-02-22 10:18:45 <Cogitri> Testing icu 65 right now
2020-02-22 10:20:15 <nmeum> I am just picking up fail builds and attempting to fix them
2020-02-22 10:20:22 <nmeum> will take a lunch break now though
2020-02-22 10:21:51 <xrs> hey guys, here is the new merge request: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1907
2020-02-22 10:36:18 <Cogitri> Huh, what are the exact CFLAGS set in /etc/abuild.conf of the builders?
2020-02-22 10:36:33 <Cogitri> Can't reproduce the failure on waylandpp with -Os -fomit-frame-pointer
2020-02-22 10:41:41 <nmeum> not sure if that's really a CFLAGS issue but I could not reproduce it either
2020-02-22 10:41:46 <nmeum> also works fine on the ci
2020-02-22 10:42:53 <Cogitri> !4363 for grantlee
2020-02-22 10:43:08 <nmeum> hehe
2020-02-22 10:43:17 <nmeum> I just backported patches for grantlee which should also fix it
2020-02-22 10:43:26 <nmeum> will attempt to fix ettercap now
2020-02-22 10:44:56 <Cogitri> Okie
2020-02-22 10:45:17 <Cogitri> Bumping it is a good idea anyway I suppose, but then we can wait for the maintainer on that
2020-02-22 10:45:40 <Cogitri> Ugggghh, seems like my dabuild still doesn't work properly
2020-02-22 10:46:03 <Cogitri> I do get my packages on my host system now but packages built in dabuild don't see the repository with the new version
2020-02-22 10:46:10 <Cogitri> So I just rebuilt everything against icu 64 again
2020-02-22 10:46:24 <Cogitri> Oh well, I guess this is the torture test for my cooling solution then :P
2020-02-22 10:51:58 <nmeum> https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/gnome-obfuscate/gnome-obfuscate-0.0.2-r1.log
2020-02-22 10:52:01 <nmeum> first meson build failure
2020-02-22 10:52:07 <nmeum> fails with a rustc segfault :3
2020-02-22 10:58:26 <Cogitri> Restart it
2020-02-22 10:58:33 <Cogitri> Rustc SIGSEGVs from time to time on musl
2020-02-22 10:58:42 <Cogitri> Sadly I didn't get to debugging that yet
2020-02-22 10:59:18 <Cogitri> Because LLVM breaks ABI when built with assertions so building rustc isn't fun when it needs itself to boostrap and is linked dynamically against LLVM
2020-02-22 11:00:23 <Cogitri> Also, fwiw I'm pretty sure that Rust packages don't care at all for the buildtype being used because you need some not so pretty hacks to get cargo to work with Meson
2020-02-22 11:09:39 <nmeum> yeah
2020-02-22 11:09:43 <nmeum> it passed now
2020-02-22 11:10:41 <Cogitri> Neat
2020-02-22 11:29:55 <nmeum> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/libphonenumber/libphonenumber-8.11.4-r1.log
2020-02-22 11:30:03 <nmeum> does anybody have any idea what this is about?
2020-02-22 11:37:01 <nmeum> I will just change the build type for now to unblock the builders
2020-02-22 11:37:13 <nmeum> I tried fixing this aport but couldn't figure out what's causing this
2020-02-22 11:41:04 <Cogitri> Weird how that'd introduce such failures though
2020-02-22 11:49:31 <nmeum> indeed
2020-02-22 13:29:16 <Cogitri> Oh wow the rippled build is kinda scary
2020-02-22 13:33:13 <nmeum> yep
2020-02-22 13:33:24 <nmeum> downloads a bunch of github repositories from the internet and takes forever to build
2020-02-22 13:33:55 <Cogitri> Yes
2020-02-22 13:43:06 <PureTryOut[m]> So I got all of Qt 5.14 to compile, but on armv7 and aarch64 the CI goes out of memory when building qt5-qtwebengine. Will that cause problems on the builders?
2020-02-22 13:46:57 <Cogitri> I don't think so
2020-02-22 13:47:11 <Cogitri> I can test qt5-qtwebengine on an aarch64 container
2020-02-22 13:47:22 <Cogitri> Are you running Qt 5.14 on your machine already?
2020-02-22 13:47:49 <Cogitri> Qt uses some internal API that can cause all kinds of funny runtime failures that aren't detectable by us
2020-02-22 14:03:12 <PureTryOut[m]> Not yet no
2020-02-22 14:03:17 <PureTryOut[m]> Will do later
2020-02-22 14:03:31 <Cogitri> Okay, good luck
2020-02-22 14:03:58 <PureTryOut[m]> Lol thanks. So far getting Qt 5.14 to build was relatively painless so let's hope it continues going like this
2020-02-22 14:51:42 <nmeum> PureTryOut[m]: https://cgit.kde.org/kmymoney.git/tree/CMakeLists.txt#n211 kymymoney seems to be incompatible with the current Qt5::WebKitWidgets we are shipping how would you like that to be fixed?
2020-02-22 14:52:29 <nmeum> > Qt5WebEngineWidgets_VERSION VERSION_LESS 5.9.3
2020-02-22 14:52:38 <nmeum> don't know much about this qt stuff but it seems we are shipping 5.12.5
2020-02-22 15:59:47 <nmeum> PureTryOut[m]: 7d25918a96a143577d28106eaebfdc1318f74aaf disabled kmymoney temporarily to unblock the builders for now
2020-02-22 16:38:01 <mps> 'cd $builddir' doesn't work for all functions in APKBUILD
2020-02-22 16:38:33 <mps> automatically/by default, I mean
2020-02-22 16:41:03 <maxice8> what you mean ?
2020-02-22 16:42:47 <mps> community/crystal, zshcomp() without explicit  '1cd "$builddir"' it fails
2020-02-22 16:43:00 <mps> s/1cd/cd/
2020-02-22 16:43:00 <alpine-meetbot> mps meant to say: community/crystal, zshcomp() without explicit  'cd "$builddir"' it fails
2020-02-22 16:43:32 <maxice8> Can't install be "$builddir"/etc/completion.zsh ?
2020-02-22 16:44:01 <mps> yes, not found
2020-02-22 16:44:33 <maxice8> Then the file isn't there anymore
2020-02-22 16:44:55 <mps> file is there
2020-02-22 16:45:12 <mps> adding 'cd "$builddir"' fixed it
2020-02-22 16:45:37 <maxice8> Then you did it wrong, if you cd to $builddir and do a command relative to install it is the same as doing the install but with the $builddir before the relative path
2020-02-22 16:46:34 <mps> please look at community/crystal APKBUILD
2020-02-22 16:47:22 <mps> only change I made was remove 'cd "$builddir"' and then it fails
2020-02-22 16:47:41 <mps> reverting this fixed it
2020-02-22 16:49:06 <mps> for build, prepare, check, package it works fine without 'cd "$builddir"'
2020-02-22 16:56:59 <maxice8> http://ix.io/2cpw
2020-02-22 16:58:27 <_ikke_> cd builddir only works for the default functions
2020-02-22 16:58:32 <_ikke_> any custom functions still require it
2020-02-22 16:58:51 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n662
2020-02-22 16:59:35 <_ikke_> s/cd builddir/leaving out cd "$builddir"/
2020-02-22 16:59:36 <alpine-meetbot> _ikke_ meant to say: leaving out cd "$builddir" only works for the default functions
2020-02-22 17:24:35 <mps> _ikke_: I see, thought so after got mentioned bug
2020-02-22 17:25:12 <mps> (still don't see rush to remove 'cd "$builddir"' even from default functions)
2020-02-22 17:25:37 <maxice8> There is no rush, you're at worst doing cd "$builddir" twice
2020-02-22 17:25:40 <maxice8> just do as you see them
2020-02-22 17:27:14 <_ikke_> The idea is that you remove 'cruft', so that only the interesting bits remain
2020-02-22 17:31:04 <xrs> _ikke_: I changed the merge request and sorted the user stuff out. would you mind to have a look at it?
2020-02-22 17:31:19 <xrs> I mean the GNUnet merge request.
2020-02-22 17:34:43 <mps> maxice8: I can't remember who but I remember that someone told some months ago that we should remove 'cd "$builddir"' from APKBUILD whenever we upgrade package
2020-02-22 17:35:07 <_ikke_> xrs: right, I already briefly looked at it last night
2020-02-22 17:36:18 <maxice8> @mps yeah, from the main functions, which are prepare(), build() and package()
2020-02-22 17:36:52 <mps> maxice8: ok, np, now I know fine points :)
2020-02-22 17:36:53 <_ikke_> check() as well
2020-02-22 17:37:56 <nmeum> the only builder still number crunching meson / cmake rebuilds is the x86_64 builder, the others are idle again \o/
2020-02-22 17:38:22 <_ikke_> nmeum: nice
2020-02-22 17:38:37 <maxice8> @ikke i knew i was forgetting one, unpack() took precedence somehow
2020-02-22 17:39:00 <_ikke_> The list is here: https://git.alpinelinux.org/abuild/tree/abuild.in#n662 :)
2020-02-22 17:40:00 <_ikke_> xrs: it definitely looks a lot better
2020-02-22 17:40:20 <xrs> good!
2020-02-22 18:07:43 <Cogitri> nmeum: Neat :)
2020-02-22 18:07:53 <Cogitri> Thanks for guarding the builders
2020-02-22 21:00:16 <PureTryOut[m]> nmeum: thanks for the notice, I'll look into it
2020-02-23 04:10:38 <maxice8> What is the logic for the size = field in .PKGINFO
2020-02-23 04:15:02 <maxice8> oh
2020-02-23 04:35:28 <maxice8> mate-themes is installing the .mo files (they are for translation so they go into -lang) but they are completely disappearing
2020-02-23 07:09:50 <_ikke_> vtk fails due to buildtype None not recognized
2020-02-23 07:10:03 <maxice8> So who will fix it ? you or me ?
2020-02-23 07:10:32 <_ikke_> I'm not sure how to properly fix it
2020-02-23 07:10:52 <_ikke_> I could probably look in the commit history for similar cases
2020-02-23 07:10:55 <maxice8> Me neither, i'll dwelve into CMakeLists.txt and find out
2020-02-23 07:11:20 <maxice8> The most likely case is that it tries to match some CMAKE buildtypes like MinRelSize RelWithDebInfo etc and forgot to match None
2020-02-23 07:12:14 <_ikke_> Right
2020-02-23 07:12:20 <_ikke_> 3e27da2e570268d135e1e70342b7e2b37faad7d6
2020-02-23 07:12:28 <maxice8> looking at it
2020-02-23 07:13:23 <_ikke_> I'll fix xvfb-run
2020-02-23 07:13:31 <maxice8> have fun
2020-02-23 07:14:38 <_ikke_> checksum issue :)
2020-02-23 07:15:31 <_ikke_> hmmm
2020-02-23 07:20:48 <_ikke_> I guess an intermittant issue, seems alright now
2020-02-23 07:20:52 <maxice8> @ikke i think we need a check in abuild for stuff in  /etc/init.d
2020-02-23 07:21:01 <maxice8> some upstreams install files there that are meant for sysv and not openrc
2020-02-23 07:21:17 <maxice8> maybe error out if it doesn't start with #!/sbin/openrc-run
2020-02-23 07:21:20 <_ikke_> maxice8: ah ok. we already have checks for initd files
2020-02-23 07:21:22 <_ikke_> yeah
2020-02-23 07:22:05 <_ikke_> linting is not going to help there
2020-02-23 07:22:09 <maxice8> Oh
2020-02-23 07:22:18 <maxice8> it does
2020-02-23 07:22:40 <maxice8> oh yeah, the package i fixed was installing SYMLINKS to the main package
2020-02-23 07:22:47 <maxice8> and because the symlinks were broken it failed the check
2020-02-23 07:23:10 <maxice8> but the user was still prompted to add -openrc subpackage because /etc/init.d existed :D
2020-02-23 07:26:58 <_ikke_> You just removed the buildtype check for xvt?
2020-02-23 07:27:33 <maxice8> yes
2020-02-23 07:50:40 <maxice8> @ikke xen has alternative CVE identifiers in the form of XSA-XXX
2020-02-23 07:50:53 <maxice8> secfixes-check beautifully trips over them
2020-02-23 07:51:22 <_ikke_> heh
2020-02-23 07:51:39 <_ikke_> So I guess we need to allow those too?
2020-02-23 07:52:53 <maxice8> I really don't feel like adding support, considering it will make some checks currently done in secfixes-check impossible
2020-02-23 07:53:03 <maxice8> like checking if the CVE identifier is missing a CVE identifier
2020-02-23 07:53:24 <maxice8> or rather, a CVE- prefix
2020-02-23 08:00:16 <_ikke_> Can't you just match those 2 forms?
2020-02-23 08:00:46 <_ikke_> (XSA-\d+|CVE-\d{4}-\d+)
2020-02-23 08:01:36 <maxice8> One of the checks if for missing CVE-
2020-02-23 08:11:22 <_ikke_> Wouldn't it make more sense to let the yaml parser handle the data, and then check the data you got back from yaml?
2020-02-23 08:12:08 <_ikke_> though I guess that would make it harder to give good syntax feedback
2020-02-23 08:17:10 <maxice8> It would make it impossible to give feedback on indentation and I didn't found a way yet to show which line, if we use only yaml data
2020-02-23 08:18:34 <_ikke_> The question is, does indentation matters that much? It's more important that it can be parsed as valid yaml
2020-02-23 08:35:44 <maxice8> No, it will be abandoned once (if?) we move to a separate secfixes.yaml file
2020-02-23 09:08:24 <maxice8> also should we support only 1 identifier per line or many identifiers per line
2020-02-23 09:08:39 <maxice8> Xen has a few like this on the same line: CVE-YYYY-XXXXX XSA-XXX
2020-02-23 09:08:48 <maxice8> they also have some like this alone in a line XSA-XXX
2020-02-23 10:03:46 <russkel> any chance of getting my proj MR !3634 looked at?
2020-02-23 10:04:04 <russkel> fixed quite a few issues and got it working on all archs
2020-02-23 10:04:19 <russkel> + test suite passes
2020-02-23 10:05:39 <Cogitri> Oh huh, somehow I thought I had merged that already
2020-02-23 10:05:45 <Cogitri> Sorry, gonna take a look at it in a little bit
2020-02-23 10:06:56 <russkel> thanks ;)
2020-02-23 10:26:10 <russkel> and when that gets merged !3000 will be good to go as well
2020-02-23 10:29:59 <Cogitri> Okie
2020-02-23 10:32:22 <russkel> =) =)
2020-02-23 10:40:07 <AinNero> maxice8: pickfire: community/tlp needs the -w option for flock, which breaks when only busybox is installed
2020-02-23 10:40:19 <AinNero> still works but spews some stderr during boot / no lock aquired
2020-02-23 10:40:30 <AinNero> this is just for notification that i filed a ticket upstream https://github.com/linrunner/TLP/issues/475
2020-02-23 11:07:16 <minecrell> Apparently we have a fork of qt5-qtbase in postmarketOS only to make it use OpenGL ES2 on arm* instead of desktop OpenGL. Which is rather annoying because it breaks with every qt5 update in Alpine :/
2020-02-23 11:07:16 <minecrell> I think I asked PureTryOut[m] about it at some point and he mentioned it was discussed before... But I would say the majority of ARM* devices support GLES better than desktop OpenGL...
2020-02-23 11:07:16 <minecrell> Is there any reason we cannot change it to use GLES on arm*?
2020-02-23 11:47:37 <PureTryOut[m]> We did have this discussion before yes and although I don't remember the exact reasons, the conclusion was to stay with desktop OpenGL on Alpine
2020-02-23 11:47:40 <PureTryOut[m]> I rather not have it forked either tbh
2020-02-23 12:52:11 <_ikke_> opencascade: CMake Error: File /home/buildozer/aports/testing/opencascade/src/occt-V7_4_0/build/OpenCASCADECompileDefinitionsAndFlags-none.cmake does not exist.
2020-02-23 14:07:26 <_ikke_> andypost[m]: ping
2020-02-23 14:08:23 <_ikke_> n/m
2020-02-23 14:25:25 <Cogitri> ikke: CMake sure is annoying
2020-02-23 14:27:18 <_ikke_> I have a fix, just need to create a patch
2020-02-23 14:27:39 <_ikke_> There is an existing patch to that file, so trying to figure out the best way to go about it
2020-02-23 14:28:31 <Cogitri> Ah, okay, thanks
2020-02-23 14:50:51 <pickfire> AinNero, pltrz:I think maybe you all can take a look at the tlp for flock? Just make the change, currently I am not using that.
2020-02-23 14:51:07 <AinNero> pickfire: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4412
2020-02-23 14:51:08 <pickfire> If possibly, just take ownership of that package.
2020-02-23 14:51:20 <AinNero> okay, ill amend
2020-02-23 14:51:26 <pickfire> AinNero: Thanks.
2020-02-23 14:52:03 <pickfire> AinNero: Maybe add pltrz as co-maintainer?
2020-02-23 14:52:34 <pickfire> Is gitlab.alpinelinux.org slow on your side? Seemed very slow to load that link here. More than half a minute already.
2020-02-23 14:52:38 <pickfire> Not loaded yet.
2020-02-23 14:53:53 <Cogitri> Works for me
2020-02-23 14:53:56 <AinNero> same
2020-02-23 14:54:16 <AinNero> ill summarize: i added coreutils as runtime dependency
2020-02-23 14:54:30 <AinNero> we can also just skip the maintainer part
2020-02-23 14:54:31 <pickfire> Cogitri: Works for me too but very slow. Like one minute to load.
2020-02-23 14:54:43 <AinNero> if it breaks on my machine ill probably work on it regardless
2020-02-23 14:54:44 <pickfire> But isn't coreutils available by default?
2020-02-23 14:54:59 <pickfire> Same goes for me too but I am not using it for my machine.
2020-02-23 14:55:05 <AinNero> until today i run without coreutils
2020-02-23 14:55:06 <PureTryOut[m]> No
2020-02-23 14:55:09 <pickfire> At least not using alpine on laptop since no IME.
2020-02-23 14:55:20 <pickfire> AinNero: Did you remove it or...
2020-02-23 14:55:32 <AinNero> no, it wasnt installed per default
2020-02-23 14:55:34 <Cogitri> Loads for me within a second
2020-02-23 14:56:13 <pickfire> Cogitri: Where are you?
2020-02-23 14:56:28 <pickfire> Loads for me within a minute.
2020-02-23 14:56:42 <AinNero> might be timeout due to ipv6 misconfiguration
2020-02-23 14:56:54 <Cogitri> Germany, on a 16 Mbit/s connection
2020-02-23 14:57:06 <pickfire> Ah, probably I think I have ipv6 misconfiguration, not sure how to set it up correctlay.
2020-02-23 14:57:20 <pickfire> Germany is using 16 Mbit/s, that slow?
2020-02-23 14:57:33 <pickfire> I thought Germany is already 1Gbp/s
2020-02-23 14:59:40 <pickfire> I am at Malaysia, currently speedtest shows 50 Mbit/s
2020-02-23 14:59:44 <Cogitri> Sadly not, no
2020-02-23 14:59:48 <pickfire> For downlad
2020-02-23 15:00:06 <Cogitri> Especially if you're not living in a city internet is pretty bad in Germany
2020-02-23 15:00:19 <pickfire> Ah, I heard Germany is quite big.
2020-02-23 15:00:23 <pickfire> No wonder.
2020-02-23 15:00:38 <Cogitri> I think Germany has the 3rd lowest average internet speed in the EU
2020-02-23 15:00:50 <AinNero> ist halt neuland
2020-02-23 15:01:16 <Cogitri> Ah, Germany being big isn't the problem, we just tried very hard not to invest anything into such weird technology that probably won't ever be used anyway like the internet :^)
2020-02-23 15:01:34 <pickfire> From my laptop, I heard my dad say we are using 300 Mbit/s.
2020-02-23 15:01:36 <Cogitri> Yes, Neuland fΓΌr uns alle
2020-02-23 15:02:02 <_ikke_> T-Mobile NLD tried to reroute traffice through a DEU DC and people stared complaining that speeds and latency was really poort
2020-02-23 15:06:55 <Tuxist> i have problem heimdal package have no ldap support
2020-02-23 15:18:37 <andypost[m]> _ikke_: I'm afk mostly
2020-02-23 15:19:00 <_ikke_> sure, np
2020-02-23 15:30:23 <pickfire> AinNero: I can still help with bumping the version if I received the email, but probably cannot do much if something broke since I cannot test it.
2020-02-23 15:32:53 <Tuxist> so patch for apkbuild https://tuxist.de/files/heimdal.patch
2020-02-23 15:33:15 <_ikke_> Tuxist: would be nice if it would just show the patch instead of offering it for download
2020-02-23 15:34:39 <_ikke_> Tuxist: best to contact the maintainer (Leonard Arenda aka rnarld)
2020-02-23 16:25:53 <Tuxist> _ikke_: ok
2020-02-23 16:58:18 <Cogitri> Just to make sure: not specifying the suid option means that abuild will scream at me if a suid bit on a binary is detected and not that it is stripped, right?
2020-02-23 16:58:39 <Cogitri> s/option/option in an APKBUILD/
2020-02-23 16:58:39 <alpine-meetbot> Cogitri meant to say: Just to make sure: not specifying the suid option in an APKBUILD means that abuild will scream at me if a suid bit on a binary is detected and not that it is stripped, right?
2020-02-23 16:59:47 <_ikke_> Cogitri: afaik, yes
2020-02-23 16:59:55 <Cogitri> Good, thanks
2020-02-23 17:19:21 <kaey> nmeum: you there?
2020-02-23 17:20:22 <nmeum> kaey: kind of, what's up?
2020-02-23 17:21:09 <kaey> i finally wrote a bit about caching go stuff https://tpaste.us/DDjo
2020-02-23 17:21:44 <nmeum> ah nice
2020-02-23 17:22:23 <nmeum> downloaded it, will read it later. currently doing something else
2020-02-23 17:22:35 <nmeum> but thanks a lot for the write-up! \o/
2020-02-23 17:27:12 <PureTryOut[m]> Cogitri: what is this rootbld you mentioned in ~alpine-devel?
2020-02-23 17:27:43 <Cogitri> You can do `abuild rootbld` and it'll build in a sandbox (bwrap, the same thing flatpak uses)
2020-02-23 17:28:20 <Cogitri> That way it doesn't manipulate your system (i.e. it doesn't install packages to it, network is sandboxed (unless you specifiy options="net") etc.)
2020-02-23 17:28:32 <PureTryOut[m]> Oh, I use docker-abuild for that normally
2020-02-23 17:28:40 <Cogitri> I use docker-abuild too
2020-02-23 17:28:40 <PureTryOut[m]> But rootbld sounds better then tbh
2020-02-23 17:28:49 <PureTryOut[m]> I'm willing to fix all packages that require "net" lol
2020-02-23 17:28:57 <Cogitri> That'd be good too :)
2020-02-23 17:29:06 <Cogitri> rootbld certainly sounds like less effort
2020-02-23 17:29:20 <Cogitri> But I didn't quite get caching to work with it, but maybe I just messed something up about that
2020-02-23 17:29:57 <PureTryOut[m]> Hmm then you have the problem of the current user not having permissions in `/var/cache/distfiles`...
2020-02-23 17:32:01 <PureTryOut[m]> That's an easy enough fix though
2020-02-23 17:32:54 <Cogitri> Ah, I mean caching of apk packages not distfiles
2020-02-23 17:33:20 <Cogitri> Also, there doesn't happen to be some documentation to apk-tools API somewhere I'm missing?
2020-02-23 17:33:54 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/mMMEccByrCCVTpquKyngFIIa >

2020-02-23 17:33:56 <PureTryOut[m]> Uhh....
2020-02-23 17:34:19 <PureTryOut[m]> I mean, the file is there
2020-02-23 17:34:28 <Cogitri> Maybe not in the sandbox
2020-02-23 17:34:44 <Cogitri> I should bindmount your $HOME/.abuild in the sandbox AFAIK
2020-02-23 17:34:53 <PureTryOut[m]> Oh yeah but why not?
2020-02-23 17:35:30 <Cogitri> That's a very good question
2020-02-23 17:36:17 <Cogitri> https://gitlab.alpinelinux.org/alpine/abuild/blob/master/abuild.in#L2305
2020-02-23 17:36:48 <Cogitri> What's your PACKAGER_PRIVKEY in your abuild.conf?
2020-02-23 17:37:11 <Cogitri> Maybe you need to s/builder/$USER/ since that builder user only exists in dabuild?
2020-02-23 17:37:43 <PureTryOut[m]> PACKAGER_PRIVKEY contains the path mentioned in the error above, so `/home/builder/everything/else`
2020-02-23 17:38:23 <Cogitri> And bwrap only bindmounts $HOME/.abuild to $HOME/.abuild
2020-02-23 17:38:42 <Cogitri> In contrast to dabuild which bindmounts $HOME/.abuild to /home/builder/.abuild
2020-02-23 17:38:46 <Cogitri> So I guess that's why it blows up
2020-02-23 17:39:35 <Cogitri> It doesn't appear that abuild has a way to pass custom stuff to bwrap as of now, so changing PACKAGER_PRIVKEY to /home/$USER/everything/else is probably the way to go
2020-02-23 17:42:04 <PureTryOut[m]> Changing the username to `$USER` did indeed work
2020-02-23 17:42:10 <PureTryOut[m]> Although then it fails in docker lol but ok
2020-02-23 17:43:22 <Cogitri> You could symlink stuff into place in docker-abuild :P
2020-02-23 17:43:39 <Cogitri> Or rename your user to builder πŸ€”
2020-02-23 17:45:06 <Cogitri> I think dabuild is going to get an update soon to change it's behaviour around that anyway, so it'll work with dabuild again once that lands
2020-02-23 17:46:44 <Cogitri> PureTryOut[m]: About your mail: I think the only proper way to do it would be to not have a mesa package (maybe call it mesa-stable) and have `provides="mesa"` in both mesa-stable and mesa-git
2020-02-23 17:47:23 <Cogitri> At least that's how I did it in !4182 and nothing broke for me
2020-02-23 17:47:31 <PureTryOut[m]> Tbf I only need to use Docker on my Gentoo system as obviously there are no Alpine tools there. I can just modify my script to check the distro: if Alpine, use Alpine tools, otherwise stick to Docker
2020-02-23 17:47:58 <PureTryOut[m]> Cogitri: we can't "not" provide Mesa though, we directly use the Alpine repos
2020-02-23 17:48:12 <PureTryOut[m]> So we'd have to modify the Alpine package to mesa-stable lol
2020-02-23 17:55:43 <Cogitri> Ah, wasn't sure how closely pmOS is attached to the Alpine repos
2020-02-23 17:56:00 <PureTryOut[m]> We're literally just an extra repository on top with some nifty tooling πŸ˜‰
2020-02-23 18:02:20 <PureTryOut[m]> Hmm I have a package now that compiles fine in docker-abuild, but for some reason fails in rootbld
2020-02-23 18:02:40 <PureTryOut[m]> I'm not sure but it seems to not like directory changing from the Makefile or something
2020-02-23 18:03:41 <Cogitri> Can you spin me a log?
2020-02-23 18:05:04 <PureTryOut[m]> Will in a sec
2020-02-23 18:06:08 <maxice8> @AinNero merged the tlp change
2020-02-23 18:06:21 <AinNero> yeah seen it
2020-02-23 18:06:22 <AinNero> thanks
2020-02-23 18:06:34 <PureTryOut[m]> Cogitri: actually no that is, but you can probably reproduce the error I'm seeing. Checkout my Qt MR and try to build qt5-qttools
2020-02-23 18:09:29 <Cogitri> Will try later on
2020-02-23 19:15:13 <PureTryOut[m]> Cogitri: hmm got another package that fails to compile in rootbld but works fine in docker-abuild. Error shows source code problems but that can't be it, so not sure what's happening. `qt5-qtvirtualkeyboard` this time
2020-02-23 19:18:33 <Cogitri> FWIW all the Qt stuff from your MR built fine for me in dabuild
2020-02-23 19:46:43 <_ikke_> We are upgrading gitlab, it should be back soon
2020-02-23 19:49:54 <_ikke_> All down, gitlab is back. Let us know if you notice anything out of the order
2020-02-23 20:08:55 <Cogitri> Heh, all down
2020-02-23 20:09:15 <Cogitri> Thanks for keeping the Gitlab up to speed :)
2020-02-23 20:09:35 <_ikke_> lol
2020-02-23 20:09:38 <_ikke_> s/down/done
2020-02-23 20:09:39 <alpine-meetbot> _ikke_ meant to say: All done, gitlab is back. Let us know if you notice anything out of the order
2020-02-23 20:10:09 <_ikke_> My fingers have live of their own :)
2020-02-23 21:08:14 <maxice8> @ikke re: CVE and  XSA identifiers, i think we can just error if the user doesn't provide one of the acceptable prefixes (CVE-, XSA-, etc) and do policy checks based on the type (CVE, XSA, etc) of the identifier
2020-02-23 21:09:19 <_ikke_> sounds good
2020-02-23 21:11:09 <maxice8> Another thing is if we should allow multiple identifiers per-line or have a system of preference
2020-02-23 21:11:13 <maxice8> like
2020-02-23 21:11:32 <maxice8> CVE-2020-1000 XSA-200 (where the XSA is the equivalent to the CVE)
2020-02-23 21:12:04 <maxice8> @ikke https://gitlab.alpinelinux.org/Leo/atools/issues/27 please read
2020-02-23 21:15:19 <_ikke_> I think at least each identifier should be a separate yaml element
2020-02-23 21:16:34 <maxice8> I think it is ok to have multiple equivalents on the same line
2020-02-23 21:22:23 <maxice8> Unless having them all around and having no (obvious) way to make a relationship between the different identifiers is ok
2020-02-23 21:24:07 <_ikke_> verboser option: http://tpaste.us/1O8z
2020-02-23 21:25:33 <maxice8> If that is the case then i'd drop the CVE- and XSA-
2020-02-23 21:26:23 <_ikke_> Yeah, possible
2020-02-23 21:26:55 <_ikke_> yaml is a structured language, so it's a pitty if we would not use that
2020-02-23 21:27:14 <maxice8> When ncopa returns ?
2020-02-23 21:27:29 <maxice8> doing it that way will require rewriting
2020-02-23 21:27:38 <_ikke_> begging of March somewhere
2020-02-23 21:27:46 <_ikke_> maxice8: yes, it would
2020-02-23 21:27:56 <maxice8> oh wow that is a lot
2020-02-23 21:29:55 <maxice8> anyways, would it also be done with the secfixes.yaml transition ?
2020-02-23 21:33:43 <kaey> why use yaml and not some comma-separated list, for ex "pkgver: CVE-1,XSA-1 - short descr"
2020-02-23 21:35:47 <_ikke_> That's also yaml :)
2020-02-23 21:35:53 <_ikke_> but quite poort
2020-02-23 21:36:42 <maxice8> poort ?
2020-02-23 21:36:43 <kaey> common complaint about yaml is that its spec is too big and parsers implement only parts of it
2020-02-23 21:37:03 <kaey> which leads to "i wrote yaml using tool X, but tool Y doesn't parse it"
2020-02-23 21:37:22 <_ikke_> That's hardly any issue in the intended usecase
2020-02-23 21:38:02 <_ikke_> The basics of lists and maps is universally supported
2020-02-23 21:38:32 <_ikke_> I mean, even the lua lib we use supports it
2020-02-23 21:38:59 <_ikke_> We just need *a* format, lets not bikeshed about it
2020-02-23 21:43:43 <maxice8> @ikke https://gitlab.alpinelinux.org/Leo/atools/issues/27#note_69600
2020-02-23 21:45:33 <_ikke_> yes indeed, something like that
2020-02-23 21:45:42 <maxice8> exactly like that
2020-02-23 21:46:04 <_ikke_> others probably also have an opinion about it :)
2020-02-23 21:46:23 <maxice8> I'll wait until ncopa is back
2020-02-23 21:46:33 <maxice8> the design also hinges on whether we get secfixes.yaml separate from APKBUILD
2020-02-23 21:50:23 <clandmeter> maxice8: ncopa does not want that.
2020-02-23 21:50:36 <clandmeter> i talked to him about it few days ago
2020-02-23 21:51:13 <_ikke_> clandmeter: you mean the separate secfixes file?
2020-02-23 21:51:19 <clandmeter> yes
2020-02-23 21:51:22 <_ikke_> ok
2020-02-23 21:53:05 <maxice8> back to the drawing board
2020-02-23 21:53:39 <_ikke_> :)
2020-02-23 21:54:39 <maxice8> @clandmeter did he also comment on alternative security identifiers ?
2020-02-23 21:54:51 <clandmeter> i did not talk about those
2020-02-23 21:55:10 <clandmeter> what i read from you is that some have 2 entries per line?
2020-02-23 21:55:27 <_ikke_> xen has XSA identifiers that also have CVE entries
2020-02-23 21:55:53 <clandmeter> right, i dont see that as an issue, but 2 in one line is kind of weird.
2020-02-23 21:55:57 <_ikke_> nod
2020-02-23 21:56:16 <maxice8> It does create a relationship between them
2020-02-23 21:56:42 <_ikke_> yaml has other means to do that
2020-02-23 21:56:49 <clandmeter> true but its not how a proper yaml structure is ment
2020-02-23 21:57:21 <clandmeter> im not sure its important that we keep the relation?
2020-02-23 21:57:44 <_ikke_> clandmeter: otherwise it looks like there are multiple issues
2020-02-23 21:58:19 <clandmeter> _ikke_: right, but are we the ones that should make the relation?
2020-02-23 21:59:00 <_ikke_> perhaps
2020-02-23 21:59:42 <maxice8> would be nicer if someone could know that those identifiers mean the same thing
2020-02-23 21:59:49 <_ikke_> If you ask: "is issue CVE-yyyy-xxxx fixed for this package, it does not matter a lot
2020-02-23 22:00:18 <_ikke_> If you ask: what issues does this version of a package has, it can be confusing
2020-02-23 22:02:51 <clandmeter> i think ncopa has a better overview of how to handle those
2020-02-23 22:03:44 <clandmeter> what he does not like is to introduce a lot of extra files in aports.
2020-02-23 22:04:17 <clandmeter> he also likes that the data is integrated in the apkbuild and not so easy to forget.
2020-02-23 22:05:08 <clandmeter> the downside is that its somewhat more difficult to parse, but also easier to make mistakes.
2020-02-23 22:10:56 <maxice8> sounds like 2 negatives to me
2020-02-23 22:11:24 <_ikke_> but also 2 positives
2020-02-23 22:14:14 <Cogitri> One minor positive about having a seperate yaml file would be that text editors would pick up properly on that
2020-02-23 23:22:11 <Danct12[m]> can #4344 be merged?
2020-02-23 23:22:27 <Danct12[m]> gah, !4344
2020-02-23 23:23:53 <mps> Danct12[m]: we usually do not use pre/post-install to alert users
2020-02-23 23:24:29 <Danct12[m]> then how can we alert users?
2020-02-23 23:24:51 <mps> we don't do this
2020-02-23 23:25:06 <mps> usually, I mean
2020-02-23 23:25:09 <Danct12[m]> removing it in a second
2020-02-23 23:26:57 <mps> ok, will wait some time
2020-02-23 23:27:36 <mps> I see it passed CI fine
2020-02-23 23:27:44 <Danct12[m]> alright
2020-02-23 23:28:12 <mps> done?
2020-02-23 23:50:26 <mps> Danct12[m]: if no one pushes it remind me tomorrow, I'm going to bed. good night :)
2020-02-24 06:14:28 <opal> i just want to confirm: does abuild (specifically abuild-apk) need write access to /lib/apk?
2020-02-24 06:14:42 <opal> trying to test changes i made to a package
2020-02-24 06:14:49 <opal> before sending in a patch
2020-02-24 06:16:08 <Cogitri> Usually you only need write permissions to /var/cache/distfiles
2020-02-24 06:17:12 <opal> interesting why its failing to write to /lib/apk then: https://wowana.me/paste/q8rFAv.txt and https://wowana.me/paste/Ugxqh4.txt
2020-02-24 06:17:25 <opal> both are `abuild -r` invocation but latter is with `sh -x`
2020-02-24 06:17:37 <opal> and the latter one is just a snippet of full output, around the error
2020-02-24 06:18:06 <[[sroracle]]> lib/apk is where apk has the installed packages database amongst other things... so yes it needs write access in order to do abuild deps properly
2020-02-24 06:18:12 <opal> strace on the abuild-apk command gave me this: openat(3, "lib/apk/db/lock", O_RDWR|O_CREAT|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)
2020-02-24 06:18:48 <opal> [[sroracle]] alright, i just dont remember ever having to touch perms outside of what Cogitri said
2020-02-24 06:19:03 <opal> (and usually /var/cache/distfiles has been correctly permed to abuild group)
2020-02-24 06:19:29 <[[sroracle]]> you shouldn't have to touch any perms, it sounds like something is broken with your system
2020-02-24 06:19:34 <opal> hm
2020-02-24 06:20:02 <opal> just made a fresh chroot with 3.11.3
2020-02-24 06:20:40 <Cogitri> And you have sudo installed and have permission to use it?
2020-02-24 06:20:58 <Cogitri> I think the package install step is run with sudo
2020-02-24 06:21:26 <opal> sudo's installed from alpine-sdk, yeah, didnt realise i had to add myself to wheel
2020-02-24 06:22:18 <opal> keep in mind last time i touched any of this was a while ago, i may have forgotten how to set up a dev environment properly lol
2020-02-24 06:23:58 <opal> oh i have nosuid mount which is messing with sudo
2020-02-24 06:24:03 <opal> let me fix that
2020-02-24 06:25:55 <opal> that fixed it
2020-02-24 06:26:15 <opal> :>
2020-02-24 06:31:38 <Cogitri> Neat :)
2020-02-24 06:32:42 <opal> error reporting on that front could be a bit more solid
2020-02-24 06:32:50 <opal> sudo spat out at me right away when i tried to invoke it
2020-02-24 07:03:53 <opal> reminds me that i'd rather have capabilities for stuff like that
2020-02-24 07:04:08 <opal> (in general on linux, not particularly talking about alpine)
2020-02-24 09:03:53 <PureTryOut[m]> Cogitri: now I have different Qt package that with rootbld fails to find some private Qt modules. Works fine in docker-abuild. How does this even work? πŸ€”
2020-02-24 09:08:29 <Cogitri> 
ACTION shrugs

2020-02-24 09:09:01 <Cogitri> That's odd, it should be the same since rootbld installs all the packages as well
2020-02-24 09:21:54 <PureTryOut[m]> Where does abuild normally put it's built packages?
2020-02-24 09:22:27 <nmeum> $REPODEST
2020-02-24 09:22:42 <_ikke_> which defaults to ~/packages
2020-02-24 09:24:44 <PureTryOut[m]> Cool thanks
2020-02-24 09:29:07 <maxice8> It can be changed in /etc/abuild.conf
2020-02-24 09:46:09 <Cogitri> And you mustn't touch that value if you use dabuild because otherwise it can't find locally built packages
2020-02-24 09:46:15 <Cogitri> I tripped pretty hard over that
2020-02-24 09:53:10 <PureTryOut[m]> dabuild didn't seem to use $REPODEST anyway for me
2020-02-24 09:54:40 <clandmeter> PureTryOut[m]: dabuild repodest should not be set
2020-02-24 09:54:54 <clandmeter> you need to mount it to the correct location
2020-02-24 09:55:19 <PureTryOut[m]> What...? I have no issues with dabuild
2020-02-24 09:55:48 <Cogitri> It uses DABUILD_PACKAGES to place it in your filesystem but REPODEST is used to place the package files in the container
2020-02-24 09:56:12 <clandmeter> yes and if you change it you need to change mountpoint too
2020-02-24 09:56:17 <Cogitri> So if it's set to anything but $HOME/packages dabuild will put it in the wrong location (which isn't a bindmount)
2020-02-24 10:00:13 <PureTryOut[m]> Ah ok
2020-02-24 10:29:25 <PureTryOut[m]> How do you guys find out what needs to be rebuild when a package gets upgraded?
2020-02-24 10:30:39 <_ikke_> If you want to know what depends on a certain package, I use ap (from lua-aports) to find the reverse dependencies
2020-02-24 10:41:36 <Cogitri> !4338 contains some tips on that, PureTryOut
2020-02-24 10:42:53 <_ikke_> ap revdep <foo>-dev for each of the repositories
2020-02-24 10:44:00 <Cogitri> Can I reply to mails on the ML when I wasn't subscribed to the ML at the point of when the mail was sent?
2020-02-24 10:45:36 <_ikke_> mailing lists should not require subscription
2020-02-24 10:46:29 <_ikke_> Non subscribers Permissions: browse, post, reply
2020-02-24 10:52:50 <Cogitri> Yes, but how do I reply when I don't have the mail in my client?
2020-02-24 10:55:13 <_ikke_> Not sure if your client supports it, but you can manually set in-reply-to to the message id
2020-02-24 10:55:38 <_ikke_> Otherwise, often using the same subject would have the same effect
2020-02-24 11:04:14 <Cogitri> Alrighty, I guess I'll try that
2020-02-24 11:04:36 <tru_tru> Hi, https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases is missing 3.10.3 (https://alpinelinux.org/posts/Alpine-3.10.3-released.html) and 3.10.4 (404 for https://alpinelinux.org/posts/Alpine-3.10.4-released.html but https://git.alpinelinux.org/aports/log/?h=v3.10.4 exists )
2020-02-24 11:05:47 <AinNero> tru_tru: yes, that was an accident
2020-02-24 11:07:00 <AinNero> i think the post should have spelled 3.10.4, with 3.10.3 being left out
2020-02-24 11:22:00 <_ikke_> 3.10.3 was the mistagged one, right?
2020-02-24 11:24:48 <_ikke_> tru_tru: 3.10.3 is listed under latest release atm
2020-02-24 11:35:55 <tru_tru> right 3.10.3 listed as latest, instead of 3.10.4
2020-02-24 11:36:18 <tru_tru> my bad
2020-02-24 11:51:12 <PureTryOut[m]> Cogitri: I'm running Qt 5.14.1 atm on my laptop. Runs well, seems just Qt5WebEngine is broken like you mentioned
2020-02-24 11:56:34 <Cogitri> Yup, other than QtWebEngine it works fine for me too
2020-02-24 11:57:01 <Cogitri> Had to install qt5-qtbase-sqlite manually for some reason, no clue why that library was installed without a packages
2020-02-24 11:59:23 <Cogitri> Gonna look into what syscall QtWebEngine dies on soon
2020-02-24 11:59:46 <Cogitri> With my handy syscall tester thingie which probably is one giant hack but it does appear to work :P
2020-02-24 12:00:40 <Cogitri> Ugh, seems like I deleted that or at least I don't know where I put the .c file for that, so let's see if I can find the same Stackoverflow posts to copy and paste it together again, eh?
2020-02-24 12:21:56 <PureTryOut[m]> Lol nice
2020-02-24 12:33:47 <PureTryOut[m]> Failing syscall seems to be `sched_getparam`, whatever that is
2020-02-24 12:42:44 <PureTryOut[m]> Cogitri: seems Void might have a patch for it https://github.com/void-linux/void-packages/blob/master/srcpkgs/qt5/patches/0100-sandbox-sched_getparam.patch
2020-02-24 12:44:01 <Cogitri> Ah neat
2020-02-24 12:44:12 <Cogitri> I can try that after work unless you beat me to it :)
2020-02-24 12:49:20 <PureTryOut[m]> 
ACTION is compiling it right now but fuck does it take long

2020-02-24 12:52:46 <Cogitri> Yes, it still takes like half an hour on a 3950X
2020-02-24 12:53:10 <Cogitri> Even webkit2gtk only needs ~10 minutes, so I'm puzzled how QtWebEngine needs so much longer
2020-02-24 12:58:59 <PureTryOut[m]> Chromium takes 3 hours on my desktop, Firefox only half an hour. It's just that much bigger
2020-02-24 12:59:31 <PureTryOut[m]> Also webkit is different from webengine
2020-02-24 13:06:28 <Cogitri> Ah, fair
2020-02-24 13:28:56 <PureTryOut[m]> Cogitri: could you update Chatty to 0.1.7?
2020-02-24 13:53:55 <PureTryOut[m]> Oh awesome, qt5-qtwebengine compilation segfaulted πŸ˜’
2020-02-24 14:40:29 <PureTryOut[m]> And again... Seems I can't use my laptop while it's compiling it, yay. Guess you'll beat me after all Cogitri
2020-02-24 14:40:33 <PureTryOut[m]> *beat me to it
2020-02-24 14:42:40 <Cogitri> You still have 1:20 until I'm done with work :P
2020-02-24 14:42:54 <Cogitri> Sure, I can update Chatty later
2020-02-24 14:43:25 <PureTryOut[m]> Yeah I'm not going to make that lol
2020-02-24 15:02:05 <Cogitri> Oof
2020-02-24 15:37:17 <td34> hi
2020-02-24 15:37:25 <td34> hihas anyone created a package here? I'm looking at finding out how the signatures for the packages are created
2020-02-24 15:38:46 <mps> look at abuild
2020-02-24 15:39:07 <_ikke_> td34: there is a huge difference between creating a package and knowing in detail how packages are signed :)
2020-02-24 15:39:37 <td34> I'm sure there is :)  trying to find the details is providing difficult. I'll have to read a bunch of C if no luck here :(
2020-02-24 15:39:58 <mps> ah, you want technical details
2020-02-24 15:40:04 <TBB> abuild-sign
2020-02-24 15:40:19 <TBB> unless the package format has changed already, which was planned
2020-02-24 15:40:28 <_ikke_> not yet
2020-02-24 15:40:40 <TBB> and that's readable
2020-02-24 15:40:47 <TBB> abuild-sign, that is
2020-02-24 15:40:50 <td34> so, what i don't really understand is how they verify it
2020-02-24 15:40:53 <mps> abuild-sign -q APKINDEX.tar.gz.$$ &&
2020-02-24 15:41:10 <reidrankin> @td34 i can help with that
2020-02-24 15:41:13 <td34> When i open up an apk there is a signed blob there, which is good
2020-02-24 15:41:41 <td34> And i've found the public key, but i'm not sure if they hash the usr directory or tar it up then hash/sign
2020-02-24 15:41:56 <reidrankin> so turns out gzip is a neat format in that you can concatenate two gzip files and it's a perfectly valid gzip file containing the concatenation of the contents
2020-02-24 15:42:26 <td34> oh nice
2020-02-24 15:42:32 <reidrankin> also turns out tar is a neat format in that you can concatenate two tar files and it's a perfectly valid tar file containing the concatenation of the contents
2020-02-24 15:43:04 <reidrankin> (with the caveat that tar files contain an "end-of-tar" record of like a kilobyte of zeros at the end, so you gotta chop that off the first one)
2020-02-24 15:43:54 <td34> ok
2020-02-24 15:43:55 <TBB> and for that there's a tool
2020-02-24 15:44:09 <TBB> was it apk-gzsplit or abuild-gzsplit
2020-02-24 15:44:31 <reidrankin> abuild-tar --cut to kill the end-of-tar record
2020-02-24 15:44:46 <TBB> but the pkgsign script tells you how the signing happens
2020-02-24 15:44:52 <TBB> ah, cutting has been integrated
2020-02-24 15:45:05 <reidrankin> yeah, i'm just breaking down the process
2020-02-24 15:45:50 <td34> but for individual packages there isn't a .tar file inside
2020-02-24 15:45:57 <reidrankin> despite the concatenated-gzip thing, if you're writing an app that uses libz (like, say, APK) you can detect the end of each gzip block in the file as it comes up
2020-02-24 15:46:20 <td34> it's just a tar.gz with a usr directory, .PKGINFO and the signature
2020-02-24 15:46:26 <td34> at least that's what it appears to be
2020-02-24 15:47:05 <reidrankin> technically that's correct, but it's actually something like `cat signature.tar.gz control.tar.gz data.tar.gz`
2020-02-24 15:47:52 <reidrankin> due to the aforementioned cleverness regarding slicing off the end-of-tar records (which are technically optional anyway) that makes a valid tarball containing all those files
2020-02-24 15:47:54 <td34> does cat open up a gz?
2020-02-24 15:48:04 <reidrankin> no, it just sticks them end to end
2020-02-24 15:48:06 <td34> oh right
2020-02-24 15:48:40 <td34> does it then hash all of the files and sign? or something else?
2020-02-24 15:49:03 <_ikke_> I think it creates a tar and sign that, but not sure
2020-02-24 15:49:09 <reidrankin> but when APK reads that concatenated stuff it's clever and can tell the boundaries of the underlying gzip chunks
2020-02-24 15:50:00 <td34> reidrankin do you know when the signatures are calculated?
2020-02-24 15:50:01 <reidrankin> for the next bit, keep in mind that when you're calculating the hash of a thing, you gotta do it sequentially
2020-02-24 15:50:10 <reidrankin> td34: getting there
2020-02-24 15:50:11 <td34> or i should say "what is the input for the signature generation"
2020-02-24 15:50:14 <td34> :)
2020-02-24 15:50:33 <reidrankin> easier to explain how APK verifies, that'll tell you how to make the sigs
2020-02-24 15:50:50 <reidrankin> so APK only wants to have to read the package once
2020-02-24 15:51:30 <reidrankin> it would be too expensive to read it once, calculate the hash so you can check a signature, and then read it again
2020-02-24 15:52:00 <reidrankin> so it starts searching at the beginning of the series of gzipped chunks for a signature it recognizesd
2020-02-24 15:52:53 <reidrankin> any block containing only files starting with ".SIGN." is considered a signature block, and isn't verified
2020-02-24 15:53:13 <td34> ok
2020-02-24 15:54:00 <reidrankin> APK will read signature blocks in until it finds a file named ".SIGN.<probably RSA>.<name of file in /etc/keys>"
2020-02-24 15:54:13 <td34> yep
2020-02-24 15:55:15 <reidrankin> I say probably rsa, but it supports RSA (over sha-1), DSA, and sort-of RSA256 (using sha-256; unfortunately it segfaults because of a bug when trying to install these though)
2020-02-24 15:55:40 <reidrankin> the first one that matches gets set as the signature that will be verified and the rest of the signature blocks are skipped
2020-02-24 15:56:05 <reidrankin> the first block containing something not named ".SIGN." is considered the control block
2020-02-24 15:56:38 <reidrankin> this usually contains .PKGINFO, as well as any scripts APK runs on installation or removal or whatever
2020-02-24 15:56:47 <reidrankin> the signature is checked over this block
2020-02-24 15:57:07 <reidrankin> .PKGINFO is a series of lines formatted like "key = value"
2020-02-24 15:57:23 <reidrankin> one of the lines might have the key "datahash"
2020-02-24 15:57:32 <reidrankin> if it does, that hash is recorded
2020-02-24 15:57:38 <reidrankin> (sha-256)
2020-02-24 15:58:30 <td34> ok
2020-02-24 15:58:33 <reidrankin> also, i lied earlier, the signature is checked against the hash of the control block if that line is present; if it isn't, it's checked against the hash of the control block + data block in sequence
2020-02-24 15:58:39 <td34> so pulls the hash from the .PKGINFO
2020-02-24 15:59:16 <reidrankin> (essentially there's one running hash state, and it's checked and reset between the control and data block if that line is there; otherwise it's done at the end)
2020-02-24 15:59:43 <reidrankin> then it decompresses the contents of the data block into a temporary directory, hashing the block as it goes
2020-02-24 16:00:15 <td34> hmm
2020-02-24 16:00:16 <td34> confusing
2020-02-24 16:00:44 <reidrankin> when done, it either checks the final hash against the datahash line (which was in the already-sig-checked control block) or against the signature, if there was not datahash line
2020-02-24 16:00:48 <td34> so if there is a hash as a value in the .PKGINFO the verifier will use that to check the signature?
2020-02-24 16:01:27 <reidrankin> yeah; the benefit is that it makes it quick to check the signature of a package that's large
2020-02-24 16:01:40 <td34> cool
2020-02-24 16:01:49 <reidrankin> you just gotta read the sig block (there's typically only one; no rule that says that though) and the control block
2020-02-24 16:02:00 <td34> and if the PKGINFO doesn't contain a hash then it has to do?
2020-02-24 16:02:37 <reidrankin> if no hash in the pkginfo it doesn't perform the sig check at the end of the control block and reset the hash state
2020-02-24 16:02:54 <reidrankin> it just keeps putting the data block chunks into the running hash and checks the sig at the end
2020-02-24 16:03:15 <td34> ooh i guess that's the interesting thing
2020-02-24 16:03:28 <td34> how does it keep "putting data block chunks into the running hash"
2020-02-24 16:03:48 <reidrankin> essentially, either .PKGINFO has the datahash line and the sig is over control.tar.gz, or it doesn't have the line and the sig is over `cat control.tar.gz data.tar.gz`
2020-02-24 16:04:00 <td34> ohhhh
2020-02-24 16:04:01 <reidrankin> hash functions have an internal state
2020-02-24 16:04:05 <td34> so they litrally do something like
2020-02-24 16:04:19 <reidrankin> you initialize it at the beginning and then you stick data in there
2020-02-24 16:04:29 <reidrankin> you can do that a bunch
2020-02-24 16:04:31 <td34> cat control.tar.gz data.tar.gz | hash_function
2020-02-24 16:04:54 <reidrankin> and then you "finalize" the hash, which extracts the final hash value from the opaque state object
2020-02-24 16:05:19 <reidrankin> each hash has a different way to initialize, update, and finalize, but that's how they all work
2020-02-24 16:05:28 <td34> ok nice
2020-02-24 16:05:52 <td34> obviously i'm going to be recieving a .apk file, how would i retrieve the control/data tar
2020-02-24 16:06:10 <td34> whenever i open up the .apk file it just appears as a usr dir and associated .PKGINFO and .sign
2020-02-24 16:06:12 <reidrankin> there's nothing actually named control.tar.gz or data.tar.gz
2020-02-24 16:06:28 <td34> so it would just be running the hash function over the usr dir?
2020-02-24 16:07:17 <reidrankin> those are actually the individual gzipped chunks
2020-02-24 16:07:58 <reidrankin> you use abuild-gzsplit to split an apk into those chunks
2020-02-24 16:09:24 <reidrankin> it's `cat whatever.apk | abuild-gzsplit`
2020-02-24 16:09:52 <reidrankin> that'll spit out a files named signatures.tar.gz, control.tar.gz, and data.tar.gz
2020-02-24 16:09:56 <td34> ok
2020-02-24 16:10:20 <td34> i wonder if you can take the datahash and pass that into openssl to validate the signature
2020-02-24 16:11:13 <reidrankin> but remember those names are just what abuild-gzplit calls them -- they're not named in the APK, they're just concatenated blocks, and which is each one is determined by the rules about the tar file's contents
2020-02-24 16:12:09 <reidrankin> first one with anything but stuff starting with ".SIGN." is the control block, everything before is left in signatures.tar.gz
2020-02-24 16:12:23 <reidrankin> first block containing a non-hidden file (not starting with .) is the data block
2020-02-24 16:12:56 <reidrankin> a simple `sha256sum data.tar.gz` will spit out the same thing as is on the datahash line
2020-02-24 16:13:09 <td34> yep
2020-02-24 16:13:32 <reidrankin> and the signature is verifiable with openssl (rsautl i think? been a while); it's over the control.tar.gz
2020-02-24 16:13:41 <td34> ideally id like to be able to take a public key, hash from the .PKGINFO, and validate the signature with that info
2020-02-24 16:13:56 <reidrankin> (or `cat control.tar.gz data.tar.gz` if .PKGINFO is missing datahash)
2020-02-24 16:14:33 <reidrankin> you can indeed do the verification manually if you want
2020-02-24 16:15:02 <td34> you ever used openssl much :P
2020-02-24 16:16:02 <td34> i'm guessing it's sha1 too?
2020-02-24 16:16:20 <reidrankin> datahash is sha256, signature is sha1
2020-02-24 16:16:23 <reidrankin> or md5
2020-02-24 16:16:43 <reidrankin> or sha256, if you want apk verify to work but apk install to segfault
2020-02-24 16:16:56 <td34> hmm why does it segfault lol
2020-02-24 16:17:17 <reidrankin> because the code is inconsistent with the size of the buffer it expects
2020-02-24 16:18:16 <reidrankin> I made a patch to fix it, but it was rejected because fixing it would let people use sha256 signatures
2020-02-24 16:18:26 <reidrankin> let me explain
2020-02-24 16:18:40 <td34> aren't there collision issues with SHA1
2020-02-24 16:18:52 <reidrankin> yeah, that's why I wrote the MR for it
2020-02-24 16:19:25 <reidrankin> i'm a software engineer and apk is a very strange program in that it works really well
2020-02-24 16:20:07 <reidrankin> as in now that I've read the code I'm very surprised it does as well as it does but I gotta admit it's really good in practice
2020-02-24 16:20:31 <reidrankin> there's a lot of hyper-optimization in very odd places
2020-02-24 16:20:50 <td34> you must be a C expert :P
2020-02-24 16:21:02 <reidrankin> yep
2020-02-24 16:21:10 <td34> i've only dabbled in C
2020-02-24 16:21:16 <reidrankin> one of those places is that the internal list of packages is stored in this homegrown hash table thing
2020-02-24 16:21:36 <reidrankin> it's an instrusive container with no documentation powered by a bunch of magic preprocessor macros
2020-02-24 16:22:09 <reidrankin> it's absolutely horrible and i hate that it works somehow
2020-02-24 16:22:19 <td34> haha
2020-02-24 16:22:24 <td34> documentation does seem abit thin on the ground
2020-02-24 16:22:29 <reidrankin> you have no idea
2020-02-24 16:23:31 <reidrankin> I spent more than 12 hours the other day trying to figure out how APK does version comparisons
2020-02-24 16:23:32 <td34> hence why im here
2020-02-24 16:23:57 <td34> tbh now i know it's got the hash the next problem is me trying to figure out how openssl can verify a hash rather than a file
2020-02-24 16:23:59 <reidrankin> there's a single comment containing what sort of looks like a pseudo-regexp as documentation
2020-02-24 16:24:34 <reidrankin> and it's wrong, but not so much as you'd notice unless you were reverse-engineering it
2020-02-24 16:24:38 <td34> i'm assuming openssl hashes the file it's provided and then uses the public key to verify
2020-02-24 16:24:50 <td34> nice
2020-02-24 16:25:01 <reidrankin> anyhow, the hashtable that the list of installed packages is stored in uses the hash of the package as the key
2020-02-24 16:25:23 <reidrankin> and the solver (the thing that figures out dependencies and such) pulls from that hash table
2020-02-24 16:25:45 <reidrankin> so if you use a different hash as the key, the packages will be traversed in a different order
2020-02-24 16:26:40 <reidrankin> and because the hash that is used is the one calculated while comparing the signature, signing with SHA-256 would change how the solver calculates dependencies
2020-02-24 16:26:55 <reidrankin> now ideally it wouldn't matter because the solver would come to the same answer
2020-02-24 16:27:19 <reidrankin> but no one can be sure that actually happens because it takes *weeks* to understand apk-tools
2020-02-24 16:27:42 <td34> :P
2020-02-24 16:27:58 <reidrankin> i'm not even kidding. that's literal. I'm working on it as we speak.
2020-02-24 16:28:01 <td34> one of the reasons i want to write something using openssl to validate the signature is because there is more trust in it
2020-02-24 16:28:36 <td34> or
2020-02-24 16:28:39 <td34> i should say it's easier to read :P
2020-02-24 16:29:12 <reidrankin> so sha256 signatures are supported, but they cause a segfault on install. and you can't fix the segfault because then people could use the signatures. and if they did it would change how the solver behaves and we don't have enough confidence that it will come up with the correct answer anyway to allow that.
2020-02-24 16:29:49 <reidrankin> and the worst part is that APK is still amazing.
2020-02-24 16:30:44 <td34> hahaha
2020-02-24 16:30:52 <td34> i prefer how ubuntu package managers do it
2020-02-24 16:30:53 <td34> seems much easier
2020-02-24 16:31:19 <td34> could you do me a favour - can you figure out how to validate a signature from a hash haha
2020-02-24 16:31:21 <td34> only if you have time
2020-02-24 16:31:27 <reidrankin> it's super tiny, it does all you need it to and nothing you don't, it's fast. It's just nigh-on-unmaintainable.
2020-02-24 16:31:53 <td34> that's alpine in a nutshell isn't it :P
2020-02-24 16:32:29 <reidrankin> not true, alpine is one of my favorite distros because it's easy to maintain stuff in it
2020-02-24 16:32:53 <td34> i meant the what you need it to and nothing you don't
2020-02-24 16:32:56 <td34> that is the point of it right
2020-02-24 16:33:04 <reidrankin> a single person has a hope, with enough study, of understanding the entire system
2020-02-24 16:33:31 <reidrankin> i feel confident in saying that I can debug any alpine problem given enough time, which is something I couldn't say with ubuntu or fedora or something
2020-02-24 16:33:56 <td34> cool
2020-02-24 16:34:05 <reidrankin> 95% of the time, sure, but they're just too complicated to be sure you can definitely fix anything
2020-02-24 16:34:29 <reidrankin> anyhow, yeah, put the apk through abuild-gzsplit
2020-02-24 16:34:30 <td34> another quick question, when alpine creates the hash and sticks it into the .PKGINFO does it use padding?
2020-02-24 16:34:36 <reidrankin> no
2020-02-24 16:34:41 <reidrankin> it's a text file
2020-02-24 16:34:53 <td34> so it doesn't use PKCS#1#
2020-02-24 16:35:06 <reidrankin> the hash is just a lowercase hex string
2020-02-24 16:35:07 <td34> sorry dont worry am getting confused
2020-02-24 16:35:22 <reidrankin> yeah, that's signatures
2020-02-24 16:35:39 <td34> i just don't get why providing a signature to openssl won't work lol
2020-02-24 16:35:53 <reidrankin> openssl dgst -sha1 -sign /path/to/key control.tar.gz will create a signature
2020-02-24 16:36:07 <td34> already got the signature though
2020-02-24 16:36:10 <td34> it's how i validate it
2020-02-24 16:36:28 <reidrankin> (i know, i'm just going through my command line history looking for the answer)
2020-02-24 16:38:19 <td34-pc> this is the current command i'm using : openssl dgst -sha1 -verify alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub -signature sig hash
2020-02-24 16:38:28 <td34> *that's me on my pc :P
2020-02-24 16:38:36 <reidrankin> yeah, just came up with the same thing
2020-02-24 16:38:57 <td34-pc> but i think the issue is that it would take the hash file and create a hash of that, hence why it's messing up
2020-02-24 16:39:13 <reidrankin> openssl dgst -sha1 -verify /etc/apk/keys/alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub -signature .SIGN.alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub control.tar.gz
2020-02-24 16:39:41 <reidrankin> where the .SIGN. thing is the file inside the signatures.tar.gz
2020-02-24 16:39:54 <td34-pc> yep, but i don't know how to create the control.tar.gz
2020-02-24 16:40:28 <reidrankin> cat foo.apk | abuild-gzsplit
2020-02-24 16:40:38 <reidrankin> will create the file in the working directory
2020-02-24 16:41:32 <td34> ideally i don't want to use a tool which is already used in the validation of the normal apk product
2020-02-24 16:41:37 <reidrankin> then you gotta pull the datahash from the .PKGINFO and check it against `sha256sum data.tar.gz`
2020-02-24 16:41:50 <reidrankin> well, FWIW abuild isn't apk
2020-02-24 16:42:23 <reidrankin> totally different code used in abuild-gzsplit and apk internally
2020-02-24 16:42:30 <td34> ok
2020-02-24 16:42:44 <td34> is abuild-gzsplit available on anything other than apline?
2020-02-24 16:43:16 <reidrankin> idk? you could build it for whatever, or maybe there's a statically linked version?
2020-02-24 16:44:11 <reidrankin> you could do `cat foo.apk | abuild-gzsplit; sha256sum foo.apk; cat signatures.tar.gz control.tar.gz data.tar.gz | sha256sum` and verify those last two sums are the same
2020-02-24 16:44:18 <td34> is the file that comes out of cat foo.apk | abuild-gzsplit the one i need to sha256 checksum?
2020-02-24 16:44:28 <reidrankin> that'll ensure there's not trickery in abuild-gzplit
2020-02-24 16:45:01 <reidrankin> abuild-gzplit dumps signatures.tar.gz, control.tar.gz, and data.tar.gz into the working directory
2020-02-24 16:45:06 <reidrankin> no stdout
2020-02-24 16:45:11 <td34> ok
2020-02-24 16:45:29 <reidrankin> `cat signatures.tar.gz control.tar.gz data.tar.gz` will get you foo.apk back byte-for-byte
2020-02-24 16:45:34 <reidrankin> which you can check
2020-02-24 16:45:52 <td34> i need to figure out how to take the abuild-gzsplit.c and compile it
2020-02-24 16:45:54 <td34> brb
2020-02-24 16:46:30 <reidrankin> then you gotta extract .SIGN.alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub from the signatures.tar.gz and do `openssl dgst -sha1 -verify /etc/apk/keys/alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub -signature .SIGN.alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub control.tar.gz`
2020-02-24 16:46:55 <reidrankin> then you gotta extract .PKGINFO from control.tar.gz and make sure the datahash line matches `sha256sum data.tar.gz`
2020-02-24 16:47:00 <reidrankin> and that'll do it
2020-02-24 16:47:05 <td34> ooooHHHH
2020-02-24 16:47:20 <td34> so the signature is just for the .PKGINFO
2020-02-24 16:47:21 <reidrankin> caveat: apk uses a fairly hardened tar archive parser
2020-02-24 16:47:22 <td34> and if you trust that
2020-02-24 16:47:31 <reidrankin> no, it's over control.tar.gz
2020-02-24 16:47:33 <td34> you use hash to check the data
2020-02-24 16:47:43 <reidrankin> which contains .PKGINFO and maybe other stuff
2020-02-24 16:47:43 <td34> but control.tar.gz is the .PKGINFO isn't it?
2020-02-24 16:47:47 <td34> got ya ;)
2020-02-24 16:48:15 <reidrankin> mostly not, but preinstall scripts and stuff are in there
2020-02-24 16:48:29 <td34> thanks for your help
2020-02-24 16:48:57 <reidrankin> right, caveat: apk uses a fairly hardened tar archive parser, which I would trust more than the typical tar utility on untrusted input
2020-02-24 16:49:24 <reidrankin> especially if you're unzipping the thing to the filesystem instead of running through the files in memory
2020-02-24 16:49:49 <reidrankin> like, apk won't let you have a signatures.tar.gz with "/bin/sh" inside
2020-02-24 16:49:55 <reidrankin> because that doesn't start with a .
2020-02-24 16:50:21 <td34> thanks for allof your help :)
2020-02-24 16:50:24 <reidrankin> (fun fact, having that file in there would cause that block to be considered the data block)
2020-02-24 16:50:49 <reidrankin> hope it helps
2020-02-24 17:38:05 <_ikke_> anyone has an idea where pllerrorcodes should come from? (s390x is failing to build postgresql-pllua)
2020-02-24 17:39:09 <_ikke_> It's in the source from postgres
2020-02-24 17:39:29 <AinNero> hm, rsyslog + logrotate dont work in the default state
2020-02-24 17:39:45 <AinNero>  /var/log/messages is rotated per default via logrotate pkg
2020-02-24 17:40:14 <AinNero> and everyone that installs another logrotate rule on that file is ignored
2020-02-24 17:40:39 <AinNero> so if rsyslog is installed, the rsyslog.logrotate is ignored, and all the other files there dont get rotated
2020-02-24 17:41:16 <AinNero> can someone revert aports 5d232331b7421bef5851f167f105e8282db5f4ba ?
2020-02-24 17:42:39 <_ikke_> But you don't want to completely disable rotation of /var/log/messages
2020-02-24 17:43:36 <AinNero> look at main/rsyslog/rsyslog.logrotate
2020-02-24 17:44:03 <_ikke_> But that assumes you have syslog installed
2020-02-24 17:44:08 <_ikke_> what if you don't have syslog
2020-02-24 17:44:17 <_ikke_> rsyslog
2020-02-24 17:44:33 <AinNero> then the logrotate should come with the busybox syslogd
2020-02-24 17:44:43 <AinNero> or none if there is none
2020-02-24 17:44:57 <AinNero> the thing is, with rsyslogd, mail.log never got rotated
2020-02-24 17:45:02 <AinNero> which is not very nice on a active mail server
2020-02-24 17:45:50 <_ikke_> Is it expected that logrotate ignores those entries?
2020-02-24 17:46:02 <AinNero> i dont think so
2020-02-24 17:46:19 <AinNero> > error: rsyslog:1 duplicate log entry for /var/log/messages
2020-02-24 17:46:20 <AinNero> > error: found error in file rsyslog, skipping
2020-02-24 17:46:46 <_ikke_> You have multiple systems that want to manage logrotate for /var/log/messages
2020-02-24 17:47:49 <AinNero> right now there is a generic way in logrotate.conf
2020-02-24 17:48:00 <AinNero> but that does not send reload signals to any possible syslod daemons
2020-02-24 17:48:35 <_ikke_> would be nice of logrotate would allow you to extend / override rules
2020-02-24 17:48:38 <AinNero> we could remove the line from logrotate.conf and make use of the busybox syslogd -b option
2020-02-24 17:48:53 <AinNero> -b for, implicit logrotate, without helper program
2020-02-24 17:50:36 <AinNero> whats most annoying for me is that i need to edit logrotate.conf for drop-ins in logrotate.d to work
2020-02-24 17:51:27 <_ikke_> Even if it was a drop-in itself, it would still conflict I guess
2020-02-24 17:57:24 <_ikke_> Maybe some kind of subpackage that automatically gets removed when you install rsyslog?
2020-02-24 17:57:33 <AinNero> i just checked a fresh alpine setup
2020-02-24 17:57:46 <AinNero> that rotates the log without logrotate being installed
2020-02-24 17:57:54 <AinNero> i think its an busybox syslogd feature
2020-02-24 17:58:09 <_ikke_> how / when does it rotate?
2020-02-24 17:58:46 <AinNero> i suspect its at 200k
2020-02-24 17:59:09 <_ikke_> ah, size based
2020-02-24 17:59:24 <AinNero> this is the default as it seems from syslogd --help
2020-02-24 17:59:53 <AinNero> uhm, since the line in logrotate.conf does not send any signal to syslogd, i would consider it broken anyways
2020-02-24 17:59:57 <_ikke_> Then I wonder why kunkku added that
2020-02-24 18:00:02 <AinNero> are they here?
2020-02-24 18:00:07 <_ikke_> yes
2020-02-24 18:00:12 <_ikke_> but probably afk
2020-02-24 18:14:54 <_ikke_> Anyone aware of some kind of change that causes projects to sunddenly require clang?
2020-02-24 18:18:50 <_ikke_> This shows that clang is installed, but when I run abuild deps on that package, it does not install clang:
2020-02-24 18:18:52 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/postgresql-pllua/postgresql-pllua-2.0.4-r1.log
2020-02-24 18:48:57 <_ikke_> frustrating, postgresql-pllua builds fine in a docker container, though I had to add clang-dev and llvm9-dev as makedepends
2020-02-24 18:53:32 <mps> _ikke_: I think it is because JIT is enabled in some previous commit, but didn't tested
2020-02-24 18:54:21 <_ikke_> jit is disabled on s390x
2020-02-24 18:54:56 <mps> aha, then something else
2020-02-24 18:55:18 <_ikke_> This is the 2nd package btw where I had to add clang-dev / llvm9-dev
2020-02-24 18:55:37 <mps> although I think we enabled JIT in postgresql too fast, maybe it should wait next PG major release
2020-02-24 18:55:45 <_ikke_> da044de28fc4fa8e06191a5d5c465c79675426f1
2020-02-24 18:56:08 <_ikke_> mps: I must say, luajit is not used on s390x
2020-02-24 18:56:14 <mps> this is also related to pg
2020-02-24 18:56:51 <mps> postgresql got JIT in latest release
2020-02-24 18:57:38 <mps> or maybe even one release earlier, not sure, writing from head
2020-02-24 18:57:51 <_ikke_> I don't think this issue is related to jit though
2020-02-24 18:59:24 <mps> I don't want to say that, just noted that this new stuff could be issue
2020-02-24 19:00:55 <mps> I'm not sure if the interoperability of PG, lua, llvm and clang tested enough
2020-02-24 19:04:39 <_ikke_> My biggest question is why clang/llvm are not pulled in like on the builders
2020-02-24 19:08:22 <Cogitri> Require clang as in needs it to build or needs libclang?
2020-02-24 19:08:36 <_ikke_> needs to build
2020-02-24 19:08:51 <_ikke_> it looks for /usr/bin/clang
2020-02-24 19:09:09 <mps> hmm, src/error.c:1279:10: fatal error: 'plerrcodes.h' file not found
2020-02-24 19:09:12 <_ikke_> yes
2020-02-24 19:09:20 <_ikke_> That's generated in the Makefile
2020-02-24 19:09:22 <Cogitri> Oof, hardcoding a compiler
2020-02-24 19:09:33 <mps> oof
2020-02-24 19:10:16 <_ikke_> Cogitri: same for proj btw
2020-02-24 19:10:26 <_ikke_> I had the exact same
2020-02-24 19:10:50 <_ikke_> So it looks more like a pattern that's caused by something being changed
2020-02-24 19:10:57 <mps> perl lua err codes?
2020-02-24 19:11:06 <_ikke_> sorry, not proj, postgis
2020-02-24 19:11:22 <_ikke_> but also related to postgres
2020-02-24 19:13:50 <_ikke_> Cogitri: note that gcc is used in general, it's just one step where it needs clang
2020-02-24 19:14:45 <_ikke_> And I could not find clang being hardcoded
2020-02-24 19:15:09 <_ikke_> Where is the default linker defined?
2020-02-24 19:20:45 <Cogitri> -fuse-linker= ?
2020-02-24 19:21:31 <_ikke_> It's generating .bc files with clang apparently
2020-02-24 19:24:07 <Cogitri> Whatever that is
2020-02-24 19:24:20 <_ikke_> llvm bytecode apparently
2020-02-24 19:28:08 <_ikke_> I guess this is out of my league
2020-02-24 19:28:29 <_ikke_> I have no idea what in the makefile (or anywhere else) triggers clang to be executaed
2020-02-24 19:28:34 <_ikke_> executed
2020-02-24 19:43:35 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10675
2020-02-24 19:45:32 <Cogitri> ikke: Just so I understand: this only happens on the builders and no in abuild?
2020-02-24 19:45:37 <Cogitri> clandmeter: Ah nice :)
2020-02-24 19:47:24 <_ikke_> Cogitri: on both the builders, and in a docker container, clang is used at the end of the build process
2020-02-24 19:47:36 <_ikke_> Cogitri: On the builders, clang at least is automatically pulled in
2020-02-24 19:48:09 <_ikke_> Cogitri: On the builder, it fails due to plerrorcodes.h missing, which does not happen in a docker container
2020-02-24 19:49:25 <Cogitri> Alright, so I can test this on a docker container when doing !clang in the makedepends?
2020-02-24 19:49:45 <_ikke_> Cogitri: at least for me, if clang-dev is not in makedepends, it's not even installed
2020-02-24 19:49:53 <_ikke_> Cogitri: I did not test it on non-s390x
2020-02-24 19:50:27 <_ikke_> ie, I only tested it on s390x
2020-02-24 19:50:52 <Cogitri> Ah, that I can't do, I suppose
2020-02-24 19:57:31 <clandmeter> maxice8: ^
2020-02-24 19:58:31 <maxice8> @clandmeter yes ?
2020-02-24 19:58:47 <clandmeter> the issue posted
2020-02-24 19:59:10 <clandmeter> I wonder if we should make a dedicated issue for just aports.
2020-02-24 19:59:31 <maxice8> neat
2020-02-24 20:00:11 <clandmeter> i think everything is in place to do the switch
2020-02-24 20:00:24 <clandmeter> but i would like to wait for ncopa to be around to do it.
2020-02-24 20:07:49 <_ikke_> Cogitri: strange, on x86_64, it does pull in clang
2020-02-24 20:38:33 <PureTryOut[m]> Cogitri: Qt MR is ready for merging!
2020-02-24 20:39:00 <maxice8> DO IT :D
2020-02-24 21:11:44 <Cogitri> Nice
2020-02-24 21:17:31 <_ikke_> re squid
2020-02-24 21:17:56 <mps> yes, as I see these cves aren't backported
2020-02-24 21:18:45 <mps> c960394d423ce258a68bf53364ae13b6e331d8fe
2020-02-24 21:18:56 <mps> this is 3.11-stable
2020-02-24 21:18:59 <_ikke_> mps: 4.10 fixed 4 CVEs btw
2020-02-24 21:19:34 <mps> I must be blind
2020-02-24 21:19:41 <_ikke_> one advisory contains 2
2020-02-24 21:19:51 <mps> meh, yes
2020-02-24 21:19:58 <_ikke_> http://www.squid-cache.org/Advisories/SQUID-2020_1.txt
2020-02-24 21:20:03 <mps> I'm actually blind :)
2020-02-24 21:21:02 <_ikke_> building 4.10 now
2020-02-24 21:21:19 <mps> and they are backported to 3.10-stable c960394d423ce258a68bf53364ae13b6e331d8fe
2020-02-24 21:22:04 <mps> but not to 3.9-stable
2020-02-24 21:23:44 <mps> I need some fresh air
2020-02-24 21:24:04 <_ikke_> Shoud squid be in main if they are not supporting older versions?
2020-02-24 21:24:08 <_ikke_> Should
2020-02-24 21:24:27 <_ikke_> Now the burden falls on us to backport these fixes
2020-02-24 21:24:34 <maxice8> I think, no
2020-02-24 21:24:56 <mps> it should
2020-02-24 21:25:04 <maxice8> being in main/ should be an amazing privilege
2020-02-24 21:25:24 <_ikke_> mps: we are hardly keeping up with CVE fixes
2020-02-24 21:25:36 <mps> if gnuchess is in main then why not squid :)
2020-02-24 21:25:46 <_ikke_> gnuchess should also not be in main
2020-02-24 21:25:51 <_ikke_> nobody bothered to move it yet
2020-02-24 21:26:02 <_ikke_> and gnuchess is not riddled with CVE's I guess :)
2020-02-24 21:26:09 <mps> _ikke_: I'm joking, ofc better place is community
2020-02-24 21:26:33 <maxice8> @mps because gnuchess was problably made before repository separation
2020-02-24 21:26:40 <maxice8> i don't think any graphical application should be in main/ really
2020-02-24 21:26:41 <_ikke_> mps: sometimes hard to gauge how serious someone is :)
2020-02-24 21:26:54 <mps> actually I'm waiting n_copa back to move gnuchess to community
2020-02-24 21:27:14 <_ikke_> mps: honestly I don't think ncopa would mind if it was moved
2020-02-24 21:27:17 <mps> xorg?
2020-02-24 21:27:21 <maxice8> yes
2020-02-24 21:27:31 <_ikke_> ok, squid 4.10 built fine
2020-02-24 21:27:32 <mps> maxice8: I agree actually
2020-02-24 21:28:02 <mps> but now really going on fresh air
2020-02-24 21:28:06 <_ikke_> shouldn't initd files be in source?
2020-02-24 21:28:29 <_ikke_> ah it is
2020-02-24 21:33:36 <maxice8> !4465
2020-02-24 21:38:43 <_ikke_> !4468
2020-02-24 22:05:47 <_ikke_> squid is pushed
2020-02-24 22:08:08 <mps> meh, to fast
2020-02-24 22:08:21 <mps> but I see you changed commit message
2020-02-24 22:08:31 <mps> all is good
2020-02-24 22:12:35 <_ikke_> I didn't change the commits
2020-02-24 22:12:47 <_ikke_> That's how they were already
2020-02-24 22:13:13 <_ikke_> I chose the make the MR about the statedir fix, because that's what motivated me to do this in the first place
2020-02-24 22:14:14 <mps> yes, I noticed that when I saw it in #alpine-commits
2020-02-24 22:14:25 <mps> sorry for mess
2020-02-24 22:14:39 <_ikke_> np ;)
2020-02-24 22:15:01 <_ikke_> I wish the gitlab interace would show commits as first class citicens
2020-02-24 22:19:26 <maxice8> @PureTryOut pushed Qt by request from @Cogitri
2020-02-24 22:19:41 <_ikke_> Hold on tight
2020-02-24 22:20:07 <PureTryOut[m]> Saw it, thanks!
2020-02-24 22:20:35 <maxice8> the builders are going to be very busy
2020-02-24 22:22:06 <MY-R> no eco mode :D
2020-02-24 22:30:36 <Cogitri> Thanks for looking into the Qt stuff, PureTryOut :)
2020-02-24 22:31:07 <maxice8> qt5-qttools failed because of missing vulkan/vulkan.h
2020-02-24 22:31:37 <Cogitri> Huh, that passed on CI
2020-02-24 22:31:48 <maxice8> armhf
2020-02-24 22:35:17 <Cogitri> Can we please add some kind of EOL date to our repos so users get a big fat warning during updates when they have an EOL release?
2020-02-24 22:35:38 <Cogitri> The amount of users having zombie setup where they mix 3.11 edge and 3.4 or 3.6 scares me
2020-02-24 22:39:47 <MY-R> most of them probably installing Alpine on sdcard/usb drives and dont bother to update same as docker users :P
2020-02-24 22:43:25 <Cogitri> Ugh, right
2020-02-24 22:43:39 <Cogitri> I think there's just generally a lot of confusion about mixing different branches
2020-02-24 22:44:16 <Cogitri> Really, I feel like apk should just print a warning when updating with mixed repos, it almost never goes well unless you use a just tagged release mixed with edge
2020-02-25 00:33:21 <reidrankin> clandmeter: just wanna say thanks for looking at !4056
2020-02-25 02:06:33 <timlegge90> Is there a process or criteria for moving aport packages from testing to community?
2020-02-25 02:49:13 <maxice8> @timlegge90 not super strictly defined, like a checklist
2020-02-25 02:49:37 <maxice8> in general: Make sure it works, and make an MR for it is the most common criteria.
2020-02-25 05:36:03 <maxice8> @mps ping re: terminfo dependency mess
2020-02-25 07:30:46 <maxice8> Can i get snapshots of the tarball of ncurses-6.1_p20191130 ?
2020-02-25 07:30:54 <maxice8> 3.11 and below have broken ncurses because of that
2020-02-25 07:31:06 <maxice8> 3.11 I believe I can update to the latest release
2020-02-25 07:32:29 <_ikke_> sorry, what do you mean
2020-02-25 07:33:03 <maxice8> the tarball in sources= of ncurses in the branches 3.11 and below
2020-02-25 07:33:07 <maxice8> are not available to be fetched
2020-02-25 07:33:30 <_ikke_> ah
2020-02-25 07:33:31 <maxice8> i need the mirrored in dev.a.o or a different link
2020-02-25 07:33:54 <maxice8> have to say, i hate when  projects do that, foomatic-db on Void Linux is the gold standard for doing that
2020-02-25 07:34:13 <maxice8> they have daily releases and delete all other archives that are not daily so your package basically can't be built unless you update it every day :DD
2020-02-25 07:34:55 <_ikke_> ugh, so anoying
2020-02-25 07:35:01 <_ikke_> ncurses-6.1-20191130.tgz, right?
2020-02-25 07:35:31 <maxice8> Yes
2020-02-25 07:35:31 <_ikke_> The hash matches
2020-02-25 07:38:23 <maxice8> ?
2020-02-25 07:38:54 <_ikke_> https://dev.alpinelinux.org/archive/ncurses/
2020-02-25 07:39:03 <_ikke_> The hash of the file I found matches the one in the APKBUILD
2020-02-25 07:39:10 <maxice8> oh
2020-02-25 07:39:11 <_ikke_> as confirmation I had the correct one
2020-02-25 07:39:40 <maxice8> oh, 3.10 is on 20190518
2020-02-25 07:40:25 <_ikke_> done
2020-02-25 07:40:55 <maxice8> That was quick
2020-02-25 07:41:00 <maxice8> how do you do it ?
2020-02-25 07:41:19 <_ikke_> I have access to the builders, and git is hosted on the same host (in an lxc container)
2020-02-25 07:41:24 <_ikke_> so it's literally just a cp for me
2020-02-25 07:41:39 <maxice8> oh
2020-02-25 07:42:38 <maxice8> And how others that have access to it do it ? scp ?
2020-02-25 07:42:46 <_ikke_> yes
2020-02-25 07:42:57 <_ikke_> scp to dev.a.o
2020-02-25 07:43:26 <maxice8> i see
2020-02-25 07:44:36 <maxice8> So yeah, someone pointed out that readline depended on ncurses-libs which should depend ONLY on ncurses-terminfo-base but it depends on ncurses-terminfo
2020-02-25 07:44:56 <maxice8> added around 7.5 MB extra
2020-02-25 07:45:06 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4536 :D has explanation of what happened
2020-02-25 07:47:59 <mps> maxice8: good morning
2020-02-25 07:48:13 <maxice8> @mps morning
2020-02-25 07:49:29 <mps> I'm too busy now, will explain later, just to tell that I proposed 'fix' terminfo and ncurses about year ago but some devs had objection
2020-02-25 07:49:46 <maxice8> ok
2020-02-25 07:49:51 <mps> and I ceased
2020-02-25 07:50:45 <mps> I have a hope for new 6.2 release we will do that, because that I marked MR with WIP
2020-02-25 07:51:09 <mps> or 'hold'
2020-02-25 08:35:12 <maxice8> @PureTryOut just to confirm, can I merge !4543 and !4545 as soon as the CI is green ?
2020-02-25 08:35:37 <PureTryOut[m]> If CI is green definitely, but I doubt it will turn green for 4545
2020-02-25 08:35:50 <maxice8> :D lets find out!
2020-02-25 08:41:56 <maxice8> yup broken
2020-02-25 08:42:06 <maxice8> fails on a shellscript apparently
2020-02-25 08:44:17 <PureTryOut[m]> > WARNING: Python version 2 (2.7.5 or later) is required to build QtWebEngine.
2020-02-25 08:44:22 <PureTryOut[m]> Well, screw that then...
2020-02-25 08:44:55 <maxice8> qtLog("Python version 3 is not supported by Chromium.")
2020-02-25 08:44:55 <maxice8> oof
2020-02-25 08:45:08 <PureTryOut[m]> Oh of course it's Chromium that's too blame
2020-02-25 08:45:17 <PureTryOut[m]> 99% of the compilation problems in qt5-qtwebengine also come from Chromium
2020-02-25 08:45:36 <PureTryOut[m]> (which is why we should make sure our patches for Chromium get upstreamed)
2020-02-25 08:46:16 <maxice8> From what i remember from Void Linux, the upstreaming experience is suboptimal
2020-02-25 08:46:36 <maxice8> i didn't do it myself, i just remember reading Void Linux contributors/members ranting
2020-02-25 08:47:42 <clandmeter> reidrankin: thanks for your contribution.
2020-02-25 08:48:08 <_ikke_> Would be nice if we could fix postgresql-pllua
2020-02-25 08:48:14 <_ikke_> is blocking s390x for some time now
2020-02-25 08:50:42 <PureTryOut[m]> maxice8: I have yet to look into it, but my main problem is that I can't explain the patches lol. Someone with knowledge about them needs to do it
2020-02-25 08:51:28 <PureTryOut[m]> maxice8: btw I pushed another commit to the Qt5 MR to also rebuild py3-qt5. Since the first CI pipeline already succeeded, you probably don't have to wait till the new one completes before merging
2020-02-25 08:51:40 <maxice8> ok i'll merge
2020-02-25 09:41:00 <maxice8> PureTryOut[m] (IRC): 6 to 8 are ok to merge if CI is green ?
2020-02-25 09:43:18 <Ariadne> north1: ack
2020-02-25 09:43:44 <Ariadne> or whoever leo is today
2020-02-25 09:43:58 <_ikke_> maxice8: :)
2020-02-25 09:45:09 <maxice8> yes ?
2020-02-25 09:45:36 <PureTryOut[m]> maxice8: yes
2020-02-25 09:45:41 <_ikke_> maxice8: was pointing out that you are north1 / Leo
2020-02-25 09:48:02 <maxice8> @Ariadne ack about ?
2020-02-25 09:48:12 <Ariadne> the apk gtk3
2020-02-25 09:48:45 <maxice8> ah ok, will push
2020-02-25 09:50:47 <PureTryOut[m]> Huh, why is startup-notification not built for armv7? It is enabled for it
2020-02-25 09:51:06 <PureTryOut[m]> Seems the builders skipped it or something?
2020-02-25 09:51:39 <maxice8> Wasn't rebuilt, armv7 is very busy atm
2020-02-25 09:51:44 <maxice8> libfilezilla also failed because of it
2020-02-25 09:51:57 <maxice8> If the MR doesn't concern armv7 specifically i think it is safe to push
2020-02-25 09:52:48 <PureTryOut[m]> It doesn't concern it specifically no
2020-02-25 09:53:02 <maxice8> !4548 ?
2020-02-25 09:57:21 <PureTryOut[m]> Yes
2020-02-25 11:41:03 <nmeum> maxice8: if you want PR feedback from me you have to give me more time than 8 hours to respond ;) but thanks for cleaning up rxvt-unicode, xfontsel and dwm
2020-02-25 11:41:27 <maxice8> @nmeum was more of notice than feedback :D
2020-02-25 11:41:44 <nmeum> ah
2020-02-25 11:41:44 <nmeum> ok
2020-02-25 11:42:58 <maxice8> oh wow luajit has 47k patch for s390x support :D
2020-02-25 11:42:59 <nmeum> also: I considered rxvt-unicode a common application which is why I kept it in main/ though I don't personally care which repo it is in as I use edge anyhow
2020-02-25 11:43:27 <nmeum> not sure what our current policy is regarding which packages should be in main/ and which should be in community/ (apart from the difference in "time supported" of cause)
2020-02-25 11:43:42 <maxice8> I was a little on the fence but moving from repo to repo but this is an action that is very easily reversible
2020-02-25 11:43:57 <maxice8> if someone asks it to be in main with good reason i just do: gbr app; ax m community; mgbr
2020-02-25 11:44:49 <nmeum> sure
2020-02-25 11:45:06 <nmeum> it just would be nice to have some general guideline regarding main/ vs. community/
2020-02-25 11:45:46 <_ikke_> nod
2020-02-25 11:46:41 <nmeum> for instance: dmenu is still in main/ currently but dwm/ isn't
2020-02-25 11:46:56 <maxice8> uhh
2020-02-25 11:47:16 <_ikke_> there is still a lot of legacy
2020-02-25 11:47:31 <_ikke_> lots of packages were in main before community existed
2020-02-25 11:47:40 <maxice8> i'm almost 100% sure i moved both dwm and dmenu to community
2020-02-25 11:47:46 <_ikke_> yes
2020-02-25 11:47:49 <_ikke_> I see it in the commit log
2020-02-25 11:48:12 <_ikke_> https://git.alpinelinux.org/aports/commit/?id=69468127
2020-02-25 11:48:53 <PureTryOut[m]> What is the support duration for main vs community actually?
2020-02-25 11:49:06 <maxice8> 1.5 years x 6 months iirc
2020-02-25 11:49:06 <_ikke_> main is 3 years
2020-02-25 11:49:08 <_ikke_> 2
2020-02-25 11:49:21 <PureTryOut[m]> So is it 1.5, 2 or 3 years? πŸ˜‚
2020-02-25 11:49:24 <_ikke_> community is only last stable release
2020-02-25 11:49:39 <_ikke_> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-02-25 11:49:52 <PureTryOut[m]> Ah ok
2020-02-25 11:49:52 <maxice8> @PureTryOut 2 years for main/ 6 months for community/
2020-02-25 11:49:54 <PureTryOut[m]> But the repo will still exist after those 6 months right?
2020-02-25 11:50:03 <_ikke_> v3.8 main is supported until may
2020-02-25 11:50:11 <_ikke_> PureTryOut[m]: yes
2020-02-25 11:50:20 <_ikke_> but no active security patching
2020-02-25 11:50:21 <PureTryOut[m]> Cool thanks
2020-02-25 11:50:52 <_ikke_> So the more packages in main, the more we have to support
2020-02-25 11:51:19 <_ikke_> It required commitment from Alpine
2020-02-25 11:51:31 <nmeum> maxice8: oops, intended. was on older aports branch
2020-02-25 11:51:44 <maxice8> https://gitlab.alpinelinux.org/Leo/aports/-/jobs/56037 again the clang thing
2020-02-25 11:51:50 <nmeum> *indeed
2020-02-25 11:52:32 <_ikke_> maxice8: yes, I'm not sure why clang is not pulled in (or why it's pulled in on the builder)
2020-02-25 12:10:19 <mps> moving a lot of packages here-there without plan leads to chaos, imo
2020-02-25 12:20:57 <mps> maxice8: re ncurses, here is link about big terminfo DB https://invisible-island.net/ncurses/ncurses.faq.html#big_terminfo
2020-02-25 12:23:01 <mps> current developer, Thomas Dickey, wrote on ML that he could develop a nicer script but he is not sure if any of packagers will use it
2020-02-25 12:24:37 <AinNero> mps: whats the context?
2020-02-25 12:24:40 <mps> and, to repeat, about year ago I proposed to split terminfo but idea was rejected by some developers, history probably could be find in IRC log
2020-02-25 12:25:37 <mps> AinNero: it is issue/bug report or MR, let me try to find it
2020-02-25 12:26:32 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/11250
2020-02-25 12:28:29 <mps> yes, this
2020-02-25 12:29:49 <mps> btw, I proposed something similar for vim about less than a year ago on alpine-devel ML but no one answered, so I forgot it
2020-02-25 12:32:34 <_ikke_> mps: cannot find it
2020-02-25 12:34:34 <mps> Date: Tue, 23 Apr 2019 18:55:19 +0200
2020-02-25 12:34:45 <mps> Subject: [alpine-devel] vim fix and/or change
2020-02-25 12:35:09 <mps> heh, algitbot
2020-02-25 12:35:25 <mps> algitbot: you are wrong :)
2020-02-25 14:04:12 <vkrishn> did I miss something, some commits have $pkgname var being reverted to non-variable, eg af3255c60801f09d9de8396c38be2b9db0a7a0a2
2020-02-25 14:04:35 <vkrishn> or its ok ?
2020-02-25 14:04:56 <_ikke_> pkname is purely the aports packagename, and not so much the upstream project name
2020-02-25 14:06:53 <vkrishn> ok
2020-02-25 14:10:35 <vkrishn> looks like leo, removed most $pkgname in source=, but not all commits
2020-02-25 14:41:51 <clandmeter> maxice8: can you move lab to community?
2020-02-25 14:42:28 <maxice8> Am laying in bed with a very mild case of the tummy hurts, is it urgent?
2020-02-25 14:42:56 <clandmeter> do you mind if i do it?
2020-02-25 14:45:14 <maxice8> No
2020-02-25 14:49:45 <clandmeter> maxice8: i you are not the maintainer anymore
2020-02-25 14:49:46 <clandmeter> noted.
2020-02-25 15:19:10 <maxice8> i aggressively dissociated from maintaining what i don't use
2020-02-25 15:30:25 <maxice8> @ikke re: luajit and clang on postgresql-pllua, does clang need to be explicitly added or just the CI that fails to bring it in ?
2020-02-25 15:32:01 <_ikke_> maxice8: abuild deps installs it on the builders, but in CI and locally for me, it was not installed
2020-02-25 15:50:06 <maxice8> I'm updating python3 to 3.8.2
2020-02-25 15:50:15 <maxice8> Anything i should know ?
2020-02-25 19:04:02 <_ikke_> hmm, live-media another case where they only keep the latest release?
2020-02-25 19:07:42 <_ikke_> http://live555.com/liveMedia/faq.html#old-versions
2020-02-25 19:07:44 <_ikke_> yup
2020-02-25 19:07:50 <_ikke_> "old versions are not available"
2020-02-25 19:13:50 <dalias> ...
2020-02-25 19:21:04 <nmeum> fcolista: do you still use oath-toolkit? is cvs really a required dependency? if at all it seems to be a make dependency
2020-02-25 20:15:57 <_ikke_> ugh, getting crazy here
2020-02-25 20:16:31 <_ikke_> trying to pass -DNO_LCHMOD to unzip, but whatever I try, I don't see it being used
2020-02-25 20:16:48 <_ikke_> Same idea as here: https://sources.debian.org/src/unzip/6.0-25/debian/rules/#L11
2020-02-25 20:17:13 <_ikke_> I tried passing it to CF on the make command line
2020-02-25 20:17:26 <maxice8> Updated python3 to 3.8.2, also separated pip from it !4562
2020-02-25 20:17:33 <_ikke_> if I execute make -np, I see that flag being used (but as only flag)
2020-02-25 20:17:49 <_ikke_> when I remove -np, it's no longer being used, and a whole set of different flags appear
2020-02-25 20:18:38 <_ikke_> output with -np: x86_64-alpine-linux-musl-gcc -c -Os -fomit-frame-pointer -DNO_LCHMOD unzip.c
2020-02-25 20:19:07 <_ikke_> output without: x86_64-alpine-linux-musl-gcc -c -I. -Ibzip2 -DUNIX -O3 -DLARGE_FILE_SUPPORT -DUNICODE_SUPPORT -DUNICODE_WCHAR -DUNICODE_SUPPORT -DUTF8_MAYBE_NATIVE -DHAVE_DIRENT_H -DHAVE_TERMIOS_H -D_MBCS  unzip.c
2020-02-25 20:19:40 <_ikke_> Seems like our CFLAGS are ignored there as well
2020-02-25 20:24:43 <_ikke_> Hmm
2020-02-25 20:24:49 <_ikke_> CF_NOOPT *does* work
2020-02-25 20:27:36 <_ikke_> Apparently they commented out the line that normally uses CF
2020-02-25 20:48:07 <_ikke_> One thing is sure, that Makefile is horrible
2020-02-25 20:48:34 <_ikke_> It calls a configure script, and then it calls itself again with the configure output
2020-02-25 21:01:46 <Cogitri> Oof
2020-02-25 21:11:47 <_ikke_> I'm kind of confused, there are rules for *.o files which includes $CF
2020-02-25 21:12:02 <_ikke_> ah right, but that gets overridden again
2020-02-25 21:27:19 <Ariadne> dalias: how bad is the fallout for time64 btw
2020-02-25 22:01:20 <maxice8> :D my fix for ncurses-libs <-> ncurses-terminfo relationship revealed a massive breakage
2020-02-25 22:01:39 <maxice8> lots of terminal packages that have their terminfo files in ncurses-terminfo didn't depend on it because they already depended on ncurses-libs
2020-02-25 22:01:52 <maxice8> #11254
2020-02-25 22:04:36 <minecrell> Well, having it in the terminal packages doesn't help if you use SSH :\
2020-02-25 22:05:11 <maxice8> SSH is a separate issue altogether that has other problems
2020-02-25 22:15:58 <Ariadne> maxice8: you fixed ncurses-libs/ncurses-terminfo ?
2020-02-25 22:16:14 <maxice8> yes
2020-02-25 22:16:38 <maxice8> There is a 3 paragraph explain on the commit that did it
2020-02-25 22:19:02 <mps> maxice8: does xterm need ncurses-terminfo in depends
2020-02-25 22:19:09 <Ariadne> i think we should move some common terminal types, like xterm-256color into ncurses-terminfo-base
2020-02-25 22:19:25 <Ariadne> depending on ncurses-terminfo does not fix SSH as minecrell observes
2020-02-25 22:19:31 <maxice8> @mps i believe yes, xterm-256color is in ncurses-terminfo
2020-02-25 22:19:36 <Ariadne> the problem is
2020-02-25 22:19:44 <Ariadne> ncurses-terminfo is mostly obscure stuff
2020-02-25 22:19:55 <Ariadne> if it is xterm-256color it should just be moved to base
2020-02-25 22:19:56 <Ariadne> :)
2020-02-25 22:20:16 <mps> apk info -L ncurses-terminfo-base | grep xterm
2020-02-25 22:20:42 <Ariadne> the idea of ncurses-terminfo-base was to provide the shit people actually use
2020-02-25 22:20:57 <Ariadne> and then if you have some terminal from 1989 in your closet you want to hook up
2020-02-25 22:21:00 <Ariadne> you can install the full set
2020-02-25 22:21:31 <mps> or vice versa
2020-02-25 22:22:13 <maxice8> @Ariadne without thinking about it too much i agree
2020-02-25 22:23:23 <dalias> ariadne, in what sense?
2020-02-25 22:24:11 <Ariadne> dalias: well, we are halfway through the unfrozen part of the 3.12 dev cycle
2020-02-25 22:24:23 <Ariadne> dalias: i am wondering if it makes sense to hold musl 1.2 for after 3.12
2020-02-25 22:25:24 <dalias> maybe. at least you want to be putting resources into getting everyone to make clean upgrade when you do it
2020-02-25 22:25:52 <dalias> so if that would be hard at this point it may make sense to wait
2020-02-25 22:26:37 <dalias> the amount of software that's broken and needs patching isn't all that big, unless you count stuff like broken format strings (still not all known/found) which could make wrong output but probably won't blow up
2020-02-25 22:28:16 <timlegge83> @maxice8 thanks for the info on moving ports to community from testing.  Basically move the directory to community git commit and do a pull request....
2020-02-25 22:28:27 <Ariadne> timlegge83: yes
2020-02-25 22:28:51 <Cogitri> git mv might be handy :)
2020-02-25 22:29:51 <timlegge83> Cogitri: Nice I have never used that.  Thanks Ariadne
2020-02-25 22:40:40 <timlegge83> And for moves, one commit per move I assume but would multiple renames in a PR be okay?
2020-02-25 22:43:39 <Ariadne> yes
2020-02-25 22:48:05 <maxice8> @Ariadne i have made changes to ncurses, i'm going to post a paste with a diff of contents so you can see if all is right
2020-02-25 22:48:28 <Ariadne> just open an MR please
2020-02-25 22:48:52 <maxice8> ok
2020-02-25 22:57:50 <maxice8> tagged you
2020-02-26 00:15:10 <timlegge21> are cpanmakedepends and cpandepends no longer accepted?  If not I can update apkbuild-cpan and send a MR
2020-02-26 00:17:26 <maxice8> Yes
2020-02-26 00:18:47 <timlegge21> maxice8 to clarify - yes they are no longer accepted and yes send a MR :-)
2020-02-26 00:22:45 <maxice8> Exactly
2020-02-26 00:47:11 <timlegge21> Also, with two license do you ad OR between them?
2020-02-26 00:59:26 <maxice8> It depends
2020-02-26 00:59:40 <maxice8> if the code can be distributed under FOO or under BAR then it is OR
2020-02-26 00:59:55 <maxice8> if the code is under FOO and BAR then it is AND
2020-02-26 01:00:07 <maxice8> it is something you have to see by reading README, LICENSE or whatever file describes that
2020-02-26 01:07:44 <timlegge21> The only ones I have the OR for are the ones that were "perl5" that is Equivalent to GPL-1.0-or-later OR Artistic-1.0-Perl as I understand it
2020-02-26 01:08:10 <maxice8> yes perl5 is Artistic-1.0-Perl which also is OR GPL-1.0-or-later
2020-02-26 01:08:15 <maxice8> if you're dealing with perl then that is the most common
2020-02-26 01:09:33 <timlegge21> thanks
2020-02-26 01:48:50 <bfritz> Hi all.
2020-02-26 01:48:55 <bfritz> The `ip=dhcp` boot option is broken in 3.11.3 (at least) for the rpi2 and rpi4 profiles.
2020-02-26 01:49:01 <bfritz> Fix is straightforward Makefile change: https://gitlab.alpinelinux.org/alpine/mkinitfs/merge_requests/64
2020-02-26 02:30:13 <timlegge21> MR 4581 Perl modules to community is complete if anyone has time to review.  Mostly moves but also removed the cpan references and fixed a few license things
2020-02-26 02:30:37 <maxice8> @timlegge21 you can use !4581 and algitbot will show the MR link and title
2020-02-26 02:32:33 <timlegge21> cool thanks
2020-02-26 06:17:30 <Cogitri> Ariadne: Can you take a look at !4182 ?
2020-02-26 06:18:07 <Ariadne> i think the virtual should be namespaced
2020-02-26 06:18:10 <Ariadne> something like
2020-02-26 06:18:17 <Ariadne> dbus:libsecret
2020-02-26 06:18:35 <Ariadne> perhaps
2020-02-26 06:18:43 <Ariadne> dbus:[name of dbus interface]
2020-02-26 06:19:37 <Cogitri> Is that something I can do in my APKBUILD?
2020-02-26 06:20:23 <Ariadne> see my note
2020-02-26 06:22:33 <Cogitri> Ah okay, just wasn't sure if APKs can just do that or if that needs support from abuild or smth
2020-02-26 06:22:44 <Cogitri> Thanks for taking a look :)
2020-02-26 06:22:52 <Ariadne> to do it automatically, abuild will need to be modified
2020-02-26 06:22:55 <Ariadne> but we can do that later
2020-02-26 06:23:26 <Cogitri> I don't think doing it automatically would work well (at least on the depends-on side, the provider side should be fairly easy)
2020-02-26 06:23:35 <Ariadne> yes, the provider side
2020-02-26 06:23:41 <Ariadne> obviously depends is tricky ;)
2020-02-26 06:24:00 <Ariadne> but i think it makes sense to specify dbus interface dependencies by their interface name
2020-02-26 06:24:06 <Ariadne> in this case, org.freedesktop.Secrets
2020-02-26 06:24:29 <Cogitri> Yup
2020-02-26 06:24:37 <Ariadne> because the spec is not 'libsecret', libsecret is just the GNOME implementation of the org.freedesktop.Secrets interface
2020-02-26 06:25:55 <Ariadne> i wonder why the rework of ncurses failed on armv7 CI
2020-02-26 06:26:07 <Ariadne> oh
2020-02-26 06:26:18 <Ariadne> because edge is in an uninstallable state there
2020-02-26 06:26:22 <Ariadne> okay cool
2020-02-26 06:26:42 <Cogitri> Yes, currently choking hard on qt5-qtwebengine apparently
2020-02-26 06:26:50 <Ariadne> annoying
2020-02-26 06:27:15 <Ariadne> let me do ncurses while you do their sed work :)
2020-02-26 06:34:40 <maxice8> Got MRs for Ncurses
2020-02-26 06:42:01 <Ariadne> yeah i applied the one in edge
2020-02-26 06:42:09 <maxice8> i saw
2020-02-26 07:16:17 <Cogitri> ERROR: unsatisfiable constraints:
2020-02-26 07:16:18 <Cogitri> Huh? Error reporter did not find the broken constraints.
2020-02-26 07:16:19 <Cogitri> Huh indeed
2020-02-26 07:16:44 <Cogitri> I think apk might not like the dbus:org.freedesktop.Secret thingie, Ariadne
2020-02-26 07:17:08 <Cogitri> Not that I can tell, but the only change between the last upgrade on this machine has been the rebuild for that
2020-02-26 07:19:51 <Cogitri> Or maybe apk just didn't like replacing the provider
2020-02-26 07:19:59 <Cogitri> Can someone with a clean system test !4182 please?
2020-02-26 07:30:44 <hrio[m]> Hmm the terminal got a bit weird with zsh after updating in v3.11 this morning. Anybody else that have issues?
2020-02-26 07:31:28 <hrio[m]> This is for remote SSH session with TERM screen-256color
2020-02-26 07:31:46 <maxice8> Is there an error message ?
2020-02-26 07:32:42 <Cogitri> Ah, downgrading (so removing the libsecret-provider) and ugprading again (so install dbus:org.freedesktop.Secret) did the trick.
2020-02-26 07:32:55 <hrio[m]> No but backspace does not work in tmux
2020-02-26 07:35:55 <hrio[m]> Changing term to xterm-256color and it works, but still in the same tmux session.
2020-02-26 07:39:01 <hrio[m]> The latest update to ncurses in v3.11 seems to not include screen-256color
2020-02-26 07:39:13 <maxice8> yes, missed that apparently
2020-02-26 07:41:45 <maxice8> your ncurses-terminfo package was probably uninstalled because of a fix made to ncurses
2020-02-26 07:43:06 <maxice8> i pushed a fix to 3.11 please update in a while
2020-02-26 07:45:41 <hrio[m]> Thanks
2020-02-26 08:00:28 <Ariadne> Cogitri: its the replacing the provider that is the problem
2020-02-26 08:00:45 <Ariadne> Cogitri: we can go ahead and proceed
2020-02-26 08:02:29 <hrio[m]> maxice8 I problem solved πŸ˜ƒ big thanks!
2020-02-26 08:14:09 <Cogitri> Ariadne: Yup, a virtual helped me migrate
2020-02-26 08:50:36 <Ariadne> heh :)
2020-02-26 08:54:34 <maxice8> Please write about it in the release notes
2020-02-26 21:37:48 <_ikke_> Cogitri: ping
2020-02-26 21:39:01 <Cogitri> pong
2020-02-26 21:39:16 <crashoverride> Cogitri: ping
2020-02-26 21:39:33 <Cogitri> gnop
2020-02-26 21:39:39 <_ikke_> I killed the librsvg jobs on 3.11 on CI for s390x, they were hanging
2020-02-26 21:39:39 <crashoverride> game set, match
2020-02-26 21:39:51 <Ariadne> _ikke_: https://distfiles.dereferenced.org/rpi-5.4.22.patch
2020-02-26 21:40:01 <Cogitri> Ah, thanks for the info, it's merged now anyway
2020-02-26 21:40:07 <Cogitri> Thanks for taking care of that
2020-02-26 21:40:39 <andypost[m]> Looks I missed to backport php7 security upgrade to 3.11
2020-02-26 21:40:58 <_ikke_> Cogitri: I'm getting warnings now from Zabbix about it :)
2020-02-26 21:41:22 <_ikke_> Ariadne: done
2020-02-26 21:41:26 <Ariadne> _ikke_: thanks
2020-02-26 21:41:46 <_ikke_> Ariadne: would be easier for me if you'd name them similar as the other patches
2020-02-26 21:41:56 <_ikke_> rpi-5.4.22-alpine.patch
2020-02-26 21:42:02 <Ariadne> _ikke_: okay will do in future
2020-02-26 21:47:23 <_ikke_> ugh, unzip build system is a mess
2020-02-26 21:47:55 <_ikke_> debian just provides all the flags themselves instead of relying on any preset
2020-02-26 21:49:35 <_ikke_> If you provide generic (which is what we currently do), it just ignores CFLAGS completely
2020-02-26 21:52:31 <Ariadne> uhh
2020-02-26 21:52:44 <Ariadne> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3344.patch gives me empty
2020-02-26 21:52:59 <Ariadne> did gitlab corrupt itself or something
2020-02-26 21:53:56 <_ikke_> yes, that appears to happen sometimes
2020-02-26 21:54:21 <Ariadne> hmm, the GCC PR says it is fixed in 9.3
2020-02-26 21:54:42 <Ariadne> which is not out yet :(
2020-02-26 21:55:09 <_ikke_> Ariadne: fetching the branch works, but somehow, the diff is botched
2020-02-26 21:55:55 <Ariadne> https://gitlab.alpinelinux.org/mps/aports/commit/0dbf0211397f30372f656fcfdb0716a60a59fc73.patch works
2020-02-26 21:56:20 <Ariadne> i reviewed this a while ago, but the CI issue was scary :P
2020-02-26 22:08:57 <_ikke_> Somebody got a better idea than this for unzip? http://tpaste.us/Z07d
2020-02-26 22:12:21 <Ariadne> _ikke_: that seems fine
2020-02-26 22:16:27 <_ikke_> it's kind of horid that I need to source flags file to get the flags of which at least one we override again
2020-02-26 22:16:37 <_ikke_> s/flags/a flags/
2020-02-26 22:16:37 <alpine-meetbot> _ikke_ meant to say: it's kind of horid that I need to source a flags file to get the flags of which at least one we override again
2020-02-26 22:16:39 <Ariadne> well ideally
2020-02-26 22:16:49 <Ariadne> somebody should just write a replacement unzip that uses libarchive
2020-02-26 22:16:51 <Ariadne> :)
2020-02-26 22:17:07 <Ariadne> wouldnt be that hard to do really
2020-02-26 22:17:10 <_ikke_> I tend to use p7zip (no idea if it's any better)
2020-02-26 22:17:31 <Ariadne> if p7zip is a dropin replacement we could just provide a symlink
2020-02-26 22:17:39 <_ikke_> it's not afaik
2020-02-26 22:17:42 <Ariadne> bummer
2020-02-26 22:18:33 <_ikke_> the cli is different
2020-02-26 22:20:20 <Ariadne> but yeah
2020-02-26 22:20:34 <Ariadne> something that just wraps something known good like libarchive but provides frontends that simulate all this crap
2020-02-26 22:20:39 <Ariadne> i think is the way to go ultimately
2020-02-26 22:20:46 <Ariadne> i'll add it to my list of things to do
2020-02-26 22:56:50 <mps> proftpd CVE-2020-9273
2020-02-26 22:57:13 <mps> I think that also 1.3.6 is affected
2020-02-27 02:20:42 <alexeymin> busybox was bumped to r12, but http://dl-cdn.alpinelinux.org/alpine//edge/main/armhf/busybox-static-1.31.1-r12.apk 404 not found?
2020-02-27 02:30:09 <maxice8> armhf builder is apparently stuck in python3, at least according to build.a.o
2020-02-27 02:41:00 <alexeymin> that's sad, now we can only wait (indefinitely?)
2020-02-27 05:35:58 <_ikke_> I'll check it
2020-02-27 05:36:04 <_ikke_> forgot to follow up on it yesterday
2020-02-27 05:56:53 <Jiggy> Anyone know what's going on with the code-server package in testing? Throws an error for me
2020-02-27 05:57:05 <_ikke_> Jiggy: what error?
2020-02-27 05:57:15 <Jiggy> RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range. It must be >= 0 and <= 16696294. Received 16702498
2020-02-27 05:58:36 <Jiggy> https://github.com/cdr/code-server/issues/825 - Known issue, looks like our package needs to be refreshed
2020-02-27 05:58:56 <_ikke_> heh
2020-02-27 05:58:59 <_ikke_> was about to link to that
2020-02-27 06:00:53 <Jiggy> flagged
2020-02-27 09:32:20 <PureTryOut[m]> maxice8: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4547 now passes on armv7, the previous pipeline failure seems to be a race issue
2020-02-27 09:32:40 <PureTryOut[m]> CI is still building aarch64, but nothing changed there so should be fine to merge
2020-02-27 09:32:57 <PureTryOut[m]> (this fixes the armv7 builder)
2020-02-27 09:33:48 <_ikke_> PureTryOut[m]: I just disabled the py3 package :x
2020-02-27 09:34:00 <PureTryOut[m]> Well, re-enable it! πŸ˜ƒ
2020-02-27 09:34:52 <_ikke_> After that MR is finished :D
2020-02-27 09:35:06 <PureTryOut[m]> Oh you literally just disabled that package lol
2020-02-27 09:35:18 <_ikke_> yes
2020-02-27 09:35:19 <PureTryOut[m]> _ikke_: it just got merged πŸ˜‰
2020-02-27 09:35:22 <_ikke_> heh
2020-02-27 09:35:55 <_ikke_> lies :)
2020-02-27 09:36:03 <_ikke_> maxice8: forgot to push it I guess
2020-02-27 09:36:07 <PureTryOut[m]> Hmm you're right, maxice8 has been lying
2020-02-27 09:36:13 <PureTryOut[m]> Guess so
2020-02-27 09:36:21 <_ikke_> there
2020-02-27 09:36:45 <PureTryOut[m]> There we go
2020-02-27 09:36:47 <PureTryOut[m]> Now re-enable py3 lol
2020-02-27 09:38:00 <_ikke_> done
2020-02-27 09:38:08 <PureTryOut[m]> πŸ‘οΈ
2020-02-27 09:50:25 <MY-R> since week or two I see those emojis so huge and cut in half that dont even know what mean... and not sure if my client/config broken it or just matrix users
2020-02-27 09:51:21 <MY-R> πŸ˜‘
2020-02-27 09:51:41 <MY-R> ye looks like something changed after alpine upgrade in edge
2020-02-27 09:52:48 <_ikke_> πŸ˜‰
2020-02-27 09:53:33 <mps> sending emojis to IRC (text mode chat) is impolite
2020-02-27 09:53:57 <_ikke_> officially emojies are just text (unicode / utf-8)
2020-02-27 09:54:31 <_ikke_> And the irc protocol supports it
2020-02-27 09:54:43 <PureTryOut[m]> How is sending a character impolite?
2020-02-27 09:54:49 <PureTryOut[m]> Like _ikke_ said, they're just unicode
2020-02-27 09:55:00 <mps> yes, I see them, but still think it is impolite
2020-02-27 09:55:24 <PureTryOut[m]> Why?
2020-02-27 09:55:53 <PureTryOut[m]> It's just a character and as long as you don't send a middle-finger or something, not meant as an insult to anyone
2020-02-27 09:56:04 <mps> some people don't have irc client with utf-8 support and some emoji fonts are ugly at least
2020-02-27 09:56:32 <PureTryOut[m]> I'm not sure why the sender of the emoji should think of that when sending them, that seems to be an issue of the receiver
2020-02-27 09:57:06 <_ikke_> I don't see them on my terminal, but I just accept that
2020-02-27 09:57:34 <_ikke_> THe basic ones I see as crude single-color emoticons
2020-02-27 09:57:38 <mps> this reasoning leads to conclusion that 'middle-finger' is issue of the receiver
2020-02-27 09:57:48 <_ikke_> No, that's something different
2020-02-27 09:58:10 <_ikke_> The middle-finger itself is a rude gesture
2020-02-27 09:58:31 <_ikke_> The other is a display issue for some specific user
2020-02-27 09:58:31 <PureTryOut[m]> No, emojis are an issue of the receiver.  The "middle-finger" itself is an issue of the sender
2020-02-27 09:58:47 <mps> Jon Postel robustness principle .......
2020-02-27 09:59:31 <_ikke_> So we should limit to ascii characters <128?
2020-02-27 10:00:03 <mps> _ikke_: that would nice
2020-02-27 10:00:13 <mps> would be*
2020-02-27 10:00:24 <PureTryOut[m]> You might not agree with using emojis, but the term "rude" is incorrect imo
2020-02-27 10:01:08 <mps> PureTryOut[m]: I didn't wrote 'rude' anywhere
2020-02-27 10:01:12 <PureTryOut[m]> At least I'm not using Matrix-only features here, of which I understand not liking it as IRC user. But emojis are supported perfectly fine by IRC so that's really an issue of the receiver not wanting to fully support the protocol they're using
2020-02-27 10:01:24 <PureTryOut[m]> Sorry, I meant "impolite"
2020-02-27 10:01:41 <_ikke_> let's move this to #-offtopic
2020-02-27 10:03:04 <MY-R> yeah, my bad I mentioned about them here, blame me!
2020-02-27 10:05:17 <MY-R> ok, I fixed my issue: ln -s /usr/share/fontconfig/conf.avail/10-scale-bitmap-fonts.conf /etc/fonts/conf.d/
2020-02-27 10:05:58 <MY-R> sorry for noise, removed that config week ago...
2020-02-27 11:41:14 <PureTryOut[m]> Is there a way to make `~/.abuild/abuild.conf` work with both rootbld and docker-abuild?
2020-02-27 11:46:00 <PureTryOut[m]> Also, when a unit test requires network access, should options contain "net" for the entire apkbuild or is there a way to do it just for the check function?
2020-02-27 11:47:48 <Cogitri> PureTryOut: By making docker-abuild have its own abuild.conf
2020-02-27 11:48:00 <Cogitri> clandmeter probably knows more about that though
2020-02-27 11:48:15 <Cogitri> I don't think there's a way to enable net just for the unittests
2020-02-27 12:06:57 <PureTryOut[m]> Hmm not sure how to do that. What was the default value for PACKAGER_PRIVKEY again that worked with docker-abuild? /home/<user> or /home/builder?
2020-02-27 12:32:08 <PureTryOut[m]> `failed to rename usr/.apk.1e9e7d60a69560032de82a2758336edbe3192120b1c1a779 to usr/bin`
2020-02-27 12:32:10 <PureTryOut[m]> What does that mean?
2020-02-27 12:35:31 <PureTryOut[m]> Ah, faulty APKBUILD, that's what it means
2020-02-27 12:56:25 <Cogitri> PureTryOut[m]: It's home/builder for dabuild
2020-02-27 12:56:41 <Cogitri> There should be upstream support for the seperate config thingie soon-ish I think
2020-02-27 12:59:45 <PureTryOut[m]> Thanks!
2020-02-27 13:05:19 <Cogitri> Glad to be of help
2020-02-27 13:10:54 <PureTryOut[m]> Cogitri: I'm trying to get KDE's partitionmanager to recognize my partition types. It seems that GNOME Disks does not recognize them either. Do you know how GNOME Disks detects partition types normally?
2020-02-27 13:11:24 <PureTryOut[m]> KDE partitionmanager calls udevadm via kpmcore but the result udevadm gives back is incomplete. Seems to be an eudev problem?
2020-02-27 13:12:45 <PureTryOut[m]> At least kpmcore expects https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-blkid.c#L40 but it never happens for whatever reason
2020-02-27 13:13:54 <Cogitri> Dunno to be honest, I can take a look after work
2020-02-27 13:17:01 <PureTryOut[m]> Thanks!
2020-02-27 13:23:23 <xrs> Hey Cogitri, I'm still waiting for a merge request being accepted. How long does this process take? Can I do something else in the mean time? :)
2020-02-27 13:24:19 <xrs> I'd like to add notes to the wiki on how to use GNUnet in Alpine Linux.
2020-02-27 13:24:28 <xrs> How do I do this?
2020-02-27 13:56:19 <Cogitri> Ah sorry that it takes so long, xrs, I forgot about it somehow
2020-02-27 13:56:24 <Cogitri> 
ACTION really, really dislikes the Gitlab notification system

2020-02-27 13:57:12 <Cogitri> You have to register an account and then you should be able to add a new page where you describe the process of setting up GNUNet, it should be the same as with other MediaWiki instances
2020-02-27 13:57:36 <Cogitri> I think we have a timeout of 5 hours after registration for links and phone numbers to avoid spam
2020-02-27 13:59:10 <xrs> Cogitri: No problem. :-) Greate, I'll do the registration then. Thanks!
2020-02-27 14:01:00 <Cogitri> Thanks for documenting it :)
2020-02-27 14:01:22 <Cogitri> Feel free to ping me again if I didn't get to your MR by the weekend
2020-02-27 14:03:45 <minecrell> Cogitri: you mean the in-existent notification system?
2020-02-27 14:03:48 <minecrell> except email I guess
2020-02-27 14:05:53 <xrs> Cool, thanks for helping out!
2020-02-27 14:06:42 <xrs> I'm new to the community and learning slowly how communication works ;)
2020-02-27 14:08:42 <Ariadne> minecrell: no, there is a to-do list system in the upper right
2020-02-27 14:09:03 <minecrell> Ariadne: Well, yeah, but you need to add things manually or get pinged explicitly...
2020-02-27 14:09:38 <Cogitri> The ToDo thingie works really badly though
2020-02-27 14:10:06 <Cogitri> I really like Gitlab other than the notification stuff, but IMHO Gitlab really is miles behind GitHub on that one
2020-02-27 14:10:52 <PureTryOut[m]> > we should all just use SourceHut
2020-02-27 14:11:04 <PureTryOut[m]> Now I mention it, does Alpine's SourceHut instance have CI yet for aports?
2020-02-27 14:14:08 <_ikke_> no
2020-02-27 14:14:47 <Cogitri> Someone should just get Gitlab's notification system into shape and I'd be all happy
2020-02-27 14:15:06 <Cogitri> Seeing how little interest there is in the ML generally I don't think we'd have a good time with SH to be honest
2020-02-27 14:15:24 <Ariadne> considering there is more preference to replace the mailing lists with anything else
2020-02-27 14:15:39 <Ariadne> i would suspect that we will likely wind up doing so
2020-02-27 14:16:48 <Cogitri> Sorry?
2020-02-27 14:17:52 <Ariadne> almost everyone i have talked to about this mailing list stuff
2020-02-27 14:18:11 <Ariadne> would like to see some sort of combination of gitlab issues and [something else] for chitchat
2020-02-27 14:18:22 <artok> mailing list is good for announcements
2020-02-27 14:18:30 <Ariadne> yes, but so is discourse
2020-02-27 14:18:46 <Ariadne> and discourse can be set up  to work with mail
2020-02-27 14:19:10 <artok> but never get into webchat thing, then it's annoying
2020-02-27 14:19:24 <Ariadne> discourse is not a webchat thing
2020-02-27 14:19:44 <artok> yah, that I know
2020-02-27 14:19:58 <Cogitri> Ah yes, not having the ML would be nice to be honest
2020-02-27 14:19:59 <artok> there has been one project that I was involved in that moved from irc->rocket.chat
2020-02-27 14:20:09 <Cogitri> And loads of projects have switched to Discourse
2020-02-27 14:20:39 <Ariadne> Cogitri: yes, but i have limited fucks to give and right now my fucks are being spent on more important issues
2020-02-27 14:20:51 <Ariadne> so we will revisit after 3.12
2020-02-27 14:26:59 <_ikke_> It surprises me how many different people still use the mailing list
2020-02-27 14:27:14 <_ikke_> for patches
2020-02-27 14:29:52 <Ariadne> yeah but then they get mad that nobody reviews
2020-02-27 14:30:14 <Ariadne> so i think its best to just funnel it all through gitlab
2020-02-27 14:30:23 <Ariadne> but i have more important things to worry about right now
2020-02-27 14:30:27 <Ariadne> like burning Alpine into ROM
2020-02-27 14:30:37 <PureTryOut[m]> I mean, if you give them the possibility to send stuff by email, then yeah it's not weird that they think people will review it
2020-02-27 14:30:53 <PureTryOut[m]> If you don't want email based patches, don't give them the possibility too
2020-02-27 14:31:14 <Ariadne> well the problem is
2020-02-27 14:31:20 <Ariadne> the email based patches are a pain in the ass
2020-02-27 14:31:29 <Ariadne> MRs, we can have CI do testing etc
2020-02-27 14:31:36 <Ariadne> which isnt foolproof
2020-02-27 14:31:42 <Ariadne> but its better than e-mail patches
2020-02-27 14:31:51 <PureTryOut[m]> For email you can have CI as well, Drew DeVault was working on it
2020-02-27 14:31:57 <Ariadne> cool
2020-02-27 14:32:00 <Ariadne> don't care
2020-02-27 14:32:13 <PureTryOut[m]> SourceHut itself has it definitely
2020-02-27 14:32:23 <Ariadne> yes, i am aware of that
2020-02-27 14:32:28 <Ariadne> but all the CI infra is in gitlab
2020-02-27 14:32:32 <PureTryOut[m]> I'm just saying, if you don't want email patches, remove that possibility
2020-02-27 14:32:45 <Ariadne> not my decision to unilaterally make
2020-02-27 14:33:03 <_ikke_> Leo and I have mostly been keeping up with patches from the mailing list
2020-02-27 14:33:18 <Ariadne> yes, but then half of them just get converted into gitlab MRs
2020-02-27 14:33:23 <Ariadne> so the CI can check them
2020-02-27 14:36:09 <Ariadne> anyway, the more important list that needs a better resolution is alpine-devel
2020-02-27 14:36:33 <Ariadne> if mail lists stay around for patches, cool i guess
2020-02-27 14:43:22 <Cogitri> IMHO we should kill the ML, at least for patches, it's really a pain and we aren't good at keeping up with the patches from the ML
2020-02-27 14:44:05 <Cogitri> For decision making it's fine as far as I can see (but apparently most don't agree with that, since replies usually only come from a few certain people)
2020-02-27 14:45:21 <Ariadne> we wind up in situations where people agree with decisions but don't voice their agreement because its annoying
2020-02-27 14:45:34 <Cogitri> Yes
2020-02-27 15:58:00 <minecrell> nmeum: What's the state of https://github.com/nmeum/android-tools/tree/platform-tools-29.0.5? I'm guessing it's not finished yet?
2020-02-27 19:37:23 <reidrankin> clandmeter, Cogitri, Ariadne: found a problem introduced by !4056 -- wish I'd found it yesterday, sorry -- fixed in !4699
2020-02-27 19:39:32 <reidrankin> didn't come up in my install since apparently `apk add wireguard-rpi2` (for example) on a run-from-RAM install causes the kernel and all the modules to be re-installed, overwriting the stuff in modloop -- and running depmod, which hides this issue
2020-02-27 19:40:56 <reidrankin> I still think !4056 was an improvement over the previous behavior, it's just not very useful without running `depmod -A`
2020-02-27 19:56:26 <oneinsect> folks good day
2020-02-27 19:56:46 <oneinsect> is there a specific order for scratch compiling the following packages
2020-02-27 19:56:47 <oneinsect> https://github.com/alpinelinux/aports
2020-02-27 19:57:04 <oneinsect> like musl first and then busybox etc?
2020-02-27 20:01:53 <_ikke_> oneinsect: yes, there certainly is
2020-02-27 20:02:15 <_ikke_> a tool like ap (from lua-aports) can be used to find the proper build order of packages
2020-02-27 20:03:07 <mps> I think we need this for ppp, though it is added after stable release https://git.ozlabs.org/?p=ppp.git;a=commitdiff;h=8d45443bb5c9372b4c6a362ba2f443d41c5636af
2020-02-27 20:03:58 <mps> any objection to add this and maybe even this https://git.ozlabs.org/?p=ppp.git;a=commit;h=858976b1fc3107f1261aae337831959b511b83c2
2020-02-27 20:03:58 <oneinsect> hmmmm
2020-02-27 20:04:14 <mps> radius: Prevent buffer overflow in rc_mksid()
2020-02-27 20:05:14 <mps> _ikke_: ^ I respect your opinions
2020-02-27 20:05:27 <_ikke_> oneinsect: list of first 50 packages: http://tpaste.us/lYDn
2020-02-27 20:05:35 <mps> and sorry if I annoy you too much
2020-02-27 20:05:42 <_ikke_> mps: My opinion is quite generic :)
2020-02-27 20:06:13 <mps> heh
2020-02-27 20:06:21 <oneinsect> @_
2020-02-27 20:06:46 <oneinsect> _ikke_ is that the order of package compilation by abuild
2020-02-27 20:06:48 <_ikke_> oneinsect: You first have to compile a bunch of dependencies before you get to compile the things you consider the first packages
2020-02-27 20:07:04 <oneinsect> like?
2020-02-27 20:07:08 <_ikke_> see that lsit
2020-02-27 20:07:12 <_ikke_> list
2020-02-27 20:07:15 <_ikke_> it is in build order
2020-02-27 20:07:49 <oneinsect> why dont i see openrc, busybox etc
2020-02-27 20:07:56 <oneinsect> are they built at a later stage?
2020-02-27 20:07:58 <_ikke_> They are probably later
2020-02-27 20:08:02 <oneinsect> hmmmm
2020-02-27 20:08:32 <oneinsect> and this is how abuild builds them right?
2020-02-27 20:08:35 <oneinsect> the order i meant
2020-02-27 20:08:51 <_ikke_> busybox is surprisingly late
2020-02-27 20:08:55 <_ikke_> 657
2020-02-27 20:09:05 <_ikke_> openrc 643
2020-02-27 20:09:18 <_ikke_> oneinsect: as far as I know, it is
2020-02-27 20:09:36 <_ikke_> this is generated with ap builddirs * in the main directory from aports
2020-02-27 20:09:38 <oneinsect> kinda strange as those the first things we need for booting....i mean Alpine-base needs only those...
2020-02-27 20:09:55 <_ikke_> Yes, but boot order is not really important
2020-02-27 20:10:15 <_ikke_> dependencies to be able to build are more important
2020-02-27 20:10:36 <oneinsect> when you say "this is generated with ap builddirs * in the main directory from aports".....
2020-02-27 20:10:41 <oneinsect> what do you mean
2020-02-27 20:11:26 <_ikke_> in aports/main, I run: `apk builddirs *`
2020-02-27 20:11:30 <_ikke_> in aports/main, I run: `ap builddirs *`
2020-02-27 20:12:10 <mps> oneinsect: to build userspace programs, first need to be build compilers, libraries etc
2020-02-27 20:12:30 <_ikke_> bzip2 is first, it has no dependencies at all
2020-02-27 20:12:45 <_ikke_> same with zlib
2020-02-27 20:13:08 <_ikke_> perl only depends on those 2 packages
2020-02-27 20:13:14 <oneinsect> ummm understood
2020-02-27 20:13:16 <oneinsect> thanks
2020-02-27 20:14:29 <oneinsect> i am just trying to get back to your help on trying to do a glibc version of alpine...that we discussed on https://dev.alpinelinux.org/irclogs/%23alpine-devel-2019-07.log
2020-02-27 20:16:46 <_ikke_> mps: regarding ppp, I think it makes sense to backport fixes
2020-02-27 20:17:05 <mps> ok, thanks
2020-02-27 20:18:30 <oneinsect> quick question why doesnt abuild have dependency on automake etc https://pkgs.alpinelinux.org/package/edge/main/x86/abuild
2020-02-27 20:18:45 <oneinsect> its uses some form of make right?
2020-02-27 20:19:06 <_ikke_> abuild *itself* does not depend on it
2020-02-27 20:19:16 <oneinsect> oooh!
2020-02-27 20:19:18 <mps> not all pkgs need autotools
2020-02-27 20:19:35 <_ikke_> there is alpine-sdk, which depends on build-base
2020-02-27 20:19:51 <oneinsect> you are right...may be i will require them during compilation....
2020-02-27 20:20:05 <_ikke_> oneinsect: then you add it as a makedepends to the package
2020-02-27 20:22:42 <oneinsect> yes understood.... _ikke_ can you guide me with some steps on building a complete glibc iso build of alpine for all packages (i will edit the pkgbuild files individually) ...any steps with syntax?
2020-02-27 20:23:50 <_ikke_> not really, I would have to research that myself
2020-02-27 20:23:57 <oneinsect> hmmmm
2020-02-27 20:24:12 <_ikke_> if you want to endeavor something like that, I would first try to get some experience with building packages in general and compiling projects
2020-02-27 20:26:20 <oneinsect> i did port alpine to couple of boards like orange-pi etc, i am familiar but i am kind of struck wit this, my mind is bank, just dont know where to start, like i will install alpine into chroot, add alpine-base, abuild and others tools including
2020-02-27 20:26:41 <oneinsect> the alpine-sdk and then compile all the packages, i dont even know if that is the right direction
2020-02-27 20:27:24 <oneinsect> (ofcourse replacing musl with glibc) and whats the command to build all packages once i clone the aports folder?
2020-02-27 20:28:34 <_ikke_> I don't think you need a chroot
2020-02-27 20:28:55 <_ikke_> at least, not right away
2020-02-27 20:29:08 <oneinsect> i mean i have debian here.
2020-02-27 20:29:35 <_ikke_> Right, it would help to have some kind of alpine system running
2020-02-27 20:30:00 <PureTryOut[m]> Somebody upgraded glslang today without rebuilding mpv
2020-02-27 20:30:03 <oneinsect> downloading the lastest alpine as we speak
2020-02-27 20:30:04 <PureTryOut[m]> Now it's broken 😒
2020-02-27 20:30:37 <_ikke_> maxice8: did 3 hours ago
2020-02-27 20:30:44 <mps> mpv is broken?
2020-02-27 20:31:56 <PureTryOut[m]> Yup, for me anyway, and I just upgraded my system
2020-02-27 20:32:47 <_ikke_> it was not even a pkgrel bump
2020-02-27 20:33:09 <PureTryOut[m]> No https://git.alpinelinux.org/aports/commit/main/glslang?id=2af25057f488b2210845463dd80b9d31388430a4 is the issue
2020-02-27 20:33:10 <_ikke_> ok, that was done earlier
2020-02-27 20:33:14 <_ikke_> ye
2020-02-27 20:33:36 <PureTryOut[m]> The current pkgver is now incorrect as well, should be 8.13.3559_git<date>
2020-02-27 20:33:37 <_ikke_> PureTryOut[m]: why would mpv need to be rebuilt for that?
2020-02-27 20:34:11 <PureTryOut[m]> Because currently running mpv causes `Error relocating /usr/lib/libglslang.so: _ZN7glslang23DefaultTBuiltInResourceE: symbol not found`
2020-02-27 20:34:47 <PureTryOut[m]> Oh and rebuilding mpv fails because of glslang now `undefined reference to `glslang::DefaultTBuiltInResource'`
2020-02-27 20:35:01 <_ikke_> then that should not have been a pkgrel bump
2020-02-27 20:35:06 <Cogitri> Does upstream have a patch for that already?
2020-02-27 20:35:15 <_ikke_> I mean, it should have been a version bump
2020-02-27 20:35:22 <Cogitri> Yup
2020-02-27 20:35:23 <PureTryOut[m]> Yup
2020-02-27 20:38:02 <oneinsect> quick question when I install some packages (say in the memory version of rpi) and do a lbu - commit, during the next reboot, I see the new packages being installed on the fly each time
2020-02-27 20:38:08 <oneinsect> is this how alpine works?
2020-02-27 20:38:23 <_ikke_> In run-from-ram mode it is
2020-02-27 20:38:39 <_ikke_> PureTryOut[m]: I don't see mpv depending on glslang
2020-02-27 20:39:19 <_ikke_> (ap revdep does not list it as a revdep for glslang / glslang-dev
2020-02-27 20:39:21 <_ikke_> )
2020-02-27 20:39:49 <oneinsect> great and this is achieved by the init script isnt it?
2020-02-27 20:40:19 <_ikke_> I think so, I don't know all the details of that part
2020-02-27 20:40:31 <oneinsect> thank you!
2020-02-27 20:41:29 <_ikke_> PureTryOut[m]: apparently is through mesa
2020-02-27 20:42:06 <PureTryOut[m]> Yeah
2020-02-27 20:42:44 <_ikke_> I guess mesa (with all its revdeps) would need to be rebuilt then I guess?
2020-02-27 20:43:57 <PureTryOut[m]> Probably yeah
2020-02-27 20:45:04 <_ikke_> fun
2020-02-27 20:46:05 <_ikke_> http://tpaste.us/MbNX
2020-02-27 20:46:26 <_ikke_> revdeps for mesa-dev
2020-02-27 20:46:27 <mps> I hope mesa 20.1 will be released in a few days
2020-02-27 20:46:56 <_ikke_> mps: do you expect that to happen?
2020-02-27 20:47:53 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/11262
2020-02-27 20:48:52 <mps> what, issue or mesa release?
2020-02-27 20:49:01 <_ikke_> mesa release
2020-02-27 20:49:10 <PureTryOut[m]> Well, the builders will be stuck for a while now...
2020-02-27 20:49:11 <mps> yes, I hope
2020-02-27 20:49:30 <mps> on Monday I think
2020-02-27 20:50:08 <mps> there are accumulated patches and some notes that the 20.1 is near
2020-02-27 20:50:13 <PureTryOut[m]> Not sure who merged my mpv rebuild MR but that should probably be reverted lol
2020-02-27 20:50:27 <_ikke_> prspkkt
2020-02-27 20:50:56 <_ikke_> PureTryOut[m]: it would not help to revert a pkgrel bump
2020-02-27 20:51:52 <PureTryOut[m]> Well Mesa better get a rebuild quick then, cause all builders are stuck now
2020-02-27 20:52:03 <PureTryOut[m]> Not sure why it was merged without CI being green
2020-02-27 20:53:02 <_ikke_> good question :)
2020-02-27 20:53:32 <_ikke_> and after mesa is rebuilt, all those others need to be rebuilt as well, right?
2020-02-27 20:53:42 <PureTryOut[m]> Guess so
2020-02-27 20:53:53 <Cogitri> I don't see why that'd be the case
2020-02-27 20:53:58 <PureTryOut[m]> At least mpv, that's for sure
2020-02-27 20:54:05 <Cogitri> If they link shared and don't need glslang
2020-02-27 20:54:20 <_ikke_> Cogitri: right
2020-02-27 20:54:30 <_ikke_> but how is mpv affected then
2020-02-27 20:57:21 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4702
2020-02-27 20:59:22 <Cogitri> Maybe glslang-dev is being pulled in my mesa-_3: and it enables it automatically
2020-02-27 20:59:35 <Cogitri> s/_3:/dev/
2020-02-27 20:59:36 <alpine-meetbot> Cogitri meant to say: Maybe glslang-dev is being pulled in my mesa-dev and it enables it automatically
2020-02-27 21:02:45 <oneinsect> a quick question when i manually unzip an apk package (say build-base) and install it, where should i add it to let alpine linux know that the package is installed?
2020-02-27 21:03:05 <oneinsect> is it like add "build-base" to /etc/apk/world file?
2020-02-27 21:03:34 <_ikke_> no, there is another db which has info about installed packages
2020-02-27 21:03:34 <oneinsect> during manual unzipping the alpine linux says ERROR: unsatisfiable constrains: build-base (missing):
2020-02-27 21:03:42 <oneinsect> oooh which one is it?
2020-02-27 21:04:10 <_ikke_> /lib/apk/db/*
2020-02-27 21:04:21 <oneinsect> aha thanks
2020-02-27 21:04:22 <_ikke_> /lib/apk/db/installed
2020-02-27 21:04:26 <_ikke_> but it contains all kinds of metadata
2020-02-27 21:04:44 <oneinsect> ummmmm so manually adding entries are impossible you say???
2020-02-27 21:04:57 <_ikke_> not impossible, you need to know what to add there
2020-02-27 21:05:13 <oneinsect> ummm
2020-02-27 21:07:08 <_ikke_> ugh, ci runners are getting timeouts from the docker hub
2020-02-27 21:07:58 <_ikke_> apparently the revert did help (prspkt reverted it)
2020-02-27 22:00:10 <maxice8> glslang is fun
2020-02-27 22:01:00 <maxice8> THere is no need to rebuild, i updated glslang to a newer version that has support for Vulkan 1.2 so we can update shaderc to 2019.1 which uses vulkan 1.2 because of our spirv-tools.
2020-02-27 22:01:32 <maxice8> In the meantime glslang::DefaultTBuiltInResource stopped being linked because it is an external interface part of StandAlone that applications should provide
2020-02-27 22:01:34 <maxice8> but people started depending on it so i linked it back in
2020-02-27 22:07:46 <maxice8> @PureTryOut ^
2020-02-27 22:13:31 <AinNero> uhm, the behavior of the kernel modules on edge changed
2020-02-27 22:13:44 <AinNero> kernel modules are not removed if their matching kernel is currently running?
2020-02-27 22:15:01 <AinNero> ah no... kmod generates file there, which are not removed when the kernel modules are uninstalled by apk
2020-02-27 22:21:55 <AinNero> so the modules itself (as tracked by apk) get removed, but the kmod remnant dont
2020-02-27 22:22:24 <AinNero> not sure if this is a bug. im off to bed, gn8
2020-02-27 23:36:45 <Jiggy> Does anyone know what wener's irc handle is?
2020-02-28 00:01:31 <timlegge> I am working on a perl mod aport that has a library dependency that automatically installs if it not available (the make downloads the source and compiles against it).. Is that okay or should the dependency be pulled out toa seperate package?
2020-02-28 01:58:29 <Jiggy> Does anyone know how to get in contact with wener?
2020-02-28 02:44:07 <Jiggy> wenerme[m]: Hey! They've updated code-server significantly; I think your package needs to be updated. Building is no longer necessary, as they now provide a musl-based package specifically for Alpine. For example - https://github.com/cdr/code-server/releases/download/2.1698/code-server2.1698-vsc1.41.1-alpine-x86_64.tar.gz
2020-02-28 02:44:34 <Jiggy> In the meantime, I've been using the binary from that archive, and it works great
2020-02-28 02:46:32 <wenerme[m]> πŸ‘Œ
2020-02-28 03:32:49 <wenerme[m]> Shiz: dose alpine package accept prebuild binary ?
2020-02-28 03:59:30 <dalias> i don't think prebuilt binaries should be accepted in packages
2020-02-28 04:01:43 <dalias> there's no evidence they actually correspond to the sources provided, or that they were built with a compatible library ecosystem
2020-02-28 04:01:55 <dalias> and i doubt they ship binaries for all the same archs
2020-02-28 04:25:41 <Ariadne> no we do not accept prebuilt binaries
2020-02-28 04:26:33 <Ariadne> wenerme[m]: to be accepted into Alpine, software must be licensed under a free license with the ability to build from source
2020-02-28 04:27:01 <Ariadne> wenerme[m]: we do not accept prebuilt binaries
2020-02-28 04:37:51 <dalias> good to hear :)
2020-02-28 05:37:40 <Jiggy> That's very reasonable! I suppose the binary for code-server should not be used then wenerme[m]. Fortunately, their toolchain/make for 2.x provides everything we need to compile from source for musl/alpine
2020-02-28 05:43:05 <Cogitri> I looked into building it yesterday and it didn't look fun but I don't know Node stuff well, I suppose
2020-02-28 05:43:21 <Cogitri> An up-to-date version of it would be great though
2020-02-28 05:51:55 <Jiggy> Cogitri: in the meantime, I've been using the compiled binary from their releases page; works greaet
2020-02-28 06:01:37 <Cogitri> I'll probably give that a shot too, right now I'm using the VSCode Flatpak with a custom Sdk extension which contains the dependecies I need for development
2020-02-28 06:01:52 <Cogitri> Which isn't the prettiest thing ever if I already packaged that in Alpine
2020-02-28 08:15:00 <mps> maxice8: have you seen  wenerme[m]| πŸ‘Œ
2020-02-28 08:15:00 <mps> 04:32 ...... wenerme[m]| Shiz: dose alpine package accept prebuild binary ?
2020-02-28 08:15:03 <mps> 04:59 .......... dalias| i don't think prebuilt binaries should be accepted in packages
2020-02-28 08:15:08 <mps> crap
2020-02-28 08:15:29 <mps> maxice8: have you seen  wenerme[m]| πŸ‘Œ
2020-02-28 08:15:29 <mps> 04:32 ...... wenerme[m]| Shiz: dose alpine package accept prebuild binary ?
2020-02-28 08:15:32 <mps> 04:59 .......... dalias| i don't think prebuilt binaries should be accepted in packages
2020-02-28 08:15:45 <mps> what's happening
2020-02-28 08:15:48 <mps> :(
2020-02-28 08:15:57 <mps> sorry to all
2020-02-28 08:16:12 <maxice8> @mps no
2020-02-28 08:16:28 <mps> maxice8: !4066
2020-02-28 08:17:04 <mps> sorry, aggain, libinput again made mess on aarch64
2020-02-28 08:17:09 <maxice8> I know but i don't like having a pkgrel based versioning system
2020-02-28 08:17:33 <mps> that was what n_copa wanted
2020-02-28 08:18:02 <mps> because that I put S-Hold on MR
2020-02-28 08:18:21 <maxice8> he wanted a pkgrel based versioning system or he didn't like having it ?
2020-02-28 08:19:07 <mps> he wanted to get rid of the current versioning
2020-02-28 08:19:32 <maxice8> and he was ok with bumping pkgrel to get a new version based on the date of the archive ?
2020-02-28 08:19:39 <mps> i.e. 6.1_pYYYYMMDD
2020-02-28 08:20:01 <mps> no, he wanted opposite of current
2020-02-28 08:20:45 <mps> i.e. to have 6.2 release and something in pkgrel
2020-02-28 08:21:15 <maxice8> so what i said
2020-02-28 08:21:18 <maxice8> he wanted to get rid of pkgver=6.1_p and use pkgver=6.2 and have _date=YYYYMMDD and bump pkgrel by 1
2020-02-28 08:21:33 <mps> yes, something like that
2020-02-28 08:21:58 <mps> I'm not sure I can find in IRC history our discussion about this
2020-02-28 08:22:24 <mps> because that I put MR on hold till he come back
2020-02-28 08:24:19 <maxice8> If he gave you the thumbs up on that why the wait ? push it
2020-02-28 08:25:44 <mps> really, didn't noticed it
2020-02-28 08:26:54 <mps> hmm, I don't see any 'thumbs' in MR
2020-02-28 08:27:26 <maxice8> thumps up is a metaphor for approval
2020-02-28 08:27:40 <mps> ah
2020-02-28 08:28:02 <mps> sorry, misunderstood
2020-02-28 08:29:26 <mps> I don't like to push anything which I'm not sure is what maintainer want without explicit approval
2020-02-28 08:32:14 <mps> for now, is it possible to revert somehow ncurses 6.2_pXXXXXX push to aports
2020-02-28 09:08:55 <nmeum> minecrell: yep, didn't get around to finishing it yet, too busy with other stuff atm
2020-02-28 09:09:40 <nmeum> unfourtunatly, updating android-tools is a very time consuming and error-prone process
2020-02-28 09:14:18 <minecrell> nmeum: Do you mind if I try? I think with a recent Alpine change there are now assertions enabled, and fastboot is pretty much entirely broken at the moment
2020-02-28 09:14:23 <minecrell> I think it was fixed in 29.0.5
2020-02-28 09:17:05 <nmeum> sure, go ahead
2020-02-28 11:52:12 <Ariadne> maxice8: as i have no confirmation from ncopa himself and the package isn't critical and the change isn't critical, i see no reason to proceed with a non-maintainer push
2020-02-28 11:53:30 <Ariadne> kernel 5.4.23 is going to come out today most likely.  will do the update tomorrow.
2020-02-28 11:54:09 <mps> tomorrow I think
2020-02-28 11:55:04 <mps> or, today if we take west of greenwich :)
2020-02-28 14:16:09 <PureTryOut[m]> How does the `ap revdep` command work? Is it supposed to be ran inside an aports tree?
2020-02-28 14:16:29 <PureTryOut[m]> If I run it next to an APKBUILD in an aport tree, it doesn't complain but it doesn't print out anything either
2020-02-28 14:18:44 <Cogitri> 
ACTION is wondering that too

2020-02-28 14:20:13 <_ikke_> It needs to be run in a repo dir
2020-02-28 14:20:19 <_ikke_> so in aports/main for example
2020-02-28 14:30:36 <mps> cd community then ap revdep ell
2020-02-28 14:30:44 <mps> for example
2020-02-28 14:31:08 <mps> ell is in main
2020-02-28 14:33:13 <mps> for a little more: ~/aports/community > ap revdep glib-dev
2020-02-28 14:35:43 <_ikke_> You need to repeat the command for every repo that you want to check
2020-02-28 14:52:41 <oneinsect> the command ap builddirs * doesnt execute in the aports/main folder
2020-02-28 14:52:58 <oneinsect> however apk buildirs * does
2020-02-28 14:53:10 <oneinsect> _ikke_
2020-02-28 14:54:36 <oneinsect> just trying to get the order of builds to be executed
2020-02-28 14:54:42 <oneinsect> packages*
2020-02-28 14:55:01 <_ikke_> oneinsect: did you install lua-aports?
2020-02-28 14:56:35 <oneinsect> oooh
2020-02-28 14:56:40 <oneinsect> i did not ....let me
2020-02-28 14:57:11 <oneinsect> its lua-aports right?
2020-02-28 14:57:17 <oneinsect> done installed let me try now
2020-02-28 14:57:48 <oneinsect> got it .....works now
2020-02-28 15:23:08 <oneinsect> in here for example zlib https://github.com/alpinelinux/aports/blob/master/main/zlib/APKBUILD  doesnt actually have musl dependency for compiling however as per here https://pkgs.alpinelinux.org/package/edge/main/aarch64/zlib it does depend on musl for running
2020-02-28 15:23:19 <oneinsect> is that a correct assessment?
2020-02-28 15:26:40 <fabled> yes, on all APKBUILDs, there's implicit build time dependency on build-base which includes gcc, musl and few other basic things
2020-02-28 15:27:12 <oneinsect> oooh
2020-02-28 15:27:20 <oneinsect> i did not know this
2020-02-28 15:27:47 <fabled> the runtime dependency is generated automatically based on ELF NEEDED tags
2020-02-28 15:28:31 <minecrell> Is there some easy way to make 'abuild -r' take the updated dependencies I have shortly built before? Looking at the abuild code I thought it does this by default (see https://gitlab.alpinelinux.org/alpine/abuild/blob/master/abuild.in#L2142-2152) but it's still installing the older dependencies from the repo for me for some reason :(
2020-02-28 15:28:36 <oneinsect> this makes it although more difficult to have it compile against glibc ....phew!
2020-02-28 15:30:12 <minecrell> oh, wait, there is a confusing warning, hm
2020-02-28 15:32:08 <mps> minecrell: you have your local packages dir in /etc/apk/repositories ?
2020-02-28 15:32:20 <minecrell> no, I guess I need to do that?
2020-02-28 15:32:28 <mps> yright
2020-02-28 15:32:34 <maxice8> Yes
2020-02-28 15:32:38 <mps> right*
2020-02-28 15:33:07 <mps> example: /home/mps/packages/main
2020-02-28 15:39:54 <minecrell> hmm, I think it detects stuff incorrectly because I don't build directly in aports. So there is a random directory above it and it puts the packages into $REPODEST/<random directory>/x86_64
2020-02-28 15:40:29 <maxice8> Random directory?
2020-02-28 15:43:02 <minecrell> like there is dirA/somepkg/APKBUILD and dirB/otherpkg/APKBUILD. "somepkg" is installed to $REPODEST/dirA/x86_64/... for "otherpkg" it uses $REPODEST/dirB/x86_64
2020-02-28 15:43:41 <maxice8> That is indeed very weird
2020-02-28 15:43:55 <_ikke_> It uses the parent directory as name
2020-02-28 15:44:12 <_ikke_> of you have foo/packagea/APKBUILD, it adds it to $REPODEST/foo/
2020-02-28 15:44:41 <minecrell> ooh, I think I got it working :)
2020-02-28 15:46:01 <minecrell> so I had to add $REPODEST/dirA to /etc/apk/repositories, then it worked :)
2020-02-28 15:46:09 <_ikke_> yes
2020-02-28 15:46:26 <_ikke_> dirA would normally correspond with main / community / testing
2020-02-28 16:07:24 <oneinsect> here is ncopa first trying to develop apk-tools in 2005 https://sourceforge.net/p/leaf/mailman/message/12730905/ as part of leaf project, interesting insights into the whole apk-tools package
2020-02-28 16:10:55 <mps> eh, I remember that I looked at it at these time, even tested leaf but never used it in production
2020-02-28 16:12:00 <Cogitri> oneinsect: Thanks, that's interesting
2020-02-28 16:15:07 <oneinsect> whats more interesting is his explanation on including metadata is some files that are compressed to a tar.gz archive and the compressed files are very similar to lrp....i am documenting this
2020-02-28 16:15:44 <oneinsect> any ideas on how abuild packages apk files? i mean how are abuild and apk related?
2020-02-28 16:16:15 <mps> oneinsect: look at irc log few days ago
2020-02-28 16:16:25 <oneinsect> same month?
2020-02-28 16:16:44 <oneinsect> okie checking https://dev.alpinelinux.org/irclogs/%23alpine-devel-2020-02.log
2020-02-28 16:16:44 <mps> yesterday, maybe even
2020-02-28 16:17:09 <mps> search for reidrankin explanations
2020-02-28 16:18:54 <oneinsect> thanks
2020-02-28 16:29:00 <oneinsect> this is way harder than i thought.....i thought of compiling separately (using LFS or something similar) with make but packing them as apk files but oh my god...there is too much to know about apk signing here
2020-02-28 16:38:01 <oneinsect> _ikke_ i cloned the aports repo.... can you please let me know the command to start building ... i went into the zlib folder and abuild but nothing happens
2020-02-28 16:38:23 <_ikke_> abuild -r
2020-02-28 16:39:20 <oneinsect> nothing happens
2020-02-28 16:49:45 <oneinsect> friends is there a way we can convert debian or rpms to apks? any ideas?
2020-02-28 16:52:02 <wsinatra> oneinsect: dunno that there's a way currently. I usually just convert by hand after referencing known working builds on other systems
2020-02-28 16:52:27 <wsinatra> maybe a script or emacs extension could be made to do that though
2020-02-28 16:52:40 <wsinatra> what exactly are you trying to port over?
2020-02-28 16:55:10 <oneinsect> www.tensorflow.org
2020-02-28 16:55:43 <oneinsect> can you atleast paste how you convert by hand? any steps you can outline wsinatra
2020-02-28 16:58:57 <wsinatra> typically the only things I take from another package build are source urls (for reference), licenses, dependencies, and build/check/install steps
2020-02-28 16:59:26 <wsinatra> that's typically what moves over once you cut back the fluff.
2020-02-28 17:00:01 <oneinsect> hmmmm
2020-02-28 17:00:29 <wsinatra> I have an APKBUILD template at https://gitlab.com/Durrendal/WS-Alpine-Packages/snippets/1897535 that might be of useful reference
2020-02-28 17:01:44 <wsinatra> I remember struggling to wrap my head around the package build when I picked up SBCL, so I'm happy to help
2020-02-28 17:03:19 <oneinsect> i really struggling since august 2019 to think around and build a glibc version of alpine but there is so much to wrap around...its been really really hard
2020-02-28 17:04:02 <wsinatra> why glibc though? Half of the appeal is musl libc for a lot of people
2020-02-28 17:04:58 <wsinatra> You can get a glibc chroot going easily enough I think, but if you wanted to rebuild all of alpine against glibc you're talking about a fork at that point
2020-02-28 17:05:48 <afontain_> void has both musl and glibc
2020-02-28 17:06:04 <oneinsect> the deep learning libraries depend on glibc, i tired compiling them with musl, they dont work, and they require direct access to hardware and chroot doesnt give direct access to hardware right? and i only realized today if i was use the abuild to build glibc, there's implicit build time dependency on build-base which includes gcc, musl and few
2020-02-28 17:06:04 <oneinsect> other basic things..
2020-02-28 17:06:19 <oneinsect> void doesnt have the inmemory functionality of alpine linux
2020-02-28 17:06:40 <_ikke_> oneinsect: a chroot is nothing special
2020-02-28 17:06:53 <_ikke_> It just runs on the host os
2020-02-28 17:07:02 <_ikke_> the only difference is that it sees a different root path
2020-02-28 17:07:20 <wsinatra> could you not build the tools that are required against musl? I had to do that to get SBCL built
2020-02-28 17:07:55 <maxice8> Compiling tensorflow and other deep learning libraries against musl is harder than compiling Alpine Linux with glibc
2020-02-28 17:08:14 <oneinsect> agreed maxice8
2020-02-28 17:08:50 <oneinsect> the tools dont compile against musl wsinatra
2020-02-28 17:09:38 <dalias> doesn't tensorflow depend on nvidia binary drivers or something awful? :-p
2020-02-28 17:09:42 <wsinatra> That's a shame
2020-02-28 17:10:04 <dalias> (no idea really; i'm asking)
2020-02-28 17:10:45 <oneinsect> it depends heavily on nvidia drivers and sdk/cuda which simply refuses with musl
2020-02-28 17:10:53 <oneinsect> to compile*
2020-02-28 17:12:50 <wsinatra> oneinsect: so your plan is to try to rebuild everything against glibc and then package the ML libraries for it so that you can use the in memory build?
2020-02-28 17:12:58 <oneinsect> exactly
2020-02-28 17:13:48 <wsinatra> Not positive if it works or not, but there appears to be a few Alpine docker builds for tensorflow
2020-02-28 17:14:24 <wsinatra> https://github.com/better/alpine-tensorflow/blob/master/Dockerfile
2020-02-28 17:15:04 <wsinatra> I'm not sure if that would help you package it or not, or if it even works. It at least helps point some of the dependencies out.
2020-02-28 17:15:12 <maxice8> That has no nvidia sdk/cuda support from what i can see
2020-02-28 17:15:31 <oneinsect> yeaa unfortunately there is no cuda support
2020-02-28 17:15:53 <dalias> it we worked out the gpu driver bridge then it would work
2020-02-28 17:16:11 <dalias> you'd just make an isolated environment for glibc + cuda to run in, and ipc to that
2020-02-28 17:17:19 <oneinsect> yeaa that would be like the last restort....
2020-02-28 17:17:51 <dalias> well that's the right way to do it, always, but depends on actually doing the long-awaited gpu driver bridge to get that crap out of the process's core
2020-02-28 17:19:32 <oneinsect> but i always wonder why is to so hard to compile against glibc (if not the entire full alpine packages) but some basic core, there should be a way...just not able to figure out the whole picture
2020-02-28 17:21:54 <dalias> oneinsect, i don't think it's much harder than bootstrapping a new arch for alpine, but bootstrapping a new arch isn't easy
2020-02-28 17:22:57 <dalias> for both you'd have to cross compile enough initial packages to get a working base environment for build
2020-02-28 17:23:03 <dalias> and then build the packages you need inside it
2020-02-28 17:23:30 <dalias> as an easy hack it might work to just build them from abuild on an existing non-alpine glibc-based host
2020-02-28 17:23:33 <dalias> like a debian box
2020-02-28 17:26:18 <oneinsect> the problem with that approach is abuild compiles very well on debian but then it doesnt compile other packages, it itself i think requires alpine environment
2020-02-28 17:26:28 <oneinsect> that was what i was made to understnad
2020-02-28 17:26:45 <dalias> ah
2020-02-28 17:26:48 <oneinsect> somebody did port alpine to RISC-V https://drewdevault.com/2018/12/20/Porting-Alpine-Linux-to-RISC-V.html
2020-02-28 17:27:07 <oneinsect> but dont use glibc anywhere...its just basic port
2020-02-28 17:28:02 <wsinatra> Would a glibc compatibility layer work? I'm guessing it would run into the same problem as any other sort of middleware suggested thus far
2020-02-28 17:29:42 <oneinsect> yes and i dont understand why abuild should require alpine environment? if abuild has aports (compiled in debian) it should work right, i mean it really doesnt depend on anything fancy https://pkgs.alpinelinux.org/package/edge/main/x86_64/abuild
2020-02-28 17:30:17 <oneinsect> abuild and aports should in any host without alpine right? experts can throw in some info
2020-02-28 17:30:22 <dalias> oneinsect, i think it depends on installing the build dep packages, right ?
2020-02-28 17:30:47 <dalias> imo the right way to do this would be installing build dep packages in a separate build-deps root
2020-02-28 17:31:00 <dalias> and adding the right -I and -L to use that during build of the new package
2020-02-28 17:31:15 <dalias> if done right this would let you build packages without even having root
2020-02-28 17:31:36 <oneinsect> that points seems to be make sense
2020-02-28 17:32:16 <[[sroracle]]> you'd have to play an endless game of trying to prevent the host system from contaminating the build
2020-02-28 17:32:31 <[[sroracle]]> at that point it's easier to just build everything inside a container/chroot
2020-02-28 17:32:40 <maxice8> Sounds like a fun game, Exherbo did it for the amusement of bystanders.
2020-02-28 17:33:08 <[[sroracle]]> which should generally be done anyway for the sake of reproducible builds
2020-02-28 17:36:12 <oneinsect> i mean i am not against musl but there are too many glibc packages which just dont work and alpine has too many great ideas to left out, i wish a glibc build comes along, okie back to our discussion, assuming we do start a chroot build, whats the starting point, compile abuild and then how do you make it to compile packages, it just doesnt seem to
2020-02-28 17:36:12 <oneinsect> work in isolation
2020-02-28 17:37:16 <oneinsect> dalias: i would like to try your idea, can you expand a bit more
2020-02-28 17:39:47 <dalias> oneinsect, my idea is developing something we've desperately wanted for over a decade
2020-02-28 17:40:15 <dalias> to fix the model of gpu-using applications not to be hopelessly fragile & insecure & dependent on dynamic linking
2020-02-28 17:40:29 <dalias> it is a very significant development project to make it happen
2020-02-28 17:40:38 <dalias> not a quick solution to your problem
2020-02-28 17:41:21 <oneinsect> hmmmm
2020-02-28 17:44:31 <dalias> if you want to develop this or fund a project for some ppl to do so that'd be awesome! ;-)
2020-02-28 17:44:43 <dalias> but it's by no means an easy task and involves a lot of preliminary research
2020-02-28 17:46:50 <oneinsect> i am mostly electronics/material science guy, i have patents in battery technologies, right now working on motor, mostly for autonomous vehicles, the requirement for in-memory glibc based os came there, if i get any funds going forward i am happy divert them to you guys
2020-02-28 17:51:21 <oneinsect> okie so as a first task i will try out compiling the https://pkgs.alpinelinux.org/package/edge/main/x86/alpine-base and then compile the abuild and do a chroot of that and see if i am able to progress somewhere
2020-02-28 17:51:38 <oneinsect> by changing musl to glibc
2020-02-28 17:53:20 <dalias> in any case i believe people have successfully hacked the nvidia drivers to load with musl
2020-02-28 17:53:25 <dalias> but i'm not sure how easy it is
2020-02-28 17:54:08 <oneinsect> also there is too much metadata to be populated in /lib/apk/db for alpine chroot to know that i have compiled those packages and installed them
2020-02-28 17:54:38 <oneinsect> that is one help if someone can throw light on what exactly are those metadata fields are for and do we need to populate them
2020-02-28 17:54:48 <oneinsect> for every package*
2020-02-28 17:55:09 <oneinsect> then the progress should happen faster
2020-02-28 17:56:19 <oneinsect> how do you manually populate /lib/apk/db/installed file to tell alpine that packages are installed
2020-02-28 17:59:18 <oneinsect> are all these fields required? which are optional? https://wiki.alpinelinux.org/wiki/Apk_spec
2020-02-28 18:26:12 <oneinsect> okie i tried commenting the C Pull Checksum, I Package Installed Size, S Package Size fields for example in the /lib/apk/db/installed for curl package and when I run apk info curl, it throws Segmentation fault (core dumped)
2020-02-28 18:26:22 <oneinsect> seems they are required
2020-02-28 18:28:43 <oneinsect> okie seems the symbol # is not liked by apk so commenting doesnt work .....however removing them completely (some fields) doesnt seem to make any issues, apk info curl works
2020-02-28 18:31:50 <[[sroracle]]> trying to manually change the installed database sounds much harder than whatever you're trying to solve
2020-02-28 18:32:01 <[[sroracle]]> manually*
2020-02-28 18:33:10 <reidrankin> oneinsect: sounds like you're having a fun day so far
2020-02-28 18:33:49 <reidrankin> fun fact: apk has next to no accurate documentation of its internal formats
2020-02-28 18:34:08 <reidrankin> I'm working on that
2020-02-28 18:34:14 <oneinsect> okie the idea is basically this, manually compile glibc, abuild etc and to manually populate lib/db/installed so that abuild and apk knows that the packages are there to build further on it
2020-02-28 18:34:26 <[[sroracle]]> no
2020-02-28 18:34:27 <oneinsect> that will helpful reidrankin:
2020-02-28 18:34:46 <[[sroracle]]> just skip abuild deps as needed until you have a working set of packages
2020-02-28 18:34:49 <reidrankin> you can probably just use a virtual package for that
2020-02-28 18:34:54 <[[sroracle]]> or that
2020-02-28 18:34:58 <reidrankin> apk add -t package-name
2020-02-28 18:35:36 <reidrankin> the docs say it's intended to let you install/uninstall a bunch of packages as a block, so you'd do `apk add -t foobar foo bar`
2020-02-28 18:36:10 <reidrankin> and `apk del foobar` would get rid of both foo and bar because they're only installed because they've been set as dependencies of the virtual package "foobar"
2020-02-28 18:36:23 <reidrankin> but you can totally leave the list of dependencies empty and it works fine
2020-02-28 18:36:41 <oneinsect> aha
2020-02-28 18:37:10 <reidrankin> for example: if you're installing wireguard-rpi2 (say) on a run-from-RAM system, the WG package depends on linux-rpi2
2020-02-28 18:37:46 <reidrankin> but the kernel and its modules are not delivered by that package on run-from-RAM systems
2020-02-28 18:38:29 <reidrankin> so `apk add wireguard-rpi2` causes installation of a duplicate download and install of the kernel and modules into the tmpfs root
2020-02-28 18:39:02 <reidrankin> anyway, you can do `apk add -t linux-rpi` and it'll make a virtual package with that name, thereby preventing the chaos
2020-02-28 18:39:25 <reidrankin> it's not a *good* solution but it works and the others suck more ATM
2020-02-28 18:40:26 <oneinsect> i mean we are leaving the dependencies empty right? what if say wireguard crashes due to lack of dependencies (just assuming) i would still need them right?
2020-02-28 18:41:21 <oneinsect> and i can use -d for abuild to disable dependency checking
2020-02-28 18:42:41 <oneinsect> but ofcourse in this case (glibc builds), virtual packages will help instead of just skipping using -d, correct right?
2020-02-28 18:42:55 <reidrankin> in my example, the run-from-RAM install has the kernel and associated modules already -- it just doesn't get them via installation of the linux-rpi2 package
2020-02-28 18:43:02 <oneinsect> aha
2020-02-28 18:43:17 <reidrankin> so installing that package installs the deps over the existing copies
2020-02-28 18:43:45 <reidrankin> which mostly doesn't happen to break stuff -- except the /lib/firmware folder
2020-02-28 18:43:58 <reidrankin> which is how I realized it was happening at all
2020-02-28 18:44:12 <oneinsect>  kinda strange why it doesnt find them in the first place, these should be fixed...
2020-02-28 18:44:36 <reidrankin> I'm working on that too
2020-02-28 18:46:05 <reidrankin> the solution isn't immediately obvious, because the virtual package thing is a hack -- the linux-rpi2 package includes, say, /boot/config-rpi2
2020-02-28 18:46:41 <oneinsect> ummmm...understood, all these have to be documented nicely like a beginners guide or something, i will do it after i finish this glibc builds
2020-02-28 18:46:50 <reidrankin> run-from-RAM installs typically have that file, but don't nessecarily have a boot partition mounted at that location
2020-02-28 18:47:04 <reidrankin> hahahaha documentation
2020-02-28 18:47:07 <oneinsect> yes i use alpine on rpi3
2020-02-28 18:47:30 <reidrankin> I've been reverse engineering APK for like 3 weeks to try and figure out how it works
2020-02-28 18:47:52 <reidrankin> i literally have the source code right here -- and I'm not dumb -- but it still takes hours to figure out certain things
2020-02-28 18:48:30 <reidrankin> for example: how does APK compare version numbers? who the heck knows.
2020-02-28 18:49:10 <reidrankin> Certainly not the single comment in the function that does it that contains a pseudo-regex-thing purporting to describe how it works.
2020-02-28 18:51:06 <reidrankin> Took me 3 days to get a precise answer. It looks way more obvious than it is, which you only find out by writing code does what you think it's doing and finding out that it compares things differently.
2020-02-28 18:52:55 <reidrankin> Anyhow I'm working on it. It'll probably be a month or two before I've got something to show for it though.
2020-02-28 18:55:02 <oneinsect> thats lots of work reidrakin
2020-02-28 18:59:18 <reidrankin> the worst part is that APK is amazing
2020-02-28 18:59:45 <reidrankin> it's tiny, fast, does everything you need it to and nothing you don't
2020-02-28 19:00:22 <reidrankin> it's just severely lacking documentation on how it works and nigh-on-unmaintainable
2020-02-28 19:00:55 <reidrankin> which are things that git under my skin because I'm a developer, but users never see
2020-02-28 19:01:48 <reidrankin> I was just a user for years before I poked my head down the rabbit hole to see what made it tick, and I had a great experience with no major issues
2020-02-28 19:02:32 <reidrankin> all my code-quality instincts tell me that there's no way this thing can work well, but dammit it does
2020-02-28 19:03:26 <oneinsect> ummmmm i hope this glibc thingi works out.... alpine is just amazing to be left for me, i keep coming back to it
2020-02-28 19:14:38 <oneinsect> quick question wont abuild work in bash? seems its looking for ash only?
2020-02-28 19:15:30 <reidrankin> (idk much about abuild internals, sorry)
2020-02-28 19:28:51 <mps> heh, nearly exact prediction, kernel 5.4.23 is released
2020-02-28 19:54:03 <oneinsect> okie compiled abuild from here https://dev.alpinelinux.org/archive/abuild/ and its successful..now downloaded zlib apkbuild and tried to compile, doesnt work https://justpaste.it/6c2v5
2020-02-28 19:54:15 <oneinsect> any ideas on how to make it work in a non-alpine host environment
2020-02-28 20:00:48 <Cogitri> I'd say use docker-abuild to be honest
2020-02-28 20:01:03 <Cogitri> This is going to be unsupported either way and no one will really care if it breaks
2020-02-28 20:07:25 <mps> clandmeter: ping
2020-02-28 20:28:45 <oneinsect> folks
2020-02-28 20:30:10 <oneinsect> thanks for all the help, on a non-alpine host, i am able to use abuild to compile and package into pkg/ folder however i am still unable to assemble it into a single file package
2020-02-28 20:32:13 <oneinsect> hopefully tomorrow once i get back i should be able to solve it
2020-02-28 20:32:25 <oneinsect> thats for zlib
2020-02-28 20:43:59 <oneinsect> okie ERROR: Unable to read database state: No such file or directory and ERROR: Failed to open apk database: No such file or directory are two errors preventing the creation of the apks
2020-02-28 20:45:00 <oneinsect> any ideas where is apk or abuild looking to read the database state? is lib/apk/db/ ?
2020-02-29 02:38:04 <oneinsect> reidrankin: are you here or asleep
2020-02-29 02:38:12 <oneinsect> i have some questions on apk-tools
2020-02-29 02:41:57 <oneinsect> on a completely new system, how does apk-tools start creating required files? like etc/apk/world, like/apk/db/lock, etc/apk/arch, lib/apk/db/scripts.tar, lib/apk/db/installed etc. the database.c source code mentions that it the apk_db_read_state function reads in the following order
2020-02-29 02:42:27 <oneinsect> Read: * 1. /etc/apk/world, * 2. installed packages db, * 3. triggers db, * 4. scripts db 	
2020-02-29 02:45:55 <oneinsect> can i create etc/apk/keys on my own
2020-02-29 06:45:14 <oneinsect> okie i was able to progress further very near to creating an apk on non-alpine host - i did the following, apk --root /target --initdb add and copied the etc/apk and other folders that alpine creates in the target to the host include the keys. Generate a new private key using abuild-keygen -a -i which created keys and wrote in the host
2020-02-29 06:45:15 <oneinsect> /etc/abuild.conf file automatically
2020-02-29 06:47:29 <oneinsect> https://justpaste.it/6liis lines 1471 and 1601 of abuild script say bad substitution
2020-02-29 06:49:42 <oneinsect> what could be wrong with this line....... 1470 and 1471 local path=$1[ "${path:0:1}" = / ] || path=$(dirname "$2")/$path and 1601 which says mkdir -p "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}
2020-02-29 07:10:58 <oneinsect> okie solved the error by change the abuild script on the top to have #!/bin/bash instead of ash, solved the above bad substitution issues, seems this problem occurs because Ubuntu points to dash, not bash
2020-02-29 07:20:47 <oneinsect> it gladly creates the following zlib-1.2.11-r3.apk  zlib-dev-1.2.11-r3.apk  zlib-doc-1.2.11-r3.apk  zlib-static-1.2.11-r3.apk....wooow! i mean really wooow! although it still at one point says >>> zlib: Tracing dependencies...>>> ERROR: zlib: libc.so.6: path not found
2020-02-29 07:31:56 <oneinsect> Because the file /etc/ld.so.conf.d/x86_64-linux-gnu.conf file defines the paths to be (multiarch)/usr/local/lib/x86_64-linux-gnu/lib/x86_64-linux-gnu/usr/lib/x86_64-linux-gnuThe libc.so.6 can be found in /lib/x86_64-linux-gnu/libc.so.6 and alpine seems to be looking in lib folder hence i could just do a sudo ln -s /lib/i386-linux-gnu/libc.so.6
2020-02-29 07:31:56 <oneinsect> /lib/libc.so.6 or change the zlib APKBUILD file
2020-02-29 07:34:33 <oneinsect> more precisely ln -s /lib/x86_64-linux-gnu/libc.so.6 /lib/libc.so.6
2020-02-29 07:37:44 <oneinsect> phew! ERROR: /usr/lib/x86_64-linux-gnu/libc-2.30.so: Could not find owner package, what does this mean? owner package?
2020-02-29 08:13:15 <Cogitri> oneinsect: apk tracks sonames of packages for you
2020-02-29 08:13:40 <AinNero> i dont think apk building is supported on non-alpine
2020-02-29 08:13:57 <Cogitri> So if package X links against package Y abuild will automatically add a runtime dependency for X on Y
2020-02-29 08:14:14 <Cogitri> Yes, it sure isn't and probably will never be, AinNero
2020-02-29 08:15:34 <Cogitri> Regarding that, I'm still not sure why you're trying to compile Alpine packages on Ubuntu against glibc, oneinsect
2020-02-29 08:30:14 <oneinsect> i was just testing it out, to build base packages required to build an alpine-glibc version (zlib was just a test)
2020-02-29 08:31:20 <Cogitri> Getting an alpine-glibc version is going to be one kind of an uphill battle
2020-02-29 08:32:51 <AinNero> also, whats the reason to use alpine if you blow it up with glibc?
2020-02-29 08:33:08 <AinNero> the small binary size with musl is like the primary feature of alpine
2020-02-29 08:33:58 <oneinsect> yes i know its an uphill battle, there are features than binary size that i was interested in, especially using on edge devices as in-memory linux and easy of maintenance with its vfat support, lbu based easy commits
2020-02-29 08:34:37 <oneinsect> there are too many good features to list out here, i mean i just like the ideology of alpine.. i could have happily used musl if not for the nvidia cuda and other framework issues
2020-02-29 08:36:01 <oneinsect> easy openrc system...i just simply love it
2020-02-29 08:38:39 <mps> oneinsect: small binaries are here thanks to musl
2020-02-29 08:40:35 <mps> I didn't measured but from experience you will have glibc binaries at least 40% bigger
2020-02-29 08:40:49 <mps> in average I mean
2020-02-29 08:42:09 <oneinsect> yeaa and i wish i could avoid glibc but i dont know when that possibility will come
2020-02-29 08:43:35 <mps> if you manage to build glibc with alpine tools and get alpine-glibc distro it will be more like Arch linux and not alpine
2020-02-29 08:45:16 <mps> imo, better would be to rewrite/patch software you need for musl
2020-02-29 08:45:35 <Cogitri> mps: That won't be possible with NVidia stuff since that's about as proprietary as it gets though
2020-02-29 08:46:06 <mps> ah, propritary, then well ...
2020-02-29 08:46:32 <Cogitri> I guess a solution would be to buy AMD instead, but since those cards don't support CUDA I'm not sure how OpenCL would hold up
2020-02-29 08:46:40 <Cogitri> Although Rocm seems to shape up nicely
2020-02-29 08:51:21 <oneinsect> alpine-glibc ... i agree its against the some philosophy of alpine but i hope the day will come soon when glibc will be phased out
2020-02-29 09:04:17 <oneinsect> okie back to the previous error 'Could not find owner package', the problem is alpine tries find the name of the package that owns the file and when it doesnt return so it throws an error and comes
2020-02-29 09:04:37 <Cogitri> Yes
2020-02-29 09:04:49 <Cogitri> It'd be easiest to just make a glibc package, I suppose
2020-02-29 09:04:50 <oneinsect> why does abuild need the owner of the dependency file say libc.so.6
2020-02-29 09:04:54 <oneinsect> hmmm
2020-02-29 09:05:03 <oneinsect> you are right, may be i will do that now
2020-02-29 09:07:37 <Cogitri> See the explanation I wrote at 9:13 for that one
2020-02-29 09:09:16 <oneinsect> for the record the info.c source file contains the error "could not find owner package"
2020-02-29 09:10:41 <oneinsect> you mean this "if package X links against package Y abuild will automatically add a runtime dependency for X on Y" for this reason?
2020-02-29 09:11:00 <oneinsect> hence it will research for that package to add the dependency?
2020-02-29 09:11:05 <Cogitri> Yes
2020-02-29 09:11:07 <oneinsect> search*
2020-02-29 09:11:12 <Cogitri> It tries to find the package providing that so but can't do so
2020-02-29 09:11:23 <Cogitri> So it complains since that'll result in a missing runtime dep
2020-02-29 09:11:37 <oneinsect> okie i will have to try glibc build first
2020-02-29 09:13:02 <oneinsect> but then if even if i happen to make an apk how will abuild know libc.so.6 belong to glibc.apk unless i update the world and other apk local db files
2020-02-29 09:13:10 <Cogitri> !3202
2020-02-29 09:13:26 <Cogitri> 
ACTION shrugs

2020-02-29 09:13:33 <Cogitri> No clue ho to do that on non-Alpine
2020-02-29 09:13:50 <Cogitri> But you'll need this anyway if you want to build anything that links against something
2020-02-29 09:14:19 <oneinsect> is algitbot: a human?
2020-02-29 09:16:13 <Cogitri> No, as indicated by the name it's a bot
2020-02-29 09:20:05 <oneinsect> well glibc itself depends on other packages hence abuild will fail trying to find them to add as dependency
2020-02-29 09:20:23 <oneinsect> this problem has to be overcome somehow
2020-02-29 09:20:55 <oneinsect> make be create a virtual package
2020-02-29 09:30:02 <oneinsect> a quick question I can define a virtual package by say apk add -t glibc but how do i add list of files or description or metadata to the virtual package so that abuild knows libc.so.6 belongs to that package?
2020-02-29 09:32:22 <Cogitri> You'd need to add provides=so:libc.so.6 somehow
2020-02-29 09:35:28 <oneinsect> hmmm there is no documentation anywhere on how to do that
2020-02-29 09:39:51 <Cogitri> Not sure if there is a way to do that for virtual packages but you could just make an APKBUILD that installs nothing and provides that I suppose
2020-02-29 09:43:22 <oneinsect> ooh that is great idea....good thinking cogitri:
2020-02-29 09:44:03 <oneinsect> i will keep it as last resort let me dig in how to add files metadata to virtual packages
2020-02-29 09:53:58 <oneinsect> just for the record if you look at /lib/apk/db/installed file, alpine clearly uses the following notation as per alpine spec https://wiki.alpinelinux.org/wiki/Apk_spec     D for dependencies and p (small p) for package provides with F for specifying the file path
2020-02-29 09:54:20 <oneinsect> the p metadata field can be used to list files includes with the virtual package
2020-02-29 09:54:25 <oneinsect> gonna try it now
2020-02-29 09:54:35 <oneinsect> included*
2020-02-29 09:58:49 <oneinsect> sample p:so:libz.so.1=1.2.11 so:libcap.so.2=2.27 so:libssl.so.1.1=1.1 i wonder how does that version number on right side come from, is it used for finding the file or for file matching?
2020-02-29 10:00:29 <Cogitri> That's the version of the package that provides that soname
2020-02-29 10:00:50 <Cogitri> E.g. icu 64.1 has a different soname than 65.1
2020-02-29 10:04:55 <oneinsect> thus when I run apk info -a zlib, the out says zlib-1.2.11-r3 contains: lib/libz.so.1.2.11lib/libz.so.1
2020-02-29 10:05:11 <oneinsect> and the db file contains p:so:libz.so.1=1.2.11
2020-02-29 10:05:40 <oneinsect> so it is decoded as libz.so.1.2.11
2020-02-29 10:31:10 <oneinsect> success!!!! thank you all folks, it is compiling successfully and creating apk packages perfectly and here one of the entries i created for the virtual package
2020-02-29 10:31:11 <oneinsect> https://justpaste.it/215tx
2020-02-29 10:31:33 <oneinsect> just these 3 lines did the job p:so:libc.so.6=6F:lib/x86_64-linux-gnuR:libc.so.6
2020-02-29 10:32:56 <oneinsect> alpine is amazing, now i am going to create the entire alpine on glibc, let me see how it goes, will next need to create a repo, signatures and stuff ---yaay!!!!!
2020-02-29 10:35:03 <oneinsect> can i just complete a 100 meters race? please... can i? can i?
2020-02-29 11:20:21 <maxice8> @nmeum can we get !4 merged already ? nobody complained for 2 weeks
2020-02-29 12:13:19 <nmeum> maxice8: not sure, does ncopa return on monday if so: maybe just wait to see if he has any strong opinions on this? otherwise I would be ok with merging it soonish, I think I need to rebase it again though
2020-02-29 12:18:47 <maxice8> Yeah I merged it
2020-02-29 12:39:19 <minecrell> nmeum: https://github.com/nmeum/android-tools/pull/10
2020-02-29 12:40:36 <nmeum> maxice8: ok great (:
2020-02-29 12:40:45 <nmeum> minecrell: ahhh, nice \o/
2020-02-29 12:41:57 <nmeum> will try to review it in the next few days
2020-02-29 12:42:00 <nmeum> looks good on first glance
2020-02-29 12:50:38 <minecrell> nmeum: Thanks :)
2020-02-29 12:50:53 <nmeum> thanks for doing the upgrade (:
2020-02-29 16:42:09 <mps> nmeum: do you think 3e79eb3b13e98d85abf3941f8bf54e0743a86896 should be backported to 3.11-stable
2020-02-29 16:42:58 <mps> I'm preparing thumb fix and noticed that
2020-02-29 16:47:14 <nmeum> mps: since the old url still works I personally don't think that a backport is neccessary
2020-02-29 16:49:05 <mps> ok, I created MR !4794
2020-02-29 16:49:44 <mps> will not hurt to have there your url update ?
2020-02-29 16:52:25 <mps> except I didn't bumped pkgrel, but it will be ok as it is, I think
2020-02-29 16:56:52 <mps> _ikke_: in above MR when followed armv7 log and tried to dowload apk's I'm somehow redirected to aarch64 instead of armv7
2020-02-29 17:20:12 <_ikke_> mps: can you try and see if the packages self are aarch64 or armv7?
2020-02-29 17:21:14 <_ikke_> ARMv7 is built on an aarch64 machine in 32 bits mode
2020-02-29 17:21:50 <_ikke_> I'm not on a pc atm, so cannot verify myself
2020-02-29 17:24:35 <mps> I dowloaded complete zip, will unpack and look
2020-02-29 17:32:59 <mps> unpacked MR5201_armv7.zip, untar musl-1.1.24-r1.apk, then 'file lib/ld-musl-aarch64.so.1' => lib/ld-musl-aarch64.so.1: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, stripped
2020-02-29 17:34:32 <mps> I will build it on lxc to test it again on real hardware
2020-02-29 17:37:11 <_ikke_> Yeah, appears to be aarch64 then.
2020-02-29 17:37:58 <mps> np, I built it on lxc again
2020-02-29 18:12:51 <oneinsect> can I use alpine-glibc for glibc builds or alpine word is restricted usage?
2020-02-29 18:13:00 <oneinsect> alpine or alpine linux
2020-02-29 18:15:06 <mps> I think it is better to find another name, your port is not official Alpine subproject and as such not related to Alpine Linux
2020-02-29 18:15:33 <oneinsect> thanks i will find another name
2020-02-29 18:15:50 <mps> look how Adelie Linux did this
2020-02-29 18:16:15 <oneinsect> oooh yeaaaa
2020-02-29 18:16:51 <mps> it started as fork (iirc) and they still use apk and APKBUILD, but they don't have Alpine anywhere in their site
2020-02-29 18:18:09 <oneinsect> i mean i will use everything from alpine only the glibc library will be the change, otherwise i will not do much changes, yes i will check their site
2020-02-29 18:18:46 <mps> well, ever then it is not related to Alpine project
2020-02-29 18:19:48 <mps> you can freely use whatever you want from alpine but not official project names, anyway IANAL :)
2020-02-29 18:20:20 <oneinsect> yes agreed and the folks here are really wonderful people, they support so much
2020-02-29 18:20:25 <mps> Alpine belongs to current BDFL
2020-02-29 18:20:45 <mps> Alpine Linux, sorry
2020-02-29 18:21:30 <mps> personally and sincerely I wish you good luck and success
2020-02-29 18:22:44 <oneinsect> :-D  thanks btw i am not going anywhere, this build is only temporary, i will return to alpine to start working on doing some patches for nvidia libraries and see if we can port them
2020-02-29 18:22:56 <oneinsect> to muslc
2020-02-29 18:24:32 <mps> well, I wrote 'good luck' and not 'good bye' :)
2020-02-29 18:25:00 <oneinsect> heeheee thanks