2020-04-01 07:42:25 <clandmeter> morning
2020-04-01 07:42:29 <clandmeter> im getting makecontext: symbol not found
2020-04-01 07:52:52 <Cogitri> What package?
2020-04-01 07:52:52 <Cogitri> I get libucontext might help
2020-04-01 07:53:02 <Cogitri> s/get/guess/
2020-04-01 07:53:02 <alpine-meetbot> Cogitri meant to say: I guess libucontext might help
2020-04-01 08:08:50 <ncopa> i puhsed a fix for clandmeters issue
2020-04-01 08:13:27 <Cogitri> 👍
2020-04-01 08:14:22 <clandmeter> obrigado
2020-04-01 08:14:48 <ncopa> de nada :)
2020-04-01 08:16:52 <clandmeter> ncopa: works
2020-04-01 08:19:42 <ncopa> awesome. I'll backport it
2020-04-01 08:25:30 <ncopa> uwsgit fix pushed to 3.11
2020-04-01 10:00:00 <ncopa> Ariadne: what is pivot_root needed for? and why is switch_root not sufficient? 84b90508d3362862fef2569bd167ca4f70cb8b4d
2020-04-01 10:50:35 <Ariadne> pivot_root is used in some scripts for my work in progress AlpineWRT project to switch the root at runtime
2020-04-01 11:31:34 <ncopa> and you cannot use switch_root for that?
2020-04-01 12:29:08 <Hello71> probably for in memory upgrade...
2020-04-01 13:24:53 <Ariadne> ncopa: we had difficulty getting it to work with switch_root
2020-04-01 14:56:25 <ncopa> ok
2020-04-01 15:33:14 <AinNero> Ariadne: what does AlpineWRT switch between?
2020-04-01 15:33:35 <AinNero> rootfs to dev? or dev to dev?
2020-04-01 15:57:25 <maxice8> http://ix.io/2gfg config-lts ran against https://github.com/a13xp0p0v/kconfig-hardened-check
2020-04-01 16:03:33 <mps> usable and secure, select one, both doesn't fit together well
2020-04-01 16:04:05 <maxice8> it is not a binary choice
2020-04-01 16:04:42 <mps> yesterday I read this https://flak.tedunangst.com/post/rethinking-openbsd-security
2020-04-01 16:05:01 <mps> enough to read conclusion at the end
2020-04-01 16:37:16 <ncopa> they recommend setting CONFIG_MODULES=n
2020-04-01 16:37:28 <ncopa> so i question how valuable this is
2020-04-01 16:40:15 <mps> it is more secure
2020-04-01 16:41:34 <ncopa> ofc it is, but it is useless for a general-purpose kernel without module support
2020-04-01 16:42:27 <mps> true, and that is why I wrote above: select one, both doesn't fit together well
2020-04-01 16:43:30 <mps> only inexperienced people thinks that both are possible
2020-04-01 16:44:09 <mps> at the same time, I mean
2020-04-01 17:55:36 <Hello71> I think it's fair to have it listed under "cut_attack_surface"
2020-04-01 18:39:16 <mps> well, now in 5.6 this particular case is solved by lockdown option
2020-04-01 18:39:57 <mps> to some degree, ofc
2020-04-01 18:41:08 <maxice8> Yeah, that was done against a 5.4 kernel, I ran it against config-lts
2020-04-01 18:43:53 <Ariadne> AinNero: dev to dev
2020-04-01 18:46:02 <mps> again, I think those who want more security of the kernel should build it themselves
2020-04-01 18:46:39 <mps> or want to tweak performance (or size)
2020-04-01 20:04:46 <_ikke_> FYI, going to restart gitlab to install latest patch release
2020-04-01 21:27:36 <Sodomon> 
ACTION 

2020-04-02 07:17:54 <oneinsect> can anyone suggest how to static compile abuild?
2020-04-02 07:19:06 <clandmeter> abuild is a shell script?
2020-04-02 07:19:18 <clandmeter> or do you mean to compile static *with* abuild?
2020-04-02 07:20:20 <oneinsect> no i mean there are sub-programs in abuild package like abuild-tar etc
2020-04-02 07:20:23 <oneinsect> those i meant
2020-04-02 07:20:40 <clandmeter> ah the helpers
2020-04-02 07:21:10 <oneinsect> this will help a lot in bootstrapping like apk-static version
2020-04-02 07:21:13 <_ikke_> clandmeter: oneinsect is trying to build againt glibc
2020-04-02 07:21:23 <clandmeter> heh :)
2020-04-02 07:21:35 <clandmeter> i boostrapped alpine ones on glibc
2020-04-02 07:21:48 <clandmeter> there are still some refs in aports i guess
2020-04-02 07:22:38 <oneinsect> how did you do that clandmeter: the thing is its like a chicken and egg problem, everything can be built from scratch using abuild and apk tools alone but abuild compilation itself depends on openssl which then depends on other things
2020-04-02 07:23:09 <clandmeter> that is probably 10 years ago
2020-04-02 07:23:21 <clandmeter> the world was a different place back then
2020-04-02 07:23:25 <oneinsect> can you go back in time
2020-04-02 07:23:42 <clandmeter> i would love to :)
2020-04-02 07:23:59 <clandmeter> im not sure about the helpers, better ask ncopa fabled or Ariadne.
2020-04-02 07:24:21 <oneinsect> hmmmm mostly the helpers from here
2020-04-02 07:24:22 <oneinsect> https://github.com/alpinelinux/abuild
2020-04-02 07:24:36 <clandmeter> better use gitlab uri
2020-04-02 07:24:39 <oneinsect> that is one last staw in the nail left to be nailed
2020-04-02 07:24:41 <clandmeter> we are switchin
2020-04-02 07:24:44 <oneinsect> ooooh
2020-04-02 07:24:53 <oneinsect> i didnt know that, i will
2020-04-02 07:25:00 <clandmeter> just a small reminder :)
2020-04-02 07:25:59 <oneinsect> ncopa: fabled: ariadne: anyone around?
2020-04-02 07:31:09 <Cogitri> Just build add CFLAGS="-static" ?
2020-04-02 07:33:01 <oneinsect> in the makefile?
2020-04-02 07:33:49 <oneinsect> got it something like CFLAGS=-static make
2020-04-02 07:34:33 <oneinsect> let me try, thanks Cogitri:
2020-04-02 07:37:13 <oneinsect> Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
2020-04-02 07:37:20 <oneinsect> abuild-rmtemp.c:(.text+0x175): warning:
2020-04-02 07:37:45 <oneinsect> may be i need to enable --enable-static-nss
2020-04-02 07:42:12 <oneinsect> darn libc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration
2020-04-02 07:55:29 <Cogitri> It doesn't work when statically linking musl either?
2020-04-02 07:57:47 <mps> mesa update released, https://lists.freedesktop.org/archives/mesa-dev/2020-April/224357.html
2020-04-02 07:58:16 <mps> maybe it fixes issue in previous release
2020-04-02 07:59:02 <Cogitri> Let me check
2020-04-02 07:59:11 <mps> clandmeter: re lxc, yes I read that the soon will be 4.0.1 released
2020-04-02 07:59:24 <mps> waiting for it
2020-04-02 07:59:36 <mps> and I think to upgrade lxcfs also
2020-04-02 07:59:37 <Cogitri> Nop, it doesn't fix it, my Chromium still looks weird
2020-04-02 07:59:50 <clandmeter> you did not have troubles with cgroups?
2020-04-02 08:00:01 <clandmeter> are the scripts still doing a good job?
2020-04-02 08:00:04 <clandmeter> the alpine ones
2020-04-02 08:00:11 <mps> I didn't noticed any problem
2020-04-02 08:00:24 <mps> works same as 3.2.X
2020-04-02 08:00:59 <mps> though I don't have any 'special' settings
2020-04-02 08:02:11 <mps> Cogitri: could it be chromium problem then, all programs works fine on my two boxes, though I don't have chromium installed
2020-04-02 08:02:36 <Cogitri> It probably is something in Chromium's hw accel, yes
2020-04-02 08:02:48 <Cogitri> Either chromium triggers some bug in mesa since 20.x or the other way around
2020-04-02 08:03:07 <Cogitri> Steam (which also uses Chromium for the store) has the same bug
2020-04-02 08:03:25 <Cogitri> What's really weird is that QtWebEngine doesn't have it since version 5.14.x anymore but did have it in 5.12, so I'm not sure how they fixed it while Chromium didn't
2020-04-02 08:03:47 <Cogitri> Actually, maybe it runs on Wayland now, so it doesn't trigger that bug? Seems like only XWayland stuff using hw accel is hit
2020-04-02 08:04:29 <mps> ah, wayland
2020-04-02 08:28:03 <oneinsect> Cogitri: i think it should work with musl
2020-04-02 08:28:06 <oneinsect> i will recheck it once
2020-04-02 08:28:09 <oneinsect> with musl
2020-04-02 08:45:34 <PureTryOut[m]> mps: Cogitri What issues were you having exactly?
2020-04-02 08:48:10 <mps> PureTryOut[m]: as I said I don't have any, if you think on mesa
2020-04-02 09:02:33 <Cogitri> 
ACTION uploaded an image: image.png (93KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/ddzseHTHgJsJUnPbxBGPvSPC >

2020-04-02 09:02:50 <Cogitri> PureTryOut: My Chromium looks like this with HW accel on and Mesa 20.x
2020-04-02 09:06:56 <oneinsect> okie no such error when i compile with musl Cogitri: its build static without errors, thanks for the tip, i will go back to glibc environment to test it out
2020-04-02 09:06:57 <oneinsect> thanks
2020-04-02 09:09:46 <Cogitri> 👍
2020-04-02 09:27:33 <oneinsect> okie things like abuild-gzsplit wont run when though they compile statically because they could have run-time dependencies on tar, sudo etc
2020-04-02 09:27:40 <oneinsect> even*
2020-04-02 09:28:26 <oneinsect> darn, if I apk add them then musl gets into the way, woaa it is so hard to get a clean chroot of alpine
2020-04-02 09:29:31 <oneinsect> i could just alpine itself to bootstrap glic but things will leak into the new glibc bootstrap environments eventually
2020-04-02 09:29:38 <oneinsect> use*
2020-04-02 09:32:40 <Cogitri> Well, abuild wasn't really engineered to allow another configuration of packages
2020-04-02 09:33:35 <PureTryOut[m]> Cogitri: damn that is screwed up. Well I don't have Chromium, but like you said can not reproduce it with qt5-qtwebengine
2020-04-02 09:34:16 <oneinsect> is there a roadmap to reduce abuild dependencies?
2020-04-02 09:35:27 <Cogitri> PureTryOut[m]: Yes, it somehow fixed itself. I usually don't use Chromium either, I only used it for testing
2020-04-02 09:35:46 <Cogitri> oneinsect: Seems like a lot of work for basically no reason at all for mainstream Alpine
2020-04-02 09:36:03 <Cogitri> And I don't see how it'd do without tar and sudo
2020-04-02 09:36:22 <oneinsect> hmmmm
2020-04-02 09:38:05 <oneinsect> okie the other way around let me see if I can find static versions of tar/sudo etc from here
2020-04-02 09:38:15 <oneinsect> https://pkgs.alpinelinux.org/packages?page=1&branch=edge&name=%2Astatic%2A
2020-04-02 09:38:20 <oneinsect> or may be just build them also
2020-04-02 09:38:24 <oneinsect> statically
2020-04-02 11:12:40 <crashoverride> ok, there's one thing I don't get. If I have a package, let's say abc-1.2.3-r0, and I want to install abc-1.2.4-r2, why does apk complain about "breaks: abc-1.2.3-r0"?
2020-04-02 11:12:52 <crashoverride> it does not break it, it upgrades it...
2020-04-02 11:13:24 <Cogitri> That's probably a question for #alpine-linux
2020-04-02 11:13:32 <crashoverride> no, it is not.
2020-04-02 11:13:49 <u0jQx9gPyrYg> probably because abc depends on something that cannot be upgraded
2020-04-02 11:14:03 <crashoverride> u0jQx9gPyrYg: but apk does not mention that.
2020-04-02 11:15:07 <Cogitri> Well, we need to know the actual error message and the command you used, otherwise it's hard to do something other than guessing
2020-04-02 11:19:14 <crashoverride> u0jQx9gPyrYg: thanks for your hint, I did expect apk to inform the user of the full dependency requirements in case 'world' cannot be satisifed.
2020-04-02 11:23:39 <mps> crashoverride: no, if it become 'apt' it will be slow as 'apt'
2020-04-02 11:24:23 <mps> apk info -R abc
2020-04-02 11:24:27 <crashoverride> mps: the package manager needs to know what breaks in order to work, so it could calculate that. There's not much code requried to display it all; just more execution time.
2020-04-02 11:24:49 <crashoverride> mps: and yes, I did run that
2020-04-02 11:27:55 <crashoverride> mps: thanks for your help
2020-04-02 11:28:18 <mps> what pkg?
2020-04-02 11:28:31 <mps> and what alpine release
2020-04-02 11:29:15 <crashoverride> oh, it's a question I'd rather not answer publicly
2020-04-02 11:29:34 <mps> hmm, how then you expect help
2020-04-02 11:30:02 <crashoverride> by precisely describing what I was hoping for, and getting precise answers on why it does not work
2020-04-02 11:30:04 <mps> or you want to discuss design issue with apk tools
2020-04-02 11:30:05 <crashoverride> like what u0jQx9gPyrYg did.
2020-04-02 11:30:40 <crashoverride> I would, but I don't think I can either convince anyone here or bring any helpful insight in the current context.
2020-04-02 11:30:48 <crashoverride> mps: query if you want to know more :)
2020-04-02 11:31:27 <mps> most of use are open for design discussion
2020-04-02 11:32:26 <mps> and I agree with your note that maybe apk should give more infos in case something can't be done
2020-04-02 11:32:56 <mps> but we should look at pros and cons
2020-04-02 11:35:39 <Cogitri> I don't think there are many cons, since that error handling code would only run when things do go wrong and it's super worth it to go the extra mile then
2020-04-02 11:35:57 <Cogitri> I guess the problem is more with someone needing to implement that, but maybe that's already being done in apkV3
2020-04-02 11:40:28 <oneinsect> okie it is not actually building static executables even when I pass CFLAGS=-static make
2020-04-02 11:40:34 <oneinsect> ldd still shows dependencies
2020-04-02 11:40:38 <oneinsect> this is in musl
2020-04-02 11:55:43 <oneinsect> strange
2020-04-02 12:00:34 <oneinsect> okie found that I dont have a static version of the C library installed which is required if we want to use -static as the flag forces the linker to accept only static libraries and not any shared libraries
2020-04-02 14:43:52 <crashoverride> curl -I http://nl.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
2020-04-02 14:44:07 <crashoverride> X-Frame-Options: DENY
2020-04-02 14:44:12 <crashoverride> ? =/
2020-04-02 14:49:27 <crashoverride> nevermind, that was a proxy.
2020-04-02 14:49:36 <crashoverride> I should use https instead, I guess.
2020-04-02 17:53:08 <maxice8> andypost: can we talk here about libgit2 ? !6167
2020-04-02 17:54:15 <andypost[m]> maxice8: sure, I'm just checking dependencies
2020-04-02 17:55:04 <maxice8> I posted them up, using `apk list --depends so:libgit2.so.28` works pretty well
2020-04-02 17:55:41 <maxice8> http://ix.io/2gnJ i wrapped it into this neat script that looks only at the main package and removes duplicates
2020-04-02 18:02:21 <[[sroracle]]> maxice8: apk search --rdepends --exact --origin so:libgit2.so.28
2020-04-02 18:03:36 <maxice8> also works
2020-04-02 18:52:07 <andypost[m]> maxice8:
2020-04-02 18:52:21 <andypost[m]> pushed bumps but it looks py/ruby needs upgrades
2020-04-02 18:52:33 <andypost[m]> the only question is salt
2020-04-02 18:52:43 <maxice8> Alright
2020-04-02 18:52:44 <_ikke_> What about salt?
2020-04-02 18:53:33 <maxice8> @andypost did you push 0.28.5 for 3.11-stable ?
2020-04-02 18:54:03 <andypost[m]> it has dependency on py3-pygit2 but no idea how to test salt
2020-04-02 18:59:51 <andypost[m]> maxice8: pushed !6171
2020-04-02 20:30:39 <mps> maxice8: fcolista pushed lxd not lxc
2020-04-03 00:33:02 <maxice8> i saw
2020-04-03 07:48:14 <ncopa> _ikke_: FYI: 65dc9611694f97c20ea6061326d7756e788b7015
2020-04-03 07:48:35 <ncopa> sorry, wrong commit. this one: 3ca662903f5eb9c2462e4efcc37f636f5c072538
2020-04-03 07:48:50 <ncopa> i added the _kpkg so my script will pick it up
2020-04-03 07:49:09 <_ikke_> ncopa: ah, thanks
2020-04-03 07:49:39 <ncopa> i am not sure we should have this in community
2020-04-03 07:49:44 <ncopa> there are no releases
2020-04-03 07:50:41 <ncopa> having it in community means that we take responsibility to ship "releases" when upstream does not. normally there is a reason why upstream dont do stable releases
2020-04-03 07:51:10 <_ikke_> Yeah, the only reason I've added it is because someone needed it
2020-04-03 07:51:43 <ncopa> they should report it upstream so the driver gets into mainline kernel
2020-04-03 07:52:26 <ncopa> there is also normally a reason why upstream has not accepted it. often it is because no-one takes responsibility for maintenance
2020-04-03 07:52:48 <ncopa> we we ship this package, we are effectively taking responsibility for it
2020-04-03 07:54:30 <_ikke_> We don't have something like dkms as alternative either
2020-04-03 07:54:53 <_ikke_> I understand your point
2020-04-03 07:55:40 <ncopa> im not saying we should never do it. but i think its better to try push it upstream if possible
2020-04-03 07:56:05 <ncopa> i would probably have maintained such package myself if i needed it
2020-04-03 07:57:29 <_ikke_> The upstream of this package is taking the source code from realtek and providing it as a DKMS package
2020-04-03 07:57:36 <_ikke_> that's probably why they don't have releases
2020-04-03 07:58:12 <_ikke_> I took it because it was the easiest way to get just the driver code as an archive
2020-04-03 08:00:19 <Cogitri> We want to avoid calls to external programs like `tr` in APKBUILDs, right? Like here: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5823/diffs#c10bd88916718bbcf1aa619c632307ea8dca1781_32_41
2020-04-03 08:01:34 <_ikke_> Certainly in the global context
2020-04-03 08:02:26 <Cogitri> Okie, I'll mention that then, thanks
2020-04-03 08:03:50 <_ikke_> The reason is that we have tools that mass source all APKBUILDS. if there is a lot of forking happening in the global context, it would slow down these tools immensely
2020-04-03 08:04:31 <TBK[m]> _ikke_: please unlock !6121
2020-04-03 08:05:04 <_ikke_> Done
2020-04-03 08:41:02 <mps> uhm, internet is unstable. are my msg about mdocml appeared here?
2020-04-03 08:41:33 <_ikke_> I dont think so
2020-04-03 08:41:40 <_ikke_> Not since today at least
2020-04-03 08:41:58 <mps> aha, ok
2020-04-03 08:42:01 <mps> mdocml is renamed to mandoc for some time upstream. should we also rename apk to be 'in sync'
2020-04-03 09:36:12 <Cogitri> Does someone else have freezes with the latest kernel upgrade?
2020-04-03 09:36:27 <Cogitri> mps: Do you have your kernel 5.6 APKBUILD around?
2020-04-03 09:54:41 <ncopa> i dont have freeze with 5.4.30 (yet)
2020-04-03 09:59:18 <Cogitri> I'm suspecting it might be one of my USB devices going ham after I accidentally shocked it with some strong static
2020-04-03 09:59:40 <Cogitri> I'm somehow charging up a lot at my desk
2020-04-03 10:12:15 <_ikke_> Cogitri: I have the same
2020-04-03 10:12:23 <_ikke_> lots of shocks lately
2020-04-03 10:12:35 <_ikke_> Probably due to dry air
2020-04-03 10:16:25 <Cogitri> Let's hope it's just that USB device and I didn't shock something more expensive (although the PC case should be grounded so I don't seee how that'd do something)
2020-04-03 10:19:46 <TBK[m]> No ground connection?
2020-04-03 10:23:22 <TBK[m]> hmm I am getting a lot of delay lately with from the matrix <> freenode bridge.
2020-04-03 10:24:21 <Cogitri> Yes, matrix.org likes to be pretty slow, so I host my own thing
2020-04-03 10:24:45 <TBK[m]> Cogitri: do you have a multimeter you can use to measure continuity?
2020-04-03 10:26:30 <TBK[m]> I have contemplated doing that as well. Was hoping ruma would be prod ready by now.
2020-04-03 10:27:10 <Cogitri> I do have a multimeter around, but I'm pretty sure the thing should be grounded via the PSU
2020-04-03 10:27:25 <Cogitri> Also, it seems like it doesn't crash on Windows 🤔
2020-04-03 10:29:23 <Cogitri> Nevermind, f
2020-04-03 11:09:59 <Cogitri> Seems like my RX 5700 is dead :c
2020-04-03 11:11:21 <Cogitri> Doesn't crash with my HD 7970 apparently (phew that thing is old)
2020-04-03 11:17:20 <Cogitri> On Windows that is though, somehow I lose display signal after modeset
2020-04-03 12:05:25 <markand> +1 for s/mdocmel/mandoc
2020-04-03 14:19:25 <Ariadne> [03:42:01] <mps> mdocml is renamed to mandoc for some time upstream. should we also rename apk to be 'in sync'
2020-04-03 14:19:33 <Ariadne> seems reasonable, but will need provides/replaces
2020-04-03 15:01:40 <oneinsect> good morning
2020-04-03 15:06:05 <Cogitri> Hello
2020-04-03 15:10:32 <Cogitri> Shiz: Did replying to that mail on the ML worked for you?
2020-04-03 15:11:04 <Cogitri> I got `<jean-louis.fuchs@adfinis-sygroup.ch>: Name service error` back from my mailer daemon because it couldn't deliver the thing
2020-04-03 15:11:28 <oneinsect> cogitri: i have failed building a glibc based distro, someway or the other there are too many interdependencies and host libraries leak into the newer builds
2020-04-03 15:12:00 <oneinsect> i am gonna try using alpine itself as a host now one last time
2020-04-03 15:12:46 <Cogitri> Yeah, forcing glibc onto is bound to be a lot of work
2020-04-03 15:19:23 <paper_> is it a conflict when 2 -doc packages provide the same manpage? should it be added to conflicts=?
2020-04-03 15:19:39 <Cogitri> Or the docpage should be deleted from one of the pkgs
2020-04-03 15:20:01 <paper_> hmm, ok, I will look into it
2020-04-03 15:22:41 <artok> hey I found out that mount -t nfs <host>:<share> /mnt hits busybox flock error (-e unregogniced option)
2020-04-03 15:26:40 <artok> I just added util-linux for now, didn't check what is happening on mount that tries to get the lock
2020-04-03 15:32:28 <oneinsect> any static versions of muslc? It will help me cross the first major hurdle, apk-static is happily available in repo
2020-04-03 15:33:16 <maxice8> musl-dev
2020-04-03 15:34:12 <oneinsect> but then why is there a dependency on musl itself for installation?
2020-04-03 15:34:13 <oneinsect> https://pkgs.alpinelinux.org/package/edge/main/x86_64/musl-dev
2020-04-03 15:36:07 <maxice8> because the -dev package depends on the package that provides the soname
2020-04-03 15:36:29 <oneinsect> ooh my god
2020-04-03 15:36:29 <maxice8> musl-dev has libc.so and you link against it and it resolved against libc.musl-$CARCH.so.1
2020-04-03 15:36:53 <oneinsect> it has libc.a
2020-04-03 15:37:16 <maxice8> ?
2020-04-03 15:37:17 <maxice8> yes, that is the static part that i was referring to
2020-04-03 15:39:21 <oneinsect> okie let me try with that static library for static building of abuild
2020-04-03 15:47:14 <oneinsect> okie great maxice8: libz.a and libc.a arent problem now however abuild-gzsplit still wants static version of ld-musl-x86_64.so.1
2020-04-03 15:47:39 <oneinsect> any idea which package has a static version of it? (will save me from doing a static build)
2020-04-03 15:47:51 <maxice8> that is from the abuild package
2020-04-03 15:48:06 <maxice8> I don't expect it to have a static version
2020-04-03 15:49:01 <oneinsect> ld-musl-$(ARCH).so.1 provides the dynamic linker, or "program interpreter", for dynamically linked ELF programs using musl, so no static version for it?
2020-04-03 15:49:18 <maxice8> libc.a
2020-04-03 15:49:56 <oneinsect> darn why is it still asking for ld-musl-x86_64.so.1 then for static builds, let me recheck
2020-04-03 15:59:40 <arch_nemesis> is it possible to make the installer create the swap partition at the END of the disk as opposed to the beginning?
2020-04-03 16:00:48 <kaey> oneinsect: did you try looking at buildroot or crosstool-ng for bootstrapping?
2020-04-03 16:01:04 <oneinsect> buildroot took 16 hours and failed
2020-04-03 16:01:07 <oneinsect> i had no patience
2020-04-03 16:01:12 <oneinsect> to retry it again
2020-04-03 16:02:15 <oneinsect> crosstool-ng gives the glibc and cpp environment but when i copy them into a pristine alpine chroot without musl etc, i still need abuild
2020-04-03 16:02:32 <kaey> thats strange, took 15-20 mins to build full image for my devboard from zero
2020-04-03 16:02:42 <oneinsect> now abuild has so many dependencies which intern have many other interdependencies
2020-04-03 16:03:13 <oneinsect> that will pollute with so many dependencies
2020-04-03 16:04:07 <oneinsect> i had to select many libraries as addons for buildroot since abuild has that requirement
2020-04-03 16:04:46 <artok> was this all to get apk work for own lfs?
2020-04-03 16:04:48 <oneinsect> the idea is fundamentally simple alpine chroot ----> with basic gcc tools with abuild/apk ----> starting building from scratch
2020-04-03 16:05:29 <oneinsect> i want to reuse the existing alpine APKBUILDs for all packages
2020-04-03 16:05:52 <oneinsect> yes the other way is to use apk/abuild for own LFS
2020-04-03 16:06:27 <oneinsect> but i am loner and i dont have much support, so I want keep everything i can from alpine except rebuilt regularly just the glibc version
2020-04-03 16:08:10 <artok> forking aports and removing all musl stuff.. great!
2020-04-03 16:08:44 <oneinsect> dont hate me, i love alpine and i am forced to do it temporarily for deep learning libraries
2020-04-03 16:08:51 <oneinsect> till they enable musl builds
2020-04-03 16:09:44 <artok> I have docker to run glibc thingies
2020-04-03 16:10:51 <artok> everything that can, is run on alpine based docker images, and then those poor that need glibc, are run on debian buster-slim based images
2020-04-03 16:11:58 <artok> at the moment, only mongodb is run on glibc in my systems (haven't had time to check the patches)
2020-04-03 16:13:14 <maxice8> ncopa: finished adding support on secfixes-check for multiple security identifier types
2020-04-03 16:18:28 <oneinsect> but it artok: it will messy if i have run a few system with both glibc and musl coexisting
2020-04-03 16:18:58 <oneinsect> okie back to the work gcc -static -O3 -o abuild-gzsplit abuild-gzsplit.c -I/usr/include /lib/libz.a /lib/libc.a -lz still has one more dependency
2020-04-03 16:19:06 <oneinsect> lib/ld-musl-x86_64.so.1 (0x7fecd0c52000)
2020-04-03 16:21:25 <oneinsect> dynamic-linker
2020-04-03 16:22:44 <oneinsect> may be patch it to force it against the new interpreter in target
2020-04-03 16:23:29 <oneinsect> patchelf --set-interpreter /lib/ld-new.so.1 abuild-gzsplit
2020-04-03 16:23:30 <artok> you have libz.a and libc.a there? -lc -lz isn't enough ?
2020-04-03 16:24:31 <oneinsect> yes i have both libz.a and libc.a and abuild-gzsplit compiles successfully but it is still a dynamic executable
2020-04-03 16:24:47 <oneinsect> and ldd shows lib/ld-musl-x86_64.so.1 as dependency
2020-04-03 16:26:49 <oneinsect> i mean the resulting binary still lights up ldd
2020-04-03 16:27:43 <oneinsect> aaah understood the issue
2020-04-03 16:28:05 <artok> linking order right?
2020-04-03 16:30:21 <oneinsect> If we pass -no-pie to GCC on Alpine, its binary will not be PIE-enabled just like Ubuntu binary isn't PIE-enabled, but then it will be statically linked as you want
2020-04-03 16:30:21 <oneinsect> gcc -no-pie -static -O3 -o abuild-gzsplit abuild-gzsplit.c -I/usr/include /lib/libz.a
2020-04-03 16:31:30 <oneinsect> thanks artok: maxice8: kaey: Cogitri:
2020-04-03 16:36:12 <Cogitri> 👍
2020-04-03 16:39:49 <artok> actually my question was legit, as I didn't remember what was the order of linking... =)
2020-04-03 16:42:27 <Ariadne> oneinsect: as this work is offtopic, can you take discussion elsewhere
2020-04-03 16:43:00 <oneinsect> yes artok: it was legit, np Ariadne: i will leave now
2020-04-03 16:43:03 <oneinsect> thanks folks!
2020-04-03 16:43:40 <Ariadne> oneinsect: thanks
2020-04-03 17:03:43 <Ariadne> ncopa: Cogitri: so how do you guys think we should bootstrap rust on s390x and mips64
2020-04-03 17:05:32 <Cogitri> Well, we'd first need a cross environment from x86_64 (or any support arch) to those arches
2020-04-03 17:06:21 <Cogitri> Or mips64 glibc to musl
2020-04-03 17:06:44 <Ariadne> also, mips64 is softfloat (because most mips CPUs have various levels of broken FPUs)
2020-04-03 17:06:54 <Cogitri> Ah well, I don't know any mips
2020-04-03 17:07:05 <Ariadne> so i'm not sure if such a bootstrap is viable
2020-04-03 17:07:13 <Ariadne> but i have access to s390x as well
2020-04-03 17:08:23 <Cogitri> I think I have access to a box from tmhoang (sorry that I didn't get to fixing that yet...)
2020-04-03 17:09:59 <markand> quick question, what's the use case of /etc/init.d/udev.orig? looks almost similar to /etc/init.d/udev
2020-04-03 17:10:20 <Cogitri> I guess someone messed up applying a patch
2020-04-03 17:10:34 <Hello71> artok: maybe they didn't configure packages so buildroot built *everything*...
2020-04-03 17:12:10 <Hello71> I guess ncopa didn't realize that make install does cp *
2020-04-03 17:16:53 <Ariadne> Cogitri: how did you generate the current 'boot' tarballs
2020-04-03 17:21:34 <Cogitri> Ariadne: I built them on Void Linux because I could use xbps-src there
2020-04-03 17:22:26 <Ariadne> is it possible to do the same for mips64 and s390x ?
2020-04-03 17:22:39 <Cogitri> (And I added Rust support for more arches on Void too so I happened to know the system somewhat well)
2020-04-03 17:22:45 <Cogitri> No, they don't support mips and s390x
2020-04-03 17:23:00 <Ariadne> bummer
2020-04-03 17:23:17 <Ariadne> guess that means i'll just mask all rust-dependents for the moment
2020-04-03 17:23:30 <Ariadne> we can deal with this in 3.13
2020-04-03 17:24:42 <Cogitri> Probably easiest
2020-04-03 17:26:00 <Cogitri> librsvg is probably the most annoying thing missing
2020-04-03 17:26:08 <Ariadne> yes
2020-04-03 17:27:42 <Ariadne> in reality, most mips devices do not have a gpu so there's no desktop anyway :p
2020-04-03 17:28:55 <dalias> X is a network protocol :-)
2020-04-03 17:35:34 <Ganwell> Cogitri: I try to help with rust, but probably till I understand the bootstrap process you guys have solved it. In the email from ncopa his host was armv7 or is it cross-compile? I currently trying to cross compile armv7 on x86_64, since I don't have access to a fast armv7.
2020-04-03 17:38:04 <Cogitri> You can't really do that on Alpine since Rust also has native (C) dependencies
2020-04-03 17:38:30 <Cogitri> So you'd need to be able to crosscompile C things from x86 to armv7
2020-04-03 17:38:37 <Cogitri> ncopa compiled that on armv7 most probably
2020-04-03 17:42:17 <Ariadne> dalias: yes, but realistically nobody is going to use X on a mips device forwarded along the network
2020-04-03 17:43:00 <Ariadne> Cogitri: it is possible to crosscompile with dabuild
2020-04-03 17:44:08 <Cogitri> Maybe possibly?
2020-04-03 17:44:22 <Cogitri> I think it has some support for binfmt but I never used it
2020-04-03 17:48:15 <Ganwell> Cogitri: Ok, I think I don't understand the problem completely. armv7-alpine-linux-musleabihf is built, at least rustc --print target-list will list it.
2020-04-03 17:48:27 <Hello71> muh wayland
2020-04-03 17:49:08 <SerkanDevel[m]1> Hello
2020-04-03 17:49:22 <dalias> ariadne, that may be true. but also don't forget lemote
2020-04-03 17:49:33 <Cogitri> Hello
2020-04-03 17:49:43 <Cogitri> Ganwell: What don't you understand? Have you read my reply to ncopa's mail=
2020-04-03 17:50:07 <Ganwell> Cogitri: Oh, sorry, no didn't see it.
2020-04-03 17:51:24 <Ganwell> Cogitri: There is an answer to "rust triples (WAS: Re: Planning for 3.12 feature freeze)"? I didn't get it.
2020-04-03 17:51:57 <SerkanDevel[m]1> I'm trying to install sr.ht by building alpine packages and I was referred to this channel from here https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C60bc87e3-3f61-554d-fbc8-1ab2ee3e299c%40gmail.com%3E . I'm running alpine edge on an lxc container on a Reaspberry Pi
2020-04-03 17:52:09 <Cogitri> https://lists.alpinelinux.org/~alpine/devel/%3CkcEE.jwTbMwvuQKKkHR3apIGq6Q.gNaPvrAJ1gE%40srsyg17.sygroup-int.ch%3E#%3C2a1589a885d5f7e81609ed43dee892555379aff6.camel@cogitri.dev%3E
2020-04-03 17:53:20 <Cogitri> SerkanDevel[m]1: Read https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Setup_your_system_and_account
2020-04-03 17:54:37 <Ariadne> dalias: i haven't, that's why the port is softfloat (well that and some octeons also have buggy FPUs)
2020-04-03 17:54:50 <Ariadne> dalias: AFAIK lemote *still* haven't figured out how to make a working FPU
2020-04-03 17:59:55 <SerkanDevel[m]1> I kinda works further in building for me now. Thanks!
2020-04-03 18:00:01 <Ganwell> Cogitri: The mailinglist is strange. It does some magic with CC, when I am in CC I sometimes don't get the message at all.
2020-04-03 18:00:21 <_ikke_> the mailing list has no influence on CC at all
2020-04-03 18:00:29 <Ganwell> Cogitri: Is currently a function armv7-alpine-linux-musleabihf built or not?
2020-04-03 18:00:52 <Ganwell> _ikke_: of course not, I didn't say that
2020-04-03 18:02:25 <SerkanDevel[m]1> But while I'm here, is it a problem that whenever I log into the alpine container as a lesser privilaged user with sudo rights, this error appears
2020-04-03 18:02:25 <SerkanDevel[m]1> sudo: setrlimit(RLIMIT_CORE): Operation not permitted
2020-04-03 18:02:42 <_ikke_> SerkanDevel[m]1: yes, apparently a bug with sudo
2020-04-03 18:02:50 <_ikke_> I heard it's fixed now though
2020-04-03 18:03:03 <Cogitri> Ganwell: We're currently building armv7-unknown-linux-musleabihf
2020-04-03 18:03:17 <_ikke_> SerkanDevel[m]1: https://gitlab.alpinelinux.org/alpine/aports/issues/11122
2020-04-03 18:03:26 <_ikke_> SerkanDevel[m]1: note that it's just a 'warning'
2020-04-03 18:03:27 <Cogitri> So you'd have to compile from that to the right triplet
2020-04-03 18:03:38 <Cogitri> As I've mentioned in the mail, only adjust target and not build on the first run
2020-04-03 18:03:42 <Ganwell> Cogitri: So building armv7-alpine-linux-musleabihf is an objective?
2020-04-03 18:04:45 <Cogitri> Yes
2020-04-03 18:06:20 <SerkanDevel[m]1> Thanks again
2020-04-03 18:06:51 <Cogitri> 👍️
2020-04-03 18:17:46 <Shiz> Cogitri: got no immediate errors for me
2020-04-03 18:18:56 <Cogitri> Hm, weird. I gues my mail server didn't want to resolve it for some reason then. Thanks for the info
2020-04-03 18:27:16 <Ganwell> So one can test other archs via docker/qemu-user-static. I tried a RPi for a while, but the development cycles are soooo long. Not that qemu-user-static is fast.
2020-04-03 22:43:29 <Ganwell> Cogitri: Bootstrapping (mips s390x) via the rustup binaries and gcompat is not possible?
2020-04-03 22:44:53 <Ganwell> ah gcompat does not exist for mips
2020-04-03 22:51:11 <Ganwell> I guess creating -musl using debian would work
2020-04-04 06:40:10 <Cogitri> Ganwell: I doubt gcompat is capable of that
2020-04-04 10:12:16 <Ganwell> Builds with qemu-arm-static seem to freeze after 2h hours :-( Why can't I have a reasonably fast build-system on arm... :-)
2020-04-04 10:35:04 <llnu> Ganwell, would cross compiling on fast hw help?
2020-04-04 10:49:08 <Ganwell> llnu: Yes, but thats difficult on alpine. The kernel is about the only thing you can cross compile. I first though it works for rust, but of course as soon as you have a C dependency it breaks down.
2020-04-04 10:59:12 <llnu> How about using qemu arm emulation?
2020-04-04 11:07:44 <llnu> Ah, those freeze sorry, I though you are trying to build qemu on arm
2020-04-04 11:07:51 <Ganwell> llnu: Currently using https://github.com/multiarch spezifically qemu-arm-static and the rustc build freezes.
2020-04-04 11:08:49 <Ganwell> llnu: Booting an arm VM is an option, but it is much more work.
2020-04-04 11:10:03 <llnu> ill give it a shot
2020-04-04 11:10:31 <llnu> does it matter which arm arch?
2020-04-04 11:11:12 <llnu> i think yes, which one is your target?
2020-04-04 11:19:11 <Ganwell> llnu: QEMU terms it is just 'arm' and in Alpine terms 'armv7'
2020-04-04 11:28:48 <Ganwell> llnu: I wanted to have all the alpine archs, but every arch has different arguments in qemu and different problems.
2020-04-04 11:30:52 <Ganwell> llnu: this might help: https://github.com/tkmru/multiarch_bootstrap/blob/master/launch.sh
2020-04-04 11:32:23 <llnu> im preparing to emulate alpine in armv7
2020-04-04 11:35:09 <Ganwell> llnu: there are few git-repos out there that contain knonwn to work qemu arguments. I know one much more comprehensive than that above
2020-04-04 11:35:41 <Ganwell> llnu: I knew one, don't find it anymore
2020-04-04 11:37:05 <Ganwell> I'm off
2020-04-04 11:37:29 <llnu> no problem, ill figure out something:) o/
2020-04-04 11:41:36 <mps> llnu: not sure I understand what you mean by 'im preparing to emulate alpine in armv7'. Alpine works native on armv7
2020-04-04 11:42:49 <Ganwell> mps: he means booting a alpine armv7 VM on x86_64 using qemu.
2020-04-04 11:42:53 <llnu> yup, i have create a disk first that i can boot
2020-04-04 11:43:31 <llnu> also finally fix my documentation flow that means learning sphinx
2020-04-04 11:44:08 <mps> here is script I use to create arm{hf,v7} on x86_64 http://arvanta.net/~mps/install-arm-under-qemu.sh
2020-04-04 11:44:57 <mps> and short guide for aarch64 http://arvanta.net/~mps/install-aarch64-under-qemu.txt
2020-04-04 11:45:47 <mps> could be useful but do not follow blindly, tweak according your needs
2020-04-04 11:46:41 <llnu> thanks! it will save me quite a few brain cycles:)
2020-04-04 11:47:34 <mps> also here is script to boot armv7 when it is installed http://arvanta.net/~mps/boot-armhf.sh
2020-04-04 12:40:39 <mps> hmm, firefox-esr 68.6.1 failed on CI. is that because we now have llvm10 or something else?
2020-04-04 12:41:18 <Cogitri> Can you send a log?
2020-04-04 12:42:29 <mps> Cogitri: !6209 CI
2020-04-04 12:43:07 <mps> I will try to rebuild on x86_64 3.11-stable with llvm9
2020-04-04 12:43:31 <Cogitri> Don't do that
2020-04-04 12:44:03 <Cogitri> From CI log:
2020-04-04 12:44:07 <Cogitri> > g++: fatal error: Killed signal terminated program cc1plus
2020-04-04 12:44:07 <Cogitri> So it just ran out of memory on Ci
2020-04-04 12:44:16 <Cogitri> LLVM 9 vs 10 isn't going to change that
2020-04-04 12:44:27 <mps> ohm
2020-04-04 12:44:40 <mps> anyway I will try on 3.11-stable
2020-04-04 12:44:54 <Cogitri> Sure, good idea to backport it
2020-04-04 12:44:57 <mps> locally
2020-04-04 12:48:23 <markand> with that confinment I'll be able to provide lots of new packages
2020-04-04 12:49:06 <Cogitri> Huh?
2020-04-04 12:49:29 <markand> Cogitri, in france we're unable to get out, so much more time to spend on my computer ;p
2020-04-04 12:49:44 <Cogitri> Oh, right :P
2020-04-04 12:49:48 <mps> IMO, we should create committee which should judge adding new packages
2020-04-04 12:50:07 <Cogitri> mps: That'll grind Alpine's development speed down to a halt
2020-04-04 12:50:25 <Cogitri> And will lead to us having an AUR
2020-04-04 12:50:38 <markand> like debian? and then people will complain about software which have "offensive" names?
2020-04-04 12:50:41 <markand> like weboob fiasco
2020-04-04 12:50:45 <mps> but will lead to more stable and lean distro
2020-04-04 12:50:54 <markand> that's what review is made for
2020-04-04 12:50:57 <Cogitri> Yes
2020-04-04 12:51:12 <Cogitri> Having a committee which needs to approve packages really doesn't help anyone
2020-04-04 12:51:13 <markand> fortunately the repository is not a wiki, not all people are able to push :)
2020-04-04 12:51:38 <Cogitri> And users are still be best instance to judge if they want a certain package
2020-04-04 12:52:12 <mps> I disagree, but ok
2020-04-04 12:52:22 <Cogitri> There's still no fractal (the matrix client) in Debian because getting packages into Debian is so much effort
2020-04-04 12:53:17 <markand> having a package to be included in debian/fedora requires a Ph.D
2020-04-04 12:53:27 <markand> that's what I like with clean and simple distributions like Alpine
2020-04-04 12:53:34 <Cogitri> We already have a shortage of maintainers (like most OSS projects), so adding yet another instance of bureaucracy in the packaging process isn't going to make that any better
2020-04-04 12:53:42 <mps> we can select one, "small, simple, secure" or second one "opposite of the previous"
2020-04-04 12:53:43 <markand> direct get to work rather than having to pass ten thousands infrastructures
2020-04-04 12:53:54 <Cogitri> markand: Same here (and the package format is really nice)
2020-04-04 12:54:32 <Cogitri> Really, since I'm big on GNOME Fedora would seem like an optimal distro, but the infra and maintaince (and RPM!) is way too much of a pain for that
2020-04-04 12:54:46 <markand> I tried to provide a package to RPMFusion a long time ago and I can tell you that I won't do it again (and it's not even fedora infra)
2020-04-04 12:54:49 <Cogitri> Also, SELinux is a very nice idea but I trip over it every time
2020-04-04 12:55:07 <mps> selinux is bad idea
2020-04-04 12:55:10 <Cogitri> I provide a package of mine as RPM and Deb via OBS and phew that was a pain to get running
2020-04-04 12:55:24 <Cogitri> SELinux is an amazing idea, but getting the rules right is basically impossible
2020-04-04 12:56:26 <mps> about ten (or more years ago) I backported selinux in debian, a loot of work but not much gain
2020-04-04 12:57:07 <mps> imo, apparmor is better, but I'm not sure if it also deserve to be enabled by default
2020-04-04 12:57:24 <Cogitri> AppArmor is pretty nice, I don't see why we wouldn't have it enabled
2020-04-04 12:58:21 <mps> "we" have suid bit in /usr/bin/Xorg and we talk about selinux and apparmor :D
2020-04-04 12:58:56 <markand> that's quite common AFAIK
2020-04-04 12:59:16 <mps> :-]
2020-04-04 13:00:08 <Cogitri> Well, granting users full access to input, video and audio devices doesn't seem more secure to me
2020-04-04 13:00:32 <Cogitri> So if you want Xorg to be more secure we should go ahead and enable elogind support in it
2020-04-04 13:01:14 <markand> FreeBSD uses setuid by default on it too
2020-04-04 13:01:15 <mps> oh, you advice me to use gnome :)
2020-04-04 13:01:42 <Cogitri> elogind != gnome, but oh well
2020-04-04 13:02:09 <Hello71> mUh bLoAt
2020-04-04 13:02:57 <mps> Cogitri: does elogind prevent user access to input (or video)
2020-04-04 13:07:01 <_ikke_> maxice8: netcdf is failing on s390x
2020-04-04 13:09:49 <Cogitri> mps: Yes, with elogind you don't need those permissions on the user since elogind handles that for you
2020-04-04 13:11:53 <mps> but? user get access to input when s/he logs in?
2020-04-04 13:13:27 <Cogitri> I'm not sure how it works internally in Xorg
2020-04-04 13:16:00 <_ikke_> FYI: in 15 minutes I'm going to upgrade gitlab to the next major version (12.8)
2020-04-04 13:18:34 <Cogitri> 
ACTION quickly finishes reviews

2020-04-04 13:35:08 <_ikke_> Upgrade is succesful, we're now running Gitlab 12.8
2020-04-04 13:35:21 <_ikke_> Let me know if you encounter issues
2020-04-04 13:40:20 <timlegge> @Cogitri: I removed the package with the failing test for now from !6256 all green will look further
2020-04-04 13:40:47 <Cogitri> Okie :)
2020-04-04 14:29:39 <minecrell> maxice8: I think you need to rebuild packages using glew after https://gitlab.alpinelinux.org/alpine/aports/-/commit/3c0bd084c750b09ea3a6bd298e965b84c477be20
2020-04-04 14:29:42 <minecrell> soname seems to have changed
2020-04-04 14:37:37 <dsmster> is is normal for 'apk add linux-firmware' to throw so many errors on rpi-aarch64 systems?   Looks like it installed a subset but threw hundreds of error lines verbosely
2020-04-04 14:58:09 <Cogitri> ikke: https://gitlab.alpinelinux.org/a16bitsysop/aports
2020-04-04 15:22:39 <newalpineuser> Hi, are there any plans/ongoing work for porting any vncserver (vnc4server, tightvnc) to alpine?
2020-04-04 15:31:34 <Hello71> xorg requests necessary fds from logind, logind opens and transfers over unix socket with SCM_RIGHTS
2020-04-04 16:32:14 <_ikke_> Cogitri: interesting, that one is not forked from alpine/aports
2020-04-04 16:35:09 <Cogitri> Oh, I guess the user cloned the repo and then created a new repo and pushed to that?
2020-04-04 16:35:18 <Cogitri> ...but how can they create a MR then?
2020-04-04 16:37:42 <_ikke_> I don't think they can
2020-04-04 16:38:49 <Cogitri> Huh
2020-04-04 16:40:01 <_ikke_> Not like that
2020-04-04 16:40:29 <timlegge> !6261 fixes earlier issue modernizing perl-anyevent-i3 had to disable 2 tests as they appear to fail related to the aports builders - the module locally clears ENV and the -T flag highlights an insecure path
2020-04-04 16:40:53 <timlegge> works file locally thoug
2020-04-04 16:41:18 <timlegge> not sure if there is anything else to do with it
2020-04-04 16:55:24 <maxice8> @minecrell working on it, sorry i missed it
2020-04-04 17:03:19 <maxice8> ikke: will look after i'm done working on the libGLEW.so.2.2 rebuilds
2020-04-04 18:18:16 <minecrell> maxice8: Thanks, seems to be fine now :)
2020-04-04 19:49:51 <maxice8> @minecrell good good, i had to disable a package that wasn't building and a package on armhf that needs qt5-declarative
2020-04-04 19:50:15 <maxice8> Opinions on !6271 , or is it too opaque ?
2020-04-04 21:39:22 <llnu> thank you mps, i've managed to boot an arm alpine on x86:)
2020-04-04 21:41:07 <mps> llnu: you are welcome :)
2020-04-04 23:10:05 <fcolista2> has anyone a working example on how to use ipset in awall?
2020-04-04 23:10:17 <fcolista2> I couldn't find any
2020-04-05 08:32:09 <Cogitri> ikke: https://gitlab.alpinelinux.org/a16bitsysop/aports This time it's forked but it's still internal
2020-04-05 09:27:12 <markand> I have a software which hasn't a real license except terms "Non commercial"
2020-04-05 09:27:25 <markand> what should I put into license field? there are no "custom" SPDX identifier
2020-04-05 09:29:10 <markand> I guess it's custom according to a grep -R
2020-04-05 11:33:30 <_ikke_> Cogitri: fixed
2020-04-05 11:38:44 <Cogitri> Thanks
2020-04-05 16:05:20 <timlegge> ping !6317
2020-04-05 17:43:42 <maxice8> !6271
2020-04-05 17:43:59 <maxice8> algitbot: you ok ? you're missing the title
2020-04-05 17:44:09 <maxice8> 6271 is main/meson: add opinionated helper for Alpine Linux packaging
2020-04-05 17:44:11 <maxice8> @mps ^
2020-04-05 17:45:06 <mps> maxice8: ?
2020-04-05 17:45:23 <maxice8> i want people to review that
2020-04-05 17:45:50 <mps> !6271 ?
2020-04-05 17:47:16 <mps> hmm, reading
2020-04-05 17:48:34 <Hello71> mps: !6271
2020-04-05 17:48:38 <Hello71> hm
2020-04-05 17:50:32 <mps> I don't have strong opinion about that, especially because I'm novice to meson build
2020-04-05 17:52:17 <maxice8> I'm asking more about the acceptance of hiding lots of switches behind a binary that the users must look at to see what is really going on
2020-04-05 17:52:43 <Cogitri> But in return we don't need to repeat these every time
2020-04-05 17:53:09 <Cogitri> (And it's a little tiring noting that in every other review because the contributor didn't know about newapkbuild)
2020-04-05 17:53:22 <mps> oh, this. then I'm not sure it is a good idea, but again I don't know
2020-04-05 17:55:36 <mps> can these defaults be overridden in APKBUILD
2020-04-05 17:55:41 <maxice8> yes
2020-04-05 17:56:07 <maxice8> passing the same switch later overrides the first time it was passed
2020-04-05 17:56:15 <mps> this is good
2020-04-05 17:56:45 <maxice8> i already know a case where we want to disable LTO, mesa
2020-04-05 17:57:38 <mps> yes
2020-04-05 18:24:25 <TBK[m]> hmmm empty mr, that is a first for me !6331
2020-04-05 18:38:20 <Cogitri> Ah, you can do that with mkmr if you forget to push
2020-04-05 19:08:46 <Ariadne> PureTryOut[m]: any objection to making KDE use double-click for item activation by default instead of single-click?
2020-04-05 19:09:13 <Ariadne> (i think it would be nice to make our KDE behave like every other desktop we ship)
2020-04-05 19:32:27 <Cogitri> I think it'd make sense to stick with whatever upstream says
2020-04-05 19:47:49 <Ariadne> Cogitri: the configuration breaks apps which use semantic signals (as the Qt docs say to do)
2020-04-05 19:55:17 <mps> hmm, ncurses 6.1-20200118 which is in 3.11-stable,  disappeared from source url
2020-04-05 19:55:29 <maxice8> that is an oof
2020-04-05 19:56:27 <mps> should we find exact version somewhere or upgrade to next available release there?
2020-04-05 19:56:28 <maxice8> i can upload to dev.a.o and switch the link to there ? can you confirm it really disappeared
2020-04-05 19:56:36 <maxice8> i have in my /var/cache/distfiles
2020-04-05 19:56:51 <mps> look there https://invisible-mirror.net/archives/ncurses/current/
2020-04-05 19:57:11 <mps> also I think that I have it in cache
2020-04-05 19:58:34 <mps> but I think it is safe to use https://invisible-mirror.net/archives/ncurses/current/ncurses-6.2-20200212.tgz version
2020-04-05 19:58:34 <maxice8> @ikke i'm getting permission denied while trying to upload there
2020-04-05 19:58:58 <maxice8> $ scp /var/cache/distfiles/ncurses-6.1-20200118.tgz maxice8@git.alpinelinux.org:/var/www/localhost/htdocs/archive/ncurses
2020-04-05 19:58:58 <maxice8> scp: /var/www/localhost/htdocs/archive/ncurses/ncurses-6.1-20200118.tgz: Permission denied
2020-04-05 19:59:31 <mps> and, maybe it is good idea to put old version for stables on dev.a.o
2020-04-05 20:00:26 <mps> maxice8: I'm working to fix missing vtXXX terminfos in 3.11-stable
2020-04-05 20:05:29 <_ikke_> maxice8: let met check
2020-04-05 20:07:12 <_ikke_> mps: try again
2020-04-05 20:07:15 <_ikke_> maxice8: *
2020-04-05 20:08:57 <maxice8> Am playing krapo
2020-04-05 20:31:24 <maxice8> @ikke done, thanks
2020-04-05 20:31:49 <maxice8> @mps you can use https://dev.alpinelinux.org/archive/ncurses/ncurses-6.1-20200118.tgz
2020-04-05 20:33:16 <maxice8> secfixes-check from atools now ignores everything inside parentheses
2020-04-05 20:33:17 <maxice8> so you can do #    - CVE-2020-1000 (Not affected)
2020-04-05 20:34:40 <PureTryOut[m]> Ariadne: well I personally always set it to double-click so in that sense no, but I do agree with Cogitri that it makes sense to stick to upstream
2020-04-05 20:35:13 <Ariadne> PureTryOut[m]: i wonder if it makes sense to have an alpine-kde-theme package that overrides it
2020-04-05 20:35:29 <Ariadne> that way, if you want pure upstream behaviour, just don't install the theme
2020-04-05 20:35:45 <PureTryOut[m]> Yeah sure that'd work
2020-04-05 20:36:26 <mps> maxice8: thanks
2020-04-05 20:37:02 <mps> but tomorrow, I'm preparing for sleep
2020-04-05 20:37:26 <mps> I mean, I will work on this tommorow
2020-04-05 20:39:54 <Ariadne> PureTryOut[m]: i am of the opinion that the "next generation" alpine desktop should be KDE-based with certain features defanged by default
2020-04-05 20:43:27 <PureTryOut[m]> Lol guess you'll not get many people to agree with you there, but sounds cool
2020-04-05 20:43:41 <PureTryOut[m]> There is a big issue with KDE Plasma on Alpine though where no keyboard shortcuts work on Wayland
2020-04-05 20:45:03 <maxice8> mps: thank ikke :D wouldn't be able to put it there without him doing whatever what was needed (fix permissions probably ?)
2020-04-05 20:45:35 <_ikke_> yup
2020-04-05 20:46:45 <mps> thanks both :)
2020-04-05 21:05:37 <Ariadne> PureTryOut[m]: there is issues with KDE plasma on wayland in general
2020-04-05 23:06:42 <c705> fcolista: hey, for issue #11361 you can ping me here if you need more information or qa assistance
2020-04-06 06:09:32 <coredumb> d
2020-04-06 06:22:27 <_ikke_> coredumb: I completely agree
2020-04-06 06:23:57 <Cogitri> lol
2020-04-06 07:13:10 <PureTryOut[m]> Ariadne: sure, but the hotkey one I mentioned is specific to Alpine
2020-04-06 07:15:54 <clandmeter> _ikke_: woke up early? :p
2020-04-06 07:16:40 <_ikke_> Quite :-)
2020-04-06 08:57:40 <Shiz> sorry for the long email :)
2020-04-06 09:00:14 <Cogitri> No worries, it's interesting
2020-04-06 09:00:24 <Cogitri> But while I do agree with some of your arguments I still think it's better to roll with what other distros have been doing for years now
2020-04-06 09:01:02 <Cogitri> I think being technically correct doesn't justify the amount of confusion we'll create with this for users
2020-04-06 09:06:09 <Shiz> I'm a bit unconvinced that it should create issues at all if proper symlinks are in place
2020-04-06 09:06:47 <mps> why any subdir, use flat FS :)
2020-04-06 09:06:56 <Shiz> mps: DOS 1.0!
2020-04-06 09:07:10 <Shiz> fun fact: this is why you still can't create directories called 'con' on any place in the FS in modern Windows ;)
2020-04-06 09:07:17 <oneinsect> i used to love dos
2020-04-06 09:07:41 <oneinsect> was running on my first 386 machine
2020-04-06 09:07:49 <Shiz> once created a directory for some convention directories from my Linux box on a fat32 thumbdrive
2020-04-06 09:08:01 <Shiz> imagine my surprise when I couldn't access the con directory from the on-site Windows box
2020-04-06 09:08:05 <Shiz> some convention videos*
2020-04-06 09:08:11 <mps> CP/M
2020-04-06 12:31:09 <markand> honestly I never understood why the FHS didn't change
2020-04-06 12:31:30 <markand> it looks like people want to keep old things for historical reasons
2020-04-06 12:33:15 <mps> how goes famous saying: those who don't understand unix are condemned to reinvent it, badly
2020-04-06 12:36:48 <markand> there was a time when /usr was needed
2020-04-06 12:36:59 <markand> when UNIX gods didn't have enough space for /
2020-04-06 12:37:42 <markand> now it's pretty archaic choice to separate /usr from /
2020-04-06 12:37:54 <markand> so nothing to reinvent, just simplification
2020-04-06 12:38:57 <markand> UNIX is far from perfect, even their creators stated that when they designed plan 9.
2020-04-06 12:39:44 <mps> ah, yes. and plan 9 superseded unix :D
2020-04-06 12:40:40 <mps> of all OSes only unix is nearly perfect
2020-04-06 12:41:26 <markand> yes
2020-04-06 12:42:23 <TBB> some old school vms guys would raise an eyebrow at that statement
2020-04-06 12:42:51 <mps> :)
2020-04-06 12:43:20 <TBB> I never really tried plan 9, but if I understand correctly they basically just took "everything is a file" a lot more seriously?
2020-04-06 12:43:47 <mps> well, mostly this, I would say
2020-04-06 12:45:50 <markand> yes
2020-04-06 12:46:07 <markand> like you can literally move your mouse pointer by just echo'ing to character devices
2020-04-06 13:33:41 <Shiz> there's a lot to criticize about unix
2020-04-06 13:33:45 <Shiz> and plan 9 for that natter :)
2020-04-06 13:35:09 <timlegge> ping !6360
2020-04-06 13:43:14 <AinNero> re: the /usr discussion, sabotage linux also did have /usr being a symlink to /
2020-04-06 13:43:32 <AinNero> i tried that too, with an own distro
2020-04-06 13:43:37 <AinNero> and ran into the same issues as markand
2020-04-06 13:43:56 <AinNero> many build script cant differentiate between prefix empty and no prefix configured
2020-04-06 13:44:20 <AinNero> so you get surprise references into /usr and /usr/local
2020-04-06 13:45:30 <Shiz> good old empty string vs null problem
2020-04-06 13:46:32 <afontain_> to be fair, it's easy to make a mistake in a shell script
2020-04-06 13:46:55 <afontain_> I learned to do [ -z "$var" ]
2020-04-06 13:47:26 <afontain_> (then I saw some code generated by GNU auto-something)
2020-04-06 15:22:07 <maxice8> good to see that usrmerge is getting more approval, one day /{bin,sbin} and /lib will be fully in /usr
2020-04-06 15:26:21 <mps> maxice8: no, in '/', or C: D: E: :)
2020-04-06 15:28:44 <maxice8> mps: so moving /usr to / ?
2020-04-06 15:29:35 <mps> yes, FFS, i.e. Flat File System
2020-04-06 15:31:56 <mps> unix is much older (and quite sucsessful) than most of those who want to reinvent it
2020-04-06 15:32:43 <maxice8> so instead of linking /bin /sbin to /usr/bin and /usr/sbin and /lib to /usr/lib you're gonna link the result of $(ls -1 -d /usr/*) into /
2020-04-06 15:33:19 <mps> :)
2020-04-06 15:33:39 <maxice8> i must be missing something
2020-04-06 15:33:48 <mps> maxice8: sorry, I just kidding. hoped that you noticed that
2020-04-06 15:34:37 <mps> sorry again
2020-04-06 15:36:15 <zfoo> the way I've seen it is /usr linked to /, not all the content of /usr
2020-04-06 15:37:05 <maxice8> so mv /usr/* / && rmdir /usr && ln -s  /usr ../ ?
2020-04-06 15:38:41 <zfoo> cd /; ln -s . /usr
2020-04-06 15:44:07 <zfoo> that seems to be common for the toolchains and rootfs produced by buildroot and factory, maybe its just popular within the embedded space
2020-04-06 15:44:38 <maxice8> it is, all distros that do usrmerge do it as merge into usr
2020-04-06 15:51:53 <AinNero> except sabotage linux and whatever i and markand did
2020-04-06 17:06:07 <Ariadne> PureTryOut[m]: weird :)
2020-04-06 17:06:32 <oneinsect> quick help there is full entry written in /lib/apk/db/installed along with /etc/apk/world when apk installs a package. Do you guys have any sample from real life where they are multiple p, F and R fields within the same package?
2020-04-06 17:08:16 <oneinsect> the fields are from here https://wiki.alpinelinux.org/wiki/Apk_spec
2020-04-06 17:09:31 <oneinsect> just want to understand if a package contain multiple .so files, is it populated in p (Package Provides) or some other field
2020-04-06 17:10:10 <Ariadne> yes in provides
2020-04-06 17:10:51 <oneinsect> what about R (Get File ) field?
2020-04-06 17:11:11 <oneinsect> what does it mean?
2020-04-06 17:13:07 <oneinsect> in some packages R lists binaries and some packages it lists files this R:libacl.so.1.1.2253
2020-04-06 17:13:14 <oneinsect> any clarity will help
2020-04-06 17:14:07 <oneinsect> there is no documentation anywhere on this
2020-04-06 17:22:51 <Ariadne> R is just a filename or directory
2020-04-06 17:23:16 <oneinsect> why have it when p already mentions it
2020-04-06 17:23:26 <oneinsect> whats the idea?
2020-04-06 17:24:58 <oneinsect> if you have full installation of alpine kindly check /lib/apk/db/installed file especially the entries for say P:sudo or P:binutils
2020-04-06 17:26:01 <oneinsect> compare the contents in the p (small p) and R fields
2020-04-06 17:26:04 <oneinsect> they seem to repeat
2020-04-06 17:51:02 <_ikke_> maxice8: nice, latest version of apenwarr-redo has python3 support
2020-04-06 17:51:10 <maxice8> nice
2020-04-06 17:51:19 <maxice8> i'll delete my redo-c then
2020-04-06 17:54:26 <_ikke_> building it now, see if the test suite succeeds
2020-04-06 17:56:01 <_ikke_> still some references to `python`
2020-04-06 18:01:59 <maxice8> Speaking of whixhr
2020-04-06 18:02:00 <maxice8> Which*
2020-04-06 18:02:17 <maxice8> I made some MRs to make Python3 provide the python binary and python and python-dev names
2020-04-06 18:02:51 <_ikke_> 3aha, ok
2020-04-06 18:05:04 <maxice8> Idk if we should just get rid of the provides altogether and force people to explicitly pick the version
2020-04-06 18:07:19 <Shiz> clarified my perspective on the possble merge on the ML, fwiw :)
2020-04-06 18:10:19 <Shiz> oneinsect: p doesn't already mention it, per se
2020-04-06 18:10:28 <Shiz> p lists special provides that are injected by abuild at build-time
2020-04-06 18:10:38 <Shiz> you can insstall a package by specifying its provides instead of its name
2020-04-06 18:10:49 <Shiz> e.g. `apk add cmd:dig` will add bind-tools, as it has `p:cmd:dig`
2020-04-06 18:10:59 <oneinsect> aha
2020-04-06 18:11:04 <Shiz> but these are relatively freeform
2020-04-06 18:11:07 <Shiz> while R is absolutely files
2020-04-06 18:11:50 <oneinsect> R is like absolute file or does it also include so names?
2020-04-06 18:12:03 <Shiz> i believe it is just the file name and nothing more
2020-04-06 18:12:08 <oneinsect> thanks!
2020-04-06 18:12:10 <Shiz> it aso includes filenames of .so files, but not sonames :)
2020-04-06 18:12:34 <Shiz> I also don't think R: entries are added for say, APKINDEX.tar.gz
2020-04-06 18:12:38 <Shiz> because of file size bloat
2020-04-06 18:12:49 <Shiz> while p: entries are (allowing you to install something using them)
2020-04-06 18:13:16 <mps> I'm not sure I understand this '/' and '/usr' symlink idea. does it mean path to ls will be'/ls'
2020-04-06 18:13:30 <maxice8> no
2020-04-06 18:13:43 <maxice8> if Shiz proposal passes, it will be /bin/ls
2020-04-06 18:13:57 <maxice8> and /usr/bin will point to /bin
2020-04-06 18:13:57 <Shiz> for ls to be in /ls it would have to be in /usr/ls
2020-04-06 18:13:59 <Shiz> :P
2020-04-06 18:14:10 <Shiz> but yes, there's two says this can go, if it passes at all
2020-04-06 18:14:31 <Shiz> we either merge /{bin,sbin,lib}(,boot?) into /usr or we merge /usr into /
2020-04-06 18:14:43 <oneinsect> i have question then, abuild when packaging seems to search for sonames like libc.so.6 which point -> libc-2.31.so
2020-04-06 18:14:43 <oneinsect>  and only include them in the p and R fields does it move ahead with packing apks without errors
2020-04-06 18:14:51 <maxice8> I want the Void way
2020-04-06 18:15:01 <oneinsect> only if I include them*
2020-04-06 18:15:08 <oneinsect> otherwise it says  Could not find owner package
2020-04-06 18:15:19 <Shiz> you using abuild for glibc stuff? :P
2020-04-06 18:15:19 <maxice8> /bin -> /usr/bin /sbin -> /usr/sbin /usr/sbin -> /usr/bin, /lib -> /usr/lib
2020-04-06 18:15:34 <oneinsect> how come abuild is searching for sonames with the library doesnt support it?
2020-04-06 18:15:36 <oneinsect> yes
2020-04-06 18:15:42 <oneinsect> i mean its the same even with musl
2020-04-06 18:15:45 <mps> maxice8: aha, I see
2020-04-06 18:15:49 <maxice8> Was one of the nice things of Void, they didn't need to fiddle around with it and just choose a path that worked
2020-04-06 18:16:05 <Shiz> (just curious, that's all)
2020-04-06 18:16:15 <oneinsect> when the apk library/db doesnt support it
2020-04-06 18:16:18 <Shiz> maxice8: honestly i think it will go the same whatever we choose
2020-04-06 18:16:23 <Shiz> the symlinks will be there in place anyway
2020-04-06 18:16:26 <Shiz> things should JustWork
2020-04-06 18:16:31 <Shiz> (aside from apk upgrade hardships)
2020-04-06 18:16:53 <maxice8> they said shouldwork for samurai<->ninja too and we needed a few releases to sort it out
2020-04-06 18:16:56 <mps> then why symlinks, isn't move better then
2020-04-06 18:17:03 <maxice8> with Void proposal we also have the fixing prowess of every other distro out there
2020-04-06 18:17:07 <Shiz> mps: it's the same thing
2020-04-06 18:17:16 <oneinsect> so sonames are required to be included in the apk database then
2020-04-06 18:17:20 <Shiz> you're gonna want to keep symlinks either way
2020-04-06 18:17:21 <oneinsect> in the R field
2020-04-06 18:17:34 <Shiz> oneinsect: not sure about R, but it's def needed in p for the dependency scanning
2020-04-06 18:17:43 <oneinsect> even sonames????
2020-04-06 18:17:52 <oneinsect> in p?
2020-04-06 18:17:54 <Shiz> p only lists sonames
2020-04-06 18:17:56 <Shiz> :P
2020-04-06 18:17:58 <Shiz> and cmds
2020-04-06 18:18:05 <oneinsect> there you go!!!!
2020-04-06 18:18:05 <Shiz> (or it should, anyway)
2020-04-06 18:18:13 <oneinsect> this should be documented somewhere please
2020-04-06 18:18:15 <mps> Shiz: well, then my vote goes to 'keep current' option
2020-04-06 18:18:18 <oneinsect> i beg you guys
2020-04-06 18:18:47 <Shiz> oh there's also pkgconfig
2020-04-06 18:19:06 <Shiz> oneinsect: https://github.com/alpinelinux/abuild/blob/master/abuild.in#L1371-L1384
2020-04-06 18:19:14 <Shiz> these are the automatically-inferred provides by abuild
2020-04-06 18:19:17 <maxice8> @mps it will certainly be for at least 3.12 and quite possibly 3.13
2020-04-06 18:19:19 <Shiz> cmd:, so: and pc: (pkg-config)
2020-04-06 18:19:28 <Shiz> maxice8: how do you figure?
2020-04-06 18:19:35 <Shiz> I on't think anyone on the core team has even weighed in yet :)
2020-04-06 18:19:39 <Shiz> don't*
2020-04-06 18:20:02 <mps> good, then I don't have to leave alpine for another release cycle :)
2020-04-06 18:20:22 <Shiz> very fatalist
2020-04-06 18:20:30 <Shiz> how come?
2020-04-06 18:20:57 <mps> I don't see what we will achieve with that change
2020-04-06 18:21:32 <mps> to be like other distros?
2020-04-06 18:21:37 <maxice8> @Shiz we are on the edge of 3.12 feature freeze  plus this /->/usr or /usr->/ is gonna be a doozy
2020-04-06 18:22:34 <Shiz> maxice8: ah, i interpreted that as 'it will be in 3.12 or 3.13 for sure'
2020-04-06 18:22:36 <Shiz> my bad
2020-04-06 18:22:45 <Shiz> mps: from my perspective, /usr is a deprecated artifact
2020-04-06 18:23:23 <mps> but we need /bin and /sbin, and /boot
2020-04-06 18:23:24 <maxice8> @Shiz, no i typoed, i meant it will certainly not be
2020-04-06 18:23:25 <maxice8> my bad
2020-04-06 18:23:55 <Shiz> mps: sure, and they're not going anywhere in either proposal
2020-04-06 18:24:04 <Shiz> they'd either be symlinks to /usr/bin or /usr/sbin or vice-versa :)
2020-04-06 18:24:18 <mps> iiuc, all from /usr/lib will go to /lib
2020-04-06 18:24:27 <maxice8> with Shiz's proposal yes
2020-04-06 18:24:42 <maxice8> with Void all /lib will go to /usr/lib
2020-04-06 18:24:52 <mps> Shizs proposal looks most sane to me
2020-04-06 18:25:38 <mps> and we will need /local dir
2020-04-06 18:25:54 <maxice8> and all dirs that are /usr-specific in / as well
2020-04-06 18:26:04 <mps> yes
2020-04-06 18:26:15 <Shiz> /libexec, /local, /share and /$triple
2020-04-06 18:26:16 <maxice8> so /include /share /local /libexec /x86_64-alpine-linux-musl
2020-04-06 18:26:23 <Shiz> ah yes include too
2020-04-06 18:30:21 <mps> so, most users will do 'ln -s / /usr'
2020-04-06 18:30:39 <maxice8> We should find a way to automate it
2020-04-06 18:33:13 <oneinsect> but why change everything that works?
2020-04-06 18:33:24 <oneinsect> and break unknown things in future?
2020-04-06 18:34:35 <oneinsect> and Shiz: only p with sonames is enough to find package dependencies by abuild and R is more attributes and checksum per file
2020-04-06 18:34:45 <oneinsect> thanks
2020-04-06 18:35:39 <andypost[m]> Hi, any idea why builders do rebuild of testing/proftpd 1.3.7_rc3-r0 every commit?
2020-04-06 18:36:15 <maxice8> Does the new version appear in the repos ?
2020-04-06 18:37:36 <zfoo> abuild doesn't like a pkgver of '2020-01-22', any way around that?
2020-04-06 18:37:59 <maxice8> 20200122 ?
2020-04-06 18:38:04 <Shiz> ^
2020-04-06 18:38:08 <Shiz> that's the common way we approach it
2020-04-06 18:38:15 <Shiz> maybe something like
2020-04-06 18:38:20 <Shiz> _pkgver="2020-01-22"
2020-04-06 18:38:35 <Shiz> pkgver="$(echo $_pkgver | tr -d -)"
2020-04-06 18:38:41 <Shiz> in your apkbuild
2020-04-06 18:38:44 <maxice8> ${pkgver//-/}
2020-04-06 18:38:50 <maxice8> _pkgver*
2020-04-06 18:38:55 <Shiz> or that, depending on how portable you want to be :P
2020-04-06 18:39:02 <mps> oneinsect: good point about 'everything that works'
2020-04-06 18:39:04 <Shiz> i'm used to not using sh extensions at all
2020-04-06 18:39:04 <zfoo> got it, thanks!
2020-04-06 18:39:44 <maxice8> it is in the CODINGSTYLE
2020-04-06 18:40:03 <oneinsect> it will be massive undertaking if things go south which so many patches, commits, new MRs, issues
2020-04-06 18:40:15 <oneinsect> already you guys are burdened, why take more
2020-04-06 18:40:44 <Cogitri> This ^
2020-04-06 18:40:56 <oneinsect> you can spend that energy on improving others important aspects
2020-04-06 18:41:05 <Cogitri> A lot of work, user confusion downstream patches just to be "correct"
2020-04-06 18:41:33 <mps> or 'to be modern' :)
2020-04-06 18:42:23 <oneinsect> may be test it thoroughly with all packages first by giving it to users - choose some testers, noobs like us
2020-04-06 18:42:26 <oneinsect> :D
2020-04-06 18:42:32 <oneinsect> before*
2020-04-06 18:44:10 <maxice8> Because there were actual issues raised by upstreams choosing the "wrong paths" for binaries and having it all in sync with the other distros and what upstream expects will prevent that issue for rising again and wasting developer time
2020-04-06 18:44:35 <oneinsect> oooh correct point
2020-04-06 18:45:14 <oneinsect> have separate alpha releases - distinct from the one of mainstream alpine and slowly let this correct path alpine take over
2020-04-06 18:45:30 <Cogitri> That's what edge is for
2020-04-06 18:45:36 <oneinsect> just my 2 cents, you guys are better judges of things, just unburden yourself less
2020-04-06 18:45:49 <maxice8> Edge Tags snapshots from time to time
2020-04-06 18:46:03 <Cogitri> And if we want to do what upstreams usually expect the answer is to move from / to /usr not the other way around
2020-04-06 18:55:56 <[[sroracle]]> if you were to do what upstreams usually expect the answer would be to use glibc, not musl :p
2020-04-06 18:56:04 <[[sroracle]]> etc etc
2020-04-06 18:56:31 <maxice8> @[[soracle]] you don't need to do everything that upstreams expect
2020-04-06 18:56:34 <oneinsect> but glibc is a bad choice, just the whole experience has been very bad
2020-04-06 18:56:49 <oneinsect> musl the compilation and builds are so straight-forward
2020-04-06 18:56:59 <Cogitri> But we don't need to make our lives harder than we need to, eh?
2020-04-06 18:57:01 <oneinsect> this is what i have learnt
2020-04-06 18:57:27 <maxice8> but if you can reduce the problems caused by upstream picking without sacrificing Alpine core ideas like usage of musl, why not ?
2020-04-06 18:57:27 <[[sroracle]]> Right, it's just a weak argument. You do things based on if they're correct and good, not "everyone else is doing it"
2020-04-06 18:57:36 <[[sroracle]]> bbl
2020-04-06 18:58:16 <maxice8> the argument is "developer time is being wasted, we can invest in this so we don't waste it anymore fighting against the people we package software from, while not compromising on stuff that makes us a unique distro"
2020-04-06 18:59:36 <maxice8> having split-usr is not a core ideal of Alpine Linux (i would hope), but using musl for its smaller ram footprint, ability to truly statically link, compliance to correctness and standards is something we are willing to waste developer time on fighting against upstreams that assume linux == glibc
2020-04-06 19:31:34 <oneinsect> any idea on how time it takes to compile all the 1600 odd packages in main of aports? what configuration is preferred? ram?
2020-04-06 19:31:57 <oneinsect> 10 packages almost took 30 minutes for me
2020-04-06 19:39:01 <oneinsect> one more question do you guys run abuild -v check after abuild -v build? I mean are the current builds test every package and only bundle if they pass all tests?
2020-04-06 19:39:07 <oneinsect> how is it that you guys do?
2020-04-06 19:40:13 <oneinsect> tested on every package* and only bundled*
2020-04-06 19:46:45 <Cogitri> The time required for building very much depends on your rig
2020-04-06 19:47:07 <Cogitri> And how much RAM you need very much depends on how many build jobs you use (so how many threads you have)
2020-04-06 19:48:00 <Cogitri> I'd say 16-32 threads would be the minimum, paired with at least 32GB RAM (but then you'll need to decrease the buildjobs for stuff like Chromium, so I'd prefer 64GB RAM)
2020-04-06 19:48:15 <Cogitri> Then building everything will probably "only" take a week or so
2020-04-06 19:52:29 <Hello71> chromium builds fine in 16 even with -j6 and lto
2020-04-06 19:52:34 <Hello71> ... gdb
2020-04-06 19:52:38 <Hello71> fuck. GB
2020-04-06 19:53:28 <Cogitri> I needed to upgrade to 64GB of RAM to build it with 33 build jobs with the default options that are set in the APKBUILD
2020-04-06 19:53:32 <oneinsect> holy .... a week!!! how are you guys managing
2020-04-06 19:53:46 <Hello71> if you use tmpfs then more
2020-04-06 19:53:56 <Hello71> just unpacking it is like 3 GB or something
2020-04-06 19:54:01 <Cogitri> oneinsect: About checks: We always run checks unless they're disabled in the APKBUILD via options="!check"
2020-04-06 19:54:26 <oneinsect> what if one of those checks fail?
2020-04-06 19:54:33 <oneinsect> will you still continue to build?
2020-04-06 19:54:55 <Cogitri> oneinsect: Well, we don't start from 0 very often (only every 6 months with a new release), so it's not a huge problem. Also, our builders are pretty powerful so they may only need like 2~5 days
2020-04-06 19:55:11 <Cogitri> No, if checks fail the build fails, that's the point of them
2020-04-06 19:55:32 <Cogitri> If the tests fail then something in the package needs fixing probably
2020-04-06 19:56:35 <oneinsect> i mean the builds are successful in spite of missing some tests (failed)
2020-04-06 19:57:13 <Cogitri> Doesn't matter, if the test fail the entire build fails
2020-04-06 19:57:15 <oneinsect> also i had 100 numbers of xeon phi 64 core socket cpus, sold some 30 on ebay for cheap, dont know what to do with the rest, the intel motherboards arent available
2020-04-06 19:57:28 <oneinsect> ummmm
2020-04-06 19:58:18 <oneinsect> it is the check() first then and later build()?
2020-04-06 19:58:23 <oneinsect> or build and then check
2020-04-06 19:59:11 <Cogitri> We need to build() first because what would we run the checks against otherwise? :)
2020-04-06 19:59:20 <oneinsect> okie
2020-04-06 20:05:22 <_ikke_> I wonder whether it makes sense to run the >1h test_asyncio tests for python
2020-04-06 20:05:32 <_ikke_> 1:57:01 load avg: 0.01 running: test_asyncio (1 hour 56 min)
2020-04-06 20:05:36 <_ikke_> almost 2h
2020-04-06 20:10:38 <_ikke_> k
2020-04-06 20:10:40 <_ikke_>  
2020-04-06 20:10:42 <_ikke_>  
2020-04-06 20:10:52 <clandmeter> i totally agree
2020-04-06 20:11:00 <oneinsect> yes
2020-04-06 20:11:13 <_ikke_>  heh
2020-04-06 20:11:14 <oneinsect> and good night for today
2020-04-06 20:11:28 <_ikke_> I have 3 logitech wireless reciever, and I was wondering why my kb was not resonding :D
2020-04-06 20:30:02 <maxice8> @ikke: if you want i can disable them in my MRs
2020-04-06 20:30:07 <maxice8> the asyncio tests
2020-04-06 20:31:42 <_ikke_> Well, it's not just up to me, just wondering whether it makes sense to have those long tests running for alpine
2020-04-06 20:32:41 <_ikke_> We run tests to verify that the projects work properly in an alpine environment, but a lot of tests are just testing the project itself. In most cases, they're so fast that we don't need to distinguish between them
2020-04-06 20:33:10 <_ikke_> But if tests take long, it's worth to disable things that don't provide a lot
2020-04-06 20:33:23 <_ikke_> But I'm not sure whether that's the case here or not, hence me posting the question
2020-04-06 20:38:03 <kmaxwell> maybe a naive question, but is it easy to run a subset? to disable the slowest ones?
2020-04-06 20:38:35 <kmaxwell> I can see some value in testing asyncio but not 2hours of value :)
2020-04-06 20:38:48 <_ikke_> A lot of test frameworks allow you to disable specific tests
2020-04-06 20:39:13 <_ikke_> I'm not sure what the python internal test suite is offering
2020-04-06 20:48:32 <kmaxwell> taking a look, and was amused to read check() calls `make quicktest` :)
2020-04-06 20:49:17 <_ikke_> haha :D
2020-04-06 20:49:30 <_ikke_> I don't want to know then how long the full test takes
2020-04-06 23:32:34 <kmaxwell> is is better to leave tests disabled or turn on the passing tests?
2020-04-07 07:37:59 <_ikke_> re python tests: ERROR: Job failed: execution took longer than 5h0m0s seconds
2020-04-07 08:50:24 <Cogitri> `ERROR: python3-3.8.2-r2: trying to overwrite usr/bin/python owned by python2-2.7.17-r0.` I think both python3 and python2 provide /usr/bin/python now?
2020-04-07 08:53:03 <_ikke_> hmm
2020-04-07 08:53:46 <_ikke_> is that due to upstream?
2020-04-07 08:54:29 <_ikke_> ah, no
2020-04-07 08:54:47 <_ikke_> maxice8 installed python3 as python
2020-04-07 08:54:57 <_ikke_> 7d0c1c002d1faffabd55083cf03a54325e8df6e8
2020-04-07 08:55:29 <Cogitri> Hm, I think 5ad0ec7da1064361cc74d56edf7524960f49ef9b should remove the python2 symlink?
2020-04-07 08:55:54 <_ikke_> I don't think that should be done without verifying everything that still depends on python2
2020-04-07 08:56:03 <_ikke_> and let it explicitly use python2
2020-04-07 08:56:33 <Cogitri> apk doesn't upgrade my server to the new python2 for some reason 🤔
2020-04-07 08:57:01 <_ikke_> maybe because something is holding it back?
2020-04-07 08:57:03 <Cogitri> ```
2020-04-07 08:57:04 <Cogitri> ERROR: unsatisfiable constraints:
2020-04-07 08:57:04 <Cogitri>   python2-2.7.17-r0:
2020-04-07 08:57:04 <Cogitri>     breaks: world[python2=2.7.17-r1]
2020-04-07 08:57:04 <Cogitri>     satisfies: world[python]
2020-04-07 08:57:04 <Cogitri> ```
2020-04-07 08:57:04 <Cogitri> Huh
2020-04-07 08:57:24 <_ikke_> yeah, I think a so: dependency
2020-04-07 08:58:36 <mps> 
ACTION doesn't allow python on servers, bad idea from experience

2020-04-07 08:59:21 <Cogitri> Well, I need it for searx
2020-04-07 08:59:50 <mps> yes, I understand. sometime we don't have choice
2020-04-07 09:00:36 <mps> didn't intended to criticize you, or anyone
2020-04-07 09:02:54 <Cogitri> Ah yes, I didn't understand it as that :)
2020-04-07 10:37:37 <maxice8> you added python to /etc/apk/world ?
2020-04-07 10:41:48 <Cogitri> Apparently yes:
2020-04-07 10:41:54 <Cogitri> ```
2020-04-07 10:41:54 <Cogitri> cogitri:~$ cat /etc/apk/world  | grep python
2020-04-07 10:41:54 <Cogitri> python
2020-04-07 10:41:54 <Cogitri> python3-dev
2020-04-07 10:41:54 <Cogitri> uwsgi-python3
2020-04-07 10:41:55 <Cogitri> ```
2020-04-07 10:43:01 <maxice8> i mean, apk tells you in no uncertains terms
2020-04-07 10:43:04 <maxice8> satisfied world[python]
2020-04-07 10:43:41 <Cogitri> Ah, somehow I tread world[python2] in there
2020-04-07 10:44:23 <maxice8> the satisfies: key
2020-04-07 11:05:41 <kmaxwell> I've been trying out mkmr, thanks to the authors, I like it
2020-04-07 11:15:12 <markand> UUOC
2020-04-07 11:15:40 <oneinsect> whats mkmr
2020-04-07 11:16:15 <maxice8> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/mkmr
2020-04-07 11:16:59 <oneinsect> oooh nice
2020-04-07 11:17:06 <oneinsect> very nice
2020-04-07 11:20:52 <Cogitri> I use it for every mr, it's very nice
2020-04-07 11:23:41 <maxice8> mps: https://crystal-lang.org/2020/04/06/crystal-0.34.0-released.html
2020-04-07 11:23:45 <maxice8> llvm10 support included
2020-04-07 11:24:47 <Cogitri> 🎉
2020-04-07 11:30:49 <maxice8> mps: can you test !6075 on aarch64 ? i don't get the test errors locally, i wanna know if they are CI-specific
2020-04-07 11:37:14 <mps> maxice8: thanks for info, will look later, now don't have much time
2020-04-07 11:37:37 <maxice8> No worries
2020-04-07 11:38:09 <mps> ncopa: did you made any progress on building crystall 0.33 or 0.32 on aarch with llmv8+
2020-04-07 11:38:26 <mps> aarch64*
2020-04-07 11:44:43 <ncopa> mps: no. i got stuck. I think its llvm bug of some sort. https://github.com/crystal-lang/crystal/issues/8080#issuecomment-606772770 I dont know how to proceed
2020-04-07 11:49:28 <mps> only sane solution is to drop aarch64, for now at least. that's my opionion
2020-04-07 11:49:32 <ncopa> hum
2020-04-07 11:49:43 <ncopa> not rust fails to build due to missing /usr/bin/python
2020-04-07 11:50:40 <_ikke_> I feel that that transition could have been with a little bit more preparation
2020-04-07 11:50:46 <mps> I would like to push !4237 . any objection?
2020-04-07 11:51:25 <mps> hm, algitbot forgot to show 'subject' of MR
2020-04-07 11:51:47 <mps> community/crystal: upgrade to 0.32.1
2020-04-07 11:52:22 <ncopa> _ikke_: at least a warning might have been good
2020-04-07 11:52:22 <PureTryOut[m]> It'd be nice if the next upgrade fixes the linting issues
2020-04-07 11:52:26 <maxice8> @ikke: yeah i'll be reverting the python change as soon as i  finish gnutls
2020-04-07 11:55:20 <ncopa> python change will be reverted? ok, then i need to wait with my rust work. maxice8: please ping me when python is reverted
2020-04-07 11:55:36 <maxice8> i'll ping
2020-04-07 12:04:10 <PureTryOut[m]> You're reverting https://git.alpinelinux.org/aports/commit/main/python3?id=7d0c1c002d1faffabd55083cf03a54325e8df6e8?
2020-04-07 12:04:41 <maxice8> @PureTryOut yes
2020-04-07 12:05:20 <markand> rust is a real PITA to build
2020-04-07 12:05:31 <markand> not mentioning when I tried to build it under a pure LLVM toolchain
2020-04-07 12:06:13 <Shiz> ncopa: you can just send one email next time instead of 6 in a row :)
2020-04-07 12:08:00 <ncopa> ok. sorry
2020-04-07 12:10:41 <PureTryOut[m]> maxice8: why exactly? Where there problems? I haven't had a `/usr/bin/python` on my Alpine system for ages now without issues
2020-04-07 12:10:59 <maxice8> some packages fail to build
2020-04-07 12:11:09 <maxice8> rust calls python directly and apparently uses python2
2020-04-07 12:11:43 <PureTryOut[m]> Oh interesting
2020-04-07 12:16:02 <maxice8> ncopa: ping, pushed the commits, should be available sometime soon. Python takes a bit in tests
2020-04-07 12:16:35 <ncopa> thanks!
2020-04-07 12:17:18 <Cogitri> markand: Wdym? Can I help maybe? :)
2020-04-07 12:18:02 <mps> hmm, apk info --quiet is not quiet?
2020-04-07 12:18:14 <mps> it shows 'header'
2020-04-07 12:18:15 <markand> Cogitri, when I've tried to build my pure LLVM distribution I spent a week to build rust because they provide only a musl+gcc toolchain
2020-04-07 12:18:22 <markand> I needed dozen of patches
2020-04-07 12:18:35 <Cogitri> Ah, pure LLVM as in full LLVM suite
2020-04-07 12:18:51 <Cogitri> I didn't hear the term "pure LLVM" before
2020-04-07 12:19:22 <markand> yes, no GNU component at all (even not libstdc++/libgcc_s/ld)
2020-04-07 12:20:47 <Cogitri> Oh, neat
2020-04-07 12:27:01 <zfoo> I'm seeing an error at the end of running 'abuild -r' saying 'APKINDEX: UNTRUSTED signature', it's fine the first time it run but see the error for each run after that
2020-04-07 12:27:42 <Cogitri> I guess your APKINDEX is signed with a key that you don't use anymore
2020-04-07 12:27:53 <Cogitri> The easiest way to fix that is to delete the APKINDEX and run `abuild index` afterwards
2020-04-07 12:28:03 <Cogitri> (The new APKINDEX will be signed with your current APKINDEX then)
2020-04-07 12:32:07 <zfoo> Cogitri, still get the error after updating the index
2020-04-07 12:36:28 <zfoo> nvm, some how my key was removed from /etc/apk/keys
2020-04-07 12:37:08 <Cogitri> Ah yes, of course the key also needs to be trusted :)
2020-04-07 13:03:24 <mps> hm, 'license="0BSD"' testing/bfs/
2020-04-07 13:03:51 <mps> interesting :)
2020-04-07 13:05:19 <maxice8> ?
2020-04-07 13:05:59 <mps> never heard for '0BSD' license, but it is listed in spdx
2020-04-07 13:07:26 <maxice8> Toybox license
2020-04-07 13:10:17 <Cogitri> Is someone else getting `gzip: invalid magic` errors in the cracklib trigger?
2020-04-07 14:11:30 <artok> compiler-rt and lld is easy to get working, but dropping libstdc++ out of the question... wheee
2020-04-07 14:11:40 <artok> on llvm toolchain, that is
2020-04-07 14:11:59 <Cogitri> AFAIK there's still some stuff which doesn't like lld
2020-04-07 14:12:32 <artok> would like to get sanitizers first to work
2020-04-07 14:12:41 <mps> just made quick apk TUI browser with perl and curses-ui, calling 'apk info -a $apk' is slow
2020-04-07 14:13:42 <Cogitri> artok: Wouldn't you need glibc for sanitizers?
2020-04-07 14:13:51 <Cogitri> 
ACTION uses an Ubuntu VM for that right now

2020-04-07 14:13:53 <mps> there is libapk binding for scripting langs?
2020-04-07 14:14:06 <Cogitri> mps: No, there's only libapk which is C and very low level
2020-04-07 14:14:18 <Cogitri> That might change with apkv3 though
2020-04-07 14:14:30 <artok> yeah, on musl, compiler-rt needs to be built without sanitizer support
2020-04-07 14:14:49 <Cogitri> You can use the higher level D bindings in apk-polkit if you want to :^)
2020-04-07 14:16:12 <mps> polkit?
2020-04-07 14:16:28 <artok> I'm building docker image using llvm and targeting alpine x86_64, alpine i686, alpine armv7, alpine aarch64 and AVR
2020-04-07 14:16:47 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/apk-polkit
2020-04-07 14:17:07 <Cogitri> It's mainly for allowing GNOME Software and the likes
2020-04-07 14:17:37 <Cogitri> But it contains a library (apkd) that works without polkit which is basically just a higher level API to libapk
2020-04-07 14:17:49 <mps> rather will create local cache with apk infos, I'm making TUI at the end which can run on remote servers
2020-04-07 14:17:52 <Cogitri> I didn't seperate it out of apk-polkit yet because there wasn't really much reason to do so
2020-04-07 14:19:01 <mps> and have to leard D, hmm
2020-04-07 14:19:13 <mps> for now, no thanks
2020-04-07 14:19:21 <mps> learn*
2020-04-07 14:20:29 <mps> Cogitri: thanks for info, could be useful anyway. who knows :)
2020-04-07 14:21:44 <Cogitri> Well, it has a C callable API if you prefer that :)
2020-04-07 14:26:56 <mps> after some thinking whatever I do it will not be fast as I thought this morning
2020-04-07 14:58:39 <markand> D :|
2020-04-07 14:58:44 <markand> even worse than Goo
2020-04-07 14:58:46 <markand> -o
2020-04-07 15:00:23 <Cogitri> D's neat because it has a dynamic linking
2020-04-07 15:00:32 <Cogitri> Otherwise I'd use Rust, but static linking all the crates and micro deps are such a pain
2020-04-07 15:00:58 <markand> Rust is the new npm, literally
2020-04-07 15:01:13 <markand> Alacritty requires around 50 deps, ending in a binary size of somewhat several megabytes
2020-04-07 15:01:17 <markand> totally insane for a terminal
2020-04-07 15:01:17 <markand> ¯\_(ツ)_/¯
2020-04-07 15:17:57 <Cogitri> 50 deps is pretty small for Rust packages :^)
2020-04-07 15:24:17 <Cogitri> Anyway, I wanted something that's not as error prone as C or C++, has dynamic linking and is a compiled language, so D was one of my only choices
2020-04-07 15:24:58 <TBB> D's not -that- bad
2020-04-07 15:26:11 <Cogitri> I've grown to like it a lot
2020-04-07 16:27:24 <maxice8> can i get lua-aports to deal with multiple repos ?
2020-04-07 16:32:16 <maxice8> @Ikke: i'll need more CI time in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6482
2020-04-07 16:32:51 <maxice8> llvm{5,6,8,9,10} + firefox + firefox-esr + python{2,3} + thunderbird + ghc + idris
2020-04-07 16:34:25 <_ikke_> Better do that in the night then..
2020-04-07 16:34:51 <_ikke_> When CI is not used that much
2020-04-07 17:28:40 <Cogitri> FF 75 doesn't need system sqlite anymore apparently, do we still want SECURE_DELETE set on sqlite nontheless?
2020-04-07 17:28:59 <Cogitri> It comes with a performance penalty and probably decreases SSD lifetime a bit
2020-04-07 17:29:27 <Ariadne> umm
2020-04-07 17:29:38 <Ariadne> what do you mean by "doesn't need system sqlite"
2020-04-07 17:29:51 <_ikke_> Sounds like it uses an embedded sqlite lib
2020-04-07 17:29:55 <Cogitri> Yes
2020-04-07 17:30:23 <Ariadne> that's not good
2020-04-07 17:30:34 <Ariadne> embedded libs are bad for security
2020-04-07 17:30:35 <Cogitri> https://bugzilla.mozilla.org/show_bug.cgi?id=1611386
2020-04-07 17:31:25 <dalias> well firefox is special. it has security issues of its own a lot more often than sqlite does
2020-04-07 17:31:43 <dalias> i think getting rid of the SECURE_DELETE performance and disk-grinding penalty would be worthwhile
2020-04-07 17:32:08 <Cogitri> Yes, would be good to get rid of that
2020-04-07 17:32:21 <_ikke_> Fx says they need to use sqlite in an incompattible way with system sqlite
2020-04-07 17:32:36 <Ariadne> yuck
2020-04-07 17:32:47 <dalias> it'd be interessting to see their reason..
2020-04-07 17:33:00 <Cogitri> dalias: see the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1611386 I guess
2020-04-07 17:33:00 <_ikke_> dalias: ^^
2020-04-07 17:33:02 <_ikke_> it's in the link
2020-04-07 17:33:12 <dalias> ok
2020-04-07 17:33:18 <mps> well, on arm64 with e/mmc I run FF with ~/.mozilla/profile.xxx in tmpfs
2020-04-07 17:34:21 <dalias> *sigh* they're doing secure delete just for porn mode? :(
2020-04-07 17:34:29 <_ikke_> mps: does that mean you'll lose your profile when you reboot?
2020-04-07 17:34:32 <dalias> that's so useless when system swap is not going to be secure-deleted anyway
2020-04-07 17:34:41 <dalias> it should just be removed to fix the perf/diskgrinding cost
2020-04-07 17:34:55 <Ariadne> the solution to porn mode is to not look at porn
2020-04-07 17:35:05 <dalias> porn mode is just the nickname
2020-04-07 17:35:10 <dalias> it's useful/needed for lots of things
2020-04-07 17:35:13 <Ariadne> i know, i am just being faceitious
2020-04-07 17:35:19 <mps> _ikke_: I have script which sync tmpfs to ~/mozilla dir
2020-04-07 17:35:23 <dalias> like logging into someone else's google account without trashing your own sessions
2020-04-07 17:35:41 <mps> and run it before shutdown/reboot
2020-04-07 17:35:46 <_ikke_> ok
2020-04-07 17:36:01 <_ikke_> but not crash resilient I guess
2020-04-07 17:36:04 <dalias> or browsing amazon without the things you browse getting added to your "you recently viewed", etc
2020-04-07 17:36:15 <Ariadne> sure love to rebuild python3 several times in a week
2020-04-07 17:36:24 <mps> it is not for security but for wear minimizing
2020-04-07 17:36:27 <Ariadne> that testsuite is brutal
2020-04-07 17:36:27 <dalias> but it is not a mitigation of forensic recovery of your browsing history if your machine is compromised
2020-04-07 17:36:32 <_ikke_> Ariadne: yes, it is
2020-04-07 17:36:34 <dalias> and trying to pretend it is is silly
2020-04-07 17:36:56 <mps> _ikke_: yes, but alpine doesn't crash :)
2020-04-07 17:36:58 <_ikke_> Ariadne: I was asking whether we need to run the asyncio tests
2020-04-07 17:37:03 <Cogitri> Does secure delete even work on flash storage?
2020-04-07 17:37:07 <Ariadne> _ikke_: i don't think we do
2020-04-07 17:37:16 <Cogitri> Doesn't the memory controller make it defunct due to wear leveling?
2020-04-07 17:37:33 <dalias> cogitri, it should, at the appropriate abstraction layer
2020-04-07 17:37:58 <dalias> you can't recover anything via the exposed interfaces of the flash as a block device
2020-04-07 17:38:31 <dalias> whether you can hack the uc on the flash chip to get at physical sectors that haven't been reused is another matter
2020-04-07 17:40:07 <Cogitri> Ah, okay
2020-04-07 17:40:30 <Cogitri> Oof, just finished building FF but it failed to install because I ran out of space on my / :^)
2020-04-07 17:40:42 <Cogitri> I really need to get one of those fancy 2TB NVMe drives
2020-04-07 17:40:53 <dalias> it should be possible to mitigate even that with appropriate use of crypto
2020-04-07 17:40:59 <dalias> :/
2020-04-07 17:42:03 <dalias> 256GB usb3 small profile drives are really cheap now
2020-04-07 17:42:45 <dalias> with a hub you can get bulk storage cheap that way
2020-04-07 17:42:50 <Cogitri> I have a deep distrust against usb drives
2020-04-07 17:43:15 <dalias> i'm talking samsung and sandisk ones, not generic stuff off aliexpress :)
2020-04-07 17:43:39 <dalias> iirc it was like $30 for 256 GB last time i ordered
2020-04-07 17:43:44 <Cogitri> Even then, those USB drives usually get super toasty when actually using them and there's a reason they're that cheap
2020-04-07 17:44:38 <dalias> yeah. i haven't had any problems but i just use them for infrequent access, large data
2020-04-07 17:45:10 <dalias> if i wanted a big array i'd do raid or something and also spread out the access to keep individual ones cooler as a side effect
2020-04-07 17:45:22 <dalias> or stick active cooling on them :-p
2020-04-07 17:48:44 <Cogitri> Heh, that could work too :P
2020-04-07 17:51:18 <Ariadne> for the mips port, we are using "samsung portable SSD" USB drives
2020-04-07 17:51:40 <Ariadne> they are more like an external HDD
2020-04-07 17:51:45 <Ariadne> and inexpensive
2020-04-07 17:52:01 <dalias> yeah
2020-04-07 17:52:08 <Cogitri> Ah yes, those have a proper controller and stuff, right?
2020-04-07 17:52:11 <Cogitri> And a DRAM cache?
2020-04-07 17:52:12 <dalias> actually i have a cheap usb3 to sata cable
2020-04-07 17:52:24 <dalias> that lets you use normal sata drives that way
2020-04-07 17:52:59 <Cogitri> I have that too for my bluray reader, my case is too small to fit that
2020-04-07 17:53:05 <dalias> but i think you get the best price and physical space density with the usb3 drives that fit almost entirely inside the usb-a port
2020-04-07 17:53:39 <dalias> 2.5" sata drives are gratuitously large just for the sake of physical mounting
2020-04-07 17:53:59 <Cogitri> You can mount those about anywhere with tape :P
2020-04-07 17:54:03 <Ariadne> Cogitri: yes, they are just NVMe SSDs with a USB adapter
2020-04-07 17:54:06 <dalias> :)
2020-04-07 17:54:29 <Cogitri> Anyway, nothing but a NVMe drive will fit into my case, the thing is already more than packed
2020-04-07 17:55:00 <Ariadne> the builder even uses these USB drives
2020-04-07 17:55:18 <Ariadne> we are planning to get a nicer builder which can just boot from SATA
2020-04-07 17:55:28 <Ariadne> unfortunately, COVID-19 kind of wrecked those plans
2020-04-07 17:55:34 <Ariadne> soooo gotta do what you gotta do :)
2020-04-07 18:10:02 <markand> NVMe ftw
2020-04-07 18:14:33 <paper_> is conflicts a variable respected by the package manager?
2020-04-07 18:14:55 <maxice8> i dont think so
2020-04-07 18:15:11 <[[sroracle]]> you can add !pkg to depends
2020-04-07 18:15:30 <paper_> ok, thanks
2020-04-07 18:21:28 <Ariadne> conflicts are defned as !pkg yes
2020-04-07 18:21:41 <Ariadne> you can also do
2020-04-07 18:21:45 <Ariadne> apk add !systemd
2020-04-07 18:21:48 <Ariadne> for example
2020-04-07 18:22:16 <Ariadne> and it will install a conflict into your system so that packages that pull in systemd (just example) won't be installable
2020-04-07 18:32:43 <Hello71> dalias: the mini ones are prone to overheating
2020-04-07 20:00:54 <mps> OT but, latest openwrt which works on mikrotik RB450G (mips 32 cpu) is from 2017-04
2020-04-07 20:01:28 <mps> all after that release can't be installed
2020-04-07 22:36:08 <fabrice_d> what is the usual setup to cross compile packages? (host is x86_64, target aarch64)
2020-04-07 23:06:12 <fabrice_d> Cogitri: how do you test cross compilation of Firefox? I'm trying to build it in pmOS (host x86, target aarch64) but this fails with:
2020-04-07 23:06:14 <fabrice_d> ERROR: The rust compiler host (x86_64-alpine-linux-musl) is not suitable for the configure host (aarch64-unknown-linux-musl).
2020-04-07 23:06:46 <maxice8> I don't think it is tested, alpine compiles everything natively
2020-04-07 23:09:06 <artok> llvm systems can do cross compiling quite nicely, just have support on the compiler/linker etc for the arch and the target sysroot
2020-04-08 04:21:59 <maxice8> @Ariadne: ping, you up until when ? i want to merge libffi 3.3 which will carry a rebuild of a loads of stuff which will block the builders for a bit and i see you are currently actively commiting
2020-04-08 04:22:13 <Ariadne> ahahahahahaha
2020-04-08 04:22:25 <Ariadne> thanks, i hate it
2020-04-08 04:24:35 <Ariadne> maxice8: let me finish flushing out all the FTBFS packages
2020-04-08 04:24:45 <maxice8> sure
2020-04-08 04:24:49 <maxice8> i'll go make some toast in the meantime
2020-04-08 04:26:04 <Ariadne> also
2020-04-08 04:26:11 <Ariadne> the x86 builder is stalled
2020-04-08 04:26:17 <Ariadne> as is aarch64
2020-04-08 04:26:28 <Ariadne> so i think we should sort that first
2020-04-08 04:29:14 <maxice8> Ok
2020-04-08 04:58:32 <maxice8> test_threading is taken 16 hours and 32 minutes
2020-04-08 06:16:19 <ncopa> morning
2020-04-08 06:16:27 <maxice8> hello
2020-04-08 06:16:48 <ncopa> seems like aarch64 and x86 builders are stuck at the python3 tests?
2020-04-08 06:17:08 <maxice8> yes, i notified kdaudt in #alpine-infra
2020-04-08 06:31:33 <Cogitri> Morning
2020-04-08 06:46:35 <markand> hey
2020-04-08 06:47:07 <markand> someone for !6387 ?
2020-04-08 06:47:26 <markand> the CI is a bit limited regarding "big" packages
2020-04-08 07:30:41 <Ariadne> maxice8: ok if you want to do the libffi now is probably a good time
2020-04-08 07:30:59 <maxice8> am looking at mariadb failures on armhf
2020-04-08 07:32:57 <Ariadne> hmm
2020-04-08 07:32:59 <Ariadne> disk space maybe
2020-04-08 07:33:06 <Ariadne> the logs seem truncated
2020-04-08 07:33:30 <maxice8> some are purely cryptic
2020-04-08 07:33:32 <maxice8> https://build.alpinelinux.org/buildlogs/build-3-9-armhf/main/mariadb/mariadb-10.3.22-r0.log
2020-04-08 07:34:08 <maxice8> says ld failed but where is the link error :S
2020-04-08 07:34:55 <maxice8> worst part is that they all passed Gitlab CI
2020-04-08 07:35:31 <Cogitri> Maybe it'd show the error with VERBOSE=1 ?
2020-04-08 07:35:42 <Cogitri> imho we should enable verbose makefiles in CMake anyway
2020-04-08 07:36:37 <maxice8> i guess, i'll try it with V=1, i thought errors would be the thing that would appear regardless if verbose or not
2020-04-08 07:40:10 <Cogitri> I think V=1 doesn't work with CMake
2020-04-08 07:40:11 <Cogitri> I think it needs to be VERBOSE=1
2020-04-08 07:44:17 <maxice8> yep, 3.9-armhf is out of disk space
2020-04-08 07:44:18 <maxice8> https://build.alpinelinux.org/buildlogs/build-3-9-armhf/main/mariadb/mariadb-10.3.22-r0.log
2020-04-08 07:54:52 <Ariadne> night
2020-04-08 08:26:30 <markand> either VERBOSE=1 or the more generic CMAKE_VERBOSE_MAKEFILE=1 during configure
2020-04-08 08:28:09 <Cogitri> Yup
2020-04-08 08:32:16 <markand> but cmake --build . -v is probably the best choice
2020-04-08 08:33:29 <maxice8> armv7 ran out of spice while compiling firefox https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/firefox/firefox-75.0-r0.log and is stuck
2020-04-08 08:33:43 <maxice8> s/spice/space
2020-04-08 08:33:43 <alpine-meetbot> maxice8 meant to say: armv7 ran out of space while compiling firefox https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/firefox/firefox-75.0-r0.log and is stuck
2020-04-08 09:21:33 <_ikke_> I'll look at the armhf builder in an hour
2020-04-08 09:22:05 <Cogitri> Thank you :)
2020-04-08 09:22:45 <Cogitri> Huh, 3.8-armhf failed building undefined/mariadb :D
2020-04-08 09:56:23 <ncopa> it was out of diskspace
2020-04-08 09:56:28 <ncopa> i have cleaned up it a bit
2020-04-08 09:56:39 <ncopa> and are re-running the build
2020-04-08 09:56:59 <Cogitri> Yup, I just found it funny that the repo was undefined ^^
2020-04-08 09:57:08 <Cogitri> Thanks for taking care of it :)
2020-04-08 09:57:32 <ncopa> i guess i should waith with buildinger kernel too :-/
2020-04-08 09:57:55 <Cogitri> Yes, I guess the builders will take a bit now
2020-04-08 09:58:35 <ncopa> im thinking that we should have disposable builders. for each build, boot a container, build the stuff, uplaod and delete everything
2020-04-08 10:00:12 <_ikke_> Like what gitlab does
2020-04-08 10:00:16 <ncopa> yes
2020-04-08 10:00:16 <_ikke_> For ci
2020-04-08 10:01:14 <mps> no need to hurry for kernel upgrade, not much changes in today's release
2020-04-08 10:04:43 <Cogitri> Yes, disposable builders would be nice (although we'd sort of have that with rootbld?)
2020-04-08 10:06:50 <ncopa> the reason i am thinking of it now is to reduce disk usage in total
2020-04-08 10:25:08 <_ikke_> ncopa: I wonder how much it will reduce disk usage? Most disk usage is either logs or cached source (which I assume we want to keep)
2020-04-08 10:25:37 <ncopa> and the entire package repository
2020-04-08 10:25:45 <_ikke_> yes
2020-04-08 13:18:48 <afontain_> question: I've got an openRC service that uses supervise-daemon. When the (foreground) command is run, it exits immediatly, yet the `rc-service z start` message is `Starting Z… [ok]`
2020-04-08 13:19:02 <afontain_> it exits, with an error code
2020-04-08 13:19:03 <afontain_> is it normal?
2020-04-08 13:27:53 <Cogitri> That seems very not normal
2020-04-08 13:27:58 <Cogitri> What is its status in rc-status ?
2020-04-08 13:43:18 <kaey> afontain_: ssd restarts 10times and gives up. try adding error_log=pathtolog in conf.d
2020-04-08 13:44:06 <afontain_> it is shown as stopped
2020-04-08 13:44:39 <afontain_> there is no error log, logging is done to stdout
2020-04-08 13:45:09 <kaey> error_log redirect stdout to file
2020-04-08 13:45:25 <kaey> stdout is dev nulled by default in ssd
2020-04-08 13:46:15 <afontain_> I guess sd is supervise-deamon, but then what is ssd?
2020-04-08 13:46:21 <afontain_> (well, apart from solid state drive)
2020-04-08 13:46:32 <kaey> i meant sd sorry
2020-04-08 13:46:54 <kaey> ssd is start stop daemon, sd is supervise daemon
2020-04-08 13:49:24 <afontain_> 
ACTION is rebuilding the package

2020-04-08 13:55:51 <afontain_> kaey: error_log=/… creates an empty file, while it definitely shouldn't
2020-04-08 13:56:39 <afontain_> there is no option to force background or foreground
2020-04-08 13:57:00 <afontain_> when I run it manually, it runs in foreground, so I assume it's always the case
2020-04-08 13:59:30 <afontain_> the file is empty both on fail and on success
2020-04-08 14:09:31 <kaey> there is output_log as well for stdout (error is for stderr only)
2020-04-08 14:19:06 <kaey> check dmesg also, maybe it gets oomed
2020-04-08 14:19:50 <afontain_> nothing in dmesg
2020-04-08 14:20:06 <afontain_> the file also gets created with output_log, but it's empty
2020-04-08 14:21:02 <afontain_> (I replaced error_log with output_log)
2020-04-08 14:46:12 <ncopa> wow mips64 packages are available now
2020-04-08 14:47:16 <ncopa> main and community
2020-04-08 14:47:42 <ncopa> Ariadne: good job!
2020-04-08 14:48:15 <Ariadne> there's a lot to untangle still
2020-04-08 14:48:27 <Ariadne> docker & friends have some dependencies which assume mips is 32-bit
2020-04-08 14:48:33 <ncopa> aw
2020-04-08 14:49:01 <Ariadne> which is annoying because CI
2020-04-08 14:49:09 <ncopa> indeed
2020-04-08 14:49:45 <ncopa> but go in general works?
2020-04-08 14:50:05 <Ariadne> yes
2020-04-08 14:50:08 <Ariadne> go itself works fine
2020-04-08 14:50:22 <Ariadne> it's just dependencies that need to be fixed
2020-04-08 14:50:34 <Ariadne> they either miss code for mips64 entirely or the code is wrong
2020-04-08 14:50:40 <Ariadne> stuff like syscalls
2020-04-08 14:51:01 <ncopa> are there issues reported upstream?
2020-04-08 14:51:10 <Ariadne> that's the battle for later this week
2020-04-08 14:51:15 <Ariadne> i'm going to just fix them all and send MRs
2020-04-08 14:51:28 <Ariadne> there are three main offenders
2020-04-08 14:51:38 <Ariadne> boltdb, some docker thing runc uses, and runc itself
2020-04-08 14:52:04 <ncopa> containerd is ok?
2020-04-08 14:52:13 <Ariadne> seems so
2020-04-08 14:52:19 <ncopa> cool
2020-04-08 14:52:38 <ncopa> if i'd like to play around with mips64, what hardware could I get?
2020-04-08 14:52:47 <Ariadne> you can pick up
2020-04-08 14:52:58 <Ariadne> edgerouter er-8 on amazon pretty cheap
2020-04-08 14:53:07 <Ariadne> that's like $150 US usually
2020-04-08 14:53:10 <Ariadne> dual-core 1ghz
2020-04-08 14:53:16 <Ariadne> you can upgrade the RAM
2020-04-08 14:53:31 <Ariadne> our current builder is an edgerouter infinity
2020-04-08 14:53:51 <Ariadne> which is 16-core 1.8ghz
2020-04-08 14:53:58 <Ariadne> upgradable RAM (2 slots)
2020-04-08 14:54:04 <Ariadne> but those are about $2000 US
2020-04-08 14:54:14 <Ariadne> and you have to use proprietary kernel
2020-04-08 14:54:25 <Ariadne> we are working on porting the drivers to mainline
2020-04-08 14:56:03 <Ariadne> the shitty part of the octeon devices is
2020-04-08 14:56:18 <Ariadne> a lot of them have old bootloader which does not allow using an initramfs
2020-04-08 14:56:42 <Ariadne> with linux-octeon kernel, you can create a "named memory block" containing the initramfs, and boot with rd_name=initramfs
2020-04-08 14:56:53 <Ariadne> but that only works on devices with a sufficiently new bootloader
2020-04-08 14:57:22 <Ariadne> i was going to write an email outlining all of that :)
2020-04-08 15:00:34 <ncopa> maybe stupid question, but why would anyone want run alpine instead of the provided OS they come with?
2020-04-08 15:00:46 <Ariadne> EdgeOS is really awful
2020-04-08 15:00:58 <Ariadne> like, really really really awful
2020-04-08 15:01:21 <Ariadne> it is based on Debian from 10 years ago
2020-04-08 15:01:29 <ncopa> heh
2020-04-08 15:01:34 <Ariadne> there is a new EdgeOS based on Debian from 5 years ago, but it crashes a lot
2020-04-08 15:02:19 <ncopa> i guess with alpine you could do stuff like dmvpn, wireguard etc
2020-04-08 15:02:24 <Ariadne> yes
2020-04-08 15:02:44 <Ariadne> that is basically how this entire thing started
2020-04-08 15:02:55 <ncopa> got you
2020-04-08 15:03:00 <ncopa> makes sense
2020-04-08 15:03:16 <ncopa> sorry if you already explained to me. sounds familiar :)
2020-04-08 15:03:27 <Ariadne> EdgeOS offers OpenVPN and IPsec, and you have to configure all of that using EdgeOS CLI
2020-04-08 15:03:39 <Ariadne> with alpine it's basically just a normal linux machine
2020-04-08 15:04:34 <Ariadne> what is more interesting is the embedded stuff i am working on
2020-04-08 15:04:53 <Ariadne> which allows you to bake a firmware image for any OpenWRT device that contains Alpine userspace instead
2020-04-08 15:05:24 <Ariadne> COVID-19 kind of wrecked that project though, because i need to go to Shenzhen and source some boards for a "maker kit"
2020-04-08 15:13:30 <tmlind> oh that sounds interesting :)
2020-04-08 15:17:17 <mps> clandmeter: !5928 this is lxc LTS, upgrade to 4.0.1
2020-04-08 15:17:40 <mps> you asked me about week ago about that
2020-04-08 15:18:10 <afontain_> pms: btw, what's your opinion about the Anbox breakage?
2020-04-08 15:18:13 <afontain_> *mps
2020-04-08 15:18:37 <afontain_> sorry, I tried to type too fast
2020-04-08 15:18:55 <mps> afontain_: I don't know, didn't looked at anbox issue
2020-04-08 15:19:14 <mps> is that reported upstream, anbox or lxc
2020-04-08 15:19:23 <afontain_> it might be better with 4.0.1, I didn't try
2020-04-08 15:19:47 <afontain_> https://github.com/anbox/anbox/issues/1397
2020-04-08 15:19:58 <afontain_> but there has been no update for a week
2020-04-08 15:21:09 <afontain_> do you think there should be a second issue on the lxc tracker?
2020-04-08 15:23:26 <mps> this is github tracker, not alpine
2020-04-08 15:24:11 <afontain_> hmm, yes?
2020-04-08 15:24:15 <mps> if you want it to be 'followed' on alpine create bug report on alpine bug tracker
2020-04-08 15:24:47 <afontain_> well, I kinda used the MR discussion for that
2020-04-08 15:24:49 <mps> but, you can first try anbox with lxc 4.0.1 and see will it work
2020-04-08 15:24:54 <afontain_> I can do a proper issue if you prefer
2020-04-08 15:25:40 <mps> but have to say, I didn't tried to install or use anbox on alpine, so don't expect much from me
2020-04-08 15:28:39 <afontain_> there is no issue on the LXC tracker atm
2020-04-08 15:31:15 <mps> did you tried to report issue/bug to them
2020-04-08 15:45:08 <ncopa> maxice8: fontforge test suite hangs on x86
2020-04-08 15:45:37 <ncopa> it is the test139.pe
2020-04-08 15:45:52 <ncopa> 16956 buildoze  6h07 /home/buildozer/aports/testing/fontforge/src/fontforge-20200314/build/bin/fontforge -lang ff -script /home/buildozer/aports/testing/fontforge/src/fontforge-20200314/tests/test139.pe /home/buildozer/aports/testing/fontforge/src/fontforge-20200314/tests/fonts/StrokeTests.sfd
2020-04-08 16:01:10 <afontain_> still broken with LXC-4.0.1 https://paste.gnugen.ch/raw/iQzk
2020-04-08 16:09:13 <mps> do you know what is broken, lxc or anbox
2020-04-08 16:10:07 <afontain_> well, LXC changed his cgroup handling
2020-04-08 16:10:47 <afontain_> but I don't know if it worked before while it shouldn't or if it's an issue that should be fixed in lxc
2020-04-08 16:10:52 <ncopa> Cogitri: firefox does not build on armv7. do you ahve time to look at it soonish? I'd like that sorted before I introduce new breakages by pushing cargo updates
2020-04-08 16:11:37 <mps> afontain_: try to contact anbox devs and ask
2020-04-08 16:13:00 <Cogitri> ncopa: Oh, sure, I thought that was just because of Rust SIGSEGVing for no good reason agai
2020-04-08 16:14:05 <Cogitri> Will take a look in an hour or so
2020-04-08 16:14:55 <afontain_> I'll try that then
2020-04-08 16:20:47 <mps> afontain_: 'nice' part of job of maintainer :)
2020-04-08 16:21:45 <mps> (asking myself why I 'accepted' maintainer position)
2020-04-08 16:31:10 <afontain_> I feel like it's probably Anbox that should get fixed
2020-04-08 16:31:35 <afontain_> it looks like they changed cgroup path in LXC4
2020-04-08 16:31:39 <afontain_> paths*
2020-04-08 17:32:28 <_ikke_> firefox fails on armv7: /usr/lib/gcc/armv7-alpine-linux-musleabihf/9.3.0/include/arm_neon.h:10303:1: error: inlining failed in call to always_inline 'vld1_u8': target specific option mismatch
2020-04-08 17:34:54 <Cogitri> Yes, I'll disable asm
2020-04-08 17:35:05 <Cogitri> Sorry, took a powernap first :P
2020-04-08 17:35:14 <Cogitri> C++ for work was quite the brain drain
2020-04-08 17:38:03 <SerkanDevel[m]1> Hello again, when I build sourcehut with
2020-04-08 17:38:03 <SerkanDevel[m]1> abuild -rd
2020-04-08 17:38:03 <SerkanDevel[m]1> where is the package located?
2020-04-08 17:39:17 <Cogitri> By default it should be in $HOME/packages/$repo/sourcehut
2020-04-08 17:41:45 <SerkanDevel[m]1> Found it, thanks again
2020-04-08 17:43:41 <Cogitri> 👍️
2020-04-08 18:24:39 <maxice8> ping ncopa: https://gitlab.alpinelinux.org/Leo/atools/issues/29
2020-04-08 18:49:29 <mps> preparing firefox-esr 68.7.0 upgrade, should I add also android CVEs or just those related to desktop variant?
2020-04-08 18:50:13 <Cogitri> Only those which actually hit us
2020-04-08 18:50:34 <mps> thought so, thanks for be on 'my side' :)
2020-04-08 18:51:25 <Cogitri> ikke Do you have the complete log of that for me? Seems like it's gone from b.a.o already
2020-04-08 18:54:15 <_ikke_> Cogitri: fx?
2020-04-08 18:54:52 <Cogitri> Yes, of FF on armv7
2020-04-08 18:55:35 <_ikke_> tpaste doesn't like it (the log is too large)
2020-04-08 18:56:03 <Cogitri> I usually use Github Gists for large lgos
2020-04-08 18:58:01 <_ikke_> 45k lines :D
2020-04-08 18:58:26 <_ikke_> Cogitri: https://gist.github.com/Ikke/dc1f55ad3377c7446ecdbab99f82c742
2020-04-08 19:00:32 <artok> umh.. is there reason not having armv7 triplet on clang patch ?
2020-04-08 19:00:33 <Cogitri> Yeah, FF build throws loads of warnings
2020-04-08 19:00:36 <Cogitri> Thanks for the log
2020-04-08 19:00:50 <artok> talking about https://git.alpinelinux.org/aports/tree/main/clang/10-add-musl-triples.patch
2020-04-08 19:10:56 <Cogitri> 
ACTION looks at git log

2020-04-08 19:11:22 <Cogitri> I guess someone messed that up, but who knows who did that :P
2020-04-08 19:13:07 <Cogitri> I'll fix that after I'm done fixing aom on armv7
2020-04-08 19:21:44 <Cogitri> artok: !6540
2020-04-08 19:23:34 <artok> ;)
2020-04-08 19:34:34 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/88107 => 80 ERROR: cbindgen-0.13.2-r0: BAD signature
2020-04-08 19:35:27 <Cogitri> Huh, does installing cbindgen work for you locally?
2020-04-08 19:35:58 <mps> didn't tried
2020-04-08 19:36:14 <mps> lets see
2020-04-08 19:36:29 <mps> yes, it works
2020-04-08 19:36:38 <mps> will restart job to see
2020-04-08 20:03:29 <Cogitri> !6538 should fix FF on armv7
2020-04-08 20:03:47 <clandmeter> mps: LGTM
2020-04-08 20:12:38 <mps> clandmeter: ok, nice
2020-04-08 20:13:05 <mps> will someone merge? I can't
2020-04-08 20:16:14 <maxice8> send number
2020-04-08 20:16:30 <clandmeter> i pushed the green button
2020-04-08 20:16:37 <clandmeter> did i break it?
2020-04-08 20:16:51 <maxice8> no, they are stuck on fontforge, can you yeet x86 ?
2020-04-08 20:17:29 <mps> maxice8: !5928
2020-04-08 20:21:53 <maxice8> @clandmeter you pressed the green button only once and it did a rebase, you then need to merge it
2020-04-08 20:22:14 <maxice8> that is very annoying, on GitHub you can press `rebase and merge` and it does both in a single step for you
2020-04-08 20:22:16 <clandmeter> yeah, it was spinning
2020-04-08 20:22:33 <maxice8> You can also use mgmr from testing/mkmr :D
2020-04-08 20:22:46 <clandmeter> ah you pressed merge
2020-04-08 20:22:52 <clandmeter> you take all the fun away :p
2020-04-08 20:23:02 <maxice8> didn't press anything, `mgmr 5928` :D
2020-04-08 20:23:10 <clandmeter> you pressed enter :p
2020-04-08 20:24:50 <mps> ohm, two commits in MR, will the builder skip first one and just build last?
2020-04-08 20:25:17 <maxice8> it looks at what changed
2020-04-08 20:56:15 <mps> I'm blind. forgot to reset pkgrel for lxc, uhm
2020-04-08 20:57:46 <Cogitri> Ah, no worries, just look at qt5-qtwebkit, I didn't notice that the pkgrel hasn't been reset on that either
2020-04-08 20:57:56 <Cogitri> So it's at -r10 now
2020-04-08 21:54:42 <Cogitri> Ariadne: Did you see https://gitlab.alpinelinux.org/alpine/aports/-/commit/6957885149d8c97ec0c32b7988dac349c8d26356#note_79943 ?
2020-04-08 21:56:40 <Ariadne> Cogitri: i responded
2020-04-08 21:58:08 <Cogitri> Thank you
2020-04-08 21:59:23 <Ariadne> i cannot get a CI pipeline going for mips quite yet
2020-04-08 21:59:35 <Ariadne> some dependencies of docker do not build on mips64
2020-04-08 21:59:48 <Ariadne> i need to sort that out first
2020-04-08 22:00:03 <Ariadne> if you want a container, i can arrange that though
2020-04-08 22:08:44 <Cogitri> Ah, thanks, but I think that can wait a bit
2020-04-08 22:23:12 <maxice8> @Ikke: can you kill x86 ?
2020-04-09 02:17:22 <Ariadne> maxice8: if only we could kill x86
2020-04-09 02:17:29 <Ariadne> a world without x86 seems like a nice world
2020-04-09 02:17:43 <maxice8> i mean the builder
2020-04-09 02:18:13 <Ariadne> oh
2020-04-09 02:18:21 <Ariadne> well
2020-04-09 02:18:24 <Ariadne> i still maintain
2020-04-09 02:18:26 <Ariadne> a world without x86 seems like a nice world
2020-04-09 02:18:44 <maxice8> yes, i don't think kdaudt can single-handely kill a widely used CPU arch
2020-04-09 02:32:23 <gjabell> did the recent gtk patch break wayland stuff for anyone else?
2020-04-09 02:32:39 <maxice8> Yes
2020-04-09 02:32:40 <maxice8> Update again
2020-04-09 02:33:08 <maxice8> Waybar disappeared along with other Wayland widgets with custom surfaces , there is a now closed issue because an upstream patch has been merged
2020-04-09 02:34:07 <gjabell> is there an update for alpine? not seeing anything
2020-04-09 02:34:15 <gjabell> or is it just merged upstream and making its way down
2020-04-09 02:34:26 <maxice8> gtk+3.0=3.24.17-r1
2020-04-09 02:34:44 <gjabell> hmm, I think that's the one that broke it for me
2020-04-09 02:34:59 <maxice8> then it is another issue, please open one in alpine/aports
2020-04-09 02:35:08 <gjabell> ok, thanks
2020-04-09 02:36:58 <gjabell> is there a way to downgrade without uninstalling all the dependent programs?
2020-04-09 02:37:23 <maxice8> gtk+3.0 didn't break anything because 3.24.x and 3.24.y so you should be able to
2020-04-09 02:37:30 <maxice8> apk add 'gtk+3.0<3.24.17-r1'
2020-04-09 02:37:46 <maxice8> if you have that in cache, the gtk+3.0 update was long enough ago  that it won't be in the repos anymore
2020-04-09 02:37:57 <gjabell> ah that did it, thanks
2020-04-09 02:38:23 <gjabell> yep that fixes the issue, think it's the same thing as here: https://github.com/Alexays/Waybar/issues/648
2020-04-09 02:39:00 <maxice8> we fixed that in 3.24.17-r1 i had the same problem
2020-04-09 02:39:50 <gjabell> ok, I'll open a separate issue
2020-04-09 07:36:04 <ncopa> im gonna push rust triples fix(es) now
2020-04-09 07:40:00 <clandmeter> good luck and good morning
2020-04-09 07:41:15 <Cogitri> Morning
2020-04-09 07:41:20 <Cogitri> Thanks for taking care of that, ncopa
2020-04-09 07:42:03 <Cogitri> I don't want to be overly negative, but could you please pull a copy of the current Rust apks?
2020-04-09 07:42:10 <Cogitri> Just in case something goes wrong so we can bootstrap from those again
2020-04-09 07:47:00 <ncopa> good idea
2020-04-09 09:29:28 <mps> firefox-esr failed on edge with: WARNING: Python.h not found. Install Python development headers.
2020-04-09 09:29:56 <mps> is this related to latest python changes
2020-04-09 09:31:59 <Cogitri> The latest python changes only stopped python2 providing python
2020-04-09 09:32:13 <Cogitri> So if you install python2-dev everything should be the same
2020-04-09 09:33:21 <mps> ah, so FF need changes in makedepends
2020-04-09 09:34:48 <mps> how it passed on CI?
2020-04-09 09:41:15 <mps> hmm, a lot of changes: 'The target may be unsupported, or you may not have a rust std library for that target installed. Try:  rustup target add aarch64-unknown-linux-musl
2020-04-09 09:47:03 <Cogitri> Ah, you probably need to change the target triplets to CTARGET after the recent change to rust triplets
2020-04-09 09:47:09 <Cogitri> I can do that for you if you want to
2020-04-09 09:50:09 <mps> please do if you have time, or tell me what it is now (I thought that is that and started build test on aarch64 lxc)
2020-04-09 09:51:48 <mps> aarch64-alpine-linux-musl
2020-04-09 09:51:49 <mps> ?
2020-04-09 09:52:42 <ncopa> is the firefox build failing due to rust fixes?
2020-04-09 09:53:01 <ncopa> i think i pushed rust while builders were idle
2020-04-09 09:53:41 <ncopa> maybe we should disable firefox for now?
2020-04-09 09:55:09 <mps> ncopa: give Cogitri few minutes, he probably know what need to be changed
2020-04-09 09:58:36 <mps> yes, build starts with aarch64-alpine-linux-musl. now just have to wait about hour, I hope
2020-04-09 10:00:25 <Cogitri> No, no need to disable ff
2020-04-09 10:00:29 <Cogitri> We just need to set our new triplets
2020-04-09 10:03:33 <mps> change 'unknown' to 'alpine' I think?
2020-04-09 10:04:32 <Cogitri> Well no, we can remove it entirely since CTARGET == RUST_TARGET now
2020-04-09 10:04:54 <mps> ah, yes
2020-04-09 10:05:37 <Cogitri> I just hope that the target-lexicon will recognise our new triplets
2020-04-09 10:06:06 <Cogitri> (That's a Rust crate FF uses to recognise the triplets, and it's very funny to get it to work with nonstandard triplets)
2020-04-09 10:06:12 <_ikke_> What are these triplets used for?
2020-04-09 10:07:09 <Cogitri> Well, the triplets encode information about the target
2020-04-09 10:07:22 <Cogitri> E.g. max int size, padding between types, alignment and so on
2020-04-09 10:07:44 <Cogitri> Dunno why FF needs to know those, but maybe they're doing some fancy optimizations for specifiy target options
2020-04-09 10:08:07 <mps> hmm, aarch64-alpine-linux-musl looks like quartet (sorry for nitpicking again about that) (I'm fan of Descartes notes about clear language)
2020-04-09 10:08:31 <_ikke_> quadruplet?
2020-04-09 10:08:39 <Cogitri> Since I don't have a machine which is one of the arches which were changed, CI in !6557 tests the changes now
2020-04-09 10:08:48 <Cogitri> I'll apply to ff-esr if that works for ff
2020-04-09 10:09:17 <mps> Cogitri: I'm building now on aarch64 with aarch64-alpine-linux-musl
2020-04-09 10:09:34 <mps> it still not failed :)
2020-04-09 10:10:25 <ncopa> re triples: https://wiki.osdev.org/Target_Triplet
2020-04-09 10:10:32 <_ikke_> ncopa: thanks
2020-04-09 10:11:05 <ncopa> the rust package needs another fix, because it no longer builds with current APKBUILD
2020-04-09 10:11:18 <ncopa> so im planning to bump another pkgrel once the current rust package is uploaded
2020-04-09 10:11:20 <mps> Cogitri: did you pushed your changes about that? I don't see them in aports
2020-04-09 10:20:16 <Cogitri> No, as I mentioned it's in !6557
2020-04-09 10:20:31 <Cogitri> I want to have CI run over it before I push it if thats OK
2020-04-09 10:21:26 <mps> ok, will look in 15-20 minutes (now I'm out of house)
2020-04-09 10:32:08 <Cogitri> ncopa: I'll do a quick test build while i grab myself lunch and then push a fix, OK?
2020-04-09 10:33:23 <ncopa> ok
2020-04-09 10:34:30 <mps> Cogitri: I see your changes for firefox, is it ok to apply them for FF-esr
2020-04-09 10:57:02 <Cogitri> mps: I think so, yes, but I'd like to fix firefox first, push that and then if that works apply it to ff-esr
2020-04-09 10:59:26 <mps> ok, I'm testing FF-esr on aarch64 and soon will also on armv7
2020-04-09 11:01:39 <Cogitri> Thanks
2020-04-09 11:04:26 <mps> when we are at FF, did you considered moving FF back to testing? I fear that keeping it in community will make troubles for next stable because of rust releases changes
2020-04-09 11:05:51 <Cogitri> I had asked ncopa if he's fine with keeping rust  up-to-date for 3.12 but didn't get a reply on that, so I haven't thought about it yet, no
2020-04-09 11:06:49 <Cogitri> I personally think it's fine to keep Rust updated in 3.13 (and as such also FF). During the 6 months of support for community we'd have to bump Rust 4~5 times, which is acceptable IMHO
2020-04-09 11:07:10 <Cogitri> And since Rust still changes a lot from release to release I don't think having an old version of Rust in the repos helps many people
2020-04-09 11:07:26 <Cogitri> Especially since Rust folks are quick to jump on new features
2020-04-09 11:07:54 <mps> but that means rebuild every package which depeneds on rust in stable, which is trouble imo
2020-04-09 11:08:50 <Cogitri> Why would it mean that?
2020-04-09 11:08:56 <mps> and rust like to introduce changes which breaks packages
2020-04-09 11:09:39 <Cogitri> Hm, they have a pretty sane deprecation cycle by now
2020-04-09 11:10:33 <Cogitri> So unless your package does something obviously wrong that needs to be deprecated quickly (e.g. when Rust devs discovered some unsound behaviour in the borrow checker), you might get additional warnings with new versions of Rust but your build most likely wont fail
2020-04-09 11:10:38 <mps> ok, if you are sure then I will not insist (but still fell some fear)
2020-04-09 11:11:28 <Cogitri> Well, I personally am pretty confident that we can keep Rust updated in stable releases, but I won't insist on my position either
2020-04-09 11:11:49 <Cogitri> I just think that having Rust in stable relases but not updating it makes it basically useless to most folks after 6 weeks
2020-04-09 11:13:21 <mps> yes, not easy to come to sane solution
2020-04-09 11:16:25 <nmeum> is there any way to make `apk info` ignore installed packages? e.g. if different versions of a given package are installed and available in the repository information for both is displayed
2020-04-09 11:16:55 <_ikke_> nmeum: do you want apk policy?
2020-04-09 11:18:06 <nmeum> don't think so. I want to determine the size of a package as available in the repository, ignoring the size of the installed version of that package
2020-04-09 11:19:06 <nmeum> i think apk is missing some kind of --ignore-installed flag, e.g. apk info --size --ignore-installed vim would only display the size of the vim package available in the repository
2020-04-09 11:22:17 <Cogitri> mps: pushed ff, let's see if the builders like it
2020-04-09 11:22:32 <mps> Cogitri: ff-esr passed in lxc on aarch64
2020-04-09 11:23:06 <mps> now started on armv7
2020-04-09 11:23:43 <mps> Cogitri: yes, I see on #alpine-commits
2020-04-09 11:25:21 <oneinsect> FATAL ERROR: attr/error_context.h does not exist says abuild when trying to compile acl even though attr is installed and available at /usr/include/attr/err....
2020-04-09 11:25:31 <oneinsect> any ideas?
2020-04-09 11:29:36 <nmeum> _ikke_: just FYI, this is what I need this for: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/41/diffs#note_80070
2020-04-09 11:30:02 <_ikke_> nmeum: does the index contain the pkgsize?
2020-04-09 11:30:59 <nmeum> I think it's only stored in the .PKGINFO
2020-04-09 11:31:59 <_ikke_> So how would apk show you the pgksize of uninstalled packages?
2020-04-09 11:32:37 <nmeum> good point
2020-04-09 11:33:28 <nmeum> if the size would be recorded in the index, how would that help though?
2020-04-09 11:34:04 <_ikke_> Because the index is cached locally, it can get the information there
2020-04-09 11:34:09 <nmeum> just checked: the APKINDEX does seem to contain size information
2020-04-09 11:34:27 <nmeum> right, but how can I get apk info to ignore the locally cached index?
2020-04-09 11:35:30 <mps> Cogitri: ff-esr on armv7 passed configure and started compiling, have to wait about one hour again. Your changes works
2020-04-09 11:35:43 <Cogitri> Nice 👍️
2020-04-09 11:35:59 <mps> only have to see do we need fix 'NEON' on ff-esr
2020-04-09 11:37:00 <Cogitri> I don't think so
2020-04-09 11:37:10 <Cogitri> FF-esr doesn't ship aom yet (required for AV1 playback)
2020-04-09 11:37:48 <_ikke_> nmeum: apk info --no-cache?
2020-04-09 11:38:54 <nmeum> _ikke_: tried that already, doesn't seem to work :/
2020-04-09 12:46:09 <mps> Cogitri: ff-esr passed build on armv7, edge
2020-04-09 12:46:26 <Cogitri> Nice :)
2020-04-09 12:47:28 <mps> will you push changes or I?
2020-04-09 12:48:58 <mps> here is what pick from your MR http://tpaste.us/KyV9
2020-04-09 12:50:14 <Cogitri> You can remove the RUST_TARGET_PATH thingie
2020-04-09 12:50:45 <Cogitri> And you can probably move the case statement to one case which is arm*|x86*)
2020-04-09 12:50:55 <Cogitri> But other than that lgtm
2020-04-09 12:51:08 <mps> no, without it doesn't worked, at least on armv7
2020-04-09 12:51:21 <Cogitri> RUST_TARGET_PATH itself doesn't do a thing though
2020-04-09 12:51:43 <Cogitri> You'd need to move JSON files explaining what the triplets do at that path for it to do anything
2020-04-09 12:53:10 <mps> hmm, why it worked when I added RUST_TARGET_PATH but not before that
2020-04-09 12:53:24 <mps> will investigate
2020-04-09 13:41:13 <mps> I think I will package this https://github.com/exfat-utils/exfat-utils because RSN I will build and run kernel 5.7
2020-04-09 13:44:09 <mps> but not sure should it be in aports yet, or to wait we switch to kernels 5.7+
2020-04-09 14:20:17 <kmaxwell> mps: what will you call it? we already have an exfat-utils - the FUSE implementation - in community
2020-04-09 14:20:21 <kmaxwell> https://pkgs.alpinelinux.org/package/edge/community/x86_64/exfat-utils
2020-04-09 14:20:40 <kmaxwell> I am looking forward to the kernel support, packagin it sounds great!
2020-04-09 14:20:51 <mps> yes, I see
2020-04-09 14:21:20 <mps> but this new native tool is also called exfat-utils
2020-04-09 14:22:26 <kmaxwell> yeah I see the clash, I guess naming is one of the hard problems
2020-04-09 14:22:41 <mps> heh, yes
2020-04-09 14:22:56 <mps> native-exfat-utils :)
2020-04-09 14:23:35 <TBB> easy. name one exfat-utils and the other exfat-tools. no chance of causing confusion, ever!
2020-04-09 14:24:21 <mps> TBB: that was first idea in my head
2020-04-09 14:24:41 <mps> but it will be misleading, imo
2020-04-09 14:26:06 <mps> previous one (fuse) is named 'exfat' without suffix, but alpine added -utils
2020-04-09 14:27:50 <TBB> I'd perhaps add the -fuse into that one then. IDK.
2020-04-09 14:28:52 <mps> yes, that is proper naming, I think
2020-04-09 14:29:20 <mps> be it suffix or prefix (fuse)
2020-04-09 14:37:38 <Ariadne> rename the driver to exfat-fuse
2020-04-09 14:40:04 <mps> which one? current?
2020-04-09 15:13:53 <Ariadne> yes
2020-04-09 15:18:56 <mps> makes sense
2020-04-09 15:20:42 <maxice8> Any objections to pushing libffi=3.3-r0 ?
2020-04-09 15:20:51 <maxice8> !6482 is the MR for it
2020-04-09 15:25:10 <Cogitri> Nop
2020-04-09 15:36:39 <maxice8> ikke: :{} can i ping you to kill a builder if something gets stuck ?
2020-04-09 15:37:16 <_ikke_> Sounds like I'm a hitman :D
2020-04-09 15:37:29 <maxice8> of builders ? basically yes
2020-04-09 15:37:52 <_ikke_> But, sure
2020-04-09 15:38:02 <_ikke_> I'm not going anywhere anyway :D
2020-04-09 15:38:03 <Cogitri> lol
2020-04-09 16:09:54 <Ariadne> getting ready to do the -fno-common mock rebuild
2020-04-09 16:09:57 <Ariadne> :)
2020-04-09 16:15:14 <Cogitri> Seems like there's a fair bit of breakage
2020-04-09 16:15:25 <Cogitri> Exherbo switched to GCC10 already and they needed a fair bit of patching
2020-04-09 16:35:29 <Hello71> isn't it not out yet
2020-04-09 16:36:24 <Cogitri> GCC is out already
2020-04-09 16:37:18 <Hello71> well gcc has existed for some time
2020-04-09 16:37:23 <Hello71> that is true
2020-04-09 16:37:27 <Hello71> gcc 10 is not released
2020-04-09 16:37:34 <Hello71> it's not on https://gcc.gnu.org/ or https://gcc.gnu.org/pipermail/gcc-announce/2020/thread.html
2020-04-09 16:37:47 <Hello71> and https://gcc.gnu.org/gcc-10/changes.html says "GCC 10 has not been released yet"
2020-04-09 16:38:27 <Cogitri> Ah, you're right, somehow I though it's out already
2020-04-09 16:38:33 <Cogitri> I guess they tested with a RC then
2020-04-09 16:40:41 <Hello71> that has also not yet been released
2020-04-09 16:40:57 <Hello71> https://gcc.gnu.org/pipermail/gcc/2020-April/232005.html: There's still quite some work to do before ... a first release candidate of GCC 10
2020-04-09 16:42:18 <Hello71> https://repology.org/project/gcc/versions says exherbo has 10.0.1_pre20200405
2020-04-09 16:42:45 <Cogitri> Yus
2020-04-09 16:44:44 <Hello71> but it's masked, so users need to explicitly opt in
2020-04-09 16:46:08 <Hello71> so in conclusion it is not accurate to say "Exherbo switched to GCC10 already"
2020-04-09 16:46:39 <maxice8> That is so pedantic lol
2020-04-09 17:27:48 <mps> hmm, we can remove llvm5 now, or move to unmaintained
2020-04-09 17:27:57 <maxice8> remove
2020-04-09 17:27:59 <maxice8> :D
2020-04-09 17:34:05 <mps> I'm waiting crystal to pass on builder, and then will remove llvm5. any objection?
2020-04-09 17:34:26 <maxice8> not from me
2020-04-09 17:34:41 <mps> I knew for you already :)
2020-04-09 17:35:17 <mps> but maybe maintainer have objections :D
2020-04-09 17:35:28 <maxice8> yes
2020-04-09 17:35:51 <mps> hm, maintainer field is already removed
2020-04-09 17:35:53 <maxice8> I don't think the maintainer of llvm5 will raise any objections
2020-04-09 17:35:58 <maxice8> lol
2020-04-09 17:36:04 <mps> :D
2020-04-09 17:47:35 <Cogitri> I think we should just remove it
2020-04-09 17:52:18 <E1337> Anyone able to help me trouble-shoot a custom kernel install for alpine? Every time I attempt to install and reboot I get an error "mounting UUID=xxx /sysroot: No such device found". I can show my Kernel build steps and install steps and different things I have tried if it would help :)
2020-04-09 17:53:04 <Cogitri> That's a question for #alpine-ljnuc
2020-04-09 17:53:10 <Cogitri> s/ljnuc/linux/
2020-04-09 17:53:11 <alpine-meetbot> Cogitri meant to say: That's a question for #alpine-linux
2020-04-09 17:54:08 <E1337> Thanks :)
2020-04-09 17:57:15 <oneinsect> why do we have lua5.1 and then 5.2 and then 5.3 in aports/main?
2020-04-09 17:57:18 <oneinsect> so many versions?
2020-04-09 17:58:14 <TBB> incompatible ones, probably
2020-04-09 17:58:31 <oneinsect> hmmmm
2020-04-09 17:58:51 <maxice8> we also have luajit
2020-04-09 18:02:20 <maxice8> @mps can we remove llvm5 right now ? the build is broken and i don't feel like fixing it just to have it removed later :s
2020-04-09 18:04:27 <mps> yes, will you or I
2020-04-09 18:04:43 <maxice8> i'll rm it
2020-04-09 18:04:47 <mps> ok
2020-04-09 18:05:00 <maxice8> done
2020-04-09 18:05:25 <mps> I see, good :)
2020-04-09 19:14:19 <PureTryOut[m]> Can we do something about `apk upgrade` being broken when something like libffi or libicu gets upgraded?
2020-04-09 19:15:05 <maxice8> wait
2020-04-09 19:15:27 <Cogitri> We'd need proper staging in our repos for that
2020-04-09 19:15:38 <PureTryOut[m]> maxice8: except for waiting
2020-04-09 19:16:02 <_ikke_> edge is kind of our staging environment
2020-04-09 19:16:27 <PureTryOut[m]> At postmarketOS we don't publish anything unless everything for that arch has successfully built. Is that not an approach we can take?
2020-04-09 19:17:10 <_ikke_> PureTryOut[m]: afaik, it should only upload after it has done building
2020-04-09 19:18:04 <_ikke_> those uploaded messages in #alpine-commits are when it's done building and uploading everything
2020-04-09 19:18:07 <PureTryOut[m]> Then how do we get reports of "ERROR: Could not find dependency 'so:libffi.so.6' in any aports folder or APKINDEX."?
2020-04-09 19:19:54 <_ikke_> edge/main/x86_64: uploaded
2020-04-09 19:20:07 <_ikke_> so x86_64 main was finished
2020-04-09 19:20:16 <_ikke_> not sure why that would cause those messages though
2020-04-09 19:20:34 <maxice8> user has something in community/ that depends on something in main/ that was updated
2020-04-09 19:20:46 <_ikke_> right
2020-04-09 19:21:14 <maxice8> libffi is in main/ and now it provides libffi.so.7, maybe there is something in community like community/ecl, if you try installing it you will get that
2020-04-09 19:22:03 <PureTryOut[m]> Could we consider only uploading when the entire arch has finished?
2020-04-09 19:22:14 <PureTryOut[m]> That'd basically fix it
2020-04-09 19:24:45 <_ikke_> https://git.alpinelinux.org/aports/tree/jmain/aports-build/aports-build
2020-04-09 19:24:52 <_ikke_> This script would need to be modified
2020-04-09 19:26:59 <_ikke_> it does mean that if testing is breaking it would hold back main as well
2020-04-09 19:27:18 <maxice8> Well we can make it only on edge ?
2020-04-09 19:28:11 <PureTryOut[m]> I'd think it's useful on stable as well
2020-04-09 19:28:15 <PureTryOut[m]> And then again, we could exclude testing from it
2020-04-09 19:28:19 <PureTryOut[m]> It's not called testing for nothing
2020-04-09 19:28:29 <_ikke_> The loop in line 180 needs to move out of the loop it's in
2020-04-09 19:29:50 <PureTryOut[m]> Well that seems easy enough
2020-04-09 19:30:15 <PureTryOut[m]> What's the repository for it?
2020-04-09 19:30:40 <PureTryOut[m]> Oh, seems it doesn't have any?
2020-04-09 19:31:09 <PureTryOut[m]> Any reason for that? Can we move it to a git repo?
2020-04-09 19:32:59 <_ikke_> Something like this might work: http://tpaste.us/DDRz
2020-04-09 19:33:04 <_ikke_> PureTryOut[m]: ask ncopa
2020-04-09 19:42:30 <PureTryOut[m]> Well, ncopa? 😛 Would you consider moving aports-build to a git repo? I'd like to submit a change to only push the `main/` and `community/` repository when both repos have finished building to prevent errors when updating the system if a package in community hasn't been rebuild yet when depending on a package in main.
2020-04-09 19:49:01 <[[sroracle]]> i mean
2020-04-09 19:49:11 <[[sroracle]]> you can submit an MR now against aports
2020-04-09 19:49:24 <[[sroracle]]> thats orthogonal to what repo it's in
2020-04-09 19:50:23 <PureTryOut[m]> I know, but I rather not tbh. I prefer a clean git history in it's own repo
2020-04-09 19:50:59 <_ikke_> for proper history you would need to extract the history from aports
2020-04-09 19:51:13 <_ikke_> A subtree split or something like that
2020-04-09 19:52:24 <[[sroracle]]> you're going to have to do that anyway if you want to move it to its own repo, if you want to preserve the existing history that is
2020-04-09 19:58:54 <Ariadne> PureTryOut[m]: doing such would make it more difficult to have multiple builders working in parallel
2020-04-09 19:59:46 <Ariadne> the actual solution is to have two repos, one that the builders use internally, and one that is composed from that one based on what has been built successfully
2020-04-09 20:00:07 <_ikke_> Ariadne: it kind of works like that
2020-04-09 20:00:09 <_ikke_> not?
2020-04-09 20:00:15 <Ariadne> nope
2020-04-09 20:00:29 <Ariadne> edge is literally whatever came from the builders
2020-04-09 20:00:43 <_ikke_> yes, but at least per repo, it's only after it's built
2020-04-09 20:00:48 <_ikke_> everything
2020-04-09 20:00:59 <Ariadne> only after whatever the builder decided to build yes
2020-04-09 20:01:16 <Ariadne> but some  archs like arm and mips would benefit from having multiple builders and splitting the work between them
2020-04-09 20:01:18 <_ikke_> issue is that it uploads main alreayd, while community is not ready yet
2020-04-09 20:01:35 <Ariadne> so if we want to rework this, we should rework it properly to allow that
2020-04-09 20:01:54 <_ikke_> Ariadne: ncopa wants to redesign this process anyway
2020-04-09 20:02:16 <_ikke_> Similar to how gitlab does it with CI containers that are disposable
2020-04-09 20:02:42 <Ariadne> for example, arm and mips are chugging along on llvm10, while other packages could also be rebuilt at the same time
2020-04-09 20:02:50 <_ikke_> yup
2020-04-09 20:08:15 <mps> uhm, who pushed crystal 0.34.0
2020-04-09 20:09:02 <Cogitri> No one?
2020-04-09 20:09:11 <Cogitri> I still see 0.32.1 in the git repo
2020-04-09 20:09:34 <mps> ah, sorry, this was new push in MR
2020-04-09 20:09:40 <_ikke_> EUREKA
2020-04-09 20:10:09 <mps> anyone know who is J0WI?
2020-04-09 20:10:43 <maxice8> ikke: what happened ?
2020-04-09 20:10:44 <Cogitri> I only know them as J0WI on Gitlab, I think they're not in IRC
2020-04-09 20:11:10 <_ikke_> maxice8: was meant for another channel, but I have been fighting with iptables on my personal vps the last 2 days
2020-04-09 20:11:16 <_ikke_> finally got it working again
2020-04-09 20:11:42 <Cogitri> Nice :)
2020-04-09 20:11:46 <maxice8> nice
2020-04-09 20:12:46 <mps> Cogitri: s/he does a lot of work, but sometimes make a mess
2020-04-09 20:13:29 <Cogitri> Oh?
2020-04-09 20:15:34 <mps> this time I will ignore her/his MR for crystal, not nice behavior from me but don't like to go over all needed fixes
2020-04-09 20:15:54 <Cogitri> It's better to mention that in the MR instead of just ignoring it then
2020-04-09 20:16:06 <Cogitri> A polite rejection is still better than no reaction at all
2020-04-09 20:16:14 <mps> well
2020-04-09 20:16:43 <mps> I agree, but sometimes I'm not so patient :)
2020-04-09 20:52:20 <maxice8> ghc is in a bit of a pickle
2020-04-09 20:52:26 <maxice8> it needs itself to build itself but it can't use itself because it needs libffi.so.6
2020-04-09 20:52:57 <Cogitri> Yes, I hit that too with LLVm
2020-04-09 20:54:28 <maxice8> guess i'll have to add a libffi3.2 package that only provides that, make ghc depend on that and libffi-dev and then remove it when ghc rebuilds itself with the new libffi
2020-04-09 20:54:33 <maxice8> sounds good ?
2020-04-09 20:58:04 <Cogitri> Sounds like the only way forward
2020-04-09 20:58:20 <[[sroracle]]> a more long term solution would be to make the bootstrap version completely static
2020-04-09 20:59:54 <maxice8> Yes, but I'd like to unblock x86_64 soon
2020-04-09 20:59:57 <maxice8> It still has a bit to build I believe
2020-04-09 21:01:08 <Ariadne> hmm
2020-04-09 21:01:23 <Ariadne> mips built python3 before libffi
2020-04-09 21:01:28 <Ariadne> well mips64 anyway
2020-04-09 21:01:31 <Cogitri> Yes
2020-04-09 21:03:32 <Ariadne> this is why sequencing is important
2020-04-09 21:03:42 <Ariadne> libffi should have come before the rebuilds
2020-04-09 21:04:50 <Ariadne> if you do libffi bump, push, rebuilds
2020-04-09 21:04:56 <Ariadne> it will ensure that libffi come first
2020-04-09 21:06:28 <mps> heh, looks like I will wait tomorrow to push some updates/upgrades :)
2020-04-09 22:31:01 <mps> uh, crystal failed in colorize test, it worked on lxc with terminal but probably failed because builders doesn't have normal terminal
2020-04-09 22:32:39 <mps> will remove these tests tomorrow, now is to late here
2020-04-09 22:32:55 <maxice8> can i disable it for now so it doesn't block the builder ?
2020-04-09 22:33:04 <mps> ok, thanks
2020-04-09 22:33:15 <maxice8> i mean
2020-04-09 22:33:16 <maxice8> the package
2020-04-09 22:33:29 <mps> yes, I understood
2020-04-09 22:33:45 <mps> but if you want you can fix tests :)
2020-04-09 22:34:10 <maxice8> I do want tests to be fixed but i also want to end libffi=3.3-r0 upgrade so others can also do their stuff
2020-04-09 22:34:39 <mps> aha, understand, but added a little humor
2020-04-10 00:22:50 <Ariadne> maxice8: theres a lot that needs to be rebuilt again
2020-04-10 00:43:32 <maxice8> ?
2020-04-10 08:18:10 <ncopa> looks like mozjs60 rebuild was built againt libffi-3.2
2020-04-10 08:18:22 <ncopa> meaning that libffi was not upgraded for some reason
2020-04-10 08:18:48 <maxice8> libffi was upgraded but the builder botched the ordering
2020-04-10 08:19:05 <ncopa> mozjs60-60.9.0-r4 was supposed to rebuild it against libffi
2020-04-10 08:19:15 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/mozjs60/mozjs60-60.9.0-r4.log
2020-04-10 08:19:21 <ncopa> no, libffi was built before
2020-04-10 08:19:32 <ncopa> look at the date at the top of the build log
2020-04-10 08:19:48 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/libffi/libffi-3.3-r0.log
2020-04-10 08:20:00 <ncopa> libffi was built Thu, 09 Apr 2020 15:39:15 +0000
2020-04-10 08:20:23 <ncopa> and moz60js was built  Thu, 09 Apr 2020 16:49:39 +0000
2020-04-10 08:21:32 <maxice8> huh,  that looks terrible
2020-04-10 08:22:32 <ncopa> so for some reason, it did not install the updated libffi
2020-04-10 08:23:50 <Cogitri> I guess something else still pulled in the old libffi
2020-04-10 08:24:40 <ncopa> yeah
2020-04-10 08:24:43 <ncopa> it was python2
2020-04-10 08:25:16 <ncopa> mozjs60 pulls in python2, which was at that point still linked to old libffi
2020-04-10 08:25:31 <ncopa> python2 was rebuilt later: Thu, 09 Apr 2020 17:29:26 +0000
2020-04-10 08:25:47 <ncopa> algitbot: please don't be stupid
2020-04-10 08:27:06 <mps> ohm, BDFL doesn't respect CoC :)
2020-04-10 08:27:14 <maxice8> not sure because of lack of sleep but it is try to do my best, not try do my best
2020-04-10 08:27:25 <Cogitri> lol
2020-04-10 08:41:12 <mps> how can I run lxc to simulate builder
2020-04-10 08:42:04 <ncopa> in your lxc container, remove all uncessary deps, and then run aports-build
2020-04-10 08:42:05 <mps> now I ssh to lxc, start tmux and work what I have to, but that is not how builders run
2020-04-10 08:42:06 <_ikke_> mps: You want to test running without a tty I guess?
2020-04-10 08:42:17 <mps> _ikke_: yes
2020-04-10 08:44:02 <mps> last night I tested crystal locally and it pass without error but failed on builder because it missing color term (I think)
2020-04-10 08:44:51 <_ikke_> https://superuser.com/a/1430883/4134
2020-04-10 08:47:05 <mps> ah, will try. thanks
2020-04-10 08:47:39 <_ikke_> You could also use something like cron or atd to run it, but that would be more convoluted
2020-04-10 08:48:26 <mps> I would prefer to run 'by hand'
2020-04-10 08:48:31 <_ikke_> nod
2020-04-10 08:50:20 <ncopa> is it not enough to redirect the build to a file?
2020-04-10 08:57:29 <mps> for logging yes, but I'm not sure in this specific case where crystal tests writing to terminal
2020-04-10 08:57:55 <Cogitri> _ikke_: https://gitlab.alpinelinux.org/nilclass/aports somehow that's not public
2020-04-10 09:02:26 <_ikke_> I need to run the script manually, done now
2020-04-10 09:02:43 <Cogitri> Oh, I thought it runs automatically
2020-04-10 09:02:44 <Cogitri> Thanks
2020-04-10 09:13:13 <Cogitri> Can one of you squash and merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6421 ? When I change the commit message to adhere to our commit names and press merge it just gets stuck forever
2020-04-10 09:17:08 <nmeum> mps: you could also try setting TERM to dumb
2020-04-10 09:19:02 <mps> nmeum: this idea appeared few minutes ago in my mind, but didn't know will it work. now we are two with that in mind so I will try. thanks
2020-04-10 09:20:36 <mps> synchronicity at work :)
2020-04-10 09:20:41 <nmeum> no idea how the crystal test suite works but at least their colorize library seems to respect that seeting https://github.com/crystal-lang/crystal/blob/master/src/colorize.cr#L127-L130
2020-04-10 09:20:59 <nmeum> *setting
2020-04-10 09:23:59 <mps> I played just little with it to see that it works, but don't understand why they want it base language libs
2020-04-10 09:36:31 <minecrell> maxice8: in https://gitlab.alpinelinux.org/alpine/aports/-/commit/b6a2cf9a9fe21b1d060039b1ee5dbf95bd727bf9 you made the dev subpackage in mpfr4 provide mpfr-dev, but this doesn't make much sense at the moment because the dev subpackage is still called "mpfr-dev" for some reason (not "$pkgname-dev", see subpackages)
2020-04-10 09:36:45 <minecrell> and now that package cannot be installed anymore :)
2020-04-10 09:47:23 <Cogitri> fwiw they went to sleep a bit ago I think
2020-04-10 09:48:17 <_ikke_> maxice8 is in UTC-4
2020-04-10 09:48:28 <_ikke_> oh -3 atm
2020-04-10 09:54:57 <maxice8> It is 7 AM here
2020-04-10 09:55:22 <_ikke_> I hope you had enough sleep :)
2020-04-10 09:55:30 <maxice8> lol sleep
2020-04-10 09:55:43 <maxice8> It is good Friday, holiday
2020-04-10 09:57:31 <clandmeter> its everywhere holiday except in NL it seems.
2020-04-10 09:57:37 <maxice8> @minecrell my bad, I can fix it in about 8 hours
2020-04-10 09:58:04 <maxice8> I think non-catholic countries don't get this holiday, @Cogitri is it holiday for you?
2020-04-10 09:58:51 <Cogitri> It is a holiday for me
2020-04-10 09:59:09 <maxice8> Huh
2020-04-10 10:00:00 <Cogitri> Monday is a holiday for me too
2020-04-10 10:00:17 <maxice8> @clandmeter Netherlands appears in the list of countries that respect good friday
2020-04-10 10:00:38 <clandmeter> yes, but no holidays
2020-04-10 10:00:38 <Cogitri> Well, "holiday" as in time to catch up with uni homework :D
2020-04-10 10:00:57 <_ikke_> wikipedia says it's not a recognized holiday in the netherlands
2020-04-10 10:01:05 <clandmeter> maybe some companies will do it, but its not a rule.
2020-04-10 10:01:37 <minecrell> maxice8: no hurry, just wanted to report it :)
2020-04-10 10:02:24 <mps> heh, I'm for idea that every holiday in every country should be holiday for all us
2020-04-10 10:02:45 <clandmeter> or create a virus
2020-04-10 10:02:53 <mps> :)
2020-04-10 10:03:16 <mps> isn't it already done
2020-04-10 10:05:52 <clandmeter> what do you mean? which virus?
2020-04-10 10:06:21 <mps> heh ;)
2020-04-10 10:06:30 <clandmeter> jk, I hope everybody stays safe here.
2020-04-10 10:07:41 <mps> I never catch flu (or any of these viruses)
2020-04-10 10:08:48 <mps> ok, maybe I catch but I don't ever have any symptoms or illness when at least half of the people around me are ill
2020-04-10 10:09:52 <_ikke_> please don't understimate this one though :)
2020-04-10 10:10:06 <mps> and I don't take any special food, medicine or measures
2020-04-10 10:10:33 <mps> personally I don't care, I don't have fear of it
2020-04-10 10:10:57 <_ikke_> I don't feat it either, but I do take it serious
2020-04-10 10:11:01 <_ikke_> fear*
2020-04-10 10:11:21 <mps> maybe I'm safe because I drink alcohol and smoke good Dutch tobacco :)
2020-04-10 10:11:25 <nmeum> haha
2020-04-10 10:11:59 <mps> and, I don't eat or drink any 'sugar'
2020-04-10 10:12:30 <mps> I'm over 60 year but didn't visited doctor for about two decades
2020-04-10 10:12:48 <_ikke_> lots of healthy people have died to this
2020-04-10 10:13:52 <mps> I don't know and I don't want to give advises around
2020-04-10 10:14:02 <clandmeter> alcohol and tobacco, that sounds like a healthy diet
2020-04-10 10:14:08 <mps> everyone should think for self
2020-04-10 10:14:37 <mps> clandmeter: yes, it is, imo
2020-04-10 10:14:51 <mps> and sport, IO forgot
2020-04-10 10:15:01 <mps> s/IO/I/
2020-04-10 10:15:01 <alpine-meetbot> mps meant to say: and sport, I forgot
2020-04-10 10:15:27 <mps> and sense of humor and fun
2020-04-10 10:15:31 <clandmeter> rolling cigarettes is not a sport :p
2020-04-10 10:15:38 <mps> :D
2020-04-10 10:15:57 <clandmeter> not even sure how thats called in english
2020-04-10 10:16:04 <mps> this is first morning exercise with cup of coffee
2020-04-10 10:16:23 <mps> I think it is 'rolling'
2020-04-10 10:28:20 <minecrell> maxice8: I thought you wanted to sleep? :D Anyway, thanks for fixing it, seems to work fine again now :)
2020-04-10 10:28:44 <maxice8> I didn't, Cogitri forced me to
2020-04-10 10:29:16 <Cogitri> Heh
2020-04-10 11:40:55 <Cogitri> ncopa: Are you looking into rebuilding Rust with the new triplets again already?
2020-04-10 13:10:22 <justin_> o/
2020-04-10 13:10:59 <justin_> Hi there, I have an issue trying to package a Pypi package
2020-04-10 13:11:47 <Cogitri> Hello
2020-04-10 13:11:54 <justin_> No matter what I do abuild ends with errors
2020-04-10 13:12:13 <justin_> the package is pywal
2020-04-10 13:12:26 <justin_> and the error is
2020-04-10 13:12:33 <justin_> python3: can't open file 'setup.py': [Errno 2] No such file or directory
2020-04-10 13:16:11 <SerkanDevel[m]1> I'm trying to set up a local repo for packages that I've built. Do I have to configure lighttpd in a specific way, so that another alpine instance can pull updates or is just a change in the directory enough?
2020-04-10 13:18:13 <mps> SerkanDevel[m]1: I use darkhttp (small and simple) with rsync
2020-04-10 13:19:17 <Cogitri> justin_ Well, is there a setup.py in that dir? Is the builddir set correctly?
2020-04-10 13:19:47 <SerkanDevel[m]1> mps: I'll try that out
2020-04-10 13:22:42 <SerkanDevel[m]1> How do I change the port on that webserver?
2020-04-10 13:23:53 <SerkanDevel[m]1> port 80 doesn't work on any lxc-container
2020-04-10 13:25:24 <clandmeter> darkhttpd runs non root
2020-04-10 13:25:28 <clandmeter> so ports is probably 8080
2020-04-10 13:27:06 <SerkanDevel[m]1> And how do I run it as a background service?
2020-04-10 13:27:16 <justin_> OK, builddir was not set properly.
2020-04-10 13:27:24 <justin_> but I do not understand one thing.
2020-04-10 13:27:46 <justin_> for example mkmr (by Leo) does not have a builddir in APKBUILD and it builds just fine
2020-04-10 13:28:26 <_ikke_> justin_: builddir defaults to $srcdir/$pkgname-$pkgver
2020-04-10 13:28:42 <_ikke_> if it fits that pattern, you don't have to set it, but if it differs, you do need to define it
2020-04-10 13:28:51 <SerkanDevel[m]1> I have darkhttpd running on a container but I can't access it over the local network
2020-04-10 13:29:09 <justin_> Oh I see, thanks
2020-04-10 13:30:13 <justin_> So do I have to rename the tarbal in "source" or prefere to use a "builddir" section ?
2020-04-10 13:31:15 <_ikke_> You typically don't have influence on the directory in the archive
2020-04-10 13:31:26 <_ikke_> It's easier in that case to just specify the builddir as it is
2020-04-10 13:31:36 <justin_> Alright
2020-04-10 13:32:39 <mps> SerkanDevel[m]1: darkhttpd have subpkg darkhttpd-openrc
2020-04-10 13:32:56 <mps> it can be enabled to start on boot
2020-04-10 13:34:42 <mps> and you can specify port and address on which it listen
2020-04-10 13:36:02 <mps> is the llvm10 'stable/safe' to use for packages
2020-04-10 13:40:37 <mps> hmm, just looked, darkhhtpd need confd file probably
2020-04-10 13:42:13 <mps> uhm, llvm10 looks not safe: src/llvm/ext/llvm_ext.cc:1:10: fatal error: llvm/IR/DIBuilder.h: No such file or directory
2020-04-10 13:43:05 <Cogitri> ?
2020-04-10 13:44:10 <mps> this file is in /usr/include/llvm10/llvm/IR/DIBuilder.h
2020-04-10 13:44:46 <mps> shouldn't it be in /usr/include/llvm10/IR/DIBuilder.h
2020-04-10 13:45:19 <Cogitri> No, how would the include work then?
2020-04-10 13:45:30 <Cogitri> You just need -I/usr/include/llvm10
2020-04-10 13:46:02 <mps> ahm, no llvm10-config
2020-04-10 13:46:03 <Cogitri> The folders itself aren't versioned because then it'd break all applications which need llvm with every release
2020-04-10 13:47:32 <mps> should we have llvm10-config binary?
2020-04-10 13:49:02 <Cogitri> We have llvm-config in the llvm10-dev package in some dir and in llvm-dev it's in PATH
2020-04-10 13:49:09 <Cogitri> So just depend on llvm-dev
2020-04-10 13:49:26 <mps> yes, /usr/lib/llvm10/bin/llvm-config
2020-04-10 13:49:53 <mps> and symlink /usr/bin/llvm-config -> ../lib/llvm10/bin/llvm-config
2020-04-10 13:50:43 <Cogitri> Yes
2020-04-10 13:50:49 <Cogitri> I don't see the problem
2020-04-10 13:51:28 <mps> well, lets see
2020-04-10 13:52:05 <mps> but, iirc this was not the case with llvm{8,9} though not sure
2020-04-10 13:53:30 <Cogitri> It certainly exactly the same with llvm8 and 9
2020-04-10 13:53:39 <Cogitri> You can diff the two APKBUILDs if you want
2020-04-10 13:54:51 <Cogitri> And loads of upstream stuff can't cope with it being called anything but llvm-config
2020-04-10 13:56:20 <mps> I'm hit by upgrading crystal to use llvm10, earlier it worked with /usr/bin/llvm{ver}-config, but no with llvm10
2020-04-10 13:56:42 <mps> I will look why
2020-04-10 13:58:52 <mps> hm, look this: /usr/bin/llvm9-config -> ../lib/llvm9/bin/llvm-config
2020-04-10 13:59:53 <mps> in llvm10 only /usr/bin/llvm-config and no /usr/bin/llvm10-config
2020-04-10 14:04:15 <Cogitri> Yes, because llvm9 isn't the default llvm anymore (the latest version always is  the default)
2020-04-10 14:04:24 <Cogitri> But llvm10 is
2020-04-10 14:05:35 <mps> I thought so. anyway another symlink wouldn't hurt to have
2020-04-10 14:06:03 <mps> explicit one
2020-04-10 14:06:58 <Cogitri> Hm, sure, but most of the time you just want whatever is the latest LLVM
2020-04-10 14:07:56 <mps> yes, most of time, but when we upgrade to llvm11 there will be packages which need llvm10
2020-04-10 14:09:17 <mps> like there are packages which needs llvm9 for now
2020-04-10 14:09:45 <mps> and llvm9 was default till few days ago
2020-04-10 14:10:15 <ncopa> Cogitri: i dont think we need rebuild it again. i just updated the APKBUILD without actually rebuild
2020-04-10 14:10:39 <Cogitri> Yes, there are a few, but setting PATH has the same effect, doesn't it, mps?
2020-04-10 14:11:12 <Cogitri> But I think you have a point, having versioned llvm binaries for all versions makes it nice and uniform across all versions
2020-04-10 14:11:28 <mps> yes, I did already and building it now, but my note is about having it in better shape
2020-04-10 14:11:37 <Cogitri> ncopa: Right, I worded that badly
2020-04-10 14:12:09 <mps> Cogitri: nice that we agree :)
2020-04-10 14:21:40 <Cogitri> :)
2020-04-10 14:22:07 <Cogitri> If you want to you can make the change and I'll review it, I'll go through old issues now
2020-04-10 14:23:05 <mps> I trust you :)
2020-04-10 14:24:07 <mps> or, my trust is in your hands, to rephrase it better
2020-04-10 14:29:01 <mps> crystal have all_spec spec/all_spec.cr
2020-04-10 14:29:11 <mps> umm
2020-04-10 14:29:23 <mps> crystal have 4244 tests
2020-04-10 17:24:48 <andypost[m]> SpaceToast: please check !6340
2020-04-10 17:25:26 <SpaceToast> andypost[m]: as long as it builds it seems fine to me
2020-04-10 17:27:03 <andypost[m]> I did not check on mips but works for me
2020-04-10 17:28:19 <mps> is it ok for package to makedepends on self
2020-04-10 17:43:44 <maxice8> No, that is a circular dependency
2020-04-10 17:44:35 <_ikke_> I think abuild even filters it out
2020-04-10 17:55:05 <Cogitri> Yes, it filters that out
2020-04-10 17:55:14 <Cogitri> You can work around that with provides though (see Rust for how to do that)
2020-04-10 17:55:45 <_ikke_> ghc as well
2020-04-10 17:58:21 <mps> it worked in my test for community/shards
2020-04-10 17:58:35 <mps> but, yes, I agree it is not fine
2020-04-10 18:06:21 <mps> I have dilemma, how to name name this pkg, https://github.com/crystal-lang/crystal-molinillo ? crystal-molinillo or molinillo
2020-04-10 18:17:28 <andypost> mps, as it tightly coupled to lang, better keep prefix
2020-04-10 18:19:15 <mps> andypost: makes sense
2020-04-10 18:52:50 <Cogitri> Could someone with a RPI look into https://gitlab.alpinelinux.org/alpine/aports/issues/9189 ?
2020-04-10 18:52:56 <Cogitri> Currently going through old issues again
2020-04-10 18:53:29 <mps> which RPi board version
2020-04-10 18:55:03 <Cogitri> The reporter only mentions `original RPI (0002)` so I don't really know
2020-04-10 18:55:29 <mps> i have only rpi zero W
2020-04-10 18:56:20 <artok> that is the truly original, by numbering 0002
2020-04-10 18:57:51 <clandmeter> mpmc: ^
2020-04-10 19:17:37 <Cogitri> Ariadne: https://gitlab.alpinelinux.org/alpine/aports/issues/9641
2020-04-10 19:19:51 <mps> Cogitri: hm, I can't test this issue https://gitlab.alpinelinux.org/alpine/aports/issues/9189, I don't have this small hdmi cable (micro/mini?) which is needed for rpi zero
2020-04-10 19:21:22 <Cogitri> I think it's mini hdmi
2020-04-10 19:21:28 <Cogitri> Anyway, thanks for trying :)
2020-04-10 19:23:44 <mps> np
2020-04-10 19:33:56 <Ariadne> cogitri that's old and resolved
2020-04-10 19:34:39 <Cogitri> Thanks, wasn't sure. Can you maybe close it then?
2020-04-11 04:12:29 <iggy> looks like there aren't any aarch64 runners currently available
2020-04-11 07:17:32 <_ikke_> iggy: should be fixed now, the host was having issues
2020-04-11 07:19:26 <iggy> thank you
2020-04-11 07:19:44 <mps> iggy: you put 'strange' character in commit message 'testing/micro: upgrade to 2.0.3 '
2020-04-11 07:23:39 <iggy> I will try no to let that happen again, I accidently had the github mirror as master and had trouble catching up to gitlab:master
2020-04-11 07:24:10 <iggy> now I've got all the github stuff out of my tree hopefully
2020-04-11 07:25:01 <mps> I think it is better to use gitlab.a.o as master/origin
2020-04-11 07:25:14 <iggy> that's what I have now
2020-04-11 07:25:20 <mps> nice
2020-04-11 07:25:52 <iggy> I didn't even realize I had the gh as master until I saw issues with merging into master on gitlab
2020-04-11 07:26:06 <mps> and ok, errors and mistakes happens, don't worry :)
2020-04-11 08:19:03 <Cogitri> Hm, does someone know autotools a bit better than me and knows how to fix https://github.com/signalwire/freeswitch/issues/557 ?
2020-04-11 08:19:21 <Cogitri> I guess they typo'ed with ibdir instead of libdir somewhere but I can't find that with grep
2020-04-11 08:46:56 <mps> probably
2020-04-11 08:53:14 <iggy> I'd guess it's a `-libdir` being read as `-l` `ibdir`
2020-04-11 08:53:33 <Cogitri> Oh, that could be it too 🤔
2020-04-11 08:53:34 <Cogitri> Let's see
2020-04-11 10:43:09 <mps> fabled: if you have some time I would ask you about strange issue with apk-tools on armv7 with kernel 5.6 (which is not officially in alpine). and when you find time
2020-04-11 11:36:54 <fabled> mps, email to mailing list might be better? i'm quite sporadic here on irc nowadays
2020-04-11 11:37:47 <mps> ok, probably will open bug/issue in gitlab.a.o
2020-04-11 15:01:02 <ollieparanoid[m]> hey all! py3-flake8 is currently broken in edge, because it depends on a specific version of py3-pyflakes, and pyflakes was updated
2020-04-11 15:02:20 <ollieparanoid[m]> I'll prepare patches to fix this, first by applying https://gitlab.com/pycqa/flake8/-/merge_requests/417 to flake8, so it works with the newest pyflakes version. this is an unmerged patch, the latest release of flake8 is still not comaptible with pyflakes
2020-04-11 15:02:33 <ollieparanoid[m]> and to make sure we don't run into this in the future I'll add a note to the pyflakes package that it should only be upgraded together with flake8 in alpine
2020-04-11 15:03:14 <ollieparanoid[m]> let me know if anybody has a problem with that approach, working on the patches  now
2020-04-11 15:04:43 <Cogitri> Sounds good to me. Let's hope we get automatic deps for python packages (and as such version constraints) soon so this doesn't happen again :)
2020-04-11 15:15:08 <ollieparanoid[m]> yeah :)
2020-04-11 15:15:21 <ollieparanoid[m]> I'll create an issue, so I can reference it in the APKBUILDs
2020-04-11 15:15:41 <kmaxwell_> ollieparanoid: sounds like a good approach, I think I proposed the upgrade, didn't realise they're closely coupled
2020-04-11 15:16:34 <kmaxwell_> Cogitri: do you know is anyone working on automatic deps for python packages?
2020-04-11 15:16:50 <ollieparanoid[m]> np, it's not really obvious now
2020-04-11 15:17:47 <Cogitri> kmaxwell_: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24
2020-04-11 15:19:31 <kmaxwell_> thanks!
2020-04-11 15:51:58 <ollieparanoid[m]> here's my flake8 fix: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6664
2020-04-11 16:02:12 <ollieparanoid[m]> (would be great if somebody could take a look at it some time soon, right now the pmbootstrap CI pipeline is broken because of this)
2020-04-11 16:08:00 <Cogitri> ollieparanoid[m]: Done :)
2020-04-11 16:08:41 <ollieparanoid[m]> Cogitri: thanks! \o/
2020-04-11 16:24:53 <mps> how to disable building 'luaapk' in apk-tools?
2020-04-11 16:26:47 <Cogitri> make LUAAPK=""
2020-04-11 16:27:00 <Cogitri> You can build without SCDOC with `make SCDOC=""`
2020-04-11 16:27:18 <mps> ah, thanks
2020-04-11 16:27:18 <Cogitri> (Yes, the build system is meh, but we can't use !make because then we'd need more things for bootstrapping)
2020-04-11 19:51:27 <timlegge> !6669 commit title corrected
2020-04-11 20:07:42 <maxice8> upgrade to <version>
2020-04-11 20:07:42 <maxice8> not upgrade to version <version>
2020-04-11 22:52:17 <timlegge> maxice8: thanks.  Normally look at previous commits and forgot... fixing now
2020-04-11 22:55:54 <mps> timlegge: ask maxice8 for his githooks prepare-commit-msg, it helps me
2020-04-11 22:56:57 <timlegge> mps: thanks I will
2020-04-11 22:57:42 <timlegge> maxice8: mps tells me you have a  githooks prepare-commit-msg :-) that might help me...
2020-04-11 23:52:09 <maxice8> @timlegge See: prepare-commit-msg and pre-commit files https://github.com/maxice8/meltryllis/tree/master/alpinelinux
2020-04-12 00:04:28 <timlegge> thanks maxice8
2020-04-12 00:25:23 <maxice8> welcome
2020-04-12 08:28:03 <maxwell-k> if I have a directory full of packages (.apk files) and I delete one is there an easy way to update the index?
2020-04-12 08:36:10 <Cogitri> abuild index
2020-04-12 08:44:09 <maxwell-k> thanks
2020-04-12 08:44:39 <maxwell-k> I was trying apk index and struggling
2020-04-12 09:07:03 <maxwell-k> if an APKBUILD has the name of a package on PyPI, should it be called _pkgname or _pyname?
2020-04-12 09:07:49 <maxice8> can you give an example ?
2020-04-12 09:08:23 <Cogitri> It really doesn't matter much, it's called _pkgname for a reason (it's not an official variable)
2020-04-12 09:08:28 <Cogitri> It's just private to the APKBUILD
2020-04-12 09:09:47 <maxwell-k> these three all use _pkgname: main/py3-chardet main/py3-docutils main/py3-pygments
2020-04-12 09:10:03 <maxwell-k> main/py3-wheel which I'm working on now uses _pyname
2020-04-12 09:10:10 <maxice8> it is irrelevant as long as it isn't something ridiculous
2020-04-12 09:11:11 <maxwell-k> agree it is irrelevant just now, it might become relevant much later
2020-04-12 09:11:57 <maxice8> it is a private variable
2020-04-12 09:13:38 <maxwell-k> yes, however it appears to be a part of the policy: https://wiki.alpinelinux.org/wiki/Python_package_policies
2020-04-12 09:14:30 <maxwell-k> like the examples above more packages use _pkgname than follow that policy, hence I ask
2020-04-12 09:20:12 <_ikke_> More descriptive  names are preferable
2020-04-12 09:20:50 <_ikke_> _pkgname doesn't really tell much
2020-04-12 09:39:23 <maxwell-k> good point
2020-04-12 09:39:47 <maxwell-k> I had missed the section on the talk page for that policy, I've added to it based on our discussion
2020-04-12 18:57:34 <grafoo> hey, i'm trying to get libffado running under 3.11.5, which uses sigval_t.
2020-04-12 18:59:10 <grafoo> glibc provides this and other related types in bits/types/*, but i can't find them in musl.
2020-04-12 18:59:49 <Ariadne> i would suggest asking in #musl :)
2020-04-12 19:01:00 <grafoo> Ariadne: i thought someone ran into this already while building other libs, so i came here first.
2020-04-12 19:01:53 <Ariadne> no, sigval_t is rarely used
2020-04-12 19:05:53 <Ariadne> i'm curious as to why libffado would need it
2020-04-12 19:11:47 <grafoo> Ariadne: sorry can't say. i'm no ffado dev, just trying to get my audo interface working.
2020-04-12 19:14:31 <grafoo> they're using it for some message queueing as far as i can tell.
2020-04-13 06:13:39 <Cogitri> http://lkml.iu.edu/hypermail/linux/kernel/2004.1/02939.html neat, it's now possible to compile kernel 5.7 with CLang by flicking a single switch
2020-04-13 06:23:51 <mps> yes, but I still prefer gcc, building 5.7-rc1 right now
2020-04-13 06:31:17 <Cogitri> Does someone know how we decide when to tag a new release for ca-certificates?
2020-04-13 06:35:53 <oneinsect> can we build most of the APKBUILDS using CLang
2020-04-13 06:35:57 <oneinsect> did anyone try?
2020-04-13 06:36:05 <oneinsect> putting aside the kernel
2020-04-13 06:36:29 <Cogitri> We probably could, but it's probably not worth the effort right now
2020-04-13 06:36:49 <oneinsect> hmmmm
2020-04-13 06:37:44 <oneinsect> btw buildroot doesnt actually copy the toolchain
2020-04-13 06:37:58 <oneinsect> i mean it just doesnt bundle the gcc in the images
2020-04-13 06:38:01 <oneinsect> wonder why
2020-04-13 07:11:48 <Ariadne> maxice8: can we start to throttle back on big pushes
2020-04-13 07:12:02 <Ariadne> we need to green the tree so we can start preparing for branching 3.12
2020-04-13 07:12:44 <maxice8> What is in the big pushes set ?
2020-04-13 07:12:58 <Ariadne> the bash-completion stuff you just did broke community/udisks2
2020-04-13 07:16:41 <maxice8> I'll pass through CI next time
2020-04-13 09:48:10 <Cogitri> Can we detect broken so dependencies on all packages in the repo? I think more packages than just these https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6736 weren't rebuilt correctly against the new libffi
2020-04-13 10:29:43 <timo-k> Hello everyone! I'm trying to make an ISO for a live CD which boots, sets up network and starts ssh server, all this unattended. I already managed to generate a working ISO image where I added openssh and kmod (needed to get realtek nic working) apks. The first challenge I faced is how to get those apks automatically installed at boot time. Any ideas?
2020-04-13 10:30:23 <oneinsect> like rpi or arm live
2020-04-13 10:30:33 <oneinsect> lbu commit does that for rpi live
2020-04-13 10:30:36 <oneinsect> after apk add
2020-04-13 10:31:06 <oneinsect> i havent looked at how to do it on x86
2020-04-13 10:31:44 <_ikke_> same process
2020-04-13 10:32:02 <_ikke_> create an apkovl file in the root of the boot media
2020-04-13 10:32:16 <oneinsect> but there is no space on a live cd
2020-04-13 10:32:30 <_ikke_> correct, it's a read-only filesystem
2020-04-13 10:32:31 <oneinsect> actual physical cd if you mean
2020-04-13 10:32:34 <_ikke_> so you'd need to bake it in
2020-04-13 10:32:38 <oneinsect> correct
2020-04-13 10:32:48 <timo-k> Yes physical CD
2020-04-13 10:33:13 <oneinsect> he needs to create a chroot then add whatever he wants
2020-04-13 10:33:18 <oneinsect> and then make an iso out of it
2020-04-13 12:03:33 <timo-k> I realized that genapkovl-dhcp.sh does almost what I wanted
2020-04-13 12:24:18 <timo-k> Ok, I have no almost working ISO. For some reason it didn't give hostname to the DHCP-server. And I can't ssh yet because root doesn't have password...
2020-04-13 12:25:38 <Cogitri> Classic, that happens to me about every time I set up a new system
2020-04-13 12:58:37 <maxwell-k> I was just suprised to learn that python3 is now a dependency for abuild (via pax-utils)
2020-04-13 12:59:00 <oneinsect> no its not
2020-04-13 12:59:13 <oneinsect> from pax-utils it only uses scanelf
2020-04-13 12:59:16 <maxwell-k> https://gitlab.alpinelinux.org/alpine/aports/-/commit/65d7341d091149ee453bcca5673b8728d1b1459c
2020-04-13 12:59:56 <maxwell-k> sorry to disagree, but yes it is
2020-04-13 13:00:00 <oneinsect> authored 3 hours ago by Leo
2020-04-13 13:00:02 <oneinsect> sad
2020-04-13 13:00:22 <maxwell-k> the other place to check is https://pkgs.alpinelinux.org/package/edge/main/x86_64/pax-utils under dependencies
2020-04-13 13:00:32 <oneinsect> makes it even more complex to bootstrap
2020-04-13 13:02:05 <maxwell-k> I haven't thought through the implications yet, just mentioning so other people aren't surprised; took me a minute to figure out what was going on
2020-04-13 13:02:28 <oneinsect> for someone bootstrapping it will be huge burden
2020-04-13 13:02:30 <mps> that's not good to hear
2020-04-13 13:04:44 <maxice8> Guess we can split lddtreepax out then
2020-04-13 13:04:52 <maxice8> It uses python3 and py3-elftools
2020-04-13 13:05:35 <maxwell-k> I personally would appreciate it if they were split out, makes my life slightly easier right now
2020-04-13 13:06:06 <maxice8> I'm in doctor RN
2020-04-13 13:06:17 <maxice8> In a few hours
2020-04-13 13:06:56 <mps> maxice8: I hope nothing serious, and you are ok
2020-04-13 13:07:10 <maxice8> It isn't
2020-04-13 13:07:11 <maxwell-k> maxice8: I hope you're OK too, thank you
2020-04-13 13:07:32 <maxice8> It's monthly checkup for the surgery I did in August 2019
2020-04-13 13:53:58 <minecrell> Maybe you can just change the abuild depends from `pax-utils` to `scanelf`? Does abuild even use something other than scanelf from pax-utils?
2020-04-13 14:40:12 <timo-k> I tried to create a user with a password into the ISO image by putting something like this into the apkovl script:
2020-04-13 14:40:12 <timo-k> echo 'admin:x:1000:1000:Linux User,,,:/home/admin:/bin/ash' >>"$tmp"/etc/passwd
2020-04-13 14:40:12 <timo-k> But now all other users are dropped from the ISO image.
2020-04-13 14:40:12 <timo-k> How should I do this?
2020-04-13 14:50:58 <maxice8> !6756 to have abuild depend only on scanelf
2020-04-13 14:53:26 <oneinsect> thanks maxice8:
2020-04-13 15:21:05 <zfoo> the microsoft site says there is an Alpine package for dotnet core, but I can't find it in the package list, does it still exist?
2020-04-13 15:21:39 <Cogitri> I guess they might build it themselves in a custom alpine based docker container?
2020-04-13 15:49:03 <timo-k> Please tell me how is e.g. /etc/passwd created? I hacked main/alpine-baselayout/passwd but my changes didn't appear in ISO image.
2020-04-13 15:50:24 <oneinsect> quick question why cant abuild use tar xz during unpack() functions, it throws this error unxz: unrecognized option: threads=0
2020-04-13 15:50:24 <oneinsect> BusyBox v1.31.1 () multi-call binary.
2020-04-13 15:50:37 <maxice8> need to install xz ?
2020-04-13 15:51:42 <oneinsect> i mean why cant it use tar
2020-04-13 15:51:42 <maxice8> lines 511 to 514 of /usr/bin/abuild
2020-04-13 15:52:05 <maxice8> huh ?
2020-04-13 15:52:20 <maxice8> it uses xz and passes to tar
2020-04-13 15:52:44 <maxice8> or rather, unxz
2020-04-13 15:52:56 <oneinsect> i mean tar xf works for me manually
2020-04-13 15:53:00 <oneinsect> in the same chroot
2020-04-13 15:53:26 <maxice8> i assume they just call unxz under the hood ?
2020-04-13 15:53:31 <oneinsect> yes
2020-04-13 15:54:42 <maxice8> no real difference except that it checks if xz links to /bin/busybox and if not it passes --threads to unxz | tar
2020-04-13 15:55:07 <oneinsect> yeaaa
2020-04-13 15:59:12 <timo-k> Should I clean up something before running again mkimage.sh
2020-04-13 16:25:22 <timo-k> Why is there etc/passwd both in the alpine-baselayout--.apk package and in aports/main/alpine-baselayout folder?
2020-04-13 16:26:22 <artok> aports/main/alpine-baselayout  creates the apk package
2020-04-13 16:26:36 <artok> with abuild
2020-04-13 16:27:20 <timo-k> My confusion shows
2020-04-13 16:28:12 <timo-k> Why it then seems to download the .apk from the repository?
2020-04-13 16:29:01 <timo-k> "Downloading alpine-baselayout-3.2.0-r5"
2020-04-13 16:29:01 <artok> aports has instructions to create packages with abuild, and those are uploaded to repositories
2020-04-13 16:30:09 <artok> creating your own packages, so add your local directory to /etc/apk/repositories
2020-04-13 16:31:09 <artok> check abuild info from wiki "creating alpine packages"
2020-04-13 16:34:34 <timo-k> Is this something like when I run mkimage.sh it uses packages from the repository if available?
2020-04-13 16:36:27 <timo-k> I'm not trying to create my own package, I'm trying to hack the alpine-baselayout package. mkimage.sh creates a working ISO for me but those hacks are not there...
2020-04-13 16:36:30 <artok> it uses apk to install the packages, so yes
2020-04-13 16:37:25 <timo-k> Ok, so I need an additional step, where I actually build the package?
2020-04-13 16:37:38 <artok> hack the aports alpine-baselayout, have version id for that, build it, it will add the package to your local repo
2020-04-13 16:37:53 <artok> run abuild in the directory
2020-04-13 16:38:35 <artok> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2020-04-13 16:38:40 <artok> "lue ja ymmärrä" =)
2020-04-13 16:39:49 <timo-k> Moon jo oppinu paljon enemmän kuin halusin. Piti vaan lisätä passwd/group/shadow tiedostoihin yksi nimi lisää...
2020-04-13 16:41:03 <artok> I don't remember what was your final purpose..
2020-04-13 16:43:21 <timo-k> I'm trying to create a rescue CD for a headless server. It must be physical CD to be able to boot without access to bios menus. I am in a state, that it boots and sets up network and ssh and I can try to login with ssh but fails because root can't login and there is no other users.
2020-04-13 16:46:50 <artok> init script could add some users
2020-04-13 16:48:29 <timo-k> But then I had to create brand new apk for that?
2020-04-13 16:48:52 <artok> just modify initrd ?
2020-04-13 16:52:29 <c705> timo-k: you might also wish to explore the scripts in aports/scripts. you can make your own custom iso build scripts, though unfortunately, it's not well documented (yet)
2020-04-13 16:53:36 <artok> well yeah that is also good way to add script to init
2020-04-13 16:53:53 <artok> as it does create the initrd =)
2020-04-13 16:54:40 <c705> artok: still trying to figure out how to directly manipulate the initrd, but yeah!
2020-04-13 16:55:16 <artok> directly? it is cpio archive
2020-04-13 16:55:21 <timo-k> Where the initrd is created?
2020-04-13 16:55:58 <c705> i was specifically looking at how to add modules to the initfs, but i gave up after i no longer needed to do that
2020-04-13 16:56:34 <artok> mkinitfs script is there
2020-04-13 16:57:16 <timo-k> In aports/scripts?
2020-04-13 16:57:33 <timo-k> cd ..
2020-04-13 16:57:45 <timo-k> Wrong window...
2020-04-13 16:58:36 <timo-k> Ah, in main as a package
2020-04-13 17:07:51 <timo-k> Doesn't that mean that I had to hack the mkinitfs-x.tar.xz source?
2020-04-13 17:19:38 <artok> what you are trying to do, there is few things... add user stuff to lbu commit and then boot alpine basic with that, or then create own initramfs that will start all needed services
2020-04-13 17:25:40 <timo-k> "add user stuff to lbu commit" - you mean basically to extract the ISO, modify apkovl and packing it again into an ISO? Yes, that is one alternative. I'm still hoping to be able to pop out an ready ISO from aports...
2020-04-13 17:26:54 <timo-k> I think I'm quite close with the alpine-baselayout. I only have to learn how to trigger the actual rebuild...
2020-04-13 17:27:43 <timo-k> Trying to digest your link...
2020-04-13 18:15:16 <timo-k> Heh - I succeeded. Perhaps I thought building a package would be harder than it really was
2020-04-13 18:16:18 <timo-k> Now only have to find a CD-drive and a CDR - are they still manufactured...?
2020-04-13 18:19:19 <Cogitri> Why not use an usb stick? That's way faster and probably even cheaper
2020-04-13 18:20:22 <timo-k> This goes to headless server. I can't boot from USB as I have no access to BIOS menus
2020-04-13 18:21:05 <timo-k> USB-stick would have been really easy...
2020-04-13 18:22:51 <Cogitri> Huh, a headless server with a CD-drive?
2020-04-13 18:27:20 <timo-k> It is for rescue
2020-04-13 18:27:29 <artok> cd-drive is ok but usb is not? =)
2020-04-13 18:27:51 <artok> what a security =)
2020-04-13 18:28:21 <artok> it does slow you down, needing to boot from cd rather than inserting usb stick
2020-04-13 18:29:17 <timo-k> Yes but it is for rescue only and USB would not work at all
2020-04-13 22:00:34 <Ariadne> timlegge: apkovl replaces files on disk with the ones you provide
2020-04-13 22:00:38 <Ariadne> er
2020-04-13 22:00:43 <Ariadne> timo-k: ^
2020-04-13 22:14:19 <[[sroracle]]> Cogitri: apk dot --errors is the standard way to look for broken deps. I've also been working on a tool to do a similar thing (also to look for outdated deps)
2020-04-14 00:32:34 <timlegge> for !6770 please read the description in case there it a conflict there in packager versus underlying module maintainer - Also perl-moose is missing a dependency on perl-devel-overloadinfo
2020-04-14 02:21:43 <[[sroracle]]> Cogitri: this is some example output. looks like racket is the last package missing an ffi rebuild https://dev.sick.bike/alpine.html
2020-04-14 03:01:35 <Ariadne> [[sroracle]]: you forgot to do it with mips64 too
2020-04-14 03:01:36 <Ariadne> :p
2020-04-14 03:02:38 <[[sroracle]]> the testing repo doesn't appear to be available for mips64 yet
2020-04-14 03:02:48 <[[sroracle]]> i could run it against just main and community if you want though
2020-04-14 03:13:45 <Ariadne> i can publish it, but it's not fully there yet
2020-04-14 03:25:29 <[[sroracle]]> this is main/community only, including mips64 https://dev.sick.bike/alpine-mips64.html
2020-04-14 03:29:42 <maxice8> that is super useful
2020-04-14 03:32:03 <[[sroracle]]> i have a separate tool that checks for package version spread across architectures, i can run that too if you want
2020-04-14 03:32:28 <maxice8> package version spread ?
2020-04-14 03:33:07 <[[sroracle]]> like if one architecture doesn't have the newest version of a package compared to others
2020-04-14 03:33:12 <[[sroracle]]> or if it's missing entirely
2020-04-14 03:34:40 <maxice8> I see
2020-04-14 03:34:47 <maxice8> i'll behaving some fun with that link you sent :D
2020-04-14 03:34:55 <[[sroracle]]> i'm sure :p
2020-04-14 03:36:19 <maxice8> How frequently it checks stuff again ?
2020-04-14 03:36:23 <maxice8> there are a few things that don't make much sense
2020-04-14 03:38:05 <[[sroracle]]> what specifically? it's only manually run, so things may have changed in the meantime
2020-04-14 03:38:49 <maxice8> there are a few packages that have missing so:librsvg-2.so.2 on s390x
2020-04-14 03:38:55 <maxice8> like xfce4-xkb-plugin
2020-04-14 03:39:02 <maxice8> but that package has !s390x in arch=""
2020-04-14 03:39:32 <maxice8> basically for all that has missing so:librsvg-2.so.2 like jwm and netsurf
2020-04-14 03:39:50 <Ariadne> this is really cool
2020-04-14 03:39:52 <[[sroracle]]> xfce4-xkb-plugin appears to be available on s390x. maybe missing cleanpkg/cleanoldpkg
2020-04-14 03:39:58 <[[sroracle]]> http://dl-cdn.alpinelinux.org/alpine/edge/community/s390x/xfce4-xkb-plugin-0.8.1-r1.apk
2020-04-14 03:40:06 <maxice8> oh
2020-04-14 03:40:18 <Ariadne> i would still like to provide older librsvg on platforms that do not have rust
2020-04-14 03:40:32 <Ariadne> but i don't know that it is a good idea
2020-04-14 03:40:44 <Ariadne> maybe it is a better idea to write QtSVG wrapper that provides librsvg API :)
2020-04-14 03:41:08 <[[sroracle]]> simiarly with the other rsvg rdeps
2020-04-14 03:41:24 <Ariadne> it should be possible in theory
2020-04-14 03:41:46 <maxice8> http-parser is failing on aarch64 and armhf
2020-04-14 03:42:09 <Ariadne> yes
2020-04-14 03:42:35 <maxice8> the test in question adds up a whole lot of numbers including sizeof(void *)) and expects it to be 8 while it is 4 on those arches from what i tested
2020-04-14 03:43:09 <Ariadne> that's not the problem
2020-04-14 03:43:17 <Ariadne> the problem is that the struct is padded on ARM
2020-04-14 03:43:43 <Ariadne> for alignment
2020-04-14 03:45:49 <maxice8> hmm
2020-04-14 03:47:15 <Ariadne> one thing i just noticed with gitlab migration is
2020-04-14 03:47:36 <Ariadne> if an alpine developer accepts an MR, it no longer puts them as the committer field
2020-04-14 03:48:16 <Ariadne> which is annoying because developers are responsible for the things they choose to merge
2020-04-14 03:48:36 <Ariadne> instead, now, you have to look it up in gitlab
2020-04-14 03:48:38 <maxice8> Where is the committer field ?
2020-04-14 03:49:38 <Ariadne> https://git.alpinelinux.org/aports/commit/?id=243f6674
2020-04-14 03:49:44 <Ariadne> see committer field below author
2020-04-14 03:49:54 <maxice8> I mean, in the commandline
2020-04-14 03:52:17 <Ariadne> git log --format="%cN <%cE>"
2020-04-14 03:52:49 <maxice8> i see
2020-04-14 03:53:07 <Ariadne> i guess it only happens with fast-forward merges
2020-04-14 03:53:19 <Ariadne> sometimes commiter field is right
2020-04-14 05:55:02 <_ikke_> maxice8: netcdf-fortran fails on s390x due to missing deps
2020-04-14 05:55:43 <maxice8> oh
2020-04-14 07:37:13 <PureTryOut[m]> Is there an example of a Golang package somewhere?
2020-04-14 07:37:28 <_ikke_> testing/minio
2020-04-14 07:37:34 <_ikke_> community/chezmoi
2020-04-14 07:37:48 <_ikke_> communityzf
2020-04-14 07:37:55 <_ikke_> community/fzf
2020-04-14 07:38:17 <PureTryOut[m]> Thanks!
2020-04-14 07:38:33 <_ikke_> Important is to make sure that dependencies are pinned
2020-04-14 07:39:41 <PureTryOut[m]> What about https://git.alpinelinux.org/aports/tree/testing/minio/APKBUILD#n26 vs https://git.alpinelinux.org/aports/tree/community/fzf/APKBUILD#n30? So inside `prepare()` our outside?
2020-04-14 07:41:20 <_ikke_> outside makes it more clear that it's globally set
2020-04-14 07:43:41 <PureTryOut[m]> Ok will do that then
2020-04-14 07:48:30 <PureTryOut[m]> I guess Glide pins those dependencies?
2020-04-14 07:48:37 <PureTryOut[m]> I don't see how minio does it though
2020-04-14 07:51:34 <PureTryOut[m]> Neither for chezmoi
2020-04-14 07:52:05 <_ikke_> PureTryOut[m]: different projects use different systems
2020-04-14 07:52:16 <_ikke_> initially, go did not have dependency management
2020-04-14 07:52:24 <_ikke_> you were supposed to vendor your deps
2020-04-14 07:52:38 <_ikke_> then some third-party dependency managers were written (glide)
2020-04-14 07:52:52 <_ikke_> and now there is a built-in depdendency manager (go mod)
2020-04-14 07:54:28 <PureTryOut[m]> The thing I want to package has even more specific steps, as it seems to be Qt specific https://github.com/muesli/telephant
2020-04-14 07:56:02 <_ikke_> it basically has nothing
2020-04-14 07:58:56 <PureTryOut[m]> Yeah that won't be fun to package...
2020-04-14 08:06:29 <_ikke_> You could create a go.mod / go.sum file yourself I guess
2020-04-14 08:13:12 <kaey> you can also try approach i described in ml a few month ago. that idea was ignored by other devs though
2020-04-14 08:13:21 <kaey> take a look at testing/mtg for example
2020-04-14 10:58:53 <PureTryOut[m]> kaey: that would be writing our own go.mod and go.sum files? Seems that is a good approach to take indeed. Then again, that would still require the build system to have network access right? As you just tell it what versions of the packages to retrieve?
2020-04-14 10:59:22 <_ikke_> PureTryOut[m]: building go projects without internet access is hard to do
2020-04-14 10:59:40 <_ikke_> We don't ship any go modules
2020-04-14 11:00:00 <kaey> yes (re: that would still require the build system to have network access right?)
2020-04-14 11:00:32 <_ikke_> PureTryOut[m]: and we don't want to vendor all modules for each project either
2020-04-14 11:02:16 <PureTryOut[m]> I guess I could list all the module sources in `$source`...
2020-04-14 11:03:04 <kaey> alpine can setup their own GOPROXY and advertise it via abuild.conf, but again, nobody discussed this
2020-04-14 11:03:42 <kaey> nmeum did some stuff though, not sure if he's planning to move forward with it
2020-04-14 11:06:03 <kaey> PureTryOut[m]: putting modules in sources is a bit annoying to do
2020-04-14 11:06:40 <kaey> and you'll still need to reimplement a bunch of things go expects
2020-04-14 11:07:17 <nmeum> my efforts are primarly focusing on cleaning up the community/go module (fully run the test suite et cetera)
2020-04-14 11:08:44 <nmeum> ncopa: if you have the time, could you take a look at !4138? I would personally suggest simply pushing this as is (need to rebase it though), updating the /etc/abuild.conf on the builders manually and maybe discussing a proposal for improving the build configuration in the feature separatly?
2020-04-14 11:10:03 <kaey> nmeum: i remember you asked about caching go deps and i wrote a bunch of thoughts about it
2020-04-14 11:10:10 <nmeum> yep
2020-04-14 11:10:17 <nmeum> still have the document laying around here
2020-04-14 11:10:48 <nmeum> haven't yet gotten around to working on it as I wanted to improve community/go itself before I work on caching dependencies
2020-04-14 11:12:20 <nmeum> also wanted to add a newapkbuild template for go packages. there are a lot of go-related todos on my todo list (:
2020-04-14 11:12:37 <PureTryOut[m]> Not just a bit
2020-04-14 11:21:45 <kaey> not being able to merge stuff for a year is always frustrating
2020-04-14 11:23:37 <_ikke_> nmeum: would need to be done before the 3.12 builders are up
2020-04-14 11:26:13 <nmeum> _ikke_: that would be neat, however, I would not like to move forward on my on with this as (a) I don't have access to the builders and (b) ncopa wanted to investigate this further
2020-04-14 11:27:52 <nmeum> probably makes sense to push this after 3.12 to have some time to actually test this on the builders though
2020-04-14 11:28:00 <_ikke_> right
2020-04-14 12:00:44 <markand> firefox-esr has been re-enabled for armv7 but is not available in 3.11
2020-04-14 12:00:50 <markand> is there any chance it gets backported?
2020-04-14 12:01:59 <_ikke_> depends on what it needs
2020-04-14 12:02:23 <Cogitri> It's still disabled on armv7 on 3.11?
2020-04-14 12:02:32 <Cogitri> I can backport that, shouldn't be too hard
2020-04-14 12:02:45 <Cogitri> It's just disabling NEON instructions for AV1 decoding
2020-04-14 12:03:22 <markand> I don't know but it's not in the repository for now
2020-04-14 12:04:49 <Cogitri> I'll fix it later today
2020-04-14 12:05:05 <Cogitri> I thought mps had backported that already
2020-04-14 12:05:33 <markand> <3
2020-04-14 12:41:39 <midasi> hello, did anybody already prepare an APKBUILD for kopano.io?
2020-04-14 12:47:11 <mps> Cogitri: yes, I was tempted during latest ff-esr upgrade for 3.11 to enable it, but didn't had time to test and forgot after that
2020-04-14 12:48:37 <mps> I'm trying/wasting my free time to fix some drivers for rk3399, for my chromebook to work smoothly
2020-04-14 12:49:48 <Cogitri> Oh, okie :)
2020-04-14 12:49:53 <Cogitri> Well, I'll go ahead and see if CI likes it now
2020-04-14 12:50:08 <mps> I can try on lxc
2020-04-14 12:50:47 <mps> hm, no, my armv7 lxc is edge
2020-04-14 12:50:58 <Cogitri> Well, CI will take care of it, so no worries
2020-04-14 12:51:24 <mps> CI is sometimes wrong with firefox
2020-04-14 13:40:52 <wsinatra> Would anyone mind taking a quick look at MR!6682 ? I think it's good to go
2020-04-14 13:42:00 <Cogitri> I think you haven't ticked the "Allow maintainers to commit" something something switch, wsinatra
2020-04-14 13:43:51 <wsinatra> hmm where is that setting? The branch is unprotected entirely, but I suppose that didn't change anything
2020-04-14 13:44:31 <Cogitri> Edit the MR
2020-04-14 13:44:41 <Cogitri> 
ACTION uploaded an image: image.png (96KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/QMLKBIGnXQWZphRRTGCVtDNg >

2020-04-14 13:44:45 <Cogitri> It's at the very bottom, see my screenshot ^
2020-04-14 13:45:22 <wsinatra> well darn, that's not anywhere I was looking
2020-04-14 13:45:26 <wsinatra> thanks Cogitri :)
2020-04-14 13:45:39 <Cogitri> 👍️
2020-04-14 13:56:50 <Cogitri> markand (IRC): Seems like it'd need a bit more work to work on 3.11 and we'll drop support for community in 3.11 soon (when 3.12 is released) anyway, so I think I'll just hold off of that to focus working on 3.12 :/
2020-04-14 13:57:30 <markand> okay no problem
2020-04-14 13:57:34 <markand> I use chromium for now
2020-04-14 14:26:06 <mps> markand: you can upgrade to edge, works fine for me
2020-04-14 14:29:10 <markand> can't take the risk to break my daily corporate driver right now :P
2020-04-14 14:30:15 <wsinatra> I switched to Alpine edge on my corporate driver because Arch gave me too many problems, edge has been a far more stable build than I imagine "edge" being
2020-04-14 14:30:30 <wsinatra> (this is a wonderful thing in my mind)
2020-04-14 14:31:34 <Cogitri> I use edge on all of my devices too
2020-04-14 14:31:49 <Cogitri> The one problem is that sometimes you can't upgrade because so dependencies are temporarily broken, but oh well
2020-04-14 14:32:20 <maxice8> well, it is edge
2020-04-14 14:32:33 <wsinatra> I had that issue with virt-manager recently, I just waited it out like you said.
2020-04-14 14:33:20 <wsinatra> Oh definitely, I expect breakage. But I've never had Alpine Edge updates break my boot loader. If I can still get a shell the system works
2020-04-14 14:37:01 <mps> well, true, I don't run edge on servers
2020-04-14 14:38:07 <Cogitri> I do run edge on my servers because I'm too inpatient to work for new packages :P
2020-04-14 14:38:37 <wsinatra> Yeah I need SBCL, so edge is there. And it's not in a place where I feel comfortable getting it in main yet, so I'm stuck
2020-04-14 14:44:07 <Cogitri> It only needs to be in community to be in a stable release (for 6 months)
2020-04-14 14:45:51 <wsinatra> This is true, maybe once 2.0.4 is released at the end of the month, and if aarch64 builds finally work, I'll move it.
2020-04-14 14:46:01 <wsinatra> I really want that arm64 support
2020-04-14 15:13:21 <mps> does all our arches have SPI (Serial Peripheral Interface). s390x and ppc64le especially?
2020-04-14 15:14:49 <mps> I prepared spi-tools apk but not sure is it needed for these two arches
2020-04-14 15:16:56 <_ikke_> mps: How can I tell?
2020-04-14 15:17:20 <_ikke_> Or is this more a general question rather than about our infra?
2020-04-14 15:17:32 <mps> TBK[m]: are you around? want to ask you to rename exfat-utils to something else because next kernel have exfat drivers which don't need fuse, and there is upstream tools with name exfat-utils for this 'native' driver
2020-04-14 15:18:08 <mps> _ikke_: no, it general question, not related to our -infra
2020-04-14 15:18:13 <_ikke_> ok
2020-04-14 15:19:01 <mps> I don't know much about s390x and ppc64, so not sure if spi-tools is needed for them
2020-04-14 15:19:10 <_ikke_> Me neither
2020-04-14 15:20:05 <mps> someone here is with ppc64le knowledge but I forgot nick
2020-04-14 15:20:39 <mps> walbon: ?
2020-04-14 15:20:44 <walbon> just say ppc64le and so I appear
2020-04-14 15:21:04 <mps> hi, I still not forgot you :)
2020-04-14 15:21:06 <walbon> how can I check this feature?
2020-04-14 15:21:23 <mps> maybe in dmesg output
2020-04-14 15:21:59 <walbon> I'm wondering if I can check in a KVM guest
2020-04-14 15:22:22 <mps> kernel should say something like 'spi found'
2020-04-14 15:22:36 <mps> ah, kvm maybe can't help
2020-04-14 15:22:46 <mps> real hardware can
2020-04-14 15:24:06 <walbon> well, I looked at a share baremetal
2020-04-14 15:24:09 <walbon> no SPI
2020-04-14 15:24:15 <walbon> $ dmesg | grep -i spi
2020-04-14 15:24:15 <walbon> 10:23 AM walbon @ ltc-hab4:~
2020-04-14 15:24:15 <walbon> Linux ltc-hab4.aus.stglabs.ibm.com 3.10.0-862.el7.ppc64le #1 SMP Wed Mar 21 22:20:19 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux
2020-04-14 15:24:15 <walbon> $ uname -a
2020-04-14 15:25:07 <walbon> I'm looking for a s390x to check too
2020-04-14 15:25:33 <mps> our linux-lts have this for ppc64le config. # CONFIG_SPI is not set
2020-04-14 15:26:39 <mps> also, s390x confog. # CONFIG_SPI is not set
2020-04-14 15:27:26 <mps> ok, I will disable it for these two arches and see later if it can/should be enabled on them
2020-04-14 15:27:37 <walbon> I agree
2020-04-14 15:27:48 <mps> thanks
2020-04-14 15:28:39 <walbon> y're welcome
2020-04-14 15:29:25 <mps> nmeum: did you had time to see !6764, zig 0.6.0 upgrade
2020-04-14 15:30:00 <nmeum> oh neat
2020-04-14 15:30:09 <nmeum> currently playing around with zig a bit in a private project
2020-04-14 15:30:27 <nmeum> will take a look in a sec
2020-04-14 15:31:15 <mps> ok, no problem. but build docs still doesn't work on my test in x86_64 lxc
2020-04-14 15:32:00 <nmeum> hm, that's unfourtunate
2020-04-14 15:32:10 <nmeum> the error message is also kind of cryptic
2020-04-14 15:32:26 <nmeum> but I would definitly merge the upgrade first and add the -doc subpackage separatly afterwards
2020-04-14 15:33:26 <mps> yes, I tried with building its 'docgen' but it still doesn't work, and I forgot how to run it to produce doc/html file
2020-04-14 15:34:01 <mps> ok, I agree but just wanted to hear from you what you think
2020-04-14 15:34:32 <nmeum> also kind of strange that building docs fails on some arches but doesn't on others. shouldn't really be a architecture specific thing, should it?
2020-04-14 15:35:17 <mps> well, no
2020-04-14 15:35:49 <mps> but it failed for me on both currently enabled, x86_64 and aarch64
2020-04-14 15:36:43 <mps> but we can fix this later, I see you are active in zig development
2020-04-14 15:36:56 <nmeum> strange, it worked for me on x86_64 with abuild -r
2020-04-14 15:37:02 <nmeum> anyway, I will look into this further at some point
2020-04-14 15:37:10 <nmeum> currently building zig 0.6
2020-04-14 15:37:12 <mps> ok
2020-04-14 15:38:52 <mps> just merged it
2020-04-14 15:40:04 <nmeum> great
2020-04-14 15:40:36 <nmeum> did you try enabling the test suite with 0.6?
2020-04-14 15:41:03 <nmeum> would definitly like to see zig in community/ for 3.12 imho the only thing left to do is enabling the testsuite and adding a -doc subpackage
2020-04-14 15:42:08 <nmeum> maybe also enable it on more arches, hm
2020-04-14 15:42:24 <mps> oh, I thought I enabled it but obviously I didn't :\
2020-04-14 15:43:26 <mps> I tried today to build on armv7 but it failed with same error as when upstream told me use specific git commit
2020-04-14 15:44:05 <mps> later today I will enable 'check' and see will it work
2020-04-14 15:44:53 <nmeum> ok, nice
2020-04-14 15:45:14 <nmeum> the build error we are seeing during doc generation seems to be a known upstream issue
2020-04-14 15:45:22 <maxice8> Merged big move of KDE to community/ going out to eat
2020-04-14 15:45:23 <nmeum> https://github.com/ziglang/zig/issues/4069 looks very much related
2020-04-14 15:47:51 <mps> yes, but I'm not sure
2020-04-14 15:48:01 <nmeum> mps: currently looking at the zig aport, just wondering: is there any reason why cmake is also invoked in package()?
2020-04-14 15:48:19 <nmeum> normally, it should be sufficient to generate makefiles using cmake once in build()
2020-04-14 15:48:34 <mps> I'm advised from upstream to do it
2020-04-14 15:49:03 <nmeum> hm
2020-04-14 15:49:13 <mps> also, Arch linux maintainer (daurnimator, or similar) told me and also do it like we
2020-04-14 15:49:19 <nmeum> https://github.com/ziglang/docker-zig/blob/master/build upstream doesn't seem to do it in their alpine-based dockerfile though :D
2020-04-14 15:49:21 <nmeum> ok
2020-04-14 15:49:49 <mps> I had a hope that this will be fixed in some of the releases
2020-04-14 15:49:54 <nmeum> in that dockerfile the documentation is also generated after `make install`, maybe that helps. will do some tests
2020-04-14 15:51:33 <mps> well, yes, zig will need some care in near future. I would appreciate your help or even if you would take maintainership because I see your interest in zig
2020-04-14 15:51:40 <nmeum> mps: https://git.archlinux.org/svntogit/community.git/commit/trunk/PKGBUILD?h=packages/zig&id=68a841d36a2e74f76896f8e8d561f2b54481171e the archlinux package stopped invoking cmake in install() with 0.6
2020-04-14 15:52:02 <mps> heh, didn't looked it
2020-04-14 15:54:03 <mps> ah, I see
2020-04-14 15:54:19 <mps> good, will test on my lxc
2020-04-14 15:56:20 <nmeum> doesn't seem to help in my x86_64 abuild rootbld environment
2020-04-14 15:56:34 <nmeum> I will add a comment to the github issue I linked above
2020-04-14 16:10:33 <Cogitri> clandmeter: Is there some way to fix dabuild breaking on every abuild upgrade?
2020-04-14 16:11:00 <Cogitri> I throws `ERROR: abuild-3.5.0-r1: failed to rename usr/bin/.apk.4005a7a50cbc2894af4dab81a00a600592c369d2e2279592 to usr/bin/abuild.` for me
2020-04-14 16:11:56 <Cogitri> And AFAIK the only way to fix that is to build the docker container for dabuild from scratch
2020-04-14 17:27:28 <clandmeter> Cogitri: that's weird
2020-04-14 17:29:12 <clandmeter> Did you mount something specific in the container?
2020-04-14 17:33:09 <nmeum> ncopa: thanks for merging the GOFLAGS change :)
2020-04-14 17:33:20 <nmeum> just pushed the first go upgrade with GOFLAGS set in abuild.conf
2020-04-14 17:33:26 <nmeum> lets see how that goes
2020-04-14 17:36:18 <_ikke_> nice
2020-04-14 17:43:31 <zfoo> nmeum: can you point me to what the  new change looks like, I have a few APKBUILDs I want to write for some Go programs
2020-04-14 17:44:25 <nmeum> shouldn't affect go APKBUILDs, I just changed the way we enforce -buildmode=pie on the builders
2020-04-14 17:44:44 <zfoo> ah, I see, thanks
2020-04-14 17:50:45 <kunkku> what's the best practice on applying patches which alter configure.ac but not the other autoconf files?
2020-04-14 17:51:34 <nmeum> run autoreconf -vfi in prepare()?
2020-04-14 18:00:09 <walbon> mps: s390x and ppc both don't have spi listed in their device-tree
2020-04-14 18:01:37 <nmeum> except for ../misc/cgo/test (which hangs on my hardware) all go tests seem to pass on x86_64 now
2020-04-14 18:01:38 <mps> walbon: thanks for info, I already pushed spi-tools with s390x and ppc64le disabled
2020-04-14 18:01:49 <nmeum> with one patch backported
2020-04-14 18:02:00 <walbon> mps: ok
2020-04-14 18:02:30 <Cogitri> clandmeter: Derp, spot on. Apparently I bindmounted abuild into the container to test some abuild changes
2020-04-14 18:20:47 <nmeum> mps: can you do me a favor and test !14388 in your aarch64 container? the test suite fails on the CI but only due to the syscall test which always fails on the CI but doesn't on the builders. it should pass entirely in your container (hopefully)
2020-04-14 18:21:21 <nmeum> on an unrelated note: did algitbot somehow loose the ability to extract merge request titles recently?
2020-04-14 18:24:17 <mps> nmeum:  https://gitlab.alpinelinux.org/alpine/aports/merge_requests/14388 , not found
2020-04-14 18:24:45 <nmeum> sorry that was the pipeline number
2020-04-14 18:24:48 <nmeum> !6824
2020-04-14 18:25:48 <mps> ah, ok. will do after syncing git repo
2020-04-14 18:26:58 <nmeum> thanks!
2020-04-14 18:29:37 <mps> community/go ?
2020-04-14 18:30:05 <mps> with 'abuild -r'?
2020-04-14 18:32:53 <nmeum> yes
2020-04-14 18:33:07 <nmeum> whatever your usual setup is should work
2020-04-14 18:33:46 <mps> running ....
2020-04-14 18:33:50 <nmeum> I just think that the aarch64 CI container is lacking some kind of capability which always causes the syscall test to fail
2020-04-14 18:36:18 <_ikke_> I never found any documentation about which capability though
2020-04-14 18:36:21 <mps> nmeum: passed
2020-04-14 18:36:50 <nmeum> \o/ thanks for checking, will merge it then
2020-04-14 18:36:51 <mps> only there are some number about '-static', like this '>>> WARNING: go*: Found static archive on usr/lib/go/pkg/linux_arm64/testing/internal/testdeps.a but name doesn't end with -static'
2020-04-14 18:37:00 <nmeum> that's to be expected
2020-04-14 18:37:43 <mps> ls -l packages/community/aarch64/go-1.14.2-r1.apk => rw-r--r--    1 mps      mps       81969056 Apr 14 18:35 packages/community/aarch64/go-1.14.2-r1.apk
2020-04-14 18:39:20 <nmeum> pushed
2020-04-14 18:46:40 <_ikke_> nmeum: Why would calling getrlimit be blocked by a missing capability?
2020-04-14 18:47:08 <_ikke_> https://golang.org/src/syscall/syscall_unix_test.go#L330
2020-04-14 18:47:46 <nmeum> _ikke_: just a wild guess, i didn't research this any further since we tried to debug it last time
2020-04-14 18:48:38 <nmeum> ah, you found the functions thats causing the problem
2020-04-14 18:48:45 <_ikke_> I did find this, but it's a very old issue: https://github.com/golang/go/commit/5852760088f15c68b98f18620e4fa720e1f167da
2020-04-14 19:35:11 <kaey> pkg/linux_arm64/testing/internal/testdeps.a i think those are safe to remove now? go uses build cache now instead of archives
2020-04-14 19:36:16 <kaey> zfoo: one visible change is that now you must preserve GOFLAGS="$GOFLAGS -otherflag"
2020-04-14 19:36:26 <kaey> in APKBUILD
2020-04-14 19:37:01 <maxice8> sounds like another flag to be added to apkbuild-lint's overwrite-xflags check
2020-04-14 20:49:32 <mps> nmeum: 6838e819bbef4d229089931eb422847a0eb01c03
2020-04-14 20:49:47 <mps> and 968c24a4225635826f41c131d3890ed634ce6ec4
2020-04-14 20:54:03 <mps> so, https://github.com/ziglang/zig/issues/4069 could be closed :)
2020-04-14 21:06:51 <Cogitri> FYI, you can use `cmake -B build` instead of manually creating the dir and cd'ing go that, mps
2020-04-14 21:09:34 <mps> Cogitri: thanks. didn't know, as I don't know much about cmake. will try next time (if I don't forget this)
2020-04-14 21:10:18 <Cogitri> I don't know lots of CMake either, I just copied that from PureTryOut[m] :P
2020-04-14 21:10:37 <Cogitri> I think newapkbuild defaults to it now too (once a new release is out)
2020-04-14 21:11:17 <mps> :)
2020-04-14 21:11:45 <mps> will try to remember, next time
2020-04-14 21:34:05 <Ariadne> it would be nice to be able to say arch="!big-endian" or arch="!little-endian" if we know a package is broken by endianness
2020-04-15 05:39:03 <Cogitri> Ariadne: that doesn't really happen too often though, or does it?
2020-04-15 05:39:31 <Ariadne> Cogitri: yes, most of the packages blocked on s390x are blocked because tests fail on big endian
2020-04-15 05:39:32 <Cogitri> And then I'd need to look up to which arches that translates, so personally I'd rather not have that
2020-04-15 06:18:15 <Ariadne> i think it is useful to know what archs have broken builds due to endianness
2020-04-15 06:20:32 <Cogitri> Wouldn't adding a comment to the arch field do the trick too?
2020-04-15 06:29:28 <Ariadne> no, because the idea is to make it so that other bringups don't have to go through and block a bunch of packages based on endianness
2020-04-15 06:30:13 <Ariadne> for example, aarch64be (Octeon TX) is an interesting target to us.
2020-04-15 06:31:46 <Ariadne> so being able to block based on architecture trait is useful
2020-04-15 06:32:03 <Ariadne> we could also have !32bit
2020-04-15 06:32:57 <Ariadne> anyway, go compilation process being non-verbose is annoying
2020-04-15 06:40:52 <Ariadne> i figured out how to make it verbose
2020-04-15 07:05:04 <PureTryOut[m]> Cogitri: newapkbuild indeed defaults to it
2020-04-15 07:06:55 <Cogitri> Once a new release gets out, I guess?
2020-04-15 07:07:16 <PureTryOut[m]> Yes
2020-04-15 07:07:34 <PureTryOut[m]> Which I hope will happen soon, as current newapkbuild still quotes pkgname and pkgver as well
2020-04-15 07:10:28 <Cogitri> Yes, it's really annoying when you use newapkbuild and then the linter goes ham on you
2020-04-15 07:11:32 <PureTryOut[m]> Yup
2020-04-15 07:11:55 <PureTryOut[m]> Tbh newapkbuild should probably be upgraded together with the linter, it doesn't make much sense otherwise
2020-04-15 07:13:14 <Cogitri> Well, they're usually upgraded at the same point speaking in git history terms, it's just that abuild's releases are waaaaay slower since only a limited amount of people has access to that
2020-04-15 07:13:31 <PureTryOut[m]> Btw, cmake can entirely replace the Make commands. E.g. `cmake --build build` vs `make -C build`, I wonder if we should do that
2020-04-15 07:22:27 <Cogitri> Also noticed some builds doing that but I'm unsure if that actually gets us anywhere
2020-04-15 07:22:37 <Cogitri> Actually, it could make switching from make to ninja a lot easier, right?
2020-04-15 07:23:01 <Cogitri> Meson can do the same thing, so if we switch CMake over we probably want to switch Meson too
2020-04-15 07:26:49 <PureTryOut[m]> It'd make it a lot easier yes
2020-04-15 07:27:20 <PureTryOut[m]> Or well, not really actually. Switching to Ninja would just be one switch
2020-04-15 07:27:36 <PureTryOut[m]> But we could use different systems in the future, and as long as CMake supports them, we wouldn't have to switch anything anymore besides telling CMake what build system to generate for
2020-04-15 07:28:09 <Ariadne> PureTryOut[m]: great work on KDE incidentally
2020-04-15 07:28:58 <PureTryOut[m]> Thanks!
2020-04-15 07:30:09 <TBB> speaking of KDE, any new rumours on the Qt mess?
2020-04-15 07:30:20 <PureTryOut[m]> Nope
2020-04-15 07:30:23 <Cogitri> <PureTryOut[m] "Or well, not really actually. Sw"> Yes, it's just one switch if we use CMake for building instead of having to switch make for ninja everywhere
2020-04-15 07:30:25 <PureTryOut[m]> We'll just have to wait and see what happens
2020-04-15 07:30:41 <_ikke_> Ariadne: Can we setup CI for mips already?
2020-04-15 07:30:49 <Ariadne> _ikke_: no
2020-04-15 07:30:52 <_ikke_> ok
2020-04-15 07:31:04 <PureTryOut[m]> Cogitri: shall I just make a MR to abuild? We can discuss further there
2020-04-15 07:31:08 <Ariadne> _ikke_: docker uses libraries that need to be updated (boltdb)
2020-04-15 07:31:17 <Cogitri> Sounds good
2020-04-15 07:31:20 <_ikke_> alright
2020-04-15 07:32:02 <_ikke_> sounds like boltdb is abandoned?
2020-04-15 07:32:14 <Ariadne> correct
2020-04-15 07:32:16 <Ariadne> there is bbolt
2020-04-15 07:32:20 <Ariadne> which has mips support
2020-04-15 07:35:00 <nmeum> mps: how did you manage to resolve the zig-doc errors?
2020-04-15 07:39:17 <PureTryOut[m]> Cogitri: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/42
2020-04-15 07:40:50 <mps> nmeum: 'mkdir -p build', 'cmake .... ..'
2020-04-15 07:41:14 <PureTryOut[m]> Don't do it like that 😕
2020-04-15 07:41:16 <PureTryOut[m]> Do cmake -B build instead
2020-04-15 07:41:17 <mps> looks like it needs to be build in 'build' subdir
2020-04-15 07:42:07 <mps> nmeum: look git log -p for APKBUILD
2020-04-15 07:42:46 <mps> PureTryOut[m]: I don't know much about cmake (except it is ugly build tool)
2020-04-15 07:43:25 <Cogitri> Let's all switch to meson! :P
2020-04-15 07:43:45 <PureTryOut[m]> Idk much about build tools in general, but CMake seems alright to me 😜 Just make sure to use direct cmake commands rather making directories manually
2020-04-15 07:44:28 <nmeum> mps: ah!
2020-04-15 07:44:47 <Ariadne> _ikke_: and Go 1.14 has broken Go entirely on mips64
2020-04-15 07:45:14 <nmeum> oh, that's unfourtunate
2020-04-15 07:45:20 <_ikke_> sad
2020-04-15 07:45:53 <Ariadne> as soon as we run on Go 1.14 produced toolchain, it deadlocks
2020-04-15 07:46:00 <Ariadne> i suspect the goroutine trampoline code has broken
2020-04-15 07:46:57 <mps> zig check fails with error saying it can't spawn file which exists. not sure if this is related because it runs on lxc or something else
2020-04-15 07:47:31 <nmeum> that sounds fixable though
2020-04-15 07:48:33 <Ariadne> i would prefer to revert Go 1.14
2020-04-15 07:48:42 <Ariadne> we need functioning Go on mips or the entire port is pointless
2020-04-15 07:48:44 <mps> maybe I will find time to test it on real (native) hardware and not in container
2020-04-15 07:49:09 <mps> but have first to fix FS on my real hardware
2020-04-15 07:50:15 <markand> RISC-V ftw
2020-04-15 07:50:58 <Ariadne> RISC-V does not have physical hardware that can be purchased
2020-04-15 07:51:08 <Ariadne> once it does, i am sure we will supply a port
2020-04-15 07:51:13 <Ariadne> yes i know about sifive
2020-04-15 07:51:46 <PureTryOut[m]> Drew DeVault already has a working RISC-V port of Alpine
2020-04-15 07:51:56 <Ariadne> yes
2020-04-15 07:52:05 <Ariadne> it is of main, and it is a year old
2020-04-15 07:52:11 <Ariadne> and it's not in alpine itself, now is it
2020-04-15 07:52:28 <PureTryOut[m]> I know...
2020-04-15 07:52:39 <PureTryOut[m]> I wasn't saying it is
2020-04-15 07:53:05 <Ariadne> when i say "we will supply a port", i mean in an official capacity.
2020-04-15 07:53:09 <Ariadne> :)
2020-04-15 07:53:29 <PureTryOut[m]> I realize that, I was just mentioning it 😉
2020-04-15 07:53:33 <Ariadne> and he abandoned the port anyway, because booting the sifive board is apparently quite abysmal
2020-04-15 07:54:00 <waterlemon> Hello I am trying to compile tigervnc and hitting into a compile error make[2]: *** No rule to make target '/root/compiled/tigervnc/common/network/libnetwork.la', needed by 'Xvnc'.  Stop.
2020-04-15 07:54:18 <Cogitri> Ah fun, libtool
2020-04-15 07:54:40 <Cogitri> Also, compiling as root? :/
2020-04-15 07:55:05 <Cogitri> Anyway, habe you tried with -j1 ?
2020-04-15 07:55:07 <waterlemon> yes I know its not good, I am just playing arounf
2020-04-15 07:55:20 <Ariadne> nmeum: any objection to reverting back to 1.13.8?
2020-04-15 07:55:35 <Cogitri> Maybe it's just their autotools setup not liking to be run in parallel
2020-04-15 07:55:38 <waterlemon> well i did not give any params for -j , is it wrong to assume it will he -j1 by default?
2020-04-15 07:55:41 <Ariadne> nmeum: i have opened an issue with go developers, and they have fixed other mips64 regressions, so...
2020-04-15 07:56:11 <waterlemon> anyways let me give it a try
2020-04-15 07:56:32 <Ariadne> nmeum: maybe we revert to 1.3.10
2020-04-15 07:57:06 <waterlemon> same error with -j1 too
2020-04-15 07:57:09 <nmeum> Ariadne: the thing with reverting to 1.13.8 is that it will cause the test suite to fail again, so probably also need to disable check then
2020-04-15 07:57:29 <Ariadne> nmeum: i was thinking about going to 1.13.10
2020-04-15 07:57:39 <nmeum> haven't tested that version yet
2020-04-15 07:57:46 <Ariadne> that gets us the sec fixes
2020-04-15 07:57:56 <Ariadne> let me see if it builds successfully on mips64
2020-04-15 07:58:18 <nmeum> regarding go sec fixes: we also need to rebuild a bunch of go aports due to static linking
2020-04-15 07:58:27 <Ariadne> i suspect it will
2020-04-15 07:58:49 <Cogitri> Wouldn't it be easier and better to look into why Go 1.14 is failing on mips at that point?
2020-04-15 07:59:09 <Ariadne> Cogitri: it really wouldn't
2020-04-15 07:59:38 <Ariadne> that is a... gopherhole i do not wish to jump into right now
2020-04-15 07:59:39 <nmeum> debug go is really annoying
2020-04-15 07:59:43 <nmeum> *debugging
2020-04-15 08:00:10 <Ariadne> i also don't like that we jumped from 1.13 to 1.14 this close to freeze
2020-04-15 08:00:15 <Ariadne> that's asking for trouble really
2020-04-15 08:00:40 <nmeum> I was kind of eager to get the test suite to pass as I figured it would make the thing more realiable generally
2020-04-15 08:00:55 <Ariadne> testing go 1.13.10 on x86_64 and ppc64le
2020-04-15 08:01:46 <nmeum> I don't mind reverting the upgrade for 3.12 but afterwards I would definitly like to move away from go 1.13 shot-term
2020-04-15 08:01:56 <Ariadne> yes, that's fine
2020-04-15 08:02:07 <Ariadne> i don't mind investigating it after 3.12 release
2020-04-15 08:02:12 <Ariadne> if go devs haven't fixed it since then
2020-04-15 08:02:12 <nmeum> ok
2020-04-15 08:02:54 <Ariadne> well
2020-04-15 08:02:56 <Ariadne> actually
2020-04-15 08:02:58 <Ariadne> let me try something
2020-04-15 08:03:02 <Ariadne> maybe if i set GOMAXPROCS=1
2020-04-15 08:03:07 <Ariadne> we can avoid deadlock on mips64
2020-04-15 08:03:24 <Ariadne> but
2020-04-15 08:03:28 <Ariadne> i am suspicious about it
2020-04-15 08:03:40 <Ariadne> because i feel the compiler will deadlock building other packages
2020-04-15 08:03:57 <oneinsect> folks can anyone tell me how does abuild pickup or determine/populate the "$CARCH" variable?
2020-04-15 08:03:57 <Ariadne> go builds and passes tests on 1.13.10
2020-04-15 08:04:14 <Ariadne> oneinsect: it asks apk
2020-04-15 08:04:27 <oneinsect> and how does apk do that?
2020-04-15 08:04:47 <Ariadne> $ apk --print-arch
2020-04-15 08:04:47 <Ariadne> aarch64
2020-04-15 08:05:09 <Ariadne> nmeum: 1.13.10 passes tests on x86_64
2020-04-15 08:05:28 <nmeum> great!
2020-04-15 08:05:32 <PureTryOut[m]> Is there a quick way to see what applications installed on your system come from the testing repository? I wonder what packages I use still have to be moved over to community
2020-04-15 08:05:47 <nmeum> Ariadne: does 1.13.10 also work on mips64?
2020-04-15 08:05:50 <PureTryOut[m]> (so I can move them over and have my laptop run on stable Alpine once 3.12 is out)
2020-04-15 08:05:59 <nmeum> oneinsect: see also: https://git.alpinelinux.org/abuild/tree/functions.sh.in#n120
2020-04-15 08:06:19 <oneinsect> strange apk --print-arch is throwing out x86_64 but not sending it to abuild in mycase coz the CARCH is empty
2020-04-15 08:06:51 <Ariadne> nmeum: yes, it appears so
2020-04-15 08:07:03 <oneinsect> let me look at hostspec_to_arch() in functions.sh
2020-04-15 08:08:16 <nmeum> Ariadne: in that case reverting to 1.13.10 for 3.12 is fine with me. maybe submit that as a MR to check that the test suite also passes on all other arches using the CI?
2020-04-15 08:08:32 <nmeum> (the aarch64 ci will fail though that's to be expected)
2020-04-15 08:09:05 <oneinsect> okie a small thing in case of x86_64-*-*-* then echo "x86_64" but sometimes compilers can be x86_64-linux-gnu
2020-04-15 08:09:14 <oneinsect> can the case fail in that case?
2020-04-15 08:09:33 <oneinsect> line 41 functions.sh
2020-04-15 08:10:07 <_ikke_> Ariadne: go 1.13.10 fails tests
2020-04-15 08:10:16 <_ikke_> testing: can't write /tmp/go-build401610118/b822/testlog.txt: write /tmp/go-build401610118/b822/testlog.txt: broken pipe
2020-04-15 08:10:31 <Ariadne> what the fuck
2020-04-15 08:10:38 <Ariadne> it didn't fail locally
2020-04-15 08:11:12 <nmeum> would be the first time it only fails on the builders ':)
2020-04-15 08:11:18 <nmeum> *wouldn't
2020-04-15 08:12:02 <Ariadne> this is still better than rust
2020-04-15 08:12:04 <Ariadne> just saying
2020-04-15 08:12:23 <nmeum> D
2020-04-15 08:14:02 <Ariadne> go 1.13.10 does in fact successfully build on mips64 in the build environment
2020-04-15 08:14:13 <Ariadne> or at least it got past where it deadlocks
2020-04-15 08:23:40 <ncopa> disk full? flaky test?
2020-04-15 08:24:11 <_ikke_> it failed on many builders, so don't think the disk is full
2020-04-15 08:25:40 <_ikke_> Same for flaky tests I guess, I would not expect it to fail for 6 builders if it's flaky
2020-04-15 08:27:16 <oneinsect> quick question, when bootstrapping musl, during creation of .apks it says file not found for certain .so files however the apks are created successfully
2020-04-15 08:27:25 <oneinsect> can we ignore the not found error
2020-04-15 08:28:00 <oneinsect> since it is bootstrapping, we can let it ignore and not let abuild find dependencies and pack those meta data into apks
2020-04-15 08:28:08 <oneinsect> is this correct way?
2020-04-15 08:31:42 <Ariadne> yes
2020-04-15 08:32:01 <oneinsect> is that an yes for me Ariadne:
2020-04-15 08:32:04 <Ariadne> yes
2020-04-15 08:32:11 <oneinsect> lol thank you
2020-04-15 08:32:33 <Ariadne> nmeum: i am pretty confident i can get the issue resolved in go after 3.12 release anyway :)
2020-04-15 08:32:45 <Ariadne> i just have way too many other battles to fight right now
2020-04-15 08:36:37 <[[sroracle]]> PureTryOut[m]: i have a script that looks at apk policy output to determine such a thing. I can try to clean it up and make it public tomorrow
2020-04-15 08:37:26 <[[sroracle]]> really just needs configureability rn
2020-04-15 08:40:49 <nmeum> Ariadne: alright
2020-04-15 08:41:25 <PureTryOut[m]> [[sroracle]]: thanks that'd be great
2020-04-15 08:51:01 <Ariadne> PureTryOut[m]: at one point, other than loongson, Imgtec were trying to get people to make MIPS-based android phones sooo :D
2020-04-15 08:51:12 <Ariadne> i don't think they succeeded with that
2020-04-15 08:52:11 <PureTryOut[m]> Oh lol. Well, plasma-phone-components is available for mips 😂
2020-04-15 09:37:48 <maxwell-k> is there something up with the x86 edge builder?
2020-04-15 09:38:20 <_ikke_> maxwell-k: not aware of anything?
2020-04-15 09:38:20 <maxwell-k> its doing something I haven't seen before in !6847
2020-04-15 09:38:30 <_ikke_> ah, CI
2020-04-15 09:38:45 <maxwell-k> Going to retry, but I've never seen it add the 'stuck' label before
2020-04-15 09:39:02 <maxwell-k> sorry, yes used the wrong words there :-)
2020-04-15 09:39:02 <_ikke_> it just means it's busy
2020-04-15 09:39:04 <_ikke_> just wait
2020-04-15 09:40:41 <maxwell-k> _ikke_: thank you
2020-04-15 09:40:44 <_ikke_> maxwell-k: I forgot to increase the max amount of concurrent jobs, so it was only runnin one at the time
2020-04-15 09:47:18 <_ikke_> hmmm: https://gitlab.alpinelinux.org/odidev/aports/-/merge_requests/1
2020-04-15 09:47:24 <_ikke_> That's not good..
2020-04-15 09:56:58 <maxwell-k> that is a very odd merge request
2020-04-15 09:58:16 <_ikke_> yes, it is
2020-04-15 09:58:43 <_ikke_> It tried to build a huge amount of projects
2020-04-15 09:59:06 <_ikke_> So it would have kept our CI busy for a while (until the timeout was reached)
2020-04-15 10:00:40 <Cogitri> Hm, can we make CI runners only available to the alpine group?
2020-04-15 10:00:57 <_ikke_> No
2020-04-15 10:01:24 <_ikke_> The way CI works in gitlab is that the the jobs run in the originating projects, not the target project
2020-04-15 10:05:20 <Cogitri> Ah, okay
2020-04-15 10:06:28 <_ikke_> and we don't want to have to enable CI for every fork
2020-04-15 10:06:36 <mps> so anyone can DOS CIs
2020-04-15 10:06:41 <_ikke_> yes
2020-04-15 10:06:57 <_ikke_> but there is a timeout
2020-04-15 10:07:56 <_ikke_> but even if we would limit it somehow to aport forks, they can still DOS our CI
2020-04-15 10:17:14 <nmeum> who is paying the bills for our ci setup anyhow?
2020-04-15 10:17:38 <oneinsect> are you guys using the free version of gitlab?
2020-04-15 10:18:03 <_ikke_> oneinsect: yes
2020-04-15 10:18:06 <_ikke_> nmeum: sponsors
2020-04-15 10:20:51 <_ikke_> Companies that provide hosting for us like Linode and Packet, and others that directly provide hardware to support the port (like IBM)
2020-04-15 10:23:08 <oneinsect> ooh nice linode donates servers for you guys
2020-04-15 10:28:36 <waterlemon> Hi alpine has two packages which conflict due to the include files they install
2020-04-15 10:29:01 <waterlemon> gettext-dev-0.20.1-r2 and musl-libintl-1.1.24-r2
2020-04-15 10:30:42 <waterlemon> I am trying to build tigervnc and it fails with error: more undefined references to `libintl_gettext' follow
2020-04-15 10:33:54 <waterlemon> I am not really sure why its failing though i can see the function reference in /usr/include/libintl.h
2020-04-15 10:37:18 <Cogitri> It probably fails in the linking phase
2020-04-15 10:37:45 <Cogitri> So it's not complaining about missing function prototypes (in headers) but about missing implementions (e.g. because you forgot to link a library)
2020-04-15 10:41:31 <waterlemon> well I am not sure, I am just following their guide for compilation, I have no knowledge of cmake and c/c++ compile process
2020-04-15 10:41:52 <waterlemon> however i am able to fix it by disabling NLS in their source header files
2020-04-15 10:42:18 <waterlemon> who the hell needs internationlization anyways, I am not even able to compile the binary
2020-04-15 10:51:53 <waterlemon> holy s***, I think I finally compiled it
2020-04-15 10:52:07 <waterlemon> Feels like I have performed a miracle :D
2020-04-15 10:52:16 <waterlemon> https://github.com/TigerVNC/tigervnc/issues/742 this looked to be the issue to me
2020-04-15 10:52:40 <waterlemon> the compile process was looking for lib files in the source directory
2020-04-15 11:52:37 <TBK[m]> Review wanted !5957
2020-04-15 12:02:06 <TBK[m]> mps: regarding exfat-utils I was thinking we could drop the aport when bumping the kernel to a version (5.7 I believe) where the exfat is out of staging.
2020-04-15 12:26:35 <PureTryOut[m]> Is there a guide somewhere to make my own rootfs?
2020-04-15 12:29:37 <mps> TBK[m]: ok, makes sense. I will rename next version to exfat-utils2 for now, to not conflict with current
2020-04-15 12:29:57 <mps> in my local repo, I mean
2020-04-15 12:33:24 <TBK[m]> I was pleasantly surprised to learn that samsung devs are contributing to the exfat kernel effort.
2020-04-15 12:34:43 <mps> they did it for some not short time (though don't know how long)
2020-04-15 12:36:09 <mps> I was surprised that their implementation is not included in previous kernels, but one with a lower quality
2020-04-15 12:36:26 <mps> nice that this is changed with kernel 5.7
2020-04-15 12:38:08 <TBK[m]> The staging code was the "leaked" version, so a quite old version of the code.
2020-04-15 12:39:09 <TBK[m]> I think Samsung has been waiting for MS to open the exfat spec/patents.
2020-04-15 12:39:59 <mps> not sure, but it was for some time on their repo, before ms opened its
2020-04-15 12:40:40 <mps> maybe Linus waited for ms and then feel safe to include Samsungs version
2020-04-15 12:41:30 <PureTryOut[m]> Hmm mkimage.sh fails with `aports/scripts/genrootfs.sh: line 35: /tmp/tmp.7t6DIHaQwV/bin/busybox: not found`
2020-04-15 15:14:50 <oneinsect> WARNING: when i get a warning to use subpackages=pkg:split:arch format instead
2020-04-15 15:14:50 <oneinsect>  arch="noarch" in il18n() what does it mean
2020-04-15 15:19:39 <oneinsect> i have set arch="all" in the main APBUILD starting, should i change it to arch="noarch" and subpkgarch="all"?
2020-04-15 16:16:13 <PureTryOut[m]> Currently in a custom Alpine boot image it doesn't autoload the ext4 module in the initramfs. How do I make that happen?
2020-04-15 16:23:25 <_ikke_> PureTryOut[m]: /etc/update-extlinux.conf? (or comparable)
2020-04-15 16:24:18 <PureTryOut[m]> I guess append `modules=<things>` to the kernel cmdline?
2020-04-15 16:24:26 <PureTryOut[m]> That won't be easy in this case...
2020-04-15 16:24:38 <_ikke_> It should be part of the initramfs
2020-04-15 16:24:39 <mps> yes, I do that mostly
2020-04-15 16:41:22 <ddevault> hey, can someone backport the latest mercurial package on edge to 3.11?
2020-04-15 16:41:25 <ddevault> it contains an important bug fix
2020-04-15 17:06:03 <oneinsect> quick question why arent we using lib64? but even for x86_64 we are using lib
2020-04-15 17:06:51 <dalias> because lib64 is wrong :)
2020-04-15 17:07:13 <dalias> if you want to do multiarch it doesn't suffice, and if you don't, it's not necessary
2020-04-15 17:15:02 <oneinsect> hmmm
2020-04-15 17:15:30 <oneinsect> okie thanks
2020-04-15 17:32:40 <Hello71> eh, lib64 isn't that bad. it's only an issue if you think multilib is a good idea in the first place
2020-04-15 17:32:52 <oneinsect> naa multilib is bad
2020-04-15 17:32:57 <oneinsect> disabling it now
2020-04-15 17:46:56 <oneinsect> can anyone please give me an example for subpackages=pkg:split:arch format
2020-04-15 17:47:33 <TBK[m]> oneinsect: https://git.alpinelinux.org/aports/tree/main/abuild/APKBUILD#n22
2020-04-15 17:47:55 <oneinsect> aha
2020-04-15 17:48:02 <oneinsect> thanks TBK[M]:
2020-04-15 17:52:52 <oneinsect> i think this also should be correct
2020-04-15 17:52:54 <oneinsect> $pkgname-i18n-noarch
2020-04-15 17:53:07 <oneinsect> instead of $pkgname:i18n:noarch
2020-04-15 17:54:43 <_ikke_> why do you think so?
2020-04-15 17:54:58 <oneinsect> is that question for me?
2020-04-15 17:55:02 <_ikke_> yes
2020-04-15 17:55:26 <oneinsect> in the wiki https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2020-04-15 17:55:27 <oneinsect> it says
2020-04-15 17:55:33 <oneinsect> The split function can be specified in 1 of 3 different methods:
2020-04-15 17:55:46 <oneinsect> is that correct?
2020-04-15 17:56:41 <oneinsect> or is the wiki dated?
2020-04-15 17:57:54 <_ikke_> It only mentions the split function, not the arch
2020-04-15 17:58:24 <oneinsect> so i can only use this
2020-04-15 17:58:26 <oneinsect> $pkgname:i18n:noarch
2020-04-15 17:59:41 <_ikke_> yes
2020-04-15 21:19:21 <clandmeter> _ikke_: http://dl-cdn.alpinelinux.org/alpine/edge/main/tests/
2020-04-15 21:20:42 <_ikke_> where did that come from?
2020-04-15 21:20:52 <clandmeter> check the content of t hat dir
2020-04-15 21:21:18 <_ikke_> I see lz4-tests
2020-04-15 21:21:35 <clandmeter> i bet there is something funky in that apkbuild
2020-04-15 21:21:54 <clandmeter> but im writing a letter ;-)
2020-04-15 21:23:32 <_ikke_> Programs and scripts for automated testing of LZ4
2020-04-15 21:24:51 <_ikke_> I bet someone made a mistake in the arch
2020-04-15 21:25:08 <_ikke_> it's a lz4 subpkg
2020-04-15 21:26:02 <_ikke_> yup
2020-04-15 21:26:10 <_ikke_> ae1f4c098467a4071d568bb0268eef3b4a617f88
2020-04-15 22:33:24 <[[sroracle]]> PureTryOut[m]: https://gist.github.com/sroracle/29969e1be9a1ea0368d6744f65b98990
2020-04-15 22:59:30 <Ariadne> here's one for you
2020-04-15 22:59:40 <Ariadne> in tmux under konsole, ^B-C is not working
2020-04-16 00:27:17 <Hello71> shift-c?
2020-04-16 05:28:02 <waterlemon> Hello , I want to know if there would be any audience interested in the tigervnc package? If yes, what is the procedure for adding a new package to alpine repos? Thanks
2020-04-16 05:29:21 <_ikke_> waterlemon: it's hard to say in advance if there is an audience
2020-04-16 05:29:54 <_ikke_> getting it included is a matter of making a merge request against aports in gitlab.a.o
2020-04-16 05:30:01 <waterlemon> ok fair enough, would it make sense to add it anyways?
2020-04-16 05:30:15 <_ikke_> waterlemon: sure
2020-04-16 05:30:54 <waterlemon> ok is there any example or doc on how to make a pr to the git repo for a simple package?
2020-04-16 05:31:59 <Cogitri> https://wiki.alpinelinux.org/wiki/Creating_patches#Submitting_patches_via_Gitlab
2020-04-16 05:32:18 <waterlemon> Thanks all I will give this a try
2020-04-16 05:50:07 <opal> did a sync on aports and man that unmaintained directory filled up
2020-04-16 05:50:53 <_ikke_> python packages I guess?
2020-04-16 05:51:18 <opal> some of those yeah
2020-04-16 05:51:36 <opal> gajim, libpurple-lurch, opencv, and some other things that caught my eye got moved to there
2020-04-16 05:51:55 <opal> if i were still using alpine as daily driver i'd definitely try working on opencv + the python bindings
2020-04-16 05:52:09 <opal> but as it stands i'm too busy
2020-04-16 05:52:19 <opal> quicktun there too, haha, didnt know that was a package
2020-04-16 05:53:58 <opal> gajim switched to py3 i believe. still as big a pain as ever to actually make sure it works across versions, at least in my experience. i just gave up and switched to dino for now
2020-04-16 05:56:33 <opal> if i can get alpine working on my raspberry pi i might try to maintain/create some desktop packages actually
2020-04-16 05:56:44 <opal> would be nice to have an alpine system lying around just to mess around with
2020-04-16 06:22:45 <Ariadne> i'm about to move half of testing to unmaintained tbh at this point
2020-04-16 06:22:53 <Ariadne> so many APKBUILDs have bitrotted
2020-04-16 06:23:53 <Cogitri> Please make those MRs so others can have a look before they're moved though
2020-04-16 06:32:06 <Ariadne> Cogitri: of course
2020-04-16 06:32:27 <Ariadne> testing is really in bad shape
2020-04-16 06:35:30 <Cogitri> Well, it'd rather have it in suboptimal state than aggressively move stuff to unmaintained
2020-04-16 06:43:03 <opal> if nobody's testing stuff then it makes no sense to hav ein testing, i agree
2020-04-16 06:43:59 <Ariadne> Cogitri: half of testing will not presently rebuild under x86_64.
2020-04-16 06:49:39 <Cogitri> You meant they're disabled on all arches?
2020-04-16 06:49:51 <Cogitri> fabled: Sorry, but what's the status of apk-tools 2.10.6?
2020-04-16 06:53:18 <Ariadne> Cogitri: no i mean they need to be disabled
2020-04-16 07:06:05 <clandmeter> welcome to the joy of rebuilding testing
2020-04-16 07:07:37 <clandmeter> testing should not be in main tree at all, but that's just my personal opinion.
2020-04-16 07:08:20 <Ariadne> i agree
2020-04-16 07:08:29 <clandmeter> i ones moved a lot of broken stuff to unmaintained (announced) and i made a lot of friends back then.
2020-04-16 07:08:36 <Ariadne> :D :D :D
2020-04-16 07:08:44 <clandmeter> that was sarcasm if you didnt notice ;-)
2020-04-16 07:09:51 <Ariadne> +1 for replacing testing with something else
2020-04-16 07:10:36 <Cogitri> What would that something else be?
2020-04-16 07:10:57 <Ariadne> testing is especially a nightmare for mips, because you get hit with bitrot and the assumption that mips is little-endian always
2020-04-16 07:11:02 <clandmeter> i ones proposed to use gitlab and use artifacts so users can try it. keep it for x period and after it is left behind we can just close and get rid of it.
2020-04-16 07:11:42 <Cogitri> Sounds like a lot of effort though
2020-04-16 07:11:44 <Ariadne> well, i would be fine with testing if it had ground rules
2020-04-16 07:11:59 <Ariadne> like "package must be updated within X amount of time or it is automatically removed by a bot"
2020-04-16 07:12:06 <clandmeter> but if it follows our rules we could merge it into the tree.
2020-04-16 07:12:18 <Ariadne> the problem is
2020-04-16 07:12:30 <Ariadne> people contribute an APKBUILD (that is frequently dubious)
2020-04-16 07:12:36 <Ariadne> and then it just sits there and bitrots
2020-04-16 07:13:20 <clandmeter> yes, this is our typical testing workflow
2020-04-16 07:13:22 <Ariadne> having a space where people can develop APKBUILDs iteratively is useful, but letting things fester for several years in testing is harmful
2020-04-16 07:13:41 <Ariadne> so we need to at the very least change the workflow to discourage this kind of drive-by stuff
2020-04-16 07:14:04 <Cogitri> I think if we stop allowing that we'll have way less contributors and not as many packages available though
2020-04-16 07:14:16 <Ariadne> quality is more important than quantity
2020-04-16 07:14:46 <Ariadne> having 9000 packages where 4000 of them are in testing and not actually maintained correctly is worse than having 6000 packages in community that have correct maintenance
2020-04-16 07:15:01 <clandmeter> you need a playground outside of the main tree which automatically expires. this would get my vote.
2020-04-16 07:15:10 <Ariadne> right
2020-04-16 07:15:13 <Ariadne> that is what i am saying
2020-04-16 07:15:26 <clandmeter> and with gitlab we have the features to doit.
2020-04-16 07:15:46 <Ariadne> we could even compose a flat view of the gitlab artifacts as a repo that emulates testing
2020-04-16 07:15:56 <Ariadne> seems would it be easy
2020-04-16 07:16:01 <clandmeter> i already did that ones :)
2020-04-16 07:17:45 <Ariadne> in testing you also see a lot of
2020-04-16 07:17:58 <Ariadne> arch="all !every-arch-other-than-one"
2020-04-16 07:18:29 <_ikke_> At least one person is just keeping their packages in testing because they only use edge and don't care about stable releases
2020-04-16 07:19:03 <clandmeter> isnt that what community is for?
2020-04-16 07:19:18 <_ikke_> for them it's the same difference
2020-04-16 07:19:33 <clandmeter> so we just allow it to happen
2020-04-16 07:19:43 <clandmeter> and if its maintained, its not a direct issue at all.
2020-04-16 07:19:50 <_ikke_> it is maintained
2020-04-16 07:20:16 <Ariadne> _ikke_: and they could use the new system instead
2020-04-16 07:21:00 <Ariadne> but "don't care about stable releases" means that people who do care about stable releases may be discouraged from taking those packages
2020-04-16 07:21:12 <Ariadne> since they are "already being packaged"
2020-04-16 07:21:55 <opal> <Ariadne> like "package must be updated within X amount of time or it is automatically removed by a bot"
2020-04-16 07:22:17 <opal> what about "if it isnt pulled into main/community by x release then drop it"
2020-04-16 07:22:25 <Ariadne> opal: that is what i am saying basically :)
2020-04-16 07:22:30 <opal> because thats the whole point of testing, right? to onboard to ... yeah
2020-04-16 07:22:31 <clandmeter> that is much more difficult than its looks from first glance
2020-04-16 07:22:40 <clandmeter> some packages dont need lot of updates
2020-04-16 07:22:46 <opal> so is having to deal with obsoleted software
2020-04-16 07:22:48 <Ariadne> it is
2020-04-16 07:22:48 <clandmeter> i made that selection before
2020-04-16 07:22:53 <Ariadne> that's why i prefer clandmeter's proposal
2020-04-16 07:23:07 <Ariadne> just replace testing with something that doesn't disrupt the normal release engineering process
2020-04-16 07:23:19 <Ariadne> that way testing can be truly "best effort"
2020-04-16 07:23:26 <clandmeter> get it out of developers face is a big win.
2020-04-16 07:23:40 <Ariadne> yes, that's the other thing
2020-04-16 07:23:46 <Ariadne> to get something into testing to begin with
2020-04-16 07:23:49 <opal> honestly i'd go to the extreme and promote third-party repos as playgrounds until a more serious proposal to include in main is made
2020-04-16 07:23:56 <Ariadne> you have to find somebody to push it
2020-04-16 07:24:10 <opal> that way maintainers dont have to deal with testing packages at all until it's "ready" to be dealt with
2020-04-16 07:24:16 <opal> dunno how that would work in practice
2020-04-16 07:24:17 <Ariadne> i would rather we spend developer time sponsoring packages into main or community, not testing
2020-04-16 07:25:26 <mps> my vote goes to 'quality rather than quantity'
2020-04-16 07:26:02 <opal> for sure
2020-04-16 07:26:19 <mps> and, yes, testing is somewhat misleading
2020-04-16 07:26:23 <Ariadne> clandmeter: well, i guess once 3.12 is branched, we should have a chat and bang out a proposal
2020-04-16 07:26:47 <clandmeter> sure, you know where to find me.
2020-04-16 09:11:08 <PureTryOut[m]> I'm trying to create a custom Alpine image and I can boot from it, but it seems to OpenRC services get loaded. It tries to start the service "hwdrivers" but fails because it depends on "dev" which is not found. I don't see `/etc/init.d/dev`, but then again I don't have that on my working system either and there hwdrivers can start fine
2020-04-16 09:11:15 <PureTryOut[m]> *no OpenRC services get loaded
2020-04-16 09:11:31 <PureTryOut[m]> What am I missing?
2020-04-16 09:13:41 <clandmeter> what does 84cc16748cd34cfad1a1137d898a71261fa360c3 mean?
2020-04-16 09:19:34 <Cogitri> andypost: ^ ?
2020-04-16 09:20:22 <Cogitri> PureTryOut[m]: There's only devfs AFAIK, I guess that's a typo?
2020-04-16 09:23:58 <PureTryOut[m]> I assumed so too but the same init file works fine on my laptop
2020-04-16 09:24:40 <andypost[m]> Proftpd fails to build and rebuilding each commit, so I did bump to catch it
2020-04-16 09:29:43 <PureTryOut[m]> Well making it depend on devfs seems to work. Not sure what's up with that
2020-04-16 09:30:00 <PureTryOut[m]> Still, besides that service it doesn't seem to have anything loaded. `rc-status -a` reveals empty runlevels
2020-04-16 09:32:55 <mps> anyone know which kernel version running on s390x builder?
2020-04-16 09:37:53 <clandmeter> andypost[m]: its probably something else that triggers it
2020-04-16 10:20:08 <_ikke_> mps: 4.19.58-0-vanilla
2020-04-16 10:23:25 <mps> ah, maybe this is reason for failed iwd test there
2020-04-16 10:25:23 <ncopa> PureTryOut[m]: iirc "dev" is provided by either mdev or udev service
2020-04-16 10:26:43 <Cogitri> Right, udev-trigger provides it
2020-04-16 10:33:00 <ncopa> should be an mdev variant too
2020-04-16 10:33:08 <ncopa> maybe hwdrivers or similar
2020-04-16 10:33:21 <mps> it works without eudev for me
2020-04-16 10:33:31 <PureTryOut[m]> Interesting
2020-04-16 10:33:55 <ncopa> yes, mdev provides it
2020-04-16 10:35:22 <mps> (these days I'm working on removing udev on one of my machines)
2020-04-16 10:36:10 <mps> and, will see, maybe most of 'things' could work without eudev
2020-04-16 10:36:41 <Cogitri> I install eudev on all of my machines because mdev never worked for me on any of my machines
2020-04-16 10:36:54 <Cogitri> And on most setups eudev-libs is pulled in anyway
2020-04-16 10:37:47 <mps> actually, for me only X is problem without eudev, though it can work fine with configs in /etc/X11/xorg.conf.d/
2020-04-16 11:05:03 <mps> s390x CI is stuck (again)?
2020-04-16 11:28:41 <_ikke_> Just restart the job if it keeps hanging
2020-04-16 11:28:44 <_ikke_> (which I just did)
2020-04-16 11:30:53 <_ikke_> It's not that the runner itself is stuck or the host, just that specific job
2020-04-16 11:31:35 <mps> aha, ok
2020-04-16 11:33:39 <Ariadne> https://gitlab.alpinelinux.org/alpine/aports/issues/11403
2020-04-16 11:34:04 <Ariadne> and this is yet another reason testing should go away
2020-04-16 11:35:19 <Ariadne> license=custom, indeed
2020-04-16 11:35:22 <_ikke_> Ariadne: Would it be a difference if it went to testing first or directly to community?
2020-04-16 11:35:56 <Ariadne> _ikke_: no, it would be a problem either way
2020-04-16 11:36:34 <_ikke_> this is more about being dilligent before accepting patches
2020-04-16 11:36:50 <Ariadne> the reason why i say it is another reason though
2020-04-16 11:37:08 <Ariadne> is because if somebody wants to make their own "PPA" with this in it, that's their business i guess
2020-04-16 11:38:44 <Ariadne> so yes, more diligence is needed
2020-04-16 11:39:32 <Ariadne> but at the same time, this package probably wouldn't be in mainline alpine if we had a better alternative to testing anyway
2020-04-16 11:40:30 <Cogitri> Sorry for merging
2020-04-16 11:40:50 <Cogitri> My license-fu isn't really on spot I guess, can you maybe explain me the problem? 😅
2020-04-16 11:41:13 <Cogitri> The
2020-04-16 11:41:13 <Cogitri> > Urban Terror can be freely distributed over the internet, unmodified, without charging for the product
2020-04-16 11:41:13 <Cogitri> Sounded to me as if it'd be OK
2020-04-16 11:41:13 <mps> few days ago I wrote that we need some kind of 'approval process'
2020-04-16 11:41:34 <Ariadne> Cogitri: the game logic itself is licensed under the terms of the Quake 3 EULA
2020-04-16 11:41:41 <_ikke_> Do we want to form an official commitee who decides what gets included and not
2020-04-16 11:41:44 <_ikke_> ?
2020-04-16 11:41:55 <mps> _ikke_: exactly that
2020-04-16 11:42:06 <Cogitri> Let's not become Debian please
2020-04-16 11:42:15 <Ariadne> i don't think that is necessary, but i think that people should be careful when reviewing data packages
2020-04-16 11:42:16 <_ikke_> Yeah, I'm not sure we want to go that direction
2020-04-16 11:42:53 <Cogitri> Yes, sorry again. The license sounded to me as if it was OK to distribute the package nontheless
2020-04-16 11:43:02 <mps> yes, then we can go to current direction :)
2020-04-16 11:43:11 <_ikke_> and then it gets rectified again
2020-04-16 11:43:40 <Ariadne> the debian ftpmaster process does not really solve problems
2020-04-16 11:43:42 <mps> Cogitri: it is not your mistake, and my comment is not addressed to you, but to current workflow
2020-04-16 11:43:50 <Ariadne> they review debian/copyright, which could be wrong anyway
2020-04-16 11:44:00 <Ariadne> similar incidents have happened in debian
2020-04-16 11:44:17 <Ariadne> and the only reason why i noticed it is because i was monitoring the upload of mips64 testing
2020-04-16 11:44:38 <_ikke_> aven the license field could be wrong
2020-04-16 11:44:45 <Ariadne> yes
2020-04-16 11:45:02 <Ariadne> basically what i am saying is, if you see license=custom, it is probably a red flag
2020-04-16 11:45:34 <Ariadne> and it is probably better to say no than yes if there is any doubt
2020-04-16 11:46:04 <mps> few times I 'meet' packages with 'incorrect' license, but only by haphazard
2020-04-16 11:47:29 <_ikke_> Abuild alreayd verifies and warns about 'custom' as a license
2020-04-16 11:49:29 <Ariadne> yes, because most likely it is a sign that we should not accept the package :p
2020-04-16 11:50:50 <_ikke_> It does require you to have the spdx-license-list installed, which is the case for our CI
2020-04-16 12:21:30 <ncopa> Cogitri: i think llvm10 should have a replaces=llvm9 https://github.com/alpinelinux/docker-alpine/issues/74
2020-04-16 12:25:57 <Cogitri> Hm, I had expected the `replaces="llvm"` would take care of that
2020-04-16 12:32:40 <ncopa> i think it only replaces litteral 'llvm' package, which no longer have
2020-04-16 12:33:18 <ncopa> maybe that is something that could/should be fixed in apk-tools
2020-04-16 12:34:04 <ncopa> fabled: what do you think, should "replaces=llvm" replace any package that provides="llvm"? ^^^
2020-04-16 12:35:41 <fabled> i think it's in general dangerous, but i understand the reasoning for it. i think both sides have arguments. i need to think about it a bit
2020-04-16 12:37:35 <ncopa> in any case, i think we should fix llvm10 to have a replaces=llvm9
2020-04-16 12:38:19 <ncopa> it is a more simple/stupid fix. and i like simple
2020-04-16 12:42:09 <Cogitri> Okay. Are you going to add that or should I do that?
2020-04-16 12:42:43 <Cogitri> fabled: Also, sorry to annoy you with it, but are you going to release 2.10.6 before 3.12? Otherwise I'll have to static link apk in my project
2020-04-16 12:43:44 <fabled> Cogitri, next releases would be 2.11 as it has pretty much stuff in it. i'm not sure if we want to release it before alpine-3.12 for that reason.
2020-04-16 12:48:12 <Cogitri> Hm, okay. I guess I'll go ahead and static link it for now then
2020-04-16 13:25:42 <ncopa> i am about to set up the 3.12 builders any time now so there is not much time in case you want apk-tools-2.11 included in alpine 3.12
2020-04-16 13:27:41 <Cogitri> Alrighty, thanks for the info, I'll go for static linking then
2020-04-16 14:07:03 <Cogitri> fabled: Maybe it's just me not knowing C well, but how is apk-tools saving bitflags that are 35 bits long in total in an uint in apk_package.h ?
2020-04-16 14:18:33 <ncopa> i think uint is 64bit
2020-04-16 14:18:52 <ncopa> even on 32 bit arches
2020-04-16 14:21:19 <ncopa> unsigned long may be 32 bit
2020-04-16 14:22:54 <Cogitri> At least on my machine (x86_64) unsigned int is 4 bytes, so 32-bit
2020-04-16 14:28:16 <ncopa> right, its 'long' that is 64bit
2020-04-16 14:29:12 <ncopa> in which field is a uint bitflag storing 35 bit flag?
2020-04-16 14:29:33 <ncopa> should probably been uint64_t
2020-04-16 14:32:59 <Cogitri> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_package.h#L121
2020-04-16 14:33:05 <Cogitri> And APK_MAX_REPOS is defined as 32
2020-04-16 14:51:12 <fabled> Cogitri, it just allocates more space
2020-04-16 14:51:19 <fabled> C bitfields are
2020-04-16 14:51:25 <fabled>  type name : width
2020-04-16 14:51:37 <fabled> type specifies the granularity amount of allocation from struct
2020-04-16 14:52:59 <fabled> so if using 32-bit base type, so when a field comes that uses 33th bit, it's going to allocate another 32-bits...
2020-04-16 14:53:01 <Cogitri> Ah, okay. And the other fields like "marked" only take up 1 byte then?
2020-04-16 14:53:45 <fabled> the marked field takes 1 bit
2020-04-16 14:53:53 <Cogitri> Alright, got it, thanks
2020-04-16 14:54:02 <fabled> but it's unsigned type
2020-04-16 14:54:06 <fabled> which means unsigned int
2020-04-16 14:54:15 <Cogitri> Apparently I need to align with 1 byte in my bindings instead of aligning in size_t increments
2020-04-16 14:54:19 <fabled> si it's going to round up the total length to next int sized boundary
2020-04-16 14:54:29 <fabled> also, the bit order depends on machine type
2020-04-16 14:54:45 <fabled> C specification does not tell what is the order
2020-04-16 14:54:51 <fabled> gcc does one thing, some other compiler might do another
2020-04-16 14:54:56 <Cogitri> Fun
2020-04-16 14:55:21 <fabled> yeah, it is kinda intended to be kept internal
2020-04-16 14:56:00 <fabled> need to think how to do it with the rewrite so it's easier to make it visible via bindings
2020-04-16 14:56:10 <fabled> need to run
2020-04-16 14:56:12 <fabled> ttyl
2020-04-16 19:20:29 <oneinsect> folks
2020-04-16 19:20:53 <oneinsect> when i mention something like https://data.iana.org/time-zones/releases/tzdata2019c.tar.gz in the sources
2020-04-16 19:21:03 <oneinsect> why does abuild automatically unzip it
2020-04-16 19:21:27 <Cogitri> Because that's what you want in 99% of cases
2020-04-16 19:21:27 <oneinsect> how do i include a file that abuild should not compile but still download
2020-04-16 19:21:39 <Cogitri> You can override unpack()
2020-04-16 19:21:47 <oneinsect> aha
2020-04-16 19:21:56 <oneinsect> any simple example?
2020-04-16 19:22:25 <Cogitri> grep -R unpack in aports should yield some examples
2020-04-16 19:22:38 <oneinsect> thanks
2020-04-16 19:29:00 <TBB> or you can look at how the abuild default unpack function works
2020-04-16 19:30:24 <oneinsect> thanks TBB:
2020-04-16 20:03:30 <oneinsect> or may be i could just download that file during package() function
2020-04-16 20:04:03 <oneinsect> the grep returns results but none seem to be straight forward to over-ride, like only preventing extracting a certain file
2020-04-16 20:10:00 <mps> huhm, why we forgot to enable fs_verity in linux-lts (shame on me)
2020-04-16 20:11:20 <oneinsect> source="http://foo.org/bar/foobar.tar.xz" then do we any option called
2020-04-16 20:11:21 <oneinsect> noextract='foobar.tar.xz' like in PKGBUILD
2020-04-16 20:11:25 <oneinsect> have*
2020-04-16 20:14:45 <oneinsect> okie noextract option isnt there in alpine
2020-04-16 20:14:49 <oneinsect> would have been nice to have
2020-04-16 23:23:53 <Ariadne> all of this libretro stuff in testing makes me anxious too
2020-04-16 23:24:15 <Ariadne> many libretro releases contain firmware blobs that lack copyright attribution and do not include a permission grant allowing redistribution
2020-04-17 07:19:31 <PureTryOut[m]> Is there a way of making the initramfs load the required modules without editing the bootloader CMDLINE to do so? Like make mkinitfs generate some script which loads them on boot instead?
2020-04-17 07:20:52 <Cogitri> See /usr/share/mkinitfs/initramfs-init
2020-04-17 07:21:00 <Cogitri> 
ACTION sent a long message:  < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/KEauihaZRyfMPAFJYgyjOaMR >

2020-04-17 07:21:38 <PureTryOut[m]> Did you prepare this in advance? 😂
2020-04-17 07:22:06 <Cogitri> Ah no, I just messed around with initramfs-init before for ZFS
2020-04-17 07:22:33 <oneinsect> why cant you have them built-in kernel itself
2020-04-17 07:22:37 <oneinsect> instead of modules?
2020-04-17 07:23:14 <PureTryOut[m]> Because I want to use linux-lts, and not some custom kernel
2020-04-17 07:23:23 <oneinsect> hmmm
2020-04-17 07:23:25 <oneinsect> okie
2020-04-17 07:23:52 <PureTryOut[m]> Cogitri: thanks though. I wonder if it's something that would be accepted to upstream?
2020-04-17 07:28:24 <Cogitri> Ah, that already is in initramfs-init
2020-04-17 07:28:51 <Cogitri> So I think you only need it to populate /etc/modules in the initramfs :)
2020-04-17 07:29:30 <PureTryOut[m]> Oh and how would I do that? 🤔
2020-04-17 07:31:02 <Cogitri> That's a good quesiton
2020-04-17 07:47:40 <mps> maybe mkinitfs should 'learn' modules loaded during install or from kernel cmdline (boot file soon) and create initramfs with them
2020-04-17 07:48:27 <Cogitri> Like dracut's host-initramfs (although that has only caused trouble for me)
2020-04-17 07:48:54 <mps> uhm, dracut
2020-04-17 07:49:15 <PureTryOut[m]> Something like that would be nice yes. I got a workaround for my problem working for now which is good enough
2020-04-17 07:52:00 <mps> I do this 'by hand' for now, i.e. creating /etc/mkinitfs/features.d/ file with modules and add it to mkinitfs.conf and run mkinitfs 'by hand again'
2020-04-17 07:52:43 <PureTryOut[m]> That is something I can not do in this case
2020-04-17 07:56:26 <Ariadne> PureTryOut[m]: something that may be helpful is a kexec-based bootloader i am working on
2020-04-17 07:56:45 <Ariadne> presumably, this is related to a phone or other embedded system where you cannot alter cmdline easily
2020-04-17 08:08:07 <PureTryOut[m]> Nope, this is related to a graphical installer for the desktop. I can not alter GRUB_CMDLINE_LINUX_DEFAULT with it (because it already does it's own smart stuff internally with it), but I can alter GRUB_CMDLINE_LINUX with it so that's what I'm doing atm
2020-04-17 08:25:11 <Ariadne> hmm, what installer is that
2020-04-17 08:27:30 <PureTryOut[m]> Calamares
2020-04-17 08:27:35 <PureTryOut[m]> Working on packaging it
2020-04-17 08:27:59 <Ariadne> ah, the manjaro one
2020-04-17 08:28:28 <Ariadne> at work, we have adapted the adelie installer to run on alpine as well
2020-04-17 08:28:37 <PureTryOut[m]> No
2020-04-17 08:28:49 <PureTryOut[m]> It's the one Manjaro uses, but it's not Manjaro's installer 😉
2020-04-17 08:43:17 <PureTryOut[m]> `mkimg.base.sh` has some functions defined, but I don't actually see them being called anywhere. When/how are they called, and can I make my own for a custom profile?
2020-04-17 10:04:24 <PureTryOut[m]> Figured it out, all sections_* functions get automatically called
2020-04-17 10:04:40 <PureTryOut[m]> I now made an Alpine ISO, and the contents seem good, but it fails to boot in Qemu. Just reports No such file or directory?
2020-04-17 10:25:56 <PureTryOut[m]> Ah, `/boot` is empty and thus no kernel or initramfs is available, interesting
2020-04-17 10:31:21 <Cogitri> Maybe /boot is a different partition?
2020-04-17 10:32:57 <PureTryOut[m]> Nah I was missing basic stuff, got it now
2020-04-17 10:33:10 <PureTryOut[m]> I assume the live iso boots purely into initramfs. How can I put extra stuff in there?
2020-04-17 10:39:33 <ncopa> Ariadne: has adelie an installer? where can i find it?
2020-04-17 10:39:48 <Ariadne> yes, horizon
2020-04-17 10:40:01 <oneinsect> is there is a nostrip_files= XYZ supported command in APKBUILD
2020-04-17 10:40:24 <Ariadne> https://code.foxkit.us/adelie/horizon
2020-04-17 10:40:31 <_ikke_> oneinsect: there is only a !nostrip global option
2020-04-17 10:40:45 <oneinsect> darn
2020-04-17 10:41:16 <oneinsect> i wish i could just give a list of files not to strip selectively
2020-04-17 10:41:21 <_ikke_> option is !strip ofcourse
2020-04-17 10:42:20 <ncopa> aha, its a qt app
2020-04-17 10:42:21 <oneinsect> this and noextract option where i can specify a file from being extracted without overriding would have been nice
2020-04-17 10:42:59 <Ariadne> the frontend is, the backend runs a scr
2020-04-17 10:43:02 <Ariadne> ipt
2020-04-17 10:43:19 <Ariadne> there is also an agent that manages system state based on a JSON-LD model
2020-04-17 10:43:44 <Ariadne> the idea is to reuse restconf with that model to provide centralized management
2020-04-17 10:45:19 <Ariadne> it does however have the capability of installing Alpine or our downstream fork
2020-04-17 10:45:47 <oneinsect> nice Ariadne:
2020-04-17 10:47:51 <Ariadne> PureTryOut[m]: apkovl :)
2020-04-17 10:48:13 <PureTryOut[m]> I've seen that but am unsure what it is
2020-04-17 10:48:39 <_ikke_> It's what contains persistent data for run-from-ram systems
2020-04-17 10:53:36 <Ariadne> PureTryOut[m]: it's a tarvall which contains files to override such as /etc/apk/world :)
2020-04-17 10:53:57 <PureTryOut[m]> Interesting, thanks will look into it
2020-04-17 10:54:50 <PureTryOut[m]> Basically I need to generate a squashfs image and include that in the ISO. Got the squashfs image generated now so just need to make it available to the booted system
2020-04-17 10:54:51 <PureTryOut[m]> 
ACTION is learning while doing this

2020-04-17 10:56:22 <Ariadne> why would you need to include a squashfs
2020-04-17 10:56:40 <Ariadne> the Alpine way is to assemble the system with an apkovl
2020-04-17 10:57:53 <Ariadne> then the system is assembled from the apkovl and package tree at boot
2020-04-17 10:58:02 <Ariadne> this allows for trusted boot
2020-04-17 10:58:14 <PureTryOut[m]> Because Calamares works with a squashfs
2020-04-17 10:58:28 <Ariadne> isn't it just an app?
2020-04-17 10:58:42 <Ariadne> why would it need a squashfs
2020-04-17 10:58:52 <AinNero> i thought its food
2020-04-17 10:58:57 <AinNero> but i think this is meantr: https://github.com/calamares/calamares
2020-04-17 10:59:23 <Ariadne> on other distros a squashfs may be appropriate but I fail to see why it is appropriate here
2020-04-17 10:59:42 <Ariadne> we should try to stick with doing things the normal way
2020-04-17 10:59:45 <PureTryOut[m]> It extracts the root fs to work in from the squashfs
2020-04-17 10:59:55 <Ariadne> which is what?
2020-04-17 11:00:20 <PureTryOut[m]> You don't know what a rootfs is...?
2020-04-17 11:01:05 <PureTryOut[m]> I guess I don't understand your question
2020-04-17 11:01:15 <Ariadne> I know what a rootfs is.  I'm asking why calamares needs a special one
2020-04-17 11:01:55 <Ariadne> why can't you just have an apkovl with calamares in world
2020-04-17 11:02:04 <Ariadne> with calamares apk on the disc
2020-04-17 11:02:07 <PureTryOut[m]> It doesn't need a "special" one, it just needs any rootfs to work in. Do some configuration, install some packages, then move it over to the specified partitions etc
2020-04-17 11:02:46 <ncopa> re samuria
2020-04-17 11:02:48 <ncopa> vs ninja
2020-04-17 11:02:57 <ncopa> is there some way to force use of ninja?
2020-04-17 11:02:58 <Ariadne> why can't it generate that at runtime with apk --root /tmp add alpine-base ?
2020-04-17 11:03:12 <AinNero> PureTryOut[m]: this is exactly the usecase for apkovl
2020-04-17 11:03:47 <Ariadne> we removed ninja
2020-04-17 11:04:18 <ncopa> oh, i thought we could select which to use
2020-04-17 11:04:40 <ncopa> so how should I go forward to see if this is a bug in chromium or it is a missing feature in samurai?
2020-04-17 11:05:48 <Ariadne> mcf: ping ^^^
2020-04-17 11:05:52 <Cogitri> Probably ask mforney
2020-04-17 11:06:46 <ncopa> i thin it would be nice to be able to select which one to use but default to samurai
2020-04-17 11:07:11 <Cogitri> Yes, but maybe we can do that with 3.13?
2020-04-17 11:08:00 <_ikke_> ninja was moved to unmainted
2020-04-17 11:08:12 <PureTryOut[m]> Ariadne: because it only has very basic package manager support (just `apk update`, `apk add`, and `apk remove`) really. I'll see if I can make something work
2020-04-17 11:08:16 <Cogitri> Or rather once we've discussed https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/42
2020-04-17 11:08:32 <Cogitri> If we do this and something similiar for meson then we won't have to rework all APKBUILDs to use a different build tool (ninja vs samu)
2020-04-17 11:09:53 <Ariadne> at any rate, a bootstrap squashfs would be packaged like any other apk
2020-04-17 11:10:11 <ncopa> could we not simply have a ninja package that conclifcts with samurai?
2020-04-17 11:10:19 <Ariadne> but seems like a dubious design
2020-04-17 11:10:26 <Ariadne> ncopa: I think it would work
2020-04-17 11:10:28 <Ariadne> but
2020-04-17 11:10:50 <ncopa> http://tpaste.us/RzkW
2020-04-17 11:10:53 <Cogitri> Then we'll have to change depends for all APKBUILDs
2020-04-17 11:10:56 <Ariadne> ninja would win over samurai
2020-04-17 11:11:03 <Ariadne> in such a scenario
2020-04-17 11:11:05 <Ariadne> I think
2020-04-17 11:11:22 <Ariadne> unless it took a different name and provided ninja with lower priority
2020-04-17 11:11:32 <Ariadne> in which case a conflict isn't needed
2020-04-17 11:11:40 <nmeum> is it just me or are https://git.alpinelinux.org/abuild/ and https://gitlab.alpinelinux.org/alpine/abuild/ out of sync?
2020-04-17 11:11:59 <Cogitri> Seems very out of sync
2020-04-17 11:12:01 <ncopa> why dont we just change the makedepends to samurai if that is what we want to use?
2020-04-17 11:12:13 <Cogitri> But you're suppoed to push to gitlab.a.o and not g.a.o, nmeum
2020-04-17 11:12:14 <Cogitri> I though g.a.o is readonly actually
2020-04-17 11:12:29 <nmeum> yep, forgot to update my remote for that repository
2020-04-17 11:12:36 <ncopa> nmeum: i think its a diskcussion for #alpine-infra
2020-04-17 11:12:39 <Cogitri> <ncopa "why dont we just change the make"> We have to change the deps and build tool invocations for hundreds of APKBUILDs then
2020-04-17 11:12:41 <nmeum> ncopa: ok
2020-04-17 11:12:42 <PureTryOut[m]> Ariadne: I doubt Calamares supports running arbritatry commands, and even then I'm not sure I can passit the required location of the chroot, but I'll ask around
2020-04-17 11:13:10 <Ariadne> PureTryOut[m]: well I provided an alternative: make an APKBUILD which generates the squashfs
2020-04-17 11:13:13 <Cogitri> But I'm fine with replacing the deps. Can you take a look at abuild!42, ncopa? Then we at least wont have to switch that twice
2020-04-17 11:13:36 <PureTryOut[m]> Ariadne: yeah I understand but that seems very ugly
2020-04-17 11:13:52 <Ariadne> it ensures the squashfs is signed
2020-04-17 11:13:54 <Cogitri> We can call meson build -C build instead of ninja -C build, then we don't have to change anything when changing from samu to ninja other than the dependency
2020-04-17 11:14:38 <PureTryOut[m]> I think I found a way to run commands and even pass it the chroot location, I'll see if this works
2020-04-17 11:15:23 <Ariadne> if we are to ship an arbitrary FS for an installer (presumably this is modelled after anaconda's stage1 stuff)
2020-04-17 11:15:30 <Ariadne> I think it is best it is signed anyway
2020-04-17 11:15:50 <Ariadne> because otherwise an attacker could install a backdoor in the squashfs
2020-04-17 11:18:47 <ncopa> are there any volunteer to take over chromium package?
2020-04-17 11:19:39 <Ariadne> I think chromium and other desktop stuff is a good candidate for team maintenance
2020-04-17 11:19:39 <Cogitri> That's quite the task
2020-04-17 11:20:04 <Ariadne> having a working group for those tasks would be good
2020-04-17 11:20:18 <Ariadne> I am willing to facilitate such a working group incidentally
2020-04-17 11:21:13 <Cogitri> Maybe the notion of maintainer teams would make sense in general (e.g. a KDE and a GNOME team), but I think that we'd mostly have one-man teams anyway
2020-04-17 11:21:22 <ncopa> i dont mind having a working group, but i want one person to have the top-level responsibility, to avoid a group where everyone hopes that other team member takes care of it
2020-04-17 11:21:48 <PureTryOut[m]> I'd love a KDE team to help me out 😃
2020-04-17 11:22:23 <Cogitri> I'm afraid it'd just be an unnecessary layer of bureaucracy though
2020-04-17 11:22:42 <Cogitri> I'm pretty happy with the status quo to be honest
2020-04-17 11:22:49 <ncopa> question is if it is unnecessary
2020-04-17 11:22:57 <Cogitri> Anyway, I don't have resources to take on Chromium too, FF does the trick for me
2020-04-17 11:23:09 <Ariadne> ncopa: that's why I suggest having a designated facilitator for teams
2020-04-17 11:24:20 <Ariadne> (and I'm willing to assist with KDE as well)
2020-04-17 11:24:25 <Cogitri> As long as we don't make membership in teams necessary for anything it's fine for me
2020-04-17 11:24:45 <Cogitri> As in teams may be maintainers but you don't have to be in some team to make changes to something
2020-04-17 11:24:52 <ncopa> Cogitri: re chaging the deps and build tool invocations for hundres of APKBUILDs, I think that would make sense to run a sed to do that in a bulk
2020-04-17 11:25:15 <Cogitri> Right, but I imagine that with something like this we'll have a pretty high error rate
2020-04-17 11:25:25 <ncopa> in the sed?
2020-04-17 11:25:29 <Cogitri> Yes
2020-04-17 11:25:44 <Cogitri> And I'm not quite sure if meson and CMake can call samu directly or if they just expect it to be called ninja?
2020-04-17 11:26:08 <ncopa> i guess we only need to change the makedepends
2020-04-17 11:26:20 <Ariadne> Cogitri: precisely.
2020-04-17 11:26:42 <Cogitri> Ah, samu still provides a samu -> ninja symlink then?
2020-04-17 11:26:44 <Cogitri> Ariadne: Alright, then I'm all for it, great :)
2020-04-17 11:26:48 <ncopa> correct
2020-04-17 11:26:59 <Cogitri> Ariadne: But I guess that's something to be done after 3.12?
2020-04-17 11:27:20 <Ariadne> Cogitri: being part of some team would be voluntary, but if you are touching something that is team maintained and you're not on the team, then it's treated as a non-maintainer change
2020-04-17 11:27:25 <Cogitri> ncopa: Ah, got it. How do you only change the makedepends and not the ninja invocations though?
2020-04-17 11:27:34 <ncopa> Cogitri: correct
2020-04-17 11:27:36 <Cogitri> (I guess regex somehow but I'm pretty nooby with regex to be honest)
2020-04-17 11:27:59 <Cogitri> Ariadne: What special treatment do "non-maintainer" changes get?
2020-04-17 11:28:31 <Ariadne> well they have to be reviewed and some amount of time has to pass for the maintainer to either ack or timeout
2020-04-17 11:28:48 <ncopa> the benefit woudl be: 1) it is transparent that we use samu (and not ninja), 2) it makes it possible to override and actually use ninja if there would ever pop up a reason to why someone would want to do it
2020-04-17 11:28:59 <Cogitri> Meh, let's please not make maintainer reviews mandatory for anything but major changes
2020-04-17 11:29:01 <ncopa> 3) it would make it easier to debug samu
2020-04-17 11:29:05 <Ariadne> (there are exceptions of course, like urgent QA)
2020-04-17 11:29:40 <Cogitri> ncopa: Sounds good, I'm all for adding ninja back. I already had to bring it back a few times in my own repo to test if samu was broken (and it was)
2020-04-17 11:30:10 <ncopa> right, that is the exact problem i have at hand too
2020-04-17 11:30:10 <Ariadne> gitlab has features to facilitate teams already
2020-04-17 11:30:32 <Ariadne> for example, in Pleroma one can ping @plataformatec to escalate to elixir devs
2020-04-17 11:30:38 <ncopa> i dont know if samu is broken or not so i dont know if i should report it or try patch chromium
2020-04-17 11:30:44 <_ikke_> Ariadne: We already started doing that
2020-04-17 11:30:47 <Ariadne> we can do similar in our gitlab
2020-04-17 11:30:49 <_ikke_> we have @developers for example
2020-04-17 11:30:52 <Cogitri> Good, let's add ninja back then. Are you going to do the sed-ing, ncopa? Otherwise I can look at it later today
2020-04-17 11:31:08 <Cogitri> About patching chromium: I think the samu dev already did that a few times and upstream generally accepted those patches
2020-04-17 11:31:21 <_ikke_> https://gitlab.alpinelinux.org/developers
2020-04-17 11:31:29 <Ariadne> I think we should just build chromium with ninja
2020-04-17 11:31:57 <ncopa> so how do i move forward? should I wait that someone takes a look at chromium build issue and give me a patch?
2020-04-17 11:32:03 <Cogitri> Probably easiest, yes
2020-04-17 11:32:06 <ncopa> or should I report it to samu?
2020-04-17 11:32:41 <ncopa> Ariadne: my current problem is that it is not possible
2020-04-17 11:32:44 <_ikke_> ncopa: at least create an issue on gitlab?
2020-04-17 11:32:50 <Ariadne> _ikke_: yes, precisely.  so then we can create more teams for things like @kde et al
2020-04-17 11:33:17 <Ariadne> ncopa: I think let's reintroduce ninja and make ninja vs samu explicit
2020-04-17 11:33:39 <PureTryOut[m]> Ariadne: I don't fully understand `apk --root`. When doing any command with a `--root` specified, it just fails to lock the database (no such file or directory). Does it look for the database in the `--root`? At this point that is just an empty directory
2020-04-17 11:34:04 <ncopa> _ikke_: that makes sense, but at this point i dont know if it was introduced with the MR i sneaked in before i started work on the upgrade
2020-04-17 11:34:14 <ncopa> its unlikely
2020-04-17 11:34:36 <ncopa> ok, let me drop the upgrade and only do the MR/fix
2020-04-17 11:34:41 <PureTryOut[m]> Oh nvm there is a `--initdb` switch I see
2020-04-17 11:34:48 <Ariadne> PureTryOut[m]: yeah initdb :)
2020-04-17 11:35:09 <ncopa> i wanted save time and do the upgrade, since it takes significant time to build chromium
2020-04-17 11:35:42 <ncopa> and i really wanted to start with the 3.12 builder bootstrap
2020-04-17 11:36:44 <Ariadne> 3.12 mips bootstrap will be slightly delayed, our jump box corrupted it's /etc/shadow.  should have it fixed by Monday I guess
2020-04-17 11:37:52 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/issues/11405
2020-04-17 11:38:25 <ncopa> Ariadne: re mips, i wonder if we should test make an edge release, so we get a release tarball and docker image for edge
2020-04-17 11:38:37 <ncopa> it would also test if the release script works for mips
2020-04-17 11:38:52 <ncopa> I guess we would test it on monday
2020-04-17 11:39:04 <Ariadne> well right now we can't cook a docker image
2020-04-17 11:39:12 <Ariadne> because I'm still fixing the dependency tree
2020-04-17 11:39:23 <Ariadne> this boltdb crap infects everything
2020-04-17 11:39:52 <Ariadne> there is bbolt, which is a fork that is actually maintained that builds fine on mips
2020-04-17 11:39:53 <Ariadne> haha
2020-04-17 11:43:55 <Cogitri> ncopa: So apparently there's a fix for Chromium w/ samu, I guess we can just apply that for now then and get back to 3.12?
2020-04-17 11:49:46 <nmeum> mps: did some experiments with the zig test suite, it seems to me that we don't want to enable the entire test suite anyhow as it will take quite some time to run. we can run individual parts of it though, e.g. `./zig build test-cli`
2020-04-17 11:51:31 <Cogitri> I guess we're not interested in the language correctness parts anyway
2020-04-17 11:52:05 <markand> Ariadne, I've added a comment to !6379
2020-04-17 11:55:11 <markand> :-)
2020-04-17 11:58:01 <Ariadne> markand: non-free is fine, but non-free will not be distributed on alpine mirrors
2020-04-17 11:58:32 <markand> not a big deal
2020-04-17 11:59:48 <Cogitri> So it's basically just the build recipe
2020-04-17 12:01:06 <markand> but maintained in a unique place with proper support from packagers
2020-04-17 12:01:14 <markand> still better than a AUR which has definitely no review
2020-04-17 12:02:01 <Ariadne> well, eventually, non-free and testing will be replaced with something else, but need to sit down and bang out the details
2020-04-17 12:02:22 <Ariadne> there is also apkfission which provides non-free and encumbered apks for alpine and adelie
2020-04-17 12:02:55 <markand> in the same spirit as RPMFusion then?
2020-04-17 12:09:52 <Ariadne> yes
2020-04-17 12:26:32 <PureTryOut[m]> I don't fully understand the live images still. If you boot the standard live iso, what on the ISO becomes `/` on the booted system? I thought it was modloop-lts but that doesn't seem to be it
2020-04-17 12:33:17 <ncopa> apparently i already added explicit dependency of samurai in february
2020-04-17 12:40:39 <ncopa> Cogitri: we already apply that patch
2020-04-17 12:43:12 <ncopa> doh
2020-04-17 12:43:16 <ncopa> im stupid
2020-04-17 12:43:17 <ncopa> i mean
2020-04-17 12:43:39 <ncopa> patching file tools/gn/bootstrap/bootstrap.py
2020-04-17 12:43:39 <ncopa> Reversed (or previously applied) patch detected!  Assuming -R.
2020-04-17 12:44:40 <ncopa> i still want ninja package to be available in alpine 3.12
2020-04-17 12:49:23 <Cogitri> Yup, a good idea nontheless
2020-04-17 12:51:17 <Ariadne> PureTryOut[m]: nothing
2020-04-17 12:51:40 <Ariadne> PureTryOut[m]: the / is assembled by initramfs using apk add --root /target --initdb [contents of /etc/apk/world]
2020-04-17 12:52:00 <PureTryOut[m]> Interesting
2020-04-17 12:52:24 <Ariadne> PureTryOut[m]: this is why i was asking why a squashfs would be needed :)
2020-04-17 12:52:50 <PureTryOut[m]> >  The typical approach with Calamares is actually neither to unpack a separate image (though some distros do that), nor to bootstrap the chroot from scratch (for which Calamares does not have builtin support), but to unpack the same image that is being booted as a live image.
2020-04-17 12:53:06 <PureTryOut[m]> quote from Calamares dev ^
2020-04-17 12:54:53 <PureTryOut[m]> Guess I'll have to bootstrap it anyway using shell commands
2020-04-17 12:55:11 <PureTryOut[m]> But annoyingly enough while doing that apk stays quiet and Calamares eventually thinks it timed out..
2020-04-17 13:00:03 <Ariadne> well, the image that is being booted as a live image is not something you would want to install as a traditional desktop ;)
2020-04-17 13:01:34 <PureTryOut[m]> well no, you can install extra stuff onto it, but the bit he was talking about is just the rootfs used as base to work on
2020-04-17 13:01:45 <PureTryOut[m]> I can write a custom module for bootstrapping it if you think that is the best approach
2020-04-17 13:06:01 <PureTryOut[m]> Ok so after bootstrapping, Busybox is installed but none of it's symlinks are 🤔
2020-04-17 13:06:21 <_ikke_> There is a trigger that runs a bb command to install the symlinks
2020-04-17 13:06:41 <_ikke_> busybox --install I believe
2020-04-17 13:07:20 <PureTryOut[m]> Does that not run on `apk add --root <somedir> --initdb alpine-base` though?
2020-04-17 13:07:38 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/busybox/busybox.trigger#L22
2020-04-17 13:07:43 <_ikke_> I have no idea :)
2020-04-17 13:07:55 <clandmeter> openssld
2020-04-17 13:08:01 <clandmeter> that sounds weird
2020-04-17 13:08:34 <Cogitri> Well, it's d bindings for openssl
2020-04-17 13:09:23 <clandmeter> it sounds like a openssl daemon
2020-04-17 13:10:02 <clandmeter> whatever that would be
2020-04-17 13:14:13 <kaey> i suggested at the time to make samurai-ninja subpackage with a single symlink, but it was ignored
2020-04-17 13:23:01 <markand> the unmaintained directory means there is no maintainer or the software is no longer maintained upstream?
2020-04-17 13:23:41 <markand> looks like the first one
2020-04-17 13:24:23 <Cogitri> Yup, it's the former
2020-04-17 13:27:58 <markand> if I want to take one, must it go through testing again first?
2020-04-17 13:29:21 <Cogitri> Doesn't hurt to make sure the builders like it
2020-04-17 13:42:44 <oneinsect> darn i dont know how you guys are managing but all the locales are 200MB uncompressed
2020-04-17 13:42:55 <oneinsect> in glibc
2020-04-17 13:43:42 <markand> is there an example of package to take reference on it, which install python bindings as a separate subpackage?
2020-04-17 13:49:08 <TBK[m]> markand: https://pkgs.alpinelinux.org/packages?name=*-py*&branch=edge&arch=x86_64
2020-04-17 13:49:57 <markand> thanks TBK[m]
2020-04-17 13:53:58 <mps> nmeum: re zig, yes I agree if we skip some unimportant test, though we skip them all now
2020-04-17 13:56:15 <markand> TBK[m], why the url variable should end with a / ?
2020-04-17 13:58:22 <TBK[m]> markand: Was not my intention so signal that. I just did a copy paste, which was to indicate that the site supports https which is preferred.
2020-04-17 13:58:41 <markand> oh okay
2020-04-17 13:59:08 <markand> ah yes, misread, understood :)
2020-04-17 14:12:34 <markand> 
ACTION is packaging ardour and related libraries

2020-04-17 14:12:40 <markand> funny that waf is widely used in the MAO area
2020-04-17 14:12:52 <markand> but not sure why someone would chose waf by choice
2020-04-17 14:13:34 <nmeum> mps: yep, I am currently experimenting with running a subset
2020-04-17 14:17:41 <mps> nmeum: nice. last time I tried there was one failed when tried to spawn something (forgot what exactly)
2020-04-17 14:18:04 <mps> maybe that happened because run in lxc
2020-04-17 14:18:24 <nmeum> I am currently running the test as https://tpaste.us/XgoE that seems to work so far but already takes a while
2020-04-17 14:18:40 <mps> and I didn't yet converted my arm64 to be full dev box
2020-04-17 14:19:18 <mps> yes, it takes time, but that is expected for these new langs
2020-04-17 14:20:00 <nmeum> I think we want to avoid blocking the builder for too long
2020-04-17 14:20:42 <mps> not relataed question, do we have tool in alpine which can convert markdown to man page and to be run in APKBUILD
2020-04-17 14:21:11 <mps> nmeum: crystal also take much time to run tests
2020-04-17 14:22:37 <mps> or, can we take README,md from package and convert it to man page
2020-04-17 14:23:26 <nmeum> iirc community/ronn can convert markdown to man pages (used by git-lfs for example) but ofc it can't take arbitrary formatted markdown documents
2020-04-17 14:23:51 <nmeum> if the markdown document is not designed to be converted to a man page I would just install it as is to /usr/share/doc/$pkgname/
2020-04-17 14:24:50 <mps> nmeum: thanks, your advice is so good that I will follow it :)
2020-04-17 14:24:58 <nmeum> (:
2020-04-17 14:32:58 <nmeum> mps: zig test suite passed, I will create an MR
2020-04-17 14:33:09 <nmeum> maybe you can test it on aarch64 before I push it?
2020-04-17 14:33:39 <mps> ok, I will, just post note when you create MR
2020-04-17 14:33:53 <nmeum> great
2020-04-17 14:36:20 <nmeum> mps: !6924 only tested the first commit so far, however, the other two commits are just cosmetic changes if your build fails in package() it's likely due to those cosmetic changes
2020-04-17 14:39:17 <mps> ok, I will run it in about 20-30 minutes, I'm out of home right now
2020-04-17 14:39:30 <nmeum> sure, it's not super important anyhow :)
2020-04-17 14:40:18 <mps> thanks
2020-04-17 15:09:44 <maxwell-k> I was preparing a MR for a package upgrade when I noticed several CVEs in the upstream changelog
2020-04-17 15:09:57 <maxwell-k> does that mean I should do something differently? I couldn't find anything on the wiki
2020-04-17 15:12:46 <_ikke_> maxwell-k: the CVE's should be recored in the secfixes section in the APKBUILD file
2020-04-17 15:13:22 <_ikke_> And depending on what repo, it should be backported to 3.11, or even upto 3.8
2020-04-17 15:13:27 <nmeum> and if the package is in main/ or community/ they should also be backported
2020-04-17 15:16:10 <_ikke_> maxwell-k: fsverity-utils fails, likely due to missing dep
2020-04-17 15:16:13 <_ikke_> mps: *
2020-04-17 15:17:38 <mps> _ikke_: yes, I see
2020-04-17 15:17:48 <mps> forgot linux-headers
2020-04-17 15:18:45 <mps> actually, forgot that we have CI ;)
2020-04-17 15:20:38 <_ikke_> :)
2020-04-17 15:24:01 <maxwell-k> _ikke_: ty for explaining
2020-04-17 15:25:45 <maxwell-k> !6926 is the MR, its the first time I've done this so just working out what a backport involves
2020-04-17 15:26:28 <nmeum> mps: zig tests actually passed on the aarch64 CI (I assumed it would time out) should I just merge it or do you also want to test it?
2020-04-17 15:27:37 <mps> It's still running in my lxc, but if it passed CI you can merge, I think
2020-04-17 15:28:48 <nmeum> if it's already running I will just wait
2020-04-17 15:30:13 <mps> hmm, just noticed I didn't started build with 'time' to see how much time it takes
2020-04-17 15:30:24 <nmeum> hehe
2020-04-17 15:32:04 <mps> 'Test 77/588', so much too :)
2020-04-17 15:32:58 <nmeum> that's just one test suite of the entire test set though :p
2020-04-17 15:33:17 <nmeum> and I already disabled yet a few tests
2020-04-17 15:33:24 <mps> yes, I see
2020-04-17 15:35:18 <mps> but it is good that lang have exhaustive tests, imo
2020-04-17 15:35:40 <nmeum> yeah
2020-04-17 15:35:55 <nmeum> generally speaking: zig does a lot of things right
2020-04-17 15:37:48 <mps> yes. ime, best languages are not made by companies or foundations or universities but by devoted individuals
2020-04-17 15:38:47 <mps> and other software, linux, musl etc are examples
2020-04-17 15:39:49 <AinNero> and php [dumpsterfire.jpg]
2020-04-17 15:52:42 <mps> nmeum: it is finished without error
2020-04-17 15:53:10 <nmeum> \o/
2020-04-17 15:53:17 <nmeum> do you want to merge it or should I?
2020-04-17 15:53:21 <nmeum> did you run it with time?
2020-04-17 15:53:28 <mps> please do
2020-04-17 15:53:43 <mps> no, I told that I forgot
2020-04-17 15:54:26 <nmeum> ah, right
2020-04-17 15:54:32 <nmeum> thanks for testing it!
2020-04-17 15:54:35 <mps> but it takes similar time as crysta
2020-04-17 15:54:48 <mps> np, thanks for fixing it :)
2020-04-17 15:54:59 <mps> crystal*
2020-04-17 15:54:59 <maxwell-k> working on some backports, what are the rules about `cd "$buildir"`?
2020-04-17 15:55:15 <maxwell-k> are there some versions where they are still required?
2020-04-17 15:55:26 <mps> maxwell-k: yes
2020-04-17 15:55:30 <Cogitri> No, it isn't required anymore
2020-04-17 15:55:38 <Cogitri> Alpine >= 3.8 supports it
2020-04-17 15:55:44 <mps> Cogitri: for older releases ?
2020-04-17 15:56:07 <nmeum> mps: do you still recall why you only enabled zig on x86_64 and aarch64? can we enable it on more architectures?
2020-04-17 15:56:26 <mps> iirc main doesn't work without cd $builddir
2020-04-17 15:56:44 <mps> on 3.9 I mean
2020-04-17 15:57:00 <maxice8> no
2020-04-17 15:57:27 <maxwell-k> my memory is hazy, just so I understand is that right 3.8 doesn't need it?
2020-04-17 15:57:28 <maxice8> main/gnutls on 3.9-stable has no 'cd "$builddir"' and works fine
2020-04-17 15:58:30 <mps> ah, so I forgot when it is 'fixed'
2020-04-17 15:58:40 <maxwell-k> maxice8: ty
2020-04-17 15:58:43 <maxice8> since Alpine 3.3 it is not a problem
2020-04-17 15:58:44 <maxice8> see alint(5) in atools-doc
2020-04-17 15:59:39 <mps> nmeum: I tried zig on armv7 and it fail, talked with upstream but there was no fix about 10-15 days ago
2020-04-17 16:00:16 <mps> maxice8: heh, times flies :)
2020-04-17 16:00:57 <nmeum> mps: we could just run it with arch=all on the CI and enable those on which it doesn't fail, but idk if that's a good idea
2020-04-17 16:01:55 <mps> nmeum: I'm not sure is good idea, but I'm sure it not bad idea :)
2020-04-17 16:01:56 <nmeum> the reason I am asking: I would like to move it to community/ for 3.12 (if that's ok with you) and enabling as many arches as possible might make sense then
2020-04-17 16:02:27 <mps> it is ok, imo
2020-04-17 16:03:00 <nmeum> I will just run it with arch=all on the CI, it's not my electricity bill after all ;)
2020-04-17 16:03:05 <mps> and if you want to take maintainership I'm not against :)
2020-04-17 16:04:13 <mps> I see that you work with it more than I and you know it better than I
2020-04-17 16:04:48 <nmeum> I am just experimenting with currently, not sure if I will end up using it long term
2020-04-17 16:05:04 <nmeum> but it's an interessting language for sure, that's why I would like to have it in 3.12
2020-04-17 16:05:59 <mps> well, I started few months ago but nowadays I don't have much time to experiment with it, because of $day_job
2020-04-17 16:06:45 <mps> and my $day_job is less and less programming
2020-04-17 16:08:27 <nmeum> yeah, my time to experiment with other languages and oss projects in general is also constrained by $day_job
2020-04-17 16:08:42 <nmeum> on s390x the build fails after during compilation
2020-04-17 16:09:06 <nmeum> ppc64le also
2020-04-17 16:09:37 <mps> hmm, just recalled that I tried that on CI about week ago
2020-04-17 16:10:16 <mps> sorry, I forgot, my uncle died yesterday so I'm little 'out of normal mind'
2020-04-17 16:10:30 <nmeum> sorry about that
2020-04-17 16:11:58 <mps> well, he was old (nearly 90) and we expected that end, but again we feel somewhat out of normal state of mind
2020-04-17 16:13:24 <mps> and I'm trying to 'calm' self by work
2020-04-17 16:16:32 <_ikke_> mps: my condolances
2020-04-17 16:17:03 <mps> _ikke_: thanks
2020-04-17 17:47:50 <_ikke_> Cogitri: apk-polkit is failing on aarch64
2020-04-17 17:49:36 <Cogitri> Yup, just saw it, thanks
2020-04-17 18:00:24 <Cogitri> I guess a polkitd bump would fix it
2020-04-17 18:08:39 <Cogitri> https://lwn.net/Articles/817668/ might be interesting to follow
2020-04-17 19:46:43 <_ikke_> I'm not subscribed to LWN
2020-04-17 19:53:10 <mcf> ncopa: Ariadne: Cogitri: i don't add a ninja symlink on my system, so there should be no problem with that (except that users might get confused and think they need to install ninja to build something)
2020-04-17 19:53:22 <mps> nor I'm but have some experience with discourse as mailing list on crystal lang, I'm not impressed by it
2020-04-17 19:53:51 <mcf> latest cmake and meson are both able to detect and use samu
2020-04-17 19:57:32 <Cogitri> ikke: TL; DR Debian is discussing to change to Discourse now
2020-04-17 19:57:33 <Cogitri> mcf: Ah nice, thanks for the info
2020-04-17 20:02:24 <mcf> but also, just want to say that patches shouldn't be blindly carried forward when updating a package to a new version. i've seen this with firefox, too, where i fix an issue upstream, and then see all these distributions apply their same patches anyway without checking if they are still needed
2020-04-17 20:16:26 <Cogitri> Having patch headers with upstream status etc. would help a lot with that
2020-04-17 20:21:36 <mps> mcf: is your previous nick mforney (or similar)?
2020-04-17 20:21:48 <mcf> yes
2020-04-17 20:22:16 <mps> ah, nice work with firefox, thank you :)
2020-04-17 20:26:00 <mcf> Cogitri: but who will add those patch headers? if i fix an issue upstream, i don't think it should also be my responsibility to add patch headers to every downstream, too. that's their job
2020-04-17 20:27:40 <mps> mcf: sure, maintainers or volunteers should do that
2020-04-17 20:29:23 <TBK[m]> an alpine standardized patch header would help...
2020-04-17 20:40:48 <Cogitri> mcf: You don't add that when you fixed an issue upstream, you'd add that when you add a new patch
2020-04-17 20:41:14 <Cogitri> So the condition for adding anything but trivial patches would be that there are 3 things mentioned in the patch header:
2020-04-17 20:41:22 <Cogitri> * Upstream status
2020-04-17 20:41:46 <Cogitri> * Link to upstream issue (and a pending MR if possible)
2020-04-17 20:41:47 <Cogitri> * Source
2020-04-17 21:36:24 <markand> is it possible to make source variable from a git clone? the software I want to package does not provide release explicitly because it requires git + submodules
2020-04-17 21:38:18 <markand> hmm looks like I could use fetch() function
2020-04-18 01:18:18 <fabrice_d> Is it possible to install packages from different arch on the same host? To cross compile Rust programs, we need rust-stdlib for the target
2020-04-18 01:20:07 <fabrice_d> I tried `apk add --arch aarch64 rust-stdlib` but that didn't work
2020-04-18 01:27:54 <Ariadne> no, it is not possible
2020-04-18 01:30:55 <fabrice_d> so what is the use of --arch ?
2020-04-18 01:35:25 <[[sroracle]]> afaik it's only useful with --root
2020-04-18 01:37:22 <Ariadne> [[sroracle]]: and fetch
2020-04-18 01:37:39 <[[sroracle]]> oh it works with fetch? >_< that would have saved me some trouble today...
2020-04-18 01:38:28 <[[sroracle]]> i've been working on getting libabigail working for adelie (which is actually easy compared to getting elfutils to pass its test suite), alpine might be interested in that
2020-04-18 01:44:41 <fabrice_d> hm, `apk fetch --arch aarch64 rust-stdlib` fetched the x86_64 version
2020-04-18 02:25:40 <Ariadne> mps: yes, but you are already boycotting the mailing lists anyway.
2020-04-18 02:27:58 <Ariadne> _ikke_: https://lwn.net/SubscriberLink/817668/61d8572bc6f4a0f9/
2020-04-18 02:30:35 <Ariadne> anyway
2020-04-18 02:31:09 <Ariadne> my proposal is more like debian's: moving some mailing lists to discourse, and replacing other mailing lists (like -devel) with entirely different procedure (probably gitlab)
2020-04-18 02:33:34 <Ariadne> and some of this is already being implemented independently.  mkmr, for example effectively deprecates the aports list, allowing us to decommission it.
2020-04-18 07:00:53 <mps> Ariadne: it is not important that I boycott ML, discourse is not good as ML system, imo
2020-04-18 07:01:16 <Ariadne> mps: the proposal in question removes development from ML entirely
2020-04-18 07:02:02 <mps> yes, I read your mail, and I agree to some of your points (maybe most)
2020-04-18 07:02:27 <Ariadne> and replaces the alpine-user mailing list which is dead
2020-04-18 07:02:31 <Ariadne> with discourse
2020-04-18 07:02:36 <Ariadne> which would presumably be less dead
2020-04-18 07:03:26 <mps> could be, but not sure how discourse will be accepted by 'hard-core' ML users
2020-04-18 07:04:53 <Ariadne> well considering the hard-core ML users aren't even using the sourcehut list
2020-04-18 07:05:00 <Ariadne> i think it is kind of moot
2020-04-18 07:05:37 <Ariadne> i think we should align our user support channels with that of other distributions
2020-04-18 07:05:54 <Ariadne> fedora, debian, etc are all looking at or have already switched to discourse for that
2020-04-18 07:06:18 <mps> yes, yes. your points are correct but as you know there are always (number unknown in advance) of people who will dislike whatever new is introduced
2020-04-18 07:06:23 <Ariadne> yeah
2020-04-18 07:06:28 <Ariadne> well
2020-04-18 07:06:31 <Ariadne> whatever :p
2020-04-18 07:06:34 <Ariadne> can't make everyone happy
2020-04-18 07:06:39 <mps> true
2020-04-18 07:07:13 <mps> and at the end, we should not try that (impossible) mission
2020-04-18 07:08:08 <mps> btw, I installed discourse in docker to play with it
2020-04-18 07:08:19 <Ariadne> i agree that discourse's email gateway is limited
2020-04-18 07:09:50 <mps> nice thing about it is more modern interface (web, JS) and android
2020-04-18 07:11:10 <mps> (but show me anything perfect in this world :) )
2020-04-18 07:11:49 <Ariadne> right, and that's my point
2020-04-18 07:11:59 <Ariadne> i think its more useful to provide something that people want to use
2020-04-18 07:12:15 <Ariadne> almost everyone i talk to about this email stuff is basically like "i hate email anyway"
2020-04-18 07:12:41 <mps> agree, if we can know in advance what
2020-04-18 07:13:18 <Ariadne> hince my for development, gitlab, for support, discourse
2020-04-18 07:13:27 <Ariadne> discourse seems to be popular for user support
2020-04-18 07:13:36 <mps> again, your proposal on ML is good starting food for thinking
2020-04-18 07:14:26 <mps> food for brain*
2020-04-18 07:15:11 <mps> (I hope my metaphor is correct)
2020-04-18 07:18:07 <[[sroracle]]> food for thought
2020-04-18 07:18:33 <mps> [[sroracle]]: thanks
2020-04-18 07:19:23 <Ariadne> well the reality is
2020-04-18 07:19:34 <Ariadne> people were avoiding the MLs *before* sourcehut
2020-04-18 07:19:59 <Ariadne> sourcehut's eccentric approach to mail exacerbated this issue, but the MLs were already in decline prior to that
2020-04-18 08:00:28 <markand> I don't mind replacing the mailing system with another one (possibly mlmmj)
2020-04-18 08:00:37 <markand> but alpine user is still useful I think
2020-04-18 08:00:42 <markand> discourse is a PITA to use
2020-04-18 08:18:25 <Ariadne> alpine user is more useful if people actually use it
2020-04-18 08:45:03 <Cogitri> Would it be acceptable to rename package which has been in testing for a day and isn't user facing?
2020-04-18 08:45:27 <Cogitri> A few people have complained about openssld and polkitd sounding like daemons for openssl and polkit when they're actually D bindigns for those
2020-04-18 08:45:36 <Cogitri> So I guess I'll move them to openssl-d and polkit-d
2020-04-18 08:51:24 <mps> heh, I thought they are some kind of daemons
2020-04-18 08:59:31 <Cogitri> !6950
2020-04-18 09:07:16 <Cogitri> ikke: Somehow https://gitlab.alpinelinux.org/patrick330602/aports became un-public again apparently
2020-04-18 09:09:46 <Ariadne> he may have deleted it
2020-04-18 09:09:48 <Ariadne> and made a new copy
2020-04-18 09:09:56 <Ariadne> i see people do that on github all the time
2020-04-18 09:10:21 <Cogitri> Oh huh
2020-04-18 09:10:47 <Ariadne> so, i just pulled community/tor from every release of alpine because it is allegedly compromised
2020-04-18 09:11:30 <Ariadne> the maintainer suggested that the security contact that contacted them advised we should rebuild the packages instead
2020-04-18 09:11:45 <Ariadne> i don't think this is a good idea until we can prove the supply chain is secure for community/tor
2020-04-18 09:11:51 <ikke> Cogitri: ran the script again
2020-04-18 09:12:07 <Ariadne> because if we pull sources and recompute checksums
2020-04-18 09:12:13 <Ariadne> we may be introducing malware ;)
2020-04-18 09:16:22 <ikke> Yes, totally plausible
2020-04-18 09:38:01 <ikke> Ariadne: ncopa says you should make arch="" instead of commenting it out
2020-04-18 09:38:22 <Ariadne> oh were you able to reach him?
2020-04-18 09:38:40 <ikke> yes
2020-04-18 09:38:57 <Ariadne> okay, let me push out updates really disabling community/tor
2020-04-18 09:39:05 <Ariadne> hopefully we can get  in contract with "fire-eye"
2020-04-18 09:39:19 <Ariadne> i suspect we are actually talking to an APT who wants us to self-own ourselves
2020-04-18 09:39:23 <Ariadne> *but*
2020-04-18 09:39:36 <Ariadne> in the absence of knowing, the only thing we can do is pull the packages
2020-04-18 09:39:44 <ikke> Yes, makes sense
2020-04-18 09:40:59 <Ariadne> it's strange that arch="" is not equivalent to #arch="all"
2020-04-18 09:41:42 <Ariadne> ok lets see what the edge builders do
2020-04-18 09:41:58 <ikke> maybe due to this? https://git.alpinelinux.org/abuild/tree/abuild.in#n2714
2020-04-18 09:43:12 <Ariadne> verifying they are gone from master
2020-04-18 09:43:46 <Ariadne> ikke: arch="" didn't kill them from master, they are still in community/edge/x86_64/tor-0.4.2.7-r0.apk on master :(
2020-04-18 09:44:12 <ikke> yes, I see
2020-04-18 09:44:41 <Ariadne> this is annoying
2020-04-18 09:45:10 <Ariadne> let me figure out how buildrepo determines what to purge
2020-04-18 09:45:18 <ikke> there is no uploaded msg from the builders
2020-04-18 09:45:33 <Ariadne> yeah
2020-04-18 09:45:38 <Ariadne> buildrepo sees no reason to sync
2020-04-18 09:45:54 <Ariadne> are the packages gone on the builder?
2020-04-18 09:47:02 <ikke> no
2020-04-18 09:49:13 <Ariadne> so buildrepo loops on the directory tree
2020-04-18 09:49:26 <ikke> heh, so only purging it from aports would help
2020-04-18 09:49:49 <Ariadne> i see the problem
2020-04-18 09:49:49 <ikke> mv APKBUILD _APKBUILD?
2020-04-18 09:49:51 <ikke> ok
2020-04-18 09:49:56 <Ariadne> db:each() returns all aports
2020-04-18 09:50:07 <Ariadne> we should check if it is actually enabled
2020-04-18 09:50:22 <Ariadne> if not, then we don't put it in keep table
2020-04-18 09:52:43 <clandmeter> Ariadne: did you copy the packages locally?
2020-04-18 09:52:53 <Ariadne> no
2020-04-18 09:53:09 <clandmeter> how can you check them if they are gone?
2020-04-18 09:53:09 <Ariadne> i am trying to figure out why buildrepo does not purge packages disabled on an arch
2020-04-18 09:53:23 <Ariadne> great point
2020-04-18 09:53:33 <Ariadne> we should make copies of the source packages we have
2020-04-18 09:53:57 <Ariadne> right now though i am trying to figure out
2020-04-18 09:54:04 <Ariadne> how to make buildrepo purge the binaries
2020-04-18 09:54:05 <AinNero> was CVE-2020-8835 discussed here previously? eBPF Privilege Escalation
2020-04-18 09:54:06 <clandmeter> the cdn has a cache probably
2020-04-18 09:54:17 <Ariadne> AinNero: yes
2020-04-18 09:54:17 <clandmeter> so you could still fetch it
2020-04-18 09:54:23 <ikke> clandmeter: we check master directly, and verified it on the builder
2020-04-18 09:54:27 <Ariadne> AinNero: eBPF on alpine requires you to be root anyway
2020-04-18 09:54:37 <clandmeter> its better to have a the actual package imho
2020-04-18 09:54:57 <Ariadne> what matters is the source tarball actually
2020-04-18 09:55:15 <clandmeter> it depends what kind of issue it is.
2020-04-18 09:55:15 <Ariadne> if our supply chain is compromised, that is how it would be compromised
2020-04-18 09:55:27 <clandmeter> ikke:  what did you check?
2020-04-18 09:55:50 <Ariadne> clandmeter: ikke checked if the packages are still live, we are trying to pull them until we can prove they are safe
2020-04-18 09:56:47 <Ariadne> Aports:each() calls Aports:each_name()
2020-04-18 09:56:57 <Ariadne> which iterates over self.apks
2020-04-18 09:57:45 <clandmeter> setting arch="" does not work to delete the pkg?
2020-04-18 09:57:59 <ikke> no
2020-04-18 09:58:59 <clandmeter> i dont see it anymore
2020-04-18 09:59:07 <clandmeter> which mirror are you checking?
2020-04-18 09:59:18 <ikke> http://master.alpinelinux.org/alpine/latest-stable/community/x86_64/tor-0.4.1.9-r0.apk
2020-04-18 09:59:23 <ikke> 200 OK
2020-04-18 09:59:50 <Ariadne> i purged from edge, but it is still there
2020-04-18 09:59:50 <clandmeter> ah wrong search
2020-04-18 10:00:45 <Ariadne> certainly, if arch="" disables it, then that URL should be 404 for edge :)
2020-04-18 10:02:02 <Ariadne> or rather, this one http://master.alpinelinux.org/alpine/edge/community/x86_64/tor-0.4.2.7-r0.apk
2020-04-18 10:03:40 <Ariadne> one option is to rename the APKBUILD
2020-04-18 10:03:42 <Ariadne> i guess
2020-04-18 10:03:44 <Ariadne> as ikke says
2020-04-18 10:03:59 <Ariadne> but i think its better to fix buildrepo
2020-04-18 10:04:40 <clandmeter> i think it usually should just work
2020-04-18 10:05:01 <ikke> archive of all the src archives on the x86_64 edge builder for tor: https://dev.alpinelinux.org/archive/tor-src.tar
2020-04-18 10:05:56 <ikke> clandmeter: https://github.com/alpinelinux/lua-aports/blob/master/bin/buildrepo.lua#L239
2020-04-18 10:07:01 <ikke> clandmeter: purely the existince of the APKBUILD will keep it apparently
2020-04-18 10:07:26 <ikke> disabling it will preventing it to be built, but will not purge it apparently
2020-04-18 10:07:26 <clandmeter> what about the index?
2020-04-18 10:08:06 <ikke> apk update && apk info tor still returns tor
2020-04-18 10:09:47 <Ariadne> aha
2020-04-18 10:09:51 <Ariadne> i think i found problem
2020-04-18 10:09:57 <Ariadne> in buildrepo
2020-04-18 10:10:23 <ikke> It should check for :relevant()?
2020-04-18 10:10:42 <Ariadne> yes
2020-04-18 10:11:02 <Ariadne> if aport:relevant() then keep[...] = true end
2020-04-18 10:13:53 <Ariadne> but this is some ncopa-level shit
2020-04-18 10:14:10 <Ariadne> can you ping him :D
2020-04-18 10:14:20 <ikke> He said he would be able to help in a couple of hours
2020-04-18 10:14:35 <Ariadne> ok
2020-04-18 10:14:51 <Ariadne> in that case, arch="" and #arch="all" seem to be equivalent
2020-04-18 10:14:56 <Ariadne> so as soon as buildrepo is fixed
2020-04-18 10:15:06 <Ariadne> the packages should be removed from compose
2020-04-18 10:15:21 <Ariadne> and thus drop out of repos
2020-04-18 11:01:20 <mps> as I understand 'arch=""' it is intended to build new pushed aport but keep previous one in mirrors
2020-04-18 11:01:48 <mps> to prevent build*
2020-04-18 11:02:09 <clandmeter> im not sure that is what its intended to do
2020-04-18 11:03:00 <Cogitri> Why would you want to do that though, mps?
2020-04-18 11:03:03 <clandmeter> arch= should remove the pkg from the pkg list and get purged. i think aports index should match repo index.
2020-04-18 11:03:54 <clandmeter> its also very inconsistent
2020-04-18 11:04:06 <clandmeter> some pkgs will be available for some arches and some not.
2020-04-18 11:04:13 <mps> if we have pkgver 1.0 and upgrade to 1.1 doesn't work then 'arch=""' not build 1.1 but keep 1.0 (which is good).
2020-04-18 11:05:08 <mps> if we want to remove pkg we should have something else
2020-04-18 11:05:50 <clandmeter> having a older release of a package is a different feature
2020-04-18 11:05:51 <Cogitri> Why upgrade when you know it doesn't work?
2020-04-18 11:06:45 <clandmeter> mps: what you propose is that some packages can have different versions across arches
2020-04-18 11:06:48 <mps> well, things happens
2020-04-18 11:08:50 <mps> but, ok. maybe it is better to remove pkg which can't be built during upgrade
2020-04-18 11:51:13 <ikke> Ariadne: clandmeter https://github.com/alpinelinux/lua-aports/pull/3
2020-04-18 11:52:33 <Cogitri> Super nitty, but wouldn't it be `As of now` instead of `Now`? The current commit description sounds as if you changed it to only the behaviour we don't want
2020-04-18 11:53:33 <ikke> It was mean as, the behavior as it is now
2020-04-18 11:54:34 <ikke> adjusted the message
2020-04-18 11:55:26 <Cogitri> Thanks :)
2020-04-18 12:22:45 <ddevault> https://lwn.net/Articles/817668/
2020-04-18 12:22:55 <ddevault> ah, subscriber link https://lwn.net/SubscriberLink/817668/6e9f4b711819004b/
2020-04-18 12:25:21 <ddevault> but hey, just keep hammering away at the anti-email brigade, don't worry how many fingers you break along the way
2020-04-18 12:35:33 <Cogitri> I had posted that a bit above, Ariadne wrote a ML post after that
2020-04-18 13:17:49 <ncopa> ikke: re https://github.com/alpinelinux/lua-aports/pull/3
2020-04-18 13:18:08 <ncopa> i was not aware that we dont remove the package if we comment out arch
2020-04-18 13:18:22 <ncopa> , which is kind of interesting
2020-04-18 13:18:33 <ncopa> i actually thought we did
2020-04-18 13:18:39 <ikke> Right, everyone expected it
2020-04-18 13:18:53 <ikke> But it turned out it didn't
2020-04-18 13:18:59 <ncopa> there is actually a valid usecase when we may want the current behavior
2020-04-18 13:19:23 <ikke> New package doesn't build but old one is still valid?
2020-04-18 13:19:26 <ncopa> if we get build failure of a package
2020-04-18 13:19:32 <ncopa> we had a case last week i think
2020-04-18 13:19:34 <ncopa> or this week
2020-04-18 13:19:44 <ncopa> firefox in 3.11 was disable on arm
2020-04-18 13:19:48 <ncopa> due to build failure
2020-04-18 13:19:56 <ncopa> but hum....
2020-04-18 13:20:13 <ikke> So how can we distinguish between just preventing new build and actually purge
2020-04-18 13:20:30 <ncopa> i think im wrong
2020-04-18 13:20:52 <ncopa> it dont think it saved us in the firefox 3.11-stable case
2020-04-18 13:21:02 <ncopa> because it was an update that failed to build
2020-04-18 13:21:08 <ncopa> meaning that the old version got deleted
2020-04-18 13:21:17 <ncopa> and the new failed to build
2020-04-18 13:21:30 <ncopa> so i thikn what you propose is the correct thing to do
2020-04-18 13:22:02 <ikke> And is it something we want? A package kind of orphaned
2020-04-18 13:22:10 <ikke> On a single arch
2020-04-18 13:23:20 <ikke> People will perhaps continue updating the package, but not realizing that on the disabled arch there is still an even older version
2020-04-18 13:25:13 <ncopa> if its updated it will get removed
2020-04-18 13:25:22 <Cogitri> And it'll break eventually anyway with soname changes
2020-04-18 13:25:38 <Cogitri> So that seems like a ticking time bomb
2020-04-18 13:26:32 <ikke> Right
2020-04-18 13:30:17 <ncopa> i think the patch is correct
2020-04-18 13:30:48 <ncopa> but i will only apply it when i have time to deal with a disaster, which i dont have today
2020-04-18 13:39:03 <ikke> Understood. What do we want to do with tor? Manually purge
2020-04-18 15:32:48 <ikke> cmake is returning "-- Configuring incomplete, errors occurred!" How can I find what's actually missing?
2020-04-18 15:34:35 <Cogitri> Scroll up I guess
2020-04-18 15:34:44 <ikke> I tried, just see a bunch of warnings
2020-04-18 15:35:07 <ikke> maybe Missing po4a-translate. Can NOT create translated manpages
2020-04-18 15:35:08 <Cogitri> Can you send the log?
2020-04-18 15:35:08 <Cogitri> CMake has some very creative ways of showing errors
2020-04-18 15:35:09 <ikke> Missing po4a-updatepo. Can NOT update manpage translations
2020-04-18 15:35:41 <ikke> http://tpaste.us/lYNY
2020-04-18 15:36:22 <Cogitri> ```
2020-04-18 15:36:22 <Cogitri> CMake Error at src/external/rawspeed/cmake/build-type.cmake:31 (message):
2020-04-18 15:36:22 <Cogitri>   Unknown build type: NONE.  Please specify one of:
2020-04-18 15:36:22 <Cogitri> ```
2020-04-18 15:36:22 <Cogitri>   Debug;RelWithDebInfo;Release;Coverage;Sanitize;TSan;Fuzz
2020-04-18 15:36:50 <ikke> ah
2020-04-18 15:36:53 <ikke> thanks
2020-04-18 15:36:58 <ikke> The patch I had for that no longer applied
2020-04-18 15:51:52 <Cogitri> 👍️
2020-04-18 16:25:17 <artok> oh... that was it.. to set terminal font to support all utf emoticons etc
2020-04-18 16:59:09 <artok> cmake build dir CMakeFiles/ has output file
2020-04-18 16:59:20 <artok> and error file also
2020-04-18 16:59:40 <ikke> yes, but they weren't that more helpful
2020-04-18 17:06:33 <artok> oh yeah needs searching, much of compiler tests there
2020-04-18 17:06:57 <ikke> Now I at least know what to look for
2020-04-18 17:07:11 <ikke> error just found too many -error- switches
2020-04-18 17:07:29 <artok> build dir, ccmake . , hit configure, and errors are in the list =)
2020-04-18 17:07:39 <artok> this time gui is helpful
2020-04-18 17:09:28 <ikke> Or just a clear error message at the end
2020-04-18 17:10:29 <Cogitri> I think we can all agree that the easiest option is to port to meson :P
2020-04-18 17:10:49 <TBK[m]> xD
2020-04-18 17:11:42 <TBK[m]> Reminds me of https://xkcd.com/927/
2020-04-18 17:11:42 <alpine-meetbot> https://xkcd.com/927 | Standards | Alt-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.
2020-04-18 17:11:55 <ikke> good bot
2020-04-18 17:13:25 <ikke> Hmm, what if a python project complains about the package distribution not being found while running it's test suite :-/
2020-04-18 17:13:57 <ikke> __version__ = pkg_resources.get_distribution('sopel').version
2020-04-18 17:14:02 <ikke> Because it's not installed yet
2020-04-18 17:15:33 <ikke> I'll just open an issue upstream
2020-04-18 17:49:10 <Cogitri> I think we had something similiar in another package a bit ago
2020-04-18 17:49:24 <Cogitri> And setting PYTHONPATH didn't help so I just gave up and disabled that test
2020-04-18 17:55:21 <ikke> Opened a ticket
2020-04-18 17:55:28 <ikke> /issue
2020-04-18 19:29:10 <ikke> Cogitri: I forgot to do it, but now created the 3.13.0 milestone
2020-04-18 19:36:40 <Cogitri> Thanks
2020-04-18 19:39:14 <ikke> Ariadne: I saw you disabled zabbix for mips due to go components. I already had code to easily disable the go agent on specific arches
2020-04-18 19:39:42 <ikke> Ariadne: So if the go agent is the only thing that prevents zabbix being built, I guess we could use that, but I have no way to verify myself
2020-04-18 19:47:17 <ikke> restarting gitlab in a moment to upgrade to the latest patch release
2020-04-18 19:47:28 <maxice8> nice
2020-04-18 19:48:09 <Cogitri> 👍
2020-04-18 19:50:50 <ikke> gitlab is back up
2020-04-18 20:02:00 <PureTryOut[m]> maxice8: please revert !6958
2020-04-18 20:02:17 <PureTryOut[m]> I (as maintainer of that package) had comments left open that were unanswered, but you merged it anyway
2020-04-18 20:07:18 <ikke> PureTryOut[m]: fyi, it has been reverted
2020-04-18 20:07:56 <PureTryOut[m]> Thanks
2020-04-18 20:21:24 <markand> is make aliased to something in a APKBUILD? I get a strange error with a package but it builds fine if I ran plain make by hand in the source directory
2020-04-18 20:22:04 <maxice8> i think not
2020-04-18 20:22:07 <Cogitri> No
2020-04-18 20:22:08 <Cogitri> It's just make
2020-04-18 20:22:09 <Cogitri> Maybe it's *FLAGS related?
2020-04-18 20:22:14 <markand> hmmm
2020-04-18 20:23:08 <markand> I can't understand what's wrong here
2020-04-18 20:23:21 <markand> let's try with sh -x
2020-04-18 20:27:45 <markand> okay, I think it's the JOBS environment varialbe
2020-04-18 20:28:02 <markand> it fails to build if set
2020-04-18 20:28:20 <PureTryOut[m]> You can just do `make -j<some other number>` if that's the problem
2020-04-18 20:28:20 <ikke> why would that be?
2020-04-18 20:28:23 <PureTryOut[m]> Or just unset JOBS
2020-04-18 20:28:31 <markand> yes, I'm trying that
2020-04-18 20:28:35 <ikke> is it calling make itself?
2020-04-18 20:28:49 <PureTryOut[m]> Some build systems have problems with building multithreaded
2020-04-18 20:29:02 <ikke> But I wonder if that's the case here
2020-04-18 20:29:13 <PureTryOut[m]> No clue
2020-04-18 20:45:59 <markand> it's faust, fairly poorly written Makefile that calls itself to Cmake...
2020-04-18 20:46:24 <ikke> heh
2020-04-18 20:49:09 <maxice8> oh
2020-04-18 20:49:19 <maxice8> it is rare to have a well written Makefile
2020-04-18 20:49:33 <maxice8> most exist in the range from poorly to passable
2020-04-18 20:52:39 <PureTryOut[m]> Most projects just don't bother with plain Makefiles and use a more sane build system 🤷‍♂️
2020-04-18 20:54:51 <markand>  plain Makefiles are fines if they are correctly written, but it's rare though
2020-04-18 20:54:56 <markand> suckless's one are good
2020-04-18 20:58:49 <Cogitri> Meh, makefiles usually suck hard if you don't have the same system as the dev
2020-04-18 21:00:48 <markand> someone for !6909 ? I've restarted the build
2020-04-18 21:14:47 <PureTryOut[m]> Ugh does Busybox mv not do wildcard substitution?
2020-04-18 21:15:13 <Cogitri> Isn't that something the shell expands for mv
2020-04-18 21:16:12 <PureTryOut[m]> Idk but the APKBUILD doesn't seem to like it
2020-04-19 06:10:28 <Ariadne> ikke: seems reasonable.  we can try it
2020-04-19 06:14:58 <ikke> Ariadne: can you try this patch? http://tpaste.us/EOgJ
2020-04-19 06:14:58 <Ariadne> yes
2020-04-19 06:21:35 <Ariadne> give me a moment to set up a build environment where i can easily test that
2020-04-19 06:21:41 <Ariadne> but it looks like it is probably ok
2020-04-19 06:22:24 <ikke> sure, np
2020-04-19 06:56:22 <Ariadne> ikke: seems to build so far
2020-04-19 07:16:16 <ikke> ok
2020-04-19 07:17:08 <Ariadne> built successfully
2020-04-19 07:17:11 <Ariadne> feel free to push it
2020-04-19 07:17:24 <ikke> ok
2020-04-19 07:18:00 <ikke> and the go agent is just due to missing go, so far, right?
2020-04-19 07:19:27 <Ariadne> no, it fails to build because of boltdb
2020-04-19 07:19:33 <Ariadne> afaik
2020-04-19 07:19:50 <ikke> I mean the zabbix go agent (agent2)
2020-04-19 07:20:13 <Ariadne> yeah
2020-04-19 07:20:21 <Ariadne> boltdb is in the dependency tree of that, afaik :)
2020-04-19 07:20:37 <ikke> right
2020-04-19 07:20:54 <Ariadne> i did not look closely, i can run a build of agent2 on mips64 if you want and give you the log
2020-04-19 07:22:10 <ikke> Sure, if it's something upstream needs to fix, I'd like to report an issue for that
2020-04-19 07:22:27 <ikke> At least for the other platforms they have been responsive in fixing these issues
2020-04-19 07:25:24 <Ariadne> anyway, as soon as more ubiquiti edgerouter infinity become available, we'll look into sourcing some additional devices for the infra team
2020-04-19 07:26:00 <Ariadne> lots of people are snatching these up though, sooo lol
2020-04-19 07:26:07 <ikke> Can imagine
2020-04-19 07:26:43 <ikke> But to get docker to work, we'd need to switch to the forked boltdb library?
2020-04-19 07:27:45 <Ariadne> yes
2020-04-19 07:27:54 <Ariadne> there's some other things that need to be fixed too, but they are minor
2020-04-19 07:28:08 <Ariadne> that's going to be the focus for this coming week :)
2020-04-19 07:28:34 <ikke> ok
2020-04-19 08:20:13 <ikke>   Ariadne: did you receive the email from the university?
2020-04-19 08:58:04 <clandmeter> i just replied the email, i hope we can get some additional information.
2020-04-19 09:11:26 <Ariadne> i did
2020-04-19 09:18:32 <clandmeter> ok i had to fix smtp.a.o first, all my mails bounced
2020-04-19 09:23:42 <Ariadne> i am wondering if perhaps it is not that our packages are compromised, but that an APT is using them as part of a rootkit
2020-04-19 09:29:03 <ikke> According to the email, it would be a VPN filter trojan
2020-04-19 09:29:27 <Ariadne> what does "VPN filter trojan" mean though
2020-04-19 09:29:38 <Ariadne> i am starting to begin to believe that this ends in fire-eye being sued
2020-04-19 09:31:20 <ikke> https://en.m.wikipedia.org/wiki/VPNFilter
2020-04-19 09:31:44 <Ariadne> 	Edit
2020-04-19 09:31:44 <Ariadne> VPNFilter uses multiple third stage operations after the initial infection. One such function of VPNFilter is to sniff network data on a network connected to the infected device, and gather credentials, supervisory control and data. The data are then encrypted and exfiltrated via the Tor network.
2020-04-19 09:32:02 <Ariadne> so,what if this rootkit downloads and uses alpine packages (such as tor) for this purpose
2020-04-19 09:35:57 <Ariadne> i suspect, strongly, that we are being caught in the middle of some stupid cyberwar shit
2020-04-19 09:36:10 <Ariadne> and the answer is to lawyer up and send fire-eye a cease & desist advisory
2020-04-19 09:36:20 <Ariadne> i suspect they will stop flagging our shit if we do that
2020-04-19 09:36:55 <Ariadne> because claiming our packages are compromised by an APT is certainly harmful to the project's reputation
2020-04-19 09:38:05 <Ariadne> at any rate, i do not see any evidence showing the packages are compromised.  i think, we can restore them
2020-04-19 09:38:17 <Ariadne> if fire-eye continues to flag them, the answer is to C&D them
2020-04-19 09:38:21 <ikke> +1
2020-04-19 09:38:24 <Ariadne> that's my conclusion
2020-04-19 09:38:42 <clandmeter> i thought no package was removed yet?
2020-04-19 09:38:52 <ikke> Disabled in the repo
2020-04-19 09:39:01 <Ariadne> i committed changes to disable them, they weren't removed due to bug
2020-04-19 09:39:09 <clandmeter> yes, but in the end that has no effect
2020-04-19 09:39:13 <Ariadne> maybe we rebuild them just to avoid this fire-eye thing
2020-04-19 09:39:27 <clandmeter> yeah that should sane
2020-04-19 09:39:31 <clandmeter> sounds*
2020-04-19 09:40:33 <Ariadne> i suspect we should have communications with fire-eye, for two reasons
2020-04-19 09:40:55 <Ariadne> 1. maybe they are unaware that these VPNFilter people are using alpine components for their rootkit (which would certainly be interesting to them i suspect)
2020-04-19 09:41:26 <Ariadne> 2. hopefully with their awareness that the tor packages are just a third-party component these VPNFilter people are using, they will stop flagging our APKs
2020-04-19 09:42:05 <Ariadne> (also communicating this to them means they are liable for any further damage they do to us, which we could pursue litigiously)
2020-04-19 09:57:38 <mps> hmm, not sure if this should be updated on stable releases http://www.postfix.org/announcements/postfix-3.5.1.html
2020-04-19 09:57:59 <mps> doesn't look as important sec fix
2020-04-19 09:58:46 <maxice8> Yeah, seems like a release to work around glibc
2020-04-19 10:00:28 <Ariadne> in other news, this means that Alpine is being used as part of a cyber weapon in the nation-state cyber war
2020-04-19 10:00:33 <Ariadne> kick ass
2020-04-19 10:00:48 <mps> maxice8: yes, and gcc10 (which is not yet released)
2020-04-19 10:01:03 <Ariadne> however, their use of alpine in their cyber weapon is not our problem tbh
2020-04-19 10:01:06 <maxice8> Something to keep in mind once we update GCC to 10
2020-04-19 10:01:25 <Ariadne> and well, i like living, so i don't think i want to pick a fight with anybody making cyber weapons
2020-04-19 10:01:48 <Ariadne> so i will hope that fire-eye shall be less moronic in future
2020-04-19 10:02:06 <mps> maxice8: yes, you still keep your notes on wiki?
2020-04-19 10:02:19 <maxice8> Notes as in Release notes for 3.12 ?
2020-04-19 10:02:31 <mps> and I should start something  to have about such things
2020-04-19 10:02:58 <mps> maxice8: yes, notes for next release
2020-04-19 10:03:06 <maxice8> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0
2020-04-19 10:03:21 <mps> ah, nice. thanks
2020-04-19 10:03:27 <maxice8> But they are notes for what is in 3.12 not postfix
2020-04-19 10:03:56 <mps> yes, I know but anyway it is nice that you keep 'whats new' notes
2020-04-19 10:04:52 <mps> Ariadne: if you react to every 'such nice people/org' you be much too busy
2020-04-19 10:05:09 <Ariadne> mps: well, that too
2020-04-19 10:05:24 <Ariadne> mps: the only reason why we are aware of this is because fire-eye started flagging tor package as being part of a rootkit
2020-04-19 10:05:38 <Ariadne> but in reality, the rootkit is most likely an alpine image that does `apk add tor`
2020-04-19 10:06:19 <mps> hah, good marketing for alpine in 'cyberwar circles' :)
2020-04-19 10:15:33 <Ariadne> FULL SPECTRUM CYBER
2020-04-19 10:20:30 <Ariadne> i guess in today's wild world of making everything a docker
2020-04-19 10:20:40 <Ariadne> it is not surprising that rootkits may be dockerized too
2020-04-19 10:25:14 <Xe> easier to sploit open kubernetes clusters that way
2020-04-19 12:29:16 <clandmeter> mps: is lxcfs still used?
2020-04-19 12:29:22 <clandmeter> i remember somebody said it was not.
2020-04-19 12:31:49 <clandmeter> mps: i mentioned you in the issue
2020-04-19 12:46:13 <mps> clandmeter: some people use lxcfs
2020-04-19 12:47:03 <mps> about month ago someone even discussed it's use on #alpine-linux
2020-04-19 12:56:42 <mps> clandmeter: ah, I see issue. I don't think lxcfs is needed for our builders, but I don't know if there are some special (corner) cases maybe
2020-04-19 15:11:53 <ikke> ddevault: did someone backport the mecurial fix already?
2020-04-19 15:12:19 <ddevault> ikke: no
2020-04-19 15:12:28 <ikke> ok
2020-04-19 15:35:22 <ikke> Ariadne: tor 0.3.4 is not offered anymore
2020-04-19 15:37:19 <Ariadne> ikke: it is on archive
2020-04-19 15:47:27 <ikke> yes
2020-04-19 15:48:27 <ikke> hmm, 0.3.4.11 isnt
2020-04-19 15:48:49 <ikke> /var/cache/distfiles/tor-0.3.4.9.tar.gz is the latest I can find
2020-04-19 15:51:55 <ikke> Ariadne: https://archive.torproject.org/tor-package-archive/tor-0.3.4.11.tar.gz
2020-04-19 15:54:04 <Ariadne> yes
2020-04-19 15:54:18 <Ariadne> that's for 3.8 right
2020-04-19 15:54:50 <ikke> 3.9
2020-04-19 15:55:07 <ikke> 3.8 is 0.3.3.12
2020-04-19 15:55:10 <Ariadne> ok
2020-04-19 15:55:17 <Ariadne> both need to be fixed i think
2020-04-19 16:25:58 <ikke> ah, you fixed it already, good
2020-04-19 16:26:08 <maxice8> @ncopa fixed Xen secissues
2020-04-19 16:26:14 <ddevault> ikke: confirmed hg fix, thank you!
2020-04-19 16:27:13 <ikke> ddevault: Didn't get to it yet..
2020-04-19 16:27:21 <ddevault> lol
2020-04-19 16:27:24 <ddevault> maybe it was backported, then
2020-04-19 16:27:28 <ddevault> it's in the branch
2020-04-19 16:27:32 <ddevault> dunno who did it, though, they didn't say so
2020-04-19 16:27:46 <maxice8> I believe someone in the mailing list sent a patch
2020-04-19 16:28:05 <ikke> last update was 2 weeks ago
2020-04-19 16:28:23 <ddevault> well, in any case, it's there now
2020-04-19 16:28:25 <ddevault> problem solved :)
2020-04-19 16:28:40 <ikke> the patch on the mailing list is what reminded me in the first place :)
2020-04-19 16:28:55 <maxice8> e30587e6d086657c2b20040a01408e6a321fc5fc
2020-04-19 16:29:10 <ikke> that one is authored by ou
2020-04-19 16:29:12 <ikke> you
2020-04-19 16:29:21 <maxice8> It was requested by the person that did the original one
2020-04-19 16:29:28 <ikke> ah ok
2020-04-19 16:29:47 <maxice8> Also 2 weeks ago, April's 6
2020-04-20 06:38:16 <mps> \o
2020-04-20 06:40:00 <mps> ncopa: I think you will upgrade linux-lts soon, please look at my MR to enable fsverity, I want to move fsverity-utils to community before freeze
2020-04-20 07:07:28 <markand> oh dear, there are some people I know I'll never try to contribute with anymore
2020-04-20 07:07:49 <Cogitri> Ah?
2020-04-20 07:10:31 <markand> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6935/diffs#diff-content-708614e8105ee6b3e2bdcd5fe1fbafb2935ad4a0
2020-04-20 07:16:53 <Cogitri> oof
2020-04-20 07:29:17 <Ariadne> in case of glibc, ldconfig is indeed needed
2020-04-20 07:31:04 <markand> yes but that is not the responsability of a software to take care of all of that
2020-04-20 07:31:24 <markand> for example, I don't expect a software to call fc-config,rc-update or systemctl by itself when installing
2020-04-20 07:31:31 <markand> fc-cache*
2020-04-20 07:31:55 <markand> I've proposed at least to use -ldconfig instead so that make can ignore, response o far *sigh*
2020-04-20 07:33:35 <Ariadne> yes, i agree.  in case of alpine running on glibc, we would simply have a trigger that calls ldconfig at the end
2020-04-20 07:36:33 <Cogitri> In most meson things they check if DESTDIR is set and if not run that sort of stuff (e.g. fc-cache)
2020-04-20 10:09:03 <ncopa> markand: sorry about that experience with upstream. It happens once in a while, but thankfully not often.
2020-04-20 10:09:20 <markand> heh yes
2020-04-20 10:09:57 <ncopa> often those people are bitter for some reason. there are many unthankful and demanding opensource users
2020-04-20 10:12:58 <ncopa> rather than write what they should or should not do, you can add it as a "feature". for exameple using `LDCONFIG =? ldconfig` and then use `$(LDCONFIG)`. That way we can call the make wihout patching it: `make LDCONFIG=true` or similar.
2020-04-20 10:13:50 <ncopa> that said, i agree that ldconfig should not be called from a makefile. It is the package manager's job to do it if needed
2020-04-20 10:14:09 <ncopa> package manager normally do that as post-install hook or similar
2020-04-20 10:14:42 <markand> ah yes that's a good idea
2020-04-20 10:14:52 <markand> but with that kind of attitude I won't send a v2'ed patch
2020-04-20 10:16:26 <ncopa> do they have a public mailing list or bugtracker where this was discussed?
2020-04-20 10:16:41 <ncopa> i can try help adding comments
2020-04-20 10:17:18 <markand> no it does not even have a public SCM, I've dig his email address from the source code itself
2020-04-20 10:17:26 <ncopa> ah, ok
2020-04-20 10:17:59 <ncopa> does not seem he is interested in feedback then
2020-04-20 10:54:34 <clandmeter> ncopa: should we mention a security contact on our www?
2020-04-20 10:58:36 <ncopa> yes. I think we should
2020-04-20 10:59:00 <clandmeter> which section?
2020-04-20 10:59:11 <clandmeter> or do we want a specific one
2020-04-20 10:59:38 <clandmeter> would be nice if we emphasize security.
2020-04-20 10:59:52 <ncopa> I guess this would make sense: https://alpinelinux.org/community/
2020-04-20 11:00:02 <Cogitri> (Can we somehow funnel that email into gitlab issue?)
2020-04-20 11:00:28 <ncopa> everything is possible. the impossible just takes longer time...
2020-04-20 11:01:09 <Cogitri> Heh
2020-04-20 11:01:21 <ncopa> it would indeed be convenient to have it create private tickets on gitlab
2020-04-20 11:01:31 <Cogitri> Well, is there an easy way to do that? It'd be nice if every dev was able to see the issue and was able to reference it in commits
2020-04-20 11:01:58 <Cogitri> And "outsiders" can see how we've solved it then too (it documents progress)
2020-04-20 11:02:03 <ncopa> but i suspect that we may need to provide a public pgp key for the security@a.o email. people will want to encrypt that kind of messages
2020-04-20 11:05:44 <ikke> We could make something that receives the mail, decrypts it and creates an issue
2020-04-20 11:05:51 <ikke> problem is how would responses go
2020-04-20 11:28:27 <Cogitri> Hmm, maybe it should just send an automated message back saying that an issue has been created with the link?
2020-04-20 11:28:39 <Cogitri> Can we subscribe people without accounts (so just the email) to issues?
2020-04-20 11:28:47 <ikke> no
2020-04-20 11:29:00 <ikke> Not that I know of at least
2020-04-20 11:29:26 <Cogitri> Ah, that's unfortunate
2020-04-20 11:52:36 <Ariadne> ncopa: there is a certain kind of FOSS developer that is just releasing stuff because they see no reason not to, and those people seem to be the most like this
2020-04-20 12:31:50 <Ariadne> ncopa: tree is presently green.  i wonder if we should start the branch process
2020-04-20 12:32:15 <ikke> Ariadne: branching is only done at release time
2020-04-20 12:32:26 <Ariadne> i know
2020-04-20 12:32:28 <Ariadne> what i mean is
2020-04-20 12:32:42 <Ariadne> with the tree green, starting the builders is a good time
2020-04-20 12:33:19 <ikke> I guess they still need to be built
2020-04-20 12:38:05 <Ariadne> right, that's my point
2020-04-20 12:38:12 <Ariadne> he expressed interest in doing that this week :p
2020-04-20 12:39:26 <ikke> At which point some packages may fail to build again
2020-04-20 12:39:36 <ikke> I understand your point :)
2020-04-20 14:13:23 <Cogitri> ```
2020-04-20 14:13:23 <Cogitri> >>> test-a: Updating the abuilds/x86_64 repository index...
2020-04-20 14:13:23 <Cogitri> ERROR: test-a-1.0-r0.apk: Not supported
2020-04-20 14:13:23 <Cogitri> Huh, what is abuild trying to tell me
2020-04-20 14:13:23 <Cogitri> ```
2020-04-20 14:14:40 <ikke> I've never seen that one
2020-04-20 14:15:07 <Cogitri> Ah, apparently that happens when you forget to change the name of your test case so two test cases write to the same test dir :D
2020-04-20 14:15:50 <ikke> are these tests for abuild itself?
2020-04-20 14:16:13 <Cogitri> No, for apk-polkit
2020-04-20 14:16:16 <ikke> ah
2020-04-20 14:16:21 <Cogitri> I need to generate a test repo to test against
2020-04-20 14:16:45 <Cogitri> To speed things up I'm building it for all test cases at once, but that fails badly if I run two test cases against the same dir in parallel
2020-04-20 14:37:41 <mps> ncopa: you didn't merged !6965 ?
2020-04-20 14:37:55 <mps> any reason?
2020-04-20 14:43:52 <ncopa> oh. i just missed it. sorry
2020-04-20 14:44:19 <ncopa> could you also include why those are enabled in the commit messages?
2020-04-20 14:44:23 <ncopa> did someone ask for it?
2020-04-20 14:44:35 <mps> ok, please don't forget next time :)
2020-04-20 14:45:02 <mps> no, there is no request from anyone afaik
2020-04-20 14:45:55 <mps> I pushed fsverity-utils in testing, and wait for kernel part to move it to community
2020-04-20 14:46:24 <mps> fsverity is for files that what dm_verity do for block devices
2020-04-20 14:49:07 <ncopa> and what is netredirect?
2020-04-20 14:50:12 <mps> it is added in sk_buff by default now
2020-04-20 14:51:09 <mps> let me find commit
2020-04-20 14:53:06 <mps> kernel git commit id f8c60f7a00516820589c4c9da5614e4b7f4d0b2f
2020-04-20 15:00:24 <ncopa> ok, but what is it?
2020-04-20 15:00:42 <ncopa> will go out for a run. bbl
2020-04-20 15:01:05 <mps> IFB depends now on it
2020-04-20 15:04:28 <mps> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.4.33&id=f8c60f7a00516820589c4c9da5614e4b7f4d0b2f
2020-04-20 17:04:28 <Ariadne> PureTryOut[m]: fyi, i added qt5-qtdeclarative dependency to grantlee, because kmail et al needs it
2020-04-20 17:05:14 <PureTryOut[m]> Does it actually display the mail now? I couldn't yet figure out how to get that working
2020-04-20 17:05:21 <Ariadne> yes
2020-04-20 17:05:45 <Ariadne> the one issue i haven't figured out is with konsole
2020-04-20 17:05:50 <Ariadne> control-B is being swallowed
2020-04-20 17:05:54 <Ariadne> so tmux does not work
2020-04-20 17:07:10 <PureTryOut[m]> Yeah neither is page back in Vim
2020-04-20 17:07:19 <PureTryOut[m]> That is only since a week or so, worked fine before that iirc
2020-04-20 17:07:26 <PureTryOut[m]> But awesome that you got  the last bit of kmail working 🎉
2020-04-20 17:07:40 <PureTryOut[m]> I can finally remove thunderbird from my system then
2020-04-20 17:12:02 <Ariadne> PureTryOut[m]: https://socially.whimsic.al/media/de82afc9-b89e-4df9-a784-eb4898ef08e4/image.png
2020-04-20 17:12:23 <PureTryOut[m]> Nice!
2020-04-20 17:12:27 <PureTryOut[m]> Did you push it yet?
2020-04-20 17:12:51 <Ariadne> yes, but builders are busy with chromium
2020-04-20 17:15:06 <PureTryOut[m]> Ah yeah sure
2020-04-20 17:37:48 <maxice8> Why does akonadi depend on a mariadb installation?
2020-04-20 17:39:04 <Ariadne> :D :D :D :D :D :D
2020-04-20 17:39:17 <Ariadne> because if you use sqlite
2020-04-20 17:39:24 <Ariadne> it is slow as shit
2020-04-20 17:39:30 <Ariadne> so it uses mysql embedded
2020-04-20 17:39:37 <Ariadne> mysqld does not actually run
2020-04-20 17:39:53 <Ariadne> or i guess, it does, but its a stripped down version
2020-04-20 17:41:47 <maxice8> But it needs to install 123MB mariadb itself for an embedded version ?
2020-04-20 17:42:31 <Ariadne> look
2020-04-20 17:42:34 <Ariadne> ppl using kde
2020-04-20 17:42:40 <Ariadne> don't care about disk space
2020-04-20 17:42:40 <Ariadne> :D
2020-04-20 17:43:13 <TBB> 
ACTION looks to the left at his KDE laptop with a package update window open

2020-04-20 17:43:21 <TBB> I guess not!
2020-04-20 17:44:17 <TBB> it's gotten so bad that the KDE project now even uses a package manager on their Neon release that doesn't report how much space new updates will take
2020-04-20 17:45:12 <maxice8> @Ariadne yeah but i just want to use KMail
2020-04-20 17:46:22 <Ariadne> afaik akonadi have multiple backends that can be selected
2020-04-20 17:47:11 <TBB> I could be wrong but they officially support just one
2020-04-20 17:47:30 <Ariadne> yeah, mysql :P
2020-04-20 18:27:52 <wsinatra> Anyone want to take a look at MR!6894 real quick? It should be ready to go
2020-04-20 18:52:50 <ncopa> wsinatra: done. Thanks!
2020-04-20 18:58:06 <wsinatra> ncopa: Thanks! I appreciate it!
2020-04-20 18:58:12 <wsinatra> On to more packaging :D
2020-04-20 19:51:03 <TBK[m]> !11419
2020-04-20 19:52:01 <TBK[m]> wrong command. take 2. #11419
2020-04-20 20:00:33 <ikke> Where do these exe files come from? Are they shipped in the source package?
2020-04-20 20:17:53 <TBK[m]> no clue, I have not taken the deep dive yet.
2020-04-20 21:01:26 <maxice8> Opinions on !6271
2020-04-21 00:08:43 <maxice8> install_if is in apk or abuild ?
2020-04-21 00:09:33 <[[sroracle]]> both?
2020-04-21 00:11:41 <maxice8> let me rephrase
2020-04-21 00:12:05 <maxice8> is it something only abuild recognize and makes some magic to apk understand in its own mechanisms or is install_if part of apk and an attribute you can set on the package like pkgname, url, pkgver, etc
2020-04-21 00:12:40 <[[sroracle]]> it's part of PKGINFO, and presumably APKINDEX
2020-04-21 00:12:47 <maxice8> so apk
2020-04-21 00:12:55 <maxice8> thanks for the answer
2020-04-21 00:13:04 <[[sroracle]]> (APKINDEX key "i")
2020-04-21 07:02:01 <PureTryOut[m]> Ariadne: found the issue with Ctrl + B in konsole: https://old.reddit.com/r/kde/comments/g0mbsl/tmux_ctrl_b_stopped_working_in_konsole/
2020-04-21 07:02:02 <alpine-meetbot> [REDDIT] Tmux `ctrl + B` stopped working in konsole. (self.kde) | 23 points (94.0%) | 11 comments | Posted by AffectionateMath6 | Created at 2020-04-13 - 16:30:00UTC
2020-04-21 07:02:40 <Ariadne> how do we um
2020-04-21 07:02:48 <Ariadne> patch our KDE to remove that
2020-04-21 07:02:56 <Ariadne> because i think we should
2020-04-21 07:03:25 <Cogitri> Can we maybe just ask upstream about that first?
2020-04-21 07:03:38 <Ariadne> "It looks like the issue is fixed in latest update."
2020-04-21 07:03:45 <Ariadne> maybe upstream already fixed it
2020-04-21 07:03:51 <Cogitri> Neat
2020-04-21 07:04:05 <Ariadne> but fixed it where
2020-04-21 07:04:09 <Ariadne> is the question
2020-04-21 07:04:48 <PureTryOut[m]> It got fixed already yes, no need to patch it
2020-04-21 07:04:58 <PureTryOut[m]> Probably KDE Frameworks
2020-04-21 07:06:08 <Ariadne> hmm
2020-04-21 07:06:13 <Ariadne> we are on kde frameworks 5.69
2020-04-21 07:07:31 <PureTryOut[m]> Yes, the latest. So either wait till 5.70 or find the patch and backport it
2020-04-21 07:08:12 <Ariadne> yes
2020-04-21 07:11:56 <Ariadne> hmm
2020-04-21 07:12:01 <Ariadne> i see
2020-04-21 07:12:04 <Ariadne> konsole
2020-04-21 07:12:07 <Ariadne> is what needs to be patched
2020-04-21 07:13:00 <Ariadne> https://cgit.kde.org/konsole.git/patch/?id=6db7f8d2
2020-04-21 07:15:43 <Ariadne> testing it
2020-04-21 07:17:45 <ikke> You mean reverting that/
2020-04-21 07:17:47 <ikke> ?
2020-04-21 07:22:42 <Ariadne> no
2020-04-21 07:22:49 <Ariadne> we need to add that patch
2020-04-21 07:22:56 <Ariadne> to work around kde frameworks 5.69
2020-04-21 07:23:02 <Ariadne> breaking an API
2020-04-21 07:23:18 <Ariadne> that patch is the fix
2020-04-21 07:25:14 <Ariadne> ok that patch works
2020-04-21 08:07:35 <ikke> The commit message is confusing the
2020-04-21 09:59:46 <Ariadne> i wonder if those loongson folks will realize that ensuring alpine works on loongson requires hardware :p
2020-04-21 10:04:21 <ikke> hehe
2020-04-21 10:05:36 <mps> loongson is mips based?
2020-04-21 10:05:43 <ikke> yes
2020-04-21 10:06:23 <mps> ah, I think I'm not interested then :)
2020-04-21 10:07:22 <ikke> Ariadne: But from our side it also requires space on the master server to support all those arches
2020-04-21 10:07:27 <ikke> and mirrors
2020-04-21 10:07:41 <mps> though I think mips arch is fine, but now I'm waiting for risc-v
2020-04-21 10:53:55 <mps> kernel 5.4.34 is landed
2020-04-21 10:55:13 <mps> iscsi fixes. do our infra use iscsi?
2020-04-21 10:55:37 <ikke> I think it's used on some servers
2020-04-21 11:26:30 <AinNero> Ariadne: i just saw the mip64el conversation
2020-04-21 11:26:55 <AinNero> if i understood them correctly, they want support for alpine as container
2020-04-21 11:27:10 <AinNero> so that the docker daemon not building would not be a blocker
2020-04-21 11:29:36 <ikke> It's a blocker for us though to provide proper support :)
2020-04-21 11:33:28 <u0jQx9gPyrYg> sounds like an interesting tool: https://nlnet.nl/project/GNUMes/ > GNU Mes was created to address the security concerns that arise from bootstrapping an operating system using large, unauditable binary blobs, which is common practice for all software distributions.
2020-04-21 12:01:02 <Ariadne> AinNero: the tools used to generate the docker image also FTBFS
2020-04-21 12:19:10 <mps> Ariadne: preparing linux-lts 5.4.34 upgrade, should I enable ' PKCS#8 private key parser (PKCS8_PRIVATE_KEY_PARSER) [N/m/y/?] (NEW)' for mips?
2020-04-21 12:19:31 <mps> I think yes, but want to ask you before
2020-04-21 12:25:04 <mps> hmm, with kernel 5.4.3* lots of defaults are added for mips, mips64, ppc64le and s390x
2020-04-21 12:26:31 <mps> looks like ncopa doesn't run his kernel-config.sh during upgrades
2020-04-21 12:42:57 <Ariadne> mps: yes
2020-04-21 12:46:20 <mps> ok
2020-04-21 13:28:23 <mps> Ariadne: !6965, commit https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6965/diffs?commit_id=2d7d30ec666a3ee83c3d374f4a3bb8586c4028d8
2020-04-21 13:29:14 <mps> if you have time, please look and tell do you agree with changes in .config(s)
2020-04-21 13:29:19 <Ariadne> looks ok
2020-04-21 13:31:21 <mps> you are fast. thanks
2020-04-21 18:28:31 <ikke> high severity ssl bugs: https://www.openssl.org/news/secadv/20200421.txt
2020-04-21 18:29:47 <krichy> hi all devs
2020-04-21 18:29:59 <mps> ikke: I think ncopa pushed upgrade
2020-04-21 18:30:07 <ikke> Ah, I see
2020-04-21 18:30:15 <krichy> I found that kea packages are not present in armhf community repo.
2020-04-21 18:30:28 <krichy> Is it intentional?
2020-04-21 18:30:50 <maxice8> it is required since log4cplus has failing tests on armhf
2020-04-21 18:31:04 <maxice8> if someone fixes log4cplus then i believe that kea can be enabled as well
2020-04-21 18:31:42 <krichy> are those logs available somewhere?
2020-04-21 18:32:01 <maxice8> probably deleted by now ?
2020-04-21 18:32:30 <krichy> i mean, where should I look for it? I am new to alpine builds, dont know where to look for.
2020-04-21 18:33:03 <ikke> I don't see the logs, indeed
2020-04-21 18:38:46 <krichy> i'll try to reproduce
2020-04-21 18:44:48 <TBK[m]> krichy: here is the upstream ticket for 2.0.4, I expect it being the issue for 2.0.5 - https://github.com/log4cplus/log4cplus/issues/407
2020-04-21 18:47:43 <krichy> thanks
2020-04-21 18:48:02 <krichy> but is still unresolved, am i right?
2020-04-21 18:48:24 <TBK[m]> it is
2020-04-21 18:48:42 <TBK[m]> still unresolved
2020-04-21 20:16:32 <ikke> There is a CVE for docker on 32-bit arches and ASN parsing (DoS). Wouldn't we need to rebuild all go packages again?
2020-04-21 20:20:59 <krichy> for a quick check, it seems that under debian/armhf log4cplus check runs without error
2020-04-21 20:25:25 <krichy> so yes, debian/buster with gcc 8.3.0 passes this test
2020-04-22 06:01:32 <Cogitri> OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f - https://www.openssl.org/news/secadv/20200421.txt
2020-04-22 06:02:05 <Cogitri> Oof
2020-04-22 06:03:40 <ikke> already updated in alpine
2020-04-22 06:03:58 <ikke> and the impact is a DoS
2020-04-22 06:05:48 <Cogitri> Ah, nice
2020-04-22 06:06:19 <Cogitri> Just read through the news during breakfast and saw it
2020-04-22 06:12:14 <ncopa> we need tag new releases
2020-04-22 06:13:27 <ncopa> i merged the ruby 2.7 update
2020-04-22 06:14:14 <oneinsect> how do you guys get time to maintain so many packages? you are just very few people? how do you get updates about new releases in public domain?
2020-04-22 06:16:49 <TBK[m]> oneinsect: https://release-monitoring.org/, https://pkgs.alpinelinux.org/flagged. Additional hands are always welcome.
2020-04-22 06:18:54 <oneinsect> ooh nice!
2020-04-22 06:29:25 <Cogitri> Repology.org also helps
2020-04-22 06:35:33 <oneinsect> nice
2020-04-22 06:36:00 <oneinsect> so this is how we keep track of updates for alpine
2020-04-22 06:37:03 <PureTryOut[m]> A combination of repology and https://release-monitoring.org/ would be best
2020-04-22 06:40:26 <mps> oneinsect: these are not only, different people use different methods
2020-04-22 06:41:00 <oneinsect> hmmm repology shows we have 915 packages as outdated
2020-04-22 06:41:10 <oneinsect> around 16.4%
2020-04-22 06:41:25 <oneinsect> what are the other sources?
2020-04-22 06:41:47 <mps> some are subscribed to upstream ML, some read news on sites, some look on sites for pkgs they maintain or interested in
2020-04-22 06:41:53 <Cogitri> Hm?
2020-04-22 06:42:07 <mps> and ofc, sec news/MLs
2020-04-22 06:42:11 <oneinsect> https://repology.org/repositories/statistics
2020-04-22 06:42:31 <oneinsect> Alpine Linux Edge statistics
2020-04-22 06:42:52 <TBK[m]> https://repology.org/projects/?inrepo=alpine_edge&outdated=1
2020-04-22 06:51:21 <oneinsect> one strange i encountered is say if I specify noarch for i18n() package, abuild says warning noarch must be avoid and if I dont set it then it gives me a warning says use noarch
2020-04-22 06:51:37 <oneinsect> i wonder how it determines when to suggest noarch
2020-04-22 07:15:47 <TBK[m]> ncopa: are you looking at the s390x ruby build problem?
2020-04-22 07:17:21 <TBK[m]> https://bugs.ruby-lang.org/issues/16455
2020-04-22 07:59:02 <mps> is this some kind of spam or? https://gitlab.alpinelinux.org/alpine/aports/issues/11430
2020-04-22 08:00:45 <ikke> Doesn't seem like it, looks like a genuine requet
2020-04-22 08:01:13 <AinNero> already 404
2020-04-22 08:01:26 <AinNero> havent even seen it
2020-04-22 08:01:48 <ikke> AinNero: it's marked confidential for some reason
2020-04-22 08:02:13 <mps> ikke: ah, then I don't understood it
2020-04-22 08:03:23 <Cogitri> ikke: Can you take out https://gitlab.alpinelinux.org/alpine/aports/issues/10612#note_82844 please?
2020-04-22 08:05:00 <ikke> Done
2020-04-22 08:08:15 <TBK[m]> Anybody got the answer for #11426 ?
2020-04-22 08:08:26 <Cogitri> Thanks
2020-04-22 08:16:36 <clandmeter> TBK[m]: alpine consists of many upstream projects, so it applies to a lot of licenses.
2020-04-22 08:21:05 <Cogitri> Its still problematic that we dont have license info on most alpine projects though
2020-04-22 08:21:45 <Cogitri> I guess aports is theortically a proprietary product that just happens to be developed in the open
2020-04-22 08:22:38 <Cogitri> But relicensing at this point will be no fun (but its possible, see LLVM)
2020-04-22 08:25:05 <PureTryOut[m]> The APKBUILDs don't have licenses, but the packages you use do though
2020-04-22 08:25:22 <PureTryOut[m]> We probably should have licenses for the APKBUILDs
2020-04-22 08:25:49 <TBK[m]> would be cool if we could generate a license report for each release type.
2020-04-22 08:26:03 <ikke> The question is how copyrightable APKBUILDs are in the first place
2020-04-22 08:26:20 <ikke> Most are derived from the same template
2020-04-22 08:27:42 <clandmeter> Cogitri: most alpine [projects have a license afaik
2020-04-22 08:27:47 <ikke> Asside from certain exceptions, there is little original work I gues (IANAL ofcourse)
2020-04-22 08:28:40 <Cogitri> clandmeter: apk-tools is the only alpine project having a license AFAICS
2020-04-22 08:29:27 <ikke> abuild: https://git.alpinelinux.org/abuild/tree/abuild.in#n7
2020-04-22 08:29:31 <Cogitri> ikke: Hm, I'm not a layer but I'd rather not just assume that APKBUILDs are such little original work that they aren't intellectual property of someone
2020-04-22 08:29:58 <Cogitri> Oh, we should probably put a LICENSE or COPYING file in there then
2020-04-22 08:30:24 <clandmeter> aports is much more complicated
2020-04-22 08:30:34 <ikke> yes
2020-04-22 08:30:43 <clandmeter> even if we license apkbuild it does not fix the named issue
2020-04-22 08:31:01 <Cogitri> TBK[m]: You can run apk info to list all license of the packages, no?
2020-04-22 08:31:21 <AinNero> i'd worry more about the patches we distribute with aports
2020-04-22 08:31:22 <TBK[m]> sure
2020-04-22 08:31:30 <Cogitri> AinNero: Also that
2020-04-22 08:31:49 <Cogitri> Especially since we usually just get those from git diffs without patch headers or anything
2020-04-22 08:32:02 <Cogitri> (We really, really need patch headers)
2020-04-22 08:33:04 <TBK[m]> I feel we need a RFC/RFD repo.
2020-04-22 08:33:43 <ikke> TBK[m]: The mailing list for now is still the cannonical place for that
2020-04-22 08:33:47 <Cogitri> I think that's in the progress of being created since Ariadne wants to scrap the ML
2020-04-22 08:34:52 <ikke> No final decission has been made yet, so as far as I know, nothing is in the proces of being created :)
2020-04-22 08:36:39 <Cogitri> Well, it's in the process of being discussed then :P
2020-04-22 08:38:05 <ikke> correct
2020-04-22 08:38:40 <ikke> So you are encourage to join the discussion if you want to see something to happen
2020-04-22 08:40:38 <TBK[m]> where can I find the scripts that generates the minirootfs archive?
2020-04-22 08:42:12 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts
2020-04-22 08:42:32 <TBK[m]> thanks :)
2020-04-22 08:44:26 <ikke> Archlinux btw also does not have any licenses specified for their PKGBUILDs
2020-04-22 08:46:37 <Cogitri> Void Linux, Exherbo and other distros do have that though
2020-04-22 08:49:01 <Cogitri> Also, about the ML discussion: I already said multiple times that the ML has to die (I guess I started the discussion on the ML actually), so I don't have much to say other than +1
2020-04-22 08:57:40 <clandmeter> that was the aports list, not the whole ml afaik
2020-04-22 08:58:10 <ikke> Ariadne mentions alpine-devel as well
2020-04-22 09:16:35 <nmeum> somewith with access to dev.alpinelinux.org around who could run abuild snapshot on !7081 for me?
2020-04-22 11:01:12 <ikke> nmeum: that change is not going to work, at least, everyone having already installed drawterm won't get the new version
2020-04-22 11:02:05 <Cogitri> apk upgrade -a being the default would be nice
2020-04-22 11:02:35 <ikke> it would break version pinning
2020-04-22 11:03:33 <PureTryOut[m]> Also `apk upgrade -i` being the default would be nice
2020-04-22 11:04:22 <ikke> as long as there is a way to disable that again
2020-04-22 11:05:46 <ikke> nmeum: /usr/bin/abuild: line 29: hg: not found
2020-04-22 11:07:49 <Cogitri> ikke: Then apk upgrade -a without the removing version pinning from world
2020-04-22 11:08:02 <Cogitri> But it'd be nice if people are actually downgraded when we downgrade something
2020-04-22 11:09:41 <ikke> nmeum: abuild snapshot is giving an error for me
2020-04-22 11:10:30 <nmeum> ikke: yes you need to install mercurial manually. I could have added it to makedepends but technically it's not needed for building the thing
2020-04-22 11:10:39 <nmeum> and we don't have $snapshotdepends ;)
2020-04-22 11:11:01 <nmeum> regarding the version change: I know that an apk upgrade -a is now required, could also stick to the old version scheme if that's prefered
2020-04-22 11:33:37 <Ariadne> clandmeter: yes, i want to see gitlab become the source of truth for tracking system changes instead of alpine-devel, since some people do not wish to use alpine-devel
2020-04-22 11:33:59 <ikke>  Ariadne what if someone refuses to use gitla?
2020-04-22 11:34:01 <ikke> gitlab
2020-04-22 11:34:23 <Ariadne> ikke: can't make everyone happy.  can optimize for the majority.  majority is already using gitlab for everything else.
2020-04-22 11:35:36 <Ariadne> and, gitlab allows us to do better management of system changes anyway
2020-04-22 11:35:45 <Ariadne> because we can put them on a kanban board or whatever
2020-04-22 11:35:48 <PureTryOut[m]> That would be a them problem imo
2020-04-22 11:37:17 <mps> for me keeping gitlab mirror on my local machine doesn't make sense, while MLs are already 'mirrored' locally
2020-04-22 11:37:31 <Ariadne> mps: that's fantastic, but you refuse to use the MLs anyway
2020-04-22 11:38:15 <Cogitri> Not sure if I understand your point, mps
2020-04-22 11:38:30 <mps> no, I don't refuse, I just wait till it be 'normal', but I still receive them and read them
2020-04-22 11:39:02 <Ariadne> we tried to make the MLs normal, that was met with "Sourcehut does not negotiate with terrorists"
2020-04-22 11:39:15 <Ariadne> and bluntly, i am not okay with Alpine being used as a weapon in somebody else's political agenda about e-mail
2020-04-22 11:39:27 <mps> the point is that the MLs are well established for some kind of communication, though I'm not against other means
2020-04-22 11:40:05 <Ariadne> so i think it is better to replace MLs with tools being used successfully instead where appropriate
2020-04-22 11:40:17 <Ariadne> then we can evaluate the future of the MLs
2020-04-22 11:40:18 <Ariadne> be that replace with discourse
2020-04-22 11:40:21 <Ariadne> keep the same
2020-04-22 11:40:26 <mps> well, we shouldn't decide for what will be used alpine
2020-04-22 11:40:27 <Ariadne> move them to mailman3 + hyperkitty
2020-04-22 11:40:51 <Ariadne> the project should not decide what tools it will use ?
2020-04-22 11:41:08 <mps> mailman3 + hyperkitty is best but also most complicated to setup
2020-04-22 11:41:29 <mps> oh, I misunderstood you
2020-04-22 11:41:33 <ikke> I'm not convinved btw that moving to gitab will increase participation (I'm not against moving to gitlab ftr)
2020-04-22 11:42:03 <mps> we should decide what we will use ofc, but not for what will be alpine used
2020-04-22 11:42:04 <Ariadne> ikke: i am not sure if it will increase participation reach, but i think it will increase productivity
2020-04-22 11:42:40 <Ariadne> because moving system change proposals to real issues means we can do all sorts of things with them
2020-04-22 11:43:15 <Ariadne> for example, using milestone tracking to generate agendas for various team meetings on jitsi
2020-04-22 11:43:25 <Ariadne> right now that has to be done by hand
2020-04-22 11:43:39 <Ariadne> with milestones, you have the list of things to discuss right there
2020-04-22 11:44:03 <Ariadne> seems like a big win to me
2020-04-22 11:44:54 <mps> yes, these things are ok, sure
2020-04-22 11:45:06 <Cogitri> We have meetings?
2020-04-22 11:45:14 <nmeum> ikke: sorry I am bothering you with this but any chance you can rerun abuild snapshot for drawterm or did you already create a snapshot?
2020-04-22 11:45:43 <mps> but I still think that ML is most appropriate for some development discussions
2020-04-22 11:45:59 <mps> Cogitri: you are right now on meeting :)
2020-04-22 11:46:21 <Ariadne> mps: i am fine with keeping the MLs, if that is what people want to do, as long as we separate *actionable* items into a better process that is not dependent on the ML
2020-04-22 11:46:25 <ikke> I get this error message:
2020-04-22 11:46:27 <ikke> bort: destination 'drawterm-0_hg20200421' is not empty
2020-04-22 11:46:42 <Ariadne> right now the question is "do we want to keep MLs or not"
2020-04-22 11:46:57 <ikke> nmeum: ok, success
2020-04-22 11:47:00 <nmeum> ikke: strange, I don't get that, do you have a clean $srcdir?
2020-04-22 11:47:05 <nmeum> ah, great
2020-04-22 11:47:06 <nmeum> thanks!
2020-04-22 11:47:06 <Ariadne> if we decide we want to keep MLs, then the question becomes "how do we solve the current issues with our MLs"
2020-04-22 11:47:08 <mps> Ariadne: I think we want
2020-04-22 11:47:12 <ikke> yeah, cleaned my srcdir
2020-04-22 11:47:42 <mps> although we are not against other means of communication
2020-04-22 11:47:46 <Ariadne> the reason why i proposed discourse as alternative to MLs is because it reduces burden on infra team
2020-04-22 11:48:14 <ikke> We'd have to host discourse instead
2020-04-22 11:48:25 <Ariadne> yes, but discourse ships as a docker image
2020-04-22 11:48:26 <mps> iiuc, we are only don't wont aports ML
2020-04-22 11:48:47 <mps> want*
2020-04-22 11:49:08 <Ariadne> what we want is a discussion mechanism for meta things
2020-04-22 11:49:11 <Ariadne> and support
2020-04-22 11:49:25 <ikke> Ariadne: our policy has always been that we eat our own dogfood, we prefer to have this images based on AL
2020-04-22 11:49:37 <Ariadne> one thing that is nice about mailman3 + hyperkitty
2020-04-22 11:49:41 <Cogitri> Killing ~/aports would be very be nice
2020-04-22 11:49:43 <Ariadne> is that it has a web UI
2020-04-22 11:49:50 <Ariadne> so you can use the mailing lists like a forum
2020-04-22 11:49:54 <Ariadne> just like with discourse
2020-04-22 11:50:15 <Ariadne> so i think m3/hyperkitty is an alternative that would solve the issue too
2020-04-22 11:50:16 <Cogitri> I wouldn't really mind the devel ML if visibility of past topics that were discussed wasn't so meh and participation was higher
2020-04-22 11:50:23 <ikke> As you are probably aware, we did have a forum which was basically abandoned
2020-04-22 11:50:42 <mps> discourse is not fine for ML, while mailmain3+hiperkitty is a lot better
2020-04-22 11:50:45 <Ariadne> ikke: yes, hince why we want to provide both formats for one channel
2020-04-22 11:50:57 <nmeum> the good thing about the ~/aports ML is that it allows one to submit patches without creating a gitlab account. as a downstream packager I am always annoyed when I need to create an account in some upstream bugtracker to submit a patch
2020-04-22 11:51:42 <Ariadne> i'm not against retaining ~/aports either, but the problem with ~/aports is, then sourcehut has value add
2020-04-22 11:51:52 <Ariadne> but sourcehut is presently holding our lists hostage
2020-04-22 11:51:54 <mps> nmeum: on most other projects when I send patches they usually accept it on their -devel list
2020-04-22 11:52:18 <Ariadne> and forking sourcehut to make it behave the way we want is not really a great use of time or resources
2020-04-22 11:52:25 <Cogitri> nmeum: But that's of no use if devs don't review your changes and they just rot forever
2020-04-22 11:52:30 <Cogitri> And no CI is really painful
2020-04-22 11:52:54 <Ariadne> besides, we can come up with a way to integrate patch submission into gitlab via email
2020-04-22 11:52:58 <Ariadne> infra team already working on this
2020-04-22 11:53:01 <nmeum> that would be neat
2020-04-22 11:53:51 <mps> eh, that is why I proposed switch from github to gitlab, option to send patches by mail to GL
2020-04-22 11:54:06 <Ariadne> mps: its restricted to enterprise
2020-04-22 11:54:14 <Ariadne> mps: but cooking our own solution is likely not difficult
2020-04-22 11:54:16 <mps> but didn't it is EE only
2020-04-22 11:54:30 <mps> didn't know*
2020-04-22 11:54:48 <Ariadne> anyway.
2020-04-22 11:54:57 <mps> uhmm have to accommodate to new keyboard
2020-04-22 11:55:05 <Ariadne> if people feel m3/hyperkitty is the way to go
2020-04-22 11:55:16 <Ariadne> then i'll start working on packaging it
2020-04-22 11:55:34 <mps> Ariadne: aiiii, you are hero then
2020-04-22 11:55:54 <Ariadne> and if infra team desires it, i can lend some of my sysadmins to help migrate / do whatever they need
2020-04-22 11:56:13 <ikke> Any help is appreciated
2020-04-22 11:56:46 <ikke> We're workign atm on getting some configuration automation to make our live easier in the future
2020-04-22 11:56:49 <Ariadne> ultimately i think the main reason why people avoid the MLs right now
2020-04-22 11:56:54 <Ariadne> is because when you respond on your phone
2020-04-22 11:57:03 <Ariadne> using the normal e-mail client that comes with your phone
2020-04-22 11:57:17 <Ariadne> you get greeted with a passive aggressive error message telling you to go read useplaintext.email
2020-04-22 11:57:30 <Ariadne> which for most people causes them to go "fuck this, i'm out"
2020-04-22 11:58:13 <Ariadne> but either way, i think we should track actionable items and proposals in gitlab
2020-04-22 11:58:21 <Ariadne> it is a huge workflow win
2020-04-22 11:59:08 <ikke> We are already kind of doing that (but there is probably still some gap)
2020-04-22 11:59:16 <Ariadne> even if participation remains the same on change proposals; we still win because it is easy to get a birds eye view of what is going on
2020-04-22 11:59:23 <mps> maybe I'm wrong but most of our communication is on IRC
2020-04-22 11:59:27 <Ariadne> yes
2020-04-22 11:59:35 <Ariadne> which IRC communication has its place
2020-04-22 11:59:43 <Ariadne> but coordinating system changes isn'tit
2020-04-22 11:59:57 <Ariadne> because 2 years from now you will wind up having to search through IRC logs
2020-04-22 12:00:01 <Ariadne> to find out why something was done
2020-04-22 12:00:24 <Cogitri> And it's easy to miss a discussion on IRC
2020-04-22 12:00:36 <mps> yes, because that I keep ML archive locally
2020-04-22 12:00:45 <Ariadne> i see IRC as more for real-time work
2020-04-22 12:00:53 <Ariadne> and ML/GitLab for planning
2020-04-22 12:01:16 <Ariadne> IRC is strong for working an issue *now*, but incredibly weak for planning
2020-04-22 12:01:29 <mps> agree
2020-04-22 12:01:58 <Ariadne> which means you get to go searching through the logs if you use IRC for planning
2020-04-22 12:02:49 <mps> whenever need to search something well 'search' will be used
2020-04-22 12:03:14 <mps> be it ML, IRC or some kind of forum, and GL
2020-04-22 12:04:23 <nmeum> some time ago we actually had a forum
2020-04-22 12:04:23 <mps> and, btw, some projects accepted my patches over IRC and paste
2020-04-22 12:06:20 <Ariadne> mps: yes, in some projects i accept patches over IRC and paste
2020-04-22 12:06:31 <Ariadne> mps: i even accept aports patches over IRC and paste
2020-04-22 12:06:43 <Ariadne> with common sense
2020-04-22 12:06:56 <mps> bbl
2020-04-22 12:07:02 <Ariadne> but here's the thing
2020-04-22 12:08:10 <Ariadne> alpine has millions of installs across 8 officially supported architectures *and* several more ports that have not been included upstream yet
2020-04-22 12:08:32 <Ariadne> there is a list of stakeholders a mile long
2020-04-22 12:09:08 <Ariadne> so you have to consider context.  alpine has to move in a more coordinated way for big changes, as these changes can ruin a lot of people's day
2020-04-22 12:09:48 <Ariadne> and we don't want to do that, alpine is (rightly) seen as a stable distribution
2020-04-22 12:11:02 <Ariadne> so the point of my proposal is largely to separate planning from the ML, so we can use our new, more superior tools for planning
2020-04-22 12:11:25 <Ariadne> what we do with the leftovers, it does not matter.  we can move to discourse, keep on sourcehut, move to mailman3/hyperkitty
2020-04-22 13:28:20 <ddevault> <mps> no, I don't refuse, I just wait till it be 'normal', but I still receive them and read them
2020-04-22 13:28:26 <ddevault> <Ariadne> we tried to make the MLs normal, that was met with "Sourcehut does not negotiate with terrorists"
2020-04-22 13:28:30 <ddevault> <Ariadne> but sourcehut is presently holding our lists hostage
2020-04-22 13:28:34 <ddevault> <Ariadne> and forking sourcehut to make it behave the way we want is not really a great use of time or resources
2020-04-22 13:28:44 <ddevault> what a pleasant thing to wake up to
2020-04-22 13:28:46 <ddevault> cut the crap
2020-04-22 13:28:50 <ddevault> what's normal? HTML email? cause you got it, several months ago
2020-04-22 13:28:59 <ddevault> the only list which doesn't have it enabled is aports, which is explicitly for patches, because if you send an HTML patch it's going to be broken
2020-04-22 13:29:17 <ddevault> but hey, you want HTML, you can have it. Go to the settings page, under the content tab. You demanded the feature, and I gave it to you, many months ago. Why should I care
2020-04-22 13:29:28 <ddevault> it's never been about email, it's been about control. This project is in a state of a constant power grab from half the players, at the expense of the rest, and of the project.
2020-04-22 13:29:36 <Ariadne> i have explained this to you numerous times, you choose not to listen.
2020-04-22 13:29:38 <ddevault> crappy behavior like this, from mpu and Ariadne and others besides, are the reason the Alpine community is a toxic place
2020-04-22 13:29:52 <ddevault> hateful lies, propeganda, backroom dealings, double crossings, this has been MY experience with the alpine community
2020-04-22 13:29:58 <ddevault> you want hyperkitty? go for it. You want to drop the MLs entirely in favor of Discorse? see if I care
2020-04-22 13:30:07 <ddevault> is that being "held hostage"? Fuck if I know. I left the infra chat months ago so you can do whatever you want
2020-04-22 13:30:11 <AinNero> ddevault: could you stop that
2020-04-22 13:30:16 <ddevault> I have long since lost any desire to engage with this community on more than the most basic levels necessary for the maintenance of my interests
2020-04-22 13:30:24 <ddevault> buzz off, AinNero
2020-04-22 13:30:41 <Ariadne> your changes accept emails that contain both text/plain and text/html, but do not work with e-mail clients such as iOS email and the default Android GMail client which only send text/html.
2020-04-22 13:30:46 <ddevault> you people can do whatever you want, but don't acuse me of holding you back, because I'm not
2020-04-22 13:30:56 <Ariadne> to which, i was told, by you, "Sourcehut does not negotiate with terrorists."
2020-04-22 13:31:26 <ddevault> quote whichever 6 words are convenient for telling your tale
2020-04-22 13:31:28 <ddevault> fine
2020-04-22 13:31:52 <ddevault> skip the part where I pointed out that anyone who uses mutt or alpine or aerc will be locked out of the conversation if there's no plaintext part
2020-04-22 13:32:06 <ddevault> or the part where I wrote a patch to accomodate for HTML users in the first place
2020-04-22 13:32:06 <Ariadne> i'm not interested in telling a tale, i am interested in mailing lists that do not advise people using commonly-used mailers to read a website that provides no useful information to them other than "try another app"
2020-04-22 13:32:11 <ddevault> go pound sand, Ariadne
2020-04-22 13:32:26 <Ariadne> right
2020-04-22 13:32:28 <Ariadne> anyway
2020-04-22 13:32:53 <AinNero> man wtf
2020-04-22 13:33:10 <oneinsect> why isnt this one updated https://gitlab.alpinelinux.org/alpine/alpine-baselayout/-/tree/master while this one is more recent https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/alpine-baselayout
2020-04-22 13:33:27 <oneinsect> why have same set of files at two locations?
2020-04-22 13:33:29 <Ariadne> i would like to just point out that our previous mailing list solution did generate a plaintext version of HTML mails sent to it
2020-04-22 13:33:32 <Ariadne> so that is not really true
2020-04-22 13:33:59 <ikke> Ariadne: fyi, ddevault left the channel
2020-04-22 13:34:06 <Ariadne> yes, i see
2020-04-22 13:34:09 <ikke> ok
2020-04-22 13:34:19 <Ariadne> i just wanted to still point out that our previous mailing list software *did* handle this fine
2020-04-22 13:34:25 <Ariadne> :)
2020-04-22 13:34:26 <ikke> (many people have it filtered out, so just wanted that to be clear)
2020-04-22 13:34:42 <AinNero> Ariadne: to be honest, the content of your discussion wasnt my primary concern
2020-04-22 13:34:57 <AinNero> i terms of conflict management it was a desaster.
2020-04-22 13:35:01 <Ariadne> well, the aggression was not that surprising
2020-04-22 13:35:23 <Ariadne> i am just trying to bring us back to where we were a year ago where the mailing lists at least work with android and iOS phones
2020-04-22 13:35:34 <oneinsect> i think someone resigned inbetween after writing a long email, i cant recollect his name
2020-04-22 13:36:02 <Ariadne> several people have resigned (some have come back)
2020-04-22 13:36:06 <oneinsect> he was dissatisfied with the something about alpine
2020-04-22 13:36:11 <oneinsect> hmmmm
2020-04-22 13:37:05 <Ariadne> including me, but that was largely over some attempt to introduce absurd amounts of bureaucracy for governance
2020-04-22 13:39:43 <Ariadne> anyway, it is not productive
2020-04-22 13:39:55 <oneinsect> hmmm
2020-04-22 13:43:55 <Ariadne> i don't think alpine is that toxic, really.  it used to be, but we have worked together to make things much better.
2020-04-22 13:44:54 <Ariadne> and, well, ddv did not really make it transparent to the infra team about the (intentional) limitations of his mailing list system when pushing it as an option
2020-04-22 13:45:07 <Ariadne> i suspect had he done so, we would not have adopted it
2020-04-22 13:52:18 <Ariadne> at any rate, the more useful line of discussion is how to move forward and solve these issues.  to that end, i'll work on getting mailman3/hyperkitty packaged as a first step towards fixing this mess
2020-04-22 13:52:19 <Ariadne> :)
2020-04-22 14:25:39 <TBK[m]> If I am not mistaken "Create merge request from email" is no longer an gitlab ee feature - https://about.gitlab.com/features/
2020-04-22 14:29:48 <Ariadne> oh, wow
2020-04-22 14:29:50 <Ariadne> even better
2020-04-22 14:32:14 <Cogitri> Nice
2020-04-22 14:36:13 <PureTryOut[m]> 
ACTION still likes mkmr though, don't discontinue development please 😃

2020-04-22 14:37:33 <maxice8> i won't
2020-04-22 14:37:46 <maxice8> i use it myself for all my merge request making and merging
2020-04-22 14:39:53 <PureTryOut[m]> Cool
2020-04-22 14:40:24 <Cogitri> I only use it for making MRs, having a look over things in the webUI is neat
2020-04-22 14:40:41 <Cogitri> (And it's easy to miss comments when merging via the cli)
2020-04-22 14:42:12 <mps> I'm back, have to comment one thing, alpine is not toxic but some people and good luck these are small numbers
2020-04-22 14:42:33 <mps> most people on alpine are quite nice and pleasant to work with
2020-04-22 14:42:55 <TBK[m]> The change might be part of https://about.gitlab.com/blog/2020/03/30/new-features-to-core/ . I have not been able to finding a clue about the change in the changelogs...
2020-04-22 14:55:40 <Ariadne> mps: i know that we have clashed heads before, but that was largely just out of frustration with the fact that many people do not use the current lists
2020-04-22 14:56:03 <Ariadne> and well, we are solving this somehow aren't we :)
2020-04-22 14:56:27 <mps> I hope, sure :)
2020-04-22 14:57:09 <mps> (just don't tell me what I can tell :) )
2020-04-22 14:57:24 <Ariadne> you can say whatever you want to say
2020-04-22 14:57:51 <Ariadne> fwiw, discourse was not something i was hugely committed to
2020-04-22 14:57:57 <Ariadne> it was more a discussion piece
2020-04-22 14:58:01 <mps> also, I think everyone can, just to care to not be offensive
2020-04-22 14:59:12 <mps> yes, I tried discourse and it fine but I think it is more suited for 'modern' people and not well suited for 'old fashioned' people
2020-04-22 14:59:12 <Ariadne> my goal, ultimately is to bring us to a point with the lists where as many people as possible are happy
2020-04-22 14:59:30 <Ariadne> i think hyperkitty is a better balance
2020-04-22 14:59:49 <Ariadne> because people who do not like email can still use the hyperkitty system
2020-04-22 15:00:04 <Ariadne> but hyperkitty acts as a well-behaved email client
2020-04-22 15:00:20 <mps> nice, if I know python I would help you, but can help by testing and seeing how to setup it
2020-04-22 15:01:48 <mps> actually I have it on debian installed
2020-04-22 15:11:25 <ncopa> unfortunate incident
2020-04-22 15:12:11 <Ariadne> it is what it is
2020-04-22 15:13:39 <Ariadne> i rather remain focused on moving forward, though
2020-04-22 15:13:48 <ncopa> Ariadne: i get your point, and I agree with your goal. I wish you could be slightly more diplomatic.
2020-04-22 15:14:07 <ncopa> and yes, i like that you keep focus on moving forward
2020-04-22 15:14:49 <Ariadne> drew may not like how i characterized alpine's adoption of sourcehut, but that is how people see it
2020-04-22 15:15:13 <ncopa> dealing with people is difficult
2020-04-22 15:15:15 <Ariadne> i rather we be truthful about things
2020-04-22 15:15:20 <ncopa> some are more difficult than others
2020-04-22 15:15:30 <Ariadne> we are talking about killing his kitten, he isn't going to be happy either way :p
2020-04-22 15:15:35 <ncopa> and i think drew is one of the omre difficult ones
2020-04-22 15:15:44 <ncopa> its not only that
2020-04-22 15:16:05 <Ariadne> drew will stew on it for a few months and realize that things weren't working out
2020-04-22 15:16:08 <ncopa> he has never felt included really, in alpine community
2020-04-22 15:16:15 <Ariadne> yes
2020-04-22 15:16:17 <Ariadne> i agree
2020-04-22 15:16:25 <Ariadne> and i tried to solve that, but it is not easy
2020-04-22 15:16:35 <ncopa> and that is not Ariadne's fault
2020-04-22 15:16:48 <Ariadne> many people lost trust in him over the sourcehut e-mail adoption issues
2020-04-22 15:16:54 <Ariadne> and how he responded to them
2020-04-22 15:17:16 <Ariadne> i can't fix the fact that his response to "my phone cannot send email to alpine lists" is https://useplaintext.email
2020-04-22 15:17:33 <Ariadne> i tried to tell him on fediverse that was a phenomenally bad idea
2020-04-22 15:18:28 <Ariadne> and another thing is
2020-04-22 15:18:31 <ncopa> as i said, some people are difficult to deal with
2020-04-22 15:18:47 <Ariadne> with riscv64 port, drew wanted to use sourcehut build system instead of our traditional build system
2020-04-22 15:18:55 <Ariadne> which again, isn't going to work
2020-04-22 15:19:38 <ncopa> tbh, i miss the times when sending patches to ML was enough.
2020-04-22 15:19:45 <ncopa> i have mixed feelings about gitlab
2020-04-22 15:19:49 <Ariadne> great news
2020-04-22 15:19:59 <Ariadne> gitlab moved the e-mail submission feature to CE
2020-04-22 15:20:01 <Ariadne> from EE
2020-04-22 15:20:12 <ncopa> i saw. i am not holding my breath though :)
2020-04-22 15:20:51 <Cogitri> I'm quite happy that we use Gitlab, reviewing patches and CI is a mess on the ML
2020-04-22 15:20:54 <ncopa> i think some things with gitlab is clumsy
2020-04-22 15:21:05 <Ariadne> i wish pagure was a more mature product
2020-04-22 15:21:09 <Ariadne> i would have suggested it instead
2020-04-22 15:21:09 <ncopa> Cogitri: I agree
2020-04-22 15:21:29 <ncopa> i belive gitlab was the right thing to do
2020-04-22 15:21:36 <Ariadne> on the other hand, red hat is pulling the plug on pagure basically
2020-04-22 15:21:47 <Ariadne> so i think gitlab is best option available to us
2020-04-22 15:21:47 <Cogitri> Yes
2020-04-22 15:22:11 <Cogitri> Pagure is going to die now unless Fedora decides to not use the infra RH provides (I doubt it)
2020-04-22 15:22:23 <ncopa> its not perfect but it is the least bad option :)
2020-04-22 15:22:31 <Cogitri> And Gitlab is more broadly used so I don't see the point in using Pagure
2020-04-22 15:22:45 <Cogitri> ncopa: I agree, Gitlab has some quirks but it's neat nontheless
2020-04-22 15:23:17 <ncopa> it makes it easy for people to contribute and get feedback
2020-04-22 15:23:28 <Ariadne> Cogitri: the value in pagure is that it was implemented by a distribution working at distro-scale
2020-04-22 15:23:40 <Ariadne> but it's moot now
2020-04-22 15:25:07 <ncopa> if sourcehut would have existed for 10 years ago i would been all for it
2020-04-22 15:25:24 <ncopa> it does not work for us, today
2020-04-22 15:25:34 <Cogitri> Yes :/
2020-04-22 15:25:47 <ncopa> that is not necessarily sourcehut's fault. it is just that emi
2020-04-22 15:25:55 <ncopa> email in general does not work for many ppl
2020-04-22 15:25:57 <Ariadne> if sourcehut would have existed 10 years ago, he would have been able to keep email from being less fucked
2020-04-22 15:26:29 <Ariadne> anyway, i think we have found a path forward
2020-04-22 15:26:41 <Ariadne> i thank everyone (including drew) for being patient as we navigated all issues
2020-04-22 15:26:45 <Cogitri> Gitlab with email support?
2020-04-22 15:26:52 <Ariadne> and providing constructive info
2020-04-22 15:26:59 <ncopa> +1
2020-04-22 15:27:01 <Ariadne> Cogitri: yes, but also using hyperkitty for lists
2020-04-22 15:27:15 <Ariadne> so we can have that "you can post to it from the web" experience
2020-04-22 15:27:21 <Ariadne> which was why discourse was interesting
2020-04-22 15:27:28 <Ariadne> you can have both email and web with hyperkitty
2020-04-22 15:27:46 <ncopa> hyperkitty can behave like a forum?
2020-04-22 15:27:52 <Ariadne> yes
2020-04-22 15:27:56 <Ariadne> sort of.
2020-04-22 15:28:16 <Ariadne> you can post from the hyperkitty web interface
2020-04-22 15:29:01 <ncopa> ugh, its sluggish...
2020-04-22 15:29:04 <ncopa> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
2020-04-22 15:29:22 <Ariadne> it also has thumbs up/down like discourse
2020-04-22 15:29:51 <Ariadne> ncopa: i think thats because of the fedora DC move
2020-04-22 15:30:00 <Ariadne> ncopa: normally it is pretty snappy
2020-04-22 15:30:27 <Cogitri> Seems OK to me
2020-04-22 15:30:38 <Cogitri> Not the fastest thing in the world but seems fine to me
2020-04-22 15:30:57 <maxice8> Cogitri: didn't Void Linux use discourse ?
2020-04-22 15:31:05 <Cogitri> I think they do
2020-04-22 15:31:21 <Cogitri> Haven't used it though, I only use the freedesktop and GNOME Discourse
2020-04-22 15:31:33 <maxice8> did, forum.voidlinux.com was yeeted
2020-04-22 15:32:15 <Cogitri> rip
2020-04-22 15:33:19 <Cogitri> Anyway, I'm happy with using Hyperkitty (or really anything) as long as the participation is higher than it currently is
2020-04-22 15:34:14 <Ariadne> well for development, the idea is to move all proposed changes to a gitlab repository where they can be discussed in some way
2020-04-22 15:34:24 <Ariadne> be that as actual spec documents in an MR, or as issues
2020-04-22 15:34:30 <Ariadne> there's pros and cons to both approaches
2020-04-22 15:34:42 <Ariadne> so hyperkitty is about support
2020-04-22 15:34:49 <Ariadne> and general discussion
2020-04-22 15:34:52 <Ariadne> like fedora :)
2020-04-22 15:34:57 <Cogitri> Ah nice
2020-04-22 15:36:18 <mps> also I see mailman3+hyperkitty for general discussion and user help channel, and not for patches
2020-04-22 15:37:25 <Cogitri> Yes, I think we've already agreed that patches on the ML don't have a future
2020-04-22 15:38:06 <Ariadne> yeah we agreed to that a while back
2020-04-22 15:38:15 <Ariadne> if you read my latest post it describes where we are at
2020-04-22 15:38:29 <Ariadne> basically: please confirm hyperkitty is the solution you want over discourse
2020-04-22 15:39:04 <Ariadne> also note that this entire process has been done in the open, with everyone's feedback carefully considered, including drew's
2020-04-22 15:39:17 <Cogitri> Drew wrote a reply to the current thread?
2020-04-22 15:39:33 <Ariadne> no, he expressed it here in IRC in the form of a CoC violation
2020-04-22 15:39:39 <Cogitri> Oh
2020-04-22 15:39:42 <Cogitri> I guess I missed that then
2020-04-22 15:40:05 <Ariadne> whatever :)
2020-04-22 15:40:21 <Ariadne> the beginning of this process was attempting to work with him to adapt the sourcehut software to meet our needs
2020-04-22 15:40:26 <Cogitri> Thanks for leading the discussion in this :)
2020-04-22 15:40:43 <Ariadne> but one of those needs is "people can reply to alpine lists from their phone, even if their phone is by our standards completely broken"
2020-04-22 15:40:57 <Ariadne> since the majority of our mlmmj traffic was phone replies :)
2020-04-22 15:42:03 <ncopa> i suppose i dont have any strong opinion re discourse vs hyperkitty
2020-04-22 15:42:12 <ncopa> which one is easiest to set up?
2020-04-22 15:42:26 <Ariadne> probably hyperkitty
2020-04-22 15:42:40 <Ariadne> hyperkitty is more e-mail friendly than discourse
2020-04-22 15:42:43 <Ariadne> basically
2020-04-22 15:42:52 <Ariadne> mailman3 + hyperkitty: e-mail first
2020-04-22 15:42:56 <Ariadne> discourse: web first
2020-04-22 15:43:10 <Ariadne> sourcehut: plaintext email only
2020-04-22 15:43:16 <ncopa> how do they deal with spam?
2020-04-22 15:43:20 <Ariadne> (with optional html support)
2020-04-22 15:43:32 <Ariadne> dealing with spam is left to the MTA in all cases
2020-04-22 15:43:36 <ncopa> sourcehut's way to deal with spam is to block html
2020-04-22 15:43:53 <ikke> there is plenty of plain-text spam
2020-04-22 15:44:25 <Ariadne> anyway presumably our strategy either way would be to use spamassassin and such
2020-04-22 15:44:32 <Ariadne> as we did in mlmmj days
2020-04-22 15:44:52 <mps> ime, discourse is easier to setup than mailman3+hyperkitty but that shouldn't be reason for choosing which to use
2020-04-22 15:45:33 <ncopa> other thing, we will need to import emails from sourcehut
2020-04-22 15:45:39 <Ariadne> yeah
2020-04-22 15:45:43 <Ariadne> we are gonna make a dumper
2020-04-22 15:45:47 <Ariadne> no biggie :)
2020-04-22 15:45:55 <ncopa> can we import emails to discourse?
2020-04-22 15:45:59 <Ariadne> yes
2020-04-22 15:46:08 <Ariadne> also to mailman3/hyperkitty
2020-04-22 15:46:15 <Ariadne> but i think we should go with hyperkitty
2020-04-22 15:46:25 <Ariadne> it will make the die-hard email fans happier
2020-04-22 15:46:42 <Ariadne> and still solve our goal of allowing people to interact with the list as a forum
2020-04-22 15:46:43 <ncopa> second, I'd like to have old links working, with redirects to new location
2020-04-22 15:47:04 <Ariadne> that one we are going to have to think about
2020-04-22 15:47:09 <Ariadne> but should be possible
2020-04-22 15:47:19 <ncopa> im thinking a big static list or similar
2020-04-22 15:47:28 <Ariadne> yep
2020-04-22 15:47:29 <ikke> similar to what we did for redmine
2020-04-22 15:47:52 <ncopa> i think redmine was easier since we could re-use the old uinque id
2020-04-22 15:47:59 <ikke> yes
2020-04-22 15:48:02 <ncopa> but yes
2020-04-22 15:48:14 <ikke> there were some expceptions though
2020-04-22 15:48:37 <ikke> everything not in the main project basically
2020-04-22 15:49:29 <ncopa> ok
2020-04-22 15:50:40 <ikke> So we would need to have some mapping from an old id to a new id
2020-04-22 15:50:46 <Ariadne> i think the other more important thing to figure out is
2020-04-22 15:50:55 <Ariadne> how the gitlab-based RFC workflow is going to be
2020-04-22 15:51:14 <ikke> I think we should start simple
2020-04-22 15:51:17 <Ariadne> because we can retain sourcehut for now and work on that angle
2020-04-22 15:51:31 <ikke> We could create a project in gitlab without a repo, just issues
2020-04-22 15:53:26 <ncopa> mps: are there any kernel configs that you think we should backport to 3.11-stable?
2020-04-22 15:54:04 <ncopa> we will hopefully have alpine 3.12 out in May
2020-04-22 15:54:21 <ikke> Any blocked
2020-04-22 15:54:24 <ikke> blockers?
2020-04-22 15:54:38 <ncopa> i think ruby was the last major thing
2020-04-22 15:55:20 <ncopa> i was hoping to have the crystal/llvm issue fixed on aarch64 so we could get rid of llvm5, but it is stuck
2020-04-22 15:55:26 <Cogitri> I guess we should test !7082
2020-04-22 15:55:34 <Cogitri> Or should that wait until after 3.12?
2020-04-22 15:55:49 <ncopa> not sure how to move that forward. it is apparently a bug in llvm on aarch64, but i dont know to report it or how to create a test case
2020-04-22 15:55:50 <ikke> Cogitri: ncopa just pushed something
2020-04-22 15:56:06 <ikke> http://dup.pw/aports/5d4ec598
2020-04-22 15:56:28 <Cogitri> Oh
2020-04-22 15:56:30 <mps> ncopa: I'm not sure, maybe FS_VERITY and NET_REDIRECT, ofc if you plan to use current LTS, 5.4.30+
2020-04-22 15:56:45 <Cogitri> Also, maybe we want !7091
2020-04-22 15:56:52 <Cogitri> But I'm not sure how smooth of an upgrade that's going to be
2020-04-22 15:58:07 <ncopa> not sure how important the FS_VERITY and NET_REDIRECT are
2020-04-22 15:58:21 <ncopa> or if we need those for 3.11-stable
2020-04-22 15:58:25 <Ariadne> both would be nice to have for 3.12
2020-04-22 15:58:52 <mps> and if you backport FS_VERITY than we should move fsverity-utils to community (which I planned to do today, but worked on something else) and backport it to 3.11
2020-04-22 15:58:53 <ncopa> i merged the FS_VERITY and NET_REDIRECT to edge
2020-04-22 15:59:04 <ncopa> has anyone asked for it?
2020-04-22 15:59:13 <ncopa> i think we better spend our time on getting 3.12 out
2020-04-22 15:59:49 <mps> NET_REDIRECT is important (imo) because change in skbuff in latest or previous kernel
2020-04-22 16:00:17 <ncopa> ok. good to know
2020-04-22 16:01:12 <mps> FS_VERITY is not important to backport  because no one asked for it (afaik) but I plan to use it in near future but not on 3.11
2020-04-22 16:02:10 <mps> but simply take current linux-lts in edge and build it for 3.11-stable is easy path, imo
2020-04-22 16:03:01 <Ariadne> NET_REDIRECT will enable itself by default anyway
2020-04-22 16:03:12 <Ariadne> when i rebased linux-octeon, it did anyway
2020-04-22 16:03:26 <Ariadne> i wish linux-octeon supported octeon3 NIC, but it does not :(
2020-04-22 16:03:44 <Ariadne> we are looking at forward-porting it from their BSP kernel tho
2020-04-22 16:03:45 <mps> I'll left it to you to decide what to do, I'm running 5.6 on my important boxes at the end, and if someone ask for these features we can backport them later
2020-04-22 16:04:06 <mps> Ariadne: correct, it is actually mandatory now
2020-04-22 16:05:03 <mps> BTW, in last two months I noticed more commits about loongson in mainline kernel
2020-04-22 16:05:29 <Ariadne> yeah i am pretty excited that they are interested in sending hardware to us
2020-04-22 16:05:47 <Ariadne> i just need to figure out who they should send it to, since i don't know if we want to have a bunch of builders in our europe lab
2020-04-22 16:06:34 <Ariadne> and i think sending to US is out of the question, i am sure that will be a shitshow
2020-04-22 16:07:15 <mps> does it have some kind of BMC for remote control, do you know?
2020-04-22 16:08:32 <ikke> protobuf cannot find -lucontext
2020-04-22 16:08:40 <ikke> Is that a missing dep?
2020-04-22 16:08:45 <ncopa> ugh
2020-04-22 16:08:58 <Ariadne> libucontext-dev :)
2020-04-22 16:09:09 <ncopa> i think it ends up in some ruby-config or pkg-config file when it shouldnt
2020-04-22 16:09:23 <Ariadne> just link everything to libucontext
2020-04-22 16:09:24 <Ariadne> :D
2020-04-22 16:09:32 <Ariadne> including libc
2020-04-22 16:09:44 <Ariadne> like we used to with libubacktrace in uclibc days
2020-04-22 16:09:46 <ncopa> protobuf does not use libucontext, it is ruby
2020-04-22 16:10:08 <Ariadne> that reminds me,
2020-04-22 16:10:11 <ikke> Why is protobuf failing then?
2020-04-22 16:10:14 <ncopa> i think ruby linked to libucontext static
2020-04-22 16:10:29 <ncopa> <ncopa> i think it ends up in some ruby-config or pkg-config file when it shouldnt
2020-04-22 16:10:35 <Ariadne> libucontext 0.11 will be out soon with m68k, riscv64 support
2020-04-22 16:10:52 <ncopa> i need to go out and run for a while
2020-04-22 16:10:55 <ikke> o/
2020-04-22 16:11:01 <Ariadne> because of the ongoing plague, i dusted off my amiga recently
2020-04-22 16:11:03 <ncopa> bbl
2020-04-22 16:11:16 <Ariadne> i am going to make alpine run on it :D
2020-04-22 16:11:23 <ikke> hmm, interesting. go tests fail on aarch64, unless I run the container as privileged
2020-04-22 16:11:32 <ikke> (single test, getrlimit)
2020-04-22 16:11:40 <Ariadne> i thought tests are disabled
2020-04-22 16:11:41 <ikke> CAP_SYS_ADMIN is not enough
2020-04-22 16:11:47 <Ariadne> did somebody bump to 1.14 again
2020-04-22 16:11:48 <ikke> no\
2020-04-22 16:12:24 <Ariadne> so far feedback from go developers is "it appears the poller goroutine just dies and we have no idea why"
2020-04-22 16:13:26 <ikke> Ariadne: funny, on 3.11, the checks are not disabled
2020-04-22 16:13:32 <ikke> 1.13.7
2020-04-22 16:13:40 <Ariadne> weird
2020-04-22 16:13:53 <Ariadne> 
ACTION mutters things about go

2020-04-22 16:14:10 <ikke> tests succeed on everything but aarch64 and armv7
2020-04-22 16:20:56 <Ariadne> no idea
2020-04-22 17:20:27 <ncopa> ikke: can we disable that specific test?
2020-04-22 17:20:52 <ncopa> also, what is the problem with go 1.14? would be nice to have go 1.14 in alpine 3.12
2020-04-22 17:58:52 <Ariadne> ncopa: https://github.com/golang/go/issues/38454#issuecomment-617929519
2020-04-22 18:03:48 <ncopa> ok, its mips that is holding us back :-/
2020-04-22 18:04:33 <ncopa> we still have a week i guess, to fix it
2020-04-22 18:04:41 <krichy> hi. since yesterday, i was debugging why compiling log4cplus fails on armhf.
2020-04-22 18:05:46 <krichy> still dont know the answer, but in short, log4cplus creates a shared library, and exceptions thrown from the library are not catched in the executable.
2020-04-22 18:06:37 <krichy> whether it is some linker configuration issue, i dont know. there are a few posts regarding similar issues
2020-04-22 18:06:52 <krichy> https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/11581/gcc-7-2-1-on-cortex-m4---c-exceptions-not-being-caught/159829#159829
2020-04-22 18:07:24 <krichy> https://community.nxp.com/thread/524440#comment-1267889
2020-04-22 18:09:15 <krichy> so i think, really not log4cplus is broken on armhf.
2020-04-22 18:12:36 <TBK[m]> krichy: would be best to open an issue on gl.a.o aports
2020-04-22 18:13:21 <TBK[m]> krichy: https://gitlab.alpinelinux.org/alpine/aports/issues/new?issue
2020-04-22 18:15:31 <Ariadne> ncopa: i am working as fast as i can to get it fixed yes
2020-04-22 18:29:10 <ikke> ncopa: the tests only fail in Docker afaik
2020-04-22 18:33:33 <Ariadne> working on adding the ability to apk fetch based on package origin
2020-04-22 18:33:44 <Ariadne> so if you fetch foo, you also get foo-dev
2020-04-22 18:33:49 <Ariadne> (optionally)
2020-04-22 19:06:26 <Ariadne> hmm, i wonder if libucontext on s390x is flaky
2020-04-22 19:06:32 <Ariadne> i'll look into it
2020-04-22 19:07:10 <Ariadne> it passes tests. but you never know
2020-04-22 19:10:34 <PureTryOut[m]> Ariadne: can you try sending mail with kmail? It just fails for me, stays in the outbox
2020-04-22 19:10:47 <Ariadne> PureTryOut[m]: apk add cyrus-sasl-plain
2020-04-22 19:11:14 <Ariadne> (it may be worthwhile to add that as a runtime dependency on kmail)
2020-04-22 19:11:32 <ncopa> i thikn we should ask upstream ruby to add support for native s390x so we dont need to use libucontext
2020-04-22 19:12:10 <ncopa> someone else did that for arm32
2020-04-22 19:12:24 <Ariadne> libucontext is faster than --with-coroutine=copy
2020-04-22 19:12:45 <PureTryOut[m]> 😱
2020-04-22 19:12:49 <PureTryOut[m]> Yup that should be runtime dep alright
2020-04-22 19:13:09 <PureTryOut[m]> Although maybe of akonadi
2020-04-22 19:13:24 <PureTryOut[m]> As I had to restart it before it worked
2020-04-22 19:13:24 <Ariadne> and if libucontext is flaky on s390x i think fixing it is important
2020-04-22 19:13:29 <ncopa> +1
2020-04-22 19:13:58 <Ariadne> if i had a pickup truck, i would go buy an s390x machine right now
2020-04-22 19:14:07 <Ariadne> there is one being auctioned off here for like $300
2020-04-22 19:16:23 <dalias> how big is it?
2020-04-22 19:16:49 <Ariadne> a cabinet
2020-04-22 19:16:53 <Ariadne> like
2020-04-22 19:16:56 <Ariadne> 42U cabinet?
2020-04-22 19:17:11 <Ariadne> you would need freight carrier to get it
2020-04-22 19:18:43 <dalias> that's like borderline fits-in-a-decent-size-hatchback-with-seats-folded-down dimensions, no?
2020-04-22 19:19:21 <ncopa> i'd love to see a picture of that! :D
2020-04-22 19:19:54 <Ariadne> uhh
2020-04-22 19:19:57 <Ariadne> https://i.ebayimg.com/images/g/vigAAOSwWapecVlK/s-l1600.jpg
2020-04-22 19:20:04 <Ariadne> this is what an s390x machine looks like
2020-04-22 19:20:13 <Ariadne> you're not fitting that into a hatchback
2020-04-22 19:20:22 <dalias> i know i carried a ~42"x6' fence panel like that a couple weeks ago
2020-04-22 19:20:35 <ncopa> i mean, a picture of that loaded in a hatchback :D
2020-04-22 19:20:37 <Ariadne> 42U is 42 rack units
2020-04-22 19:20:44 <Ariadne> like 8 feet tall
2020-04-22 19:20:45 <dalias> yeah
2020-04-22 19:20:57 <dalias> yeah at that height it'd have to hang out the back :-P
2020-04-22 19:21:00 <Ariadne> these things weigh like
2020-04-22 19:21:03 <Ariadne> 2000 pounds
2020-04-22 19:21:20 <dalias> the weight will probably kill any hope of carrying it like that tho
2020-04-22 19:21:29 <dalias> smallest uhaul trailer could probably do it tho
2020-04-22 19:22:03 <dalias> or uhaul or lowes pickup rental (something like $60 with insurance & tax)
2020-04-22 19:23:13 <Ariadne> 1802 lbs
2020-04-22 19:23:39 <Ariadne> there is no lowes pickup rental where i live
2020-04-22 19:23:55 <Ariadne> i live quite literally in the middle of nowhere on the side of a mountain
2020-04-22 19:23:56 <Ariadne> :D
2020-04-22 19:26:00 <dalias> really? is there no lowes nearby at all? afaik most/all stores have it and it's really convenient (because usually you're renting it right at the place you need to do the pickup :)
2020-04-22 19:26:16 <Ariadne> the nearest lowes is in Colorado
2020-04-22 19:26:29 <dalias> near wherever the item for sale is would also do, no?
2020-04-22 19:26:33 <Ariadne> crossing state lines during a pandemic?  nah i'm good ;)
2020-04-22 19:26:39 <dalias> *nod*
2020-04-22 19:26:44 <dalias> that'd be my main reason not to
2020-04-22 19:27:20 <Ariadne> given the absurd financing deals they are offering on vehicles right now i might just buy one
2020-04-22 19:27:24 <dalias> i'm pretty much not going out for anything that can be arranged for delivery without requiring person-to-person contact
2020-04-22 19:27:25 <Ariadne> you can buy one entirely online now
2020-04-22 19:27:36 <dalias> hah
2020-04-22 19:27:41 <Ariadne> strange how it takes a pandemic to do something that should have been done decades ago
2020-04-22 19:27:55 <Ariadne> it's not like anyone is thrilled with having to go to a car lot
2020-04-22 19:28:22 <dalias> nobody wants to, but how else could they upsell stuff you don't want and other deceptive practices?
2020-04-22 19:28:57 <dalias> i've actually never bought from a lot, but the only way i do buy vehicles is kinda out of the question for a while (craigslist :-p)
2020-04-22 19:29:13 <Ariadne> i bought my volvo from copart.com
2020-04-22 19:29:25 <Ariadne> it was a repo
2020-04-22 19:29:29 <Ariadne> got it for next to nothing
2020-04-22 19:29:48 <Hello71> actually it's because US government corruption forces manufacturers to sell through dealerships
2020-04-22 19:29:49 <dalias> you can get awesome deals on oversized vehicles on craigslist. i've seen fucking dump trucks for a couple thousand, fullsize vans for under 1k, etc.
2020-04-22 19:29:51 <Ariadne> had to drive all the way to austin to pick it up tho
2020-04-22 19:30:54 <dalias> sadly that's never been what i wanted :-p
2020-04-22 19:31:59 <ncopa> ruby is definitively broken on s390x. https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/h2o/h2o-2.2.6-r3.log
2020-04-22 19:32:21 <Ariadne> ncopa: yeah, but the question is if libucontext is to blame
2020-04-22 19:33:09 <Ariadne> hmm
2020-04-22 19:33:28 <Ariadne> well libucontext wouldn't cause jump-to-null i don't think
2020-04-22 19:36:06 <mps> ncopa: just moved fsverity-utils to community, and I see that you backported kernel config for it to 3.11-stable
2020-04-22 19:36:35 <mps> should I maybe backport fsverity-utils to 3.11-stable?
2020-04-22 19:42:04 <ncopa> Ariadne: we should report it upstream i guess
2020-04-22 19:42:23 <Ariadne> what would be useful
2020-04-22 19:42:25 <ncopa> mps: if you want. not sure its worth it
2020-04-22 19:42:37 <Ariadne> is to try to capture a coredump
2020-04-22 19:43:02 <Ariadne> i'm not sure
2020-04-22 19:43:33 <ncopa> I'm enabling a -dbg package
2020-04-22 19:43:47 <dalias> last time i looked i saw a lot of things that looked fragile in libucontext, so even if it doesn't seem like it should be possible for it to jump to address 0, i wouldn't be surprised if it can happen
2020-04-22 19:44:04 <Ariadne> dalias: 0.10 is a bit more robust
2020-04-22 19:44:12 <Ariadne> but i mean, fundamentally
2020-04-22 19:45:18 <ncopa> would still be nice with a core dump and a proper backtrace
2020-04-22 19:46:01 <ncopa> i wouldnt be suprised if there is something else they broke on big endian
2020-04-22 19:46:27 <Ariadne> mips64 has no problems though and uses libucontext
2020-04-22 19:46:32 <Ariadne> so don't think it is BE
2020-04-22 19:46:34 <Ariadne> https://github.com/kaniini/libucontext/blob/master/arch/s390x/swapcontext.S#L24
2020-04-22 19:46:38 <Ariadne> think it is this XXX
2020-04-22 19:46:48 <ncopa> it also reminds me that i should try upstream the main thread stack size fix from nsz
2020-04-22 19:47:47 <mps> ok, if no one ask for backport I will not do that, I have it already for my tests and maybe use
2020-04-22 19:48:22 <mps> use in production* (uhm, keyboard)
2020-04-22 19:50:33 <dalias> main thread stack size fix?
2020-04-22 19:51:12 <ncopa> old issue that we have a patch for
2020-04-22 19:51:14 <ncopa> for long time
2020-04-22 19:51:44 <ncopa> they commit/reserve stack memory
2020-04-22 19:52:15 <ncopa> but the use a pthread*_np func to calculate the available stack size for main thread
2020-04-22 19:52:31 <ncopa> which works differently in musl
2020-04-22 19:53:12 <dalias> oh, glibc returns the size it can grow up to (ulimit) where as musl returns the size it actually has committed
2020-04-22 19:53:20 <ncopa> exactly
2020-04-22 19:53:52 <dalias> what do they want to do with it?
2020-04-22 19:54:14 <dalias> (just trying to get an idea what kinds of problems stuff hits. i vaguely remember something like this but i forgot the specifics)
2020-04-22 19:54:33 <ncopa> iirc they want "reserve" /commit the stack memory by touching it
2020-04-22 19:54:53 <ncopa> the issue: https://bugs.ruby-lang.org/issues/14387
2020-04-22 19:55:25 <ncopa> i have an updated patch for it, which does exactly same thing as the issue, but is more clear to spot that it does nothing at all in the glibc case
2020-04-22 19:58:53 <ncopa> dalias: while i have you here, there is another issue that have been bothering me for a while. libexecinfo and backtrace is broken with musl. cannot get any backtraces. i think it was discussed on the musl mailing list, and i think the conclusion was that it is generally a bad idea to try print a backtrace from the application when the application
2020-04-22 19:58:53 <ncopa> crashes
2020-04-22 19:59:04 <ncopa> its safer to just let the app crash and generate a core dump
2020-04-22 19:59:32 <ncopa> but there are a few apps that require backtrace()
2020-04-22 19:59:40 <ncopa> varnish is one
2020-04-22 20:00:11 <ncopa> and i think the "fix" for the broken libexecinfo in alpine was to add option to use libunwind instead
2020-04-22 20:00:26 <ncopa> but i think libunwind is also broken :)
2020-04-22 20:01:58 <Cogitri> Maybe https://gitlab.alpinelinux.org/alpine/aports/issues/11406 helps with libexecinfo ?
2020-04-22 20:02:15 <ncopa> so i'd like to either fix libexecinfo so it does a best-effort to print a backtrace, or just let it print a message and crash
2020-04-22 20:03:20 <ncopa> Cogitri: i had a look at it some time ago, and i think its more complicated than that
2020-04-22 20:03:31 <Cogitri> Thought so
2020-04-22 20:05:39 <dalias> ncopa, it's a very bad idea. I suspect they're just failing to backtrace out of signal handlers across libc functions, and this is intentional, because it's a broken thing to be doing :)
2020-04-22 20:06:00 <dalias> otherwise, if they just try to backtrace across their own functions, it should work fine.
2020-04-22 20:06:33 <dalias> libbacktrace should stop at the first frame where it has no unwind info
2020-04-22 20:06:38 <ncopa> right, so the testcase i did shows that it does nto work to bracktrace out of own functions
2020-04-22 20:06:57 <ncopa> libexecinfo
2020-04-22 20:07:05 <dalias> looking at that issue report, i think the unwind lib has a bug
2020-04-22 20:07:10 <dalias> it shouldn't be returning (void*)-1
2020-04-22 20:07:17 <dalias> which archs does it do this on?
2020-04-22 20:07:30 <ncopa> i think all
2020-04-22 20:07:44 <dalias> (it's probably blindly returning the frame pointer when there's no unwind info, and the frame pointer is just a normal gpr because -fomit-frame-pointer)
2020-04-22 20:08:47 <dalias> it should either be validating the frame pointer if it wants to chase frame pointers (i.e. ensuring that it points into some mapped text segment) or treating lack of dwarf info as can't-unwind-further
2020-04-22 20:09:04 <dalias> imo the latter is a better choice
2020-04-22 20:09:20 <dalias> using frame pointers for this is a hack
2020-04-22 20:09:36 <ncopa> i think this is what we use https://github.com/mikroskeem/libexecinfo
2020-04-22 20:10:23 <ncopa> oh, its way too late for me. need to get to bed
2020-04-22 20:20:28 <dalias> https://github.com/mikroskeem/libexecinfo/blob/48872e1bb4ec2ba5663003999aec117dfeac4ff5/stacktraverse.c#L148 <-- yeah that's not really going to work
2020-04-22 20:20:51 <dalias> __builtin_frame_address(n) for n > number of frames that are valid is bogus
2020-04-22 20:21:06 <dalias> it really should be calling the unwind lib stuff correctly, i think
2020-04-22 20:21:10 <Ariadne> maybe i should write a libbacktrace
2020-04-22 20:21:27 <dalias> or it should be validating
2020-04-22 20:25:28 <Hello71> Ariadne: probably would be easier to wrap libunwind
2020-04-22 20:25:51 <Ariadne> Hello71: yes, obviously
2020-04-22 20:32:20 <mps> uhm, include/liburing.h:197:18: error: unknown type name 'loff_t'; did you mean 'off_t'?
2020-04-22 20:33:17 <mps> but I'm tired, will look tomorrow, zzzz.......
2020-04-22 20:33:26 <ikke> nite
2020-04-22 20:33:44 <mps> good night all :)
2020-04-22 20:35:09 <dalias> mps, if liburing.h is using loff_t it should be including a header that defines it
2020-04-22 20:36:50 <mps> dalias: I presume something like that, but will look tomorrow. thanks for hint
2020-04-22 20:37:56 <mps> maybe we need newer linux-headers, will look. zzz...  nite again, this time for sure :)
2020-04-22 20:42:49 <dalias> no, it's a glibcism
2020-04-22 20:42:57 <dalias> glibc defines the nnonstandard type loff_t all over the place
2020-04-22 20:43:12 <dalias> musl only in the headers that declare interfaces that use it (iirc just fcntl.h)
2020-04-22 21:04:40 <Ariadne> 
ACTION builds apk-tools git and observes that the help system is broken

2020-04-22 21:04:53 <Ariadne> manpages are cool and all, but god damn
2020-04-22 21:12:42 <Cogitri> make SCDOC=""
2020-04-22 21:12:54 <Cogitri> Male isn't fun
2020-04-22 21:12:57 <Cogitri> Make*
2020-04-22 21:13:38 <Cogitri> Might as well use the meson port :^)
2020-04-22 21:15:12 <Ariadne> that's one hell of an update
2020-04-22 21:15:36 <Ariadne> https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/23
2020-04-22 21:16:07 <Ariadne> i do not even know why the hell this was merged
2020-04-22 21:16:20 <Ariadne> the man pages part sure
2020-04-22 21:16:25 <Ariadne> this commit tho?
2020-04-22 21:18:11 <Ariadne> it completely breaks the usability of the program
2020-04-22 21:18:18 <Ariadne> who needs to know what commands there are
2020-04-22 21:18:21 <Ariadne> just read the manpage
2020-04-22 21:18:31 <Cogitri> Huh
2020-04-22 21:18:35 <Ariadne> how do you install the manpages ?
2020-04-22 21:18:37 <Ariadne> dunno
2020-04-22 21:18:48 <Cogitri> Maybe one thing could be generated from the other though
2020-04-22 21:18:56 <Ariadne> yes
2020-04-22 21:18:59 <Ariadne> sure
2020-04-22 21:19:09 <Ariadne> however, this particular commit should not have been accepted
2020-04-22 21:19:19 <Cogitri> Yup, +1 on that
2020-04-22 21:19:38 <Ariadne> just like with sourcehut mail, that one would certainly lead to immediate buyers remorse
2020-04-22 21:19:46 <Ariadne> let us stop buying things from this person
2020-04-22 21:20:12 <Ariadne> lord knows how we get burned next
2020-04-22 21:21:02 <Ariadne> i am beyond words
2020-04-22 21:21:31 <Ariadne> like this one legitimately pisses me off
2020-04-22 21:28:57 <Ariadne> i don't even have objection to having most of the documentation in man pages.  that's not a problem.
2020-04-22 21:29:14 <Ariadne> but saying this is like git is like pissing on my leg and telling me it is raining
2020-04-22 21:29:32 <Ariadne> when you use `git` without any arguments, it prints a list of commonly used commands.
2020-04-22 21:30:59 <ikke> Yeah, it's nice that you can quickly get a reference just from apk itself
2020-04-22 21:32:39 <ikke> especially because alpine's default is to not include man pages
2020-04-22 21:33:05 <Ariadne> this prints nothing
2020-04-22 21:33:12 <Ariadne> it does not even mention that manpages exist
2020-04-22 21:33:46 <Ariadne> the whole reason why apk has been a successful package manager has very little to do with its speed and everything to do with the fact that some significant effort went into usability in the design of the tool
2020-04-22 21:34:21 <Ariadne> the speed is nice, but meaningless if you can't get running quickly with the package manager
2020-04-22 21:34:27 <ikke> Well, speed has to do with it as well
2020-04-22 21:34:39 <Ariadne> yes, but it's not just speed
2020-04-22 21:34:42 <ikke> The other way around as well though
2020-04-22 21:34:43 <Ariadne> usability is a huge part of it too
2020-04-22 21:34:58 <ikke> Can be usable, but it it takes ages, then it would not work
2020-04-22 21:35:01 <Ariadne> and this removes usability
2020-04-22 21:35:12 <Ariadne> like, this takes usability all the way to zero
2020-04-22 21:37:36 <Ariadne> like, the whole point of apk is that it is a package manager that does not suck
2020-04-22 21:37:39 <Ariadne> this sucks
2020-04-22 21:37:47 <Ariadne> like, this really sucks
2020-04-22 21:38:38 <ikke> yes, we get it
2020-04-22 21:42:00 <Ariadne> sorry i am just shocked that somehow all the work we have done on usability would go flying out the window
2020-04-22 21:42:30 <Ariadne> had i known that the man pages MR would rip out the built in help system in its entirety, i would have objected then
2020-04-22 21:43:35 <ikke> I guess it's a developer trait that we have to get rid of redundant information that gets out of sync
2020-04-22 21:45:18 <Ariadne> i mean, i think it is good to have a single source of truth too
2020-04-22 21:45:46 <Ariadne> but, i think we must be realistic.  don't remove key usability components until you have found a way to achieve that single source of truth.
2020-04-22 21:46:11 <Ariadne> if somebody encountered this apk, unless they've used apk before, they wouldn't know how to use it.
2020-04-22 21:48:17 <ikke> most commands show basic explanation of each option
2020-04-22 21:48:36 <ikke> even though it's more extensively documented in the man page
2020-04-22 21:54:18 <Ariadne> ikke: yes, but
2020-04-22 21:54:20 <Ariadne> http://tpaste.us/Qnxw
2020-04-22 21:54:24 <Ariadne> what commands ?
2020-04-22 21:54:29 <Ariadne> what man page?
2020-04-22 21:54:36 <Ariadne> there is no man page or commands discussed here
2020-04-22 21:54:53 <Ariadne> just a list of common flags and the suggestion that a command must be provided
2020-04-22 21:54:58 <ikke> Ariadne: I'm not arguing against you, I'm agreeing with you
2020-04-22 21:55:04 <Ariadne> i know
2020-04-22 21:55:08 <Ariadne> i am just
2020-04-22 21:55:11 <Ariadne> this is frustrating
2020-04-22 21:55:24 <Ariadne> i am going to properly fix it, i guess
2020-04-22 21:55:40 <Ariadne> but i am dumbfounded as to why that commit made it in
2020-04-22 21:55:55 <Ariadne> we could have just accepted the manpages and left the help system for further discussion, not rip it out
2020-04-22 21:57:47 <ikke> Doesn't even mention what subcommands there are
2020-04-22 21:57:51 <Xe> tbh, if the two things being out of sync is a problem, you should look into having manpages be generated from the source code
2020-04-22 21:58:14 <Xe> i did this for a tool at work, it's one of the best decisions i've ever made
2020-04-22 22:00:23 <Xe> something like https://clbin.com/x4Vw9 with a table for subcommands on each applet, extending the applets with usage examples might help too
2020-04-22 22:00:37 <Xe> so `apk-search(n)` would be referenced from `apk(n)`
2020-04-22 22:00:43 <Xe> (i forget which man section apk uses)
2020-04-22 22:01:50 <ikke> maxice8: apparently merge trains are now also in core?
2020-04-22 22:01:59 <maxice8> I have no clue
2020-04-22 22:02:12 <maxice8> i have implemented my own merge train in mgmr
2020-04-22 22:02:37 <ikke> oh, n/m
2020-04-22 22:03:22 <Ariadne> anyway, my guess is that the commit was accepted under the assumption that it would be solved in short order
2020-04-22 22:03:27 <Ariadne> which didn't happen
2020-04-22 22:03:43 <Ariadne> and i have theories as to why, but i don't wish to violate the CoC
2020-04-22 22:04:33 <ikke> Probably not constructive
2020-04-22 22:05:22 <Ariadne> indeed not
2020-04-22 22:05:31 <Ariadne> and at this point, meaningless
2020-04-22 22:05:43 <Ariadne> as if my theories are right, it won't happen again anyway
2020-04-22 22:46:23 <Ariadne> here's one for you.  ncopa did not want this manpage thing merged because it decimated the help system
2020-04-22 22:46:31 <Ariadne> everyone likes to talk about what ncopa would do
2020-04-22 22:46:38 <Ariadne> well, ncopa would not havemerged this
2020-04-22 22:47:46 <Ariadne> alpine tools have high quality help systems, this is *the* design point that has always been made
2020-04-22 22:54:49 <Ariadne> my conclusion is that we must revert that particular commit, and then integrate manpages into the help text from there, and then and only then, remove more obscure options to the manpages
2020-04-22 22:55:08 <Ariadne> that would be the alpine way of doing manpages
2020-04-23 06:08:22 <ncopa> morning
2020-04-23 06:09:33 <ncopa> tmhoang: can you help with figuring out what is wrong with ruby on s390x? we suspect it is related to libucontext but we are not sure.
2020-04-23 06:12:01 <Cogitri> Morning
2020-04-23 06:21:31 <ncopa> im tagging 3.11.6 release now
2020-04-23 06:22:45 <Cogitri> 👍
2020-04-23 06:39:03 <mps> mesa 20.0.5 release notes https://lists.freedesktop.org/archives/mesa-dev/2020-April/224395.html
2020-04-23 06:39:16 <mps> fixes mostly
2020-04-23 06:43:24 <Cogitri> Neat
2020-04-23 07:21:45 <ncopa> release notes for 3.11.6. does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.6-released.html
2020-04-23 07:23:01 <ikke> Yes, looks good
2020-04-23 07:23:29 <TBK[m]> Keith Maxwell (1):
2020-04-23 07:23:29 <TBK[m]>       [3.11] main/ansibl...
2020-04-23 07:23:53 <ikke> TBK[m]: already committed, nothing to do about
2020-04-23 08:10:14 <ncopa> Ariadne: im not sure that ruby issue on s390x is due to libucontex. the ruby testsuite passes with libucontext, but fails with --with-coroutine=copy. https://bugs.ruby-lang.org/issues/16809
2020-04-23 08:23:21 <ncopa> hum
2020-04-23 08:23:44 <ncopa> mruby build fails. and the ruby script that causes ruby to segfault definitively use fibers
2020-04-23 09:26:49 <ncopa> Ariadne: I'd like to tag a new edge snapshot release, and would like to ship mips64 minirootfs and maybe netboot
2020-04-23 09:27:21 <ncopa> as i understand, it will automatically be built and uploaded, from aports-build
2020-04-23 09:28:03 <ncopa> Ariadne: could you please test if scripts/mkimage.sh works?
2020-04-23 09:28:08 <ncopa> $ tpaste <  mkrelease.sh
2020-04-23 09:28:08 <ncopa> http://tpaste.us/onYL
2020-04-23 09:28:10 <mps> should we rename mdocml to mandoc
2020-04-23 09:28:25 <ncopa> mps: if upstream renamed it, then i think yes
2020-04-23 09:28:31 <mps> before 3.12, I mean
2020-04-23 09:28:39 <ncopa> i think yes
2020-04-23 09:28:43 <mps> yes, upstream renamed it for some time
2020-04-23 09:29:28 <ncopa> then i think we should do it before 3.12
2020-04-23 09:29:46 <mps> would someone with better understanding replaces/provides than me do that rename, please
2020-04-23 09:30:43 <mps> I want to upgrade some pkgs before freeze
2020-04-23 09:30:59 <ikke> replaces="mdocml"; provides="mdocml=$pkgver-r$pkgrel"
2020-04-23 09:31:34 <mps> ikke: so simple? thanks
2020-04-23 09:31:51 <ncopa> yes, that should do it
2020-04-23 09:32:10 <mps> and we don't need to change depends in packages?
2020-04-23 09:32:22 <ikke> eventually, but not immediately
2020-04-23 09:32:23 <ncopa> we shoudl also do the same with subpackages
2020-04-23 09:32:48 <ncopa> i think we should change depends in packages
2020-04-23 09:33:21 <mps> ikke: yes, we can (an should) change depends in pkgs, but not in rush
2020-04-23 09:33:45 <ncopa> its only 4 packages in main
2020-04-23 09:33:56 <mps> ah, not much
2020-04-23 09:34:02 <ncopa> and 5 in community
2020-04-23 09:34:10 <ncopa> those are important for 3.12 release
2020-04-23 09:34:31 <ncopa> an one for ejson
2020-04-23 09:35:13 <mps> then we don't need replaces/provides in maandoc ?
2020-04-23 09:35:31 <ncopa> we need replaces so updates works
2020-04-23 09:35:44 <mps> aha, understand
2020-04-23 09:35:45 <ncopa> otherwise you will get error when upgrade: conflicts with mdocml
2020-04-23 09:36:46 <ncopa> provides is so when people does `apk add mdocml` it will install mandoc. so it is to avoid break unknown scripts that users may have
2020-04-23 09:37:26 <ncopa> we should at least replace depend in main repo, since aports-build will not be able to calculate build order that depends on provides
2020-04-23 09:38:03 <mps> ok
2020-04-23 09:38:27 <mps> thanks for explanation
2020-04-23 09:38:36 <ncopa> so its not urgent, but it may break 3.12 build order
2020-04-23 09:38:53 <ikke> ncopa: is that something that should be added, or is that non-trivial?
2020-04-23 09:39:18 <ncopa> i'd say its non-
2020-04-23 09:39:21 <ncopa> trivial
2020-04-23 09:40:13 <mps> but we should not add upstream patches for now?
2020-04-23 09:40:25 <ncopa> upstream patches?
2020-04-23 09:40:31 <ncopa> depends what they are for
2020-04-23 09:40:48 <mps> mandoc have some patches after latest stable release
2020-04-23 09:41:06 <ncopa> we normally dont apply those patches unless something is broken
2020-04-23 09:41:48 <mps> actually I added some (one or two) already but seen some in ML, (not much important) which fixes some behaviours, but nothing critical
2020-04-23 09:42:38 <ncopa> i dont mind backporting patches if the fix things that are important to you
2020-04-23 09:43:30 <mps> no one filled bug reports, so I think it is not important to add them
2020-04-23 09:45:17 <ikke> drdb-vanilla fails on arm* apparently
2020-04-23 09:45:33 <clandmeter> vanilla is gone?
2020-04-23 09:45:35 <mps> and right now I see drbd failed on builders, do you plan to keep this on 3.12
2020-04-23 09:45:55 <ikke> clandmeter: on 3.9 / 3.10
2020-04-23 09:46:01 <mps> external (out-of-kernel) drbd
2020-04-23 09:46:02 <clandmeter> ah ok :)
2020-04-23 09:46:18 <clandmeter> sorry i just put focus on this screen.
2020-04-23 09:46:21 <clandmeter> ill hide again
2020-04-23 09:46:54 <mps> clandmeter: please don't, it is somewhat boring here without you
2020-04-23 09:47:32 <clandmeter> 💖
2020-04-23 09:48:10 <ncopa> oh no...
2020-04-23 09:48:39 <ncopa> they released 5.4.35 kernel right after i did alpine 3.11.6 release
2020-04-23 09:48:47 <ikke> sigh
2020-04-23 09:54:31 <mps> uhm, so fast new kernel, and look very important fixes
2020-04-23 09:57:15 <mps> some of them are BPF
2020-04-23 10:08:55 <ncopa> ugh.
2020-04-23 10:09:01 <ncopa> they also release 4.19.118 kernels
2020-04-23 10:09:05 <ncopa> oh well
2020-04-23 10:11:10 <AinNero> a
2020-04-23 10:24:45 <Ariadne> ncopa: yeah I will test in a bit
2020-04-23 10:34:02 <ncopa> i think im gonna ignore the rpi kernel for alpine 3.10 and 3.9
2020-04-23 10:34:14 <ncopa> or i will never be able to get the releases out
2020-04-23 10:34:28 <mps> uh
2020-04-23 10:35:02 <ncopa> what people dont understand that adding kernel flavors add significant amount of work when there are new releases
2020-04-23 10:35:58 <mps> yes
2020-04-23 10:36:13 <mps> but I understand it is not easy task
2020-04-23 10:36:40 <Cogitri> I feel like we should switch external kernel modules over to DKMS, so we at least don't have to bump all of those when bumping kernels
2020-04-23 10:37:28 <mps> but...but, making release without upgrade important fixes also is not 'good' from 'marketing' perspective
2020-04-23 10:37:43 <mps> if we care about marketing :)
2020-04-23 10:37:47 <ncopa> not making release is wrose
2020-04-23 10:38:50 <ncopa> and CONFLICT (content): Merge conflict in drivers/gpu/drm/vc4/vc4_hdmi.c
2020-04-23 10:38:56 <ncopa> does not make my life easier
2020-04-23 10:40:40 <mps> hmm, don't know
2020-04-23 11:05:06 <ncopa> can i update linux-rpi kernels (4.19.y) in alpine 3.9 and 3.10 without update the raspberrypi-firmware?
2020-04-23 11:05:23 <ncopa> or do i also need to update the raspberrypi-firmware?
2020-04-23 11:05:41 <clandmeter> i think it needs to match afaik
2020-04-23 11:06:28 <ncopa> so where do find raspberrypi-firmware for 4.19.118? or can i use same firmware as we use for 5.4.35?
2020-04-23 11:07:15 <ncopa> how do i know which raspberrypi-firmware matches a given kernel?
2020-04-23 11:07:46 <ncopa> or is "always use latest raspberrypi-firmware" good enough?
2020-04-23 11:08:13 <clandmeter> https://github.com/raspberrypi/firmware
2020-04-23 11:08:24 <clandmeter> they mention it in the commit log
2020-04-23 11:10:02 <clandmeter> but yeah its a headache
2020-04-23 11:10:44 <clandmeter> https://github.com/raspberrypi/firmware/commit/dd8cbec5a6d27090e5eb080e13d83c35fdd759f7
2020-04-23 11:10:55 <clandmeter> that seems like the last update for a specific kernel version
2020-04-23 11:11:47 <ncopa> there are no firmware release since 20200212
2020-04-23 11:12:48 <clandmeter> i think those release are for raspbian
2020-04-23 11:13:27 <clandmeter> https://downloads.raspberrypi.org/raspbian/release_notes.txt
2020-04-23 11:13:48 <clandmeter> they are still on Linux kernel 4.19.97
2020-04-23 11:14:35 <clandmeter> a good question to have an aswer for is, are the fw's bw compat
2020-04-23 11:19:34 <clandmeter> That is the correct approach. There is, as you say, no version checking between kernel and firmware IIRC, so always using the latest firmware (we retain backwards compatibility as far as possible) is the best option.
2020-04-23 11:19:55 <clandmeter> https://github.com/raspberrypi/firmware/issues/803#issuecomment-367295401
2020-04-23 11:28:07 <ncopa> 👍
2020-04-23 11:59:30 <mps> ikke: ncopa: I created !7119 rename mdocml to mandoc
2020-04-23 12:00:18 <mps> please comment if something is wrong, so I can add pkgs which need depends changes to this MR
2020-04-23 12:02:00 <ikke> One small thing, for the rest looks ok
2020-04-23 12:05:23 <mps> oh, yes. thanks
2020-04-23 12:14:09 <Ariadne> same as ikke
2020-04-23 12:14:13 <Ariadne> i only see that one thing wrong
2020-04-23 12:16:03 <mps> thanks both, and Cogitri
2020-04-23 12:16:24 <Cogitri> 👍️
2020-04-23 12:36:40 <Cogitri> Not sure if we want to do official Alpine "events", but can we maybe do something about upstreaming more patches (e.g. a sprint)?
2020-04-23 12:37:14 <Cogitri> ````
2020-04-23 12:37:14 <Cogitri> find ./aports/ -name "*.patch" | wc -l
2020-04-23 12:37:14 <Cogitri> 3243
2020-04-23 12:37:15 <Cogitri> ```
2020-04-23 12:37:15 <Cogitri> :/
2020-04-23 12:39:33 <Ariadne> Cogitri: i do want to
2020-04-23 12:42:48 <ncopa> Cogitri: that sounds like a good idea
2020-04-23 12:44:27 <ncopa> mps: can you please test the 3.11.6 on rpi?
2020-04-23 12:44:45 <mps> ncopa: yes
2020-04-23 12:44:57 <mps> rpi armhf only
2020-04-23 12:45:08 <ncopa> 👍
2020-04-23 12:45:19 <mps> post me url
2020-04-23 12:45:42 <ncopa> http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/armhf/alpine-rpi-3.11.6-armhf.tar.gz
2020-04-23 12:45:53 <ncopa> from https://alpinelinux.org/downloads/
2020-04-23 12:47:37 <mps> ah, you already released it
2020-04-23 12:57:02 <mps> ncopa: works fine, installed and tested in run-from-RAM mode
2020-04-23 12:57:11 <mps> rpi zero W
2020-04-23 12:58:01 <oneinsect> why cant we also have a usb in memory mode similar to rpi to x86-64 without iso
2020-04-23 12:58:18 <ikke> we can
2020-04-23 12:58:29 <ikke> unless I'm misunderstanding you
2020-04-23 12:59:57 <oneinsect> well once i copy an rpi alpine to sd-card, setting up cache etc is very easy, i mean lbu-setup easily sets up a portion of sdcard for writes
2020-04-23 13:00:09 <oneinsect> does the x86 version do that? last i check it doesnt?
2020-04-23 13:00:19 <ikke> You can use setup-bootable for that
2020-04-23 13:00:23 <oneinsect> aha
2020-04-23 13:00:25 <ikke> It creates a usb drive that is writable
2020-04-23 13:00:38 <oneinsect> but I want to be in-memory only
2020-04-23 13:00:43 <ikke> yes
2020-04-23 13:00:53 <oneinsect> with manual lbu commit for commits
2020-04-23 13:00:55 <ikke> yes
2020-04-23 13:01:00 <oneinsect> great
2020-04-23 13:01:00 <ncopa> or you can 7z unzip the iso to your usb
2020-04-23 13:01:09 <ncopa> you may need to run syslinux
2020-04-23 13:01:12 <ikke> yea
2020-04-23 13:01:14 <ikke> and write a bootlaoder
2020-04-23 13:01:31 <oneinsect> perfect i did not know i could just unzip it to usb and just write a bootloader
2020-04-23 13:01:34 <oneinsect> perfect!!
2020-04-23 13:01:37 <oneinsect> just perfect
2020-04-23 13:02:00 <ikke> setup-bootable basically automates that
2020-04-23 13:02:42 <ikke> I used an alpine docker container in privileged mode in which I attached the usb block devices to and ran setup-bootlable
2020-04-23 13:02:44 <oneinsect> does setup-bootable exist for rpi versions also?
2020-04-23 13:03:03 <ikke> oneinsect: you can just specify an iso to write
2020-04-23 13:03:11 <oneinsect> coz i do just manual copy which works fine for me for rpi
2020-04-23 13:03:17 <oneinsect> aha
2020-04-23 13:03:21 <oneinsect> got it
2020-04-23 13:03:24 <oneinsect> thanks ikke:
2020-04-23 13:03:38 <ikke> setup-bootable does setup syslinux though
2020-04-23 13:03:46 <oneinsect> btw my struggle continues, hopefully today there is some respite from the daemons
2020-04-23 13:03:54 <oneinsect> ooh nice
2020-04-23 13:44:23 <maxice8> Hey i finshed working on json-c-0.14 and i want to push it
2020-04-23 13:44:26 <maxice8> it has quite a few rebuilds, 27 packages
2020-04-23 13:44:38 <maxice8> none too big like firefox, libreoffice, qt5, but it is still a less than 0 amount
2020-04-23 13:45:05 <ncopa> maxice8: does it pass? if so, push it!
2020-04-23 13:45:15 <ncopa> thanks for taking care of it
2020-04-23 13:45:16 <maxice8> it passes but last time i pushed one whole MR
2020-04-23 13:45:24 <maxice8> it mangled the build order
2020-04-23 13:45:33 <maxice8> it was libffi and some packages were built with libffi.so.6 instead of libffi.so.7
2020-04-23 13:45:40 <maxice8> caused quite a bit of pain
2020-04-23 13:46:22 <ncopa> i think the reason for that was that the builders ahd the old libffi installed for some reason
2020-04-23 13:46:25 <TBK[m]> btw there is an issue with GH atm
2020-04-23 13:46:32 <Cogitri> Yup, it's down again
2020-04-23 13:46:45 <maxice8> @TBK there is a secissue assigned to you for a package, can i take care of it ?
2020-04-23 13:46:52 <TBK[m]> so if any of the pkgs pull src from there, wait!
2020-04-23 13:47:05 <TBK[m]> waiting on gh...
2020-04-23 13:47:22 <maxice8> I am waiting fletching headless arrows in RuneScape3
2020-04-23 13:48:20 <TBK[m]> ehh so the arrows are blunt?
2020-04-23 14:03:19 <maxice8> Until they are tipped
2020-04-23 14:12:32 <PureTryOut[m]> > Runescape 3
2020-04-23 14:12:36 <PureTryOut[m]> Why when there is Oldschool?
2020-04-23 14:12:44 <maxice8> I prefer rs3
2020-04-23 14:12:57 <PureTryOut[m]> Strange 🤷‍♂️
2020-04-23 14:13:34 <PureTryOut[m]> That reminds me that I need to continue training hunter
2020-04-23 14:13:43 <maxice8> I never played oldschool runescape so i don't have nostalgia that makes me want to play it i guess
2020-04-23 14:14:34 <PureTryOut[m]> I guess, although all the microtransactions and stuff in RS3 makes it so unappealing, even if it's a good game otherwise
2020-04-23 14:14:45 <maxice8> I just ignore them
2020-04-23 14:15:28 <maxice8> also -> #offtopic
2020-04-23 14:18:49 <markand> hello
2020-04-23 14:18:58 <markand> just a friendly ping for the basic !6909
2020-04-23 14:21:16 <Cogitri> Ah, we don't get pings when you remove the WIP or add a comment on that
2020-04-23 14:22:57 <markand> :-)
2020-04-23 14:28:34 <ncopa> ok release notes for 3.9.6 + 3.10.5? https://wwwtest.alpinelinux.org/posts/Alpine-3.9.6-and-3.10.5-released.html
2020-04-23 14:32:57 <ncopa> no complaints so pushed :)
2020-04-23 14:33:02 <maxice8> :D
2020-04-23 14:33:14 <maxice8> i would post it on r/linux but my account is too new
2020-04-23 14:33:50 <ncopa> i dont think 3.9 and 3.10 is newsworthy
2020-04-23 14:33:53 <ncopa> 3.11 is
2020-04-23 14:34:05 <maxice8> We can let reddit decide :D
2020-04-23 14:45:05 <ncopa> maxice8: i think json-c get problems due to cryptsetup
2020-04-23 14:45:23 <maxice8> but why only in armhf ?
2020-04-23 14:45:25 <maxice8> i saw it breaks cryptsetup-liibs
2020-04-23 14:45:27 <maxice8> i saw it breaks cryptsetup-libs
2020-04-23 14:45:37 <ncopa> my guess it is some leftover
2020-04-23 14:45:44 <ncopa> should probably not been installed on the builder
2020-04-23 14:45:49 <maxice8> does the armhf builder has it installed while no other builder has ?
2020-04-23 14:45:51 <ncopa> only during releases
2020-04-23 14:46:01 <ncopa> i guess thats the case
2020-04-23 14:46:04 <ncopa> let me investigate
2020-04-23 14:46:28 <maxice8> Also there is a new ICU, i guess that should be for 3.13 ?
2020-04-23 14:49:15 <ncopa> i think we can include icu
2020-04-23 14:49:28 <ncopa> ok i got 3 releases out today
2020-04-23 14:49:29 <maxice8> ight, i'll work on it
2020-04-23 14:49:29 <Cogitri> ICU shouldn't be problematic, yes
2020-04-23 14:49:53 <maxice8> ICU just requires LOTS of rebuilding
2020-04-23 14:49:59 <ncopa> yeah
2020-04-23 14:50:02 <maxice8> So yeah cogitri i'm conscripting your help
2020-04-23 14:53:17 <Cogitri> Heh, sure :P
2020-04-23 14:55:59 <ncopa> i will try get some of the 3.12 builders up tomorrow
2020-04-23 14:56:13 <ncopa> at least bootstrap the toolchain and abuild
2020-04-23 14:57:18 <ncopa> im gonna call it a day
2020-04-23 14:57:57 <maxice8> Thanks for looking at armhf
2020-04-23 14:58:44 <Cogitri> Also, have we arrived at a decision what to do with Rust in stable releases?
2020-04-23 15:05:04 <maxice8> !7127
2020-04-23 15:05:09 <maxice8> Time to abuse the CI
2020-04-23 15:24:35 <maxice8> I have split the commits by repository
2020-04-23 15:24:50 <maxice8> main/icu: upgrade, then main/: rebuild against icu, then community/: rebuild against icu
2020-04-23 15:24:58 <maxice8> is that enough to guarantee the builder won't screw up ordering ?
2020-04-23 15:26:09 <TBK[m]>  ¯\_(ツ)_/¯
2020-04-23 15:27:48 <mps> heirloom-doctools fails to build in current state
2020-04-23 15:27:58 <mps> nmeum: ^
2020-04-23 15:32:58 <nmeum> oh
2020-04-23 15:33:33 <mps> I see you are maintainer
2020-04-23 15:33:34 <nmeum> is it urgent?
2020-04-23 15:33:36 <nmeum> I know
2020-04-23 15:34:06 <mps> I'm trying to fix depends on mdocml which I renamed to mandoc
2020-04-23 15:34:30 <mps> would you mind if I post you build log
2020-04-23 15:34:39 <nmeum> I already reproduced the build failure
2020-04-23 15:34:44 <mps> ah, ok
2020-04-23 15:34:46 <nmeum> can look into it in a few minutes
2020-04-23 15:35:16 <mps> ok, no hurry, we have some time till freeze
2020-04-23 15:35:29 <mps> just wanted to notice you
2020-04-23 15:36:15 <nmeum> ok, thanks for pointing that out
2020-04-23 15:37:00 <mps> np :)
2020-04-23 16:04:48 <nmeum> mps: pushed two changes which fixed the build for me
2020-04-23 16:05:15 <mps> nmeum: nice, and thanks
2020-04-23 16:05:41 <nmeum> I hope this work on the other arches as well, lets see :)
2020-04-23 16:05:45 <nmeum> *these
2020-04-23 16:07:18 <nmeum> build seems to have passed on all arches
2020-04-23 16:07:39 <mps> also tested right now locally, passed
2020-04-23 16:23:06 <minecrell> TBK[m]: I think I fixed the tinyalsa build error on ppc64le (was easier than making an issue), but can't test it because someone is blocking all the builders :(
2020-04-23 16:27:44 <TBK[m]> minecrell: k, will take a look later :)
2020-04-23 16:29:49 <TBK[m]> minecrell: you could also try locally with https://gitlab.alpinelinux.org/alpine/docker-abuild#configure-multi-arch-support
2020-04-23 18:47:38 <mps> PureTryOut[m]: !6677 arm-trusted-firmware: enable rk3399 support, I don't see rk3399-baudrate.patch file there
2020-04-23 20:18:24 <mps> eh, nice. looks like kernel 5.6.7 fixed bug with apk and f2fs filesystem on armv7, finaly :)
2020-04-23 20:21:12 <Cogitri> Nice
2020-04-23 20:22:24 <mps> yes, now can install linux-lts (big pkg) without problem
2020-04-23 20:38:40 <mps> CIs are loaded (high load, I mean)
2020-04-23 20:42:00 <Cogitri> Yup, due to ICU
2020-04-23 20:46:52 <ikke> and librsvg apparently
2020-04-23 20:50:56 <ikke> ugh
2020-04-23 20:50:59 <Cogitri> I only restarted that a few minutes ago
2020-04-23 20:51:00 <ikke> ICU just timed out :(
2020-04-23 20:51:13 <ikke> RROR: Job failed: execution took longer than 5h0m0s seconds
2020-04-23 20:51:39 <ikke> maxice8: ^
2020-04-23 20:51:48 <Cogitri> Well, I'm in the process of testing all of them locally
2020-04-23 20:51:53 <Cogitri> I only need to build testing now
2020-04-23 20:52:14 <Cogitri> And I don't think icu will fail on other arches
2020-04-23 20:54:04 <mps> I finished mdocml rename to mandoc and all packages which need to be updated
2020-04-23 21:17:54 <TBK[m]> one down, 554 to go
2020-04-23 21:18:11 <TBK[m]> 
ACTION wink at Cogitri

2020-04-23 21:22:29 <Cogitri> Heh, maybe I'll have time to go through more issues tomorrow or at the weekend again :P
2020-04-24 06:03:57 <ncopa> morning
2020-04-24 06:04:20 <afontain_> morning
2020-04-24 06:09:56 <Cogitri> Morning
2020-04-24 06:10:36 <mps> morgen :)
2020-04-24 06:26:18 <ikke> morning
2020-04-24 06:43:14 <clandmeter> morning
2020-04-24 07:08:28 <PureTryOut[m]> morning
2020-04-24 07:12:52 <TBK[m]> morning
2020-04-24 07:35:15 <mps> ncopa: ikke: I finished mdocml rename to mandoc, MR is !7119
2020-04-24 07:35:41 <mps> should be merged before 3.12 freeze
2020-04-24 07:36:07 <mps> and I hope I didn't made some big errors/mistakes there
2020-04-24 07:37:37 <PureTryOut[m]> ncopa: since you maintain Chromium, are the patches used being upstreamed?
2020-04-24 07:38:15 <mps> PureTryOut[m]: !6677 arm-trusted-firmware: enable rk3399 support, I don't see rk3399-baudrate.patch file there
2020-04-24 07:38:29 <mps> sorry for repeating question
2020-04-24 07:39:04 <PureTryOut[m]> mps: didn't see the question before, so np. Guess I forgot to git add 🤔
2020-04-24 07:39:31 <mps> np, I want to test this
2020-04-24 07:40:32 <PureTryOut[m]> Oh actually I already added it in a previous MR, so it's already in there
2020-04-24 07:40:53 <mps> nmeum: should we move zig to community before freeze, we can try add some other archs later
2020-04-24 07:40:57 <PureTryOut[m]> This MR just enables the bit of atf that actually uses it lol, which I forgot before
2020-04-24 07:41:18 <PureTryOut[m]> However, gcc-cross-embedded being in testing still is a problem for this
2020-04-24 07:41:23 <mps> PureTryOut[m]: ah, so I missed previous MR
2020-04-24 07:41:35 <PureTryOut[m]> Seems like it yes
2020-04-24 07:41:49 <mps> could you give MR number?
2020-04-24 07:42:09 <PureTryOut[m]> Uh... Have to check
2020-04-24 07:42:36 <mps> maybe it is closed
2020-04-24 07:42:52 <PureTryOut[m]> mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6523
2020-04-24 07:43:22 <mps> ah, I see. thanks
2020-04-24 08:20:48 <nmeum> mps: not sure, what do you think?
2020-04-24 08:30:12 <mps> nmeum: also I'm not sure. on one side if people want it maybe we can move it on the other side I think till it isn't released with stable api we should not
2020-04-24 08:31:26 <mps> personally I think we should not move any language without stable api to community or main, testing is quite fine for such langs
2020-04-24 08:31:37 <nmeum> yeah, waiting a bit is probably best
2020-04-24 08:32:10 <Cogitri> What lang are we talking about?
2020-04-24 08:32:28 <mps> I don't understand why is crystal in community, with every release something changes in data types and functions and included libs
2020-04-24 08:32:30 <TBK[m]> zig
2020-04-24 08:33:20 <Cogitri> Ah
2020-04-24 08:33:43 <mps> but if there is significant demand or lang is used 'in the wild' we should move it in community in current state
2020-04-24 08:34:28 <mps> but, I'm just thinking aloud, not that I deciding anything
2020-04-24 08:40:00 <mps> PureTryOut[m]: !6677 (arm-trusted-firmware) builds fine in lxc aarch64
2020-04-24 08:40:24 <PureTryOut[m]> That is good, but without gcc-cross-embedded in main it won't do much good
2020-04-24 08:41:18 <mps> hmm, will look over weekend if it can be built without gcc-cross-embedded
2020-04-24 08:41:41 <mps> sun50i can
2020-04-24 08:41:54 <mps> only rk3399 is problem, iiuc
2020-04-24 08:43:10 <PureTryOut[m]> Yeah I know
2020-04-24 08:45:49 <mps> I will ask rk3399 people about that
2020-04-24 08:48:54 <mps> samsungs exfat-utils is renamed to exfatprogs, (https://github.com/exfatprogs/exfatprogs)
2020-04-24 08:49:36 <mps> so I should rename it also before push to aports, but not sure what would be proper name, exfatprogs or exfat-progs
2020-04-24 08:51:43 <TBK[m]> hmm it is 50/50 https://pkgs.alpinelinux.org/packages?name=*progs&branch=edge&arch=x86_64
2020-04-24 08:52:02 <TBK[m]> I would go with upstream name, so exfatprogs
2020-04-24 08:52:29 <mps> TBK[m]: also I tend to this
2020-04-24 08:53:04 <mps> i.e. follow upstream names whenever is possible
2020-04-24 09:15:20 <ncopa> PureTryOut[m]: many patches are not upstreamed. I have simply not taken the time to upstream them
2020-04-24 09:15:35 <ncopa> several reasons
2020-04-24 09:16:22 <ncopa> the process for getting patch reviews upstream seems a bit heavy weight.
2020-04-24 09:16:24 <PureTryOut[m]> Hmm ok. I'm asking since upgrading qt5-qtwebengine is mostly just taking patches from chromium and modifying the file paths. Upstreaming them to Chromium would reduce the maintainance effort
2020-04-24 09:16:51 <ncopa> process is something like: 1, become an google employe, 2....
2020-04-24 09:16:56 <ncopa> :)
2020-04-24 09:17:08 <ncopa> yeah, i understand
2020-04-24 09:17:15 <afontain_> :D
2020-04-24 09:17:23 <ncopa> other reason is that they do some assumptions on the platforms
2020-04-24 09:17:36 <ncopa> like OS_LINUX == GNU
2020-04-24 09:17:44 <mps> 3.... leave alpine :)
2020-04-24 09:18:33 <ncopa> and i have a feeling that introducing a OS_GNU_LINUX vs OS_LINUX is not going to be accepted upstream
2020-04-24 09:18:47 <ncopa> because it makes things simpler for google to think linux==gnu
2020-04-24 09:19:12 <ncopa> i have my doubts that they will support musl
2020-04-24 09:19:21 <ncopa> there is a high chance that they wont
2020-04-24 09:19:40 <ncopa> which is demotivating when it comes to spending significant time to upstream stuff
2020-04-24 09:20:19 <ncopa> but many of our patches are in thirdpart repos
2020-04-24 09:20:38 <ncopa> chrome's thirdparty libs
2020-04-24 09:20:52 <ncopa> and i think what we can do is to submit patches upstream
2020-04-24 09:20:58 <ncopa> above chrome
2020-04-24 09:21:23 <ncopa> that would result in patches getting into chrome eventually
2020-04-24 09:21:40 <ncopa> i saw someone from gentoo submitting patches
2020-04-24 09:21:58 <ncopa> but yes, we should do that
2020-04-24 09:25:49 <PureTryOut[m]> They might not support musl themselves, but I'm sure they're willing to accept patches that support it, as long as it doesn't break GNU. But yeah I understand upstreaming stuff to it is hard. That's the usual with Google stuff
2020-04-24 09:42:28 <Cogitri> Can someone with main bits merge !6843 please?
2020-04-24 09:46:11 <ikke> Will be merged when CI is done
2020-04-24 09:48:25 <Cogitri> Merci
2020-04-24 11:07:08 <ikke> How come a lot of python3 packages suddently require py3-pbr in makedepends?
2020-04-24 11:07:38 <ikke> I think it's a missing dep for setuptools
2020-04-24 11:18:31 <mps> ncopa: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/headers_install.rst
2020-04-24 11:18:51 <mps> 'Kernel headers are backwards compatible, but not forwards compatible'
2020-04-24 11:22:46 <ncopa> ok?
2020-04-24 11:23:31 <ncopa> "but a program built against newer kernel headers may not work on an older kernel."
2020-04-24 11:23:41 <mps> so, we can upgrade linux-headers without waiting for new linux-lts
2020-04-24 11:23:53 <ncopa> yes
2020-04-24 11:24:09 <ncopa> well
2020-04-24 11:24:37 <ncopa> according the doc, the program may not work with our older lts kernel
2020-04-24 11:24:43 <mps> so, this is slippery slope, whatever we do
2020-04-24 11:25:02 <ncopa> yeah
2020-04-24 11:25:16 <ncopa> i think, in general, it should be no problem
2020-04-24 11:25:31 <ncopa> musl does not use any newer features
2020-04-24 11:25:47 <ncopa> i mean, they use, but have often fallback on ENOSYS
2020-04-24 11:26:10 <ncopa> but i think we should keep our linux-headers so it matches with our linux-lts
2020-04-24 11:26:15 <ncopa> i think thats the safest
2020-04-24 11:30:05 <Cogitri> Yup
2020-04-24 11:33:08 <ikke> is it correct btw that abuild-3.6.0rc1 is in edge?
2020-04-24 11:33:43 <mps> yes, that is safest
2020-04-24 11:34:23 <mps> but I'm contemplating options before adding linux-edge to aports
2020-04-24 11:34:39 <mps> (sorry, had a phone call)
2020-04-24 11:34:43 <ncopa> ikke: yes
2020-04-24 11:34:52 <ikke> ok
2020-04-24 11:36:11 <Cogitri> We're going to have abuild 3.6 in 3.12, right?
2020-04-24 11:36:44 <ikke> I think that's the idea of having rc1 already in edge
2020-04-24 11:37:15 <mps> though I didn't noticed issues with userspace built with linux 5.4 headers (3.11-stable) with 3.18 kernel
2020-04-24 11:38:07 <Cogitri> Just wanted to be sure since !7155 would break stuff for 3.12 otherwise
2020-04-24 11:38:11 <mps> and also running 5.6 kernel on 3.11-stable (which is built with 5.4 linux-headers0
2020-04-24 11:39:06 <Cogitri> mps: Well, if something is built with kernel-headers 5.6 and expects additional members on some struct or smth it could SEGFAULT/SIGSEGV on older kernels
2020-04-24 11:39:57 <mps> yes, could, but I didn't noticed anything till now
2020-04-24 11:41:02 <Cogitri> I don't think there's a point in using newer linux-headers though. For things which dont need the new API nothing changes and for things which do need the new API they'll break during runtime
2020-04-24 11:41:06 <mps> could be because musl is so good :)
2020-04-24 11:42:35 <mps> not sure, but I think it depends on what linux-headers base libc is built
2020-04-24 11:42:52 <mps> for most programs
2020-04-24 11:46:15 <ncopa> Cogitri: i normally want to wait with using new abuild features for another release cycle
2020-04-24 11:46:39 <ncopa> because it increases to work needed when backporting security fixes to stable branches
2020-04-24 11:47:04 <Cogitri> Well, I don't see how we'd wait with this one though
2020-04-24 11:47:19 <Cogitri> Since without the change the build will fail because we try to move a dir which doesn't exist anymore
2020-04-24 11:47:28 <ncopa> right
2020-04-24 11:47:31 <Cogitri> So we'd have to move the dir moving in front of default_dev
2020-04-24 11:47:31 <ncopa> that makes sense
2020-04-24 13:54:45 <ikke> We don't need sudo for abuild anymore? (did you switch to doas?)
2020-04-24 14:00:18 <kaey> you can upgrade kernel, but keep older headers, not the other way around
2020-04-24 14:25:06 <Hello71> although in practice uapi structs haven't changed in a long time, except maybe for very special syscalls (e.g. perf_event_open)
2020-04-24 14:25:31 <Hello71> libc headers are the main problem, although even there I think it's mainly glibc
2020-04-24 14:26:34 <Hello71> mostly newer headers have more functions, but people using syscall are usually either sensible enough to handle ENOSYS or actually absolutely require the function, so it just errors out
2020-04-24 14:38:15 <ncopa> we shoudnt need sudo for abuild
2020-04-24 14:39:33 <ikke> How is abuild supposed to install packages then for example?
2020-04-24 14:39:36 <ikke> (deps)
2020-04-24 14:40:13 <ncopa> using abuild-apk
2020-04-24 14:40:23 <Hello71> I think ikke means like su vs sudo vs doas
2020-04-24 14:40:29 <Hello71> and ncopa means sudo abuild
2020-04-24 14:40:44 <ncopa> nope
2020-04-24 14:41:00 <ncopa> we have a suid root wrapper so sudo shouldnt be needed
2020-04-24 14:41:09 <Hello71> ah
2020-04-24 14:41:26 <ncopa> you need to be in the abuild group
2020-04-24 14:41:27 <ikke> Why is sudo invoked then?
2020-04-24 14:41:34 <ikke> even if you  in the abuild group
2020-04-24 14:41:39 <ncopa> it shouldnt be invoked
2020-04-24 14:41:47 <ikke> It at least always has been
2020-04-24 14:42:18 <ncopa> i dont think it is anymore
2020-04-24 14:42:39 <ikke> Before sudo was fixed, abuild -r always gave permission denied warnings
2020-04-24 14:43:08 <ncopa> locally or on some build server?
2020-04-24 14:43:25 <ikke> locally, CI
2020-04-24 14:44:03 <ncopa> we should fix that if it is not already
2020-04-24 14:44:08 <ncopa> we shouldnt need sudo at all
2020-04-24 14:44:15 <ncopa> if we do, then something needs to be fixed
2020-04-24 14:46:44 <ncopa> aports-build as a dependency of ssh client
2020-04-24 14:46:55 <ncopa> for creating remote directory
2020-04-24 14:47:03 <ncopa> i think we want get rid of that too
2020-04-24 14:47:16 <ncopa> but we need re-arrange the output dirs for releases and packages
2020-04-24 14:47:40 <ncopa> i'd like rsync to create the remote dirs
2020-04-24 14:47:47 <ikke> This needs to be updated then: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2020-04-24 14:47:59 <ikke> it still has instructions to mention that you need to setup sudo
2020-04-24 14:48:25 <ikke> I removed myself from the sudo group, and it works now, so yes, it has been fixed
2020-04-24 14:48:35 <ncopa> that doc needs update yes
2020-04-24 14:48:39 <ncopa> use gitlab i gues
2020-04-24 14:53:18 <mps> kaey: kernel docs says other
2020-04-24 14:54:13 <ikke> (2/4) Purging sudo (1.8.31p1-r0) :)
2020-04-24 14:54:46 <mps> and safest would be 'never upgrade anything'
2020-04-24 14:55:02 <ikke> Not even that
2020-04-24 14:55:33 <ncopa> was sudo removed for CI too?
2020-04-24 14:55:42 <ikke> ncopa: Hmm, good question
2020-04-24 14:55:47 <ncopa> can we test that we didnt break anything?
2020-04-24 14:56:03 <ncopa> i guess we coudl push a trivial package update or similar
2020-04-24 14:56:39 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/blob/master/overlay/usr/local/bin/setup.sh
2020-04-24 14:56:54 <ikke> We don't explicitly install it, as it was part of abuild, but we do configure it
2020-04-24 14:57:32 <ncopa> shouldnt need to be in the wheel group
2020-04-24 14:57:38 <ikke> right
2020-04-24 14:57:46 <ikke> and those chmods can be removed as well
2020-04-24 14:58:05 <ncopa> can we drop alpine-sdk?
2020-04-24 14:58:24 <ncopa> use abuild and build-base alone
2020-04-24 14:58:43 <ikke> I guess that should be possible, yes
2020-04-24 14:59:07 <ikke> What is the idea?
2020-04-24 14:59:18 <ikke> We would probably need to install git then as well
2020-04-24 14:59:43 <ncopa> the idea is to keep as few deps there as possible
2020-04-24 14:59:45 <ncopa> yes
2020-04-24 14:59:59 <ncopa> git may be needed if it is used
2020-04-24 15:00:04 <ikke> alpine-sdk == git abuild and build-base
2020-04-24 15:00:11 <ikke> so you would lose nothing
2020-04-24 15:00:12 <mps> is git needed for builder
2020-04-24 15:00:25 <ncopa> ah
2020-04-24 15:00:26 <ncopa> :)
2020-04-24 15:00:35 <ncopa> so alpine-sdk has been simplified
2020-04-24 15:00:36 <ncopa> good
2020-04-24 15:00:40 <ncopa> it used to be lots of stuff
2020-04-24 15:01:23 <ikke> mps: yes, the builders need git
2020-04-24 15:01:30 <ncopa>  b668331b3aab9ffdf1c5dcc735430a0208baffe7
2020-04-24 15:01:40 <ikke> ah ok
2020-04-24 15:02:11 <Hello71> hm... if you can install anything from anywhere with abuild-sudo, isn't abuild group equivalent to passwordless sudo?
2020-04-24 15:02:15 <mps> yes, 'not a git repo' warning, but in principle
2020-04-24 15:02:40 <ncopa> Hello71: it is
2020-04-24 15:03:16 <ncopa> Hello71: i'd like to re-architecture that part
2020-04-24 15:03:31 <ncopa> so that you need root to build anything that requires deps
2020-04-24 15:03:54 <ikke> hmm?
2020-04-24 15:04:03 <ikke> basically everything..
2020-04-24 15:04:22 <ncopa> yes, but drop permissions for everything except installing/uninstalling deps
2020-04-24 15:05:02 <ikke> Isn't that worse?
2020-04-24 15:05:08 <ikke> oh no
2020-04-24 15:05:14 <ncopa> so flip it around: instead of elevating privs to install/deinstall deps, drop privs between the install/deinstall
2020-04-24 15:05:40 <ncopa> that way we get rid of the nasty elevate privs problem
2020-04-24 15:05:42 <ikke> so you would need to use sudo / doas agian to run abuild basically
2020-04-24 15:05:46 <ncopa> correct
2020-04-24 15:06:11 <Hello71> I think that is more confusing, especially if you want packages dir to be owned by own user
2020-04-24 15:06:21 <Hello71> that would be fine if you had a dedicated abuild user
2020-04-24 15:06:38 <ncopa> Hello71: but you'd still need privs to install deps
2020-04-24 15:07:00 <Hello71> my point is how do you find out which user to switch back to
2020-04-24 15:07:15 <Hello71> you can use SUDO_UID, but, like... *ugh*
2020-04-24 15:07:26 <ncopa> i guess it could be configurable
2020-04-24 15:07:27 <ikke> breaks if you use doas :)
2020-04-24 15:07:57 <ncopa> doas abuild --user ncopa -r
2020-04-24 15:07:59 <ikke> Not sure if it's an improvement if abuild itself has to run as root
2020-04-24 15:08:24 <ncopa> the point is that i'd like to wrap it around
2020-04-24 15:08:33 <Hello71> what's wrong with calling sudo anyways? that's what makepkg does
2020-04-24 15:08:53 <ncopa> from arch?
2020-04-24 15:08:57 <ncopa> arch linux
2020-04-24 15:09:11 <Hello71> the only problem I know of is that if you don't set NOPASSWD then you need to enter password up to twice
2020-04-24 15:09:14 <Hello71> yeah
2020-04-24 15:09:23 <Hello71> does anybody else have a makepkg?
2020-04-24 15:09:33 <ikke> I do
2020-04-24 15:09:39 <ikke> Oh, you mean other arch
2020-04-24 15:09:53 <ncopa> problem is that build servers effectively runs as root
2020-04-24 15:10:30 <ncopa> we could use sudo or doas
2020-04-24 15:10:39 <ncopa> and maybe its better to do so
2020-04-24 15:10:47 <ncopa> but then it needs to be configured properly
2020-04-24 15:10:53 <ncopa> and becomes a dependency
2020-04-24 15:11:06 <ikke> You would need some kind of wrapper that runs as root, runs all abuild operations except deps as a non-root user
2020-04-24 15:12:06 <ncopa> ideally it should be containerized, rootbld or docker or similar
2020-04-24 15:13:05 <ikke> rootbld does not work without privileges in an LXC container
2020-04-24 15:15:29 <ikke> bwrap
2020-04-24 15:18:07 <PureTryOut[m]> If you guys are working on the CI anyway, could you make it either build without network connection or use rootbld?
2020-04-24 15:18:57 <ikke> rootbld does not make sense for CI as it is run in a docker container
2020-04-24 15:19:00 <PureTryOut[m]> If we some day want reproducible builds, packages will have to build without network access. At least rootbld enforces that already (but `options="!net"` can overwrite it if really necessary)
2020-04-24 15:19:06 <Cogitri> I think a switch to rootbld would be required then, because otherwise CI would need some additional logic to recgonise options=net
2020-04-24 15:19:10 <ikke> PureTryOut[m]: too many packages do requrie network access
2020-04-24 15:19:21 <Cogitri> And at least for Go and Cargo we currently need network access
2020-04-24 15:19:25 <ikke> yes
2020-04-24 15:19:26 <Cogitri> They're still reproducible though
2020-04-24 15:19:44 <PureTryOut[m]> Like I said, you can add `options="net"` for the ones that require it
2020-04-24 15:20:02 <PureTryOut[m]> But it would at least force people to specify if packages require network access, so those can be worked on later on
2020-04-24 15:20:06 <ikke> But I doubt that rootbld works in a docker container
2020-04-24 15:20:47 <Cogitri> Needs privileged containers too I think
2020-04-24 15:20:59 <ikke> yes, and that;s what we don't want
2020-04-24 15:21:23 <PureTryOut[m]> At least disable network access and make it listen to the "net" options then
2020-04-24 15:21:33 <PureTryOut[m]> *disable network access by default
2020-04-24 15:21:38 <ikke> We need network access for dependencies
2020-04-24 15:21:56 <ikke> so we need to somehow disable it just after dependencies have been installed
2020-04-24 15:22:13 <PureTryOut[m]> Disable it while building I mean ofc, not entirely
2020-04-24 15:22:27 <ikke> yes, but that's not an easy thing to dod
2020-04-24 15:22:29 <ikke> do
2020-04-24 15:22:39 <ikke> without abuild support that is
2020-04-24 15:23:10 <PureTryOut[m]> Well, we control abuild, we can add support for it
2020-04-24 15:24:31 <Cogitri> How would you restrict network acces without some kind of a sandbox?
2020-04-24 15:24:52 <ikke> One easy way is to block DNS
2020-04-24 15:25:21 <Cogitri> Ah right, meant without crippling the system (but I guess for CI containers that's not a problem)
2020-04-24 15:26:55 <PureTryOut[m]> Well rootbld managers to somehow 😜
2020-04-24 15:27:29 <ikke> it uses bwrap
2020-04-24 15:27:39 <ikke> but that needs privileges
2020-04-24 15:28:46 <ikke> so it's not ideal
2020-04-24 15:30:03 <PureTryOut[m]> Ah
2020-04-24 15:45:14 <Cogitri> > /home/builder/entrypoint.sh: line 20: sudo: not found
2020-04-24 15:45:14 <Cogitri> My docker-abuild is very unhappy
2020-04-24 15:45:27 <ikke> abuild has no dependency on sudo anymore
2020-04-24 15:45:43 <ikke> so it might got purged f
2020-04-24 15:47:37 <Cogitri> Ah, probably
2020-04-24 15:48:12 <ikke> is docker-abuild itself dependent on sudo?
2020-04-24 15:48:57 <Cogitri> Apparently it tries to use sudo in the container
2020-04-24 15:49:31 <ikke> sudo install
2020-04-24 15:50:42 <ikke> I guess sudo would need to be added here: https://gitlab.alpinelinux.org/alpine/docker-abuild/-/blob/master/Dockerfile.in#L12
2020-04-24 15:50:56 <ikke> or switch to doas
2020-04-24 16:29:18 <maxice8> I wish to push ICU in 30 minutes
2020-04-24 16:29:24 <maxice8> please post any objections in that timeframe
2020-04-24 16:34:02 <Ariadne> lets do it
2020-04-24 16:34:22 <maxice8> not yet
2020-04-24 16:42:33 <maxice8> ok, lets do it
2020-04-24 16:44:44 <maxice8> Ariadne: which commit split should i do to guarantee the builders do not build out-of-order ?
2020-04-24 16:44:45 <maxice8> i am splitting by repo
2020-04-24 16:54:37 <maxice8> huh
2020-04-24 16:54:48 <maxice8> the builders are idle according to build.a.o
2020-04-24 16:54:55 <maxice8> nvm
2020-04-24 16:55:00 <Cogitri> wfm
2020-04-24 17:12:07 <Ariadne> maxice8: icu first
2020-04-24 17:12:09 <Ariadne> maxice8: then deps
2020-04-24 17:12:21 <Ariadne> maxice8: push icu first, then push deps
2020-04-24 17:14:54 <maxice8> i see
2020-04-24 17:14:58 <maxice8> so i would need separate MRs
2020-04-24 17:15:50 <ikke> If you already tested it, then you could just push it
2020-04-24 17:15:52 <ikke> no need for an MR
2020-04-24 17:16:11 <ikke> at 20:00 I'm going to upgrade gitlab
2020-04-24 17:16:28 <maxice8> the point of an MR is to test and have a list of what was merged (merged tag on GItlab) and what didn't make it
2020-04-24 17:16:50 <Hello71> ikke: "instalce" heh
2020-04-24 17:16:54 <ikke> heh
2020-04-24 17:17:24 <ikke> fixed
2020-04-24 17:20:03 <Ariadne> maxice8: yes, two MRs
2020-04-24 17:29:06 <Hello71> couldn't decide between install and instance? :P
2020-04-24 17:29:53 <ikke> I guess so
2020-04-24 18:00:19 <ikke> upgrading gitlab now
2020-04-24 18:00:58 <Cogitri> 👍️
2020-04-24 18:02:35 <ikke> Upgrade is done, gitlab is starting
2020-04-24 18:02:53 <Cogitri> Oh, that was quick
2020-04-24 18:03:56 <ikke> Nice about things being automated
2020-04-24 18:05:33 <ikke> just docker-compose up -d :)
2020-04-24 18:05:38 <ikke> after changing the docker tag
2020-04-24 18:05:55 <ikke> the entrypoint script does the db migrations
2020-04-24 18:12:55 <Cogitri> Fancy
2020-04-24 18:13:12 <ikke> clandmeter built all that :)
2020-04-24 18:14:47 <ikke> ncopa: abuild-keygen still relies on sudo
2020-04-24 18:14:59 <ikke> (with the -i option)
2020-04-24 18:42:09 <ncopa> ikke: ah yes
2020-04-24 18:42:22 <dalias> who's familiar with debugging firefox? :)
2020-04-24 18:42:26 <ncopa> i think the plan was to support sudo
2020-04-24 18:42:38 <ikke> I just found that there is a SUDO env variable that you can use to specify what to use
2020-04-24 18:42:39 <dalias> i think i found a buffer overflow
2020-04-24 18:43:55 <TBK[m]> dalias: think Cogitri is our ff expert
2020-04-24 18:45:33 <dalias> hey cogitri :)
2020-04-24 18:46:09 <dalias> i think some js crap in firefox is accessing memory it didn't ask for
2020-04-24 18:46:30 <dalias> malloc(something_large) then assuming it can access past something_large bytes up to next page boundary or something
2020-04-24 18:50:17 <mps> dalias: this is suspicious, but I don't know how to debug it
2020-04-24 18:50:34 <dalias> well i just want to know what part of the source is responsible
2020-04-24 18:51:00 <dalias> it's something with 1MB alignment hackery going on
2020-04-24 18:54:22 <Cogitri> Huh, valgrind isn't telling you?
2020-04-24 18:54:30 <Cogitri> 
ACTION really wished ASAN on musl was a thing

2020-04-24 18:55:08 <ikke> :D
2020-04-24 18:55:11 <Cogitri> (offtopic, but tell me when I can throw money at someone to make that happen, ASAN is so nice)
2020-04-24 18:55:18 <dalias> well mallocng is telling me :)
2020-04-24 18:55:33 <dalias> but i have no debug sums for libxul
2020-04-24 18:55:34 <Cogitri> And it doesn't give you a backtrace?
2020-04-24 18:55:46 <Cogitri> I can spin you a debug build if that helps
2020-04-24 18:55:49 <dalias> so i'm reading asm trying to guess what code it is from what it's doing
2020-04-24 18:56:27 <dalias> i'd love it if you could just find, based on a few unique lines of asm, what function it is :)
2020-04-24 18:57:07 <ikke> :D
2020-04-24 18:57:14 <Cogitri> I probably can't help with that ^^
2020-04-24 18:57:35 <dalias> http://ix.io/2jo2
2020-04-24 19:00:17 <dalias> hmm i could just find it myself with objdump of a build with symbols
2020-04-24 19:00:23 <dalias> rather than having to install and debug it
2020-04-24 19:00:42 <dalias> i wonder if debian's firefox has debug syms available
2020-04-24 19:02:05 <Cogitri> How would Debian's ff on musl?
2020-04-24 19:02:11 <dalias> i dont want to run it
2020-04-24 19:02:14 <dalias> just rtfasm
2020-04-24 19:02:17 <dalias> with syms
2020-04-24 19:02:24 <Cogitri> And that'd work?
2020-04-24 19:02:26 <dalias> yes
2020-04-24 19:02:34 <Cogitri> Huh, interesting
2020-04-24 19:02:35 <dalias> all i want is to know what the function is
2020-04-24 19:02:42 <Cogitri> I can build FF with debug info in about an hour
2020-04-24 19:02:48 <dalias> rest of the solution will be reading the source and seeing what utterly idiotic thing they did
2020-04-24 19:02:54 <fabrice_d> dalias: is it reproducible easily?
2020-04-24 19:02:59 <dalias> i'm not sure
2020-04-24 19:03:17 <fabrice_d> so how do you plan to reproduce it?
2020-04-24 19:03:19 <dalias> i have a reliable reproduce with resuming my session and loading a particular local-file-load on a particular site
2020-04-24 19:03:28 <dalias> i don't know if it will be easy to reproduce outside that
2020-04-24 19:03:43 <fabrice_d> can't you publish your local file?
2020-04-24 19:03:43 <dalias> and i'd rather not try anything to disturb it until i understand better what it is
2020-04-24 19:13:14 <dalias> cogitri, hold for now
2020-04-24 19:13:24 <dalias> i think i might have a good lead
2020-04-24 19:16:22 <dalias> yay, solved
2020-04-24 19:16:41 <ikke> nice
2020-04-24 19:29:24 <dalias> fixed in https://github.com/richfelker/mallocng-draft/commit/f571c115fe843ed5faeb43eb2bd875390cb3d1b6
2020-04-24 19:31:23 <Hello71> dalias: machine learning ;)
2020-04-24 19:33:35 <TBK[m]> dml?
2020-04-24 19:35:31 <dalias> doh just had another crash and was like >_<
2020-04-24 19:35:53 <dalias> but it was just firefox segfaulting on OOM because I still had a 1GB less process open reading objdump :-p
2020-04-24 19:36:29 <dalias> i love how it doesn't even report that it's crashing because OOM but just derefs the return value of malloc and blows up
2020-04-24 19:37:04 <Hello71> something something overcommit something
2020-04-24 19:42:34 <dalias> :)
2020-04-24 19:43:37 <dalias> actually i really love having firefox just disappear then restore my tabs (and even wip forms) when i restart it, rather than having the box freeze up swapping for minutes at a time while i wait for ctrl+alt+f2 and login and killall -9 firefox to go thru
2020-04-24 19:48:00 <mps> uhm, ncurses is not in good shape. do we need --with-terminfo-dirs="/lib/terminfo:/usr/lib/terminfo"
2020-04-24 19:48:32 <mps> are the "/etc/terminfo:/usr/share/terminfo" enough
2020-04-24 19:51:06 <Hello71> dalias: alt sysrq f
2020-04-24 19:53:58 <dalias> i normally dont enable magic sysrq because it's unauthenticated and can break stuff easily if done accidentally or by a clown at locked console
2020-04-24 20:06:35 <Hello71> I think it's pretty hard to accidentally press alt and sysrq, they're on opposite sides of the keyboard
2020-04-24 20:06:40 <Hello71> I think altgr doesn't work
2020-04-24 20:06:51 <Hello71> you could script it to disable it when the screen is locked
2020-04-24 20:06:55 <Ariadne> on US keyboards, there is no altgr
2020-04-24 20:09:20 <dalias> ariadne, rightalt is the same thing
2020-04-24 20:09:54 <dalias> magic sysrq doesn't respect keymaps anyway afaik, and i think it only accepts leftalt
2020-04-24 20:10:14 <ikke> WHat if your keyboard does not have sysrq?
2020-04-24 20:10:27 <Ariadne> right-alt does not use same keycode as left-alt?
2020-04-24 20:11:00 <dalias> ariadne, of course not. if it did you couldn't use right-alt as altgr (which all good keymaps do)
2020-04-24 20:11:41 <Hello71> U! S! A! U! S! A!
2020-04-24 20:12:18 <Hello71> ikke: how do you take screenshots then
2020-04-24 20:12:25 <Hello71> I guess nowadays people open snipping tool manually
2020-04-24 20:13:25 <ikke> Hello71: screenshot tool :)
2020-04-24 20:13:56 <Hello71> I think macs and chromebooks don't have prtsc but windows computers should have it
2020-04-24 20:14:03 <Hello71> "pc compatible"
2020-04-24 20:22:21 <mps> hm, didn't know that 'mv' creates symlinks
2020-04-24 20:23:17 <ikke> does it?
2020-04-24 20:23:48 <mps> busybox mv does
2020-04-24 20:23:54 <mps> just found that
2020-04-24 20:24:18 <ikke> how / when does it create symlinks
2020-04-24 20:24:18 <mps> 'mkdir -p pkg/ncurses-terminfo/usr/share'
2020-04-24 20:24:37 <mps> 'mv pkg/ncurses/usr/lib/terminfo pkg/ncurses-terminfo/usr/share'
2020-04-24 20:25:27 <mps> 'ls -l pkg/ncurses-terminfo/usr/share/' => rwxrwxrwx    1 mps      mps             17 Apr 24 22:23 terminfo -> ../share/terminfo
2020-04-24 20:25:41 <mps> or, I don't understand something
2020-04-24 20:27:42 <ikke> and you are sure that symlink wasn't already there?
2020-04-24 20:28:33 <Hello71> cp makes symlinks if you pass -s
2020-04-24 20:28:44 <mps> coreutils mv is more verbose: renamed 'pkg/ncurses/usr/lib/terminfo' -> 'pkg/ncurses-terminfo/usr/share/terminfo'
2020-04-24 20:29:01 <mps> Hello71: no, as I typed above
2020-04-24 20:30:19 <mps> hmm, very strange
2020-04-24 20:30:45 <mps> ohm, maybe because I run it on overlay FS for lxc builder
2020-04-24 20:31:41 <mps> lxc config: lxc.mount.entry = /home/mps/aports home/mps/aports none rw,bind 0 0
2020-04-24 20:31:45 <mps> heh
2020-04-24 20:32:21 <mps> every day learning something new, life is not so boring :)
2020-04-24 20:32:48 <mps> that could be problem on our builders too
2020-04-24 20:35:54 <ikke> never noticed that, I'm using an lxc container as well
2020-04-24 20:36:46 <mps> hm, same on native build
2020-04-24 20:37:06 <mps> looks like it is not related to lxc bind mount
2020-04-24 20:37:34 <mps> do we have 'mv' helper in abuild?
2020-04-24 20:37:55 <ncopa> dalias: congrats with the mallocng fix for firefox. you are awesome!
2020-04-24 20:38:15 <ikke> mps: no
2020-04-24 20:39:24 <mps> huh, what could be then, some of my aliases
2020-04-24 20:41:16 <mps> no, unaliased it and same behavior
2020-04-24 20:50:13 <ncopa> maxice8: as mentioned in wrong channel (#alpine-infra) b6a2cf9a9fe21b1d060039b1ee5dbf95bd727bf9 breaks bootstrapping 3.12 builders because build time dependencies does not understand provides
2020-04-24 20:51:49 <ncopa> actually, it is f8d794bdba10e8fbc987b8879b1ab130aeea3b1a that breaks it
2020-04-24 20:52:00 <ikke> Is there a reason to call it mpfr4, rather than just mpfr (like upstream)
2020-04-24 20:52:14 <mps> ikke: found it, orig dir is actually symlink.
2020-04-24 20:52:30 <mps> now I can fix ncurses
2020-04-24 20:52:32 <ikke> mps: right, so the symlink was already there
2020-04-24 20:53:40 <mps> yes, didn't looked carefully. sorry for annoyance
2020-04-24 20:53:45 <ikke> no problem
2020-04-24 20:54:32 <ncopa> ikke: the reason is so we can do major, ABI breaking upgrades without breaking gcc
2020-04-24 20:54:56 <mps> now ncurses-terminfo will actually not be empty ;)
2020-04-24 20:55:23 <ncopa> we needed to have separate aport for mpfr3 and mpfr4 when we upgraded to mpfr4
2020-04-24 20:55:26 <ikke> ok, so we want to have multiple versions in the rep
2020-04-24 20:55:29 <ikke> got it
2020-04-24 20:55:35 <ncopa> only for a short time
2020-04-24 20:55:36 <mps> only not sure do we need /usr/lib/terminfo link to /usr/share/terminfo
2020-04-24 20:55:44 <ikke> yes
2020-04-24 20:55:59 <ncopa> only til gcc is successfully built and upgraded on all builders
2020-04-24 21:00:01 <ncopa> maxice8: we need to either name mpfr[0-9] package's -dev for mpfr-dev, or use mpf4-dev update makedepends on every ABI breaking upgrade for all consumers (gcc and mpc1) or (fix lua-aports to consider provides *and* make it possible to specify provides for subpbackages in global scope)
2020-04-24 21:01:25 <dalias> ncopa, thanks :)
2020-04-24 21:01:53 <ncopa> we may want make lua-aports consider provides, but it does not solve our problem at hand, since the provides is set in subpackage (-dev) in this case, which means that it is impossible to know the provides til until after package is built -> meaning it is not possible to calculate build order (since it needs to be built already to calculate build
2020-04-24 21:01:53 <ncopa> order)
2020-04-24 21:02:03 <dalias> took a lot longer than i would have liked, because i didn't look at things as carefully as i should have and spent more time trying to read the firefox disasm than reading the mallocng data structure in the crashed process
2020-04-24 21:02:15 <ncopa> ha, i know the feeling
2020-04-24 21:05:47 <dalias> i do like tho how all the mallocng bugs have been "trapping when it shouldn't" rather than "failure to give the caller what it asked for" (like all the old original musl malloc ones were)
2020-04-24 21:13:01 <ncopa> indeed
2020-04-25 00:31:45 <TBK[m]> maxice8: !7184 & !7188
2020-04-25 00:32:35 <maxice8> I saw, thanks for fixing them
2020-04-25 00:34:05 <TBK[m]> I am going to make the backport MRs for ntfs-3g and then head to bed.
2020-04-25 00:34:22 <maxice8> alright, good luck
2020-04-25 09:19:41 <Cogitri> Can someone with main bits look at !7202 please? The last two pixman commits removed a patch we needed which caused some crashing in GNOME
2020-04-25 09:20:19 <Cogitri> I set the pkgrel to 1 so users which upgrade to pixman 0.40 already with pkgrel=0 get upgraded too
2020-04-25 10:26:53 <ikke> Cogitri: why does the MR only delete patches?
2020-04-25 10:28:27 <Cogitri> Hm?
2020-04-25 10:28:42 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7202/diffs
2020-04-25 10:29:06 <Cogitri> I still don't get what you mean
2020-04-25 10:29:20 <Cogitri> It also bumps pixman, enables tests, set stacksize etc.
2020-04-25 10:29:45 <ikke> You said that patches were removed that you need, yet, the MR itself is deleting patches
2020-04-25 10:31:25 <Cogitri> Ah yes, the patch to reduce stacksize was deleted in aca640da654a97c6ad6f9423beda707cd14c8a42 and doesn't apply anymore. As such that MR just increase the default stacksize until we have a proper fix in pixman (meaning it increases the stacksize itself)
2020-04-25 10:32:10 <Cogitri> And the GNOME Software patch isn't required anymore, that just disabled showing icons since that SIGSEGVs pixman with smaller stacksizes
2020-04-25 10:32:36 <ikke> Ok, was just confused by your description of the MR and what it actually
2020-04-25 10:32:38 <ikke> did
2020-04-25 10:33:29 <ikke> Do you mean upstream removed those patches?
2020-04-25 10:33:38 <Cogitri> Ah, sorry. Currently doing things for Java class so my brain is already in off mode :D
2020-04-25 10:33:54 <ikke> hehe
2020-04-25 10:34:13 <Cogitri> No, maxice8 removed the patch in the progress of bumping pixman to 0.38.4 -> 0.40 because it didn't apply anymore
2020-04-25 10:34:29 <Cogitri> The patch decreased the required stacksize
2020-04-25 10:34:45 <Cogitri> So without that (downstream) patch the requried stacksize got bigger than the default musl has
2020-04-25 10:35:05 <Cogitri> So pixman blew up when you asked it to render many SVG images
2020-04-25 10:35:15 <ikke> ah ok, but instead of restoring the patch, you just do it through LDFLAGS
2020-04-25 10:35:26 <Cogitri> (Which happens in places like GNOME Software which displays all images of installed applications)
2020-04-25 10:35:50 <Cogitri> Yes, the patch doesn't apply anymore and  I didn't feel comfortable getting it working again, pixman is scary
2020-04-25 10:36:00 <ikke> hehe
2020-04-25 10:36:26 <Cogitri> And making the default stacksize bigger for pixman wont hurt either way, the way for upstream to fix this probably is to set the default stacksize to a higher value themselves
2020-04-25 10:37:22 <ikke> It's set to merge after CI finishes
2020-04-25 10:38:35 <Cogitri> Thank you :)
2020-04-25 10:38:58 <Cogitri> Back to massaging javac
2020-04-25 10:39:13 <ikke> I'm happy I don't have to do any java anymore for school :P
2020-04-25 10:40:33 <Cogitri> I was happy that I never had to touch Java before this semester either, but apparently I'll need it for next semester's android programming class too :^)
2020-04-25 10:40:44 <Cogitri> How I wished we could at least use Kotlin or anything that wasn't Java
2020-04-25 10:40:49 <Cogitri> I'd rather do C++ at this point
2020-04-25 10:42:21 <mps> 'apk info -r sysfsutils-doc' sysfsutils-doc-2.1.0-r8 is required by: sysfsutils-dev-2.1.0-r8
2020-04-25 10:42:45 <mps> anyone know why?
2020-04-25 10:45:19 <TBK[m]> not sure what is going on, but the license info and build dates are all over the place https://pkgs.alpinelinux.org/packages?name=sysfsutils&branch=edge
2020-04-25 10:49:29 <mps> and latest release is dated: v. 2.1.0 - August 23, 2006
2020-04-25 10:50:44 <mps> only 4 pkgs make/depends on it
2020-04-25 11:05:02 <TBK[m]> mps: it has seen development recently https://github.com/linux-ras/sysfsutils
2020-04-25 11:28:00 <ncopa> source url fof xz seems to be gone
2020-04-25 11:28:09 <ncopa> https://tukaani.org/xz
2020-04-25 11:29:05 <ikke> https://repology.org/project/xz/information
2020-04-25 11:29:35 <ikke> There is one on sourceforge apparently
2020-04-25 11:30:24 <TBK[m]> and GH - https://github.com/xz-mirror/xz
2020-04-25 11:30:49 <mps> TBK[m]: ah, good that you found it. looks like it is moved for now but that is good sign that it will be continued probably
2020-04-25 11:43:11 <ncopa> Cogitri: 36233eccb51bfeb10849dad83453aa2af49d451a introduces a circular dependency
2020-04-25 11:43:20 <ncopa> ERROR: unsatisfiable constraints:
2020-04-25 11:43:20 <ncopa>   tcl-dev (missing):
2020-04-25 11:43:20 <ncopa>     required by: .makedepends-sqlite-20200425.113851[tcl-dev]
2020-04-25 11:43:35 <ncopa> i cannot build sqlite now because tcl is not yet built
2020-04-25 11:43:54 <ncopa> and i cannot build tcl because sqlite is not yet built
2020-04-25 11:44:28 <ncopa> i think we need a separate aport for sqlite-tcl
2020-04-25 11:44:49 <Cogitri> Oh huh
2020-04-25 11:44:53 <Cogitri> Sorry about that
2020-04-25 11:45:00 <ncopa> np. it happens...
2020-04-25 11:45:12 <Cogitri> I think we could build tcl against a static version of sqlite it builds itseld too
2020-04-25 11:45:53 <ncopa> it bundles sqlite?
2020-04-25 11:45:58 <ncopa> looks like it does
2020-04-25 11:46:10 <ncopa> thats another option
2020-04-25 11:46:44 <ncopa> we can either build tcl with bundled/static(?) sqlite or add a separate sqlite-tcl/APKBUILD
2020-04-25 11:47:15 <ncopa> separate sqlite-tcl means we need to bump version in sync with sqlite
2020-04-25 11:47:28 <ncopa> similar to what we do with python2-tkinter
2020-04-25 11:47:49 <ncopa> and similar to what we do with the qt5-qt*
2020-04-25 11:47:57 <Cogitri> I guess the latter approach is a bit cleaner
2020-04-25 11:48:05 <ncopa> i think so
2020-04-25 11:48:42 <ncopa> i think thats what i'd prefer, but i dont have that strong opinion here
2020-04-25 11:52:19 <TBB> as a Tcl heavy user, yeah, definitely the latter
2020-04-25 11:52:51 <ncopa> Cogitri: can you help me with that?
2020-04-25 11:52:58 <ncopa> i need to go out for a while
2020-04-25 12:03:44 <Cogitri> I can do that later today
2020-04-25 12:04:05 <Cogitri> TBB: Maybe you want to help with this then?
2020-04-25 12:41:04 <TBK[m]> ganwell: ?
2020-04-25 12:42:39 <TBK[m]> k
2020-04-25 12:43:00 <ikke> confusing, both a TBK and a TBB :)
2020-04-25 12:44:08 <TBK[m]> Cogitri: any objections to me pulling the thunderbird MR?
2020-04-25 12:44:35 <TBK[m]> says the "fake" _ikke_ :P
2020-04-25 12:44:40 <ikke> :)
2020-04-25 12:50:16 <TBK[m]> btw ikke nebula (noise framework based) might be of interest to infra as an alternative to dmvpn.
2020-04-25 13:20:48 <Cogitri> TBK[m]: pull as in merge?
2020-04-25 13:21:41 <TBK[m]> Cogitri: yes. sorry about the vague formulation.
2020-04-25 13:23:32 <mps> TBK[m]: what 'keeps' nheko MR merging
2020-04-25 13:28:58 <TBK[m]> mps: I do not follow.
2020-04-25 13:29:22 <mps> aren't you created MR?
2020-04-25 13:29:45 <mps> sorry if I'm wrong
2020-04-25 13:30:02 <TBK[m]> I created the last upgrade MR.
2020-04-25 13:30:04 <Cogitri> TBK[m]: I guess the fix is the same as for ff-esr, so it's fine by me
2020-04-25 13:30:27 <TBK[m]> Cogitri: yes, it is exactly the same.
2020-04-25 13:30:58 <mps> ah, I wanted to merge it but was not sure why you didn't
2020-04-25 13:43:22 <Ganwell> #freenode_#alpine-user:matrix.org
2020-04-25 13:44:06 <Ganwell> sorry. copy-paste err
2020-04-25 14:45:05 <mps> any explanation/guide/doc how scandeps work in abuild
2020-04-25 14:49:57 <minecrell> TBK[m]: Anything else I should change in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7126? :D
2020-04-25 15:05:32 <[[sroracle]]> mps: other than the source, no
2020-04-25 15:05:54 <[[sroracle]]> mps: i can try to answer a question if you have one though, i have studied it extensively before
2020-04-25 15:07:22 <mps> [[sroracle]]: i have problem with splitting ncurses to ncurses-terminfo, it works bu the result is the ncurses depened on ncurses-terminfo
2020-04-25 15:07:37 <mps> probably have to look at scan_symlink_targets() in abuild
2020-04-25 15:08:20 <minecrell> TBK[m]: ah, I guess not. Thank you :)
2020-04-25 15:09:36 <TBK[m]> minecrell: np :)
2020-04-25 15:16:35 <[[sroracle]]> mps: do you have an APKBUILD i can look at
2020-04-25 15:17:05 <mps> yes, I can paste it in 15 minutes
2020-04-25 15:33:01 <mps> [[sroracle]]: here is APKBUILD http://tpaste.us/Jx5g
2020-04-25 15:34:44 <mps> and 'apk info -R ncurses' shows that it depends on ncurses-terminfo
2020-04-25 15:48:17 <mps> [[sroracle]]: I fixed it with hack in package() adding 'rm -f $pkgdir/usr/lib/terminfo' at the end of this function
2020-04-25 15:48:32 <mps> though not sure is this correct way
2020-04-25 16:49:01 <[[sroracle]]> this split seems pretty wacky to me
2020-04-25 16:49:29 <[[sroracle]]> why is terminfo-base installing to /etc
2020-04-25 16:51:21 <[[sroracle]]> but yeah simply removing the symlink would of course work. it would break things if it's actually needed though...
2020-04-25 16:52:17 <[[sroracle]]> instead you could ensure there is an empty share/terminfo dir in the main package, or just move the symlink to the terminfo subpkg
2020-04-25 16:53:39 <mps> looking through pkgs I didn't find any needing /usr/lib/terminfo, but not 100% sure if I looked carefully enough
2020-04-25 16:54:15 <mps> and /lib/terminfo
2020-04-25 16:55:48 <mps> and terminfo-base to /etc/terminfo is for backward compatibility (just in case, I think)
2020-04-25 17:34:00 <dalias> updating linux package always forces update of ~90 firmware packages for things i don't use and will never use. what's the right way to avoid this?
2020-04-25 17:34:19 <ikke> apk add linux-firmware-none
2020-04-25 17:34:32 <dalias> and then just individually add the ones i want?
2020-04-25 17:34:36 <ikke> yes
2020-04-25 17:34:41 <dalias> nice. thanks.
2020-04-25 17:35:10 <dalias> just need to figure out which one i do need
2020-04-25 17:35:23 <dalias> i wonder if kernel updates atime when it loads them :)
2020-04-25 17:35:25 <ikke> There is some oneliner to figure this out
2020-04-25 17:35:46 <dalias> existing solution would of course work :)
2020-04-25 17:37:07 <mps> modinfo `lsmod | grep -v Module | awk -e '{ print $1}'` | grep firmware
2020-04-25 17:37:10 <mps> :)
2020-04-25 17:37:13 <ikke> mps: ah, thanks
2020-04-25 17:41:08 <mps> this is little better: modinfo `lsmod | grep -v Module | awk -e '{ print $1 }'` | grep ^firmware
2020-04-25 17:50:07 <dalias> ah
2020-04-25 18:03:38 <mps> [[sroracle]]: looking adelie ncurses APKBUILD https://code.foxkit.us/adelie/packages/blob/master/system/ncurses/APKBUILD
2020-04-25 18:04:40 <mps> it is without lib/terminfo and /usr/lib/terminfo in ./configure
2020-04-25 18:05:52 <[[sroracle]]> mps: afaik none of the splits for it have been touched since it was introduced in 2018ish
2020-04-25 18:06:20 <mps> also, there is 'mv $pkgdir/usr/share/terminfo $subpkgdir/usr/share' and not 'mv $pkgdir/usr/lib/terminfo $subpkgdir/usr/lib' as it is in current alpine APKBUILD
2020-04-25 18:06:57 <[[sroracle]]> is there a reason to prefer /usr/lib over /usr/share? i'm not familiar with this stuff
2020-04-25 18:06:58 <mps> looks like some 'merging' would be good
2020-04-25 18:07:14 <mps> no
2020-04-25 18:07:29 <[[sroracle]]> then it's probably fine
2020-04-25 18:07:32 <mps> I think ib/terminfo and /usr/lib/terminfo is not needed also for alpine
2020-04-25 18:07:44 <TBK[m]> ikke: can I get you to unlock !7197
2020-04-25 18:07:47 <TBK[m]> ?
2020-04-25 18:08:05 <mps> hmm, /lib/terminfo*
2020-04-25 18:08:22 <ikke> TBK[m]: done
2020-04-25 18:08:27 <TBK[m]> ikke: thanks
2020-04-25 18:08:33 <[[sroracle]]> i think what we actually need to fix is the dependencies between terminfo, terminfo-base, and the other packages (which i think you've been doing)
2020-04-25 18:08:35 <mps> ok, will create MR when I come back to home
2020-04-25 18:09:03 <mps> for review, ofc
2020-04-25 18:40:08 <maxwell-k> anyone got suggestions on how to handle this error message from CI (ppc64le)?
2020-04-25 18:40:32 <maxwell-k>  fatal: unable to access 'https://gitlab.alpinelinux.org/alpine/aports/': Failed to connect to gitlab.alpinelinux.org port 443: Operation timed out
2020-04-25 18:41:22 <TBK[m]> maxwell-k: it is flaky, just restart the job
2020-04-25 18:41:47 <ikke> retry, there are some unknown network issues with that host
2020-04-25 18:42:08 <maxwell-k> ty, I will keep trying
2020-04-25 18:42:41 <maxwell-k> I'd be a bit more patient only a dependency isn't available on ppc64le so I just had to change 3 A
2020-04-25 18:42:48 <maxwell-k> PKBUILDs :)
2020-04-25 18:43:34 <maxwell-k> oooh, spoke too soon I am past that error :-)
2020-04-25 18:43:37 <maxwell-k> thanks both
2020-04-25 18:46:50 <mps> [[sroracle]]: I create !7221 MR for ncurses
2020-04-25 18:47:18 <mps> please anyone can look and comment
2020-04-25 18:54:22 <[[sroracle]]> mps: here's your reason https://gitlab.alpinelinux.org/alpine/aports/-/commit/e773ffa89a7b52f56f5cdbce5d3ab6518a192e8d
2020-04-25 18:54:33 <[[sroracle]]> "This is so statically compiled binaries works on distros where terminfo is installed in /lib/terminfo (like ubuntu)"
2020-04-25 18:54:57 <[[sroracle]]> so probably want to undo that bit
2020-04-25 18:54:59 <mps> uhh
2020-04-25 18:55:32 <mps> I missed that
2020-04-25 18:57:04 <mps> how it works on adelie, there is no /lib/terminfo in .configure
2020-04-25 18:57:29 <[[sroracle]]> nobody has built a static executable on adelie with ncurses then tried to run it on another distro presumably
2020-04-25 18:57:39 <[[sroracle]]> so it is probably broken but nobody cares
2020-04-25 18:59:09 <mps> nice :)
2020-04-25 18:59:18 <mps> I will revert this
2020-04-26 08:27:32 <markand> hello
2020-04-26 08:27:43 <oneinsect> hi
2020-04-26 08:27:59 <markand> I'm trying to package a software that links to libasound, it fails to find a reference to a function
2020-04-26 08:28:09 <markand> /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: src/drivers/amsynth-ALSAmmapAudioDriver.o: in function `ALSAmmapAudioDriver::open()':
2020-04-26 08:28:12 <markand> ALSAmmapAudioDriver.cpp:(.text+0x5c0): undefined reference to `snd_pcm_hw_params_set_rate_near@ALSA_0.9'
2020-04-26 08:28:54 <markand> it's declared in /usr/include/alsa/pcm.h
2020-04-26 08:29:04 <oneinsect> https://git.busybox.net/buildroot/patch/?id=97b392b98468859ab2366995b6bee4140b38e388
2020-04-26 08:29:09 <markand> but pcm_old.h also declares this: /usr/include/alsa/pcm_old.h:asm(".symver snd_pcm_hw_params_set_rate_near,snd_pcm_hw_params_set_rate_near@ALSA_0.9");
2020-04-26 08:29:36 <markand> oneinsect, that was quick :P
2020-04-26 08:29:45 <oneinsect> lol
2020-04-26 08:29:55 <TBK[m]> oneinsect to the rescue :)
2020-04-26 08:30:11 <oneinsect> a mere devotee among you all gods of alpine
2020-04-26 08:30:13 <oneinsect> that is me
2020-04-26 08:30:41 <TBK[m]> hehe
2020-04-26 08:30:41 <markand> I may still add an issue upstream for my problematic software
2020-04-26 08:30:54 <oneinsect> sure
2020-04-26 08:42:29 <markand> https://github.com/amsynth/amsynth/issues/156 et hop
2020-04-26 08:43:36 <oneinsect> thank you
2020-04-26 08:43:52 <oneinsect> will help me during the alpine glibc port
2020-04-26 17:02:59 <maxice8> Any opinons on !6271 ? If no feedback is given I'll merge it as soon as 3.12 is branched off
2020-04-26 18:56:39 <AinNero> > I think we should keep it with meson, as meson changes more quickly than abuild.
2020-04-26 18:56:42 <AinNero> whelp
2020-04-26 18:57:12 <maxice8> Yes ?
2020-04-26 18:57:14 <AinNero> looks like a good idea to me
2020-04-26 18:57:23 <AinNero> like, splitting it off from the template
2020-04-26 18:57:32 <AinNero> meson changing is ofc a shitty thing
2020-04-26 18:57:39 <AinNero> but thats how things are for now
2020-04-26 18:58:33 <maxice8> Until we get a perfect build system that is how things are gonna be
2020-04-26 18:58:54 <Cogitri> And meson isn't changing that much at least in the CLI anymore
2020-04-26 19:02:20 <artok> ok now you've repeated meson so many times that I need to take good look on thagt
2020-04-26 19:04:23 <Cogitri> Meson's nice
2020-04-26 19:04:54 <Cogitri> Ariadne: Can you take a look at !7262 on mips(64?) apparently they fixed mips64: https://webkitgtk.org/2020/04/24/webkitgtk2.28.2-released.html?
2020-04-26 21:08:07 <andypost[m]> Looks gitlab has issues https://gitlab.alpinelinux.org/J0WI/aports/-/jobs/102937
2020-04-26 21:08:49 <ikke> andypost[m]: known issues with the ppc64le host
2020-04-26 21:08:55 <ikke> some unknown network issue
2020-04-26 21:10:35 <andypost[m]> ikke thanks, good to know
2020-04-26 21:19:52 <PureTryOut[m]> !7163 is ready for merging
2020-04-26 21:31:19 <TBK[m]> Cogitri: did you work on packaging electron?
2020-04-26 21:53:01 <ikke> Would be nice if we could somehow specify in CI that failing artifact uploads does not fail the job
2020-04-26 22:30:29 <maxice8> docs.v.o is super good
2020-04-26 22:32:28 <mps> maxice8: are you on wrong channel :)
2020-04-26 22:33:01 <maxice8> yes it is hard to distinguish in nheko
2020-04-27 05:31:24 <Cogitri> TBK[m]: Yes, it works on musl now, but electron's build system is very... interesting
2020-04-27 06:25:18 <Cogitri> I guess I should take another look at it though, having electron in our repos would be pretty neato
2020-04-27 06:35:27 <ncopa> morning!
2020-04-27 06:35:43 <ncopa> i hope y'all had a good weekend
2020-04-27 06:36:14 <ncopa> i have done good progress with the 3.12 builders
2020-04-27 06:36:28 <ncopa> bumped into this now:
2020-04-27 06:36:29 <ncopa> libxml2-CVE-2020-7595.patch: FAILED
2020-04-27 06:36:29 <ncopa> sha512sum: WARNING: 1 of 1 computed checksums did NOT match
2020-04-27 06:37:27 <ncopa> source=" .... libxml2-CVE-2020-7595.patch::https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c8907645d2e155f0d89d4d9895ac5112b5.patch"
2020-04-27 06:37:40 <Cogitri> Morning
2020-04-27 06:37:57 <ncopa> apparently gitlab modifies the files one way or the other
2020-04-27 06:38:20 <Cogitri> Huh, that's weird
2020-04-27 06:38:57 <ncopa> i'd guess it header or footer of the patch
2020-04-27 06:39:03 <ncopa> like git version or similar
2020-04-27 06:39:24 <ncopa> yup
2020-04-27 06:39:57 <ncopa> they generate the patch on the fly
2020-04-27 06:41:30 <ncopa> this is the change: http://tpaste.us/V4Wv
2020-04-27 06:42:53 <Cogitri> Oh, the git version changed
2020-04-27 06:42:57 <Cogitri> Makes sense, I guess
2020-04-27 07:03:32 <oneinsect> ncopa: are you here?
2020-04-27 07:04:01 <oneinsect> https://dev.alpinelinux.org/~ncopa/alpine/ i see you have pkgbuild-to-apkbuild  and ebuild-to-apkbuild
2020-04-27 07:04:05 <ikke> oneinsect: you just saw ncopa talking here :)
2020-04-27 07:04:06 <oneinsect> do they still work?
2020-04-27 07:04:31 <oneinsect> they are 2009 and 2010
2020-04-27 07:04:38 <oneinsect> almost a decade old
2020-04-27 07:04:41 <oneinsect> from*
2020-04-27 07:05:02 <ikke> Easy way to find out is to just try them
2020-04-27 07:05:11 <oneinsect> heeheee
2020-04-27 07:41:31 <oneinsect> https://fedoraproject.org/wiki/Features/UsrMove
2020-04-27 07:41:47 <oneinsect> are we moving in that direction for moving directories?
2020-04-27 07:42:12 <ikke> There are no concrete plans as of yet, just proposals
2020-04-27 07:42:20 <ikke> and it's a bit controversial
2020-04-27 07:42:46 <mps> yes, we should move to fedora :P
2020-04-27 07:43:09 <oneinsect> Lol
2020-04-27 07:43:31 <oneinsect> i mean just now have mostly 4 top directories
2020-04-27 07:44:13 <oneinsect>  and /sbin -> usr/sbin and
2020-04-27 07:44:13 <oneinsect>  /bin -> usr/bin
2020-04-27 07:44:13 <oneinsect>  and /lib64 -> usr/lib64
2020-04-27 07:44:33 <oneinsect> lib -> usr/lib
2020-04-27 07:44:37 <oneinsect> so only 4
2020-04-27 07:44:40 <ikke> There is even discussion about the direction of the merge
2020-04-27 07:44:45 <ikke> some propose the other way around
2020-04-27 07:45:06 <ikke> https://lists.alpinelinux.org/~alpine/devel/%3Cc2724fbe-e308-bcc9-e789-b3f657355d3d%40gmail.com%3E
2020-04-27 07:45:44 <oneinsect> hmmm
2020-04-27 07:46:59 <mps> people like useless work
2020-04-27 07:47:48 <oneinsect> lol
2020-04-27 08:35:11 <ncopa> oneinsect: i dont think they are useful anymore
2020-04-27 08:57:20 <oneinsect> thanks ncopa
2020-04-27 08:57:38 <oneinsect> i wish you have time to upgrade them
2020-04-27 09:05:38 <ncopa> imho they have fulfilled their purpose long time ago
2020-04-27 09:06:31 <ncopa> pkgbuild and ebuilds are different enough, so i dont think it makes much sense to try convert those to APKBUILD
2020-04-27 09:06:43 <oneinsect> no issues
2020-04-27 09:47:40 <Cogitri> Anyone wants to take over maintaince for ponyc before I go ahead with !7273 ?
2020-04-27 10:32:43 <mps> fabled: if you remember I wrote here about problem with apk on armv7 running on f2fs as root FS and kernel 5.6 and up
2020-04-27 10:33:10 <mps> problem is solved in kernel 5.6.7, so no apk issue, all is ok now
2020-04-27 10:49:08 <oneinsect> small issue
2020-04-27 10:49:18 <oneinsect> on a fresh prestine system, without any packages
2020-04-27 10:49:26 <oneinsect> when i first do apk add -t zlib
2020-04-27 10:49:40 <oneinsect> it only adds the entry to /etc/apk/world
2020-04-27 10:49:54 <oneinsect> but doesnt populate /usr/lib/apk/db/installed
2020-04-27 10:49:58 <oneinsect> is this a bug?
2020-04-27 10:51:42 <ikke> maxice8: Cogitri shouldn't python3 provide /usr/bin/python now? Or was that reverted
2020-04-27 10:59:04 <Cogitri> That was reverted I think
2020-04-27 10:59:07 <ikke> ok
2020-04-27 10:59:16 <Cogitri> I think that was deemed too much breakage for 3.12
2020-04-27 10:59:31 <Cogitri> Python2 doesn't provide the python package anymore though
2020-04-27 10:59:56 <Cogitri> (Neither does python3 now IIRC, so you have to explicitly choose what python version you want)
2020-04-27 10:59:58 <ikke> right, so you have to explicitly choose py2 or py3 now
2020-04-27 11:00:04 <ikke> which is good
2020-04-27 11:00:46 <Cogitri> Yup
2020-04-27 11:12:05 <PureTryOut[m]> I'm trying to package a Python application, but it fails with `PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.8/site-packages/evdev-1.3.0-py3.8.egg-info/PKG-INFO'`. This comes from `py3-evdev` which I just packaged fine, but I'm unsure what it's trying to do here that makes it fail
2020-04-27 11:24:06 <Cogitri> Maybe you forgot to add that package as dependency and it tries to install it with pip now?
2020-04-27 11:29:52 <fabled> mps, ok. thanks for the update!
2020-04-27 11:34:46 <ncopa> Ariadne:  https://distfiles.dereferenced.org curl: (60) SSL certificate problem: certificate has expired
2020-04-27 11:39:27 <PureTryOut[m]> Cogitri: nope that is not the case, it's there in the deps
2020-04-27 11:42:36 <ikke> When does it give that error?
2020-04-27 11:44:52 <Cogitri> A full build log would be helpful
2020-04-27 11:54:43 <Ariadne> ncopa: renewed
2020-04-27 11:56:38 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/gaDNpViuqmZRwHLcmBWMChPT >

2020-04-27 11:56:40 <PureTryOut[m]> Full build log ^
2020-04-27 11:56:40 <PureTryOut[m]> happens in build() fase
2020-04-27 11:58:22 <ikke> sudo apk add utils-linux; abuild deps; namei -om /usr/lib/python3.8/site-packages/evdev-1.3.0-py3.8.egg-info/PKG-INFO
2020-04-27 12:00:18 <ikke> (maybe sudo namei ...)
2020-04-27 12:00:20 <Cogitri> Seems like it's not allowed to read the file so I guess we have bad permissions on that thing
2020-04-27 12:00:31 <ikke> yeah, my conclusion as well
2020-04-27 12:00:39 <ikke> hence the namei to find out the permissions
2020-04-27 12:00:47 <PureTryOut[m]> Everything owned by root and chmod, except for PKG-INFO which is 640
2020-04-27 12:00:55 <PureTryOut[m]> *chmod 755, except for PKG-INFO which is 640
2020-04-27 12:01:02 <ikke> well, that's not good then
2020-04-27 12:01:03 <Cogitri> So non root can't read that file
2020-04-27 12:01:09 <PureTryOut[m]> Seems the other packages have that as 644
2020-04-27 12:01:10 <ikke> should be 644
2020-04-27 12:01:28 <PureTryOut[m]> Any clue why that would happen?
2020-04-27 12:01:30 <ikke> 640 means only readable by owner/group
2020-04-27 12:01:54 <ikke> You have to verify the packaging of evdev
2020-04-27 12:02:01 <PureTryOut[m]> I know what it means 😉
2020-04-27 12:02:22 <ikke> :)
2020-04-27 12:02:27 <PureTryOut[m]> It's just a regular package like any other... Installs stuff with `python3 setup.py install --prefix=/usr --root="$pkgdir"`
2020-04-27 12:02:37 <ikke> I help a lot of new users, so I tend to over-explain things from time to time :)
2020-04-27 12:03:04 <ikke> Is it already 640 in the pkg dir of evdev
2020-04-27 12:03:07 <ikke> ?
2020-04-27 12:03:56 <PureTryOut[m]> :q
2020-04-27 12:04:03 <ikke> /kick PureTryOut[m] ;-)
2020-04-27 12:04:19 <PureTryOut[m]> Woops wrong window lol
2020-04-27 12:04:25 <PureTryOut[m]> No directory is 755 still
2020-04-27 12:04:36 <ikke> it's about the PKG-INFO file
2020-04-27 12:07:02 <PureTryOut[m]> Yeah it's directory is 755 but the file is 640
2020-04-27 12:07:20 <ikke> so apparently setup.py is doing something wrong then
2020-04-27 12:56:20 <Cogitri> <Cogitri "Ariadne: Can you take a look at "> ^
2020-04-27 12:57:03 <Ariadne> can i look at what
2020-04-27 13:00:42 <TBK[m]> > Ariadne: Can you take a look at !7262 on mips(64?) apparently they fixed mips64: https://webkitgtk.org/2020/04/24/webkitgtk2.28.2-released.html?
2020-04-27 13:00:42 <TBK[m]> Ariadne: ^
2020-04-27 13:04:31 <Cogitri> I mean maybe you can test webkit2gtk again on mips64
2020-04-27 13:06:21 <clandmeter> that will probably kill the machine for good
2020-04-27 13:06:28 <clandmeter> :)
2020-04-27 13:21:33 <Ariadne> Cogitri: go ahead and remove the block and lets see if it builds
2020-04-27 13:24:22 <Cogitri> Ah, sure, I can do that too
2020-04-27 13:24:35 <Cogitri> Somehow I'm not that comfortable testing on the builders
2020-04-27 13:25:47 <Ariadne> ok
2020-04-27 13:25:51 <Ariadne> give me a moment
2020-04-27 13:25:55 <Ariadne> and i will start a build
2020-04-27 13:25:57 <Ariadne> how about that
2020-04-27 13:26:02 <Cogitri> Sounds good :)
2020-04-27 13:26:17 <Cogitri> No need to rush it, it's not urgent or smth
2020-04-27 13:26:23 <Cogitri> Just thought you might be interested in it
2020-04-27 13:26:54 <Cogitri> Also, does someone know what apk try to tell me with http://dpaste.com/2RN4PXY? Somehow it doesn't want to upgrade me to new fwupd
2020-04-27 13:29:54 <Ariadne> hmm
2020-04-27 13:30:02 <Ariadne> community needs to be fully composed because of icu changes
2020-04-27 13:30:11 <Ariadne> i'll try it tomorrow :)
2020-04-27 14:42:26 <ncopa> i killed the mips64 build for now. will start it up once i have configured the networking and build log upload
2020-04-27 14:46:02 <ikke> ncopa: is it correct that that plugin is required?
2020-04-27 14:46:10 <ikke> http://tpaste.us/9Nd7
2020-04-27 14:49:14 <ncopa> i think it moved to /usr/share nowdays so we only need to enable the config in /etc/buildrepo/config.lua
2020-04-27 14:49:30 <ncopa> and give scp access to distfiles
2020-04-27 14:49:33 <ncopa> which i have set up
2020-04-27 14:49:36 <ikke> Ah ok
2020-04-27 14:49:49 <ikke> that explains why apk no longer recognized it
2020-04-27 14:49:58 <ncopa> we still use a hack to access distfiles.a.o, so we need to also set Port 22015 in .ssh/config
2020-04-27 14:50:16 <ncopa> well, i dont think we need that anymore, since we have dmvpn working
2020-04-27 14:50:29 <ncopa> but thats how the other builders are configured
2020-04-27 14:53:10 <ncopa> ikke: i think we need som basic awall config too for deu3-dev1 (the mips machine)
2020-04-27 14:53:18 <ncopa> need NAT working from lxcbr0
2020-04-27 14:54:16 <ikke> setup-awall?
2020-04-27 14:55:18 <ncopa> we dont have that?
2020-04-27 14:55:23 <ikke> No
2020-04-27 14:55:31 <ikke> I recall clandmeter mentioning something like that
2020-04-27 14:58:07 <ikke> ncopa: something that created adp-* policies
2020-04-27 14:58:22 <ikke> apk add awall-policies
2020-04-27 14:59:41 <ncopa> thanks
2020-04-27 14:59:50 <ikke> this is dmvpn.json from usa4: http://tpaste.us/za8j
2020-04-27 15:00:56 <ikke> apparently dmvpn also has awall policies included
2020-04-27 15:06:17 <ncopa> yes, i thinkin figured it out
2020-04-27 15:06:49 <ncopa> i only need to change adp-config.json, dmvpn-config.json and add optional/lxc.json, and enable those
2020-04-27 15:08:38 <ncopa> nice!
2020-04-27 15:08:44 <ncopa> this is nice
2020-04-27 15:28:58 <paper_> busybox's manpage in busybox-doc is empty, but abuild -r generates it correctly for me, should I try bumping the revision? It seems unneccessary, because it might not even work. #11443
2020-04-27 15:42:21 <ikke> ncopa: cool
2020-04-27 15:51:07 <clandmeter> ncopa: setup-firewall :p
2020-04-27 16:38:18 <kaey> paper_: /bin/sh: pod2text: not found
2020-04-27 16:38:21 <kaey> make[2]: [/home/buildozer/aports/main/busybox/src/busybox-1.31.1/Makefile.custom:159: docs/BusyBox.txt] Error 127 (ignored)
2020-04-27 16:38:24 <kaey> https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/busybox/busybox-1.31.1-r14.log
2020-04-27 16:38:29 <kaey> missing makedepends
2020-04-27 16:38:56 <paper_> ah, thanks, I will look at it when I get home
2020-04-27 20:27:26 <maxice8> Why tpm2-tss-dev doesn't get the .so files ?
2020-04-27 20:59:44 <TBK[m]> try to move -dev to the top of the subpkg list
2020-04-27 21:00:25 <TBK[m]> atm it is processed last
2020-04-27 21:00:44 <TBK[m]> maxice8: ^
2020-04-27 21:21:41 <maxice8> @TBK thanks for looking at it, i'd like feedback from the one that made the change i pointed in the issue, maybe we are missing something (hopefully not because nothing should link to .so)
2020-04-27 22:26:00 <maxice8> https://gitlab.alpinelinux.org/Leo/atools/-/merge_requests/32
2020-04-28 02:41:46 <yunfan> back
2020-04-28 02:49:18 <dalias> what do i need to do to get alpine gitlab to stop signing me out? >_<
2020-04-28 02:49:58 <dalias> it's really annoying
2020-04-28 02:56:36 <dalias> just filed https://gitlab.alpinelinux.org/alpine/aports/-/issues/11455
2020-04-28 04:53:18 <ikke> dalias: how often does it happen? I think gitlab requires you to relogin every so often
2020-04-28 04:56:46 <dalias> seems to be every time i find reason to use it
2020-04-28 04:56:52 <dalias> and it's really annoying
2020-04-28 04:57:23 <dalias> reasonable modern practice is unlimited-lifetime session cookies that are invalidated only by explicit logout or actions like password change
2020-04-28 04:57:49 <maxice8> then wfm, never got logged out form gitlab.a.o on Firefox
2020-04-28 04:58:08 <dalias> login even has a "remember me" checkbox (off by default, also annoying) that's not being honored
2020-04-28 04:58:29 <dalias> every time i use it it's probably been 2-4 weeks since last use
2020-04-28 04:58:30 <ikke> I've always had to loginto gitlab every month orso
2020-04-28 04:58:43 <dalias> but that's no reason to forget the session
2020-04-28 05:00:50 <ikke> related: https://gitlab.com/gitlab-org/gitlab/-/issues/121569
2020-04-28 05:01:09 <ikke> apparently they're sessions last 7 days by default
2020-04-28 05:02:05 <dalias> ...
2020-04-28 05:02:11 <dalias> this should be easy to patch
2020-04-28 05:02:18 <dalias> just change that 7 to 7000000
2020-04-28 05:03:52 <dalias> lol https://docs.gitlab.com/ee/user/profile/#why-do-i-keep-getting-signed-out
2020-04-28 05:04:12 <dalias> "When signing in to the main GitLab application, you can also check the “Remember me” option which sets the remember_user_token cookie (via devise). remember_user_token expires after config/initializers/devise.rb -> config.remember_for (defaults to 2 weeks)."
2020-04-28 05:04:25 <dalias> "remember me" means "remember me, only for 2 weeks"
2020-04-28 05:04:39 <dalias> gitlab is the most incompetently designed webshit...
2020-04-28 05:04:53 <dalias> i hate it far more than github and that's saying a lot
2020-04-28 05:05:28 <ikke> Ah, found it
2020-04-28 05:05:36 <ikke> Session duration (minutes)
2020-04-28 05:06:18 <dalias> i think the duration enforcement is actually client-side too, lol
2020-04-28 05:06:31 <dalias> all so stupid
2020-04-28 05:06:40 <dalias> "which is for security reasons"
2020-04-28 05:06:44 <dalias> ...
2020-04-28 05:07:23 <dalias> making users susceptible to phishing by forcing them to constantly reenter passwords = opposite of security
2020-04-28 05:08:45 <ikke> I've set it to 1 year now
2020-04-28 05:08:55 <ikke> though apparently it only takes effect when we restart the instance
2020-04-28 05:08:58 <dalias> thanks, altho 10 would be nicer
2020-04-28 05:09:31 <ikke> 10 years it is
2020-04-28 05:09:33 <dalias> :)
2020-04-28 05:10:34 <dalias> it seems like a really small/stupid thing to care about, but it does really suck and reduce bug reporting engagement when every time someone goes to report or update on a bug they find they're logged out and have to go login then get back to the bug page to do anything
2020-04-28 05:11:09 <dalias> seems like the defaults were designed only with active developers in mind, ignoring that majority of users should be casual/infrequent bug reporters
2020-04-28 05:11:22 <ikke> Yeah, I understand, I find that anoying as well
2020-04-28 07:18:12 <PureTryOut[m]> Seems to be something wrong with the ppc64le CI runner, it times out when connecting to https://gitlab.alpinelinux.org/alpine/aports
2020-04-28 07:18:43 <Cogitri> Yup, it's a bit wonky right now
2020-04-28 07:19:06 <ikke> https://gitlab.alpinelinux.org/alpine/infra/compose/gitlab-runner-alpine-ci/-/issues/2
2020-04-28 07:19:35 <ikke> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10687
2020-04-28 07:38:55 <ikke> nmeum: golang provided a patch for the go issue on our CI on arm/aarch64 :)
2020-04-28 07:39:56 <nmeum> that was actually a bug in go? wow
2020-04-28 07:40:08 <ikke> not sure if it's really a bug
2020-04-28 07:40:20 <ikke> They had to use a different syscall
2020-04-28 07:40:27 <nmeum> ah
2020-04-28 07:40:35 <ikke> prlimit verses getrlimit
2020-04-28 07:41:22 <nmeum> I see, but tests are disabled anyhow currently for go due to issues with mips
2020-04-28 07:41:35 <ikke> Yes, but not on 3.11
2020-04-28 07:41:53 <nmeum> (:
2020-04-28 07:41:54 <ikke> which is where I ran into when backporting
2020-04-28 07:42:08 <ikke> So I wanted to get to the bottom of this
2020-04-28 07:42:54 <nmeum> good that you did, it was kind of a strange issue
2020-04-28 07:43:29 <ikke> yes, not sure why getrlimit is blocked in docker on arm / aarch
2020-04-28 07:44:08 <ikke> but the native c test program they provided did call prlimit
2020-04-28 07:44:34 <fabled> i've noticed recently that xfce4-terminal "stalls" for few seconds when exiting from shell, but there is a backgrounded job. seems to happen with ash and bash as the shell, so looks like xfce4-terminal issue. anyone else observed this?
2020-04-28 08:03:32 <ikke> go tests succeed now :)
2020-04-28 09:44:55 <Cogitri> Is it possible to get more info from Gitlab other than "rebase failed" when rebasing a MR failed?
2020-04-28 10:20:35 <ncopa> fabled: i use xfce4-terminal and have not noticed that.
2020-04-28 10:53:01 <PureTryOut[m]> ncopa: is there a reason to still depend on consolekit in bluez? https://git.alpinelinux.org/aports/tree/main/bluez/APKBUILD#n10
2020-04-28 10:53:39 <ncopa> PureTryOut[m]: i dont know. I dont remember why it was added
2020-04-28 10:54:25 <ncopa> Ariadne: im trying to create an edge release, but it fails to create mkinitfs image for linux-octeon
2020-04-28 10:54:46 <ncopa> apparently there are no need for any initramfs image
2020-04-28 10:55:29 <ncopa> I think you said it does not support initramfs
2020-04-28 10:56:05 <PureTryOut[m]> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/commit/f429b184dd2e50c48ad32225b1128a468c95cda8
2020-04-28 10:56:11 <PureTryOut[m]> Really old commit, but it doesn't tell why
2020-04-28 10:56:17 <PureTryOut[m]> Is it ok if I just remove the dep?
2020-04-28 10:57:07 <ncopa> yeah, lets do that
2020-04-28 10:57:09 <ncopa> its bluez4
2020-04-28 10:57:23 <ncopa> bluez5 was significantly refactored
2020-04-28 10:58:12 <ncopa> i think it may be needed to give non-root users permissions to modify bluetooth connections
2020-04-28 10:59:23 <ikke> ncopa: regarding https://gitlab.alpinelinux.org/alpine/aports/-/issues/11416, should we rebuild all go packages?
2020-04-28 10:59:39 <ncopa> in theory yes
2020-04-28 11:00:02 <ncopa> well
2020-04-28 11:00:11 <ncopa> all that has 32 bit architectures
2020-04-28 11:00:46 <ikke> ok, so everything that is built for x86, armhf, armv7, correct?
2020-04-28 11:00:55 <ncopa> yes
2020-04-28 11:01:08 <ikke> We have a patch from upstream to fix the test suite issues on our CI
2020-04-28 11:01:23 <ncopa> good
2020-04-28 11:02:57 <ikke> should we btw upgrade 3.11 to 0.13.7, or directly to 0.13.10?
2020-04-28 11:03:14 <ncopa> I'd do 0.13.10 directly
2020-04-28 11:03:16 <ikke> ok
2020-04-28 11:04:46 <PureTryOut[m]> ncopa: even if that was the case, it isn't anymore. consolekit2 isn't developed anymore and shouldn't be used really
2020-04-28 11:05:29 <ncopa> what should be used? i thought consolekti2 got replaced by systemd
2020-04-28 11:07:32 <Cogitri> Well, it got replaced by logind
2020-04-28 11:07:45 <Cogitri> Which can be used via systemd or elogind as of now
2020-04-28 11:07:51 <PureTryOut[m]> My system runs elogind and it works fine
2020-04-28 11:08:01 <PureTryOut[m]> but is it really needed to use bluez?
2020-04-28 11:11:22 <mps> consolekit2 is not developed, but that doesn't mean it should be removed because it is still usable and there are no issues reported
2020-04-28 11:12:31 <PureTryOut[m]> Sure but to hard dep on it?
2020-04-28 11:12:48 <PureTryOut[m]> I now have consolekit2 on my system just for bluez
2020-04-28 11:12:52 <PureTryOut[m]> I wasn't saying we should remove consolekit2, just to remove it as a hard dep from bluez
2020-04-28 11:13:11 <clandmeter> not being developed qualifies as at least 1 issue :p
2020-04-28 11:13:42 <mps> clandmeter: why? maybe it is some of rare perfect things :)
2020-04-28 11:15:06 <Cogitri> consolekit2 is pretty meh compared to *logind
2020-04-28 11:15:19 <Cogitri> There's a reason why so much software jumped onto *logind
2020-04-28 11:16:16 <mps> PureTryOut[m]: hehe, I hear this 'it as a hard dep from' from someone who argue we should add more deps to packages, remember libpulse and FF :)
2020-04-28 11:16:44 <ncopa> PureTryOut[m]: i think consolekit should not be a hard dep of bluez
2020-04-28 11:17:11 <mps> I think nothing should have hard deps
2020-04-28 11:17:53 <PureTryOut[m]> mps: I don't see how that's a fair comparison, as what you mentioned is a case where PulseAudio can't be used without depending on it. In this case, ConsoleKit2 can still be used with Bluez, even if we remove the hard dep
2020-04-28 11:18:03 <mps> (less dependencies more freedom)
2020-04-28 11:18:26 <Cogitri> > I think nothing should have hard deps
2020-04-28 11:18:26 <Cogitri> That sounds extremely broken
2020-04-28 11:18:36 <PureTryOut[m]> Even then, the Pulse thing isn't a hard dep in the sense that you have to run PulseAudio. You only have the libpulse library installed
2020-04-28 11:18:47 <mps> PureTryOut[m]: I'm talking on principles not about particular cases
2020-04-28 11:18:53 <PureTryOut[m]> Then again, that FF change is still not merged/blocked/accepted/refused/whatever annoyingly enough
2020-04-28 11:19:06 <Cogitri> It was merged for ff non esr already
2020-04-28 11:19:47 <PureTryOut[m]> Sure but that particular case is a bad example
2020-04-28 11:20:00 <Cogitri> Yup
2020-04-28 11:20:03 <PureTryOut[m]> Cogitri: really? Well that's a TIL
2020-04-28 11:20:21 <PureTryOut[m]> Anyways, I'm removing the consolekit dep from bluez then.
2020-04-28 11:20:24 <ncopa> elogind is not that old
2020-04-28 11:20:32 <mps> why do you think only your reasoning is right?
2020-04-28 11:21:02 <PureTryOut[m]> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7311
2020-04-28 11:21:23 <ncopa> we should probably look over what other packages depends on consolekit
2020-04-28 11:21:52 <ncopa> PureTryOut[m]: I liked the commit message
2020-04-28 11:22:17 <PureTryOut[m]> mps: if that was for me, I don't. But the discussion isn't relevant in this case. We're talking about an old package that isn't maintained anymore upstream. It's like we dropped Qt4, we should drop ConsoleKit as well
2020-04-28 11:22:30 <mps> elogind is not designed/made to solve any problem but as compatibility 'layer' for systemd only programs
2020-04-28 11:22:43 <Cogitri> PureTryOut[m]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/1051#note_75305
2020-04-28 11:22:50 <Cogitri> mps: Sorry, but that's just wrong
2020-04-28 11:23:17 <PureTryOut[m]> 👍️ thanks for the merge!
2020-04-28 11:23:19 <PureTryOut[m]> Cogitri: ah yeah I remember know
2020-04-28 11:23:32 <mps> Cogitri: yes, by beginning but nowadays mostly
2020-04-28 11:23:33 <ncopa> we should test if xfce works with elogind
2020-04-28 11:23:58 <Cogitri> That'd be good, yes
2020-04-28 11:24:18 <Cogitri> Xorg with elogind would be nice so we can remove the SUID bit, but I understand if people don't want that
2020-04-28 11:24:51 <mps> yes, I removed suid bit on xorg and it works fine
2020-04-28 11:25:05 <mps> without using elogind
2020-04-28 11:25:19 <ncopa> interesting
2020-04-28 11:25:32 <ncopa> i'd like to get rid of the suid bit on xorg
2020-04-28 11:26:03 <mps> on upgrade I do, chmod -s /usr/bin/xorg :)
2020-04-28 11:26:04 <Cogitri> mps: Only if you make each of your users privileged tho
2020-04-28 11:26:28 <Cogitri> Which is fine on single seat systems, but certainly isn't something you want on a multiseat system
2020-04-28 11:27:22 <ncopa> fwupd, lxdm and mate-desktop-environment uses consolekit
2020-04-28 11:27:31 <mps> sorry, I'm becoming tired of these discussions
2020-04-28 11:27:52 <ncopa> mps: how do you do it?
2020-04-28 11:28:08 <mps> what ?
2020-04-28 11:28:08 <ncopa> i mean, i havent really investigated but what in Xorg needs root?
2020-04-28 11:28:24 <Cogitri> It needs root to access the video and input devices
2020-04-28 11:28:42 <ncopa> so if you are in a group that has access to those?
2020-04-28 11:28:43 <mps> ls -l /usr/bin/Xorg => rwxr-xr-x 1 root root 2009056 Jan 14 17:18 /usr/bin/Xorg
2020-04-28 11:28:52 <Cogitri> So you need to elevate it with suid or elogind, or you need to grant all users which can start Xorg to be in that group
2020-04-28 11:29:05 <Cogitri> So we'd need to make all users which can start Xorg more privileged
2020-04-28 11:29:09 <mps> id => uid=1000(mps) gid=1000(mps) groups=1000(mps),6(disk),18(audio),20(dialout),27(video),28(netdev),104(plugdev),107(docker),300(abuild),1001(bumblebee)
2020-04-28 11:29:23 <ncopa> 27(video)
2020-04-28 11:29:33 <PureTryOut[m]> Isn't it only logical for the user using the desktop to be in the video and input groups?
2020-04-28 11:29:39 <mps> yes, video
2020-04-28 11:29:42 <Cogitri> Also, curious that fwupd needs consolekit2 since it needs elogind
2020-04-28 11:29:56 <Cogitri> PureTryOut[m]: You also need gdm (and other DM users) in those group
2020-04-28 11:30:07 <ncopa> Cogitri: it looks like a compile time option to enable support for consolekit
2020-04-28 11:30:17 <Cogitri> But if we can get by with that then that's fine by me
2020-04-28 11:30:27 <Cogitri> ncopa: Hm, I guess it can work with either one then
2020-04-28 11:30:33 <ncopa> yeah
2020-04-28 11:30:48 <ncopa> what about lxdm and mate-desktop?
2020-04-28 11:30:53 <ncopa> i guess lxdm is no longer maintained
2020-04-28 11:30:59 <ncopa> moved to qt iirc
2020-04-28 11:31:21 <ncopa> and i assume mate can use elogind also nowdays?
2020-04-28 11:31:34 <mps> and unix have groups for long time as solution for multiuser system, which is more safe than giving access to everything to anyone who logs in
2020-04-28 11:31:34 <fabled> ncopa, strange thing that xfce4-terminal thing. wonder if it's something on my box then.
2020-04-28 11:32:06 <ncopa> fabled: i did have some hangs, which i think was related to my video card, or similar
2020-04-28 11:32:34 <ncopa> it usually happened when there was commercials videos on web pages in chrome
2020-04-28 11:32:46 <ncopa> or when screen got blanked
2020-04-28 11:32:51 <ncopa> then it hanged
2020-04-28 11:32:53 <Cogitri> mps: Granting every on your system access to your input devices and video devices isn't something I'd call secure
2020-04-28 11:33:01 <fabled> i thought originally it's some random thing. but it happens when there's backgrounded process when existing the shell. so to reproduce: start xfce4-terminal, on shell "sleep 20 &" and then "exit" or ctrl-d
2020-04-28 11:33:05 <Cogitri> s/ on/one/
2020-04-28 11:33:05 <alpine-meetbot> Cogitri meant to say: mps: Granting everyone your system access to your input devices and video devices isn't something I'd call secure
2020-04-28 11:33:19 <ncopa> and i was able to un-hang it by switch to tty1 and back
2020-04-28 11:34:23 <ncopa> Cogitri: i thikn the idea is to not grant everyone. those who needs it needs to be in the specified groups
2020-04-28 11:34:56 <Cogitri> Well, yes, but everyone who wants a X session needs access
2020-04-28 11:34:57 <mps> so, with elogind users doesn't have access to video or input
2020-04-28 11:35:03 <PureTryOut[m]> Ah yeah that is a bit annoying
2020-04-28 11:35:10 <Cogitri> Yup
2020-04-28 11:35:20 <PureTryOut[m]> ncopa: assuming lxdm is part of lxde, yeah it's unmaintained. It's LXQt now
2020-04-28 11:35:28 <PureTryOut[m]> Idk about Mate desktop, but I would find it very strange if it didn't work with elogind
2020-04-28 11:36:25 <ncopa> elogind needs to be started with openrc script?
2020-04-28 11:36:31 <ncopa> iirc consolekit didnt
2020-04-28 11:38:16 <Cogitri> It starts itself with pam once the first user logs in
2020-04-28 11:38:28 <Cogitri> You can optionally start it with openrc if you want it to be managed via openrc
2020-04-28 11:38:35 <ncopa> aha
2020-04-28 11:38:41 <Cogitri> But it works just fine if you don't, it just doesn't show up in your rc-status then
2020-04-28 11:40:30 <mps> and btw, apk info -e consolekit2 => show nothing, i.e. I don't have it installed :)
2020-04-28 11:41:32 <mps> when I come to alpine I read 'small, simple, secure' and I had a hope, but ...
2020-04-28 11:41:51 <Ganwell> Default slim hasn't enabled PAM, should that be enabled? I often thought to make a MR, but it kept in my local ports, because I thought there might be a reason that PAM is disabled.
2020-04-28 11:42:21 <ncopa> Ganwell: we don use PAM by default
2020-04-28 11:43:14 <mps> Ganwell: 'we' removed it intentionally, iirc
2020-04-28 11:49:20 <Ganwell> I'm glad I don't need libvirt anymore. It pulls polkit and consolekit2, which caused problems and I wasn't motivated at all to fix these, because I am the only user on my laptop. I also removed the PAM magic, so I run default slim now.
2020-04-28 11:50:34 <PureTryOut[m]> I don't think libvirt pulls in consolekit2?
2020-04-28 11:52:07 <Ganwell> polkit pulls consolekit2, not? I might be mistaken. It was 3 years ago.
2020-04-28 11:53:50 <Cogitri> You can install polkit-elogind to pull in elogind instead
2020-04-28 11:54:44 <Ganwell> nice!
2020-04-28 11:55:15 <PureTryOut[m]> Just looking at the deps of polkit makes it appear consolekit doesn't get pulled in
2020-04-28 11:55:55 <PureTryOut[m]> Cogitri: actually, looking at polkit. polkit-elogind provides polkit, which isn't a virtual package, and it just works? Can't we do the same with qt5-qtbase-opengl* then? As in, keep the opengl version as qt5-qtbase, and have qt5-qtbase-opengles provide qt5-qtbase?
2020-04-28 11:57:03 <Cogitri> It's still troublesome to install polkit-dev on a system with polkit-elogind
2020-04-28 11:57:32 <PureTryOut[m]> Oh...
2020-04-28 11:57:56 <Cogitri> But maybe we're just missing a provider on polkit-dev?
2020-04-28 11:58:04 <Cogitri> Dunno, providers and replaces are black magic to me :D
2020-04-28 12:01:05 <PureTryOut[m]> Same, I don't understand it at all
2020-04-28 12:05:38 <ikke> replaces helps when you deprecate a package (name)
2020-04-28 12:05:54 <ikke> it tells apk that the new package now owns the files of the previous pacakge
2020-04-28 12:06:11 <ikke> provides creates an alias for the package
2020-04-28 12:08:10 <ikke> if you provide a version, it will automatically conflict with other packages with that name or provides
2020-04-28 12:08:11 <PureTryOut[m]> But taking the example of polkit, how can you make packages work fine with polkit-elogind-dev when that particular package depends on polkit-dev? Seems `provides="polkit-dev"` doesn't do it
2020-04-28 12:08:46 <PureTryOut[m]> If you now try to install something that depends on polkit-dev while you have polkit-elogind installed, it just complains that polkit-dev conflicts with polkit-elogind
2020-04-28 12:10:58 <ikke> is it a provides with version number?
2020-04-28 12:11:16 <ikke> provides="polkit-dev=$pkgver-r$pkgrel"?
2020-04-28 12:34:57 <ncopa> xfce works with elogind and elogind-polkit
2020-04-28 12:35:11 <Cogitri> Shutdown works too?
2020-04-28 12:35:18 <ncopa> yes
2020-04-28 12:35:25 <Cogitri> Nice :)
2020-04-28 12:36:04 <ncopa> i have replaced lxdm with lightdm too
2020-04-28 12:36:52 <ncopa> hang on a sec... seems like lightdm hanged on me now
2020-04-28 12:37:05 <ncopa> xorg
2020-04-28 12:39:09 <ncopa> yup, something broke
2020-04-28 12:54:55 <PureTryOut[m]> ikke: no, would that help?
2020-04-28 12:55:07 <PureTryOut[m]> Can you then also switch between them easily?
2020-04-28 12:55:30 <ikke> No, that would cause more issues (the conflicts part)
2020-04-28 12:56:02 <ikke> at least according to the wiki page for provides, you should be able to have multiple packages with the same unqualified provides
2020-04-28 12:58:07 <PureTryOut[m]> Hmm... Do you have a clue how to handle something like https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/5701 then? Preferably we can switch between them
2020-04-28 12:59:57 <ikke> the py3-qt5-opengles packages does not have a replaces=
2020-04-28 13:00:27 <ikke> In this case, you *should* use qualified with version
2020-04-28 13:00:44 <ikke>  provides="qt5-qtbase" ->  provides="qt5-qtbase=$pkgver-r$pkgrel"
2020-04-28 13:04:46 <PureTryOut[m]> Ok, I don't get why but sure haha. Is moving qt5-qtbase to qt5-qtbase-opengl even needed with that approach?
2020-04-28 13:06:17 <PureTryOut[m]> Also, what if the pkgrel is different of those packages?
2020-04-28 13:13:17 <ikke> The package that is providing it decides what the version is
2020-04-28 13:14:07 <ikke> provides without version is mostly meant to create a virtual package that can be handled by multiple other packages
2020-04-28 13:15:17 <ikke> say, both rsyslog and syslog-ng can have provides="syslog"
2020-04-28 13:15:44 <ikke> When renaming a package, you need both provides and replaces
2020-04-28 13:16:14 <ikke> replaces is for upgrading systems that already have the old package, while provides is for handling dependencies that still use the old name
2020-04-28 13:16:18 <PureTryOut[m]> But in this case, does qt5-qtbase even need to be renamed?
2020-04-28 13:16:41 <ikke> Depends on what goal you want to achieve I guess
2020-04-28 13:17:07 <PureTryOut[m]> Well I only want the -opengles packages installed if explicitely depended upon by some package or added to world
2020-04-28 13:17:33 <PureTryOut[m]> Otherwise it should always take the "regular" qt5 packages, the -opengl ones in that MR
2020-04-28 13:26:11 <ikke> so qt5-qtbase is the opengl version, but some other package might need the opengles version and depends on qt5-qtbase-opengles?
2020-04-28 13:28:03 <PureTryOut[m]> Yes
2020-04-28 13:29:07 <ikke> I would imagine that qt5-qtbase-opengles should do provides="qt5-qtbase=$pkgver-r$pkgrel" then
2020-04-28 13:29:46 <afontain_> isn't there a risk that some package depend on qt5-qtbase, but need opengl?
2020-04-28 13:33:21 <PureTryOut[m]> Sure, which is why I want it to default to opengl always
2020-04-28 13:33:27 <PureTryOut[m]> Oh wait, I get your point
2020-04-28 13:33:53 <PureTryOut[m]> I mean, maybe? I don't believe packages require either OpenGL or OpenGLES, it's more a matter of hardware support and performance
2020-04-28 13:36:45 <ikke> PureTryOut[m]: You can btw not depend on provided packages in makedepends
2020-04-28 13:36:53 <ikke> buildrepo cannot track those
2020-04-28 13:37:32 <PureTryOut[m]> Oh... That's an issue...
2020-04-28 13:37:47 <PureTryOut[m]> So users always have to choose what version to install themselves?
2020-04-28 13:44:31 <ncopa> humpf
2020-04-28 13:44:39 <ncopa> mips is causing problems
2020-04-28 13:45:38 <ncopa> apparently, kernel's `make install` gives different name to System.map on mips compared to all other architectures
2020-04-28 13:46:41 <PureTryOut[m]> Actually, if I don't rename qt5-qtbase to $pkgname-opengl, then we don't have a virtual package so stuff can just depend on it. And if we explicitely need $pgname-opengles, we can still depend on that too, as that's not a virtual package either
2020-04-28 13:49:07 <ncopa> what depends on qt5qtbase-opengles?
2020-04-28 13:49:13 <ncopa> what is the usecase
2020-04-28 13:49:37 <PureTryOut[m]> Plasma on ARM
2020-04-28 13:50:20 <ncopa> but other things on ARM could still use qt5-base-opengl?
2020-04-28 13:51:00 <ncopa> or is opengles required instead of opengl on ARM in general?
2020-04-28 13:51:38 <ncopa> what i wonder is, does both need to be installed in parallel?
2020-04-28 13:52:07 <ncopa> if so, then we'd need to install them in different paths or with different names
2020-04-28 13:52:58 <Cogitri> No, you only want one of them installed at a time
2020-04-28 13:53:16 <Cogitri> The problem is that openGL either doesn't work or is pretty broken on many ARM devices
2020-04-28 13:53:57 <ikke> But how does that work at build time
2020-04-28 13:54:09 <ncopa> so, in general, we should always use opengles on ARM and not opengl?
2020-04-28 13:54:31 <Cogitri> Not sure about that, I don't know enough about ARM for that
2020-04-28 13:55:23 <afontain_> apparently, that broke things?
2020-04-28 13:55:25 <Cogitri> ikke: If I understand correctly there's only ABI/API differences in Qt itself, so other applications shouldn't have trouble
2020-04-28 13:55:26 <ikke> I guess you should add the proper dependencies in APKBUILD based on arch
2020-04-28 13:55:30 <afontain_> I don't know either about openGL for that either
2020-04-28 13:55:51 <ncopa> but for qt5-qtbase, we'd always want opengles instead of opengl on arm?
2020-04-28 13:56:14 <ncopa> im thinking we should have compiltime option specificially for arm
2020-04-28 13:56:21 <Hello71> I would assume that mesa handles opengl fine but the proprietary garbage does not
2020-04-28 13:56:47 <Hello71> (but I don't know either)
2020-04-28 13:57:04 <ikke> PureTryOut[m]: ^?
2020-04-28 13:57:36 <ncopa> and does it affect aarch64 too? or only armv7 + armhf?
2020-04-28 13:57:36 <PureTryOut[m]> ncopa: no we had OpenGLES by default on ARM for a while, but Ariadne mentioned that broke things on one of their devices and reverted the change
2020-04-28 13:57:38 <ikke> PureTryOut[m] mentioned a few times that he had issues with -dev packages
2020-04-28 13:57:39 <PureTryOut[m]> Which then broke a lot of other devices, but I'm trying to fix that
2020-04-28 13:58:00 <PureTryOut[m]> Hello71: nah Mesa doesn't just handle OpenGL fine
2020-04-28 13:58:08 <PureTryOut[m]> E.g. on Pinephone, mainline kernel and mainline Mesa, still wants OpenGLES
2020-04-28 13:58:26 <PureTryOut[m]> Mostly because the driver is reverse engineered from a binary blob which indeed supports OpenGLES only
2020-04-28 13:58:49 <Hello71> hm.
2020-04-28 13:59:59 <ikke> PureTryOut[m]: Can you explain how this should work at build time? A package cannot be built against opengl and opengles at the same time
2020-04-28 14:00:45 <PureTryOut[m]> Packages don't need to be compiled to one or the other
2020-04-28 14:00:59 <ikke> ok, but why were you strugling with -dev packages then?
2020-04-28 14:01:06 <PureTryOut[m]> It's just an internal ABI difference, which is why there is a qt5-qtdeclarative-opengles and py3-qt5-opengles as well
2020-04-28 14:01:13 <PureTryOut[m]> Packages depending on it can just anyone of them
2020-04-28 14:01:35 <ncopa> ec7c2ff7d185ca4a338bc394e497f10ae2609336
2020-04-28 14:01:46 <PureTryOut[m]> Because with qt5-qtbase-opengles package installed, apk will complain if you install something that depends on qt5-qtbase-dev saying that it conflicts or something
2020-04-28 14:02:00 <ncopa> "OpenGLES-only devices should install soon-to-be packaged GL4ES library instead."
2020-04-28 14:02:21 <PureTryOut[m]> Yeah no
2020-04-28 14:02:24 <PureTryOut[m]> That won't work, at least not for Plasma
2020-04-28 14:03:07 <ncopa> if you use qt5-qtbase-opengles, then you'd need qt5-qtbase-opengles-dev as well i suppose?
2020-04-28 14:03:54 <PureTryOut[m]> Not really, but qt5-qtbase-opengl-dev will not install if qt5-qtbase-opengles is installed
2020-04-28 14:03:55 <ncopa> problem is that you cannot build multiple qt5 qtbase libraries with different built time options and have those installed in parallel
2020-04-28 14:04:16 <PureTryOut[m]> Like I said, to packages depending on Qt it doesn't matter if Qt uses GLES or GL
2020-04-28 14:04:37 <ncopa> apparently it does matter for -dev packages
2020-04-28 14:04:42 <PureTryOut[m]> Only the internal Qt ABI cares about it
2020-04-28 14:05:26 <ncopa> so it matters for qt5-qt* packages
2020-04-28 14:05:34 <ncopa> and for -dev packages
2020-04-28 14:06:27 <PureTryOut[m]> No it doesn't lol. APK only complains because I can't figure out the proper provides and replaces
2020-04-28 14:06:27 <ncopa> as i understand, what you are asking for is basicaly to be able to chose between different qt5 builds runtime
2020-04-28 14:06:50 <PureTryOut[m]> Yes
2020-04-28 14:07:20 <ncopa> so it matters, because the different builds installs files at same location, thats why they conflict
2020-04-28 14:07:41 <PureTryOut[m]> Well yeah, but that's not what I mean.
2020-04-28 14:08:33 <ncopa> meaning if you pick the opengles build, you'd need the opengles flavor of qt5-qtdeclarative and potentially other qt5-qt* packages
2020-04-28 14:08:48 <PureTryOut[m]> Packages don't care if Qt5 is compiled with OpenGL or OpenGLES. But if you make such a package depend on qt5-qtbase-dev while you have qt5-qtbase-opengles installed, APK (atm) won't install qt5-qtbase-opengles-dev or qt5-qtbase-dev, it'll just complain
2020-04-28 14:08:57 <ikke> reference: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/5701
2020-04-28 14:09:58 <ikke> I think because of htis: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/5701/diffs#64e5974f4ccb99bc7701ed11c9cfc83fb026f277_0_142
2020-04-28 14:10:40 <ncopa> PureTryOut[m]: right you need to match the -dev package with the corresponding runtime package
2020-04-28 14:10:45 <ikke> PureTryOut[m]: if it doesn't matter what dev package is used, why use provides / replaces for them at all?
2020-04-28 14:10:56 <ikke> replaces is wrong here btw
2020-04-28 14:11:39 <ncopa> but since the dependency is currently set to explicit dependency (eg qt5-qtbase-dev) things breaks
2020-04-28 14:13:22 <ncopa> neither abuild or apk-tools is designed to solve the "alternatives" feature that you are requesting
2020-04-28 14:13:35 <ncopa> it is similar to what openjdk you want
2020-04-28 14:13:51 <Hello71> pacman asks when multiple provides exist
2020-04-28 14:14:17 <ikke> but in this case, it's not a matter of user preference
2020-04-28 14:14:28 <ikke> so asking the user what to install would only cause confusion and broken setups
2020-04-28 14:14:30 <ncopa> i guess that makes automatted CI installs happy
2020-04-28 14:15:00 <ncopa> apk is designed to be non-interactive first
2020-04-28 14:15:36 <ncopa> provides may solve half of the problem. replaces is not good for this
2020-04-28 14:15:57 <ncopa> since you will not be able to switch back once its replaced
2020-04-28 14:16:33 <ikke> Well, in this case it's not an alternative that you want to switch between I guess
2020-04-28 14:16:46 <PureTryOut[m]> Can I remove the -dev packages entirely from qt5-qtbase-opengles, and have qt5-qtbase-opengles provide qt5-qtbase so qt5-qtbase-dev would work with qt5-qtbase-opengles?
2020-04-28 14:16:51 <ikke> If you install alpine on a pinephone, you always want qt5-qtbase-opengles
2020-04-28 14:16:58 <Hello71> PureTryOut[m]: well does it?
2020-04-28 14:17:27 <PureTryOut[m]> I don't know, that's why I'm asking lol
2020-04-28 14:17:44 <ncopa> PureTryOut[m]: i dont know, but i would not want to depend on it
2020-04-28 14:17:59 <ncopa> the headers may have details about buildtime options
2020-04-28 14:18:22 <PureTryOut[m]> Ok so how should I resolve this then? If at all?
2020-04-28 14:18:39 <afontain_> diffoscope to the rescue
2020-04-28 14:18:47 <afontain_> try.diffoscope.org should be enough to compare the two -dev packages
2020-04-28 14:19:45 <ncopa> i wonder if it would make sense to install different qt builds under different locations
2020-04-28 14:19:57 <ncopa> like /usr/lib/qt5-opengles/
2020-04-28 14:20:04 <ncopa> and then set LD_LIBRARY_PATH at runtime
2020-04-28 14:20:19 <ncopa> that way you can have both implementations installed at runtime
2020-04-28 14:20:45 <Hello71> even if that works I think it should be supported upstream
2020-04-28 14:21:09 <ncopa> i think qt supports that you can have multiple versions of qt installed in parallel
2020-04-28 14:21:30 <ncopa> they just need different install prefixes
2020-04-28 14:21:32 <Hello71> also I think on these arm systems you probably don't want to waste disk space
2020-04-28 14:23:15 <ncopa> but i think the best solution would be what you originally did, that on specific architectures you always pick one of the implementations
2020-04-28 14:23:31 <ncopa> so on all arm you always get qt with opengles
2020-04-28 14:24:58 <ncopa> but as i understand from the commit message in  ec7c2ff7d185ca4a338bc394e497f10ae2609336  the problem is that not everything on arm should use opengles
2020-04-28 14:26:05 <ncopa> what is GL4ES and why can it not be used for plasma?
2020-04-28 14:26:06 <PureTryOut[m]> But there is no need to have both installed at runtime, literally no device needs that
2020-04-28 14:27:26 <PureTryOut[m]> I think it implements or stubs some GL calls OpenGLES does not provide, and Plasma doesn't support it and will break on it in the future if it doesn't already. I talked with the main Plasma Mobile dev about it who has had this discussion with other distributions before, and Plasma just does not support some compability layer like that
2020-04-28 14:28:21 <ncopa> but its needed at build time?
2020-04-28 14:28:27 <ncopa> or we cannot build stuff
2020-04-28 14:31:00 <ncopa> qt-qtbase-dev needs to be linked to qt-qtbase runtime with exact version numbers
2020-04-28 14:31:12 <ncopa> that is not only for qt, that is for libraries in general
2020-04-28 14:31:58 <ncopa> otherwise you may get problems when doing ABI breaking upgrades (build time)
2020-04-28 14:32:26 <ncopa> so i'd assume that also is needed for buildtime config options
2020-04-28 14:33:25 <ncopa> the revert commit message says "This breaks source compatibility with Qt5 compiled against normal OpenGL."
2020-04-28 14:33:40 <ncopa> cant we simply rebuild all Qt with opengls then?
2020-04-28 14:34:41 <ncopa> we have similar problem with some postrgres package as well i think
2020-04-28 14:35:08 <Ariadne> no
2020-04-28 14:35:26 <ncopa> hi Ariadne! i was missing you :)
2020-04-28 14:35:41 <Ariadne> because a lot of programs assume QOpenGLWidget will give them a real opengl context
2020-04-28 14:35:58 <Ariadne> because they were ported to use it not using it from start
2020-04-28 14:36:45 <ncopa> so you are saying that "lot of programs" does not work with qt with opengles at all
2020-04-28 14:37:07 <ncopa> will they fail at build time?
2020-04-28 14:37:12 <Ariadne> yes
2020-04-28 14:37:27 <Ariadne> OpenGLES lacks immediate mode
2020-04-28 14:37:39 <ncopa> do we know which applications that is?
2020-04-28 14:37:46 <Ariadne> so programs have to be rewritten to use glDrawArrays
2020-04-28 14:37:53 <Ariadne> audacious is one
2020-04-28 14:37:59 <Ariadne> browsers
2020-04-28 14:38:46 <ncopa> that also means that you cannot simply replace the qt library with a different configured build
2020-04-28 14:38:47 <Cogitri> I think browsers worked on the Pinephone before the revert to opengl tho
2020-04-28 14:39:08 <PureTryOut[m]> Yeah worked fine
2020-04-28 14:39:09 <Cogitri> But it's a hairy problem, yes
2020-04-28 14:39:15 <PureTryOut[m]> Before Audacious we hadn't heard of any issue with OpenGLES
2020-04-28 14:39:38 <ncopa> could we disable audacious on arm?
2020-04-28 14:39:39 <Ariadne> that's because audacious uses immediate mode
2020-04-28 14:39:41 <PureTryOut[m]> Tbh, I have no clue what to do, but we need OpenGLES for a lot of ARM devices
2020-04-28 14:39:52 <PureTryOut[m]> I'd think even the RPi?
2020-04-28 14:40:09 <Ariadne> we could disable opengl plugins in audacious on OpenGLES platforms
2020-04-28 14:40:21 <ncopa> does audacios work on those devices?
2020-04-28 14:40:22 <Ariadne> but this is why i'd like to see architecture hinting
2020-04-28 14:40:24 <Ariadne> yes
2020-04-28 14:40:36 <Ariadne> I use audacious on my Chromebook frequently
2020-04-28 14:41:47 <ncopa> what browsers are we talking about? its qt based browsers, right?
2020-04-28 14:42:33 <ncopa> its not firefox right?
2020-04-28 14:42:56 <mps> also I use audacious on armv7 and aarch64 chromebooks
2020-04-28 14:43:15 <ncopa> can you live without opengl plugins?
2020-04-28 14:43:21 <mps> not FF, only qt browsers
2020-04-28 14:44:09 <ncopa> Ariadne: im also having problems with the mips kernels and release script
2020-04-28 14:44:25 <ncopa> currently the release scripts assumes there is an initramfs
2020-04-28 14:44:27 <mps> I'm not sure of current state, but that worked on till 3.11
2020-04-28 14:45:03 <Ariadne> yes what I say is that OpenGLES can break those things
2020-04-28 14:45:31 <ncopa> on linux-octeon there is not initramfs so things breaks
2020-04-28 14:45:48 <ncopa> also, the linux kernel will give System.map different name on mips
2020-04-28 14:45:53 <ncopa> thats apparently an upstream issue
2020-04-28 14:46:00 <Ariadne> yes
2020-04-28 14:46:33 <Cogitri> Well, the situation sucks either way, but I'd argue not having the Audacious OpenGL plugin on those arches is better than breaking the desktop for the majority of ARM devices.
2020-04-28 14:47:10 <Ariadne> yes, agreed
2020-04-28 14:50:34 <ncopa> what does other distros?
2020-04-28 14:50:52 <ncopa> they build spearate qt package with opengles?
2020-04-28 14:51:26 <Ariadne> btw it do
2020-04-28 14:51:32 <Ariadne> es affect ABI
2020-04-28 14:52:14 <Ariadne> a program compiled to use OpenGL is not ABI compatible with OpenGLES
2020-04-28 14:56:11 <ncopa> so we cannot have 2 different builds and use provides anyway
2020-04-28 14:56:39 <ncopa> apparently fedora uses opengl only, and fallback to QT_XCB_FORCE_SOFTWARE_OPENGL
2020-04-28 14:57:04 <PureTryOut[m]> https://lists.debian.org/debian-arm/2018/11/msg00021.html
2020-04-28 14:57:21 <ncopa> isnt there arm for arch linux?
2020-04-28 14:57:42 <mps> arch linux alaram
2020-04-28 14:57:49 <mps> alarm*
2020-04-28 14:59:00 <PureTryOut[m]> Seems Ubuntu uses OpenGLES on arm64 at least
2020-04-28 15:00:21 <PureTryOut[m]> Arch Linux ARM doesn't seem to explicitely set the GL they use
2020-04-28 15:01:20 <ncopa> it sounds like we'd want use opengles on arm* and aarch64
2020-04-28 15:01:22 <ncopa> and rebuild
2020-04-28 15:02:27 <mps> on arch alarm mesa is built with '-D gles2=true'
2020-04-28 15:03:02 <Cogitri> mps: That's not really important, we do that for all arches too
2020-04-28 15:03:19 <Cogitri> The support in mesa is there, it's just about what Qt uses
2020-04-28 15:03:47 <mps> ah, ok, didn't followed carefully, sorry
2020-04-28 15:04:03 <Cogitri> No worries :)
2020-04-28 15:05:02 <PureTryOut[m]> ncopa: I mean I'm all for. If it's just some Audacious plugins we can disable, then that seems like the better option
2020-04-28 15:06:18 <mps> PureTryOut[m]: and these are visualization plugins?
2020-04-28 15:07:44 <PureTryOut[m]> I have no clue
2020-04-28 15:07:58 <PureTryOut[m]> Ariadne would know
2020-04-28 15:10:57 <mps> if they are visualization plugins and this is blocker, I'm for disabling them
2020-04-28 15:16:35 <Ariadne> yes
2020-04-28 15:16:41 <Ariadne> disable away
2020-04-28 15:20:39 <ncopa> i quess we'd needs to rebuild evertyhing linked against qt5-qtbase
2020-04-28 15:21:45 <ncopa> libQt5Gui
2020-04-28 15:21:48 <PureTryOut[m]> Ariadne: well, you'd know best what has to be disabled, or even how
2020-04-28 15:22:23 <ncopa> PureTryOut[m]: i think we just need to rebuild evertying linked against libQt5Gui.so.* and disable whatever fails
2020-04-28 15:22:24 <PureTryOut[m]> 
ACTION doesn't know much autotools

2020-04-28 15:22:27 <Ariadne> just qtglspectrum
2020-04-28 15:22:38 <Ariadne> --disable-qtglspectrum
2020-04-28 15:23:27 <Ariadne> realistically Qt has Qt3D which is somewhat a replacement for immediate mode
2020-04-28 15:26:52 <Ariadne> but it's modelled after direct3d not opengl
2020-04-28 15:32:01 <PureTryOut[m]> This should do it then no? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7314
2020-04-28 15:32:49 <ncopa> <Ariadne> a program compiled to use OpenGL is not ABI compatible with OpenGLES
2020-04-28 15:33:04 <ncopa> so i think we need to rebuild everything linked to libQt5gui.so.*
2020-04-28 15:33:27 <ncopa> that will also help us detect if there are something else that we missed
2020-04-28 15:33:34 <PureTryOut[m]> Last time we only rebuild qt5-qtdeclarative and py3-qt5 which seemed to be enough?
2020-04-28 15:33:37 <Ariadne> Qt5OpenGL.so.*
2020-04-28 15:33:46 <PureTryOut[m]> But I don't know how to check for that
2020-04-28 15:35:32 <ncopa> apk search --rdepends --origin -q 'so:libQt5OpenGL.so' | sort -u
2020-04-28 15:35:47 <ncopa> significant number of packages
2020-04-28 15:36:33 <PureTryOut[m]> Ok thanks, will do that tomorrow. G2G now
2020-04-28 15:37:53 <ncopa> sorry, that was incorrect
2020-04-28 15:39:13 <ncopa> i think this is correct: apk list --depends so:libQt5OpenGL.so.*
2020-04-28 15:39:35 <ncopa> 11 packages
2020-04-28 16:03:29 <ncopa> whee! first mips64 "release" http://dl-master.alpinelinux.org/alpine/edge/releases/mips64/
2020-04-28 16:03:43 <ncopa> only minirootfs for now... :)
2020-04-28 16:03:45 <ncopa> but still
2020-04-28 16:04:18 <Cogitri> Neat :)
2020-04-28 16:04:42 <ncopa> Ariadne: as i understand, mips64 (big endian) does not work at all with docker at this point?
2020-04-28 16:45:02 <Ariadne> yes
2020-04-28 18:50:42 <ncopa> s390x failed to create release due to s390x-tools not being rebuilt against json-c
2020-04-28 18:50:48 <ncopa> im manually fixing it now
2020-04-28 18:53:12 <ncopa> but i think I can create an alpine mips64 docker base image anyway
2020-04-28 18:53:24 <ncopa> the question is what i should call the docker arch
2020-04-28 18:53:34 <ncopa> there is apparently mips64el
2020-04-28 18:53:39 <ncopa> but not mips64
2020-04-28 18:53:48 <ikke> what does the el stand for?
2020-04-28 18:54:22 <ncopa> endian little?
2020-04-28 18:54:30 <mps> 'endian little'?
2020-04-28 18:54:34 <mps> heh
2020-04-28 18:54:45 <mps> le reversed ?
2020-04-28 18:54:54 <ikke> lol
2020-04-28 18:55:20 <ikke> Do they prefer be somehow and want to convey that le is reverse?
2020-04-28 18:55:27 <ikke> or backwards
2020-04-28 18:56:38 <mps> https://www.debian.org/ports/mips/
2020-04-28 19:12:15 <danieli> i've been thinking about it being "el" instead of "le" in some places
2020-04-28 19:16:59 <danieli> little endian is essentially backwards when we read it, but it makes sense when reading it from memory
2020-04-28 19:17:10 <danieli> anyway, i digress
2020-04-28 19:17:23 <danieli> do we have mips32/mips64 builders?
2020-04-28 19:19:51 <ikke> We have one builder atm
2020-04-28 19:20:25 <ikke> mips64
2020-04-28 19:25:28 <ncopa> i pushed PR for mips64 docker image
2020-04-28 19:25:33 <ncopa> lets see what happens :)
2020-04-28 19:25:41 <ncopa> https://github.com/docker-library/official-images/pull/7899
2020-04-28 19:30:05 <ikke> nice
2020-04-28 20:58:31 <ncopa> 3.12 builders are up (except mips64)
2020-04-28 20:59:33 <ikke> \o/
2020-04-28 21:00:25 <ikke> So prepare for fixing a lot of build issues :)
2020-04-28 21:06:34 <Cogitri> Nice :)
2020-04-28 21:07:31 <Cogitri> To avoid trouble later on: The current kimchi in the repos won't build on 3.12 I think
2020-04-28 21:07:42 <Cogitri> There's a MR (!6260) to fix that, but I don't have the bits to merge that
2020-04-28 21:07:54 <Cogitri> And I don't know python too well :)
2020-04-28 21:38:26 <ikke> daq source seems to be gone
2020-04-28 21:39:21 <ikke> current version is 2.0.7
2020-04-28 21:40:00 <ikke> looks like 2.0.6 is pulled
2020-04-28 21:50:40 <ikke> Having issues building 2.0.7 (issues with autoconfig/automake)
2020-04-29 02:32:58 <maxice8> So for now we should focus on making 3-12 in build.a.o build everything ?
2020-04-29 02:40:53 <dalias> for musl 1.2.0?
2020-04-29 02:41:03 <maxice8> no
2020-04-29 02:41:08 <maxice8> for building
2020-04-29 02:41:13 <dalias> ?
2020-04-29 02:41:23 <maxice8> as far as i am aware musl 1.2.0 will come in 3-13
2020-04-29 02:41:34 <dalias> ah ok
2020-04-29 05:49:34 <ikke> bc is segfaulting on s390x
2020-04-29 06:09:36 <ncopa> morning
2020-04-29 06:10:44 <ncopa> dalias: we build the stable releases from scratch. for musl 1.2 we'd need first build edge from scratch too on 3 architectures, and we are not there yet :-/
2020-04-29 06:10:55 <ncopa> it would delay the 3.12 release significantly
2020-04-29 06:11:14 <ncopa> 3.12 builders are up!
2020-04-29 06:19:01 <Cogitri> Morning
2020-04-29 06:19:02 <Cogitri> And nice :)
2020-04-29 06:20:06 <ncopa> we should focus on 1) getting 3.12 built 2) fix as many bugs/issues as possible 3) testing 4) cleanup and upstream patches
2020-04-29 06:20:15 <ncopa> in other words, we should focus on getting 3.12 out
2020-04-29 06:44:22 <mps> would you look at MRs with 3.12 milestones set, I made a few
2020-04-29 06:44:44 <mps> mdocml rename to mandoc especially
2020-04-29 06:45:37 <Cogitri> A look at !6260 would be appreciated too
2020-04-29 06:48:08 <ikke> fails on armv7?
2020-04-29 06:51:23 <Cogitri> I think that is just yet another Autotools build system that can't cope with too many build jobs
2020-04-29 06:51:52 <Cogitri> > mv: can't rename 't-ru_RU.gmo': No such file or directory
2020-04-29 06:51:52 <Cogitri> Seems like some race condition since that doesn't happen on other arches
2020-04-29 06:57:47 <ikke> Probably an internal dependency missing
2020-04-29 06:59:15 <Cogitri> Yup
2020-04-29 06:59:25 <Cogitri> So it races for whether the .gmo thingie is built first or installed first
2020-04-29 06:59:39 <ikke> But the race is apparently consistent on ARM
2020-04-29 07:00:28 <Cogitri> Huh, do we have the most build jobs on that machine?
2020-04-29 07:01:01 <ikke> no, that would be x86_64 atm
2020-04-29 07:01:51 <mps> https://wiki.qemu.org/ChangeLog/5.0, JIT (just in time for 3.12)
2020-04-29 07:02:15 <mps> though arm32 is removed :(
2020-04-29 07:02:46 <Cogitri> Huh, no clue how that only fails on armv7
2020-04-29 07:47:10 <ncopa> mps: mandoc needs bump pkgrel
2020-04-29 07:48:46 <mps> didn't I bumped it? have to look
2020-04-29 07:49:41 <mps> now I'm out of home
2020-04-29 07:54:55 <ncopa> re qemu, so we simply remove it from armhf and armv7?
2020-04-29 07:56:00 <ncopa> i guess we dont want qemu user for those either
2020-04-29 07:58:31 <AinNero> uhm, the Changelog reads for me as if only kvm support was removed
2020-04-29 08:02:24 <ncopa> so we can still build it?
2020-04-29 08:02:36 <ncopa> and only support emulation mode?
2020-04-29 08:02:49 <ncopa> is that even useful on arm?
2020-04-29 08:02:54 <ncopa> are 32 bit that it
2020-04-29 08:02:56 <ncopa> is*
2020-04-29 08:03:50 <AinNero> actually, kvm support wasnt even removed, just deprecated
2020-04-29 08:04:19 <AinNero> and this will break earlier when the kernel removes the /dev/kvm interface on arm32
2020-04-29 08:05:14 <AinNero> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-Kill-32-bit-ARM-KVM
2020-04-29 08:16:33 <mps> arm32 guest is still supported, support is removed in kernel 5.7 (or 5.6) for arm32
2020-04-29 08:16:44 <ncopa> ok. se we keep it for now
2020-04-29 08:16:50 <mps> yes
2020-04-29 08:17:04 <ncopa> also reminds me, i wonder if we can drop armhf after alpine 3.12 release
2020-04-29 08:17:32 <mps> yes
2020-04-29 08:19:19 <mps> or make something minimal and separate of aports, or something else, tbh I don't have idea what
2020-04-29 08:20:45 <ikke> any idea what should provide -ltermcap?
2020-04-29 08:20:56 <ikke> (slang is failing)
2020-04-29 08:21:52 <mps> ncurses built with termcap support, maybe
2020-04-29 08:22:18 <mps> 
ACTION wonder slang is still in use

2020-04-29 08:38:01 <PureTryOut[m]> Fuck my KDE Applications MR upgrade to 20.04.0 didn't get merged for the feature freeze
2020-04-29 08:38:11 <PureTryOut[m]> Annoying, since it was ready 😒
2020-04-29 08:38:41 <ikke> PureTryOut[m]: I don't think it's too late yet
2020-04-29 08:39:01 <ncopa> builders has not started on community repo
2020-04-29 08:39:34 <ncopa> im trying to get the python performance fix in
2020-04-29 08:39:45 <PureTryOut[m]> Then please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7163
2020-04-29 08:41:35 <Cogitri> Didn't merge it yet because aarch64 didn't seem happy
2020-04-29 08:45:19 <PureTryOut[m]> Because it took longer than 3 hours to build 😉
2020-04-29 08:45:24 <PureTryOut[m]> Which is too be expected
2020-04-29 08:45:40 <mps> ncopa: you merged mandoc MR?
2020-04-29 08:48:30 <ncopa> i dont think i did?
2020-04-29 08:49:21 <ncopa> i rebased it
2020-04-29 08:49:39 <mps> Natanael Copa pushed new commits to merge request !7119
2020-04-29 08:49:46 <mps> ah, so
2020-04-29 08:50:12 <mps> 'pushed' is confused me
2020-04-29 08:50:20 <ikke> pushed to your branch
2020-04-29 08:50:22 <ikke> not to master
2020-04-29 08:50:26 <ncopa> yeah, pushed to the MR
2020-04-29 08:50:35 <mps> I see, sorry
2020-04-29 08:50:45 <ncopa> np
2020-04-29 08:50:57 <ncopa> mps: can you bump pkgrel and rebase?
2020-04-29 08:51:02 <mps> and I added mess before reading mail
2020-04-29 08:51:07 <ncopa> then i'll merge it on CI success
2020-04-29 08:51:33 <mps> lets wait till CI finish, then I will look what should be done
2020-04-29 08:52:00 <ncopa> i think you can abort the CI, bump pkgrel and re-run the CI
2020-04-29 08:52:21 <ncopa> iirc the other packages built fine
2020-04-29 08:52:35 <mps> actually I bumped it and pushed, but didn't rebased
2020-04-29 08:53:19 <ncopa> PureTryOut[m]: the kde thing needs some work :-/
2020-04-29 08:53:27 <ncopa> FAIL!  : TaskModifyJobTest::testModify(batch modify) Compared values are not the same
2020-04-29 08:53:27 <ncopa>    Loc: [/home/ncopa/aports/community/libkgapi/src/libkgapi-20.04.0/autotests/tasks/taskmodifyjobtest.cpp(92)]
2020-04-29 08:53:53 <ncopa> that is on x86_64
2020-04-29 08:53:54 <PureTryOut[m]> Where do you see that?
2020-04-29 08:53:57 <PureTryOut[m]> Which arch?
2020-04-29 08:54:02 <ncopa> x86_&4
2020-04-29 08:54:04 <ncopa> x86_64
2020-04-29 08:54:20 <ncopa> i did a full build here locally
2020-04-29 08:54:45 <ncopa> does libkgapi build on your machine?
2020-04-29 08:55:00 <ncopa> i also wonder if we should try get the opengles in first too
2020-04-29 08:55:10 <PureTryOut[m]> Testing right now
2020-04-29 08:55:20 <PureTryOut[m]> That'd be fine to me
2020-04-29 08:55:35 <mps> rebased and pushed, waiting for CI
2020-04-29 08:56:23 <PureTryOut[m]> Interesting that it built fine on CI though
2020-04-29 09:01:52 <PureTryOut[m]> ncopa: yeah builds fiune locally
2020-04-29 09:03:43 <ncopa> maybe test is flaky
2020-04-29 09:03:45 <mps> can someone push !6993 and !7001, u-boot and uboot-tools for 3.12
2020-04-29 09:05:08 <mps> also, review !7204 , rng-tools. I added librtlsdr-dev which is in testing
2020-04-29 09:05:39 <PureTryOut[m]> Guess so
2020-04-29 09:05:59 <mps> options are, move librtlsdr to main or build rng-tools without it (which is not good idea, imo)
2020-04-29 09:07:14 <mps> and this, !7221 finally (till next issue discovered) fix ncurses  -terminfo split
2020-04-29 09:09:40 <ncopa> mps: im moving librtlsdr
2020-04-29 09:12:53 <mps> I just pushed MR :)
2020-04-29 09:14:07 <mps> and mandoc
2020-04-29 09:14:07 <mps> !7119
2020-04-29 09:14:16 <mps> finished
2020-04-29 09:25:17 <mps> hmm, rng-tools with librtlsdr fail on ppc64le
2020-04-29 09:26:53 <mps> anyone with ppc64le knowledge could/would look at this error https://gitlab.alpinelinux.org/mps/aports/-/jobs/104267#L452
2020-04-29 09:27:54 <mps> sorry, this line https://gitlab.alpinelinux.org/mps/aports/-/jobs/104267#L456
2020-04-29 09:44:14 <mps> interesting, it passed now also on ppc64le, black magic ? or someone simply restarted job
2020-04-29 09:44:37 <mps> or, I'm looking wrong one :)
2020-04-29 10:40:37 <ncopa> mps: its a bug in rng-tools. they use "encrypt" which is a posix function
2020-04-29 10:40:56 <ncopa> i dont know why it only triggers on ppc64le, but it should be reported upstream
2020-04-29 10:42:04 <mps> understand, but what we should do now, disable librtlsdr only on ppc64le, and ask Ariadne about mips
2020-04-29 10:42:22 <mps> or disable on all
2020-04-29 10:43:08 <mps> and I will try to report issue upstream, but not sure when we will got answer
2020-04-29 10:44:17 <mps> would be nice to have radio as entropy source for 3.12
2020-04-29 10:48:38 <ncopa> its a simple fix for it
2020-04-29 10:51:12 <mps> where?
2020-04-29 10:51:51 <mps> I don't see upstream have but report channel except on github maybe
2020-04-29 10:52:49 <mps> but looking your comment I think we can create patch
2020-04-29 10:53:36 <mps> not sure what will be best option
2020-04-29 10:54:09 <mps> and why it is only on ppc64le
2020-04-29 11:06:06 <ncopa> i don tknow either why it is only ppc64le, but their code is wrong and it seems like they have similar fixes in the other files
2020-04-29 11:06:16 <ncopa> i did a grep encrypt *.c
2020-04-29 11:06:29 <ikke> has it already been built for other arches?
2020-04-29 11:06:36 <ncopa> yes
2020-04-29 11:06:39 <ikke> ah ok
2020-04-29 11:06:51 <ncopa> i pushed it with a fix
2020-04-29 11:06:55 <ncopa> but it needs to be upstreamed
2020-04-29 11:08:07 <mps> ah, I add '--without-rtlsdr' for ppc64le locally, but I see it is not needed now :)
2020-04-29 11:08:27 <mps> and, agree it should be reported upstream
2020-04-29 11:11:09 <ncopa> mps: can you take care of that?
2020-04-29 11:11:47 <mps> will try
2020-04-29 11:14:16 <mps> I have dilemma about ncurses, !7221, and --with-terminfo-dirs="/etc/terminfo:/usr/share/terminfo:/lib/terminfo:/usr/lib/terminfo"
2020-04-29 11:15:11 <mps> I removed /lib/terminfo and /usr/lib/terminfo but [[sroracle]] told me that we have this for ubuntu users who build static pkgs on alpine
2020-04-29 11:15:55 <mps> commit id is e773ffa89a7b52f56f5cdbce5d3ab6518a192e8d
2020-04-29 11:16:31 <mps> do we have to keep this still
2020-04-29 11:54:05 <AinNero> otherwise we'd have to tell them to set TERMINFO manually
2020-04-29 12:06:41 <ncopa> mps: yes we need to keep it
2020-04-29 12:09:22 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/9362
2020-04-29 12:09:35 <AinNero> i got a bugfix MR, do i need to do something special to have it int 3.12 ?
2020-04-29 12:09:48 <AinNero> s/int/release/
2020-04-29 12:09:49 <alpine-meetbot> AinNero meant to say: i got a bugfix MR, do i need to do something special to have it release 3.12 ?
2020-04-29 12:10:20 <ncopa> set milestone to 3.12 maybe
2020-04-29 12:36:57 <mps> fixed !7221, ncurses and reverted /lib/terminfo and /usr/lib/terminfo
2020-04-29 12:45:08 <mps> could someone merge it, and !7119
2020-04-29 12:53:08 <ncopa> what exactly is the problem it fixes?
2020-04-29 13:15:25 <ncopa> PureTryOut[m]: i think i regret that i pushed kde 20.04. umbrello fails on ppc64le
2020-04-29 13:15:53 <ncopa> test suite that is
2020-04-29 13:15:55 <PureTryOut[m]> Regret is a bit harsh 😛
2020-04-29 13:16:04 <PureTryOut[m]> I'll look into it
2020-04-29 13:16:08 <ncopa> well, i feel its my responsibility to fix it
2020-04-29 13:16:31 <ncopa> and apparently umbrello is at the end of the dep chain, so to investigate i need to build everyting more or less
2020-04-29 13:17:45 <PureTryOut[m]> 10 out of 11 tests failures, how did this pass CI? 🤔
2020-04-29 13:19:14 <ncopa> it didnt
2020-04-29 13:19:18 <ncopa> CI timed out
2020-04-29 13:19:26 <ncopa> so i built it locally on x86_64 and aarch64
2020-04-29 13:19:27 <ncopa> and pushed
2020-04-29 13:20:08 <ncopa> thats why i say i feel its my responsibility to fix it, because i shoulndt really have pushed it :-)
2020-04-29 13:20:27 <PureTryOut[m]> Oh ok
2020-04-29 13:22:12 <ncopa> its still nice to have a fresh kde
2020-04-29 13:22:21 <ncopa> if it works... :)
2020-04-29 13:22:53 <ncopa> im also working on that qt5 opengles thing
2020-04-29 13:23:20 <ncopa> and im glad that we worked out a solution with that
2020-04-29 13:24:01 <Cogitri> Yup :)
2020-04-29 13:24:19 <PureTryOut[m]> Yeah same!
2020-04-29 13:24:53 <ncopa> PureTryOut[m]: thanks for pushing that issue. i appreciate that
2020-04-29 13:25:05 <ncopa> i mean, not giving up
2020-04-29 13:25:09 <ncopa> and being patient
2020-04-29 13:25:56 <PureTryOut[m]> Yeah no probs. I really want it fixed
2020-04-29 13:27:32 <ncopa> would also be nice if you can google anything on ubrello and ppc64le
2020-04-29 13:27:41 <ncopa> or look for patches from fedora or similar
2020-04-29 13:28:13 <ncopa> Cogitri: was it so that earlier versions of webkit2gtk worked with mips64?
2020-04-29 13:28:17 <PureTryOut[m]> Yeah am doing it atm
2020-04-29 13:28:50 <PureTryOut[m]> Fedora supports ppc64le?
2020-04-29 13:29:31 <ncopa> im trying to build webkit2gtk in a mips64 dev env. but it is slow
2020-04-29 13:29:56 <ncopa> PureTryOut[m]: yes i think they do.
2020-04-29 13:30:02 <Cogitri> I have no clue to be honest, I don't know mips64 at all
2020-04-29 13:30:22 <Cogitri> I just saw the announcement of the webkit2gtk devs that the new point release should fix JIT compilation on mips64
2020-04-29 13:31:39 <PureTryOut[m]> Seems they have 19.12.3 still
2020-04-29 13:32:33 <ncopa> Cogitri: aha. nice
2020-04-29 13:40:08 <PureTryOut[m]> ncopa: armv7 fails too for umbrello. Interestingly enough Arch Linux ARM does have 20.04.0 on armv7 working, without patches
2020-04-29 13:40:15 <PureTryOut[m]> Oh actually nvm, that's not interesting. They don't build unittests
2020-04-29 13:44:11 <ncopa> but they all passed on aarch64
2020-04-29 13:45:10 <PureTryOut[m]> Actually, seems to be a webkit thing
2020-04-29 13:46:46 <PureTryOut[m]> In which I'm going to say, just disable the tests on the failing architectures. The qtwebkit version we use is an unstable version with quite a lot of commits since the last release, and I don't think it's worth finding a fix while it might already be fixed in the next qtwebkit release
2020-04-29 13:48:42 <mps> I lost internet link
2020-04-29 13:48:51 <PureTryOut[m]> *unstable being an alpha release
2020-04-29 13:49:09 <mps> 14:53 ...........@ncopa| what exactly is the problem it fixes?
2020-04-29 13:49:22 <mps> did you mean ncurses MR
2020-04-29 13:49:30 <ncopa> mps: yes
2020-04-29 13:49:53 <mps> current ncurses-terminfo is empty
2020-04-29 13:50:06 <ncopa> would be nice with either an explanation of the problem or a reference to an issue with the explanation
2020-04-29 13:50:13 <ncopa> how did it end up empty?
2020-04-29 13:50:13 <mps> and terminfo data are in ncurses apk
2020-04-29 13:50:30 <ncopa> so something broke it
2020-04-29 13:50:59 <ncopa> would be nice with "fixes empty ncurses-terminfo, which was introduced in commit <...>"
2020-04-29 13:51:02 <ncopa> or similar
2020-04-29 13:51:16 <mps> well, by 'someone' who created these changes. I think me or maxice8 , but not sure
2020-04-29 13:51:42 <ncopa> it doesnt matter so much who did it
2020-04-29 13:51:55 <ncopa> but it is of interest on when it was introduced
2020-04-29 13:52:23 <mps> I can't find exact commit
2020-04-29 13:52:35 <ncopa> can you find alpine release?
2020-04-29 13:53:42 <mps> when we started to move basic terminfo data to ncurses-terminfo-base and rest to ncurses-terminfo
2020-04-29 13:54:16 <ncopa> ok, alpine 3.11 is affected
2020-04-29 13:54:22 <mps> no
2020-04-29 13:54:27 <ncopa> 3.10 is not
2020-04-29 13:54:32 <mps> only on edge
2020-04-29 13:54:38 <ncopa> 3.11 too
2020-04-29 13:55:29 <mps> no, 3.11 and earlier have ncurses-terminfo ok but a lot of pkgs depend on it
2020-04-29 13:55:55 <ncopa> $ docker run --rm -it alpine:3.11 sh -c "apk update && apk fetch --stdout ncurses-terminfo | tar -zt" | tpaste
2020-04-29 13:55:55 <ncopa> http://tpaste.us/5Edx
2020-04-29 13:56:20 <ncopa> $ docker run --rm -it alpine:3.10 sh -c "apk update && apk fetch --stdout ncurses-terminfo | tar -zt" | tpaste
2020-04-29 13:56:20 <ncopa> http://tpaste.us/vJkk
2020-04-29 13:56:42 <mps> about month ago we started to think to move seldom used terminfos to ncurses-terminfo and most used to -terminfo-base
2020-04-29 13:57:40 <mps> actually a year and some months ago I proposed that split but was silenced by (forgot who)
2020-04-29 14:00:21 <mps> all this is not relevant or important now (imo), we should fix it finally
2020-04-29 14:00:32 <ncopa> yes
2020-04-29 14:02:10 <ncopa> it was introduced with 67ff3d44c974487c6b5594e274f686dc3d898a51
2020-04-29 14:02:44 <mps> ah, then it was my mistake
2020-04-29 14:03:14 <ncopa> have in yout commit message some thing like: "fixes regression introduced in commit <hash> (main/ncurses: fix missing vtXXX terminfo in ncurses-terminfo-base)"
2020-04-29 14:03:49 <mps> ok
2020-04-29 14:04:04 <ncopa> Leo pushed it to 3.11 stable
2020-04-29 14:04:06 <mps> thanks for found it
2020-04-29 14:04:23 <ikke> 67ff3d44c9 (main/ncurses: fix missing vtXXX terminfo in ncurses-terminfo-base, 2020-04-05)
2020-04-29 14:04:45 <ncopa> i think the commit hash it different in git master and 3.11-stable
2020-04-29 14:05:05 <ncopa> i used the one in 3.11-stable, but you shoudl use the one in edge
2020-04-29 14:05:17 <ikke> git log -1 --format=reference 67ff3d44c974487c6b5594e274f686dc3d898a51
2020-04-29 14:05:23 <mps> ah, yes. maxice8 bacported that to 3.11, I forgot
2020-04-29 14:05:35 <ncopa> and yeah, the format ikke suggests is good
2020-04-29 14:07:08 <mps> I don't understand, put in commit msg what ikke just posted?
2020-04-29 14:08:58 <mps> or 'fix mess introduced in commit 67ff3d44c974487c6b5594e274f686dc3d898a51'
2020-04-29 14:09:48 <ncopa> it is commit in git master 95aa0e7217d9ad1e89b6b66d235f2bff4f59af07
2020-04-29 14:10:00 <mps> 'mess' could be replaced by more polite word
2020-04-29 14:10:08 <ncopa> 'regression'
2020-04-29 14:10:19 <mps> yes, nice
2020-04-29 14:11:18 <ncopa> fix regression introduced in commit 95aa0e7217d9 (main/ncurses: upgrade to 6.2_p20200314, 2020-03-15)
2020-04-29 14:12:03 <ncopa> and for 3.11-stable: fix regression introduced in commit 67ff3d44c9 (main/ncurses: fix missing vtXXX terminfo in ncurses-terminfo-base, 2020-04-05)
2020-04-29 14:13:10 <mps> I'm not sure for 3.11, we should then look on all pkgs which depends on -terminfo and -terminfo-base
2020-04-29 14:13:45 <ncopa> then we just revert 67ff3d44c974487c6b5594e274f686dc3d898a51
2020-04-29 14:14:40 <mps> lets look at 3.11 after we fix things for 3.12 builders
2020-04-29 14:15:01 <mps> release*
2020-04-29 14:15:55 <ncopa> 3.11 is broken now, since 2-3 weeks
2020-04-29 14:16:02 <ncopa> since April 11
2020-04-29 14:16:09 <ncopa> i think I 'll just revert it
2020-04-29 14:16:26 <mps> maybe this is most safe option
2020-04-29 14:16:50 <mps> but give me time to look after lunch
2020-04-29 14:41:35 <PureTryOut[m]> Seems Qt5 with GLES fails on both armv7 and aarch64 for `community/gwenview` and `testing/shotcut`
2020-04-29 14:42:07 <ncopa> yes, im looking at it now. testing/shotcut seems to require opengl
2020-04-29 14:42:14 <ncopa> gwenview built here
2020-04-29 14:42:43 <PureTryOut[m]> Ah good
2020-04-29 14:43:02 <PureTryOut[m]> Shotcut is a video editor, makes sense for it to stick to OpenGL only. Disable on arm* then I guess?
2020-04-29 14:43:13 <PureTryOut[m]> If people want a video editor on arm, there at least is kdenlive 😜
2020-04-29 14:43:14 <ncopa> glwidget.cpp:939:17: error: 'QOpenGLFunctions_1_1' was not declared in this scope; did you mean 'QOpenGLFunctions'?
2020-04-29 14:43:14 <ncopa>       |                 ^~~~~~~~~~~~~~~~~~~~
2020-04-29 14:43:14 <ncopa>   939 |                 QOpenGLFunctions_1_1* f = m_context->versionFunctions<QOpenGLFunctions_1_1>();
2020-04-29 14:43:38 <ncopa> yeah, im enabling it on x86_64 only
2020-04-29 14:43:53 <ncopa> and x86
2020-04-29 14:44:17 <PureTryOut[m]> ppc64le seems to work as well, just as x86
2020-04-29 14:45:01 <ncopa> mksully22: can you help investigate if it is possible to fix qt5-qtwebengine for ppc64le?
2020-04-29 14:45:10 <ncopa> not sure its worth it
2020-04-29 14:45:23 <PureTryOut[m]> Not just fix, add support for it
2020-04-29 14:45:30 <PureTryOut[m]> That said, if we really want that, Void has a patch for it
2020-04-29 14:47:19 <PureTryOut[m]> https://github.com/void-linux/void-packages/blob/master/srcpkgs/qt5-webengine/patches/0089-enable-ppc64.patch
2020-04-29 14:47:35 <PureTryOut[m]> But I rather not enable an arch that upstream doesn't actively support
2020-04-29 14:49:12 <ncopa> FAIL!  : ImageScalerTest::testScaleFullImage() 'ok' returned FALSE. (ImageScaler did not emit scaledRect() signal in time)
2020-04-29 14:50:02 <PureTryOut[m]> That's gwenview no?
2020-04-29 14:51:58 <ncopa> yeah
2020-04-29 14:52:06 <ncopa> they only give it 30 miliseconds
2020-04-29 14:53:51 <PureTryOut[m]> That is a bit short, but it only fails on arm. Seems to be enough on other architectures
2020-04-29 14:54:17 <ncopa> its enough as long as there are no swapping going on or similar
2020-04-29 14:54:46 <PureTryOut[m]> At least Void has it packaged without patches though, but idk if they run the tests
2020-04-29 14:55:10 <ncopa> the crosscompile on arm so they cant run tests
2020-04-29 14:55:33 <PureTryOut[m]> Ah...
2020-04-29 14:59:08 <ncopa> PureTryOut[m]: can you please push those two commits to your MR: http://tpaste.us/QnBw
2020-04-29 14:59:19 <ncopa> curl http://tpaste.us/QnBw | git am
2020-04-29 14:59:22 <PureTryOut[m]> You can do it too no?
2020-04-29 14:59:42 <ncopa> im lazy, may need rebase and figure out the push url and branch name
2020-04-29 15:00:10 <ncopa> may not even be able to do it from the arm machine so i may re-pull it on other machine etc
2020-04-29 15:00:14 <ncopa> just lazy
2020-04-29 15:01:06 <PureTryOut[m]> Lol ok then
2020-04-29 15:03:29 <ncopa> i mean, its better than simple ask you to fix the CI errors in the MR ;)
2020-04-29 15:03:57 <PureTryOut[m]> Done, and rebased on master
2020-04-29 15:04:09 <ncopa> awesome 👍
2020-04-29 15:04:31 <PureTryOut[m]> Lol yes I'm thankful 😉
2020-04-29 15:18:18 <ikke> kaccounts-providers is now failing on ppc64le
2020-04-29 15:19:13 <Ariadne> morning
2020-04-29 15:19:17 <ikke> morning
2020-04-29 15:19:48 <Ariadne> did we succeed in building webkit2gtk on mips64 yet
2020-04-29 15:20:55 <ikke> ncopa was trying it, but not sure if he succeeded
2020-04-29 15:21:20 <Ariadne> well the failure to build is quite early so
2020-04-29 15:22:54 <ncopa> Ariadne: it has built all day
2020-04-29 15:23:12 <Ariadne> it's probably ok to push out :)
2020-04-29 15:23:20 <ncopa> been compiling javascriptcore for 7 hours now
2020-04-29 15:23:41 <Ariadne> hahaha
2020-04-29 15:23:54 <Ariadne> did you do make -j16
2020-04-29 15:24:00 <ncopa> a single process
2020-04-29 15:24:03 <Ariadne> oh
2020-04-29 15:24:07 <Ariadne> yeah that would do it
2020-04-29 15:24:38 <ncopa> bummer... I had -j2
2020-04-29 15:24:47 <ikke> heh
2020-04-29 15:26:12 <ncopa> Ariadne: also, thank you for you help and explanations with the qt5-qtcore and opengles yesterday
2020-04-29 15:26:23 <ncopa> found out that also shotcut needs opengl
2020-04-29 15:26:50 <ncopa> and i could easily have spent hours without your explanation yesterday
2020-04-29 15:27:04 <ikke> apcupsd needs man in makedepends, but man no longer exists
2020-04-29 15:27:43 <ikke> would that be man-db?
2020-04-29 15:27:57 <ncopa> mandoc does not have 'man'?
2020-04-29 15:28:38 <ikke> it has
2020-04-29 15:28:48 <ncopa> try buildit with that
2020-04-29 15:28:55 <ikke> I just removed man from makedepends, seems to build fine
2020-04-29 15:28:58 <ncopa> if that fails, try with man-db
2020-04-29 15:29:04 <ncopa> ok
2020-04-29 15:29:25 <ikke> hmm, but I probably have man installed
2020-04-29 15:29:56 <ncopa> rootbld
2020-04-29 15:30:28 <ikke> I would need to add certainly capabilities to my build container
2020-04-29 15:30:34 <ikke> certain*
2020-04-29 15:30:38 <ncopa> :)
2020-04-29 15:30:47 <ncopa> builders are busy and CI too
2020-04-29 15:31:19 <ikke> even with man removed, it succeeds, hmm
2020-04-29 15:32:11 <ncopa> run a checkapk
2020-04-29 15:32:18 <ncopa> maybe it does not build man pages
2020-04-29 15:32:40 <ikke> MAN   apcupsd.8 -> apcupsd.man.txt  \
2020-04-29 15:32:44 <ikke> that's part of the output
2020-04-29 15:33:46 <ikke> it reports no differences
2020-04-29 15:37:16 <Ariadne> A
2020-04-29 15:40:36 <ikke> No idea how it's working, it does seem to call the actual man command, and it's producing output
2020-04-29 15:58:52 <ikke> ncopa: 6de18b4fbf1f419c8cffaaa39630c886014d74d4
2020-04-29 15:59:02 <ikke> 10 years ago
2020-04-29 16:00:38 <Cogitri> Took me a sec to realise tha 2010 is in fact 10 years ago, time sure flies
2020-04-29 16:04:12 <ncopa> may not be needed anymore
2020-04-29 16:04:18 <ikke> No, appears not
2020-04-29 16:04:45 <ikke> man got removed as subpkg in 7f9d0dd06fc561630c2ac41c53627b218cafb7f1 without any mention
2020-04-29 16:05:28 <ikke> (and without verifying anything still depending on man apparently)
2020-04-29 16:05:36 <ncopa> im going out for a run, hopefully !7314 is done and merged when I come back
2020-04-29 16:06:07 <ncopa> and hopefully the mips build of webkit2gtk is doen too :)
2020-04-29 16:06:20 <Cogitri> That'd a nice :)
2020-04-29 16:07:46 <ikke> I'll hold off pushing, so that I don't prevent that one from being merged
2020-04-29 16:25:34 <ikke> One arch left
2020-04-29 16:27:52 <PureTryOut[m]> Do triggers work with a specific file specified, or does it need a directory instead?
2020-04-29 16:47:58 <mps> dalias: https://lore.kernel.org/io-uring/6528f839-274d-9d46-dea6-b20a90ac8cf8@kernel.dk/T/#t
2020-04-29 16:48:13 <mps> musl don't have __off64_t ?
2020-04-29 16:50:32 <dalias> did you start a mess over loff_t?
2020-04-29 16:50:39 <dalias> loff_t is THE RIGHT TYPE for this
2020-04-29 16:50:42 <dalias> it
2020-04-29 16:51:01 <dalias> it's the type for kernel interfaces that always take a 64-bit offset regardless of whether off_t is 32- or 64-bit
2020-04-29 16:51:14 <ikke> Nice !7314 was merged
2020-04-29 16:52:04 <mps> dalias: if you by 'mess' mean my mail report about build fail on musl then yes, I started mess
2020-04-29 16:52:12 <dalias> *sigh*
2020-04-29 16:52:17 <dalias> loff_t was right all along
2020-04-29 16:52:19 <dalias> please get this reverted
2020-04-29 16:52:25 <dalias> you made it *more broken* with musl
2020-04-29 16:52:37 <dalias> we absolutely will never have a __off64_t because this is not a public type
2020-04-29 16:52:42 <dalias> it's glibc-internal crap
2020-04-29 16:53:05 <dalias> the only problem to begin with was that the application was missing #include <fcntl.h>
2020-04-29 16:53:14 <mps> yes, I noticed that musl don't have  __off64_t
2020-04-29 16:53:37 <dalias> in general musl does not have any types with "64" in their names except int64_t etc :)
2020-04-29 16:54:10 <dalias> (there are the macros for LFS64 mess but i'm trying to remove that)
2020-04-29 16:54:14 <mps> huh,
2020-04-29 16:54:38 <dalias> #define stat64 stat etc.
2020-04-29 16:54:47 <mps> why then including fctnl.h didn't worked
2020-04-29 16:54:56 <mps> not question to you but to me
2020-04-29 16:55:01 <dalias> hm maybe it only exposes loff_t with _GNU_SOURCE
2020-04-29 16:55:51 <dalias> yeah that seems to be the problem :/
2020-04-29 16:55:57 <mps> ohm, looks like
2020-04-29 16:56:21 <dalias> this is really inconsistent
2020-04-29 16:56:42 <dalias> in fcntl.h some extensions we expose with _BSD_SOURCE (_DEFAULT_SOURCE) and others only with _GNU_SOURCE (_ALL_SOURCE)
2020-04-29 16:56:52 <dalias> and there doesn't seem to be any consistent motivation for which goes where
2020-04-29 17:01:00 <mps> ok, thanks as always
2020-04-29 17:04:28 <andypost[m]> Nodejs in main depends on brotli in community, does it mean that brotli should be moved to main? https://git.alpinelinux.org/aports/tree/main/nodejs/APKBUILD#n60
2020-04-29 17:05:37 <ncopa> int64_t should be usable too. it should be in stdint.h
2020-04-29 17:05:54 <ncopa> andypost[m]: yes, i think so
2020-04-29 17:08:37 <dalias> yeah, i think int64_t would be an ok contract too
2020-04-29 17:08:46 <ncopa> its defined in posix
2020-04-29 17:08:48 <ncopa> If an implementation provides integer types with width 64 that meet these requirements, then the following types are required: int64_t uint64_t
2020-04-29 17:08:48 <ncopa> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
2020-04-29 17:08:48 <dalias> it won't in practice be the same type as loff_t, but the same representation
2020-04-29 17:10:30 <ncopa> mps: i think you did the right thing though, you were unsure and asked upstream
2020-04-29 17:17:14 <mps> I'm puzzled with something else, why not adding '#include <fcntl.h>' in file in liburing source work
2020-04-29 17:17:53 <mps> but adding '#define loff_t off_t' in same file works
2020-04-29 17:18:10 <ncopa> maybe it needed a -D_GNU_SOURCE in compile flags
2020-04-29 17:18:36 <ncopa> to tell musl that it is ok to use gnu extensions
2020-04-29 17:19:13 <mps> hmm, I removed -D_GNU_SOURCE
2020-04-29 17:19:25 <mps> lets revert to see
2020-04-29 17:20:13 <dalias> why'd you remove that?
2020-04-29 17:21:49 <mps> to test will it build
2020-04-29 17:22:25 <mps> but it doesn't not. same result with or without it
2020-04-29 17:29:45 <Hello71> ncopa: this is actually an ISO C requirement
2020-04-29 17:30:13 <Hello71> http://www.iso-9899.info/n1570.html#7.20.1.1
2020-04-29 17:30:37 <Hello71> These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two's complement representation, it shall define the corresponding typedef names.
2020-04-29 17:31:27 <Hello71> although 7.20.1 seems poorly specified in general. uint64_t is optional, but uint_least64_t is mandatory
2020-04-29 17:32:17 <mps> Hello71: heh, and I thought that uint64_t is mandatory. thanks
2020-04-29 17:32:27 <Hello71> I guess technically an implementation could skip 64
2020-04-29 17:33:25 <Hello71> now I wonder if the bit size has to be a power of two...
2020-04-29 17:33:41 <Hello71> knowing C, probably not
2020-04-29 17:34:59 <mps> good question, but I think without chances to consensus
2020-04-29 17:36:48 <Hello71> ah, yes, it is allowed, they are called "padding bits"
2020-04-29 17:40:05 <dalias> if CHAR_BIT is not 8 or 16 or 32, [u]int64_t can't exist
2020-04-29 17:40:11 <dalias> because it would necessarily have padding bits
2020-04-29 17:40:43 <dalias> note POSIX requires CHAR_BIT==8 so this is a non-issue except for archeologists of weird legacy machines
2020-04-29 17:48:26 <Hello71> but then neither could int8_t, int16_t, or int32_t
2020-04-29 17:48:41 <Hello71> my question was about why uint64_t is optional but uint_least64_t is required
2020-04-29 17:49:18 <Hello71> ISO C doesn't require any intn_t but still requires int_least64_t
2020-04-29 17:54:22 <ncopa> kunkku: while investigating why aconf does not build on aarch64 I noticed that there is a `.../lua/5.2/...` leftover. https://gitlab.alpinelinux.org/alpine/aports/-/commit/6a4bd30be4a96b1a685eb93600078fde0c994666#note_84733
2020-04-29 17:54:51 <ncopa> that is not the case why its failing though
2020-04-29 17:57:30 <dalias> hello71, right. POSIX requires 8/16/32. straight C doesn't
2020-04-29 18:02:17 <Hello71> but why does POSIX also require least64
2020-04-29 18:20:18 <ncopa> I know why aconf fails to build. It’s a nasty error in the dependency calculation
2020-04-29 18:22:50 <ncopa> lua-penlight needs lua-filesystem but there is no direct dependency to the exact version. 5.3 in this case.
2020-04-29 18:27:50 <ncopa> lua5.3-filesystem is supposed to be pulled in via an install_if=lua5.3 but in this case lua5.3 is not needed so it does not get pulled in.
2020-04-29 18:28:57 <ncopa> this is why I prefer less “elegant” solutions that are simple
2020-04-29 18:46:11 <kunkku> building works if I do "abulid rootbld"
2020-04-29 18:46:37 <kunkku> I wonder what the difference is
2020-04-29 18:46:55 <ncopa> do you have lua5.3 installed?
2020-04-29 18:47:13 <ncopa> does lua5.3 gets installed?
2020-04-29 18:48:21 <kunkku> aconf depends on uwsgi-lua which depends on lua5.3
2020-04-29 18:49:53 <ncopa> no, i dont think it depends on lua5.3
2020-04-29 18:50:17 <ncopa> it depends on so:liblua-5.3.so.0
2020-04-29 18:50:27 <ncopa> which is provided in lua5.3-libs
2020-04-29 19:18:42 <kunkku> there are anyway lots of packages that depend on lua5.3
2020-04-29 19:19:09 <ncopa> so why does build fail on build-edge-aarch64?
2020-04-29 19:22:10 <kunkku> the aarch64 build log shows success
2020-04-29 19:22:20 <kunkku> but failure on armhf
2020-04-29 19:23:41 <Ariadne> a lot of lua5.3 packages were failing to build
2020-04-29 19:26:33 <ncopa> my guess is that there were nasty indirect dependencies involved
2020-04-29 19:31:07 <kunkku> the error points to line 21 of makefile
2020-04-29 19:31:16 <kunkku> so it's ldoc that is failing
2020-04-29 19:40:57 <kunkku> https://github.com/stevedonovan/LDoc/blob/e97ba25d572821ddf4fe8d46fdf758bb552a6cf1/ldoc/tools.lua#L227
2020-04-29 19:40:59 <ncopa> the error i was looking at was due to lua filesystem missing
2020-04-29 19:41:15 <ncopa> so its a different error
2020-04-29 19:41:24 <kunkku> where's the build log?
2020-04-29 19:41:52 <ncopa> if aarch64 built successfully, then its overwritte
2020-04-29 19:42:04 <ncopa> https://build.alpinelinux.org/buildlogs/
2020-04-29 19:42:06 <kunkku> I was looking at https://gitlab.alpinelinux.org/alpine/aports/-/commit/6a4bd30be4a96b1a685eb93600078fde0c994666#note_84733
2020-04-29 19:42:21 <kunkku> sorry
2020-04-29 19:42:34 <ncopa> thats unrelated issue i found
2020-04-29 19:42:37 <ncopa> it looks wrong :)
2020-04-29 19:42:39 <kunkku> https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/aconf/aconf-0.8.0-r0.log
2020-04-29 19:44:08 <kunkku> ^^^ shows ldoc failing
2020-04-29 19:44:50 <kunkku> but lua5.3-filesystem got installed
2020-04-29 19:44:54 <mps> I see bug in tmux 3.1 which is fixed in 3.1a  but https://github.com/tmux/tmux/blob/master/CHANGES file already have 'CHANGES FROM 3.1 TO 3.2'
2020-04-29 19:45:17 <ncopa> kunkku: ok. that is different error then
2020-04-29 19:45:20 <mps> should we wait for 3.2 or upgrade to 3.1a
2020-04-29 19:45:45 <mps> in a hope that 3.2 release not be to late for alpine 3.12
2020-04-29 19:45:53 <ncopa> mps: i guess we can upgrade to 3.1a
2020-04-29 19:46:17 <mps> these changes file updated just one hour ago
2020-04-29 19:46:41 <ncopa> upgrade to 3.2 should not be too risky, so i dont think its a problem to upgrade in 3.12-stable
2020-04-29 19:46:43 <mps> let give them one hour
2020-04-29 19:47:25 <mps> I meant to say it will not be late for 3.12 if they release it in a day or two
2020-04-29 19:47:34 <mps> ?
2020-04-29 19:47:38 <ncopa> kunkku: aconf builds on my armhf dev machine as well
2020-04-29 19:47:58 <ncopa> mps: yeah, they have probably a week or so :)
2020-04-29 19:48:07 <kunkku> so this is a sporadic error
2020-04-29 19:48:20 <ncopa> could be filesystem related?
2020-04-29 19:48:44 <mps> ah, good. in any case I will create MR with 3.1a
2020-04-29 19:49:39 <kunkku> would have been interesting to see the other failure log
2020-04-29 19:49:59 <kunkku> two different sporadic errors?
2020-04-29 19:51:05 <ncopa> possibly
2020-04-29 19:51:22 <ncopa> the failure log is overwritten
2020-04-29 19:51:36 <ncopa> maybe its a race? and directory is not yet created?
2020-04-29 19:52:46 <kunkku> dir creation is failing
2020-04-29 19:53:07 <kunkku> on line 227 of ldoc/tools.lua
2020-04-29 19:53:30 <ikke> What to do about slang, which is failing to find -ltermcap
2020-04-29 19:55:08 <kunkku> one more try...
2020-04-29 19:56:06 <kunkku> hey, failure on mips64
2020-04-29 19:56:16 <kunkku> but where can I see that log?
2020-04-29 19:57:09 <Ariadne> that one is soemthing i asked in #alpine-infra for them to debug :P
2020-04-29 19:57:25 <Ariadne> because i'm not sure what to do
2020-04-29 19:57:36 <Ariadne> there is some plugin, but is access provisioned to upload the log, how is it set up, etc
2020-04-29 19:57:48 <ncopa> hum
2020-04-29 19:57:50 <ncopa> drats
2020-04-29 19:57:59 <ncopa> there are no buildlogs on mips64
2020-04-29 19:58:12 <ikke> Yeah, was looking for them as well
2020-04-29 19:58:15 <ncopa> need to investigate that
2020-04-29 19:58:29 <ikke> /var/lib/lxc/build-edge-mips64/rootfs/var/cache/distfiles/buildlogs/build-edge-mips64 is empty
2020-04-29 19:58:38 <ncopa> yeah
2020-04-29 19:58:48 <ncopa> need to investigate why that happens
2020-04-29 19:59:06 <ikke> it's buildrepo that's responsible for writing them, right?
2020-04-29 20:02:25 <ncopa> yes
2020-04-29 20:02:43 <ncopa> but it needs to be configured in /etc/conf.d/mqtt-exec.aports-build
2020-04-29 20:03:05 <ncopa> i have enabled it now
2020-04-29 20:03:09 <ncopa> need to rest
2020-04-29 20:03:12 <ncopa> its late
2020-04-29 20:03:16 <ikke> o/
2020-04-29 20:08:33 <mps> good night and sorry for today rush
2020-04-29 20:08:48 <mps> I thought we are a day near freeze
2020-04-29 20:09:29 <mps> ikke: what you think about fixing slang build? we need termcap lib
2020-04-29 20:11:27 <ikke> Yeah, was looking for it
2020-04-29 20:11:35 <ikke> Or disabling it if at all possible
2020-04-29 20:12:34 <ikke> I wonder what happened to it. It at least used to be able to be built at some point
2020-04-29 20:13:22 <ikke> https://pkgs.alpinelinux.org/contents?file=*termcap*&path=&name=&branch=v3.11&repo=main&arch=x86_64
2020-04-29 20:13:42 <mps> few pkgs, partimage, newt
2020-04-29 20:13:54 <ikke> I see termcap.h, but no .so
2020-04-29 20:14:08 <ikke> only zsh, but I cannot imagine that's what needed
2020-04-29 20:14:22 <mps> and in testing advancemame, slrn and most
2020-04-29 20:14:37 <ikke> depending on termcap?
2020-04-29 20:14:58 <mps> no, on slang-dev
2020-04-29 20:15:00 <ikke> right
2020-04-29 20:15:28 <ikke> I don't think we can disable it
2020-04-29 20:15:57 <mps> but this in ncurses 1ddf81ceeb970c550e0c14a22c9e1bef1d9026ac
2020-04-29 20:16:10 <mps> fixes #517
2020-04-29 20:16:13 <ikke> Yes, I found that commit, but 9 years ago
2020-04-29 20:16:44 <mps> yes, issue number is so low :)
2020-04-29 20:17:21 <ikke> so I can hardly imagine it being relevant
2020-04-29 20:17:28 <ikke> https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html
2020-04-29 20:17:50 <ikke> did termcap got replaced by terminfo?
2020-04-29 20:18:18 <mps> yes
2020-04-29 20:18:49 <mps> but some old software didn't switched, slang is example
2020-04-29 20:19:28 <ikke> ok
2020-04-29 20:19:43 <ikke> But how was it able to build in 3.11?
2020-04-29 20:20:01 <mps> oh, wait, slang have '--with-terminfo=xxx     Terminfo layout: default, hpux11, osf1r5, aix4, uwin'
2020-04-29 20:20:20 <ikke> yes, I saw that, wasn't sure if that was usefull
2020-04-29 20:20:37 <mps> also I'm not sure
2020-04-29 20:21:42 <ikke> hmff, builds on my container
2020-04-29 20:24:29 <ikke> testing on aarch64 now
2020-04-29 20:24:52 <ikke> fail
2020-04-29 20:25:00 <ikke> so it's arch dependent
2020-04-29 20:26:36 <ikke> interesting, on x86_64m, -ltermcap is not present
2020-04-29 20:26:39 <mps> hmm, passed on armv7
2020-04-29 20:26:43 <ikke> gcc -Os -fomit-frame-pointer   objs/slsh.o objs/readline.o -o objs/slsh_exe -Wl,--as-needed -Wl,-export-dynamic -L/home/build/aports/main/slang/src/slang-2.3.2/src/elfobjs -lslang   -ldl  -lm
2020-04-29 20:26:50 <ikke> x86_64
2020-04-29 20:27:02 <ikke> gcc -Os -fomit-frame-pointer   objs/slsh.o objs/readline.o -o objs/slsh_exe -Wl,--as-needed -Wl,-export-dynamic -L/home/build/aports/main/slang/src/slang-2.3.2/src/elfobjs -lslang   -ltermcap -ldl  -lm
2020-04-29 20:27:07 <ikke> aarch64
2020-04-29 20:28:11 <mps> it failed on x86_64 here
2020-04-29 20:28:34 <ikke> strange
2020-04-29 20:28:49 <mps> and on aarch64
2020-04-29 20:29:02 <mps> yes, strange
2020-04-29 20:29:54 <mps> anyone can point me to some guide how to send patch 'signed-off-by' to upstream
2020-04-29 20:30:08 <ikke> Just add -s with commit / format-patch
2020-04-29 20:30:21 <mps> ah, so easy
2020-04-29 20:30:36 <ikke> It's a statement
2020-04-29 20:31:17 <ikke> gcc -Os -fomit-frame-pointer   objs/slsh.o objs/readline.o -o objs/slsh_exe -Wl,--as-needed -Wl,-export-dynamic -L/home/build/aports/main/slang/src/slang-2.3.2/src/elfobjs -lslang   -ltermcap -ldl  -lm
2020-04-29 20:31:19 <ikke> arg
2020-04-29 20:31:23 <ikke> DYNAMIC_LIBS    =  -ldl  -lm
2020-04-29 20:31:28 <ikke> That's on x86_64
2020-04-29 20:31:34 <ikke> on aarch64, that include -ltermcap
2020-04-29 20:32:57 <ikke> trying to find out what decides whether termcap is included or not
2020-04-29 20:35:51 <ikke> hmm, interesting
2020-04-29 20:36:08 <ikke> ok
2020-04-29 20:36:17 <ikke> so if terminfo is installed, it doesn't use -ltermcap
2020-04-29 20:38:13 <ikke> so it needs a makedepend on ncurses, not just ncurses-dev?
2020-04-29 20:38:59 <ikke> ncurses-terminfo-base does not work because it's installed in /etc
2020-04-29 20:39:03 <ikke> mps: ^
2020-04-29 20:39:11 <mps> ah
2020-04-29 20:39:28 <mps> uh
2020-04-29 20:39:29 <ikke> yes, adding ncurses to makedepends makes it work
2020-04-29 20:39:36 <ikke> so what would be the proper solution?
2020-04-29 20:39:49 <ikke> patching it to look at /etc/terminfo?
2020-04-29 20:40:32 <mps> or /usr/share/terminfo, not sure
2020-04-29 20:41:02 <ikke> it looks there
2020-04-29 20:41:36 <ikke> /usr/lib/terminfo, /usr/share/terminfo, /usr/share/lib/terminfo, /usr/local/lib/terminfo
2020-04-29 20:42:13 <ikke> but because it only depends on ncurses-dev, ncurses-terminfo-base is installed, which only has files in /etc/terminfo
2020-04-29 20:42:32 <mps> ehm, true, failed on armv7 without ncurses
2020-04-29 20:42:57 <mps> aha, good you found it
2020-04-29 20:43:36 <ikke> only because by chance I had ncurses installed on my local dev container
2020-04-29 20:43:58 <mps> also I had on armv7 :)
2020-04-29 20:44:09 <ikke> right
2020-04-29 20:44:18 <mps> when removed it build failed also there
2020-04-29 20:45:20 <mps> so, it will makedepends on ncurses-terminfo also or fixed to look in /etc/terminfo
2020-04-29 20:45:33 <ikke> I'm trying the latter
2020-04-29 20:46:15 <mps> '--with-terminfo=xxx' will not help I think
2020-04-29 20:51:35 <ikke> I think it works
2020-04-29 20:53:12 <mps> I'm searching where mode_t type is defined in musl, not related to slang problem
2020-04-29 21:04:26 <ikke> mps: http://tpaste.us/onbL
2020-04-29 21:05:56 <mps> nice
2020-04-29 21:06:22 <mps> why 'pwd' in prepare()
2020-04-29 21:06:58 <ikke> debug
2020-04-29 21:07:07 <mps> hehe
2020-04-29 21:07:35 <mps> print/f is best debug tool :)
2020-04-29 21:07:38 <ikke> hehe
2020-04-29 21:13:36 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7355
2020-04-29 21:18:08 <ikke> good that I put it through CI :)
2020-04-29 21:18:19 <ikke> forgot to update the checksum after adding a patch header
2020-04-29 21:31:34 <ikke> TBK[m] was also working on slang apparently
2020-04-29 23:08:30 <TBK[m]> ikke: I have update the MR. So it should be ready to be merged.
2020-04-29 23:08:47 <TBK[m]> Anybody with main access please merge !7357
2020-04-29 23:09:27 <TBK[m]> Feedback wanted on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7349#note_84782
2020-04-29 23:18:23 <maxice8> How annoying, so many xf86-video-* stuff fail due to old CPP macros that don't work in newer GCC
2020-04-29 23:18:32 <maxice8> can we move graphical stuff into community ?
2020-04-29 23:25:59 <maxice8> @TBK can you push your fix for slang ?
2020-04-30 00:08:18 <TBK[m]> maxice8: You are welcome to merge it. I can't, since I do not have perms for main.
2020-04-30 00:08:49 <maxice8> i only see ikke's MR
2020-04-30 00:09:18 <TBK[m]> I pushed my changes to ikke's MR.
2020-04-30 00:09:23 <maxice8> i see
2020-04-30 04:36:06 <ikke> ugh, now slang has a failing test due to mising stdin?
2020-04-30 07:01:46 <ikke> Is there a good way to see if a certain package was succesfully built for 3.12 for a certain arch?
2020-04-30 07:05:19 <clandmeter> ssh@builder i would assume
2020-04-30 07:05:35 <ikke> right, so only for people with builder access
2020-04-30 07:05:50 <clandmeter> i dont think it will rsync before the repo is ready
2020-04-30 07:08:57 <clandmeter> well you could expose the packages dir via http, but i don't think we want that.
2020-04-30 07:25:34 <ncopa> i guess you could see the buildlog
2020-04-30 07:27:23 <ikke> yes, but you would need to guess the url
2020-04-30 07:32:26 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=3.12.0&label_name[]=type%3Abuild-failure
2020-04-30 08:06:23 <ncopa> ikke: thanks!
2020-04-30 08:06:48 <ncopa> kunkku: i got the lua penlight/filesystem error: http://tpaste.us/b4mB
2020-04-30 08:07:57 <ikke> Oh, fun, even a couple of CVE's for Samba
2020-04-30 08:55:19 <kunkku> ncopa: this is interesting
2020-04-30 08:55:35 <kunkku> (23/26) Installing lua5.3-filesystem (1.7.0.2-r1)
2020-04-30 08:58:12 <kunkku> do you know how to reproduce?
2020-04-30 09:21:15 <ncopa> no
2020-04-30 09:52:06 <Ganwell> ikke: mqtt can show you build errors: https://git.io/JvaEz
2020-04-30 09:52:31 <ikke> Ganwell: I'm well aware
2020-04-30 09:52:53 <ikke> I have #alpine-commits constantly open :)
2020-04-30 09:53:26 <ikke> I even suggested that approach to you :)
2020-04-30 09:53:59 <ikke> My usecase is finding out whether a certain build issue just happens on one arch or not
2020-04-30 09:54:06 <ikke> (or a few arches)
2020-04-30 09:54:33 <ikke> oooh, we get mips64 build errors now
2020-04-30 09:54:39 <ikke> in #alpine-commits
2020-04-30 09:57:02 <Ganwell> ikke: In that case thanks a lot. :-)
2020-04-30 10:02:37 <Ganwell> ikke: the logs have an index, you don't have to guess, not? https://build.alpinelinux.org/buildlogs/build-3-12-ppc64le/
2020-04-30 10:28:34 <PureTryOut[m]> So I still have qt5-qtbase-opengl installed from messing around with it earlier, and can't get rid of it because stuff depends on it. Isn't the `upgrade --available` switch meant to replace the package if I have removed it from my local repos for the one from Alpine?
2020-04-30 10:29:16 <PureTryOut[m]> Can I somehow force uninstall the package no matter the fact that packages depend on it (and will thus temporarily break)?
2020-04-30 10:29:42 <ikke> Not that I'm aware of
2020-04-30 10:30:46 <PureTryOut[m]> So I guess I have to rebuild qt5-qtbase with a temporarily added `replaces=qt5-qtbase-opengl` just to upgrade to it once, then remove it again in favor of the Alpine version...?
2020-04-30 10:30:54 <Cogitri> You can force your will by doing `mv /etc/apk/world /etc/apk/world.orig && echo "alpine-base" > /etc/apk/world && apk upgrade -a && mv /etc/apk/world.orig /etc/apk/world && apk upgrade -a`, which effectively uninstalls and reinstalls your system once
2020-04-30 10:31:50 <PureTryOut[m]> That seems really dangerous lol, but I guess that should work indeed
2020-04-30 10:43:27 <PureTryOut[m]> That did the trick, thanks!
2020-04-30 10:46:44 <ikke> trying to reproduce the slang test error, but it succeeds for me even if I run it without tty (with nq)
2020-04-30 10:48:19 <ikke> hmm, not sure nq runs without tty
2020-04-30 10:57:36 <ikke> nohup is also passing
2020-04-30 10:58:26 <ikke> same for setsid :-/
2020-04-30 11:05:40 <mps> ikke: this 'Testing process functions...wc: standard input: Bad file descriptor'
2020-04-30 11:05:43 <mps> ?
2020-04-30 11:05:59 <ikke> yes
2020-04-30 11:06:04 <ikke> cannot reproduce it
2020-04-30 11:06:58 <ikke> building in a prestine container now, but even there it succeeds
2020-04-30 11:07:05 <mps> did you looked at this test, or simply disable it
2020-04-30 11:07:17 <ikke> no, not yet
2020-04-30 11:09:39 <mps> if you are tired of this, I can look when I come back to home later on evening
2020-04-30 11:26:28 <Ganwell> iirc sometimes things fail because on CI or builder there is no real tty and when you test it locally you have tty.
2020-04-30 11:29:30 <mps> Ganwell: yes
2020-04-30 11:30:30 <mps> some test writers doesn't have builders in mind when write tests
2020-04-30 11:34:12 <ikke> Ganwell: but it succeeded in CI
2020-04-30 11:34:37 <ikke> And even if I do all kinds of tricks to make sure therer is no tty to the controlling terminal
2020-04-30 11:34:44 <ikke> (setsid, nohup, etc)
2020-04-30 11:35:43 <ikke> This is the test btw: http://tpaste.us/7Kd1
2020-04-30 11:42:15 <Ganwell> hmm, I check it when I get back. Another guess: ulimit or sandboxing (I don't know who the builders are set up)
2020-04-30 11:47:11 <ikke> builders use lxc
2020-04-30 11:48:13 <ikke> Can it be that the filedescripters they use might already be in use on the builder?
2020-04-30 11:48:48 <ikke> they use hardcoded descriptor numbers
2020-04-30 13:32:42 <andypost> Who can merge !7349 looks few packages involved
2020-04-30 13:34:11 <ikke> I don't think dependent packages need to be rebuilt
2020-04-30 13:35:26 <ikke> 'fix' for slang: http://tpaste.us/1Ode (disable that specific test)
2020-04-30 13:45:29 <andypost[m]> ikke libs moved to other package, so rebuild required
2020-04-30 13:46:53 <ikke> the run-time deps are on soname, so that should be automatically pick the correct package, right?
2020-04-30 13:49:52 <ikke> http://tpaste.us/pK7k
2020-04-30 13:50:01 <ikke> it has no direct dependency on brotli
2020-04-30 14:26:27 <ncopa> ikke: https://tpaste.us/1Ode looks wrong
2020-04-30 14:26:48 <ikke> ok?
2020-04-30 14:26:54 <ncopa> you end up doing start_test() but no end_test()
2020-04-30 14:27:08 <ikke> It's not a real test suite
2020-04-30 14:27:09 <ncopa> i dont know if there are allocations that needs to be deallocated etc
2020-04-30 14:27:19 <ikke> they are functions that are defined in common.sl
2020-04-30 14:27:57 <ikke> It just prints OK if the test succeeded, and exits otherwise
2020-04-30 14:28:25 <ikke> http://tpaste.us/WRgv
2020-04-30 14:28:38 <ncopa> ok. I didnt say it was wrong. I just think it *looks* wrong :)
2020-04-30 14:28:54 <ikke> nod
2020-04-30 14:29:05 <ikke> thanks for reviewing
2020-04-30 14:29:06 <ncopa> pushit
2020-04-30 14:29:45 <ikke> done
2020-04-30 14:30:27 <ncopa> Cogitri: sorry if I sound harsh in email on enforcing patches. I appreciate that you work on upstreaming patches and help us track upstream state
2020-04-30 14:30:44 <ncopa> I agree that some sort of info included in patch header is good
2020-04-30 14:30:55 <Cogitri> Ah, no worries, I didn't think that you sounded harsh :)
2020-04-30 14:31:23 <Cogitri> (Sorry if I sounded harsh in my reply)
2020-04-30 14:31:24 <ncopa> and i think its good with standards
2020-04-30 14:31:40 <ncopa> even non-optimal standards are better than no standard
2020-04-30 14:40:36 <PureTryOut[m]> ncopa: did you sign the CLA yet for this? https://github.com/python/cpython/pull/18380
2020-04-30 14:40:45 <PureTryOut[m]> It seems I need that PR lol
2020-04-30 14:45:36 <mps> Cogitri: patches proposal on ML: too much formalism, imo
2020-04-30 14:48:56 <ncopa> PureTryOut[m]: i did. https://github.com/python/cpython/pull/18380#event-3116936541
2020-04-30 14:49:27 <PureTryOut[m]> Oh woops missed that. Cool, hope it gets merged soon and put into a release
2020-04-30 14:49:39 <ncopa> I think we have that patch or similar in alpine already
2020-04-30 14:50:00 <ncopa> i think i spent a day on making it suitable for upstream
2020-04-30 14:50:25 <PureTryOut[m]> Yeah but I need it in upstream before I can make some other project use it
2020-04-30 14:50:47 <Cogitri> mps: It's like 3 lines you need to add to the patch
2020-04-30 14:51:05 <Cogitri> I'm not too attached to that specific form of the patch header, I think we just need some system to track upstream progress for patches
2020-04-30 14:51:31 <Cogitri> Because the current situation where we have many, many downstream patches in our repos kind of sucks
2020-04-30 14:51:53 <mps> I'm not against add comments, but think it is not need to be formalized, would call it good practice
2020-04-30 14:53:16 <mps> maybe call it 'best practice' and add some guides and not formal 'MUST BE THAT' document
2020-04-30 14:53:48 <ncopa> PureTryOut[m]: feel free to comment on it "what is the status here?" it may make upstream aware that it is a problem for different set of users
2020-04-30 14:54:02 <PureTryOut[m]> Ah sure good call
2020-04-30 14:54:22 <mps> and good idea is to tell git commit msg from where the patch is taken
2020-04-30 14:54:35 <mps> in msg*
2020-04-30 14:54:36 <Cogitri> mps: Well, I'm fine with making it a best practice, as long as that doesn't mean that almost everyone ignores it
2020-04-30 14:54:56 <ncopa> documenting it is a good step forward
2020-04-30 14:55:07 <Cogitri> Yes, I just hate having 100+ LOC patches without any context which don't apply anymore
2020-04-30 14:55:17 <ncopa> +1
2020-04-30 14:55:23 <Cogitri> And then I have to guess whether they're still required, if they've been upstreamed and who wrote that thing
2020-04-30 14:55:39 <mps> there will be always some people who will ignore whatever is written
2020-04-30 14:56:08 <Cogitri> Well yes, but then reviewers can tell them to follow the Alpine guidelines if they want their patch to be included
2020-04-30 14:56:24 <ikke> I was already working on linting for this as well (if accepted)
2020-04-30 14:56:26 <mps> we should start by our personal examples
2020-04-30 14:56:35 <ikke> I already started
2020-04-30 14:56:45 <Cogitri> I do it too
2020-04-30 14:56:54 <Cogitri> ikke: A linter for that would be amazing :)
2020-04-30 14:57:10 <mps> well, sometimes I do but sometimes not
2020-04-30 14:57:29 <mps> though I always add comment in git msg
2020-04-30 14:57:42 <Cogitri> How about we just make it a warning like the other lints and if the reviewers feel it's necessary they can mention it in the review for a MR?
2020-04-30 14:57:57 <Cogitri> That's a bit inconsistent, but I hope we get the patch headers on most patches then nontheless
2020-04-30 14:58:32 <mps> not sure, maybe ok
2020-04-30 14:59:04 <mps> I'm more to 'teach by guiding with my/our examples'
2020-04-30 14:59:39 <ncopa> I was to say that I also always add the info in git commit or in patch header, but git log shows that I dont....
2020-04-30 14:59:50 <Cogitri> Heh
2020-04-30 15:00:09 <ncopa> 986f344c35ae51e45f9b1260f3919e389885321a
2020-04-30 15:00:12 <mps> :)
2020-04-30 15:00:13 <Cogitri> Sometimes I'm surprised when git blame proves me wrong too :D
2020-04-30 15:00:37 <ncopa> i never bothered to report it upstream, i just wanted to fix the builders
2020-04-30 15:00:37 <Cogitri> But that's a pretty trivial patch so I'd argue that's fine
2020-04-30 15:00:55 <ikke> yeah, linting so far always has been a warning
2020-04-30 15:00:55 <ncopa> same with this: 7323eb6d10cef1a4079404c65a975094b09e5851
2020-04-30 15:01:34 <ncopa> this one is worse. afca9c479889abe4fd85c50b799ae410c11e9cf8 I found it somewhere but i didnt document where.
2020-04-30 15:01:54 <ncopa> and now i dont remember anymore :)
2020-04-30 15:02:47 <mps> how I do upstream for example, https://git.kernel.dk/cgit/liburing/commit/?id=8171778c835b6be517c314cf23dd1f5ae061a117
2020-04-30 15:02:48 <ncopa> this one is a patch from upstream. I should have added an URL to upstream-commit  2eb2dada1a855d3d43d8867f0605b9ed42cbb6af
2020-04-30 15:03:18 <ncopa> ah. finally! i found a patch where i didnt mess up :) 3c82796fd36ef7e1ca5252967a3ddcb70cfb1a33
2020-04-30 15:03:32 <Cogitri> Nice :)
2020-04-30 15:04:19 <Cogitri> mps: Huh, the commit looks like upstream accepted it already?
2020-04-30 15:04:40 <mps> yes, he is fast
2020-04-30 15:05:19 <Cogitri> Then I don't quite understand your question
2020-04-30 15:05:20 <mps> posted it few minutes ago, and because this link is 'at hand' :)
2020-04-30 15:06:21 <mps> what question? I didn't asked one, I think
2020-04-30 15:06:37 <Cogitri> > how I do upstream for example
2020-04-30 15:06:37 <Cogitri> I thought that's a quesiton
2020-04-30 15:07:33 <Cogitri> Also, not on topic, but I can still merge bug fix releases like !7372, right?
2020-04-30 15:07:40 <mps> no, I wanted to say that I'm not against adding context to patches and this is example that I do that
2020-04-30 15:08:22 <Cogitri> Ahh, okay
2020-04-30 15:08:44 <mps> translating from my native lang to english straight from the head doesn't work well
2020-04-30 15:09:11 <mps> your point is correct
2020-04-30 15:10:00 <mps> s/point/note/
2020-04-30 15:10:00 <alpine-meetbot> mps meant to say: your note is correct
2020-04-30 15:24:33 <ikke> Hmm, we seem to have a file conflict
2020-04-30 15:24:40 <ikke> ERROR: util-linux-2.35.1-r1: trying to overwrite usr/bin/hexdump owned by perl-data-hexdump-0.02-r2.
2020-04-30 15:25:44 <Cogitri> > ERROR: slang-2.3.2-r0: BAD signature
2020-04-30 15:25:44 <Cogitri> That just hit me on CI
2020-04-30 15:26:23 <ikke> hmm
2020-04-30 15:26:33 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7372
2020-04-30 15:28:32 <ikke> That seems to imply that it was rebuilt for some reason
2020-04-30 15:32:17 <Cogitri> Seems like it's happy now
2020-04-30 15:33:18 <ikke> hmm, for me it still gives issues
2020-04-30 15:34:42 <ikke> Now fixed, purged if from CDN
2020-04-30 15:34:43 <Cogitri> Ah, same: https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/105145#L729
2020-04-30 15:35:46 <ikke> can you retry now?
2020-04-30 15:35:52 <ikke> I purged it on all arches
2020-04-30 15:40:29 <Cogitri> Works now, thanks :)
2020-04-30 16:02:13 <Cogitri> Maybe someone who knows libreoffice a bit can take a look at !7371 ?
2020-04-30 16:29:50 <Cogitri> Can we drop freeswitch? Doesn't build without !6647
2020-04-30 16:30:02 <Cogitri> And I wasn't figure out how to massage Autotools into working
2020-04-30 16:33:03 <Cogitri> And upstream just said that they only support Debian so I'm not too invested into fixing it
2020-04-30 16:35:24 <maxice8> sounds good to meeee
2020-04-30 17:26:07 <Ariadne> ikke: thanks for addressing that, i did not wish to do it
2020-04-30 17:26:15 <ikke> :)
2020-04-30 17:26:54 <Ariadne> also i think the put down was entirely unnecessary really, we should strive to be friendly
2020-04-30 17:28:23 <ikke> I feel jirutka lacks a sense of empathy
2020-04-30 17:29:18 <ikke> But lets not digress
2020-04-30 17:31:25 <Ariadne> indeed
2020-04-30 17:33:12 <Ariadne> TBK[m]: in future, if you split out a subpackage, it would be useful if you could document that in the commit message, instead of just "modernize".  i let it slide this time because unbreaking the 3.12 builders is somewhat urgent, otherwise i wouldn't have merged it
2020-04-30 17:34:48 <Ariadne> and to that end, i am going to get some lunch
2020-04-30 17:35:03 <Ariadne> these loongson guys are interesting
2020-04-30 17:36:48 <Cogitri> Yup
2020-04-30 17:45:13 <Cogitri> Maybe someone with main bits can take a look at !7384
2020-04-30 17:45:39 <Ariadne> we have folks using freeswitch in production
2020-04-30 17:45:54 <Ariadne> so just dropping it is not really a great approach
2020-04-30 17:46:09 <Cogitri> Well, upstream explictly said that they only support Debian and I can't get the thing to work because Autotools is a bit special
2020-04-30 17:46:36 <Cogitri> I mean I'd prefer to fix it of course, but I have no clue how to do so, especially if upstream goes meh
2020-04-30 17:48:10 <Ariadne> i was planning to work on it this afternoon :)
2020-04-30 17:48:29 <Cogitri> Ah okay, I just saw that the builders started tripping over it
2020-04-30 17:49:04 <Cogitri> !6647 is how far I got if you want to base your work on that
2020-04-30 17:54:54 <Cogitri> Can someone move #10122 to the mkinitfs repo?
2020-04-30 18:07:54 <Cogitri> mps: You had working boot on a Pi Zero, right? Can you take a look at #10224 ?
2020-04-30 18:19:42 <mps> Cogitri: will do, but this is old and I think there was issue with kernel, though not sure
2020-04-30 18:20:16 <mps> armhf-3.9.2 and armhf-3.9.3 are release tarballs I think
2020-04-30 18:24:35 <Cogitri> Yes, it probably doesn't apply anymore, I just wanted to make sure of it before I go ahead and close it
2020-04-30 18:26:08 <mps> ok
2020-04-30 18:26:33 <mps> I'm out of home again, will do when I come back
2020-04-30 19:05:17 <maxice8> https://build.alpinelinux.org/buildlogs/build-3-12-s390x/main/samba/samba-4.12.2-r0.log
2020-04-30 19:05:36 <maxice8> samba is failing on s390x 3-12 because of missing dnssec-root
2020-04-30 19:17:56 <ikke> well, bind-dnssec-root is missing it
2020-04-30 19:18:07 <ikke> I suspect a circular dependency
2020-04-30 19:18:24 <ikke> maxice8: fyi: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11462
2020-04-30 19:18:44 <maxice8> nice
2020-04-30 19:18:57 <maxice8> the issue in gitlab, not the issue in the package
2020-04-30 19:19:02 <ikke> :)
2020-04-30 19:19:15 <ikke> Trying to create issues for all the build issues that are not fixed quickly
2020-04-30 19:19:52 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=3.12.0&label_name[]=type%3Abuild-failure
2020-04-30 19:20:25 <maxice8> nice
2020-04-30 19:47:34 <mps> Cogitri: wrote a comment to #10224
2020-04-30 19:47:58 <mps> not sure should it be closed after my comment
2020-04-30 19:48:15 <Cogitri> Yup, thanks for checking! :)
2020-04-30 19:48:24 <mps> np :)
2020-04-30 19:49:43 <mps> though I didn't tested 3.9.4 and 3.9.5 but I think it is not important because 3.9.6 works fine
2020-04-30 19:51:03 <Cogitri> Yup, I don't think it matters if the old unsupport releases still work
2020-04-30 19:52:04 <mps> agree
2020-04-30 20:54:27 <Ganwell> I am trying to boot alpine in qemu for different archs. I boot it like this: https://git.io/JfOBW. I was able to create the root.squashfs for x86_64 from my system. What is the best to create it for other archs?
2020-04-30 21:00:05 <Ganwell> Ah, apk add --root x --arch y
2020-04-30 21:24:48 <mps> ncopa: https://github.com/nhorman/rng-tools/commit/a4b6d9ce64f132e463b9091d0536913ddaf11516
2020-04-30 21:25:14 <mps> your patch to rng-tools is applied upstream
2020-04-30 22:28:52 <[[sroracle]]> [11:02] <Cogitri> Maybe someone who knows libreoffice a bit can take a look at !7371 ?
2020-04-30 22:29:11 <[[sroracle]]> the bit about xsltfilter seems unrelated. but i think moving xdg around is the right idea.
2020-04-30 22:31:12 <[[sroracle]]> it seems odd that this needs to be handled specially though
2020-04-30 22:31:58 <[[sroracle]]> ah i see. i should poke upstream about that
2020-04-30 22:34:00 <[[sroracle]]> now, whether this merits a full rebuild of libreoffice of all things... :)