2020-03-01 00:03:43 <timlegge> just pushed some changes to abuild/apkbuild-cpan.in https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/34 if anyone has time to review
2020-03-01 06:00:01 <Ariadne> I slept almost all day, 5.4.23 in about an hour
2020-03-01 06:15:37 <oneinsect> lucky you
2020-03-01 06:23:52 <Ariadne> _ikke_: https://distfiles.dereferenced.org/rpi-5.4.23-alpine.patch
2020-03-01 06:40:26 <_ikke_> Ariadne: done
2020-03-01 06:40:42 <Ariadne> oh I wasn't expecting you to still be up
2020-03-01 06:40:55 <_ikke_> Ariadne: It's the other way aroud
2020-03-01 06:41:00 <Ariadne> okay I'll push rpi kernels after my IHOP visit is concluded
2020-03-01 12:29:53 <PureTryOut[m]> Cogitri: Do you by any chance have an account on https://source.puri.sm and if not, could you create one?
2020-03-01 12:30:02 <PureTryOut[m]> I'd like to tag you in https://source.puri.sm/Librem5/phosh/issues/278
2020-03-01 12:30:04 <nmeum> does youtube-dl really need py3-setuptools in $depends can't it be moved to makedepends?
2020-03-01 12:30:58 <maxice8> nmeun check if the Youtube-dl binary calls pkg_resources
2020-03-01 12:31:03 <maxice8> If yes then yes it is required
2020-03-01 12:31:28 <maxice8> Lots of py stuff that provide binaries use pkg_resources
2020-03-01 12:32:19 <nmeum> doesn't seem to be any mention of pkg_resources in the source code
2020-03-01 12:32:21 <nmeum> https://github.com/ytdl-org/youtube-dl/search?q=pkg_resources&unscoped_q=pkg_resources
2020-03-01 12:33:27 <maxice8> nmeun look at the binary
2020-03-01 12:33:29 <maxice8> cmonBruh
2020-03-01 12:33:48 <nmeum> I don't know python :p
2020-03-01 12:33:54 <maxice8> http://ix.io/2d5L
2020-03-01 12:34:08 <maxice8> the installed binary
2020-03-01 12:34:28 <Cogitri> PureTryOut[m]: Ah sure, I can create one
2020-03-01 12:34:39 <nmeum> maxice8
2020-03-01 12:34:46 <nmeum> maxice8: ah, good to know
2020-03-01 12:34:57 <PureTryOut[m]> Cool thanks
2020-03-01 12:36:45 <PureTryOut[m]> Please give me your username when done
2020-03-01 12:37:32 <Cogitri> Done
2020-03-01 12:37:37 <Cogitri> Well, it's Cogitri :P
2020-03-01 12:42:00 <PureTryOut[m]> Seems gsound is also a missing dep?
2020-03-01 12:46:44 <PureTryOut[m]> https://source.puri.sm/Librem5/phosh/-/jobs/251592#L142
2020-03-01 12:56:19 <Cogitri> No
2020-03-01 12:56:32 <Cogitri> That's because it tries to configure libfeedback as a submodule (which needs gsound)
2020-03-01 13:55:18 <PureTryOut[m]> Ah ok
2020-03-01 13:57:55 <Cogitri> feedbackd is failing on 32-bit right now though, waiting fir an upstream fix
2020-03-01 13:58:03 <Cogitri> s/fir/for/
2020-03-01 13:58:04 <alpine-meetbot> Cogitri meant to say: feedbackd is failing on 32-bit right now though, waiting for an upstream fix
2020-03-01 15:11:32 <Cogitri> I got `ERROR: py3-packaging-20.1-r1: failed to rename usr/lib/python3.8/site-packages/.apk.cdc7557dcd13288ee08158d4619f716362dc9eee35506986 to usr/lib/python3.8/site-packages/packaging-20.1-py3.8.egg-info.` on multiple machines of mine
2020-03-01 15:11:41 <Cogitri> Same foor py3-six
2020-03-01 15:12:12 <Cogitri> `apk fix` apparently takes care of it but I'm still curious why this would even happen on upgrades
2020-03-01 18:46:23 <oneinsect> folks do we have an abuild static version like apk-tools-static?
2020-03-01 18:49:47 <oneinsect> never mind they arent executables (which is really excellent decision) makes it very easy for bootstrapping...except for say abuild-sudo etc
2020-03-01 19:59:50 <_ikke_> maxice8: abiword and gtkspell are failing
2020-03-01 21:19:29 <Cogitri> Is there some documentation to libapk somewhere?
2020-03-02 07:38:29 <mps> Cogitri: good morning, why do you moved firefox to community
2020-03-02 07:39:11 <mps> what was reasons for that move
2020-03-02 07:39:43 <Cogitri> Ah, that wasn't meant to be merged just yet
2020-03-02 07:40:26 <Cogitri> Anyway, I feel like we should provide Firefox in stable releases too, although it'll mean that we/me will have to bump nss/nspr/Firefox in stable releases
2020-03-02 07:40:44 <mps> firefox is intended to stay in testing, and firefox-esr in community. this is discussed long time ago
2020-03-02 07:40:50 <Cogitri> Or we could just use the vendored nss and nspr in FF on stable releases once the versions in our repos don't do it anymore
2020-03-02 07:41:36 <Cogitri> Yeah, I kind of wanted to have the MR as discussion ground for that since I wasn't around when that discussion happened I suppose, but I forgot to mark the MR as WIP so it got merged
2020-03-02 07:42:03 <mps> not sure will the secfixes for firefox (newest) be easy to keep in community
2020-03-02 07:42:51 <Cogitri> Well, it'd be kind of like a leaf package in Debian, we'd have to do major bumps for FF too
2020-03-02 07:43:11 <Cogitri> But since FF isn't a library that doesn't seem like too much of a problem to me
2020-03-02 07:43:14 <mps> yes, something like that
2020-03-02 07:44:04 <Cogitri> If you're not OK with the change, I'd fine with reverting it
2020-03-02 07:44:30 <mps> but backporting new releases of firefox will require backport not only firefox but some libs and maybe even rust
2020-03-02 07:44:35 <Cogitri> Actually, I think we'd have bump Rust too in stable releases for FF (which might not be a bad idea anyway)
2020-03-02 07:44:47 <Cogitri> I don't think we'd need to backport anything but FF and Rust
2020-03-02 07:45:17 <mps> backporting such complex things is (well) problematic sometimes
2020-03-02 07:45:48 <Cogitri> The only libs FF has strong version requirements on are nss and nspr and those should be upgraded anyway to get secfixes (or we can use the vendored versions if we don't want to upgrade the ones in the repos)
2020-03-02 07:46:09 <mps> I'm not sure, I think you know better problems with rust bacporting
2020-03-02 07:46:41 <mps> and I think backporting rust will require a lot of rebuilds
2020-03-02 07:46:53 <Cogitri> Why do you think that?
2020-03-02 07:47:11 <Cogitri> Bumping Rust doesn't require rebuilds of anything but Rust
2020-03-02 07:48:09 <Cogitri> The only thing that seems problematic to me with backporting Rust is that it tends to break compatibility in some ways over minor releases (with a deprecation process though)
2020-03-02 07:48:20 <Cogitri> So it's not really stable in that sense
2020-03-02 07:49:10 <mps> maybe not at official release, but if someone wants to rebuid stable release then (from experience) backported rust could have such changes that can make issues with packages which are already in stable
2020-03-02 07:49:36 <Cogitri> Since Rust is statically linked nothing should have to be rebuilt
2020-03-02 07:49:38 <mps> heh, you told better than me
2020-03-02 07:49:50 <Cogitri> But yes, it could cause build issues
2020-03-02 07:50:08 <Cogitri> But I think we're in a bad spot with rust either way: Either we keep Rust at a low version and aren't able to build new stuff on stable releases (since crates like to jump on new Rust features early)
2020-03-02 07:50:35 <Cogitri> Or we upgrade and potentially break the build of other packages which relied on deprecated behaviour
2020-03-02 07:50:59 <mps> yes, there are my concerns
2020-03-02 07:51:09 <mps> s/there/these/
2020-03-02 07:51:10 <alpine-meetbot> mps meant to say: yes, these are my concerns
2020-03-02 07:51:10 <Cogitri> (Although the situation isn't _that_ bad, at least I haven't been hit with that in any of my Rust crated yet)
2020-03-02 07:52:04 <Cogitri> The only thing that hit multiple crates that I know of is when the Rust team noticed that Rustc allowed handing out a &mut and & at the same time, so it made sense to error out on that (and it was an easy fix)
2020-03-02 07:52:24 <Cogitri> Anyway, I agree that FF shouldn't have been moved to community just like that
2020-03-02 07:52:29 <mps> ok, still not sure if we should backport rust, or any such complex compiler
2020-03-02 07:52:45 <Cogitri> Sorry about that, should've marked the MR as WIP do it wouldn't get merged
2020-03-02 07:52:50 <Cogitri> s/do/so/
2020-03-02 07:52:51 <alpine-meetbot> Cogitri meant to say: Sorry about that, should've marked the MR as WIP so it wouldn't get merged
2020-03-02 07:53:32 <mps> well, I don't know what to do, just expressed my concerns
2020-03-02 07:53:42 <Cogitri> Didn't expect someone else to merge my move-to-community spree
2020-03-02 07:54:16 <Cogitri> I'll post something on the ML and see what the other devs think and will move it back to testing if the others agree with your concerns, mps
2020-03-02 07:54:21 <mps> and, no need to sorry, mistakes and errors happens in development, especially with complex things
2020-03-02 07:54:22 <Cogitri> Thanks for the heads up :)
2020-03-02 07:54:59 <mps> np, really :)
2020-03-02 09:13:03 <aparcar[m]> Hi all, does Alpine has an machine readable format of releases? Or differently, does Alpine support a notification system like "New release X.Y.Z" available, and if so how does the file look like storing such information?
2020-03-02 09:17:39 <_ikke_> There is an rss feed for releases: https://www.alpinelinux.org/atom.xml
2020-03-02 09:17:57 <_ikke_> Well, mostly alpine related news
2020-03-02 09:18:13 <_ikke_> We are working on a machine readable release feed
2020-03-02 09:22:02 <aparcar[m]> _ikke_: can you elaborate? I'm trying to do something similar for OpenWrt
2020-03-02 09:22:18 <aparcar[m]> I hoped you got already something nice in place :)
2020-03-02 09:22:46 <aparcar[m]> downloading APKINDEX seems a bit much for daily release checks
2020-03-02 09:23:22 <aparcar[m]> thats fo far the only place I could find a machine readable info
2020-03-02 09:23:24 <_ikke_> we do use mqtt where git commit messages are announced on
2020-03-02 09:24:53 <clandmeter> aparcar[m]: there is an issue on gitlab which should implement such feature
2020-03-02 09:25:18 <aparcar[m]> clandmeter: I'm not familiar with the alpine infra, can you please send me the link?
2020-03-02 09:25:50 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10672
2020-03-02 09:33:13 <aparcar[m]> clandmeter: thank you!
2020-03-02 09:33:47 <clandmeter> yw
2020-03-02 10:00:57 <sauerbraten> I read that there is an issue with Go 1.14 with some kernels (5.2+), but since alpine is still using 4.19, that should not be a problem to update the Go package, right?
2020-03-02 10:01:54 <sauerbraten> I prepared a patch to the patch in aports to make abump go-1.14 work, can I just leave this here for someone? I think ncopa is the maintainer of the Go package?
2020-03-02 10:03:56 <sauerbraten> basically, instead of https://git.alpinelinux.org/aports/tree/community/go/default-buildmode-pie.patch, use https://pastebin.com/2SAJK9iU
2020-03-02 10:04:46 <sauerbraten> I'm unsure though if https://git.alpinelinux.org/aports/tree/community/go/disable-flaky-sync-test.patch needs an update as well
2020-03-02 10:05:38 <Cogitri> Alpine doesn't use 4.19 on >= 3.11 anymore
2020-03-02 10:06:06 <Cogitri> And no, leaving it in IRC probably won't lead to something, make a MR for it
2020-03-02 10:06:19 <Cogitri> Although I think nmeum and kaey have been working on Go too?
2020-03-02 10:07:03 <PureTryOut[m]> Not every version of Alpine uses Linux 4.19
2020-03-02 10:07:09 <PureTryOut[m]> E.g. edge uses 5.4 by default now
2020-03-02 10:07:30 <nmeum> I have a patch for removing default-buildmode-pie.patch entirely, yes
2020-03-02 10:07:38 <nmeum> I would prefer that
2020-03-02 10:08:05 <nmeum> !4138
2020-03-02 10:09:09 <sauerbraten> ah perfect, thank you
2020-03-02 10:09:22 <nmeum> also: go 1.14 fixes CVE-2020-7919 and we probably need to rebuild some packages for that
2020-03-02 10:11:12 <nmeum> imho the best timeline would be: (a) remove default-buildmode-pie.patch (b) upgrade to Go 1.14 (c) rebuild packages as needed
2020-03-02 10:12:53 <nmeum> _ikke_: ^ could we coordinate an update of the /etc/abuild.conf on the builders soonish?
2020-03-02 10:13:05 <sauerbraten> sounds reasonable. I'm just waiting to get go-1.14 to edge so my CI builds work again :)
2020-03-02 10:13:23 <sauerbraten> (I use a 1.14 feature of overlapping interfaces)
2020-03-02 10:13:50 <_ikke_> nmeum: I would need help from someone to update ppc6le and s390x
2020-03-02 10:14:09 <nmeum> who has access to those?
2020-03-02 10:14:28 <sauerbraten> also: I saw enet was moved from testing to unmaintained some time ago, so right now I build enet from source with ever CI build. can I maintain it so it is availabled in testing again?
2020-03-02 10:14:44 <nmeum> if /etc/abuild.conf hasn't been manually modified on these they shouldn't require manualy intervention but would probably be good to check that they haven't
2020-03-02 10:15:03 <nmeum> sauerbraten: sure, send a MR
2020-03-02 10:50:11 <aparcar[m]> clandmeter: I mentioned the issue in an email in case this is of interest for Alpine https://lists.infradead.org/pipermail/openwrt-devel/2020-March/021970.html
2020-03-02 14:38:16 <clandmeter> nmeum: regarding go and abuild.conf, ncopa will look into it today or tomorrow.
2020-03-02 14:39:53 <nmeum> clandmeter: ok, great. thanks for taking care of this!
2020-03-02 14:40:05 <clandmeter> we need to add a new milestone
2020-03-02 14:40:19 <clandmeter> so we can tag issues to new release
2020-03-02 14:40:35 <clandmeter> we want to do a new stable and edge release
2020-03-02 14:41:08 <clandmeter> so any issues with alpine-base and related should be fixed before we do edge snapshot.
2020-03-02 14:42:21 <mps> clandmeter: should I mark some of MR with these milestones, actually stable only, gcc bug fix, musl thumb2 fix and maybe something else (have to look)
2020-03-02 14:43:45 <clandmeter> yes, thats the idea, tag MR and issue to new milestone
2020-03-02 14:43:57 <mps> ok
2020-03-02 14:44:00 <clandmeter> ncopa will be online this week to look into them
2020-03-02 14:44:16 <clandmeter> but he is still in a diff timezone
2020-03-02 14:44:56 <mps> ok, thanks
2020-03-02 14:47:39 <clandmeter> i just created it so be my guest
2020-03-02 14:49:32 <_ikke_> There already was a 3.12.0 milestone?
2020-03-02 14:50:15 <clandmeter> _ikke_, Cogitri, maxice8, Ariadne (and all others) if you have anything for 3.11.5 please add them to 3.11.5 milestone.
2020-03-02 14:50:25 <_ikke_> ah, 3.11.5
2020-03-02 14:50:38 <clandmeter> yeah
2020-03-02 14:51:10 <clandmeter> if htere is another with musl busybox or related it should be fixed before edge snapshot.
2020-03-02 14:51:34 <clandmeter> so it ends up in our minirootfs
2020-03-02 14:52:56 <Ariadne> we are staying on musk 1.1
2020-03-02 14:53:00 <Ariadne> mjsl 1.1
2020-03-02 14:53:03 <Ariadne> omg
2020-03-02 14:53:05 <Cogitri> Hehe
2020-03-02 14:53:08 <Ariadne> stupid phone keyboard
2020-03-02 14:53:14 <Cogitri> But +1 on that, musl 1.1 is the way to go for 3.12 IMO
2020-03-02 14:53:21 <Ariadne> we are staying on musk 1.1 for 3.12
2020-03-02 14:53:25 <Ariadne> ....
2020-03-02 14:53:27 <Ariadne> musl
2020-03-02 14:53:27 <Cogitri> Loads of stuff about time64_t still isn't ironed out right now
2020-03-02 14:53:57 <Cogitri> clandmeter: Thanks for the ping, will do so, but I don't thunk I have anything urgent that needs to go into the stable release
2020-03-02 14:59:32 <mps> kernel should
2020-03-02 15:01:15 <mps> fcolista: would you backport acme.sh to 3.11
2020-03-02 15:02:43 <fcolista> acme.sh is already on 3.11, mps
2020-03-02 15:03:52 <mps> I know, I mean backport version from edge
2020-03-02 15:04:10 <mps> upgrade*
2020-03-02 15:20:45 <fcolista> ah, that's different
2020-03-02 15:21:58 <mps> I could do that, but wanted to ask you first
2020-03-02 15:22:41 <fcolista> np mps, go ahead
2020-03-02 15:22:51 <mps> ok
2020-03-02 15:32:56 <maxice8> Why does empty packages like lua-<module> have a size of 4096 in its .PKGINFO ?
2020-03-02 15:35:27 <maxice8> http://ix.io/2dbk
2020-03-02 15:39:05 <_ikke_> sounds like some minimal block size
2020-03-02 15:39:25 <maxice8> Doesn't happen to my locally built packages, only ones i fetch from remote repos
2020-03-02 15:45:34 <maxice8> same with qimgv-dev (which is only a symbolic link)
2020-03-02 15:45:39 <maxice8> 0 locally, and 12288 remote
2020-03-02 15:54:16 <[[sroracle]]> could be related to the churn in determining size = that has been going on recently
2020-03-02 15:55:05 <[[sroracle]]> no i must be thinking of something else nevermind
2020-03-02 16:42:07 <ncopa> hi everyone
2020-03-02 16:42:16 <maxice8> hey! :D
2020-03-02 16:42:19 <ncopa> will try work a bit this week
2020-03-02 16:42:43 <ncopa> maybe not so much on friday
2020-03-02 16:44:09 <maxice8> Okie
2020-03-02 16:46:00 <Cogitri> Hey ncopa :)
2020-03-02 16:47:01 <Cogitri> Can you maybe take a look at #11265 ? Would be good to have a decision on that and either proceed or shoot it down depending on that
2020-03-02 16:56:01 <mps> ncopa: welcome back :)
2020-03-02 17:11:08 <ncopa> Cogitri: I@m looking at it now
2020-03-02 17:14:43 <Cogitri> Thank you :)
2020-03-02 17:43:00 <ncopa> so musl 1.2 is out
2020-03-02 17:45:29 <mps> yes, we discussed it and common thinking it is not good to upgrade alpine for 3.12
2020-03-02 17:46:30 <ncopa> as i understand, to upgrade to 3.12 we will need to set up new edge builders for all our 32 bit arches
2020-03-02 17:46:33 <mps> 32bit machines can be biggest issue
2020-03-02 17:46:47 <ncopa> i dont think there are any problem with 64 bit arches
2020-03-02 17:47:33 <mps> well, we looked at some patches and most base packages can be solved, probably
2020-03-02 17:47:46 <Cogitri> Yup, it only causes problems on 32-bit
2020-03-02 17:47:47 <ncopa> i think we´d need to set up new 32 bit builders and build everything from scratch with musl 1.2
2020-03-02 17:47:55 <ncopa> at least main and edge repo
2020-03-02 17:48:07 <mps> for musl 1.2.0 kernel 5.4 need alsa patches
2020-03-02 17:48:08 <ncopa> once those are built we can rebuild the testing packages
2020-03-02 17:48:24 <ncopa> kernel needs patches?
2020-03-02 17:48:43 <mps> yes, 5.4 alsa doesn't have time64
2020-03-02 17:48:53 <Cogitri> The headers need patches if I understand correctly
2020-03-02 17:48:55 <mps> it landed in 5.6
2020-03-02 17:49:04 <Cogitri> So applications building against it work correctly
2020-03-02 17:49:05 <mps> Cogitri: true
2020-03-02 17:49:14 <ncopa> ok, so its only the linux-headers, not the kernel itself
2020-03-02 17:49:14 <mps> no
2020-03-02 17:49:38 <mps> kernel need time64 fixes
2020-03-02 17:49:39 <Ariadne> ncopa: in your absence we concluded it is best to hold on musl 1.2 until after 3.12 is branched
2020-03-02 17:50:03 <ncopa> im glad you didnt blindly jump on musl 1.2 :) thanks!
2020-03-02 17:50:27 <mps> let me find urls from adelie and musl about these things
2020-03-02 17:50:38 <ncopa> i think we need to start think about feature freeze for alpine 3.12
2020-03-02 17:50:50 <ncopa> i´d like to have all the major features in before April 1
2020-03-02 17:51:28 <Ariadne> mips/mips64 will be ready by then.  the main issue with the port right now is that my vendor did not give us accurate lead times on the 48-core boxes we ordered
2020-03-02 17:52:04 <Ariadne> we have backup plan, ubiquiti edgerouter infinity
2020-03-02 17:52:15 <ncopa> we should try set up the 3.12 builders in the beginning of April
2020-03-02 17:52:19 <Ariadne> which is 16 core with 16GB SODIMM
2020-03-02 17:52:22 <mps> here is works from awifox (adelie linux) https://wiki.adelielinux.org/wiki/Project:Time64
2020-03-02 17:52:23 <Ariadne> should be good enough for now
2020-03-02 17:53:31 <mps> and here are dalias notes http://www.aerifal.cx/~dalias/time64.html
2020-03-02 17:54:29 <mps> and dalias posted kernel patches in mcm but for kernel 4.19 (iirc)
2020-03-02 17:56:16 <mps> ncopa: another note, if you remember we discussed ncurses pkgver fix about year ago
2020-03-02 17:56:17 <ncopa> would be nice to have musl 1.2 in before we add mips32 if thats on the roadmap
2020-03-02 17:56:33 <ncopa> mps: i remember we talked about ncurses
2020-03-02 17:56:35 <mps> I created !4066
2020-03-02 17:57:00 <mps> but maxice8 pushed upgrade with old versioning scheme
2020-03-02 17:57:28 <mps> is to late to revert his commits
2020-03-02 17:57:44 <mps> s/is/is it/
2020-03-02 17:57:44 <alpine-meetbot> mps meant to say: is it to late to revert his commits
2020-03-02 17:58:09 <Ariadne> mps: this is why i wanted to just have closure on this issue
2020-03-02 17:58:34 <mps> Ariadne: yes, we discussed this here and in MR
2020-03-02 17:59:07 <Ariadne> anyway.
2020-03-02 17:59:12 <mps> and you were 'fine' enough to understand my reasoning :)
2020-03-02 18:00:05 <Ariadne> i was apathetic enough
2020-03-02 18:00:19 <mps> :)
2020-03-02 18:00:23 <ncopa> do we have the previous discussion somewhere?
2020-03-02 18:00:25 <Ariadne> at any rate
2020-03-02 18:00:33 <Ariadne> 6.2_p[DATE] ranks lower than 6.2
2020-03-02 18:00:37 <mps> ncopa: maybe on IRC log
2020-03-02 18:00:43 <Ariadne> so we can just supercede 6.2_p[DATE] with 6.2
2020-03-02 18:00:46 <Ariadne> and it will be fine
2020-03-02 18:01:07 <mps> ah, nice
2020-03-02 18:01:15 <mps> so it is not problem
2020-03-02 18:01:31 <Ariadne> yes, which is why i was apathetic
2020-03-02 18:01:46 <Ariadne> to me, the question was whether to import ncurses 6.2 last week or this week
2020-03-02 18:01:47 <mps> heh, you should tell me then
2020-03-02 18:01:48 <Ariadne> ;)
2020-03-02 18:02:26 <mps> another note !4794
2020-03-02 18:03:16 <mps> I talked there with fabled and he proposed to backport bug fixes from 1.2.0 to 1.1.24 to 3.11-stable
2020-03-02 18:03:29 <mps> musl
2020-03-02 18:03:38 <Ariadne> personally, i think 6.2_p[DATE] is pointless, but ncurses author has made several "6.1" releases
2020-03-02 18:03:51 <Ariadne> which is why the notation was added in the first place
2020-03-02 18:04:07 <Ariadne> imo the solution ultimately is to repeal and replace GNU ncurses
2020-03-02 18:04:13 <Ariadne> with well, anything else really
2020-03-02 18:04:26 <mps> ncurses releases are usually weekly or bi-weekly
2020-03-02 18:04:37 <ncopa> Ariadne: i think not
2020-03-02 18:04:56 <ncopa> i think 6.2_p[DATE] is higher than 6.2
2020-03-02 18:05:21 <ncopa> but as far i remember, the problem was that those _p[DATE] releases was development releases
2020-03-02 18:05:36 <ncopa> we should stick to stable releases
2020-03-02 18:05:55 <mps> apk version -t 6.2 6.2_p2
2020-03-02 18:06:41 <mps> ncopa: my understand is ncurses development and bug fixes are in same releases
2020-03-02 18:07:08 <mps> understanding*
2020-03-02 18:07:35 <ncopa> i think the problem that there was a difference between development releases and bug fixes releases
2020-03-02 18:07:37 <mps> there is no stable and develepment tarballs
2020-03-02 18:08:09 <ncopa> it is possible that bugfixes and dev releases are the same
2020-03-02 18:08:58 <ncopa> there are 6.2.x releases in https://invisible-mirror.net/archives/ncurses/6.2/ and in https://invisible-mirror.net/archives/ncurses/current/
2020-03-02 18:09:49 <Ariadne> ncopa: oh
2020-03-02 18:10:01 <ncopa> there are even 6.2.x tarballs in https://invisible-mirror.net/archives/ncurses/6.1/
2020-03-02 18:10:04 <Ariadne> ncopa: "p" has special handling indeed
2020-03-02 18:10:26 <mps> yes, but if I remember current is never released
2020-03-02 18:10:50 <Ariadne> this all sounds awful
2020-03-02 18:11:10 <Ariadne> somebody should fork it and do something sane instead
2020-03-02 18:11:39 <[[sroracle]]> could always try to use netbsd curses too
2020-03-02 18:12:02 <mps> https://invisible-mirror.net/archives/ncurses/6.2/ contains patches while https://invisible-mirror.net/archives/ncurses/current/ tarballs
2020-03-02 18:12:50 <mps> it is somewhat messed, I know but that is how it is released
2020-03-02 18:16:45 <Ariadne> lets deal with this in 3.13/4.0/something
2020-03-02 18:23:42 <ncopa> mps: in any case, upstream has a [DATE] part in their release tarballs, except for https://invisible-mirror.net/archives/ncurses/ncurses-6.2.tar.gz
2020-03-02 18:24:21 <ncopa> i think we either use the _p[DATE] suffix as maxice8 did or we use https://invisible-mirror.net/archives/ncurses/ncurses-6.2.tar.gz
2020-03-02 18:24:45 <ncopa> i don tthink we should hide the -[DATE] part
2020-03-02 18:25:26 <ncopa> IOW, i think what maxice8 did is good
2020-03-02 18:25:44 <ncopa> seems like that is what fedora does as well: https://src.fedoraproject.org/rpms/ncurses/blob/master/f/ncurses.spec
2020-03-02 18:25:54 <mps> ok, I'm not against that
2020-03-02 18:26:28 <ncopa> i remember we did get some complain about it
2020-03-02 18:26:39 <mps> Debian and Arch have 6.x and sub versions with date
2020-03-02 18:27:02 <ncopa> oh
2020-03-02 18:27:12 <maxice8> 6.x.DATE
2020-03-02 18:27:19 <mps> yes, you initiated this, and we thne decided to change this when 6.2 is released
2020-03-02 18:28:00 <ncopa> i think https://invisible-mirror.net/archives/ncurses/current/ is correct. there are fewer 6.1 releases than  in https://invisible-mirror.net/archives/ncurses/6.1/
2020-03-02 18:28:29 <mps> because that I prepared MR and labeled it with 'HOLD', but looks like maxice8 didn't noticed it
2020-03-02 18:32:24 <maxice8> I hit 500 Internal Server Error twice when making a merge request
2020-03-02 18:32:26 <mps> it doesn't matter which scheme we use, although to me 6.2_p20200219 looks somewhat ugly, like it some CVS version
2020-03-02 18:36:37 <ncopa> https://invisible-island.net/ncurses/announce.html at the end
2020-03-02 18:36:45 <ncopa> under "Development activities"
2020-03-02 18:37:12 <ncopa> says that:
2020-03-02 18:37:13 <ncopa> Beta versions of ncurses are made available at
2020-03-02 18:37:13 <ncopa> ftp://ftp.invisible-island.net/ncurses/current/ and
2020-03-02 18:37:13 <ncopa> https://invisible-mirror.net/archives/ncurses/current/ .
2020-03-02 18:37:33 <ncopa> Patches to the current release are made available at
2020-03-02 18:37:34 <ncopa> ftp://ftp.invisible-island.net/ncurses/6.1/ and
2020-03-02 18:37:34 <ncopa> https://invisible-mirror.net/archives/ncurses/6.1/
2020-03-02 18:38:18 <ncopa> so it sounds like we should use the tarballs found in  https://invisible-mirror.net/archives/ncurses/6.2/ ?
2020-03-02 18:39:09 <ncopa> its a bit messy...
2020-03-02 18:39:47 <mps> yes :)
2020-03-02 18:40:16 <ncopa> lets just keep what maxice8 did for now
2020-03-02 18:40:25 <mps> ok
2020-03-02 18:40:51 <ncopa> i think !4066 is wrong in any case as it hides the date part from version string
2020-03-02 18:41:12 <mps> we can live with some ugliness
2020-03-02 18:41:16 <ncopa> i will comment there, for the record
2020-03-02 18:48:28 <ncopa> mps: thanks!
2020-03-02 19:34:56 <Cogitri> Not that important, but since you're here: Can  you take a look at the linux-lts part of !3848?
2020-03-02 19:34:59 <Cogitri> ncopa: ^
2020-03-02 19:40:39 <ncopa> do we really want to support anbox?
2020-03-02 19:42:44 <Cogitri> I don't see why not
2020-03-02 19:46:46 <ncopa> it is somewhat cool to run android in a container
2020-03-02 19:47:24 <ncopa> and the user space bits are already merged
2020-03-02 19:47:37 <ncopa> i´ll merge the kernel bits
2020-03-02 19:48:17 <PureTryOut[m]> Yay!
2020-03-02 19:49:19 <Cogitri> Yup, merge the stuff on community/testing already but didn't have the bits for main/
2020-03-02 19:49:25 <Cogitri> Thanks for looking at it :)
2020-03-02 19:55:40 <oneinsect> ncopa: while you are here, can you just give a small advise, can we use buildroot to build a basic toolchain to build abuild and then use abuild to build the entire alpine, is this advisable? can we use the same approach for cross compiling as well?
2020-03-02 19:56:48 <ilyes512_> So not sure how, where I should report this... I would like to request removing the py3-crypto dependency from the ansible package: https://pkgs.alpinelinux.org/package/v3.11/main/x86_64/ansible
2020-03-02 19:57:46 <ncopa> oneinsect: in theory that should work, but there is only a limited number of packages in aports tree that works with crosscompile
2020-03-02 19:57:48 <ilyes512_> It's outdated and replaced by py3-cryptography that will already be installed because it's a sub dependency: Ansible > py3-paramiko > py3-cryptography
2020-03-02 19:58:27 <oneinsect> oooh so crosscompile wont work in that case how do you compile those packages for alpine releases? do you have native hardware for those?
2020-03-02 19:58:30 <_ikke_> ilyes512_: they're the same at the moment
2020-03-02 19:59:04 <ncopa> oneinsect: basically, when bootstrapping new arch we crosscompile the bare minimum to get abuild running (eg toolchain, busybox, apk) and the we build the rest natively
2020-03-02 19:59:08 <_ikke_> ilyes512_: https://git.alpinelinux.org/aports/tree/main/py3-pycryptodome/APKBUILD#n14
2020-03-02 19:59:31 <oneinsect> ooooh this is interesting, i didnt know this is how you guys did!
2020-03-02 19:59:44 <_ikke_> ilyes512_: it does make sense to change the dependency on ansible, but it already uses pycryptodome
2020-03-02 19:59:49 <ncopa> it is possible some (or even majority) of aports will crosscompile, but im pretty sure not everything will crosscompile
2020-03-02 19:59:58 <ilyes512_> but why is it still throwing this: `if sys.version_info[0] is 2 and  sys.version_info[1] is 1`
2020-03-02 20:00:19 <ncopa> we build everything natively, as it will allow us to run the testsuites
2020-03-02 20:00:27 <ilyes512_> this warning is given after using ansible and it seems to be thrown by pycrypto: https://github.com/dlitz/pycrypto/issues/298
2020-03-02 20:00:42 <_ikke_> ilyes512_: are you on a stable release?
2020-03-02 20:00:44 <oneinsect> understood, may be i could use qemu but probably that will be too slow
2020-03-02 20:00:48 <ncopa> ilyes512_: the proper way to report it is via an issue in gitlab
2020-03-02 20:01:13 <ncopa> oneinsect: we have hardware for all of our supported arches
2020-03-02 20:01:48 <ncopa> packet.net sponsors the arm hw, and ibm sponsors the ppc64le and s390x
2020-03-02 20:02:44 <hrio[m]> maxice8 I have the same backspace issue with TERM set to vt102 in a xen console
2020-03-02 20:03:18 <ilyes512_> I am using docker as my base image (alpine:3.11.3) and install it using `apk add ansible`. If I do `pip3 list` it shows me pycrypto     2.6.1 which contains the problem
2020-03-02 20:03:43 <_ikke_> ilyes512_: right, it's currently only in edge, 3.12 would contain that change
2020-03-02 20:03:46 <oneinsect> ooh nice!!! one question though, assuming I compile the abuild successfully, is there a list of bare minimum packages that are first needed to compiled? is it like only alpine-base
2020-03-02 20:04:54 <ncopa> oneinsect: there is a list of packages in scripts/bootstrap.sh
2020-03-02 20:05:39 <_ikke_> ilyes512_: would cryptography vs pycryptoome make a difference?
2020-03-02 20:05:51 <oneinsect> thanks ncopa:
2020-03-02 20:07:23 <ilyes512_> I think that will work as well. testing now
2020-03-02 20:08:53 <ilyes512_> the version in edge seems to work
2020-03-02 20:09:44 <ilyes512_> so how does that work in alpine? can something be promoted to stable with a patch version or does that only happen with a new minor?
2020-03-02 20:09:58 <ilyes512_> (ie alpine:3.12)
2020-03-02 20:11:18 <_ikke_> ilyes512_: Usually things are backports to fix bugs
2020-03-02 20:11:40 <_ikke_> So if you are running against a bug, please proceed as ncopa suggested and file a bug at gitlab.alpinelinux.org
2020-03-02 20:12:36 <ilyes512_> not sure if you can call this a bug? It more like its emitting a warning... but it does still work.
2020-03-02 20:16:43 <oneinsect> ncopa: bootstrap.sh requires an abuild binary but it doesnt need to be in an exiting alpine environment right? We can have any host with an abuild binary right?
2020-03-02 20:16:53 <oneinsect> existing*
2020-03-02 20:17:52 <_ikke_> note that abuild itself is not a binary
2020-03-02 20:18:05 <oneinsect> yes
2020-03-02 20:19:26 <_ikke_> maxice8: py3-py-cpuinfo checksum mismatch
2020-03-02 20:19:42 <_ikke_> maxice8: Looks like upstream source changed perhaps?
2020-03-02 20:20:26 <oneinsect> so this bootstrap.sh script can be used as a basis for selecting a libc of choice if i am right?
2020-03-02 20:23:08 <ilyes512_> hmm installing ansible from source defaults to installing cryptography instead of pycryptodome
2020-03-02 20:24:13 <ncopa> oneinsect: i think it shoulw work with any host as long as abuild and the support binaries are built
2020-03-02 20:24:30 <ncopa> i think the only deps are zlib and openssl or similar
2020-03-02 20:24:39 <ncopa> for abuild-tar
2020-03-02 20:24:50 <_ikke_> ilyes512_: maybe it makes more sense to change the dependency then
2020-03-02 20:24:53 <oneinsect> great thanks!
2020-03-02 20:25:08 <ncopa> maybe also apk-tools
2020-03-02 20:25:37 <oneinsect> yes for which i can use apk-tools static version
2020-03-02 21:33:36 <remexre> should dl-cdn.alpinelinux.org being akamai or fastly (or both)?
2020-03-02 21:34:49 <remexre> I'm seeing some very weird DNS behavior between different interfaces, where it's sometimes fastly (and working), and sometimes akamai (and not)
2020-03-03 05:35:35 <_ikke_> remexre: it should only be fastly, we don't host anything ourselves on akamai as fas as I know, but dl-cdn should only point to fastly
2020-03-03 10:23:05 <AinNero> i dont have a strong opinion on the firefox to community move
2020-03-03 10:23:20 <AinNero> id go the pythonuc way and try it out and then shout it out if an exception happens
2020-03-03 10:25:25 <mps> yes, alpine becoming more like a playground than OS
2020-03-03 10:25:57 <AinNero> it floats my boat so its fine with me
2020-03-03 10:35:17 <Ariadne> mps: trying to pretend to be an enterprise OS while not being able to supply an enterprise lifecycle is pointless.  it is better for Alpine to focus on strengths rather than weaknesses.
2020-03-03 10:35:44 <AinNero> what are its strengths even
2020-03-03 10:38:55 <Ariadne> i would say that historically research and experimentation has been alpine's strength
2020-03-03 10:39:08 <Ariadne> 99% of installs are on latest-stable anyway
2020-03-03 10:39:23 <AinNero> [doubt]
2020-03-03 10:40:14 <Ariadne> doubt to which?
2020-03-03 10:41:43 <Cogitri> The 99% latest stable figure
2020-03-03 10:42:04 <Cogitri> Or we have a rather vocal minority opening issues on Gitlab with old Alpine releases
2020-03-03 10:42:38 <maxice8> Yeah was going to say that, most of the issues i found is people doing alpine-3.7 on docker and fetching edge. I like to think that is just a case of "Went it goes wrong you hear complaints, when it goes right nobody says anything"
2020-03-03 10:43:13 <Ariadne> well, docker is typically a case of doing it wrong anyway
2020-03-03 10:43:45 <Cogitri> Heh
2020-03-03 10:44:19 <Cogitri> 
ACTION would still like a nice big warning if people mix releases

2020-03-03 10:44:33 <Ariadne> how do you propose that would work?
2020-03-03 10:44:38 <Cogitri> Loads of people don't understand that mixing repos is bound to blow up
2020-03-03 10:44:52 <Cogitri> We could encode what release a repo is for in the APKINDEX I suppose
2020-03-03 10:45:17 <Cogitri> If we're at it encoding a EOL date might also be a good idea so we can print a warning saying the thing is EOL too
2020-03-03 10:45:20 <Ariadne> i think a lot of this problem would be solved by changing 'testing' to 'experimental'
2020-03-03 10:45:51 <Ariadne> experimental is scarier sounding :)
2020-03-03 10:45:55 <Cogitri> Maybe if we change it to experimental-use-this-only-on-edge-like-ever-please
2020-03-03 10:46:19 <Ariadne> one thing we could do
2020-03-03 10:46:19 <Cogitri> Most people will just seee that the package they want is in that repo and just enable it
2020-03-03 10:46:23 <Ariadne> is have an implicit dep
2020-03-03 10:46:26 <Ariadne> on alpine-base
2020-03-03 10:46:31 <Ariadne> alpine-base=3.12
2020-03-03 10:46:33 <Ariadne> or whatever
2020-03-03 10:46:48 <Cogitri> Wouldn't that make adding testing/ impossible?
2020-03-03 10:47:01 <Ariadne> yes, if you were not on edge
2020-03-03 10:47:08 <Cogitri> (Which wouldn't be the worst thing ever I guess)
2020-03-03 10:47:25 <Cogitri> Users could still overwrite that with a virtual package, right?
2020-03-03 10:47:28 <Ariadne> yes
2020-03-03 10:47:38 <Cogitri> In case they want to say "I know what I'm doing"
2020-03-03 10:47:40 <Cogitri> Sounds good to me then
2020-03-03 10:47:41 <Ariadne> but if they do, then it is their own problem
2020-03-03 10:48:05 <Ariadne> i'll spec it up, but basically the idea is that a repo (e.g. testing) would impose default requirements
2020-03-03 10:48:18 <Cogitri> Thank you :)
2020-03-03 10:48:59 <Ariadne> however i need to do this in a clean way because alpinewrt does not use all of alpine-base (so i would like to slim it down)
2020-03-03 10:49:26 <Ariadne> and i guess pmOS probably also wants similar slimming capabilities
2020-03-03 12:55:33 <mps> ncopa: are you around? do you have time to look !4237
2020-03-03 12:56:58 <mps> we need this resolved before 3.12 freeze, and Jakub is quiet so only you can decide what to do. Crystal developer (Johannes) agreed to disable aarch64
2020-03-03 12:58:03 <Ariadne> what happens to people using crystal on aarch64
2020-03-03 12:58:34 <mps> they are doomed
2020-03-03 12:59:15 <Ariadne> this seems like a bad answer
2020-03-03 12:59:18 <mps> 0.32 build but doesn't work on aarch64, while 0.33 can't be even built
2020-03-03 12:59:52 <mps> better answer ;) ?
2020-03-03 13:00:32 <Ariadne> is it officially the position of crystal that aarch64 is not supported?
2020-03-03 13:01:05 <mps> upstream developer are concentrated with windows post and don't give much 'care' to aarch64
2020-03-03 13:01:30 <mps> yes, officially it is not supported, afaik
2020-03-03 13:02:02 <Ariadne> upstream is not concerned with linux?
2020-03-03 13:02:13 <Ariadne> perhaps the right answer is to remove crystal entirely
2020-03-03 13:02:21 <mps> maybe I missed something but Johannes is developer and if he says that we should 'drop' aarch64 I agree with him
2020-03-03 13:02:45 <mps> no, linux is primary but only x86_64
2020-03-03 13:03:25 <mps> it works quite fine on x86_64, they test their builds first on alpine
2020-03-03 13:03:44 <mps> and then, other distros
2020-03-03 13:06:22 <Ariadne> why should we package a programming language that only works on x86_64
2020-03-03 13:06:47 <Ariadne> i think if you want to be in alpine you have to try a little harder than that
2020-03-03 13:07:00 <mps> because some people need it
2020-03-03 13:07:13 <mps> and are ready to package it :)
2020-03-03 13:07:22 <Cogitri> If it's available on x86_64 then we should have it available on that
2020-03-03 13:07:37 <Ariadne> why
2020-03-03 13:08:13 <mps> and this is not only package which works only on x86_64, afail (lazy to search now)
2020-03-03 13:08:34 <mps> but till 3.11 firefox was such package
2020-03-03 13:08:52 <mps> afaik*
2020-03-03 13:09:00 <Ariadne> so we should add more ?
2020-03-03 13:09:18 <mps> we could
2020-03-03 13:09:26 <Ariadne> part of the purpose of a distribution is to put pressure on upstreams to do their fucking job correctly
2020-03-03 13:09:53 <Ariadne> "programming language that only works on x86_64, but uses LLVM" is not that
2020-03-03 13:10:23 <mps> main/efitools/APKBUILD:arch="x86_64"
2020-03-03 13:10:26 <Ariadne> "windows is more important than linux portability" is not that
2020-03-03 13:10:33 <Ariadne> mps: that's not a programming language
2020-03-03 13:11:08 <Ariadne> and until recently, x86_64 was the only hardware that we supported EFI on
2020-03-03 13:11:14 <mps> ok, unmaintained/julia/APKBUILD:arch="x86_64", it was some time in community iirc
2020-03-03 13:11:14 <Ariadne> should have aarch64 added i guess
2020-03-03 13:11:22 <Ariadne> yes, and julia was dropped
2020-03-03 13:11:29 <Ariadne> because of boneheaded upstream
2020-03-03 13:12:40 <mps> yes, I agree with your feelings but don't agree that we shouldn't langs just because they don't work on particular arch
2020-03-03 13:13:06 <mps> meh, shouldn't package langs
2020-03-03 13:13:26 <Ariadne> i do.  if they want us to take them seriously, they should take us seriously
2020-03-03 13:13:40 <Ariadne> portability is important
2020-03-03 13:13:52 <Cogitri> At least Crystal devs do test on Musl and Alpine
2020-03-03 13:13:58 <Ariadne> cool
2020-03-03 13:14:09 <mps> ah, drop rust because they don't take musl seriously
2020-03-03 13:14:13 <Ariadne> but, they do not support archs other than x86_64
2020-03-03 13:14:21 <Ariadne> mps: rust has regulatory capture
2020-03-03 13:14:49 <mps> ok, I think we are beating dead horse now
2020-03-03 13:17:06 <mps> crystal works fine for more than two years on alpine, devs care about musl, and they paln to extend it on other arches (aarch64 and armv7 have some patches in their repo)
2020-03-03 13:17:45 <mps> they are also small team (like we) and I think it wouldn't be nice from us to ignore them
2020-03-03 13:20:47 <Cogitri> +1
2020-03-03 13:36:26 <Ariadne> i guess kill aarch64 for now
2020-03-03 13:36:31 <Ariadne> but if it doesn't come back
2020-03-03 13:36:35 <Ariadne> i'm going to be underwhelmed
2020-03-03 13:41:01 <mps> waiting approval from BDFL :)
2020-03-03 13:42:16 <_ikke_> I don't think ncopa needs to approve everything :)
2020-03-03 13:42:50 <mps> ah, I'll promote you to BDFL then :)
2020-03-03 13:45:47 <mps> though seriously, Jakub expressed his opinion against removal from aarch64 and I don't want to do anything without his (maintainer) or alpine 'leader' approval
2020-03-03 13:54:45 <Ariadne> mps: the removal is authorized on QA grounds
2020-03-03 14:17:23 <ncopa> i didnt remove crystal aarch64 because it will require a bootstrap to add it back IIRC
2020-03-03 14:17:27 <ncopa> which is painful
2020-03-03 14:22:36 <ncopa> i suspect its easier to fix the aarch64 than it is to bootstrap it
2020-03-03 14:22:40 <ncopa> but i may be wrong
2020-03-03 14:23:06 <Cogitri> Couldn't we just save the apk package on d.a.o and add that to sources once we try to add aarch64 again?
2020-03-03 14:23:07 <Cogitri> And bootstrap from that tarball
2020-03-03 14:24:00 <mps> yes, that is what I just wanted to say
2020-03-03 14:24:19 <ncopa> depends on what the problem with aarch64 actually is
2020-03-03 14:24:36 <ncopa> but i guess
2020-03-03 14:25:53 <mps> we have 0.31.1 static aarch64 build on dev.a.o
2020-03-03 14:26:05 <mps> tarball
2020-03-03 14:30:39 <Ariadne> anyway
2020-03-03 14:30:51 <Ariadne> if crystal devs do not care about an arch
2020-03-03 14:30:54 <Ariadne> we should just drop it
2020-03-03 14:31:05 <Ariadne> but we should request they care about portability in future too
2020-03-03 14:31:12 <remexre> _ikke_: after debugging, the Akamai DNS turned out to be comcast mitming us; we're hopefully going to get that fixed today, I'll update the mailing list w/ the results
2020-03-03 14:31:55 <Ariadne> that's why you always use comcast as an underlay and wireguard everything to a known good endpoint for your actual traffic
2020-03-03 14:32:28 <Ariadne> force them to be essentially a dumb local loop, nothing more, nothing less
2020-03-03 14:33:01 <remexre> in theory, yes; in practice, we sometimes are pushing a few TB a day up and down, and don't want to pay for double our bandwidth
2020-03-03 14:34:16 <Ariadne> fair i suppose
2020-03-03 14:37:27 <_ikke_> remexre: good to know
2020-03-03 14:55:14 <hrio[m]> maxice8 hi
2020-03-03 14:55:37 <maxice8> Hi
2020-03-03 14:56:19 <hrio[m]> Same problem with vt102 as with the TERM var the other day
2020-03-03 14:56:44 <hrio[m]> vt102 is used in the xen console for a alpine domU
2020-03-03 14:56:49 <maxice8> Install ncuraes-terminfo
2020-03-03 14:57:14 <maxice8> ncurses*
2020-03-03 14:57:54 <maxice8> I'll see with Ariadne if we can move that to - base or if users should be instructed to install the full terminfo package
2020-03-03 14:58:03 <mps> maxice8: forgot to tell yesterday, your split of terminfo is good
2020-03-03 14:58:17 <Ariadne> yes, put vt102 in base
2020-03-03 14:58:21 <Ariadne> it is common
2020-03-03 14:58:23 <hrio[m]> Ok, so when we upgrade to v3.12 this must be done for all virtual machines?
2020-03-03 14:58:39 <Ariadne> no, it is just a bug
2020-03-03 14:58:41 <Ariadne> we will fix it
2020-03-03 14:58:56 <maxice8> @mps: it was Ariadne's idea, I just worked on it
2020-03-03 14:59:08 <hrio[m]> Ah, thanks
2020-03-03 14:59:30 <mps> yes, I followed. something similar I proposed about year ago
2020-03-03 16:02:53 <timlegge> anyone around to chat about apkbuild-cpan?  I am thinking that it makes sense to add a _template= variable as there have been a few change to the template used in the utility and new some of the older APKBUILD files are unsupported by the upgrade and check options of apkbuild-cpan
2020-03-03 16:03:32 <Cogitri> I think it'd be good to modernize apkbuild-cpan
2020-03-03 16:03:39 <Cogitri> To not put empty variables and such in the APKBUILD
2020-03-03 16:05:39 <timlegge> my latest MR https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/34 cleanus up alot of the empty variables and fixes an number of issues
2020-03-03 16:06:25 <timlegge> I think I caught everything that I came across lately
2020-03-03 16:09:06 <_ikke_> timlegge: maybe add the template as a comment
2020-03-03 16:10:36 <timlegge> I did update the template version in the comment in the MR
2020-03-03 16:12:20 <timlegge> basic issue is if you are in a directory of a perl module and run apkbuild-cpan check it can't currently read the old APKBUIL versions to tell you if there is an upgraded module on CPAN
2020-03-03 16:12:56 <_ikke_> When is an APKBUILD version old?
2020-03-03 16:13:08 <_ikke_> and how is a _template variable going to help?
2020-03-03 16:13:31 <timlegge> I guess I could put in some added logic in case the APKBUILD does not include the expected variables
2020-03-03 16:15:10 <timlegge> The big one right now is the _pkgreal that stores the original perl module name that can be used to query metacpan
2020-03-03 16:16:27 <timlegge> Older versions do not have that variable so apkbuild-cpan check cannot currently parse that file
2020-03-03 16:17:57 <timlegge> a template version would allow some logic to deal with the old versions to check the version  or recreate the APKBUILD file
2020-03-03 16:18:10 <timlegge> may be there is a better option though
2020-03-03 16:18:44 <_ikke_> But you already have the template version in a comment, right?
2020-03-03 16:18:59 <_ikke_> I would imagine it not being too hard to parse that out
2020-03-03 16:19:02 <timlegge> true I could pare that
2020-03-03 16:19:08 <timlegge> parse
2020-03-03 17:45:49 <timlegge> looks like I can work with the template comment.  It apkbuild-cpan needs updates to make allow it to deal with missing empty variables in the APKBUILD files for other options.  Seems I have a small project...
2020-03-03 19:01:00 <mps> build language apk with 'options="!check"' is nonsense ?
2020-03-03 19:02:32 <_ikke_> Sorry?
2020-03-03 19:03:07 <_ikke_> Do you mean that we should avoid disabling checks on APKBUILDs for languages?
2020-03-03 19:03:08 <mps> managed to build crystal 0.32.1 on aarch64 using llvm8
2020-03-03 19:03:25 <mps> yes, that is what I ask
2020-03-03 19:03:57 <mps> but it fails in check()
2020-03-03 19:04:08 <_ikke_> I'm not sure if language packages are special in this regard
2020-03-03 19:06:05 <mps> heh, just noticed that I disabled check in testing/zig (and forgot about it)
2020-03-03 19:08:59 <_ikke_> mps: if possible, you could try to disable individual checks instead of the entire test suite
2020-03-03 19:09:21 <_ikke_> We run the tests to ensure it integrates properly on alpine
2020-03-03 19:10:05 <mps> yes, I know, but crystal on aarch64 fails on basic
2020-03-03 19:10:25 <_ikke_> Ok, but doesn't that mean that crystal is basically not working on aarch64?
2020-03-03 19:10:30 <mps> no chance to fix it now
2020-03-03 19:10:48 <_ikke_> even though it builds
2020-03-03 19:10:53 <mps> _ikke_: right what you say
2020-03-03 19:11:10 <_ikke_> So it does not make a lot of sense to ship a broken package
2020-03-03 19:11:28 <mps> builds but doesn't work on simple things/programs
2020-03-03 19:11:40 <_ikke_> yes, which is exactly why we run the test suite
2020-03-03 19:12:18 <_ikke_> using options="!check" should not be used in that case in my opinion
2020-03-03 19:12:47 <_ikke_> The test suite is working as intended, the package is broken, so should be disabled
2020-03-03 19:12:53 <_ikke_> (on that arch)
2020-03-03 19:13:45 <mps> hmmm, have no idea what to do with it :\
2020-03-03 19:14:00 <_ikke_> yeah, these problems are anoying
2020-03-03 19:18:29 <_ikke_> mps: with the ncurses 'fix' (proper splitup terminfo and terminfo-base), would it still be possible to add some more common terminals to terminfo?
2020-03-03 19:19:36 <mps> _ikke_: yes, some are missing
2020-03-03 19:20:10 <mps> I looked at this, but didn't had time to make complete list
2020-03-03 19:20:15 <_ikke_> I notice it now when ssh-ing into some alpine containers
2020-03-03 19:20:34 <mps> also I see this issue
2020-03-03 19:20:58 <_ikke_> screen-256color is a common one :)
2020-03-03 19:22:04 <mps> I will prepare list in a few hours
2020-03-03 19:24:33 <_ikke_> thanks
2020-03-03 19:25:23 <mps> just hit with ssh key type mismatch on containers on usa4 :|
2020-03-03 19:25:39 <_ikke_> hmm, strange
2020-03-03 19:25:45 <_ikke_> to do with a new openssh version?
2020-03-03 19:25:52 <mps> yes
2020-03-03 19:26:00 <_ikke_> Do you still have access?
2020-03-03 19:26:30 <mps> right now not, but I hope I will fix it in a few minutes
2020-03-03 19:26:42 <_ikke_> ah ok, otherwise I could help :)
2020-03-03 19:27:37 <mps> thanks in advance, if I don't find solution I will ask you
2020-03-03 19:39:10 <mps> _ikke_: looks like I forgot to restart sshd after upgrade to 8.2 on mps-edge-aarch64 (usa4)
2020-03-03 19:39:44 <_ikke_> should I restart it for you?
2020-03-03 19:40:07 <mps> well, if you have some time, would be appreciated :)
2020-03-03 19:40:29 <_ikke_> done
2020-03-03 19:40:49 <mps> thanks, fixed. it works :)
2020-03-03 19:43:49 <mps> about terminfo list, here is upstream script with some base terms https://invisible-island.net/ncurses/ncurses.faq.html#big_terminfo
2020-03-03 19:45:43 <mps> but we should add screen-XXX variants, some more vtXXX and maybe more
2020-03-03 19:46:19 <_ikke_> xterm-256color is popular as well
2020-03-03 19:46:55 <mps> it is already there, ncurses-terminfo-base apk
2020-03-03 19:47:05 <_ikke_> ok
2020-03-03 19:47:43 <mps> here it is from APKBUILD http://tpaste.us/Kykq
2020-03-03 19:49:12 <mps> just tested on upgraded lxc, screen-256color is there, and works fine
2020-03-03 19:50:37 <_ikke_> hmm, ok
2020-03-03 19:50:50 <_ikke_> I noticed it on one of the builders
2020-03-03 19:51:07 <mps> `apk info -L ncurses-terminfo-base` => http://tpaste.us/on7R
2020-03-03 19:51:28 <_ikke_> htop complained
2020-03-03 19:51:29 <mps> vt52, vt102 and similar are missing
2020-03-03 19:52:31 <_ikke_> Has that changed recently?
2020-03-03 19:53:08 <mps> I removed ncurses-terminfo and upgraded ncurses-terminfo-base and everything what I need works, tmux, htop, vim, ls ...
2020-03-03 19:53:19 <mps> with colors, ofc
2020-03-03 19:53:38 <mps> few days ago it is changed, maxice8 did this
2020-03-03 19:53:49 <_ikke_> I know the change with the symlink
2020-03-03 19:55:40 <mps> his 'love' about moving everything from /etc :)
2020-03-03 19:56:29 <mps> so called 'unified /usr'
2020-03-03 19:57:42 <mps> but, for now as I see we need only vtXXX term to add to ncurses-terminfo-base
2020-03-03 19:57:48 <_ikke_> https://moi.vonos.net/linux/unified-usr/ ?
2020-03-03 19:58:51 <maxice8> I think mps is referring to usrmerge
2020-03-03 19:58:58 <mps> yes, to look more like windows for windows refuges :)
2020-03-03 19:59:17 <mps> maxice8: right, usrmerge, I even forgot term
2020-03-03 19:59:31 <maxice8> If I wanted that I would rename /lib to /Library
2020-03-03 19:59:37 <_ikke_> lol
2020-03-03 19:59:45 <_ikke_> Sounds like Mac OS
2020-03-03 20:00:04 <AinNero> meh, i can agree that the ncurses setup for my exotic stuff is now borked
2020-03-03 20:00:05 <_ikke_> For windows it would be /'Program Files' :P
2020-03-03 20:00:10 <_ikke_> or even
2020-03-03 20:00:11 <mps> maxice8: please delete your msg, I someone else see it then it will proposed soon :D
2020-03-03 20:00:27 <_ikke_> /'Program Files (x86)'
2020-03-03 20:00:40 <_ikke_> mps: I'm writing the proposal as we speak :P
2020-03-03 20:01:01 <mps> ah, my note arrived to late :)
2020-03-03 20:01:35 <_ikke_> Do you think the distinction between /bin /usr/bin etc matters?
2020-03-03 20:01:52 <mps> yes, I think
2020-03-03 20:02:36 <mps> a /bin is for basic user binaries (rescue boot for example)
2020-03-03 20:02:54 <mps> while /usr/bin for rest user binaries
2020-03-03 20:03:39 <mps> if we want to have minimal rootFS, for example, and mount /usr from separate partition
2020-03-03 20:03:59 <mps> or, over NFS for example
2020-03-03 20:04:36 <mps> same applies to /sbin and /usr/sbin, /lib and /usr/lib
2020-03-03 20:06:18 <_ikke_> Not to diminish your point, but the only reason we have /usr/* in the first place was a lack of space on floppy disks :)
2020-03-03 20:08:33 <mps> 360KB or 1.44MB floppies ?
2020-03-03 20:14:29 <_ikke_> https://blog.w1r3.net/2018/01/06/rob-landley-about-usr-split.html
2020-03-03 20:14:39 <_ikke_> 500k apparently
2020-03-03 20:15:39 <_ikke_> /usr used to be the home dir :)
2020-03-03 20:15:44 <_ikke_> or contain the home dirs
2020-03-03 20:16:00 <mps> iirc, /usr/* existed in 80's previous century
2020-03-03 20:16:19 <_ikke_> This story is from the 70s
2020-03-03 20:16:31 <mps> yes, home dirs where in /usr
2020-03-03 20:17:03 <mps> well, in 80's I first seen it
2020-03-03 20:17:21 <mps> probably this is older
2020-03-03 20:18:32 <_ikke_> One point they make there is that you cannot upgrade /lib and /usr/bin separately due to shared libraries
2020-03-03 20:20:06 <mps> iirc, binaries in /usr/bin weren't linked to libs in /lib, only in /usr/lib
2020-03-03 20:20:21 <_ikke_> libc?
2020-03-03 20:20:25 <AinNero> ^
2020-03-03 20:20:27 <maxice8> that sounds dumb
2020-03-03 20:20:31 <AinNero> other way around
2020-03-03 20:20:39 <AinNero>  /lib wasnt linked to /usr/lib
2020-03-03 20:20:48 <AinNero> s/to/against/
2020-03-03 20:20:48 <alpine-meetbot> AinNero meant to say:  /lib wasnt linked against /usr/lib
2020-03-03 20:20:57 <AinNero> thanks alpine-meetbot
2020-03-03 20:21:00 <Cogitri> Oh, we're talking about merging /usr and /
2020-03-03 20:21:04 <Cogitri> Yes please
2020-03-03 20:21:16 <mps> uh, :P
2020-03-03 20:21:28 <AinNero> huh, was just about to link Rob Landley about this topic
2020-03-03 20:21:29 <Cogitri> I don't really see any reason to keep it splitted
2020-03-03 20:21:45 <AinNero> _ikke_: thanks for linking my blog
2020-03-03 20:21:56 <_ikke_> AinNero: ah lol, wasn't aware that was your blog
2020-03-03 20:22:12 <AinNero> ... it says my name at the top
2020-03-03 20:22:17 <_ikke_> I just found it through google
2020-03-03 20:22:27 <_ikke_> It just says nero :P
2020-03-03 20:22:37 <_ikke_> and I did not focus on that
2020-03-03 20:24:43 <AinNero> tbh i dont have much strong opinions on this anymore
2020-03-03 20:25:35 <AinNero> if i had to design a system from scratch i'd use an empty --prefix and have everything in the root
2020-03-03 20:25:42 <AinNero> like sabotage linux
2020-03-03 20:25:49 <maxice8> Here are the binaries in /bin and /sbin in my system that link to /usr/lib http://ix.io/2diX
2020-03-03 20:25:59 <maxice8> And here are the libraries http://ix.io/2diW :D
2020-03-03 20:26:34 <_ikke_> yeah, nowadays no one is making sure /{lib,bin} is isolated
2020-03-03 20:27:46 <_ikke_> So you cannot even properly boot without /usr even if you wanted to
2020-03-03 20:27:52 <mps> make it to look like windows, crawls like windows, stable as window, organized like windows and call it modern linux :)
2020-03-03 20:28:45 <_ikke_> That's a weak argument. No one wants things to look like windows
2020-03-03 20:29:15 <mps> what's are gnome and kde
2020-03-03 20:29:38 <_ikke_> I think the point is a lot of complexity with no practical benefit
2020-03-03 20:30:03 <mps> I'm more for KISS
2020-03-03 20:30:07 <_ikke_> If you want to be able to have a system without /usr, you would need to do a lot more effort keeping it separate
2020-03-03 20:30:35 <_ikke_> mps: would merging /usr make things more simple?
2020-03-03 20:30:44 <_ikke_> s/would/wouldn't
2020-03-03 20:30:45 <alpine-meetbot> _ikke_ meant to say: mps: wouldn't merging /usr make things more simple?
2020-03-03 20:31:11 <mps> I don't see any problem how it is now
2020-03-03 20:31:47 <_ikke_> Personally, I don't either, but now the distinction seems kind of arbitrary
2020-03-03 20:32:06 <mps> but if I'm someone who want to make my name important I would find reason to change something
2020-03-03 20:32:33 <_ikke_> Sounds like an ad hominem
2020-03-03 20:32:46 <mps> hm, no, sorry
2020-03-03 20:33:01 <mps> didn't intended this
2020-03-03 20:33:35 <_ikke_> fyi, I didn't think you directed that at me
2020-03-03 20:33:37 <_ikke_> or Cogitri
2020-03-03 20:34:49 <mps> right, I didn't had any name in mind, just a some attitudes in general
2020-03-03 20:34:55 <_ikke_> "I’m still waiting for /opt/local to show up" :D
2020-03-03 20:39:31 <maxice8> funniest thing
2020-03-03 20:39:46 <maxice8> systemd works just fine with split-usr, elogind installs to /lib instead of /usr/lib
2020-03-03 20:42:03 <mps> maxice8: what you think about these additions to ncurses-terminfo-base http://tpaste.us/jxoq
2020-03-03 20:42:57 <maxice8> Go ahead
2020-03-03 20:43:32 <mps> ok, we can add something later if we missed it now
2020-03-03 20:43:33 <maxice8> could swear they were in /etc/terminfo and just symlinked to /usr/share/terminfo
2020-03-03 20:43:46 <maxice8> if we are doing that might as well remove the ones in /etc/terminfo
2020-03-03 20:44:01 <mps> doesn't amove do this?
2020-03-03 20:44:12 <maxice8> No
2020-03-03 20:44:16 <mps> oh
2020-03-03 20:44:26 <maxice8> amove basically does mv $pkgdir/foo $subpkgdir/foo
2020-03-03 20:44:53 <mps> aha, then we have to fix this more carefully
2020-03-03 20:46:37 <maxice8> Don't understand why the move is functionally necessary since they are available in /etc/terminfo
2020-03-03 20:47:08 <_ikke_> Why does terminfo even live in /etc?
2020-03-03 20:47:26 <maxice8> You'll have to ask the one who made that change long ago
2020-03-03 20:48:01 <mps> because /usr could be unavailable (not mounted)
2020-03-03 20:48:06 <maxice8> maybe because of usr-split, can't drop to a shell without /usr to rescue your system without /etc/terminfo/l/linux
2020-03-03 20:48:57 <_ikke_> mps: wouldn't that mean it has to go to /lib?
2020-03-03 20:49:05 <_ikke_> or something like that
2020-03-03 20:49:23 <maxice8> there is no /share :D
2020-03-03 20:49:26 <_ikke_> heh
2020-03-03 20:51:48 <mps> huh, it doesn't look good for now
2020-03-04 11:57:37 <_ikke_> maxice8: I think it might make sense to run the test suite on all py3 packages
2020-03-04 11:57:51 <_ikke_> python 3.8.2 upgrade broke at least one package
2020-03-04 11:58:41 <_ikke_> not in a big way, but still
2020-03-04 12:18:14 <maxice8> Ok i'll keep it in mind in case i bump it again
2020-03-04 12:46:28 <maxice8> Also thanks for fixing it
2020-03-04 12:47:02 <_ikke_> I wanted to upgrade it, and noticed that even the current version was not building anymore (test suite failure)
2020-03-04 12:47:13 <_ikke_> turns out the project even prepared the change (as comment) already for 3.8.2
2020-03-04 13:23:48 <maxice8> xbps-0.59 switched to zstd by default, nice
2020-03-04 14:37:12 <timlegge> I have a number of changes in to apkbuild-cpan.in in https://gitlab.alpinelinux.org/timlegge/abuild/commits/apkbuild-cpan-template-versions.  Any requirements to squash commits in the abuild tree?
2020-03-04 14:40:20 <Cogitri> IMHO no, one commit per change is nice
2020-03-04 14:40:30 <Cogitri> Especially if they have nice descriptive messages :)
2020-03-04 15:35:47 <timlegge> added a bunch of fixes for apkbuild-cpan.in in https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/35.  At this point it should be able to deal with most old APKBUILD files and corrects a number of bugs in the current version
2020-03-04 15:36:42 <timlegge> I closed out my previous MR that these changes depended on if someone has time to review.  I have tested on template versions 1 to 3 with each of the possible options and it seems to work well
2020-03-04 19:19:39 <mps> I'm working on backporting musl fixes from 1.2.0 to 1.1.24 in 3.11-stable. what is better: all patches in one commit or one by one, i.e.  for every fix/patch separate commit
2020-03-04 19:22:31 <Cogitri> All patches in one commit with patch headers for each patch
2020-03-04 19:23:32 <mps> what you mean by 'patch headers'?
2020-03-04 19:25:00 <Cogitri> A header in the patch file that state upstream status, purposes etc.
2020-03-04 19:26:44 <mps> they are already in every patch, I don't think it should be repeated in commit msg
2020-03-04 19:26:56 <Cogitri> No, you should add it in the patch
2020-03-04 19:27:02 <Cogitri> Not in the commit msg
2020-03-04 19:27:10 <mps> ah, already there
2020-03-04 19:27:24 <Cogitri> Good
2020-03-04 19:28:02 <mps> but I already commited two of them in separate commits
2020-03-04 19:28:30 <mps> will try to add rest of them in single commit
2020-03-04 19:28:41 <Cogitri> Okie
2020-03-04 19:30:47 <Cogitri> I'm satisfied as long as you add patch header :)
2020-03-04 19:30:55 <Cogitri> 
ACTION really dislikes guessing what some random patch does

2020-03-04 19:31:47 <Cogitri> Actually, I think I'll propose making that patch header mandatory for everything but really trivial patch headers on the ML
2020-03-04 19:34:36 <mps> in that case commits to musl already have commit messages
2020-03-04 19:35:10 <Cogitri> Yes then it's fine
2020-03-04 19:35:19 <Cogitri> I just dislike having a 200 line diff without any explanation
2020-03-04 19:35:33 <Cogitri> Especially if the maintainer is absent and I'm stuck upgrading the thing
2020-03-04 19:35:50 <Cogitri> And then the patch doesn't apply and I have to hope it's not necessary anymore
2020-03-04 19:36:13 <_ikke_> Cogitri: +1
2020-03-04 19:38:15 <mps> blame on me, I seldom add comment
2020-03-04 19:38:56 <mps> but for bigger changes I add in patch or commit msg
2020-03-04 19:39:22 <mps> usually I always add comment in commit msg
2020-03-04 19:42:48 <Cogitri> I don't mean git commit descriptions (although those are nice too)
2020-03-04 19:42:54 <Cogitri> I mean the top part of a patch file
2020-03-04 19:44:45 <mps> I undertood you, don't worry
2020-03-04 19:44:51 <Cogitri> Ah okie
2020-03-04 19:50:14 <mps> Cogitri: if you want to see, here it is https://gitlab.alpinelinux.org/mps/aports/commit/db89bed7243c7c34eb925f1a80da42bd0762c34f
2020-03-05 10:25:37 <maxice8> @ncopa ping
2020-03-05 11:47:21 <PureTryOut[m]> How do you guys deal with packages containing `/home/` in the rpath? I have such a package but can't figure out how to get rid of it. Already tried `chrpath --delete` on all .so files and setting CMAKE_INSTALL_RPATH to something else
2020-03-05 12:53:56 <_ikke_> mps: Did you notice more often that a armv7 CI job showed aarch64 in the build artifacts?
2020-03-05 12:54:55 <Cogitri> PureTryOut[m]: Hm, not sure, chrpath should take care of that. Maybe you forgot a file?
2020-03-05 12:55:34 <Cogitri> You could run find ./ -type f -exec sh -c "readelf -a | grep -i rpath" \; or something along those lines to check
2020-03-05 12:55:50 <PureTryOut[m]> Right now I'm just using a find command which executes chrpath on every .so file it finds. I guess that's not enough?
2020-03-05 13:00:15 <Cogitri> I think you can set rpath on binaries too
2020-03-05 13:01:20 <PureTryOut[m]> I'm using your find command now, let's see what happens 🤷‍♂️
2020-03-05 13:18:19 <mps> _ikke_: I noticed this issue with armv7 CI only when I reported it to you
2020-03-05 13:20:09 <mps> but I didn't download often artifacts, so not sure if it happens seldom or often
2020-03-05 13:22:03 <_ikke_> nod
2020-03-05 13:22:15 <_ikke_> I checked on job where it did use the proper arch
2020-03-05 13:22:54 <mps> I will look next time and inform you about this
2020-03-05 13:34:09 <PureTryOut[m]> Cogitri: doesn't help much sadly
2020-03-05 13:46:25 <Cogitri> PureTryOut[m]: :c
2020-03-05 13:47:16 <PureTryOut[m]> rootbld is also being a pain atm
2020-03-05 13:47:38 <PureTryOut[m]> Is it possible for abuild to complain about rpath even before it has run make install in the package function?
2020-03-05 13:54:57 <Cogitri> Hm, I don't think it should do that, no
2020-03-05 13:58:02 <PureTryOut[m]> Could you give it a shot? The testing/poco package in https://gitlab.alpinelinux.org/PureTryOut/aports/commits/testing_nymphcast
2020-03-05 14:06:50 <Cogitri> Sure, will do in a little
2020-03-05 14:15:43 <PureTryOut[m]> Thanks!
2020-03-05 14:18:51 <PureTryOut[m]> The specific error message from abuild I get:
2020-03-05 14:18:55 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/uYWYOYfcVgUFnKaRCklvSCLN >

2020-03-05 16:01:53 <Cogitri> PureTryOut: With the command I provided I found that the following binaries still have the wrong rpath:
2020-03-05 16:01:54 <Cogitri> ./bin/cpspcd
2020-03-05 16:01:54 <Cogitri> ./bin/cpspc
2020-03-05 16:01:55 <Cogitri> ./bin/f2cpspd
2020-03-05 16:01:56 <Cogitri> ./bin/f2cpsp
2020-03-05 16:02:29 <Cogitri> I ran `find pkg/poco/ -type f -exec sh -c "readelf -a {} | grep -i -q rpath && echo {} " \;`
2020-03-05 16:10:10 <ncopa> maxice8. pong
2020-03-05 16:10:19 <maxice8> @ncopa :D welcome back
2020-03-05 16:10:34 <ncopa> thanks
2020-03-05 16:10:49 <ncopa> im still not home....
2020-03-05 16:10:56 <ncopa> will take the plane later tonight
2020-03-05 16:10:59 <maxice8> then not welcome back
2020-03-05 16:11:05 <maxice8> yet
2020-03-05 16:11:09 <Cogitri> Hope your vacation was nice :)
2020-03-05 16:12:33 <ncopa> was nice
2020-03-05 17:35:21 <_ikke_> FYI: gitlab will be restarted for upgrades
2020-03-05 17:40:48 <mps> ah, I see, that's why I cannot send MR :)
2020-03-05 17:41:00 <_ikke_> It's back online again
2020-03-05 17:42:13 <mps> yes, and works. thanks
2020-03-05 18:18:27 <oneinsect> ./bootstrap.sh: 65: abuild-apk: not found
2020-03-05 18:18:41 <oneinsect> whats abuild-apk? i have apk static and abuild
2020-03-05 18:20:42 <oneinsect> the script sets it on the 5th line SUDO_APK=abuild-apk
2020-03-05 18:20:50 <oneinsect> but what is it?
2020-03-05 18:24:11 <maxice8> part of abuild
2020-03-05 18:25:18 <maxice8> it is a symlink to abuild-sudo apparently
2020-03-05 18:25:25 <maxice8> together with abuild-adduser and abuild-addgroup
2020-03-05 18:25:39 <oneinsect> but i built abuild and i dont see it anywhere .....aha i didnt know that
2020-03-05 18:25:54 <maxice8> see abuild-sudo.c in the abuild source for the program
2020-03-05 18:29:01 <oneinsect> thanks
2020-03-05 20:46:21 <Cogitri> It would be nice if some people could participate in https://lists.alpinelinux.org/~alpine/devel/%3C24b91bd507e8151d41ac1d9866a4fd7a07febfe0.camel%40cogitri.dev%3E
2020-03-05 21:04:52 <wsinatra> oneinsect: I think you asked about a tool to convert package builds to APKBUILDs, am I remembering correctly?
2020-03-05 21:12:35 <mps> Cogitri: though I like MLs I agree with your mail. When we started to discuss move to gitlab idea was to ditch patchwork (which is used at that time besides github)
2020-03-05 21:13:19 <maxice8> I wouldn't mind the ML for patches if it also had the amenities that GitLab has like CI
2020-03-05 21:13:27 <mps> idea was to have one place for patches/MRs/PRs (call it at your preferences)
2020-03-05 21:14:21 <mps> and, in gitlab we can 'link' MR's with but reports to have 'complete' workflow on one place
2020-03-05 21:15:40 <mps> gitlab started to get of the github and to not use patchwork
2020-03-05 21:25:25 <Cogitri> Yes, one hub for patches is a big reason for me already, splitting contributors and devs across multiple platforms (although the split is heavily in favour of Gitlab) kind of sucks
2020-03-05 21:25:56 <Cogitri> I still feel like the ML is fine for discussions and stuff but it just isn't nice for reviewing
2020-03-06 01:10:07 <timlegge> If you are simply updating the format of a APKBUILD file (but also fixing existing abuild issues) should you increment the pkgrel (Package version is unchanged)
2020-03-06 03:49:45 <oneinsect> wsinatra: yes i had asked for a tool to convert package builds into APKBUILDs
2020-03-06 03:59:00 <oneinsect> a quick question folks for the line "CTARGET=$TARGET_ARCH BOOTSTRAP=nobase APKBUILD=$(apkbuildname gcc) abuild".... does abuild read variables CTARGET, BOOTSTRAP and APKBUILD?
2020-03-06 07:24:21 <mps> anyone have time to upgrade mesa? https://www.mesa3d.org/relnotes/20.0.1.html
2020-03-06 07:54:03 <Cogitri> maxice8 maybe
2020-03-06 08:05:18 <Cogitri> I'll be busy with GNOME 3.36
2020-03-06 08:38:30 <PureTryOut[m]> Cogitri: well I noticed one mistake I was making with poco. I was passing CMake a directory to build in, but then forgot to do the same to make. So it wasn't even using the CMake configuration 🤦‍♂️
2020-03-06 08:38:35 <PureTryOut[m]> You'll see that the whole rpath thing is not even an issue now lol
2020-03-06 08:44:07 <PureTryOut[m]> Indeed it isn't, derp
2020-03-06 08:52:16 <Cogitri> Well, good that you've fixed it, I suppose :)
2020-03-06 08:52:24 <Cogitri> But was interesting to play around with readelf
2020-03-06 09:05:05 <PureTryOut[m]> Hmm now `abuild rootbld` fails to find a dependency that I just compiled.
2020-03-06 09:06:11 <PureTryOut[m]> Seems abuild doesn't like a static subpackage having a different architecture (`all`) vs it's main package (`noarch`)?
2020-03-06 09:29:35 <Cogitri> Yes, I think it only works the other way around (a all arch package having a noarch subpackage)
2020-03-06 09:33:10 <PureTryOut[m]> Hmm. But the main package in this case contains nothing, it's just a -static and -dev subpackage
2020-03-06 09:33:30 <maxice8> That is an issue in abuild
2020-03-06 09:34:20 <AinNero> Cogitri: why not convert patch mails into MR's ?
2020-03-06 09:34:30 <PureTryOut[m]> So what can I do about it now maxice8?
2020-03-06 09:34:37 <AinNero> so we get the CI stuff for free
2020-03-06 09:35:26 <maxice8> @PureTryOut the usual workaround is to just have the mainpkg be arch="all"
2020-03-06 09:36:05 <PureTryOut[m]> Ok and just let it complain I guess, sure
2020-03-06 09:36:32 <clandmeter> AinNero: i was just talking to somebody about patch to MR
2020-03-06 09:36:41 <maxice8> @PureTryOut yeah, it is not a complaint about a possible bomb it is a complaint about a possible squirrel that is too loud
2020-03-06 09:36:48 <maxice8> at worst an annoyance
2020-03-06 09:37:26 <PureTryOut[m]> Yeah ok
2020-03-06 09:51:10 <Cogitri> AinNero: A bridge comes with some issues if not done well: How do we ping users in MRs? Do we create temporary accounts? How do we handle v1,v2, vn ?
2020-03-06 09:52:09 <AinNero> not sure if its possible to subscribe externals to gitlab threads
2020-03-06 09:53:43 <PureTryOut[m]> Gitlab supports email patches btw
2020-03-06 09:53:48 <Cogitri> Neat
2020-03-06 09:54:03 <maxice8> really ?
2020-03-06 09:54:05 <PureTryOut[m]> Although idk if the enterprise version is needed for that
2020-03-06 09:54:22 <maxice8> they support email patches but can't support email replies to discussion  like GitHub does ?
2020-03-06 09:54:43 <PureTryOut[m]> Maybe they support it as well? Might just need to  be configured
2020-03-06 09:55:14 <PureTryOut[m]> https://docs.gitlab.com/ee/administration/incoming_email.html
2020-03-06 09:55:39 <PureTryOut[m]> Yeah they do support it
2020-03-06 09:56:43 <clandmeter> we currently dont support incoming email
2020-03-06 09:58:03 <PureTryOut[m]> It can be enabled though. And I think it solves the current issue most people have with emailing patches on both sides
2020-03-06 11:08:29 <maxice8> !5046
2020-03-06 11:08:55 <maxice8> If anyone needs stuff to be done to mesa please comment on that or provide patches relative to what is in that tree
2020-03-06 11:16:57 <Cogitri> I'll test it later today
2020-03-06 11:35:43 <_ikke_> Would be nice if we would have something like use at most so many cores (jobs) for some APKBUILDS
2020-03-06 11:39:12 <_ikke_> hmm, nice, $(()) has comparison and ternary operator
2020-03-06 11:42:28 <_ikke_> http://tpaste.us/pKpW
2020-03-06 11:43:46 <_ikke_> would something like that be acceptable?
2020-03-06 11:44:00 <_ikke_> (usecase, ceph uses too much memory when using all cores)
2020-03-06 12:08:50 <_ikke_> At least ceph now completes with 16 jobs
2020-03-06 12:13:29 <Cogitri> Hm, I think at that point it'd be better if we could set pet APKBUILD job amounts in abuild.conf
2020-03-06 12:13:43 <Cogitri> Since that isn't a general limitation but our infra
2020-03-06 12:21:58 <_ikke_> Yes, but we do not want to manage 6 * 5 abuild.conf files per package
2020-03-06 12:22:20 <_ikke_> and our infra is usually quite beefy
2020-03-06 12:32:29 <Cogitri> Fair
2020-03-06 12:32:44 <Cogitri> In practice it doesn't matter much so I guess setting a limit in the APKBUILD is fine
2020-03-06 13:03:01 <_ikke_> It's just a few packages probably that have these kinds of issues
2020-03-06 13:07:15 <Cogitri> Yup
2020-03-06 13:22:12 <oneinsect> how close is APKBUILD format when compared to PKGBUILD of arch
2020-03-06 13:22:38 <Cogitri> They're a little similiar, as you'll notice comparing them with diff or smth
2020-03-06 13:22:44 <_ikke_> PKGBUILD uses bash, APKBUILD uses POSIX sh
2020-03-06 13:22:54 <Cogitri> ikke: Not really
2020-03-06 13:23:04 <Cogitri> We do use some (b)ash specific extensions here and there
2020-03-06 13:23:34 <_ikke_> Sure, but PKGSBUILD uses bash only syntax
2020-03-06 13:23:38 <_ikke_> PKGBUILD
2020-03-06 13:24:06 <_ikke_> while APKBUILD is accepted by most sh implementations
2020-03-06 13:25:08 <oneinsect> the reason i asked is can i use some PKGBUILD build() and other similar functions to create an APKBUILD file
2020-03-06 13:25:27 <oneinsect> someone here noted the differences
2020-03-06 13:25:29 <oneinsect> https://yuvadm.github.io/pmosweb/wiki/Creating-a-package/
2020-03-06 13:25:35 <mps> if we use bash extensions this should be fixed
2020-03-06 13:25:45 <_ikke_> mps: afaik we don't use bash extensions\
2020-03-06 13:25:56 <_ikke_> just some syntax that's not strictly POSIX
2020-03-06 13:26:03 <Cogitri> I don't think ${var/a/b} is POSIX
2020-03-06 13:26:05 <_ikke_> like ${var/foo/bar}
2020-03-06 13:26:30 <_ikke_> or local in functions
2020-03-06 13:28:08 <_ikke_> oneinsect: the build recipes you can mostly copy
2020-03-06 13:28:19 <_ikke_> but there might be some semantic differences
2020-03-06 13:28:41 <oneinsect> yes thats what i was interested in, yes i will need to test them individually
2020-03-06 13:29:36 <oneinsect> especially openrc stuff
2020-03-06 13:33:31 <mps> well, I don't know much about POSIX '${}' expansion but, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05
2020-03-06 13:33:45 <mps> 2.6.2 Parameter Expansion
2020-03-06 13:34:34 <_ikke_> note that ${foo/bar/baz} is not mentioned
2020-03-06 13:36:31 <mps> noticed it
2020-03-06 13:37:52 <mps> ok, something else, do we mark secfix MR with T-security label, i.e. will it receive more attention
2020-03-06 13:39:06 <_ikke_> perhaps
2020-03-06 13:39:39 <mps> especially if the security issue is public already
2020-03-06 14:04:33 <PureTryOut[m]> Does anybody here know anything about the eudev internals? I need it to get here https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-blkid.c#L40 for an LVM partition (which happens on other distros it seems but not on Alpine). This currently breaks LVM functionality in the KDE kpmcore package
2020-03-06 14:38:04 <wsinatra> oneinsect: https://gitlab.com/Durrendal/toAPK ; this might help in that regard. I ran with your idea and made something that might help
2020-03-06 14:38:54 <wsinatra> It's not perfect, but it's a start, though I've only tested it on a couple of AUR packages
2020-03-06 14:45:05 <fcolista> ping ikk
2020-03-06 14:45:10 <fcolista> _ikke_,
2020-03-06 14:45:30 <fcolista> community/live-media: upgrade to 2020.02.25
2020-03-06 14:45:31 <fcolista> 452f4d932de84a246ccfd26af66f70680abfe586
2020-03-06 14:45:56 <_ikke_> fcolista: pong
2020-03-06 14:46:15 <fcolista> When vlc going to use liblive555 plugin: Error relocating /usr/lib/libliveMedia.so.78: TLS_client_method: symbol not found
2020-03-06 14:46:17 <markand> yes there are some non POSIX things in the aports tree
2020-03-06 14:46:27 <markand> but they are widely supported though (busybox ash, dash)
2020-03-06 14:46:37 <fcolista> I think tkat live-media is missing a -dev depends
2020-03-06 14:46:54 <fcolista> and in turn (maybe) we need to bump pkgrel for vlc
2020-03-06 14:47:17 <markand> honestly I don't understand the restistance of adding 'local' keyword to POSIX sh which is very handy
2020-03-06 14:47:29 <_ikke_> markand: yes, I'm in the same position
2020-03-06 14:48:58 <_ikke_> fcolista: If I recall correctly, I've upgraded it because the builders were stuck on it and the previous version is no longer offered
2020-03-06 14:49:59 <fcolista> ok. Anyway, seems that 2020-03-06 is avail
2020-03-06 14:54:21 <fcolista> umh...
2020-03-06 14:54:21 <fcolista> http://tpaste.us/WRbR
2020-03-06 14:54:45 <fcolista> seems that there's an issue with this openssl version
2020-03-06 15:11:31 <fcolista> sorry, wrong paste.
2020-03-06 15:11:33 <fcolista> http://tpaste.us/ev5V
2020-03-06 15:28:25 <oneinsect> thanks wsinatra: thats wonderful I will check it out
2020-03-06 15:28:58 <oneinsect> i will be finishing a glibc port soon of alpine and then i will test https://gitlab.com/Durrendal/toAPK
2020-03-06 15:30:39 <wsinatra> Consider it a small contribution :) I'm eager to see the glibc port come to fruition
2020-03-06 15:30:51 <oneinsect> i thought of writing it in python but you are fast
2020-03-06 15:31:23 <oneinsect> yes and i think we can use it for our main alpine also once we get toAPK script to production
2020-03-06 15:31:39 <oneinsect> it will a lot of newbies to write and maintain new community software
2020-03-06 15:31:49 <oneinsect> help*
2020-03-06 15:32:07 <wsinatra> I had something like it half written in Common Lisp, so I just rewrote it in Fennel so that it could be used without pulling down SBCL immediately
2020-03-06 15:32:20 <wsinatra> I figured the less overhead to get you where you were going the better
2020-03-06 15:33:36 <oneinsect> its a mountain of work to get glibc version working, infact archlinux packages have so many inter-dependencies, in that sense alpine is so much cleaner
2020-03-06 15:33:51 <oneinsect> thanks
2020-03-06 15:34:01 <oneinsect> i will hang around while i continue this work
2020-03-06 15:34:54 <wsinatra> I think that conclusion is why a lot of us are here
2020-03-06 15:36:00 <wsinatra> Also if you notice anything broken/missing with toAPK let me know, I have a few things in mind to add to it, but you might come up with something too if you use it
2020-03-06 15:36:50 <oneinsect> yes i will test in next couple of days, hopefully once i complete the glibc builds
2020-03-06 15:38:40 <wsinatra> How far have you made building out the base on glibc?
2020-03-06 15:41:34 <oneinsect> well, alpine is very well written, so much so that, apk tools and abuild work perfectly and natively on any host (i use ubuntu 19.10) and they are able to compile and create apk packages by using ubuntu glibc and gcc
2020-03-06 15:41:50 <oneinsect> however ubuntu is going to leak all over the new apks
2020-03-06 15:42:39 <fcolista> ok, live-media is  completely messed up. All the dependent packages are broken
2020-03-06 15:42:47 <_ikke_> ugh
2020-03-06 15:43:01 <oneinsect> hence the next step is scratch build binutils, gcc and glibc, create virtual packages and chroot into it and start building a distro
2020-03-06 15:43:02 <_ikke_> sorry about that
2020-03-06 15:43:23 <fcolista> _ikke_, i think this is broken since a while
2020-03-06 15:43:41 <fcolista> wondering who used rtsp with vlc on alpine, so far
2020-03-06 15:44:02 <wsinatra> you have your work cut out for you oneinsect, are you handling all of this on your own? Or do you have a team to help with it?
2020-03-06 15:44:09 <_ikke_> fcolista: ah ok
2020-03-06 15:44:38 <oneinsect> i have no team, i am all alone, would be helpful to have someone help
2020-03-06 15:45:25 <oneinsect> however the folks in this hangout are great help, though i fear at times i am over disturbing them
2020-03-06 15:46:14 <_ikke_> oneinsect: if we don't have time, we just not respond :)
2020-03-06 15:46:29 <oneinsect> :-P
2020-03-06 15:46:51 <wsinatra> Everyone here is amazing, I think the only way you could disturb them is if you try to convince them to adopt Systemd as the Alpine init system ;)
2020-03-06 15:47:07 <_ikke_> ha!
2020-03-06 15:47:11 <oneinsect> lol
2020-03-06 15:47:19 <oneinsect> i hate systemd to the core
2020-03-06 15:51:42 <fcolista> _ikke_, live-media is broken since forever
2020-03-06 15:52:15 <wsinatra> Personal preference is against it, but I can't rip it out of some things.
2020-03-06 15:52:35 <wsinatra> oneinsect: but anyways, if I can help let me know!
2020-03-06 15:55:37 <oneinsect> sure these VMs are so slow...this laptop I bought in microcenter, alpharetta is too slow
2020-03-06 15:56:53 <oneinsect> okie back to work
2020-03-06 16:23:59 <fcolista> i need ncopa for this linking issue...
2020-03-06 16:32:00 <Cogitri> How come?
2020-03-06 17:03:36 <mps> 'git pull --rebase origin 3.10-stable' doesn't work
2020-03-06 17:04:11 <mps> how to pull current of 3.10-stable
2020-03-06 17:05:25 <Cogitri> How does that not work?
2020-03-06 17:06:10 <mps> community/jenkins is issue
2020-03-06 17:06:46 <Cogitri> Can you send the error message?
2020-03-06 17:06:51 <mps> CONFLICT (content): Merge conflict in community/jenkins/APKBUILD
2020-03-06 17:08:20 <Cogitri> Ah, so either do `git rebase --skip` or do `git reset --hard origin/3.10-stable` (_only_ do the 2nd one if you don't have any unsaved stuff around since that'll remove all not commit data and all new commits on that branch)
2020-03-06 17:08:59 <mps> is it safe to '--skip'
2020-03-06 17:09:47 <mps> I thought to use '--skip' but not sure is it ok
2020-03-06 17:09:58 <Cogitri> Should be, yes (unless you modified community/jenkins yourself)
2020-03-06 17:10:24 <Cogitri> git rebase --skip will abandon the offending patch and just use what's in origin/3.10-stable
2020-03-06 17:10:25 <mps> aha, no I didn't, ok thanks. will try
2020-03-06 17:11:11 <mps> oh, 'CONFLICT (content): Merge conflict in main/nginx/APKBUILD'
2020-03-06 17:11:38 <Cogitri> Huh, are you sure you're not tying to rebase a 3.10 or even master branch into 3.10?
2020-03-06 17:11:46 <Cogitri> s/3.10/3.11/
2020-03-06 17:11:46 <alpine-meetbot> Cogitri meant to say: Huh, are you sure you're not tying to rebase a 3.11 or even master branch into 3.10?
2020-03-06 17:12:04 <mps> sure, I checked out 3.10-stable branch
2020-03-06 17:13:17 <Cogitri> Hm, then you shouldn't have conflicts 🤔
2020-03-06 17:13:47 <mps> I'll reset it and go from start
2020-03-06 18:03:31 <mps> hm, using ${var/foo/bar} doesn't make any sense to my POV
2020-03-06 18:04:37 <mps> yes, it is possible but ...
2020-03-06 18:08:50 <Cogitri> If we don't use that we'd need to spawn a command instead of using built-in functionality which would make parsing APKBUILDs way slower
2020-03-06 18:11:09 <mps> if we say APKBUILD is POSIX we should keep it as such, or we have to say 'POSIX with some additional features'
2020-03-06 18:11:28 <maxice8> APKBUILD is POSIX++ :D
2020-03-06 18:11:37 <mps> :D
2020-03-06 18:12:03 <mps> true, and I'm not against that, just that we should say that
2020-03-06 18:12:13 <nmeum> POSIX with additional features is the current situation that's also why abuild uses /bin/ash instead of /bin/sh
2020-03-06 18:12:33 <nmeum> iirc I also documented this in CODINGSTYLE.md
2020-03-06 18:12:45 <nmeum> yep, I did
2020-03-06 18:12:52 <mps> ah, so I missed that part
2020-03-06 18:13:00 <nmeum> first section of that document
2020-03-06 18:13:09 <mps> good that you done this
2020-03-06 18:13:14 <nmeum> )
2020-03-06 18:13:34 <mps> so, issue fixed :)
2020-03-06 18:13:46 <nmeum> \o/
2020-03-06 18:16:43 <[[sroracle]]> maxice8: have you had any problems with webgl and Mesa recently? i noticed when we went from 18 -> 19 on adelie there was some sort of regression where webgl would no longer work
2020-03-06 18:17:07 <maxice8> Hmmm, i didn't notice any slowdowns when using Firefox on Wayland or chromium on XWayland
2020-03-06 18:17:18 <maxice8> i use the Iris intel driver from mesa-dri-gallium
2020-03-06 18:17:49 <maxice8> Shameless plug: !5046 MESA 20 MR WOOOOO!
2020-03-06 18:21:04 <[[sroracle]]> maxice8: reproducer for me was to try to open google maps in Firefox and the tab would crash if webgl is enabled
2020-03-06 18:21:35 <maxice8> Seems to work fine for me
2020-03-06 18:22:12 <[[sroracle]]> this was Firefox 68 + X11 though as well, so maybe Firefox fixed it on their end or it doesn't reproduce under wayland or with your DRI
2020-03-06 18:22:44 <maxice8> Could be, i am using Mozilla Firefox 73.0.1 with Wayland under swaywm
2020-03-06 18:22:53 <[[sroracle]]> Okay, thank you
2020-03-06 18:27:01 <mps> [[sroracle]]: I'm using FF-esr 68 on aarch64 and can check if you post url
2020-03-06 18:27:21 <mps> X11, no wayland
2020-03-06 18:31:53 <mps> maxice8: I'm downloading mesa 20.1 artifacts, will check it in a hour
2020-03-06 18:32:01 <maxice8> alright
2020-03-06 18:41:18 <[[sroracle]]> mps: https://maps.google.com
2020-03-06 18:41:30 <[[sroracle]]> mps: i dunno if webgl is enabled on aarch64 tho
2020-03-06 18:41:32 <mps> ok, will test
2020-03-06 18:42:50 <[[sroracle]]> if you can zoom in and out smoothly that generally means webgl is active and if it kinda re-renders it or is kinda choppy zooming then it isn't in my testing
2020-03-06 18:43:08 <[[sroracle]]> and if it crashes as soon as it opens that means you have the same problem as me
2020-03-06 18:46:24 <mps> it doesn't crash but it is not so smooth
2020-03-06 18:46:34 <mps> but acceptable
2020-03-06 18:49:36 <mps> and webgl.disabled is false in about:config
2020-03-06 18:53:16 <mps> later will boot armv7 box, it is most responsive of all machines I have
2020-03-06 19:18:40 <oneinsect> compilation is so slow, darn i wish i had an i9
2020-03-06 19:19:53 <Cogitri> I think you meant a Ryzen 3xxx there :P
2020-03-06 19:20:25 <[[sroracle]]> mps: does it say webgl is enabled on about:support?
2020-03-06 19:21:40 <oneinsect> haaahaaa, ofcourse ryzen would be much better
2020-03-06 19:30:02 <mps> [[sroracle]]: I have issues with rockchip drm driver and analogix_dp, reported bug to kernel maintainers about week ago but didn't received response yet
2020-03-06 19:31:43 <mps> didn't know for 'about:support' :)
2020-03-06 19:32:34 <mps> there are some tables with WebGL 1 and 2 with a lot of data which I don't know what they means
2020-03-06 19:40:29 <mps> WebGL 1 Driver Version  3.1 Mesa 20.0.1 (git-53b2b224dc)
2020-03-06 19:40:47 <mps> WebGL 2 Driver Version  3.3 (Core Profile) Mesa 20.0.1 (git-53b2b224dc)
2020-03-06 19:53:55 <mps> maxice8: upgraded to mesa 20.1, for now it works, will see is it stable
2020-03-06 20:20:23 <maxice8> Am playing Eu4
2020-03-06 20:20:26 <maxice8> Lots of fun
2020-03-06 20:24:26 <oneinsect> guys once i have a list of packages and a simple alpine system what is the starting point for creating an iso?
2020-03-07 02:32:37 <timlegge> Looking through some old perl-modules that are not supported by the apkbuild-cpan script and noticed that the reason in some cases is because the module had been renamed some point.  Time-modules -> Time::Parsedate.  Should the older modules be deleted?  Moved to unmaintained if there is a package with a replaces=the old module?
2020-03-07 06:36:45 <_ikke_> i would just remove it
2020-03-07 12:20:17 <mps> hm, 886668b708b77dbd0bfeacde6bb695f7aa7451ae
2020-03-07 12:20:53 <Cogitri> Hm?
2020-03-07 12:21:00 <mps> and, '+pkgdesc="iA Performance monitoring tools"', anyone have idea why 'iA' prefix is added
2020-03-07 12:21:47 <mps> is the Fabian Affolter here?
2020-03-07 12:22:01 <_ikke_> mps: probably a typo
2020-03-07 12:22:07 <_ikke_> mps: i for vim insert I guess
2020-03-07 12:22:19 <mps> I think so
2020-03-07 12:22:39 <mps> preparing upgrade MR, I think it is safe to remove this prefix
2020-03-07 12:23:57 <_ikke_> yes
2020-03-07 12:25:59 <mps> ok, thanks
2020-03-07 13:22:00 <nmeum> mps: Fabian was never in the IRC channel (iirc) you could try writting him an email
2020-03-07 13:22:20 <oneinsect> who is fabian?
2020-03-07 13:22:40 <nmeum> an alpine contributor
2020-03-07 13:22:50 <oneinsect> :-D
2020-03-07 13:22:57 <nmeum> https://pkgs.alpinelinux.org/packages?name=&branch=edge&maintainer=Fabian+Affolter
2020-03-07 13:23:24 <oneinsect> ooOO
2020-03-07 13:23:35 <oneinsect> i remember him now
2020-03-07 13:27:23 <oneinsect> hello algitbot: whats news
2020-03-07 13:29:09 <_ikke_> algitbot: o/
2020-03-07 13:30:20 <oneinsect> she doesnt seem to like you _ikke_:
2020-03-07 13:30:30 <oneinsect> :-P
2020-03-07 13:31:17 <_ikke_> oneinsect: neither you ;-)
2020-03-07 13:31:27 <oneinsect> heeheee
2020-03-07 13:32:00 <mps> nmeum: thanks for info, I fixed sysstat pkgdesc already and created MR, so don't need to contact him
2020-03-07 13:32:12 <mps> algitbot:
2020-03-07 13:32:20 <mps> nor me :)
2020-03-07 13:32:28 <mps> \o
2020-03-07 16:11:25 <Cogitri> Does someone have opinions on !4704?
2020-03-07 16:18:03 <_ikke_> I don't see any other distros installing it in /opt/<provider>/
2020-03-07 16:20:48 <_ikke_> archlinux: /usr/lib/couchdb, fedora: /usr/share/couchdb
2020-03-07 16:22:36 <_ikke_> apparently the couchdb provided packages just drop it in /opt/couchdb
2020-03-07 16:35:05 <Cogitri> Yes, I'd opt for putting it in /usr/lib too
2020-03-07 20:44:53 <_ikke_> maxice8: libical build error
2020-03-07 20:45:00 <_ikke_> error parsing file /home/buildozer/aports/main/libical/src/libical-3.0.8/build/src/libical-glib/ICalGLib-3.0.gir: Error on line 1 char 1: Document was empty or contained only whitespace
2020-03-07 20:45:17 <maxice8> huh
2020-03-07 20:45:19 <maxice8> that is a new error
2020-03-07 20:58:45 <kpcyrd> did somebody point out https://github.com/curl/curl/commit/8aa04e9a24932b830bc5eaf6838dea5a3329341e yet?
2020-03-07 20:59:28 <_ikke_> kpcyrd: Are you running into that?
2020-03-07 20:59:31 <kpcyrd> cargo is currently broken in edge due to libcurl 7.69.0, the issue is resolved when applying that patch ^
2020-03-07 20:59:41 <_ikke_> ok
2020-03-07 21:00:11 <_ikke_> kpcyrd: No new release from curl yet, right?
2020-03-07 21:00:16 <kpcyrd> archlinux currently has an update in [testing] as well
2020-03-07 21:00:18 <_ikke_> nope
2020-03-07 21:03:35 <Cogitri> Happens to flatpak too
2020-03-07 21:03:46 <_ikke_> Preparing fix
2020-03-07 21:04:16 <_ikke_> Cogitri: Do we have a standardized patch header yet?
2020-03-07 21:04:21 <_ikke_> or semi-standard
2020-03-07 21:06:21 <Cogitri> https://exherbo.org/docs/eapi/exheres-for-smarties.html#applying_patches
2020-03-07 21:06:25 <Cogitri> I like this
2020-03-07 21:10:35 <_ikke_> ok
2020-03-07 21:14:12 <_ikke_> ttps://github.com/curl/curl/issues/5044
2020-03-07 21:14:14 <_ikke_> arg
2020-03-07 21:14:16 <_ikke_> http://tpaste.us/6Vz9
2020-03-07 21:17:32 <_ikke_> pushed
2020-03-07 21:18:04 <_ikke_> kpcyrd: I've pushed it, but the x86_64 builder is stuck now on libical.
2020-03-07 21:18:42 <Cogitri> Builds curl now
2020-03-07 21:19:02 <_ikke_> ah ok
2020-03-07 21:25:29 <maxice8> Builds fine locally and on CI, i wonder why the builder falls out like that
2020-03-07 21:26:05 <Cogitri> Maybe due to more build jobs
2020-03-07 21:28:43 <_ikke_> maxice8: let me know if you want me to check something on the builder
2020-03-07 21:30:21 <maxice8> huh
2020-03-07 21:30:22 <maxice8> it built
2020-03-07 21:30:26 <maxice8> spurious multi-job error ?
2020-03-07 21:30:32 <_ikke_> sounds like it
2020-03-07 21:31:31 <_ikke_> I wonder what I should do with https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4696
2020-03-07 21:33:56 <maxice8> push
2020-03-07 21:35:06 <_ikke_> it's still compiling with -O3, rather than our standard -Os
2020-03-07 21:35:14 <maxice8> oh
2020-03-07 21:35:15 <maxice8> then not push
2020-03-07 21:35:54 <_ikke_> But I don't see an easy fix without having th hardcode the compile flags or do some hackish things
2020-03-07 21:36:07 <_ikke_> The project does not have a proper autoconf
2020-03-07 21:37:03 <maxice8> i see
2020-03-07 21:38:40 <_ikke_> test failures for trivy on s390x
2020-03-07 21:39:47 <_ikke_> Maybe I just push it, it has been using -O3 for ages so it's not that it regresses
2020-03-07 21:39:57 <Cogitri> Yup
2020-03-07 21:40:10 <Cogitri> And breaking something like unzip probably isn't fun
2020-03-07 21:40:23 <_ikke_> right
2020-03-07 21:47:59 <Cogitri> Do maintainer changes need pkgrel bumps
2020-03-07 21:49:22 <_ikke_> If you want it to show up in pkgs.a.o, yes
2020-03-07 22:00:50 <Cogitri> Okie
2020-03-07 22:57:47 <reidrankin> can somebody enlighten me on the difference between the 'armv7' and 'armhf' architectures?
2020-03-07 22:58:03 <reidrankin> as used by the packages
2020-03-07 22:58:39 <reidrankin> obviously armhf has hardware floating point, but is it v7 as well or what?
2020-03-07 22:59:52 <crashoverride> v7 is between v6 and v8, it's a hybrid engine, the V version of the straight seven cylinder engine.
2020-03-07 23:00:48 <reidrankin> crashoverride: whereas armhf has a hardware floating point so it can be used in marine vehicles, I get it now
2020-03-07 23:01:04 <dalias> it's very bad naming
2020-03-07 23:01:23 <dalias> alpine used to have a non-hardfloat v5 or v6 target that was dropped
2020-03-07 23:01:28 <mps> misleading
2020-03-07 23:01:28 <crashoverride> reidrankin: indeed.
2020-03-07 23:01:35 <dalias> armhf is armv6 with hardfloat abi
2020-03-07 23:01:40 <dalias> armv7 is armv7 with hardfloat abi
2020-03-07 23:01:46 <reidrankin> ... ah.
2020-03-07 23:01:59 <crashoverride> but in other distros, armhf is armv7
2020-03-07 23:02:28 <dalias> i dont know why alpine did it this way :/
2020-03-07 23:03:07 <dalias> ideally there wouldn't be separate package repositories for minor isa level differences, only for mutually incompatible abis
2020-03-07 23:03:13 <crashoverride> like everything else that happened, it "just happened" that way. No reason.
2020-03-07 23:03:17 <dalias> but ppl want to run v7-optimized stuff on v7
2020-03-07 23:03:28 <mps> alpine armv7 user space is compiled wuth -thumb while armhf is not, iirc
2020-03-07 23:03:35 <dalias> imo the best way would have been just having a few performance critical packages you could replace with v7 versions
2020-03-07 23:03:50 <dalias> and a single package repo for arm (hf)
2020-03-07 23:04:05 <dalias> yeah, what mps said
2020-03-07 23:04:22 <dalias> armhf vs armv7 us like i586 vs i686
2020-03-07 23:04:25 <dalias> is*
2020-03-07 23:04:37 <mps> and armhf will probably abandoned
2020-03-07 23:04:46 <dalias> :/
2020-03-07 23:04:51 <dalias> aren't lots of pi's v6 ?
2020-03-07 23:04:56 <reidrankin> so why is linux-rpi2 avaliable in armhf and armv7 flavors?
2020-03-07 23:05:11 <dalias> or are they all v7?
2020-03-07 23:05:12 <reidrankin> pi v1 was v6, but v2 and up are v7 IIRC
2020-03-07 23:05:19 <dalias> pi zero too?
2020-03-07 23:05:20 <mps> yes, and not only rpi's
2020-03-07 23:05:44 <dalias> pi zero is in many ways the most interesting for a lite distro like alpine to support
2020-03-07 23:05:56 <dalias> pi4 can run raspian just fine
2020-03-07 23:06:06 <dalias> but it's hell on the lower-end ones
2020-03-07 23:06:17 <mps> it is proposed to abandon after 3.10 release, but we didn't and part of that is my mistake
2020-03-07 23:06:55 <mps> now I think we should remove it
2020-03-07 23:07:19 <dalias> :(
2020-03-07 23:07:47 <mps> we do not have enough testers for it
2020-03-07 23:07:58 <mps> this is big issue
2020-03-07 23:08:49 <mps> I borrowed one pi zero just for testing, and not because I need it
2020-03-07 23:09:33 <mps> and a lot of pkgs are disabled on armhf
2020-03-07 23:10:05 <mps> it is hard to keep armhf up-to with other arches
2020-03-07 23:10:36 <mps> not that I like this situation :(
2020-03-07 23:11:46 <dalias> why can't it just be tested on high-end arm hardware?
2020-03-07 23:12:08 <mps> when the removal is proposed I was against with a hope that some people will help to keep it, but not much people tried to help
2020-03-07 23:12:22 <dalias> just like i486 can be tested on high-end x86_64
2020-03-07 23:12:36 <mps> hm, maybe
2020-03-07 23:13:09 <mps> but I'm not sure will these be 'safe' tests
2020-03-07 23:13:52 <mps> if we made it for RPi zero we want to be sure it works on it
2020-03-07 23:14:50 <mps> but it will stay for 3.12 release, probably
2020-03-07 23:14:53 <reidrankin> I'm working on a project right now targeting an RPI3, and we're using armhf because we assumed that the other one lacked hard-float support
2020-03-07 23:15:05 <reidrankin> confusion bad
2020-03-07 23:15:21 <mps> reidrankin: better option in that case is armv7
2020-03-07 23:15:35 <reidrankin> yeah, I'll see what we can do to move over
2020-03-07 23:15:55 <afontain_> I think armv7 implies hf, while armv6 doesn't
2020-03-07 23:16:36 <afontain_> so that would be why there is the one that specify hf, while the other doesn't
2020-03-07 23:16:49 <mps> afontain_: http://single-boards.com/armv6-vs-armv7/
2020-03-07 23:18:49 <mps> (arm ecosystem is a jungle)
2020-03-07 23:22:23 <afontain_> well, that's a nice read
2020-03-07 23:22:25 <afontain_> good night
2020-03-07 23:23:55 <mps> also I will go to bed, good night
2020-03-08 01:58:16 <kpcyrd> _ikke_: the latest update fixed the cargo build issue for me, thanks!
2020-03-08 01:58:31 <kpcyrd> _ikke_: there has been another update in arch though: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/curl&id=7ea0545f9790617520580710c7ab1dc39cfc4f78
2020-03-08 11:01:25 <clandmeter> looks like we lost some git master commits due to forced push
2020-03-08 11:01:36 <clandmeter> could be you get errors when you pull
2020-03-08 11:04:09 <Cogitri> If you pulled within the last 6 hours that is
2020-03-08 11:05:14 <clandmeter> please do not push any new commits to aports
2020-03-08 11:05:25 <maxice8> ack
2020-03-08 11:20:42 <clandmeter> we have temp disabled git.a.o
2020-03-08 11:20:47 <clandmeter> this means for all repos
2020-03-08 12:22:45 <clandmeter> issues should be resolved
2020-03-08 12:23:01 <clandmeter> i hope not to many ppl have broken locals, else you need to force pull.
2020-03-08 12:23:01 <_ikke_> push access has been restored
2020-03-08 12:23:14 <_ikke_> Yes, please verify your local history before pushing new changes
2020-03-08 12:23:32 <_ikke_> Make sure you don't accidentally merge the old and new history together
2020-03-08 12:24:07 <clandmeter> we have disabled forced pushes
2020-03-08 12:24:13 <clandmeter> so that should be ok now
2020-03-08 12:26:33 <maxice8> git.a.o/aports doesn't exist
2020-03-08 12:30:39 <_ikke_> maxice8: sorry, what do you mean?
2020-03-08 12:30:48 <_ikke_> It does exist for me
2020-03-08 12:30:52 <maxice8> https://git.alpinelinux.org/aports/log gives me 404
2020-03-08 12:31:10 <_ikke_> ah, in cgit
2020-03-08 12:31:12 <_ikke_> hmm
2020-03-08 12:31:14 <clandmeter> Via webif
2020-03-08 12:31:22 <clandmeter> It's permissions
2020-03-08 12:31:27 <_ikke_> ah ok
2020-03-08 12:31:33 <clandmeter> I think
2020-03-08 12:31:41 <_ikke_> for what?
2020-03-08 12:31:56 <clandmeter> It should be read by all
2020-03-08 12:32:02 <clandmeter> I guess
2020-03-08 12:32:08 <clandmeter> I'm not at PC
2020-03-08 12:34:09 <_ikke_> strange, it was missing from projects.list
2020-03-08 12:34:17 <_ikke_> maxice8: it's back
2020-03-08 12:34:28 <maxice8> ty
2020-03-08 12:49:34 <_ikke_> Cogitri: i've bumped all affected packages, so mutter is being rebuilt as well
2020-03-08 12:56:48 <Cogitri> Ah, okie
2020-03-08 13:08:33 <minecrell> Cogitri: Wow, I have to install entire texlive for evince now :(
2020-03-08 13:08:43 <minecrell> 
ACTION was wondering why the upgrade takes so long

2020-03-08 13:12:15 <Cogitri> Oh right, I wanted to split that out
2020-03-08 13:12:22 <Cogitri> But evidently I didn't
2020-03-08 13:13:36 <minecrell> I was confused for a moment, couldn't remember that I installed texlive on this horribly slow tablet :)
2020-03-08 13:14:03 <Cogitri> ikke: Seems like gnome-shell still pulls in the wrong mutter version, I guess I missed some rebuild for a lib?
2020-03-08 13:16:00 <Cogitri> Ah, seems like we can't actually split that out
2020-03-08 13:16:07 <Cogitri> Well, back to using evince's internal synctex then, I suppose
2020-03-08 13:17:51 <Cogitri> It'd be best if we were to split texlive into more packages, but messing with texlive doesn't sem fun :P
2020-03-08 13:31:51 <mps> is it safe now to 'git pull -rebase --all', git.a.o and gitlab.a.o
2020-03-08 13:34:31 <_ikke_> Cogitri: what version of mutter should be used?
2020-03-08 13:43:21 <_ikke_> Cogitri: apparently there are multiple versions of mutter in the builder repo :-/
2020-03-08 13:43:49 <_ikke_> Cogitri: https://tpaste.us/na76
2020-03-08 13:44:56 <_ikke_> mps: just enough to make sure your local master matches git.a.o's master
2020-03-08 13:45:26 <mps> ok, thanks
2020-03-08 13:59:36 <Cogitri> ikke: Oh yes, mutter 3.36 is required, I made a proper dep on it now
2020-03-08 14:04:31 <_ikke_> hmm
2020-03-08 14:05:50 <Cogitri> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/gnome-shell/gnome-shell-3.36.0-r0.log
2020-03-08 14:06:26 <Cogitri> But I did bump gnome-control-center and cheese for the new gnome-desktop
2020-03-08 14:07:06 <_ikke_> The builders repos need to be reset I guess
2020-03-08 14:11:33 <fcolista> what's the correct way on gitlab to set the version "affected" by a specific bug?
2020-03-08 14:11:54 <fcolista> it's Label?
2020-03-08 14:13:05 <Cogitri> Version as in 3.[0-9][0-9]-stable?
2020-03-08 14:14:23 <mps> branch name or milestone?
2020-03-08 14:14:24 <fcolista> right
2020-03-08 14:14:50 <Cogitri> Then the label, yes
2020-03-08 14:14:56 <Cogitri> And a milestone I guess
2020-03-08 14:15:04 <fcolista> ok, good. Thanks
2020-03-08 14:15:16 <fcolista> Umh
2020-03-08 14:15:50 <fcolista> how? Milestone can be set for one specific versin
2020-03-08 14:15:53 <fcolista> *version
2020-03-08 14:17:39 <mps> fcolista: do you mean bug report on gitlab issues
2020-03-08 14:17:47 <fcolista> yes
2020-03-08 14:18:04 <mps> fixes: #issue number
2020-03-08 14:18:23 <mps> in commit msg
2020-03-08 14:18:26 <fcolista> mps, I was unclear.
2020-03-08 14:18:29 <fcolista> This but:
2020-03-08 14:18:32 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/issues/11273**bug
2020-03-08 14:18:33 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/issues/11273
2020-03-08 14:18:42 <fcolista> affects several version of Alpine
2020-03-08 14:18:47 <fcolista> v3.8-edge
2020-03-08 14:19:14 <fcolista> When I fill a bug, how can I set that this bug affects these versions?
2020-03-08 14:19:32 <mps> ah, yes, I see. I had few times problem with it
2020-03-08 14:19:32 <_ikke_> I don't think we have anything for that yet
2020-03-08 14:19:41 <fcolista> It's enough put the label v3.8, v3.9 etc
2020-03-08 14:19:49 <fcolista> oh ok
2020-03-08 14:19:54 <fcolista> I felt stupid :)
2020-03-08 14:20:48 <mps> fcolista: heh, we all sometimes fell same like this, gitlab is new for most of us
2020-03-08 14:20:59 <mps> feel
2020-03-08 14:41:52 <_ikke_> Cogitri: gnome-desktop-3.34.4-r1:
2020-03-08 14:41:54 <_ikke_>     breaks: gnome-desktop-dev-3.35.91-r1[gnome-desktop=3.35.91-r1]
2020-03-08 14:42:19 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/gnome-shell/gnome-shell-3.36.0-r0.log
2020-03-08 14:50:37 <Cogitri> Yes
2020-03-08 14:50:56 <Cogitri> But I did push commits which bumped the pkgrel for cheese and gnome-control-center
2020-03-08 14:58:21 <Cogitri> Maybe that got lost in the git thingie
2020-03-08 14:59:17 <Cogitri> But even then the builders should've figured out the right order?
2020-03-08 14:59:29 <Cogitri> Oh well, I guess it's time for more pkgrel bumps then
2020-03-08 16:03:59 <mps> dalias: are you running alpine 3.11 or edge
2020-03-08 16:04:35 <mps> nsd on 3.11 got ratelimit, and there is MR for edge
2020-03-08 16:15:51 <Cogitri> ikke: The builders are acting really weird
2020-03-08 16:16:03 <maxice8> huh
2020-03-08 16:16:09 <maxice8> aports.git is not found which broke my remote
2020-03-08 16:16:39 <Cogitri> The pkgrel for all the packages that need gnome-desktop (which had a soname bump) has been bumped but somehow they haven't been rebuilt against the new gnome-desktop
2020-03-08 16:18:19 <maxice8> fatal: repository 'https://git.alpinelinux.org/aports/' not found
2020-03-08 16:19:13 <_ikke_> hmm, indeed
2020-03-08 16:19:32 <maxice8> hey, at least i found a logic error in my git pull script :D
2020-03-08 16:21:47 <_ikke_> "Repository not exported"
2020-03-08 16:23:37 <_ikke_> maxice8: works again
2020-03-08 16:23:51 <_ikke_> but wonder why first on the webif, and now git-http-back broke
2020-03-08 16:25:10 <_ikke_> Cogitri: ping
2020-03-08 16:34:45 <Cogitri> ikke: pong
2020-03-08 16:35:07 <_ikke_> looking at the gnome-desktop issue
2020-03-08 16:35:17 <Cogitri> Thanks
2020-03-08 16:35:41 <Cogitri> Well, I guess I could just push the commits again with pkgrel++
2020-03-08 16:35:54 <_ikke_> First want to see what's happening
2020-03-08 16:39:13 <_ikke_> when gnome-session was built, it used: "(161/469) Installing gnome-desktop (3.34.4-r1)"
2020-03-08 16:40:09 <_ikke_> This is what it does now on the builder: "(375/472) Installing gnome-desktop-dev (3.35.91-r1)  "
2020-03-08 16:40:16 <_ikke_> So bumping would fix it I guess
2020-03-08 16:48:09 <_ikke_> gnome-initial-setup, gnome-session and gdm need to be bumped apparently
2020-03-08 16:55:14 <_ikke_> strange, the build dependency order seems randomly switch gdm and gnome-session
2020-03-08 16:56:04 <_ikke_> ap builddirs lists them in the correct order always
2020-03-08 17:00:04 <_ikke_> Cogitri: at least for now, it seems 'fixed'
2020-03-08 17:06:28 <Cogitri> Thanks
2020-03-08 17:08:01 <_ikke_> maxice8: gitea has test failures
2020-03-08 17:13:11 <maxice8> i saw
2020-03-08 17:18:17 <dalias> mps, edge but i don't keep it dist-upgraded
2020-03-08 17:25:36 <Cogitri> ikke: Seems like some stuff still needs the old gnome-desktop
2020-03-08 17:25:42 <Cogitri> Can I go ahead and bump?
2020-03-08 17:27:16 <Cogitri> Do conflicts work with version constraints?
2020-03-08 17:27:39 <Cogitri> E.g. !libX>1.16 ?
2020-03-08 17:34:41 <mps> dalias: MR is !5154
2020-03-08 17:35:06 <mps> would someone push it, I can't, it is in main
2020-03-08 17:36:42 <_ikke_> Cogitri: afaik no
2020-03-08 17:38:31 <Cogitri> That's unfortunate
2020-03-08 17:40:38 <Cogitri> When upgrading with network-manager-applet everyone gets conflicts right now
2020-03-08 17:40:51 <Cogitri> Because libnma was split out of network-manager-applet
2020-03-08 17:41:12 <Cogitri> So it overwrites files of the old version
2020-03-08 17:59:34 <maxice8> Anyone needs a last minute main/ merge ? i'm going party
2020-03-08 18:00:47 <mps> maxice8: !5154 if you have some time
2020-03-08 18:01:15 <mps> you already pushed same for 3.11-stable last night
2020-03-08 18:01:26 <mps> thanks :)
2020-03-08 18:02:03 <mps> enjoy your party :)
2020-03-08 18:37:57 <Cogitri> Seems like chmod-clean doesn't work for gitea: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/gitea/gitea-1.11.2-r1.log
2020-03-08 18:51:41 <maxice8> It does, the options were overridden stupidly by me
2020-03-08 18:51:54 <maxice8> In the first case statement iirc the problem is
2020-03-08 18:53:09 <Cogitri> Ah
2020-03-08 18:55:54 <Cogitri> Fixed
2020-03-08 18:56:10 <Cogitri> And my things build now, hooray
2020-03-08 18:57:37 <maxice8> Yaay
2020-03-08 19:06:29 <Cogitri> Oh derp bumping everything for gnome-desktop wasn't required apparently, gitea just blocked the builders
2020-03-08 19:08:04 <maxice8> Lol
2020-03-08 19:28:13 <_ikke_> fcolista: btw, it seems that kubernetes builds again
2020-03-08 19:29:02 <fcolista> _ikke_, good to know
2020-03-08 19:29:57 <_ikke_> 1.17.3
2020-03-08 19:30:13 <_ikke_> It failed to package because it could not find hyperkube
2020-03-08 19:30:23 <fcolista> ok
2020-03-08 19:31:46 <fcolista> i need to go ahead and split packages
2020-03-08 19:36:08 <dalias> mps, ?
2020-03-08 19:39:52 <mps> dalias: what ?
2020-03-08 19:40:16 <_ikke_> "mps │ dalias: MR is !5154"
2020-03-08 19:40:36 <mps> it is pushed
2020-03-08 19:40:52 <mps> isn't it
2020-03-08 19:43:34 <mps> oh, we are over 5000 MRs on gitlab
2020-03-08 19:44:08 <_ikke_> For a while now
2020-03-08 19:44:15 <dalias> mps, i was just asking why you were telling me about it
2020-03-08 19:44:23 <dalias> was there something you wanted me to look at?
2020-03-08 19:44:41 <mps> ah, didn't you asked about it few days ago on #musl
2020-03-08 19:45:35 <dalias> no, someone was recommending i turn off that option if it's enabled since it costs lots of memory
2020-03-08 19:45:42 <mps> your question was 'signal' that I should look why it is not enabled on alpine
2020-03-08 19:45:44 <dalias> and then realized the alpine package didn't support it anyway
2020-03-08 19:45:54 <dalias> i see
2020-03-08 19:46:15 <mps> yes, but it can be useful in some cases
2020-03-08 19:47:07 <mps> though it can consume memory because with this option it need to track connections
2020-03-08 19:47:34 <mps> because that I added default-off
2020-03-08 19:48:27 <mps> btw, we had question today on #alpine-linux why getent doesn't support shadow
2020-03-08 19:48:54 <dalias> oh?
2020-03-08 19:49:22 <_ikke_> "its related to cdist's user/ssh pubkey management"
2020-03-08 19:49:22 <mps> would be nice to hear 'authoritative' answer ready if question arise again
2020-03-08 19:57:16 <dalias> i mean why doesnt it work? it is just an omission? or something hard to do?
2020-03-08 19:58:05 <mps> omission, probably
2020-03-08 20:16:49 <_ikke_> dalias: getent does not recognize shadow
2020-03-08 21:25:33 <iggy> anybody know if the gitlab user "Leo" is on irc and what their nick might be if so?
2020-03-08 21:25:55 <Cogitri> It's maxice8, but he's currently not available
2020-03-08 21:26:19 <maxice8> I am here
2020-03-08 21:26:27 <maxice8> Currently playing cards with 2 drunk friends
2020-03-08 21:27:23 <iggy> it can wait, just wanted to ask a question about micro at some point since you seem to be the most recent/frequent to touch it
2020-03-08 21:30:04 <maxice8> Hit my mailbox and I'll answer when I get home
2020-03-08 21:30:23 <maxice8> Same address as my maintainer address
2020-03-09 06:34:08 <ncopa> morning!
2020-03-09 06:34:16 <ncopa> im finally back for real
2020-03-09 06:36:29 <Cogitri> Morning :)
2020-03-09 06:40:45 <Cogitri> I think most MRs that need your attention are  assigned to you and I'd appreciate if you could check out the devel mailing list
2020-03-09 06:49:21 <ncopa> ok
2020-03-09 06:49:28 <ncopa> we still push to git.a.o right?
2020-03-09 07:07:19 <mps> yes, still
2020-03-09 07:08:39 <mps> is 'amove' documented somewhere? or 'read the source, Luke'
2020-03-09 07:17:31 <Cogitri> mps: Was wondering that too, I think maxice8 introduced it
2020-03-09 07:17:59 <Cogitri> I think it basically does `install -Dm755 /path/to/file $pkgdir/path/to/file`
2020-03-09 07:19:35 <mps> not much pkgs (APKBUILDs) use it
2020-03-09 07:34:21 <mps> I'm thinking of renaming ncurses-terminfo subpkg to ncurses-terminfo-extra (or similar), we have ncurses-terminfo-base
2020-03-09 07:34:48 <mps> or shorten both, terminfo-extra and terminfo-base
2020-03-09 07:34:52 <mps> ?
2020-03-09 07:35:16 <Cogitri> I'd keep the ncurses prefix
2020-03-09 07:37:24 <Cogitri> ncopa: Also, I think abuild and mkinitfs need some MRs merged
2020-03-09 07:37:31 <mps> anything else except ncurses provides terminfo ?
2020-03-09 07:38:39 <mps> terminfo files, I mean. except some terminal packages which installs their terminfo
2020-03-09 09:05:06 <markand> I'm not a huge fan of all those helpers, it adds learning curve to newcomers and APKBUILDs get less explicit in favor of POSIX commands that everybody know
2020-03-09 09:05:27 <markand> I scratch my head each time I see a void linux package with all their custom helpers vbin, vman, vmove, etc.
2020-03-09 09:05:47 <markand> just look how many dh_* commands exist in debian, it's insane
2020-03-09 09:06:26 <Cogitri> Hm, I do like the convenience they provide but it's nice how simple aports are, yes
2020-03-09 09:07:29 <Cogitri> I think something like Void's build_styles would be very beneficial for APKBUILDs though, right now they're very repetitive for every package
2020-03-09 09:07:46 <Cogitri> And it's really annoying doing big changes due to that (like the build style thingie)
2020-03-09 09:28:47 <mps> I agree with markand
2020-03-09 09:36:12 <ncopa> I have tried to avoid those helpers for a while (a decade or more) for exactly the reason markand points out
2020-03-09 09:37:23 <ncopa> however, the number of APKBUILDs are increasing and making it eaiser to maintain those we have is becoming more important that make it easy for new people to add new APKBUILDs
2020-03-09 09:38:38 <minecrell> ncopa: I think you forgot to reset pkgrel to 1 in linux-lts, now all the modules try to find a non-existent -r0 of it :)
2020-03-09 09:38:52 <ncopa> i want keep the number of helpers down
2020-03-09 09:38:58 <ncopa> oh.. :-/
2020-03-09 09:39:31 <ncopa> minecrell: actually, i merged a MR after I had built the kernel and thirdparties
2020-03-09 09:40:33 <ncopa> oh well...
2020-03-09 09:42:26 <mps> how the helpers make it easy for people to add new pkgs, 'install', 'mv', 'rm', 'cp' are well known and don't hide anything
2020-03-09 09:48:13 <markand> note that install isn't POSIX either
2020-03-09 09:48:26 <markand> and it has various different behavior on several platforms
2020-03-09 09:48:56 <markand> when I see chmod 755 "$pkgdir"/bin/foo I know exactly what the APKBUILD does
2020-03-09 09:49:23 <markand> if I see amove foo "$pkgdir"/bin/foo I'll have to dig / remember again and again each of those helper
2020-03-09 09:52:11 <Cogitri> Yes, I think not including amove or something is fair
2020-03-09 09:52:41 <Cogitri> But a build helper which runs meson for you with all the right options instead of needing to add that to all APKBUILDs does seem like a nice thing to me without too much magic
2020-03-09 09:53:32 <Cogitri> Right now we have a really annoying mix of options with meson in APKBUILDs, some only set prefix and buildtype, others set libdir etc. too
2020-03-09 09:53:51 <Cogitri> I feel like at least for builsystems a wrapper which sets the options we always want is a good idea
2020-03-09 09:54:07 <mps> oh, wait till someone invent Object Oriented shell :)
2020-03-09 09:54:58 <mps> (or there is already, but I'm uninformed)
2020-03-09 09:55:08 <markand> Cogitri, yes I understand helpers for build systems, but not for very basic operations
2020-03-09 09:55:17 <markand> like RPM has %cmake macros or similar
2020-03-09 09:55:20 <markand> that make obviously sense
2020-03-09 09:55:35 <Cogitri> +1 on that, markand :)
2020-03-09 10:07:22 <minecrell> Cogitri: Thanks for fixing the texlive dependency, it was just purged again \o/
2020-03-09 10:08:35 <ncopa> mps: gentoo ebuilds uses something they call "eclasses", which basically is object oriented(ish) bash
2020-03-09 10:09:49 <TBB> mps: yeah, Microsoft provides an object oriented shell ;)
2020-03-09 10:10:43 <TBB> even buildroot offers helpers for various packaging methods in the style of $(eval $(autotools-package)) in their makefiles
2020-03-09 10:12:08 <ncopa> the feature i miss most in posix shell is hash lists key/value storage
2020-03-09 10:12:35 <ncopa> hash tables i mean
2020-03-09 10:13:14 <TBB> paraphrasing Steve Jobs, "there's a shell script for that"
2020-03-09 10:13:47 <TBB> yes, shell scripts could definitely use something like that, and maybe other data types as well
2020-03-09 10:14:15 <TBB> and improvements in scoping, and, and, and
2020-03-09 10:14:25 <markand> real data structure are much than welcome in shell, yes
2020-03-09 10:14:30 <markand> hash/arrays
2020-03-09 10:14:46 <TBB> ah well, at that point everyone and their half witted sister goes "there's Python for that stuff already"
2020-03-09 10:15:02 <AinNero> tfw virtualenvs
2020-03-09 10:15:13 <AinNero> tfw upstream pip's in debian broken
2020-03-09 10:15:29 <AinNero> i think id rather code in awk or perl
2020-03-09 10:15:47 <TBB> Perl's a pariah now
2020-03-09 10:15:52 <markand> TBB, ugh, a build script in other than shell is tedious
2020-03-09 10:15:57 <TBB> nobody wants to touch Perl with a six foot pole
2020-03-09 10:16:11 <markand> you'll have to write a lot of os.exec("cmake ") not mentioning passing arguments and such
2020-03-09 10:16:24 <markand> make/shell is the way to go for build script IMHO
2020-03-09 10:16:27 <TBB> and even the six foot Pole would rather use Python...
2020-03-09 10:16:40 <TBB> markand, fully agree on that one
2020-03-09 10:19:00 <Cogitri> ncopa: Eclasses are a pain to use though
2020-03-09 10:19:06 <_ikke_> sh is a nice python module for that :)
2020-03-09 10:19:19 <Cogitri> Exherbo's Exlibs are even worse
2020-03-09 10:19:20 <_ikke_> still not as nice as pure shell scripts ofcourse
2020-03-09 10:19:29 <_ikke_> https://amoffat.github.io/sh/
2020-03-09 10:19:35 <Cogitri> Sure, they provide some neat functionality and enable DRY but they're _so_ complex
2020-03-09 10:19:41 <ncopa> Cogitri: and they are a pain to debug and they are a pain to get started with. they are a pain. period.
2020-03-09 10:19:44 <ncopa> :)
2020-03-09 10:19:52 <Cogitri> Just an ameson command would be nice though
2020-03-09 10:19:57 <TBB> always been of the opinion everything worth doing is not worth reimplementing poorly
2020-03-09 10:20:54 <ncopa> Cogitri: what about aconfigure and acmake?
2020-03-09 10:21:41 <ncopa> re shells, i'd like something in between posix shell and Lua
2020-03-09 10:22:24 <ncopa> a shell with the size and speed of Lua, and with hash tables support
2020-03-09 10:22:25 <markand> please don't lua
2020-03-09 10:22:47 <_ikke_> markand: why?
2020-03-09 10:22:56 <markand> I don't understand the hype over this language
2020-03-09 10:22:59 <markand> _ikke_, so many reasons
2020-03-09 10:23:19 <_ikke_> markand: the 'hype' is that it's small and fast
2020-03-09 10:23:28 <ncopa> markand: Lua is small and fast. nothing beats it there
2020-03-09 10:24:11 <markand> but to start with: arrays start at 1; goto/break exist but not continue; compat is breaking every release; authors does not care about users and don't accept patches; strange ~= operator; custom pattern that are not at all compatible with real regexes
2020-03-09 10:24:40 <ncopa> markand: I agree on all those points
2020-03-09 10:24:44 <markand> and mixing table/arrays is definitely the worse thing to do
2020-03-09 10:25:00 <markand> LuaSockets was not compatible with 5.2 because of the compatibility non-promise issue
2020-03-09 10:25:06 <markand> for years
2020-03-09 10:25:47 <ncopa> the non-backwards compat thing is something most languages has, more or less
2020-03-09 10:25:58 <ncopa> but almost all langes has less of that than lua
2020-03-09 10:26:33 <ncopa> but you still get alot bang for the bucks with lua
2020-03-09 10:26:56 <ncopa> lua is 1/3 size of bash approx
2020-03-09 10:27:49 <Cogitri> ncopa: Same for those (best if we have it for all buildsytems), I just know meson the best which why I use it for examples
2020-03-09 10:28:45 <Cogitri> Let's write everything in D! :P
2020-03-09 10:28:45 <TBB> I have yet to see a scripting shell that'd be half as useful as bash for shell scripting... I tried to live 6 months with tclsh as my main shell, and even with readline support it was quite ... painful. And I like Tcl.
2020-03-09 10:28:59 <markand> however I put my +1 on custom acmake, ameson, aconfigure just for DRY concept
2020-03-09 10:29:11 <markand> maybe alpine- prefix could be better naming though
2020-03-09 10:29:28 <markand> especially since CMake requires bunch of parameters by default
2020-03-09 10:30:48 <_ikke_> I personally do like the concept of amove though
2020-03-09 10:30:59 <_ikke_> especially because we encourage the use of subpackages
2020-03-09 10:48:15 <ncopa> the main reason I am sceptic against an ameson, aconfigure and acmake is that it will be trickier to track when standard options are changed
2020-03-09 10:48:26 <Cogitri> Huh?
2020-03-09 10:48:35 <Cogitri> I think it'd be easier since we have a central place to change it
2020-03-09 10:48:45 <Cogitri> Instead of a commit which changes 500-ish APKBUILDs to change one thing
2020-03-09 10:49:27 <ncopa> was package X built with old or new standard meson option? depends on what version of abuild was installed when build was done
2020-03-09 10:49:51 <ncopa> currently you can track when the change was introduced by follow git log
2020-03-09 10:50:12 <ncopa> if we do it with ameson that becomes more tricky
2020-03-09 10:50:52 <Cogitri> When is that relevant?
2020-03-09 10:51:11 <ncopa> when you want know when a give option was introduced or removed
2020-03-09 10:51:12 <Cogitri> Most of the time when we change something then we do mass-changes
2020-03-09 10:51:23 <ncopa> right
2020-03-09 10:51:34 <ncopa> but when debug a given package that was affected but that mass change
2020-03-09 10:51:48 <Cogitri> Sorry?
2020-03-09 10:52:16 <ncopa> then you have a given package at hand and want to know in which versionthe configure change was done
2020-03-09 10:52:59 <ncopa> im not saying this is a big problem, im just saying that is what worries me most
2020-03-09 10:53:19 <ncopa> i dont think it will be a big problem because the standard options seldomly change
2020-03-09 10:53:39 <ncopa> i'll give you an example
2020-03-09 10:53:48 <ncopa> lets say we ahve a cmake built app
2020-03-09 10:53:55 <Cogitri> Ah okie, I don't think that'll ever become a problem to be honest
2020-03-09 10:54:26 <ncopa> and at some point we introduce buildmode to be RelWithDebug info
2020-03-09 10:54:33 <ncopa> or what its called
2020-03-09 10:55:05 <Cogitri> Then we'd rebuil everything, I suppose
2020-03-09 10:55:13 <Cogitri> And would have to rebuild everything once we change again
2020-03-09 10:55:20 <ncopa> from -DCMAKE_BUILD_TYPE=Release to -DCMAKE_BUILD_TYPE=RelWithDebug
2020-03-09 10:56:11 <ncopa> a year later we discover that the package built with RelWithDebug has a serious issue
2020-03-09 10:56:49 <ncopa> and we get a report from a user claiming having an issue with this package
2020-03-09 10:57:12 <ncopa> but we dont know if it this RelWithDebug issue or something else
2020-03-09 10:57:21 <ncopa> so we ask: what version of the package do you run?
2020-03-09 10:57:39 <ncopa> now, how do we know what option was used with the package?
2020-03-09 10:57:48 <ncopa> that gets harder to track
2020-03-09 10:57:55 <Cogitri> We know it because we bumped the pkgrel for the rebuild
2020-03-09 10:58:05 <ncopa> or not
2020-03-09 10:58:20 <ncopa> maybe we bumped the version instead
2020-03-09 10:58:31 <Cogitri> And with git log we'd see when the pkgrel was changed and could track it down - I don't think that'd make it too hard to find issues
2020-03-09 10:58:37 <ncopa> or rebuilt it for some other reason
2020-03-09 10:59:37 <ncopa> im not saying it will be impossible, im saying that it will harder than simply git log | grep $the_option_you_are_looking_for
2020-03-09 11:00:13 <ncopa> you will need to know what version of abuild introduced the change, and know what version of abuild was used when package was built
2020-03-09 11:01:15 <ncopa> im also not sure im happy to always rebuild all package whenever the standard/default flags are modified
2020-03-09 11:02:22 <markand> I think the a* scripts should only be there to provide minimal defaults
2020-03-09 11:02:37 <markand> like -DCMAKE_C_COMPILER="$CC" for acmake (hypothetical)
2020-03-09 11:02:48 <markand> and -DCMAKE_INSTALL_PREFIX=/usr...
2020-03-09 11:02:55 <markand> things that usually *never* change
2020-03-09 11:03:05 <ncopa> agree
2020-03-09 11:03:37 <ncopa> my point is that it may be very inconvenient to change those if ever needed
2020-03-09 11:04:10 <ncopa> that said
2020-03-09 11:04:31 <ncopa> it is posible the benefits outweights the downsides
2020-03-09 11:04:48 <ncopa> i just want make sure we are clear what the consequence is
2020-03-09 11:05:00 <ncopa> so we dont get surprises
2020-03-09 11:18:55 <Cogitri> I think they should provide what newapkbuild does
2020-03-09 11:22:34 <_ikke_> ncopa: maybe it would be possible to record what flags were used in some kind of generic way
2020-03-09 11:43:08 <_ikke_> ncopa: ok to apply https://lists.alpinelinux.org/~alpine/aports/patches/3299?
2020-03-09 11:43:20 <_ikke_> (apart from lack of pkgrel bum)
2020-03-09 12:56:15 <PureTryOut[m]> maxice8: why did you orphan appstream? https://git.alpinelinux.org/aports/commit/community/appstream?id=c685be7cbc4cb8296091fc15f59bfa723dbc325c
2020-03-09 12:57:37 <_ikke_> PureTryOut[m]: most likely because he does not use it
2020-03-09 12:59:01 <PureTryOut[m]> Hmm I guess. I wonder if he knows much about it. The format is used to tell appstores (e.g. KDE Discover and GNOME Software) metadata about packages, and it's probably the way to tell those applications properly about apk packages. I however wonder how to ship that metadata with our packages
2020-03-09 14:07:34 <Cogitri> We don't have a dgb package that pulls in all -dbg packages, do we?
2020-03-09 14:09:00 <_ikke_> nope
2020-03-09 14:16:43 <kaey> ncopa: you can somewhat have hashmaps in shell
2020-03-09 14:16:44 <kaey> stuff="foo bar"; foo_key1=value1; foo_key2=value2; bar_key1=value3
2020-03-09 14:17:02 <markand> kaey, haha
2020-03-09 14:17:12 <kaey> ?
2020-03-09 14:17:45 <kaey> freebsd uses this in rc.conf, works nicely
2020-03-09 14:18:19 <TBB> the entirety of buildroot seems to have been build on top of that
2020-03-09 14:18:26 <TBB> *built
2020-03-09 14:20:35 <kaey> go will record compiler options used in binary in the next release, maybe you can do something like this in apk?
2020-03-09 14:20:50 <kaey> like record build template version and env flags (CFLAGS etc) in apk?
2020-03-09 14:25:09 <Cogitri> Recording the build env in APKs would be nice indeed
2020-03-09 15:29:08 <mps> I was afk
2020-03-09 15:31:18 <mps> have to add to this discussion that I'm becoming more and more tired of all these helpers, smart build scripts/tools etc, and not only on alpine but on linux in general. where this world goes ?
2020-03-09 15:32:18 <wsinatra> mps: What's wrong with something that helps remove overhead between getting started and getting a result? Or do you think it's just too disparaged?
2020-03-09 15:32:38 <mps> processors are 'imperative' execution units, so all layers on top of it should follow this
2020-03-09 15:33:22 <mps> wsinatra: because they hides what actually is done
2020-03-09 15:34:46 <mps> is the cmake, meson etc specified in POSIX docs :)
2020-03-09 15:34:57 <wsinatra> That's a fair argument, people still have to learn. I think I have lazy sysadmin mentality, I like to automate anything
2020-03-09 15:35:08 <maxice8> @mps amove is in abuild you can read the function
2020-03-09 15:36:14 <mps> maxice8: I read it and not sure I understood it, because this I asked if some can explain exactly what it does
2020-03-09 15:36:25 <vkrishn> hi, read about 'forced push' issue happened in aports
2020-03-09 15:36:55 <vkrishn> would it make things difficult if there was a buffer git.zone
2020-03-09 15:37:01 <vkrishn> eg. devgit.a.o
2020-03-09 15:37:35 <vkrishn> all devs push to it, but only few devs do  'push origin master' from it
2020-03-09 15:37:42 <maxice8> @mps I guess it could have more explanation
2020-03-09 15:37:43 <mps> wsinatra: believe me or not, but I still sometime make 'make' shell scripts which build some programs as I do from CLI one-by-one
2020-03-09 15:38:39 <mps> this way I'm sure about full control of compiler or linker options
2020-03-09 15:39:12 <vkrishn> I use a similar git flow for all my codes and over period have started to like the process
2020-03-09 15:39:39 <mps> vkrishn: this is solved by disabled --force push, already, thanks to _ikke_ :)
2020-03-09 15:40:20 <vkrishn> yes, but newer devs should arguably not given a direct access to it
2020-03-09 15:40:30 <Cogitri> And we're going to migrate to Gitlab soon anyway
2020-03-09 15:41:00 <vkrishn> the mess-zone (devgit.a.o) would take the impact, where one can also do git --reset if they like
2020-03-09 15:41:01 <mps> maxice8: I didn't know that you introduced 'amove', but I wanted it to be removed, so not personally against you
2020-03-09 15:41:09 <Cogitri> Depends on what you call newer, maxice8 has been a dev for some months now
2020-03-09 15:41:18 <Cogitri> (Wow time sure passes fast)
2020-03-09 15:41:45 <_ikke_> vkrishn: with gitlab, the mess zone is each persons fork of aports
2020-03-09 15:41:52 <Cogitri> Yup
2020-03-09 15:42:16 <vkrishn> yes, each dev have their own flow, alpinelinuz has its own
2020-03-09 15:42:26 <vkrishn> its not cummulative approach
2020-03-09 15:42:34 <maxice8> @mps i guess we can document amove better, i don't plan on adding any of vbin vinstall or any other of v* functions
2020-03-09 15:42:36 <vkrishn> its 'unit'
2020-03-09 15:42:44 <maxice8> neither i do plan on adding build_styles
2020-03-09 15:42:56 <maxice8> if you want those there is Void Linux and their xbps-src, which btw is super well done.
2020-03-09 15:43:31 <maxice8> I do want to make better tooling to do the same sweeping changes that build_styles allow me to do by editing one file though.
2020-03-09 15:44:13 <vkrishn> if I were to push, I would have my own aports in localmachine(1) - workdir, public.mess.zone at gitlab(2)
2020-03-09 15:44:46 <vkrishn> public alpine mess.zone at devgit.a.o
2020-03-09 15:44:50 <maxice8> @PureTryOut: good to merge ? !5199
2020-03-09 15:45:27 <PureTryOut[m]> maxice8: yes
2020-03-09 15:45:32 <PureTryOut[m]> I was wondering what qt5-lottie would be good for lol
2020-03-09 15:47:20 <mps> maxice8: don't take it personally, but I think every change in alpine tools should be reviewed and acked by at least three developers (possibly known for their antagonistic POVs ;) )
2020-03-09 15:49:16 <maxice8> @mps you just guaranteed a deadlock
2020-03-09 15:49:47 <Cogitri> We're already having a hard time getting MRs into abuild
2020-03-09 15:49:52 <vkrishn> code move go like, editzone(local-machine, workdir)->public.dev(mess,staging,can be reverted) -> devgit.a.o (mess zone for all devs, revertable)
2020-03-09 15:50:04 <vkrishn> move goes*
2020-03-09 15:51:12 <vkrishn> all dev don't have to worry about commits going to git.a.o(gitlab, main repo)
2020-03-09 15:51:14 <mps> maxice8: I thought same (deadlock), but even it is better than chaos
2020-03-09 15:51:17 <Cogitri> vkrishn: Thanks, but Gitlab will take care of all that automatically
2020-03-09 15:51:58 <vkrishn> ok, thanks for listening
2020-03-09 15:52:34 <maxice8> @PureTryOut: merged, mind if i move qt5-lottie to community for telegram-desktop ?
2020-03-09 15:53:15 <PureTryOut[m]> Np
2020-03-09 15:53:35 <maxice8> also your qt5-qtlottie is in a directory called qt5-lottie
2020-03-09 15:53:39 <maxice8> i'll fix this one and check the others
2020-03-09 15:54:26 <PureTryOut[m]> Oh interesting, thanks
2020-03-09 15:55:06 <maxice8> Weirdly enough it passed the linting phase, aports-lint should have pointed that out
2020-03-09 15:56:13 <wsinatra> mps: there's nothing wrong with that, the more control you have over something, the more you know about it, and the easier it becomes to use/tweak etc. I can appreciate that
2020-03-09 15:56:23 <fcolista> would be cool to have abump bumping pkgrel other than pkgver
2020-03-09 15:56:33 <fcolista> pkgrel=$pkrel+1
2020-03-09 15:56:44 <maxice8> fcolista: apkgrel -a ?
2020-03-09 15:57:16 <fcolista> wow
2020-03-09 15:57:29 <maxice8> mindblow ?
2020-03-09 15:57:32 <fcolista> where are these utils documented?? THese borns like mushrooms :D
2020-03-09 15:57:47 <fcolista> I didn't know apkgrel
2020-03-09 15:58:40 <mps> wsinatra: when I untar source and see dir with Makefile.{linux,bsd,darwin ...} I'm more assured that the source better tailored for particular system than any autoconf and similar tools
2020-03-09 16:00:07 <wsinatra> I like the logic :)
2020-03-09 16:00:47 <maxice8> fcolista: apk info -L abuild will show lots of fancy utils
2020-03-09 16:01:16 <maxice8> mostly internal
2020-03-09 16:02:46 <wsinatra> +1 on that apk info command Leo, I could have used that ages ago. I should probably read documents before running off and doing things
2020-03-09 16:02:56 <fcolista> maxice8, thanks...I need to remember to check this every "abuild" upgrade :D
2020-03-09 16:05:22 <maxice8> I usually update manually, never got into abump
2020-03-09 16:56:43 <ncopa> kaey: i know you can do like that but it requires eval to use a variable as key, which is ugly
2020-03-09 16:57:50 <ncopa> _ikke_: ok with me. it looks like it makes sense
2020-03-09 16:58:43 <ncopa> im reviewing the chromium MR, but apparently there has not been any attempt to even do build testing before the MR was created
2020-03-09 16:59:07 <ncopa> so i need figure out which of patch modifications are done wrong
2020-03-09 17:00:28 <timlegge> I am seeing bad signatures on perl-html-formatter with MR #5174
2020-03-09 17:00:54 <maxice8> !5174
2020-03-09 17:01:35 <timlegge> that package had been update with a MR #5112 this past weekend
2020-03-09 17:02:50 <timlegge> I believe one of the other packages in that MR is getting a bad signature on the build server.  installed just now on my local machine with no issues
2020-03-09 17:12:26 <Cogitri> timlegge: Use ! for MRs and # for issues
2020-03-09 17:12:33 <Cogitri> So it's !5112 for the update
2020-03-09 17:13:24 <timlegge> thanks.
2020-03-09 17:19:26 <oneinsect> what did i miss?
2020-03-09 17:19:55 <oneinsect> i was washing my wife's and kids clothes
2020-03-09 17:20:03 <oneinsect> :-D
2020-03-09 17:27:19 <Cogitri> ikke: Can you take a look at !5174?
2020-03-09 17:27:33 <Cogitri> `ERROR: perl-html-formatter-2.16-r0: BAD signature` seems to be caused from the builders, I suppose
2020-03-09 17:27:40 <_ikke_> Later tonight
2020-03-09 17:36:02 <oneinsect> so i did not miss anything
2020-03-09 17:42:12 <Cogitri> I don't think so
2020-03-09 17:42:18 <Cogitri> ikke: Thanks
2020-03-09 17:43:26 <oneinsect> just pulling your legs..!
2020-03-09 18:37:42 <kaey> ncopa: some things simply cannot be done without eval, maps and quoted strings are examples of such cases
2020-03-09 18:50:36 <maxice8> @ncopa can you take a look at the abuild MRs ?
2020-03-09 18:52:31 <dalias> is ncopa back? :)
2020-03-09 18:56:34 <_ikke_> dalias: yes
2020-03-09 18:57:06 <dalias> ncopa, hope you had a nice vacation :)
2020-03-09 18:57:08 <dalias> and wb
2020-03-09 19:11:49 <ncopa> dalias: yes im back. I had a good vacation, thanks
2020-03-09 19:12:03 <ncopa> maxice8: ok, i may have a look tomorrow
2020-03-09 19:13:02 <maxice8> thanks, can't wait to get some nice fixes in and default bashcomp()
2020-03-09 19:35:16 <Danct12[m]> welcome back copa!
2020-03-09 20:13:03 <_ikke_> Cogitri: strange
2020-03-09 20:19:00 <_ikke_> ncopa: somehow, apk truncates some packages on download
2020-03-09 20:19:27 <_ikke_> https://tpaste.us/NmYP
2020-03-09 20:19:40 <_ikke_> The bottom one was downloaded with apk fetch, the top one was downloaded with curl
2020-03-09 20:19:51 <_ikke_> the middle one is the top one truncated to the same size as the bottom one
2020-03-09 20:20:12 <_ikke_> fabled: ^
2020-03-09 20:30:37 <fabled> wondering if it's more or less same issue as https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10675 and some sort of regression in latest release
2020-03-09 20:30:56 <_ikke_> fabled: do you want / need an strace?
2020-03-09 20:31:05 <fabled> is it happening always?
2020-03-09 20:31:17 <_ikke_> yes
2020-03-09 20:31:22 <_ikke_> at least, on that host
2020-03-09 20:31:54 <_ikke_> tried on another host (same arch, same url) and it works
2020-03-09 20:32:38 <fabled> mm.. i get BAD archive
2020-03-09 20:32:44 <_ikke_> yes
2020-03-09 20:32:49 <_ikke_> that's the issue
2020-03-09 20:33:08 <_ikke_> But on other hosts it's fine
2020-03-09 20:33:27 <fabled> the pastebin implies that you don't get error, but short file
2020-03-09 20:33:35 <fabled> i get no file, and an error
2020-03-09 20:33:48 <_ikke_> I used apk fetch to download it
2020-03-09 20:33:57 <fabled> $ apk fetch perl-html-formatter
2020-03-09 20:33:57 <fabled> Downloading perl-html-formatter-2.16-r0
2020-03-09 20:33:57 <fabled> ERROR: perl-html-formatter-2.16-r0: BAD archive
2020-03-09 20:34:00 <fabled> no file
2020-03-09 20:34:03 <_ikke_> strange
2020-03-09 20:34:42 <_ikke_> I *can* fetch it, without failing, but the resulting file is truncated
2020-03-09 20:34:50 <_ikke_> if I do apk add, then it gives bad archive
2020-03-09 20:35:12 <_ikke_> (10/10) Installing perl-html-formatter (2.16-r0)
2020-03-09 20:35:14 <_ikke_> ERROR: perl-html-formatter-2.16-r0: BAD signature
2020-03-09 20:35:19 <_ikke_> BAD signature, not BAD archive
2020-03-09 20:36:04 <_ikke_> note that it's missing just 17 bytes apparently
2020-03-09 20:36:17 <_ikke_> http://tpaste.us/xkLo
2020-03-09 20:36:49 <_ikke_> maybe yours is truncated even more
2020-03-09 20:37:15 <_ikke_> fabled: strace: https://tpaste.us/yZly
2020-03-09 20:56:49 <fabled> _ikke_, could be something else too, i think the size in index does not match the real file size
2020-03-09 20:58:16 <_ikke_> fabled: ah hmm
2020-03-09 20:58:39 <_ikke_> but why is that giving an issue only on certain environments?
2020-03-09 21:00:32 <fabled> index (edge/main/x86_64) has S:24748, but the file is only 24746 after wget
2020-03-09 23:02:57 <timlegge13> _ikke_ fabled Those packages were updated in a MR that was later overwritten by the forced push.  Not sure if its related !5112
2020-03-10 10:37:19 <PureTryOut[m]> Hmm I have a package that compiles fine locally but fails on the CI 🤔
2020-03-10 10:37:36 <PureTryOut[m]> Cleaning out all custom packages locally and trying again from scratch it still works fine locally. Not sure what's happening
2020-03-10 10:37:44 <PureTryOut[m]> RE https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5241
2020-03-10 10:38:41 <_ikke_> And no idea where nymphrpc should be coming from?
2020-03-10 10:38:58 <timlegge> ncopa: I added a Metacpan::Client based script apkbuild-mcpan.in to MR !35 abuild Let me know if you would rather I pull that and merge it into apkbuild-cpan.in.  Not quite ready for prime time but close
2020-03-10 10:39:00 <_ikke_> Note that the CI docker image is available
2020-03-10 10:39:14 <_ikke_> PureTryOut[m]: use alpinelinux/alpine-gitlab-ci
2020-03-10 10:40:40 <PureTryOut[m]> Currently I'm using rootbld, which is probably the difference here?
2020-03-10 10:40:53 <PureTryOut[m]> I don't get it though, the right dependencies are in place
2020-03-10 10:41:05 <PureTryOut[m]> Why is anything different between rootbld and docker-abuild in the first place?
2020-03-10 10:41:23 <_ikke_> Good question, not sure
2020-03-10 11:39:02 <PureTryOut[m]> It's still failing, even though all packages are bumped now
2020-03-10 11:39:58 <PureTryOut[m]> And I can't run docker-abuild anymore to check if there are any issues there because it reports Permission denied when accessing `~/.abuild/abuild.conf`
2020-03-10 11:40:10 <_ikke_> PureTryOut[m]: testing it in my build container
2020-03-10 11:41:02 <_ikke_> PureTryOut[m]: can it have to do with dependencies?
2020-03-10 11:41:09 <_ikke_> between built packages I mean
2020-03-10 11:41:22 <PureTryOut[m]> I wouldn't know how, all the deps are specified correctly
2020-03-10 11:42:12 <_ikke_> nymph
2020-03-10 11:42:14 <_ikke_> rpc (0_git20200309-r1)
2020-03-10 11:42:52 <_ikke_> It does seem to install the just built package
2020-03-10 11:45:34 <_ikke_> PureTryOut[m]: fails in my build container as well
2020-03-10 11:45:43 <_ikke_> (lxc container)
2020-03-10 11:46:10 <PureTryOut[m]> How though 🤔
2020-03-10 11:49:17 <_ikke_> pkgconf or something like that? (I have no experience with that)
2020-03-10 11:50:18 <PureTryOut[m]> I'll investigate more
2020-03-10 11:50:30 <_ikke_> It's strange
2020-03-10 11:50:44 <_ikke_> It appears that nymphrpc-dev is incomplete
2020-03-10 11:50:45 <PureTryOut[m]> I don't like the manual makefile of the package anyway...
2020-03-10 11:51:02 <_ikke_> The -dev package only contains header files
2020-03-10 11:51:37 <_ikke_> the *.so file is missing I guess
2020-03-10 11:52:38 <_ikke_> nymphrpc contains libnymphrpc.so.0.1
2020-03-10 11:52:58 <_ikke_> nymphrpc-dev should contain libnymphrpc.so
2020-03-10 11:53:00 <_ikke_> but does not
2020-03-10 11:53:21 <PureTryOut[m]> Yeah that file is never built, which is due to the manual makefile
2020-03-10 11:53:25 <PureTryOut[m]> I'll report upstream
2020-03-10 11:53:42 <_ikke_> alright
2020-03-10 11:54:22 <_ikke_> I think you would need to add a symlink to that file
2020-03-10 12:00:26 <PureTryOut[m]> Yeah seems I have to do it manually
2020-03-10 13:05:38 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/lrBOdFPTabkfXmuebSoVyImj >

2020-03-10 13:05:39 <PureTryOut[m]> What is happening? ^
2020-03-10 13:05:53 <PureTryOut[m]> libnymphcast.so is a symlink in this case, but I just can't install it. Neither cp or install work
2020-03-10 13:08:14 <PureTryOut[m]> Also rootbld _always_ removes the builddir, if the build failed or `-K` was specified...
2020-03-10 13:21:19 <Cogitri> Do you have the APKBUILD for that around?
2020-03-10 13:21:20 <Cogitri> readlink on the symlink works?
2020-03-10 13:23:45 <PureTryOut[m]> Still working on it. But I think I got it, seems the symlink was invalid
2020-03-10 13:23:49 <PureTryOut[m]> Stupid makefiles...
2020-03-10 13:25:18 <Cogitri> Ah yes, Makefiles tend to be stupid and rather specific to the system the dev works on
2020-03-10 13:26:17 <PureTryOut[m]> Well in this case it only makes a versioned .so file, so I'm trying to make it build a proper non-versioned link to it as well. I'm close, but it takes way too long lol. Also, I'm making a general mess of this packaging, now I'm getting package conflicts so I'm messing around with replaces and provides
2020-03-10 13:27:21 <PureTryOut[m]> Yeah got it now
2020-03-10 13:29:17 <Cogitri> Keep in mind that you might need to append `-Wl,soname,libname.so.x.x` if the Makefile doesn't do that for you
2020-03-10 13:40:44 <PureTryOut[m]> Yay CI passes now. Submitted fixes to the Makebuilds upstream
2020-03-10 13:51:33 <Cogitri> 👍
2020-03-10 14:04:31 <PureTryOut[m]> ncopa: any opinions on !4003?
2020-03-10 15:00:23 <PureTryOut[m]> Hmm actually no I still can't get it right. Symbolic link is created and installed, but the default dev() function doesn't pick it up. If I overwrite that function and install it manually, it's just a hard link or new file, and the subpackage will not depend on the original package
2020-03-10 15:06:35 <ncopa> PureTryOut[m]: i havent looked at it (yet)
2020-03-10 15:06:43 <ncopa> still have some other stuff to fix first
2020-03-10 15:06:54 <clandmeter> ncopa: when do you want to switch git?
2020-03-10 15:07:24 <PureTryOut[m]> ncopa: sure 👍️
2020-03-10 15:08:45 <PureTryOut[m]> How is a symlink created by the build process meant to be installed normally? It seems the link breaks if I use cp, mv or install on it...
2020-03-10 15:10:00 <wsinatra> can't you just call symlink during the install process?
2020-03-10 15:11:08 <PureTryOut[m]> I can but I rather don't, as there is no way to know the version appended to the .so file to link too afaik
2020-03-10 15:13:35 <wsinatra> Hmm yeah that would make it a little bit more difficult. Does the makefile, or whatever build process you're calling, have a subsection for just the symlink that could be called again later?
2020-03-10 15:13:48 <wsinatra> that might not create reproducible builds though, just spitballing
2020-03-10 15:15:17 <PureTryOut[m]> Well I created the bit that makes the symlink 😉 But no it's part of another subsection
2020-03-10 15:16:11 <PureTryOut[m]> Btw even linking manually in the APKBUILD doesn't work. It just links to `$pkgdir/usr/lib/libnymphcast.so.0.1` rather than `/usr/lib/libnymphcast.so.0.1`
2020-03-10 15:16:33 <PureTryOut[m]> I never understood linking...
2020-03-10 15:18:20 <Cogitri> I suppose you do absolute linking then, you need to do relative linking
2020-03-10 15:18:25 <Cogitri> See how testing/bloaty does it
2020-03-10 15:18:56 <PureTryOut[m]> That does not seem to be a package
2020-03-10 15:19:06 <PureTryOut[m]> Ah it's in community
2020-03-10 15:19:21 <maxice8> community/bloaty/APKBUILD
2020-03-10 15:19:38 <Cogitri> Oh, I moved it already
2020-03-10 15:21:01 <PureTryOut[m]> "Cross-device link" wut?
2020-03-10 15:23:03 <PureTryOut[m]> So such a link is what the Makefile already does. But how would I properly move that to `$pkgdir/usr/lib` so default_dev() picks it up?
2020-03-10 15:24:07 <PureTryOut[m]> Or well default_dev() does pick it up, but the link is then broken
2020-03-10 15:25:24 <wsinatra> Which package in that bundle has the problem? I might be able to make some suggestions if I know what one to look at?
2020-03-10 15:29:16 <PureTryOut[m]> wsinatra: give me a sec I'll update the MR with latest changes, but it's both NymphRPC and NymphCast
2020-03-10 15:32:25 <PureTryOut[m]> wsinatra: ok pushed, you can take a look
2020-03-10 15:41:38 <wsinatra> hmm it doesn't look much different from the AUR pkgbuilds, it should work, but the CI just hangs looking for nymph.h (probably because it's not available from the main repos yet?)
2020-03-10 15:42:04 <wsinatra> I don't see any reason why a manual install call wouldn't work, but I would probably need to pull it down and see to be more certain
2020-03-10 15:44:31 <[[sroracle]]> PureTryOut[m]: if you're manually creating the symlink the target needs to be libnymphcast.so.0.1, not $pkgdir/usr/lib/libnymphcast.so.0.1 or anything like that
2020-03-10 15:45:01 <_ikke_> right, just a relative symlink in the same dir
2020-03-10 15:46:23 <PureTryOut[m]> Does it have to be the same dir? Can it not be a subdir?
2020-03-10 15:46:37 <PureTryOut[m]> as in link to `lib/libnymphcast.so.0.1` rather than `libnymphcast.so.0.1`?
2020-03-10 15:46:48 <_ikke_> no
2020-03-10 15:47:01 <[[sroracle]]> well you can use .. as appropriate if they're in different dirs, but i'm assuming libnymphcast.so.0.1 and libnymphcast.so are in the same dir
2020-03-10 15:47:10 <[[sroracle]]> which they should be in most cases
2020-03-10 15:47:13 <PureTryOut[m]> They're not 😉
2020-03-10 15:47:16 <[[sroracle]]> ... why
2020-03-10 15:47:23 <PureTryOut[m]> That would make sense but Makefiles are hard and confusing
2020-03-10 15:47:55 <_ikke_> libzstd.so.1 -> libzstd.so.1.4.4
2020-03-10 15:47:56 <[[sroracle]]> this sounds completely backwards
2020-03-10 15:48:30 <[[sroracle]]> libnymphcast.so should be a symlink to libnymphcast.so.0.1, and they should be in the same directory
2020-03-10 15:49:19 <PureTryOut[m]> The problem for that is here https://github.com/MayaPosch/NymphRPC/blob/master/Makefile#L66
2020-03-10 15:49:52 <PureTryOut[m]> The linking is done from a different directory of the resulting file, and it seems `@ln -s $@ lib/$(OUTPUT).so` would give the wrong link
2020-03-10 15:49:56 <[[sroracle]]> just remove the symlink it's making and make it yourself in package()
2020-03-10 15:50:16 <PureTryOut[m]> I rather fix it upstream though
2020-03-10 15:51:27 <[[sroracle]]> using -r might make it DTRT, otherwise you're gonna have to adjust $@ somehow
2020-03-10 15:52:16 <PureTryOut[m]> DTRT? Also, `-r` is not available in Busybox ln
2020-03-10 15:52:23 <[[sroracle]]> do the right thing
2020-03-10 15:53:17 <PureTryOut[m]> Ah. But yeah that will not work on Busybox ln and thus in an APKBUILD
2020-03-10 15:53:21 <[[sroracle]]> then you need to chdir to lib and make the symlink there without lib/
2020-03-10 15:53:39 <[[sroracle]]> chdir before the ln i mean
2020-03-10 15:54:39 <[[sroracle]]> just a chdir should be sufficient i think then you wouldn't even need to touch the ln
2020-03-10 15:55:59 <[[sroracle]]> ah well $@ would still be lib/
2020-03-10 15:56:10 <[[sroracle]]> but you get the idea
2020-03-10 15:56:14 <PureTryOut[m]> Yes :'(
2020-03-10 15:56:23 <PureTryOut[m]> Why is stuff so hard damn it lol
2020-03-10 15:56:45 <[[sroracle]]> chdir then @ln -s $(OUTPUT).so.$(VERSION) $(OUTPUT).so i guess
2020-03-10 15:56:55 <maxice8> Should have used meson
2020-03-10 15:57:22 <PureTryOut[m]> maxice8: anything that isn't straight up Makefiles really
2020-03-10 15:57:26 <PureTryOut[m]> [[sroracle]]: thanks will try
2020-03-10 16:12:13 <PureTryOut[m]> It still seems to go wrong...
2020-03-10 16:12:15 <PureTryOut[m]> `lrwxrwxrwx 1 root root 23 Mar 10 16:25 /usr/lib/libnymphcast.so -> lib/libnymphcast.so.0.1`
2020-03-10 16:13:51 <_ikke_> Cogitri: cogl is failing on the builders due to linking issues
2020-03-10 16:22:04 <PureTryOut[m]> Hmm, seems I got it now. Creating the symlink properly in the Makefile like you said [[sroracle]], then _moving_ the symlink in the APKBUILD rather than using install
2020-03-10 16:31:42 <ncopa> clandmeter: can we do it tomorrow or Thursday? or Monday?
2020-03-10 16:31:51 <ncopa> clandmeter: i mean switch git
2020-03-10 16:32:29 <ncopa> I guess Monday or Tuesday is a good day. then we can send out email early and warn about it
2020-03-10 16:32:48 <_ikke_> ncopa: I think we have one final decission to make about how to do groups in gitlab (discussed that with clandmeter in #-infra)
2020-03-10 16:33:06 <ncopa> ok. good!
2020-03-10 16:35:08 <Cogitri> _ikke_: Yes, saw it, -j1 fixed it locally, odd that it doesn't work on the builders. I'm currently not at a PC though
2020-03-10 16:35:48 <Cogitri> Could someone with main access remove the `--enable-cogl-gst` line and the gstreamer-dev and gst-plugins-base-dev stuff from cogl for now?
2020-03-10 16:35:53 <_ikke_> weird that you need to do -j1 to fix linking issues. Lack of dependencies in the build system I guess?
2020-03-10 16:35:58 <Cogitri> It's not like we need cogl gstreamer right now
2020-03-10 16:36:14 <_ikke_> sure
2020-03-10 16:36:27 <Cogitri> Probably, yes, but it's Autotools so I'd rather not touch it :P
2020-03-10 16:36:34 <Cogitri> Thank you :)
2020-03-10 16:36:38 <_ikke_> hehe
2020-03-10 16:48:01 <mps> ncopa: if you have time please look at !5075 it is secfix
2020-03-10 16:48:48 <mps> and I think it should be backported to 3.9 and maybe 3.8
2020-03-10 16:48:55 <_ikke_> Cogitri: http://tpaste.us/5Ezy
2020-03-10 16:49:00 <_ikke_> looks good?
2020-03-10 16:49:08 <_ikke_> (it builds locally)
2020-03-10 17:00:40 <Cogitri> Yup, thank you, ikke
2020-03-10 17:01:08 <_ikke_> should I do a pkgrel bump?
2020-03-10 17:01:15 <_ikke_> or is it failing on all arches anyway?
2020-03-10 17:14:03 <Cogitri> I think it's failing on all arches
2020-03-10 17:17:54 <ncopa> mps: is v3.9 also affected?
2020-03-10 17:18:06 <ncopa> is v3.11 and edge fixed already?
2020-03-10 17:18:07 <Ariadne> all versions are
2020-03-10 17:18:19 <Ariadne> if we are talking about the ppp sec fix
2020-03-10 17:18:24 <ncopa> yeah
2020-03-10 17:18:48 <ncopa> so its not fixed in 3.11 yet?
2020-03-10 17:19:35 <ncopa> i'll folow up tomorrow
2020-03-10 17:19:47 <Ariadne> i don't think the sec fix is backported to 3.11, but i am not sure
2020-03-10 17:19:51 <Ariadne> i can check
2020-03-10 17:36:18 <mps> ncopa: there is MR for 3.11 also
2020-03-10 17:36:34 <mps> !5056
2020-03-10 17:37:41 <mps> just wanted to ask you if it is ok, I can and plan to make MRs for 3.9 and 3.8
2020-03-10 17:41:14 <adsr> Requesting some eyeballs on https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4156#note_72764 cc Cogitri
2020-03-10 18:17:06 <maxice8> zeromq-gsl kept failing because its makefile didn't understand PREFIX=
2020-03-10 19:20:06 <maxice8> i went until page 20 of the mailing list patches and merged the few i could find and rejected/superseded the rest
2020-03-10 19:21:23 <maxice8> there are some pending
2020-03-10 19:21:30 <mps> 3.8 have md5sums as cheksum in APKBUILD. If we backport fixes or upgrades do we have to keep md5sums or we can use sha256sums
2020-03-10 19:23:29 <maxice8> mps: https://git.alpinelinux.org/aports/commit/?h=3.8-stable&id=ec2cb0ea688e8d4c4ccf31b7434ab4b5cb111e66
2020-03-10 19:23:32 <maxice8> sha512sum works fine
2020-03-10 19:26:14 <mps> maxice8: nice, thanks
2020-03-10 19:35:56 <mps> maxice8: last one !5264 :)
2020-03-10 19:36:08 <mps> for 3.8-stable
2020-03-10 19:36:23 <maxice8> I saw, am preparing meal
2020-03-10 19:36:41 <_ikke_> I can apply it
2020-03-10 19:36:43 <mps> ah, ok. buon appetito :)
2020-03-10 19:36:53 <maxice8> no you can't
2020-03-10 19:37:02 <_ikke_> lol
2020-03-10 19:37:11 <_ikke_> I still can :)
2020-03-10 19:37:16 <maxice8> you can but git am will show empty commit :D
2020-03-10 19:37:26 <_ikke_> not if I don't update master :P
2020-03-10 19:37:30 <_ikke_> or 3.8-stable in this case
2020-03-10 19:37:36 <maxice8> or if you force push :D
2020-03-10 19:37:54 <_ikke_> ;)
2020-03-10 19:55:03 <mps> hmm, just read on #musl that 600+ people have commit permission on llvm. very interesting ...
2020-03-10 19:55:37 <maxice8> that is quite big
2020-03-10 19:56:20 <AinNero> [generic inflaming comment]
2020-03-10 19:56:39 <mps> I have no comment on this
2020-03-10 19:57:01 <Cogitri> Well, it's a pretty massive project
2020-03-10 19:57:17 <AinNero> so is the kernel
2020-03-10 19:57:36 <AinNero> how comes we need more and more people for the software stack
2020-03-10 19:57:52 <Cogitri> And since it's not really much of a volunteer project but a coperate project I think there are loads of people who have commit permissions because they work for LLVM
2020-03-10 19:58:06 <Cogitri> Or rather work at a company which works on LLVM
2020-03-10 19:58:37 <Cogitri> Now I'm curious if that figure it just LLVM or LLVM and all its subprojects
2020-03-10 19:58:45 <mps> as I read it, it is easy to get commit rights
2020-03-10 20:54:25 <PureTryOut[m]> Wait what, how did I author this? I don't remember this at all https://git.alpinelinux.org/aports/commit/?id=6a77b276
2020-03-10 20:55:04 <maxice8> https://lists.alpinelinux.org/~alpine/aports/patches/3031
2020-03-10 21:28:40 <PureTryOut[m]> 5 months ago wut
2020-03-10 21:30:54 <maxice8> I decided to clean up the mailing list so I went through 20 pages
2020-03-10 21:31:14 <maxice8> You have a massive amount of patches
2020-03-10 21:31:34 <PureTryOut[m]> Lol yes
2020-03-10 21:34:29 <PureTryOut[m]> I still like the mailing list (well, SourceHut specifically) tbh, it's just the lack of CI 😭
2020-03-10 21:37:02 <Cogitri> The lack of CI is bad already but having two hubs for patches (increasing load on devs even more) is the nail in the coffin for me
2020-03-10 21:39:18 <PureTryOut[m]> Yeah that I understand
2020-03-10 21:48:20 <maxice8> Wouldn't mind keeping sourcehut if people were made aware it has longer waiting times
2020-03-10 21:50:40 <PureTryOut[m]> !5241 is now ready for merging
2020-03-10 22:15:21 <mps> cat /etc/os-release => BUG_REPORT_URL="https://bugs.alpinelinux.org/", need to be changed
2020-03-10 22:15:54 <mps> hmm, it redirect. ok then
2020-03-11 00:41:55 <timlegge> Any idea why !5275 is failing?  perl-devel-overloadinfo does exist in the edge packages but it says it does not
2020-03-11 02:40:46 <maxice8> can't seem to be able to access SourceHut API in lists.alpinelinux.org to update patchsets
2020-03-11 06:46:40 <ncopa> morning
2020-03-11 06:47:03 <ncopa> mps: are there anything describing the security issue for ppp?
2020-03-11 06:47:37 <ncopa> do they have a CVE?
2020-03-11 06:48:01 <ncopa> how are this different from CVE-2020-8597?
2020-03-11 07:07:19 <clandmeter> good morning
2020-03-11 07:15:23 <mps> good morning
2020-03-11 07:16:04 <mps> ncopa: I added CVE number in every APKBUILD of ppp
2020-03-11 07:17:19 <mps> maybe I should add it also in commit msg?
2020-03-11 07:17:56 <Cogitri> Morning
2020-03-11 07:18:16 <Cogitri> I don't think that's necessary
2020-03-11 07:19:37 <mps> my after thought says to me that I should add CVEs in commit msgs, as I usually do
2020-03-11 07:28:40 <Cogitri> Well it certainly doesn't hurt
2020-03-11 08:47:47 <ncopa> i wonder if we should create a report of it
2020-03-11 08:48:03 <ncopa> ie, create an sec issue and fill in the commits where it was fixed
2020-03-11 08:48:37 <ncopa> then we have documentation that we have it fixed
2020-03-11 09:40:50 <mps> ncopa: yes, I agree, sec issue will be good to have
2020-03-11 10:57:59 <Cogitri> We don't really have a way to set runtime only deps, right?
2020-03-11 10:58:29 <Cogitri> gcr needs gpg and gpg needs gcr via pinentry but if I put gpg into gcr's depends it'll cause a circular dep
2020-03-11 10:58:29 <_ikke_> no
2020-03-11 10:58:36 <Cogitri> That's unfortunate
2020-03-11 11:08:33 <Cogitri> So I guess my options are either to hope people who install gcr install gpg or to static link gcr into pinentry?
2020-03-11 11:09:18 <Cogitri> Actually, option 2 wouldn't work since I'd still need gcr-dev then
2020-03-11 11:48:31 <timlegge> Any idea why !5275 is failing? perl-devel-overloadinfo does exist in the edge packages but it says it does not
2020-03-11 12:46:39 <maxice8> yes
2020-03-11 12:46:46 <maxice8> perl-devel-overloadinfo is in community/
2020-03-11 12:46:52 <maxice8> packages in main/ can't depend on stuff in community/
2020-03-11 12:53:42 <timlegge> ah.  I thought main and community was good not testing.  thanks
2020-03-11 12:53:56 <timlegge> will move
2020-03-11 12:54:15 <maxice8> No, it is like a ladder
2020-03-11 12:55:20 <_ikke_> packages in main can only depend on main. for community can only depend on main and community and for testing can depend on all
2020-03-11 15:06:52 <crich> I just tried to use usb-passtrough on xen/qemu with alpine 3.11. It doesn't work because qemu was not compiled with libusb support (and doesn't link to it which ldd shows).  How do I get the source of the existing qemu package, so that I can add libusb support by myself ?
2020-03-11 15:09:41 <mps> crich: ldd /usr/bin/qemu-system-x86_64 | grep usb
2020-03-11 15:09:58 <mps> libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x7f1a8eaa0000)
2020-03-11 15:21:48 <crich> mps:  ldd /usr/lib/xen/bin/qemu-system-i386 | grep usb
2020-03-11 15:22:05 <crich> shows nothing. This is the one used by xen
2020-03-11 15:24:06 <mps> ah, this is for xen, sorry
2020-03-11 15:26:12 <mps> this is probably in xen package, not qemu
2020-03-11 15:27:09 <crich> yes, you're right. So I would need to recompile the xen tools containing qemu
2020-03-11 15:28:38 <mps> probably, but I don't have much experience with xen
2020-03-11 15:34:38 <crich> mps: what's the general procedure to obtain the alpine source package ?
2020-03-11 15:35:24 <mps> crich: look at wiki.a.o and follow development link
2020-03-11 15:35:45 <mps> everything is explained there
2020-03-11 15:36:58 <mps> algitbot: what is wiki.a.o :)
2020-03-11 15:37:07 <_ikke_> lol
2020-03-11 15:37:12 <mps> wiki.alpinelinux.org
2020-03-11 15:44:23 <mps> crich: sorry for OT question, but are you really from Crichi tribe/people
2020-03-11 15:52:10 <crich> mps ?
2020-03-11 15:52:15 <crich> nope
2020-03-11 15:52:34 <mps> ah, ok
2020-03-11 16:05:15 <clandmeter> haha
2020-03-11 16:05:19 <clandmeter> we all love algitbot
2020-03-11 16:06:06 <ncopa> i think it is possible to compile xen with system qemu instead of using the bundled one
2020-03-11 16:06:55 <ncopa> but i suspect it will introduce a circular dep, as you would need build qemu with xen-dev
2020-03-11 16:10:41 <crich> ncopa: not necessarly. If xen-dev doesn't depend on xen itself it should work fine as  xen -- depends -->  qemu, xen-dev and qemu --depends--> xen-dev
2020-03-11 16:29:20 <crich> ncopa: you brought to a better idea, I'll rather recompile qemu-system with xen support and then use the qemu-system instead of the xen contained one. I guess that's  a bit more straight forward.
2020-03-11 16:35:33 <crich> but honestly I would hope that the xen package would be compiled with libusb so that the native xen-qemu would allow usb-passthrough properly
2020-03-11 17:41:37 <Cogitri> Ariadne: ping
2020-03-11 17:42:35 <Ariadne> Cogitri: hi
2020-03-11 17:48:24 <Cogitri> Just read your email, you're also interested in making some API client for the Gitlab API?
2020-03-11 18:03:29 <Ariadne> if somebody else does not get to it first
2020-03-11 18:03:45 <Cogitri> I'm currently working with maxice8 on one
2020-03-11 18:04:13 <Cogitri> maxice8 already made  a shellscript for it he and I have used for some time already, we'll port it over to Python
2020-03-11 18:05:35 <Ariadne> i think the majority of our devscripts are shell and lua
2020-03-11 18:08:52 <Cogitri> Yes, but the current thing in shell is rather annoying to maintain
2020-03-11 18:09:05 <Cogitri> I think we could do it in Lua too, but does it really matter?
2020-03-11 18:09:16 <Cogitri> Python is more useful to me personally since I need to learn that for uni and work anyway
2020-03-11 18:11:32 <maxice8> Don't see why not have multiple implementations
2020-03-11 18:11:40 <maxice8> i'm doing it in python3 and will use py3-pygit2
2020-03-11 18:12:03 <Cogitri> Seems like collaborating is a better idea here so we don't duplicate effort
2020-03-11 18:27:03 <mps> I thought to start it in perl but don't have time
2020-03-11 19:10:55 <PureTryOut[m]> Hmm most of my CI jobs failed because of stuck builders on multiple architectures...
2020-03-11 19:16:00 <_ikke_> That could be because there was a long job running before
2020-03-11 19:16:18 <PureTryOut[m]> Ah interesting ok, I'll just restart them
2020-03-11 19:16:35 <Cogitri> Yes, gnome-keyring was stuck for a long time, sorry about that
2020-03-11 21:42:01 <mps> this MR !5316 is sample that we have should be more careful on upgrade and push packages
2020-03-11 21:44:49 <_ikke_> mps: I would add that as a comment to the APKBUILD
2020-03-11 21:45:01 <_ikke_> There are more APAKBUILDs that do that
2020-03-11 21:45:30 <Cogitri> We'd have to add that for about all of GNOME then
2020-03-11 21:46:00 <_ikke_> Would not be a bad idea
2020-03-11 21:46:41 <mps> what to add 'as a comment'
2020-03-11 21:46:55 <mps> sorry, didn't understood
2020-03-11 21:48:57 <_ikke_> Something like this: https://git.alpinelinux.org/aports/tree/main/nginx/APKBUILD#n21
2020-03-11 21:49:52 <mps> aha, then a lot of APKBUILDs need this
2020-03-11 21:50:59 <_ikke_> It helps others to be aware of these things
2020-03-11 21:51:15 <mps> but one general rule could be added to CODINGSTYLE.md
2020-03-11 21:51:33 <_ikke_> I don't think this is a codestyle thing
2020-03-11 21:51:40 <mps> something like 'check carefully when upgrading'
2020-03-11 21:52:10 <_ikke_> Yes, but at least on the github page, there was no mention of it being a development version
2020-03-11 21:52:33 <mps> well, wherever but to be read by all contributors, developers and commiters
2020-03-11 21:53:58 <mps> few days ago I looked at this one (sysstat) to upgrade and noticed two different releases at the nearly same time, this triggered my alarm to check carefully
2020-03-11 21:54:40 <mps> and because that I noticed it in MR list, just coincidence
2020-03-11 21:54:54 <_ikke_> nod
2020-03-11 21:55:16 <mps> not that I'm super smart :)
2020-03-11 21:55:17 <_ikke_> but if that were not the case, you might have missed that as well
2020-03-11 21:55:28 <mps> right
2020-03-11 21:55:53 <_ikke_> So let's just document it when it comes up
2020-03-11 21:56:07 <_ikke_> Then it won't be a surprise for anyone
2020-03-11 21:56:51 <mps> well, yes. but anyway wouldn't be bad to have somewhere red notice about this, call it 'best practice'
2020-03-11 21:57:20 <mps> maybe not red, magenta is fine :)
2020-03-11 22:07:36 <_ikke_> mps: Any idea why this happens on aarch64 / armv7? https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/64145
2020-03-11 22:08:19 <_ikke_> https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/64145#L1017
2020-03-11 22:27:07 <mps> hm, this should pass
2020-03-11 22:31:13 <mps> ah, glwidget.cpp:939:17: error: 'QOpenGLFunctions_1_1' was not declared in this scope; did you mean 'QOpenGLFunctions'?
2020-03-11 22:31:55 <mps> why it have this suffix '_1_1'
2020-03-11 22:41:07 <mps> hmm, something else is issue probably
2020-03-11 22:45:19 <Cogitri> Not sure if it's related, but I think we flicked on GLES for armv7 (and aarch64?) on QtBase and disabled OpenGL a bit ago
2020-03-11 22:48:49 <mps> doesn't look related. here is another error: glwidget.cpp:943:20: error: 'class QOpenGLFunctions' has no member named 'glGetTexImage'
2020-03-11 22:51:40 <Cogitri> Ah, maybe it broke with the new Qt version then
2020-03-11 22:53:26 <maxice8> !5328 was made from CLI with a python3 script i hacked together, is of interest for Alpine to provide for people that are used to email
2020-03-11 22:53:39 <mps> this was my thoughts, but didn't fouond on their site anything about needed version
2020-03-11 22:54:38 <mps> and I'm tired now, going to bed. good night all
2020-03-12 08:35:42 <_ikke_> kpcyrd: A new curl patch release was done to fix those issues, I've pushed it to aports. Can you verify if it is working now?
2020-03-12 08:56:16 <_ikke_> Cogitri: could you also verify if flatpak is still working properly?
2020-03-12 08:57:20 <Cogitri> Sure thing
2020-03-12 08:57:28 <Cogitri> But you could just do `cargo install $somepackage` to verify the fix
2020-03-12 08:57:53 <Cogitri> E.g. `cargo install cargo-tarpaulin`
2020-03-12 08:59:31 <_ikke_> I don't have rust / cargo installed :P
2020-03-12 09:01:47 <Cogitri> Fair
2020-03-12 10:14:26 <ncopa> i just tagged new edge snapshot
2020-03-12 10:16:40 <_ikke_> nice
2020-03-12 10:45:19 <PureTryOut[m]> So a package just got downgraded, but the commit message reads "upgrade" 🤔 https://git.alpinelinux.org/aports/log/community/leptonica
2020-03-12 10:47:22 <mps> 'marketing speak' :)
2020-03-12 10:48:16 <mps> (our prices are not increased, they are changed/adapted)
2020-03-12 10:49:10 <Cogitri> fcolista: ^
2020-03-12 10:52:50 <mps> PureTryOut[m]: regarding libpulse in firefox, I don't care anymore. there are a lot of pkgs with libpulse deps so one more wouldn't change anything
2020-03-12 10:53:22 <Cogitri> mps: The question was if ALSA output still works with Pulse enabled
2020-03-12 10:53:44 <mps> ah, so we need to test
2020-03-12 10:54:13 <mps> ok, will try to build it locally with pulse and check
2020-03-12 10:54:55 <mps> I don't know why it wouldn't work, but who knows
2020-03-12 10:56:00 <mps> btw, what about movind firefox back to testing?
2020-03-12 10:56:06 <PureTryOut[m]> Yeah should work fine, I didn't remove the alsa option
2020-03-12 10:57:07 <mps> I read about pipewire, is it better than pulse
2020-03-12 10:57:58 <mps> I read that pipewire doesn't have this security problems which pulse has
2020-03-12 10:58:03 <PureTryOut[m]> Supposed to be a replacement for both Pulse and Jack, but it's not there yet
2020-03-12 10:58:16 <PureTryOut[m]> Eventually it should be better afaik
2020-03-12 10:58:22 <PureTryOut[m]> Then again, better would be subjective lol
2020-03-12 10:58:38 <fcolista> oh my
2020-03-12 10:59:19 <mps> PureTryOut[m]: it is better if it doesn't have these security problems as pulse
2020-03-12 10:59:39 <PureTryOut[m]> Idk about security problems with Pulse so I wouldn't know
2020-03-12 10:59:40 <fcolista> Cogitri, thanks
2020-03-12 10:59:51 <PureTryOut[m]> But if doesn't work currently for 95% of the use-cases of Pulse, no I wouldn't call it better
2020-03-12 11:00:23 <PureTryOut[m]> (I don't know if that is the case though)
2020-03-12 11:00:36 <mps> but pulse is bad (and I still think it should be removed from everything)
2020-03-12 11:00:42 <Cogitri> I don't see security problems in Pulse
2020-03-12 11:00:46 <Cogitri> And it works just fine for me
2020-03-12 11:01:07 <Cogitri> Pipewire's Pulse compatibility is in alpha quality right now, but eventually it should be a drop-in replacement
2020-03-12 11:01:14 <Cogitri> Pipewire's really exciting stuff
2020-03-12 11:01:53 <mps> yes, pipewire design looks really better, hope implementation also will be
2020-03-12 11:02:46 <mps> Cogitri: PA (pulseaudio) have sec issue of cross channels can't be efectivelly separated
2020-03-12 11:03:07 <mps> and controlled
2020-03-12 12:11:50 <PureTryOut[m]> Now leptonica gives me a bad signature when upgrading and fails
2020-03-12 12:12:42 <PureTryOut[m]> Then again I don't know why I had that package installed anyway so I just removed it 🤷‍♂️
2020-03-12 12:24:00 <_ikke_> PureTryOut[m]: We need to purge dl-cdn
2020-03-12 12:25:41 <PureTryOut[m]> That sounds bad
2020-03-12 12:31:28 <Cogitri> ikke: Can I still merge stuff or should I refrain from that?
2020-03-12 12:36:11 <_ikke_> Nah, it's just caching
2020-03-12 12:36:43 <Cogitri> Okie
2020-03-12 12:37:12 <_ikke_> Cogitri: so yes, you can just continue
2020-03-12 12:40:39 <Cogitri> Alright, thanks for confirming, ikke
2020-03-12 13:04:50 <_ikke_> PureTryOut[m]: dl-cdn caches packages
2020-03-12 13:16:46 <_ikke_> By reverting it, the builders build a new package with the same name that was already available
2020-03-12 13:17:07 <_ikke_> so unless you purge the cache for those files, it will keep serving the old package with a different hash
2020-03-12 14:01:58 <mps> PureTryOut[m]: are you around? I need changes for libpulse in !1051 but they are not visible there. do you have it somewhere
2020-03-12 14:02:45 <mps> yes, I know it is simple and probably can add by checking ./configure but if you have them ready would be nice
2020-03-12 14:03:08 <Cogitri> https://gitlab.alpinelinux.org/PureTryOut/aports/commit/8d145f8f7eaba06a232740d66a1c6f2f1bf87683.patch
2020-03-12 14:03:10 <u0jQx9gPyrYg> can this pulseaudio support be optional?
2020-03-12 14:03:15 <Cogitri> And https://gitlab.alpinelinux.org/PureTryOut/aports/commit/fe69028b0a70d0c316e553df1112ac01870b39b7.patch
2020-03-12 14:03:33 <Cogitri> (Gitlab corrupted old MRs on an upgrade somehow, so you have to download the patches of the commits)
2020-03-12 14:04:00 <Cogitri> u0jQx9gPyrYg: Yes, it'll pull in libpulse but probably can still use ALSA. mps is testing that right now
2020-03-12 14:04:30 <mps> u0jQx9gPyrYg: yes, if it disable alsa it will not be applied
2020-03-12 14:05:17 <mps> Cogitri: thanks for patches urls
2020-03-12 14:09:49 <u0jQx9gPyrYg> will that be the default? or does avoiding pulse require effort?
2020-03-12 14:11:41 <mps> I hope alsa will continue to work as is, if not we will not add pulse support
2020-03-12 14:16:30 <dalias> cogitri, aiui pulse allows all processes to read eachh other's audio
2020-03-12 14:16:35 <mps> surely I will not run pulseaudio (an similar) even if I have to fork alpine, which would be hard and painful. probably better idea would be to create something like ubuntu PPA for such things, or aports-ugly :)
2020-03-12 14:16:38 <dalias> that's the security problem of pulse
2020-03-12 14:17:15 <mps> dalias: hehe, I wrote few hours ago something similar above
2020-03-12 14:18:32 <mps> PA is bad in any sense, but alpine want to be user friendly
2020-03-12 14:18:43 <dalias> it may not be a practical problem with current poor priv-domain granularity
2020-03-12 14:18:53 <dalias> but we need to be moving to a model where applications are isolated from each other
2020-03-12 14:18:59 <dalias> and pulse precludes that
2020-03-12 14:19:38 <mps> pipewire looks better
2020-03-12 14:21:20 <dalias> it sounds overengineered to me
2020-03-12 14:22:30 <dalias> website main page shows an example:
2020-03-12 14:22:31 <dalias>   
2020-03-12 14:22:32 <dalias> SPA_PLUGIN_DIR=build/spa/plugins PIPEWIRE_MODULE_DIR=build  build/src/examples/export-sink
2020-03-12 14:22:43 <dalias> which suggests it's based on some awful plugin architecture :(
2020-03-12 14:29:23 <mps> (is there nowadays something not overenginered what wants to be mainstream)
2020-03-12 14:29:56 <mps> except musl, ofc :)
2020-03-12 14:31:15 <dalias> also it's from redhat..
2020-03-12 14:32:39 <mps> yes, and because that it smells to me to some degree
2020-03-12 14:33:30 <mps> but less than if it is from google
2020-03-12 14:33:37 <dalias> i've still never encountered a situation on desktop where i wanted more than one app playing audio at once
2020-03-12 14:33:45 <dalias> (on the same output device)
2020-03-12 14:33:56 <dalias> direct ALSA use seems like the obvious correct thing to do
2020-03-12 14:35:41 <mps> also for me
2020-03-12 14:37:18 <mps> maybe I didn't expressed my opinion clearly about all this. I do not advocate adding pipewire just say I think it is safer than PA
2020-03-12 14:37:46 <mps> but I don't think that any of them is needed
2020-03-12 14:39:28 <dalias> the real use case is desktop environments that want to make annoying notification noises all the time
2020-03-12 14:39:38 <mps> one of the 'drops of water' which forced me to ditch debian after more than 20 years of usage was also to have to start PA if I need to listen something in firefox
2020-03-12 14:39:41 <dalias> including while you're trying to watch a movie
2020-03-12 14:40:15 <AinNero> oh, this explains why i havent had problems with alsa until now
2020-03-12 14:40:27 <AinNero> always wondered why people explain, but i dont have notifications at all
2020-03-12 14:40:33 <AinNero> s/explain/complain/
2020-03-12 14:40:33 <alpine-meetbot> AinNero meant to say: always wondered why people complain, but i dont have notifications at all
2020-03-12 14:40:41 <dalias> i *hate* notifications of all sorts
2020-03-12 14:40:45 <dalias> i will poll for what i want to see
2020-03-12 14:40:58 <AinNero> this is like, optimized for interrupting whatever flow you are currently in
2020-03-12 14:41:03 <dalias> exactly
2020-03-12 14:41:27 <mps> nowadays people cannot live without distractions :)
2020-03-12 14:46:36 <Cogitri> I do like to sometimes listen to some quiet music while chatting with others
2020-03-12 14:46:58 <Cogitri> Pipewire is pretty nice tho
2020-03-12 14:47:49 <dalias> still the problem would be 100% solved by alsa just doing trivial mixing in the kernel
2020-03-12 14:47:58 <dalias> with far less complexity
2020-03-12 14:48:18 <Cogitri> I don't think ALSA can do video playback
2020-03-12 14:48:46 <dalias> video playback doesn't require any hardware devices, just an X window
2020-03-12 14:49:02 <TBB> one can only hope one day it will
2020-03-12 14:49:30 <dalias> so i don't see how/why they want video involved here
2020-03-12 14:49:33 <TBB> hate having a recent gfx card and the browser just never utilizing it for accelerated video playback
2020-03-12 14:49:45 <dalias> i really couldn't care less
2020-03-12 14:49:55 <dalias> i jjust want everything to be stable and properly isolated in privilege domains
2020-03-12 14:50:02 <TBB> I do, because CPU playback causes elevated fan noise
2020-03-12 14:50:07 <dalias> i don't have fans
2020-03-12 14:50:19 <Cogitri> dalias: You absolutely need more than an X window since you need a decoder and stuff
2020-03-12 14:50:33 <TBB> not that I wouldn't care about stability as well, something that's in sharp decline even in supposedly widely tested distros such as the *buntus
2020-03-12 14:50:34 <Cogitri> And pipewire integrates with gstreamer for decoding/encoding
2020-03-12 14:50:35 <dalias> cogitri, that's not hardware. it's computation
2020-03-12 14:51:17 <dalias> i don't use gstreamer either except possibly from firefox if firefox uses it
2020-03-12 14:51:58 <Cogitri> Yes, FF uses it via gst-libav
2020-03-12 14:52:54 <u0jQx9gPyrYg> coming back to the topic of mixing multiple audio streams, that actually works for me, i can mumble, watch something with mpv, and have aplay play a timed alarm at the same time with all 3 audio streams correctly being delivered to my ear
2020-03-12 14:53:10 <u0jQx9gPyrYg> pure alsa
2020-03-12 14:53:26 <AinNero> u0jQx9gPyrYg: any customisations? asoundrc?
2020-03-12 14:53:39 <dalias> u0jqx9gpyryg, is it doing the userspace mixing thing where one process acts as the server for the other?
2020-03-12 14:53:46 <dalias> or does alsa support mixing in kernel now?
2020-03-12 14:54:03 <u0jQx9gPyrYg> i have no "server" running
2020-03-12 14:54:14 <u0jQx9gPyrYg> what server would that be?
2020-03-12 14:55:01 <dalias> ok, i have 2 mplayers running now and neither has any fds open except the media file and the alsa device nodes
2020-03-12 14:55:09 <dalias> so i guess kernel does it
2020-03-12 14:55:13 <u0jQx9gPyrYg> i have no file on the system that has asoundrc in its name
2020-03-12 14:55:15 <dalias> and all this pulse/etc. stuff is just useless
2020-03-12 14:55:57 <u0jQx9gPyrYg> the only program that cannot handle other programs doing audio at the same time is linrad
2020-03-12 14:56:15 <dalias> at one point in history, libasound did soft mixing in userspace where it would silently spawn a background process or one of the sound-using processes would just consume audio from the other, mix, and output it
2020-03-12 14:56:31 <dalias> this was like 15-20 years ago, mind you
2020-03-12 14:56:39 <dalias> i haven't bothered to keep up with how it's done
2020-03-12 15:00:15 <TBB> alsa, on the other hand, has always been so hard to configure they haven't even been able to document it properly themselves. and it by no means takes care of everything...
2020-03-12 15:01:03 <u0jQx9gPyrYg> i had never to configure anything with alsa unless i wanted to do something non-default
2020-03-12 15:01:41 <AinNero> does mplayer have any advantage over mpv nowadays?
2020-03-12 15:01:42 <u0jQx9gPyrYg> the only configuration i had to do when i wanted to pipe a wav file into the line-in device, that was a bit of an exercise
2020-03-12 15:01:54 <TBB> consider yourself lucky then. I went and got myself a proper sound card for audio work, one that was even properly supported on Linux
2020-03-12 15:02:02 <u0jQx9gPyrYg> while another application was listening on the line-in device for input
2020-03-12 15:03:00 <u0jQx9gPyrYg> i don't do audiowork, i only use it as a desktop sound device, and occasionally do radio stuff with the frequency mixed down to the hearable spectrum.
2020-03-12 15:03:38 <u0jQx9gPyrYg> of course if you buy any special (non-default) hardware for linux you can run into configuration hell, that does not apply to alsa only
2020-03-12 15:03:39 <TBB> needless to say, I didn't do my audio work on Linux after that short experience either :D
2020-03-12 15:04:16 <TBB> well, like I said, the card and the chipset itself turned out to be one of the best supported at the time on Linux (ICE1712)
2020-03-12 15:04:29 <u0jQx9gPyrYg> you will have the same problems with less-than-well-supported wifi cards, or even nvidia gfx cards, or anything
2020-03-12 15:04:39 <u0jQx9gPyrYg> oh. i didn't get that.
2020-03-12 15:05:19 <u0jQx9gPyrYg> i guess my intel-onboard audio is much better supported than what you found as "one of the best supported at the time"
2020-03-12 15:05:53 <TBB> like, basic playback worked flawlessly at 24-bit/96KHz. the card just had a lot of additional features like 10 lines in, 10 out and MIDI in/out
2020-03-12 15:06:43 <TBB> and the experience configuring ALSA to make proper use of them was... well, let's just say less than satisfactory
2020-03-12 15:06:49 <PureTryOut[m]> !5048 is now only failing on CI due to too large artifacts, but is good for merging otherwise
2020-03-12 15:07:05 <u0jQx9gPyrYg> ah. right
2020-03-12 15:07:17 <u0jQx9gPyrYg> makes sense
2020-03-12 15:08:44 <mps> u0jQx9gPyrYg: I can't get audio from two (or more sources) at same time, ff and mpv for example. it works 'first come, first serve'
2020-03-12 15:09:01 <mps> maybe it is driver problem
2020-03-12 15:10:46 <mps> '[ao/alsa] Playback open error: Resource busy'
2020-03-12 15:10:46 <u0jQx9gPyrYg> super strange this has been working for me since ages
2020-03-12 15:11:00 <u0jQx9gPyrYg> ff?
2020-03-12 15:11:03 <u0jQx9gPyrYg> you mean firefox?
2020-03-12 15:11:14 <mps> firefox, yes
2020-03-12 15:11:31 <u0jQx9gPyrYg> my firefox is confined, has no access to nothing. so my firefox does not do any sound.
2020-03-12 15:11:39 <u0jQx9gPyrYg> can you try mpv and aplay together?
2020-03-12 15:11:46 <mps> but two instances of mpv also have same problem
2020-03-12 15:11:51 <u0jQx9gPyrYg> oh?
2020-03-12 15:12:41 <u0jQx9gPyrYg> i have two mpvs doing audio here in parallel
2020-03-12 15:12:56 <mps> and I never tried to find cause of this, I don't like to listen two audios at same time
2020-03-12 15:13:29 <u0jQx9gPyrYg> as said, doing mumble, watching a video, and having an alarm that tee is ready is a common thing for me
2020-03-12 15:13:36 <mps> but just noticing this sometimes if pause one and forget, and starting new one
2020-03-12 15:14:23 <u0jQx9gPyrYg> i like to watch friends play games on twitch and have an mumble channel open with them at the same time, so i get the sounds from the game, but can also chat with them
2020-03-12 15:16:21 <u0jQx9gPyrYg> my mpv gives this output: `AO: [alsa] 48000Hz stereo 2ch float`
2020-03-12 15:16:58 <u0jQx9gPyrYg> and i have no config for mpv
2020-03-12 15:17:18 <mps> same here 'AO: [alsa] 48000Hz stereo 2ch float'
2020-03-12 15:22:27 <u0jQx9gPyrYg> i have these "files" open with both mpvs: /dev/snd/pcmC0D0p /dev/snd/timer /dev/snd/pcmC0D0p /dev/snd/controlC0
2020-03-12 15:23:03 <u0jQx9gPyrYg> they are all in the audio group (rw) and i am member of it
2020-03-12 15:23:49 <mps> u0jQx9gPyrYg: hm, on x86_64 two mpv's works fine
2020-03-12 15:24:12 <mps> but not on aarch64
2020-03-12 15:24:41 <mps> interesting
2020-03-12 15:28:55 <u0jQx9gPyrYg> interesting indeed
2020-03-12 15:30:55 <mps> must be driver issue
2020-03-12 15:48:34 <mps> gcc 9.3 released https://gcc.gnu.org/gcc-9/changes.html
2020-03-12 15:49:40 <mps> no lfence by default
2020-03-12 15:50:12 <mps> so looks safe to upgrade
2020-03-12 15:50:17 <mps> ncopa: ^ ?
2020-03-12 17:00:49 <Cogitri> ikke: Is there some workaround to the bad signature thingie?
2020-03-12 17:00:55 <Cogitri> I can't build stuff due to it :/
2020-03-12 17:01:12 <_ikke_> ah yes
2020-03-12 17:01:14 <_ikke_> Which package?\
2020-03-12 17:01:42 <_ikke_> leptonica?
2020-03-12 17:01:44 <Cogitri> leptonica has the bad signature
2020-03-12 17:01:44 <Cogitri> Yes
2020-03-12 17:01:45 <_ikke_> ok
2020-03-12 17:01:52 <Cogitri> Can't build webkit2gtk due to that
2020-03-12 17:01:55 <_ikke_> I was doing that, but my laptop was acting strange
2020-03-12 17:03:28 <artok> so mu doesn't really have package maintainer?
2020-03-12 17:04:47 <artok> seems to be in edge testing
2020-03-12 17:04:57 <_ikke_> Cogitri: can you try again
2020-03-12 17:05:06 <Cogitri> ikke: leptonica is fine now, leptonica-dev isn't
2020-03-12 17:05:20 <_ikke_> I did that one as well
2020-03-12 17:05:32 <Cogitri> Ah, works now
2020-03-12 17:05:47 <Cogitri> I guess I timed that perfectly :P
2020-03-12 17:05:49 <_ikke_> artok: correct, it does not have a maintainer
2020-03-12 17:05:56 <_ikke_> yes, indeed
2020-03-12 17:09:03 <_ikke_> rust 1.42 has been released. Start the timer until the first package requires v1.42
2020-03-12 17:09:09 <_ikke_> :)
2020-03-12 17:09:19 <Cogitri> Heh
2020-03-12 17:09:29 <Cogitri> It isn't as bad as it used to be though
2020-03-12 17:09:44 <Cogitri> Thanks for the reminder though, I'll go ahead and bump it
2020-03-12 17:43:19 <Cogitri> fabled: Ping
2020-03-12 18:11:05 <mps> PureTryOut[m]: looks like it is not enough to remove '--disable-pulseaudio' from './configure' to build FF with libpulse
2020-03-12 18:20:05 <Cogitri> Oh derp, I was debugging why I was getting "Can't lock database: Resource unavailable" during updates in my Polkit helper for APK and turns out I was doing an upgrade in another terminal :D
2020-03-12 18:25:57 <PureTryOut[m]> mps: are you sure pulseaudio-dev is installed in the build environment?
2020-03-12 18:26:17 <mps> yes, it is in makedepends
2020-03-12 18:29:24 <mps> could it be that '--enable-alsa' auto disables libpulse ?
2020-03-12 19:40:26 <PureTryOut[m]> Shouldn't, other distros have it as well
2020-03-12 19:48:01 <PureTryOut[m]> Someone please merge !5048, it contains an CVE fix and it has passed CI already (just fails because of too large artifacts for CI to upload)
2020-03-12 19:48:10 <PureTryOut[m]> I will make the fix for 3.11 as well
2020-03-12 19:51:42 <fabled> Cogitri, i am not sure what happens. sounds like the builders have a race that the index might not be in sync with the packages
2020-03-12 19:52:20 <fabled> but that's something to take into account in the revision. name packages so that they have a small unique id part in the file name to make sure overwrites / force pushes won't mess up things
2020-03-12 19:55:35 <PureTryOut[m]> Please merge !5344, it fixes the security issue I mentioned in 3.11
2020-03-12 19:58:19 <Cogitri> fabled: Ah, I was actually meaning to ask for another review of the make MR for apk-tools
2020-03-12 20:12:00 <fabled> Cogitri, which one?
2020-03-12 20:12:15 <fabled> 11?
2020-03-12 20:14:02 <fabled> there's a bit more commits already then needed, and fixups to commits. i was thinking to cherry-pick / flatten some. and then maybe do few of them differently. or would you like to rework on it?
2020-03-12 20:14:55 <Cogitri> Yup. I think it's best to merge all squashed into one commit
2020-03-12 20:36:27 <PureTryOut[m]> !5344 has wrong secfix notice but I'm not on a PC atm to fix it. Can the one merging it fix it?
2020-03-12 20:50:58 <fabled> Cogitri, ok, thanks, I'll try to schedule time to look at it tomorrow
2020-03-12 20:54:07 <Cogitri> Thank you :)
2020-03-12 21:46:25 <maxice8> @PureTryOut !5345 fails on ppc64le due to an apparently CI error, ok to merge ?
2020-03-13 08:10:11 <PureTryOut[m]> maxice8: yes
2020-03-13 09:47:10 <_ikke_> flatbuffers test fail on armhf due to bus error
2020-03-13 11:17:34 <ncopa> Cogitri: re #11296 would be nice if we also add the commit that fixes each branch
2020-03-13 11:44:03 <nmeum> do we want to build busybox's wc with FEATURE_WC_LARGE to fix #11294?
2020-03-13 11:44:10 <nmeum> increase in binary size should be minimal
2020-03-13 11:44:59 <_ikke_> what about 32-bit arches?
2020-03-13 11:45:39 <nmeum> what about them? doing so just changes the counter type from unsigned to unsinged long long
2020-03-13 11:47:06 <_ikke_> nod
2020-03-13 11:52:07 <ncopa> nmeum: havent looked a the details of that config option but it sounds like something we want
2020-03-13 11:52:58 <nmeum> yep, I think so too
2020-03-13 11:53:35 <nmeum> just made the neccessary changes, will just do a quick check how much larger the package would get (very very likely not a lot)
2020-03-13 11:59:06 <nmeum> well, at least looking at the size attribute from the .PKGINFO the size doesn't seem to change?
2020-03-13 11:59:34 <nmeum> should I just push the change? https://tpaste.us/ObM8
2020-03-13 12:00:33 <mps> for a such simple change I didn't expect size change
2020-03-13 12:08:31 <nmeum> it changes a variable type but whatever
2020-03-13 12:08:33 <nmeum> I will just push it
2020-03-13 12:29:49 <Cogitri> ncopa: Ah yes, wanted to do that later, marked it check via my phone
2020-03-13 12:30:34 <Cogitri> Was busy fighting musl locales and postgres in #11297 afterwards
2020-03-13 12:30:48 <Cogitri> Seems like we'll have to revert back to Debian at work :/
2020-03-13 14:54:53 <Ariadne> Cogitri: we could backport the locale changes to musl 1.1
2020-03-13 14:54:59 <gjabell> anyone else having import issues with qutebrowser on edge?
2020-03-13 15:03:26 <Cogitri> Ariadne: Would be nice, but not sure how big of a task that is
2020-03-13 15:03:47 <mps> Cogitri: big enough
2020-03-13 15:10:25 <Cogitri> I imagine so
2020-03-13 15:10:43 <Cogitri> But it'd certainly appreciate postgres working correctly on 3.11
2020-03-13 15:10:52 <Cogitri> s/it/I/
2020-03-13 15:10:52 <alpine-meetbot> Cogitri meant to say: But I'd certainly appreciate postgres working correctly on 3.11
2020-03-13 15:11:03 <Cogitri> Switching production over to Alpine would be neat
2020-03-13 15:11:15 <mps> Cogitri: it works in my installation. what is your issue
2020-03-13 15:12:48 <Cogitri> See #11297
2020-03-13 15:12:54 <Cogitri> LC_COLLATE effectively always is C
2020-03-13 15:13:03 <mps> ah, yes
2020-03-13 15:13:16 <_ikke_> Cogitri: why specific in docker images?
2020-03-13 15:13:43 <Cogitri> So unless you explicitly say you want to use ICU locales at table creation or during the query itself it'll use C ordering
2020-03-13 15:13:49 <mps> Cogitri: how can I check this in my postgres lxc container
2020-03-13 15:13:54 <Cogitri> _ikke_: Ah, it's not specific to Docker
2020-03-13 15:14:02 <Cogitri> mps: See the reproducer in the issue
2020-03-13 15:14:54 <mps> ok, will do, though I'm feel bad now, (should take 2 weeks of self isolation using corona as excuse :) )
2020-03-13 17:57:56 <mps> rnalrd: did you add homer-app? 'release/homer-app_linux_amd64/homer-app: line 1: syntax error: unterminated quoted string'
2020-03-13 18:00:26 <_ikke_> !11302
2020-03-13 18:00:38 <_ikke_> hmm?
2020-03-13 18:00:40 <_ikke_> ah
2020-03-13 18:00:42 <_ikke_> #11302
2020-03-13 18:19:47 <kaey> _ikke_: check function looks wrong, it should be ./homer-app --version
2020-03-13 18:19:57 <kaey> or in fact options="!check"
2020-03-13 18:20:10 <_ikke_> yeah, just running --version is not considered a proper check
2020-03-13 18:20:25 <_ikke_> I did not look at the APKBUILD file at all
2020-03-13 18:38:18 <mps> PureTryOut[m]: uhm, whatever I tried I can't get FF to use libpulse
2020-03-13 18:45:57 <maxice8> fixed sleuthkit and py3-bleach, can someone take a look at cacti ? if no-one answers i'll take a look myself sometime later
2020-03-13 22:40:42 <maxice8> ok i'll take a look at cacti
2020-03-13 23:17:32 <maxice8> Good news, mkmr=0.0.2-r0 is now in testing
2020-03-13 23:20:41 <mps> made by maxice8 :)
2020-03-13 23:21:15 <mps> +1
2020-03-13 23:21:33 <maxice8> I think it is still slightly cumbersome with one having to pass --token <TOKEN> every time
2020-03-13 23:21:43 <maxice8> but i don't know if i want to burden the user with a configuration file
2020-03-13 23:22:07 <Cogitri> How about using libsecret for managing that?
2020-03-13 23:22:10 <maxice8> even though py3-python-gitlab already has support for configuration files
2020-03-13 23:22:10 <mps> if you ask me, yes, add config file
2020-03-13 23:23:31 <maxice8> @Cogitri I don't think the type of user that uses the ML even has a system keyring set up like gnome-keyring
2020-03-13 23:25:09 <Cogitri> They can use kwallet if they want to :P
2020-03-13 23:25:28 <Cogitri> Managing the API token ourselves seems cumbersome and insecure
2020-03-13 23:26:12 <maxice8> Yeah lets put the file
2020-03-13 23:26:47 <mps> security is discipline and not software
2020-03-13 23:26:53 <maxice8> people that use email already have a ~/.config/aerc/accounts.conf or whatever another config file is nothing i'd guess.
2020-03-13 23:30:09 <Cogitri> mps: I don't think any amount of discipline will stop some software from reading your ~/.secret-passwords-please-dont-read
2020-03-13 23:30:21 <Cogitri> Having an encrypted keyring will
2020-03-13 23:30:43 <Cogitri> And GNOME Keyring and friends also make sure nothing can read from their private memory and that key don't stay in memory for longer than they have to
2020-03-13 23:33:57 <mps> except when 'sec software' have sec flaw
2020-03-13 23:35:50 <mps> or hardware, you read latest news about LVI
2020-03-13 23:36:49 <Cogitri> When GNOME Keyring has a CVE then it should be fixed, but you literally can't be less safe than putting the unhashed token into a file that your main user can read
2020-03-13 23:36:51 <mps> https://lviattack.eu/
2020-03-13 23:37:05 <Cogitri> Well, unless you put the token into /tmp and make it world readable or smth I guess
2020-03-13 23:37:45 <mps> no, I want to say that false sense of security is worse than no security
2020-03-13 23:38:32 <Cogitri> ...so because something has the possibility of having a CVE it's automatically worse than no security?
2020-03-13 23:38:40 <mps> and, imo, there is no 100% secure hardware or software
2020-03-13 23:39:01 <Cogitri> Let's just off HTTPS then since that's clearly not 100% secure either :^)
2020-03-13 23:39:17 <mps> you misunderstood me. security is discipline.
2020-03-13 23:39:44 <mps> true, https is not 100% secure
2020-03-13 23:41:34 <mps> but, going to bed, good night :)
2020-03-13 23:43:08 <Cogitri> Nighr
2020-03-14 02:25:00 <manjaroi3> I would like to know what documentation I have to read regarding publishing binaries as packages. I comment on this because the documentation on the website talks about compiling the source. My case is that I managed to get the GHC to run on an ARM64, but on ARMBIAN, I would like to share the binary as an Alpine package.
2020-03-14 02:29:44 <maxice8> You mean make an alpine package with pre-compiled binaries ?
2020-03-14 02:30:14 <manjaroi3> That's right, maxice8
2020-03-14 02:30:27 <dalias> to be in official alpine repo the package needs  to be buildable from source
2020-03-14 02:30:42 <maxice8> In that case you can create an APKBUILD and have abuild build the apk file for you
2020-03-14 02:30:55 <maxice8> do note that like dalias said, it won't be considered for inclusion in Alpine Linux
2020-03-14 02:34:28 <manjaroi3> Thanks for the answers, I suspected that there was no way after researching and finding nothing about publishing this way.
2020-03-14 04:31:14 <maxice8> https://pypi.org/project/mkmr/0.0.3/, also available in testing/
2020-03-14 06:22:59 <_ikke_> thanks, will try it out
2020-03-14 18:02:43 <maxice8> @PureTryOut: merged okular to 3.11-stable with the secfixes changed
2020-03-14 18:03:01 <maxice8> @_ikke_ updated atools to 18.14.0 now it has invalid-option [AL49] which check for invalid options in the options="" variable
2020-03-14 18:03:29 <maxice8> and mkmr 0.0.4 is out, it is very aggressive in trying to get a working default configuration, at the expense of configurability
2020-03-14 18:09:43 <maxice8> oh dear, we have lots of  undocumented options
2020-03-14 18:20:24 <maxice8> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#options
2020-03-14 18:20:29 <maxice8> now they are almost all documented
2020-03-14 18:23:22 <oneinsect> have you updated only the doc for Build-time options for the package or for the full page?
2020-03-14 18:23:41 <maxice8> build-time options
2020-03-14 18:24:19 <oneinsect> thanks!
2020-03-14 18:38:08 <grubles> does the bootstrap.sh script work? it seems to hang up on binutils.
2020-03-14 18:51:07 <[[sroracle]]> >net: Allows network access when run in fakeroot.
2020-03-14 18:51:16 <[[sroracle]]> this is wrong, it's rootbld not fakeroot
2020-03-14 18:52:26 <maxice8> also with bwrap
2020-03-14 18:52:26 <_ikke_> fixed
2020-03-14 18:52:27 <maxice8> otherwise it adds --unshare-net
2020-03-14 18:53:24 <[[sroracle]]> that's what rootbld is
2020-03-14 18:53:27 <[[sroracle]]> also this is also missing sover-namecheck
2020-03-14 18:53:43 <maxice8> i didn't document that because i didn't understood what it was doing
2020-03-14 19:03:18 <_ikke_> pth fails to build on all arches
2020-03-14 19:15:39 <timlegge> was there a suggested format on patch file comments?  In APKBUILD or in the patch file?
2020-03-14 19:17:02 <_ikke_> From exherbo: https://exherbo.org/docs/eapi/exheres-for-smarties.html#applying_patches
2020-03-14 19:19:10 <timlegge> thanks
2020-03-14 19:19:54 <Cogitri> I'd add that to our docs too but I'm unsure where to be honest
2020-03-14 19:20:11 <Cogitri> But missing patch headers really are a major painpoint
2020-03-14 19:20:34 <Cogitri> Especially when there's stuff like fix.patch without a patch header and the commit msg which added it doesn't explain anything either
2020-03-14 19:21:54 <dalias> _ikke_, is this a regression in an existing package or something new you're trying to package?
2020-03-14 19:23:29 <_ikke_> dalias: about pth?
2020-03-14 19:24:16 <dalias> *nod*
2020-03-14 19:24:39 <_ikke_> Seems a regression, but I was just relaying the build status
2020-03-14 19:24:59 <_ikke_> Leo pushed some commits
2020-03-14 19:25:15 <_ikke_> https://git.alpinelinux.org/aports/commit/?id=81633f00
2020-03-14 19:27:02 <maxice8> oh
2020-03-14 19:27:04 <maxice8> oh wow
2020-03-14 19:27:15 <maxice8> i was grepping /usr/bin/abuild for options_has
2020-03-14 19:30:10 <maxice8> it uses 'list_has "!libc_$CLIBC" $options'
2020-03-14 19:30:12 <maxice8> instead of option_has "!libc_$CLIBC"
2020-03-14 19:52:37 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/39/diffs
2020-03-14 21:51:05 <maxice8> Do we still need that ? i don't remember uclibc
2020-03-14 23:51:02 <Ariadne> maxice8: it is desirable to keep
2020-03-14 23:59:23 <grubles> hello, i'm having an issue with bootstrap.sh https://pastebin.com/GgfNuXBK
2020-03-14 23:59:36 <grubles> with ppc64le host and x86_64 target
2020-03-15 11:09:08 <Cogitri> fabled: What's the purpose of doing a deep copy of `db.world` in places like del_main ?
2020-03-15 11:38:21 <Cogitri> Also, mind if I open bugs for SIGSEGVs I get in libapk? It's probably due to me doing something wrong but I suppose libapk should handle those more gracefully
2020-03-15 19:08:59 <nmeum> is it just me or does evince always crash on edge?
2020-03-15 19:09:18 <maxice8> crash on startup ?
2020-03-15 19:10:15 <mps> also here, on start
2020-03-15 19:10:53 <mps> Trace/BPT trap
2020-03-15 19:12:21 <mps> --- SIGTRAP {si_signo=SIGTRAP, si_code=SI_TKILL, si_pid=13452, si_uid=1000} ---
2020-03-15 19:13:15 <_ikke_> maxice8: when are you going to do something about flatbuffers?
2020-03-15 19:15:00 <maxice8> don't know
2020-03-15 19:15:41 <_ikke_> It's blocking the armhf builder
2020-03-15 19:17:26 <nmeum> mps: yep, same error here
2020-03-15 19:17:38 <nmeum> don't have time to investigate it atm
2020-03-15 19:17:43 <nmeum> but good to know I am not alone
2020-03-15 19:21:11 <mps> also I don't have time now
2020-03-15 19:21:52 <nmeum> I will get to it eventually unless somebody fixes it before I do :)
2020-03-15 19:23:29 <mps> I mostly use zathura, so i'm not in hurry :)
2020-03-15 19:47:37 <Cogitri> I can look into, but evince wfm
2020-03-15 19:47:57 <mps> wfm?
2020-03-15 19:47:58 <Cogitri> Can you spin me a backtrace?
2020-03-15 19:48:03 <Cogitri> Works for me
2020-03-15 19:48:17 <mps> I tested on aarch64
2020-03-15 19:48:50 <mps> would be strace enough
2020-03-15 19:49:51 <mps> btw, I tested postgres with de_DE.UTF-8 and the results same as yours
2020-03-15 19:52:20 <Cogitri> Yes :/
2020-03-15 19:52:30 <Cogitri> Really unfortunate that musl didn't support this better before 1.2
2020-03-15 19:53:04 <Cogitri> We'll have to use Debian in prod now at least until an Alpine stable release with musl 1.2/postgres 13 is out
2020-03-15 19:53:06 <mps> if you are on 64bit you can upgrade musl and rebuild postgres
2020-03-15 19:53:29 <Cogitri> Yeah, I don't think I want to upgrade musl and push that to production
2020-03-15 19:53:47 <Cogitri> Also, for evince: Doesn't it dump core?
2020-03-15 19:54:13 <mps> no, I disabled coredumps, always*
2020-03-15 19:54:46 <Cogitri> Ah, well, I won't be able to debug it then
2020-03-15 19:55:03 <Cogitri> I always enable coredumps and manage them via corecollector
2020-03-15 19:56:00 <mps> well, if I have to debug it I have to build it with -g first
2020-03-15 20:00:21 <Cogitri> Just add a -dbg package
2020-03-15 20:00:53 <Cogitri> Which we should probably do for most packages anyway
2020-03-15 20:05:05 <mps> hmm, apk search evince-dbg => nothing found
2020-03-15 20:21:37 <Cogitri> Yes, add a -dbg package and install it
2020-03-15 20:21:47 <Cogitri> I should add -dbg subpackages for more stuff
2020-03-15 20:30:48 <mps> apk add evince-dbg => evince-dbg (missing):
2020-03-15 20:36:41 <Cogitri> Add as in add it to the APKBUILD
2020-03-15 20:39:55 <mps> ah, I know this
2020-03-15 20:42:02 <mps> would be easier to temporary enable coredump :)
2020-03-15 20:48:35 <Cogitri> The coredump is useless without dbg info
2020-03-15 20:48:50 <mps> I see already
2020-03-15 20:50:30 <mps> for now I can only post strace output
2020-03-15 20:51:51 <mps> http://tpaste.us/6Vp9
2020-03-15 20:52:00 <mps> last 100 lines
2020-03-15 20:53:37 <AinNero> where do i open bugs on packages? in gitlab on the aports repo?
2020-03-15 20:54:53 <mps> AinNero: yes
2020-03-15 20:55:31 <mps> if the pkg in aports repo, ofc
2020-03-15 20:59:41 <AinNero> maybe talk here, my vt520 stuff doesnt work as expected anymore
2020-03-15 20:59:54 <AinNero> ncurses doesnt search $HOME/.terminfo first anymore
2020-03-15 21:00:04 <AinNero> so it does not respect my terminfo fixes
2020-03-15 21:01:07 <mps> eh, coincidence, right now I'm working on fixing ncurses
2020-03-15 21:01:23 <AinNero> this issue?
2020-03-15 21:02:34 <mps> I'm fixing splitting of terminfos to -base and terminfo
2020-03-15 21:02:56 <mps> and added vt* to terminfo-base
2020-03-15 21:03:32 <AinNero> might be a different issue
2020-03-15 21:03:33 <AinNero> https://gitlab.alpinelinux.org/alpine/aports/issues/11304
2020-03-15 21:04:33 <mps> will see
2020-03-15 21:07:38 <mps> AinNero: yes, I see, that need to be fixed
2020-03-15 21:08:52 <maxice8> Isn't adding all that vt stuff to -base losing the point?
2020-03-15 21:09:22 <maxice8> I tought Ncurses-terminfo-base Was to provide only the most used ones like the terminals emulators we package and the Linux terminfo
2020-03-15 21:11:02 <AinNero> maxice8: as it was before, i'd probably have to install the full set anyways
2020-03-15 21:11:04 <mps> maxice8: no, vt* is needed for serial consoles
2020-03-15 21:11:15 <AinNero> last time i checked, 'tmux' wasnt in it as well
2020-03-15 21:11:34 <AinNero> mps: is it?
2020-03-15 21:11:44 <mps> AinNero: what?
2020-03-15 21:11:49 <AinNero> serial consoles usually have the termtype of whats attached to its end
2020-03-15 21:11:57 <AinNero> so its sth like picocom or screen usually
2020-03-15 21:11:59 <mps> yes
2020-03-15 21:12:41 <mps> try minicom without vt102
2020-03-15 21:13:06 <mps> AinNero: looks like upstream changed search order of terminfo dirs
2020-03-15 21:13:42 <mps> no, it is not
2020-03-15 21:14:23 <mps> according you bug report all looks fine, it searches $HOME/.terminfo at the end
2020-03-15 21:14:58 <AinNero> because i have my chmod 0000 quirk in it
2020-03-15 21:15:09 <AinNero> my concern is not that its not found, its that the search order is wrong
2020-03-15 21:15:38 <mps> $HOME/.terminfo should be last
2020-03-15 21:15:48 <AinNero> why?
2020-03-15 21:15:58 <mps> I can ask on ML, but I think it is ok
2020-03-15 21:16:35 <mps> it overides previously found term description
2020-03-15 21:17:11 <AinNero> diskless raspi, http://w1r3.net/paste/ahDVyn.txt
2020-03-15 21:17:24 <AinNero> you cann see $HOME/.terminfo was first place before
2020-03-15 21:17:27 <AinNero> which makes sense
2020-03-15 21:17:50 <AinNero> because now i need root or custom terminal types (to set them also requires root) to make my terminal work
2020-03-15 21:18:00 <AinNero> and i dont have root on all machines where i'd ssh to
2020-03-15 21:18:53 <mps> there is TERMINFO_DIRS env var which can be set/exported with ordered search dirs
2020-03-15 21:19:40 <AinNero> like, why did the order change in the first place
2020-03-15 21:19:56 <AinNero> it worked in v3.10 (and still works there), and in edge the behavior is different
2020-03-15 21:20:16 <mps> I don't think that the order changed in last 2 years
2020-03-15 21:20:31 <AinNero> it did in the last two months
2020-03-15 21:20:56 <AinNero> i did an apk upgrade on my machine today, after which the status bar and F-keys on my terminal stopped working
2020-03-15 21:20:59 <mps> can you point to git commit in aports when it is changed
2020-03-15 21:22:30 <mps> last time change is e773ffa89a7b52f56f5cdbce5d3ab6518a192e8d
2020-03-15 21:22:49 <mps> Date:   Mon Sep 3 12:30:54 2018 +0000
2020-03-15 21:23:25 <AinNero> there had been some changes to that aport since then
2020-03-15 21:23:50 <mps> yes, but not about search path for terminfo
2020-03-15 21:24:37 <mps> and '--disable-home-terminfo' is not set
2020-03-15 21:24:39 <AinNero> id search in upstream git if they had any
2020-03-15 21:25:07 <AinNero> anyways, ill just nerf /usr/share/terminfo for now
2020-03-15 21:59:21 <craftyguy> why are openrc initd script in separate packages, $pkgname-openrc ?
2020-03-15 22:01:11 <skarnet> in order to support several init script systems in the future.
2020-03-15 22:02:46 <dalias> alpine is built without support for ~/.terminfo ?
2020-03-15 22:04:41 <mps> dalias: you mean ncurses
2020-03-15 22:24:00 <dalias> yeah i mean alpine's ncurses package
2020-03-15 22:25:07 <maxice8> @craftguy containers don't use openrc so it will just be bloating them
2020-03-15 22:27:33 <_ikke_> and if we want to support multiple init systems, alpine will just pull in the ones for the init system you use
2020-03-15 22:27:45 <mps> dalias: it support ~/.terminfo
2020-03-15 22:28:16 <Cogitri> nmeum:  Can you spin me a backtrace of evince?
2020-03-15 22:32:43 <craftyguy> skarnet: I suspected that might be the case. is there some implied 'install_if' somewhere that installed the -openrc subpkg for $pkg when openrc is the init system?
2020-03-15 22:33:09 <mps> AinNero: I tested on my machine, ~/.terminfo works fine
2020-03-15 22:33:47 <AinNero> can you post strace?
2020-03-15 22:34:04 <skarnet> craftyguy: I have no idea, sorry.
2020-03-15 22:34:27 <maxice8> @craftguy: yes, see default_openrc() in /usr/bin/abuild
2020-03-15 22:34:34 <maxice8> install abuild if you don't have /usr/bin/abuild
2020-03-15 22:34:55 <mps> AinNero: why?
2020-03-15 22:35:38 <AinNero> so i can look at the search order?
2020-03-15 22:37:09 <mps> how you get strace for this
2020-03-15 22:41:25 <AinNero> i did `strace tput -T vt520 tsl|hexdump -Cv`
2020-03-15 22:42:21 <AinNero> meh, stop looking
2020-03-15 22:42:42 <AinNero> urxvt sets TERMINFO=/usr/share/terminfo
2020-03-15 22:42:57 <AinNero> i started a tmux session from there
2020-03-15 22:43:10 <AinNero> and did an `tmux a` from the vt520
2020-03-15 22:43:49 <mps> heh
2020-03-15 23:03:08 <AinNero> mps: its MR #5451 now
2020-03-15 23:03:31 <maxice8> @AinNero: you're looking for !5451
2020-03-15 23:03:45 <AinNero> exclamation mark, mh
2020-03-15 23:03:58 <maxice8> exclamation for merge requests, hashtag for issues
2020-03-15 23:10:01 <mps> ah, urxvt have hardcoded TERMINFO env var? strange
2020-03-15 23:10:48 <AinNero> mps: https://github.com/exg/rxvt-unicode/blob/master/README.FAQ#L800
2020-03-15 23:11:58 <mps> I see
2020-03-15 23:12:27 <AinNero> this actually makes sense if you build & install it into your homedir
2020-03-15 23:13:43 <mps> but not for distro pkg
2020-03-15 23:15:59 <maxice8> If you need a merge for that fix just ping
2020-03-15 23:16:43 <AinNero> i already built and installed it locally
2020-03-15 23:17:46 <mps> if we are quarantined is it allowed to work on alpine :D
2020-03-15 23:19:01 <mps> this is good excuse to not work
2020-03-15 23:19:04 <AinNero> mps: usually quarantine is at home?
2020-03-15 23:19:47 <mps> yes, I work from home, so I'm long time in quarantine :)
2020-03-15 23:20:27 <AinNero> btw, i just checked other distros
2020-03-15 23:20:49 <mps> and?
2020-03-15 23:20:52 <AinNero> i think that line got copied over, some old AUR's and minor distros also have it
2020-03-15 23:21:21 <mps> aha, I will check debian tomorrow
2020-03-15 23:21:58 <mps> I'm preparing for bed now
2020-03-15 23:22:43 <AinNero> mps: quick link https://sources.debian.org/src/rxvt-unicode/9.22-6/debian/rules/#L18
2020-03-15 23:22:50 <AinNero> not in there
2020-03-15 23:23:12 <mps> you are so fast
2020-03-15 23:23:35 <AinNero> comes from 15 years of real-time gaming experience
2020-03-15 23:25:05 <mps> nmeum: I see you as maintainer of community/rxvt-unicode
2020-03-16 01:29:52 <pixelherodev> Idea for detecting fastest mirror: is there any reason not to set a timeout on mirror detection of the current best time?
2020-03-16 03:44:52 <maxice8> !5460
2020-03-16 09:27:27 <nmeum> mps: yeas I am, anything wrong with urxvt?
2020-03-16 09:27:45 <nmeum> Cogitri: can get a backtrace later, first need to rebuild evince with debugging symbols
2020-03-16 09:28:04 <Cogitri> Okie
2020-03-16 09:28:36 <nmeum> maxice8: do we have a clear policy regarding what should be in main/ and what should be in community/ nowadays?
2020-03-16 09:28:58 <maxice8> Not that I am aware
2020-03-16 09:29:32 <nmeum> maybe it makes sense to discuss this (a main vs. community policy) on the ml then?
2020-03-16 09:29:35 <Cogitri> Sure
2020-03-16 09:29:48 <Cogitri> But I think it basically boils down to: only keep core stuff in main/
2020-03-16 09:29:54 <nmeum> would honestly like to avoid moving stuff abitrarily
2020-03-16 09:30:12 <nmeum> you would have to define "core stuff" then ;)
2020-03-16 09:30:26 <Cogitri> Fair :P
2020-03-16 09:35:58 <mps> nmeum: #11304
2020-03-16 09:36:52 <mps> and !5451
2020-03-16 10:46:22 <maxice8> @nmeum the current arragement in main/ seems pretty arbitrary, imo you need a valid reason to be in main/
2020-03-16 10:46:44 <maxice8> and on top of that, every thing in main basically increases the workload of each maintainer from 6 months (community) to 2 years
2020-03-16 11:28:32 <nmeum> maxice8: I absolutely agree with you. I am just saying, it would be nice to finally establish what "valid reasons to be in main/" are
2020-03-16 11:55:51 <clandmeter> maybe an alternative would be to create an issue with list. also a place to discus "main" ruling.
2020-03-16 13:27:12 <fabled> Cogitri, something like http://sprunge.us/f8ozLI ok for ?
2020-03-16 13:34:32 <Cogitri> I'd very much appreciate if you set me as git author, but other than that that looks fine to me :)
2020-03-16 13:34:43 <Cogitri> Thanks for taking a look
2020-03-16 13:38:00 <fabled> i made quite a number of changes... but how about then something like http://sprunge.us/yRUnIo (changed only commit log portion)
2020-03-16 13:38:32 <fabled> i need to still check if something is broke due to the libapk.so split, e.g. if root test works
2020-03-16 13:39:52 <fabled> actually should rewrite the whole test suite
2020-03-16 15:53:55 <Cogitri> Ah, okay. At least for the things I use libapk for it works (somewhat) well now
2020-03-16 15:54:21 <Cogitri> It's a little annoying how some functions are declared and defined in that header, I had to re-write those in D since libapk doesn't expose them
2020-03-16 15:54:38 <Cogitri> fabled: You can add yourself as co-author to the commit
2020-03-16 16:26:23 <Cogitri> Hm, can I disable ToDo's in the Gitlab UI for CI failures somehow?
2020-03-16 16:26:28 <PureTryOut[m]> Is there anybody that knows anything about blkid here?
2020-03-16 17:07:05 <ncopa> PureTryOut[m]: please ask
2020-03-16 17:31:50 <PureTryOut[m]> Well, udev fails to give me some information on LVM partition that the kpmcore package expects, but it just passes it through from blkid so the problem is somewhere there
2020-03-16 17:33:27 <PureTryOut[m]> eudev passes info from blkid here https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-blkid.c#L209
2020-03-16 17:34:21 <PureTryOut[m]> https://github.com/karelzak/util-linux/blob/master/libblkid/src/probe.c#L1811
2020-03-16 17:58:02 <PureTryOut[m]> Please merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5468 to unblock the builders
2020-03-16 18:06:47 <Cogitri> Sure
2020-03-16 18:26:03 <ncopa> PureTryOut[m]: dunno. may be a regression in eudev?
2020-03-16 18:26:17 <ncopa> Does blkid show the info you are looking for?
2020-03-16 18:32:36 <Cogitri> PureTryOut[m]: Seems like attica has failing tests
2020-03-16 18:56:27 <_ikke_> breeze-icons seems to be missing bash in the makedepends
2020-03-16 19:05:24 <clandmeter> hello everyone
2020-03-16 19:05:34 <clandmeter> its time to make a switch
2020-03-16 19:06:48 <clandmeter> so we will disable push on git.a.o for aports
2020-03-16 19:10:49 <Cogitri> Okie
2020-03-16 19:25:28 <_ikke_> aports @ git.a.o is read-only now
2020-03-16 19:45:17 <clandmeter> looks like mirroring is working
2020-03-16 19:45:27 <clandmeter> _ikke_ is opening the gates
2020-03-16 19:45:59 <clandmeter> please help developers if they bump into remote issues
2020-03-16 19:48:04 <clandmeter> _ikke_: currently stable branches are only open for core group?
2020-03-16 19:49:04 <_ikke_> Just first to test
2020-03-16 19:49:15 <_ikke_> just one step at the time
2020-03-16 19:49:22 <_ikke_> if we see this working we can open it to all develoeprs
2020-03-16 19:49:48 <Cogitri> Okie
2020-03-16 19:49:57 <clandmeter> i wonder if it makes sense to have a separation in this acl
2020-03-16 19:50:08 <_ikke_> algitbot │ aports:master |Kevin Daudt| community/fzf: fix pkgver scheme | http://dup.pw/aports/ba0e76e8
2020-03-16 19:50:12 <_ikke_> that worked :)
2020-03-16 19:50:42 <_ikke_> ok
2020-03-16 19:50:58 <_ikke_> you should now be able to push to gitlab aports master
2020-03-16 19:51:05 <_ikke_> and merge in the webif
2020-03-16 19:52:11 <Cogitri> Yup, just merged dmd via the WebUi
2020-03-16 19:52:21 <_ikke_> \0/
2020-03-16 19:52:24 <Cogitri> Worked fine, thanks infra :)
2020-03-16 19:52:52 <Cogitri> Time to change my scripts to not push to g.a.o I guess
2020-03-16 19:53:30 <_ikke_> hmm https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/67273
2020-03-16 19:53:57 <Cogitri> Maybe because I merged immediately?
2020-03-16 19:54:14 <_ikke_> ah, and that deleted the branch I guess?
2020-03-16 19:54:59 <Cogitri> Maybe?
2020-03-16 19:55:17 <_ikke_> There is an option you can select to delete the source branch on merge
2020-03-16 19:58:50 <Cogitri> Not sure if my script does that to he honest
2020-03-16 20:03:01 <_ikke_> A lot of red on the builders atm
2020-03-16 20:03:29 <Cogitri> Yes
2020-03-16 20:03:52 <Cogitri> Seems like many of the KDE tests aren't happy
2020-03-16 20:04:35 <_ikke_> Did they succeeed in CI?
2020-03-16 20:05:53 <Cogitri> I think so yes
2020-03-16 20:06:01 <Cogitri> It failed on package upload
2020-03-16 20:06:33 <_ikke_> what do you mean?
2020-03-16 20:06:34 <_ikke_> oh
2020-03-16 20:06:37 <_ikke_> right
2020-03-16 20:07:12 <Cogitri> The CI artifcats were too big
2020-03-16 20:07:18 <_ikke_> nod
2020-03-16 20:08:10 <clandmeter> so all is ok?
2020-03-16 20:08:25 <_ikke_> I think so
2020-03-16 20:08:26 <clandmeter> i can go back to being social?
2020-03-16 20:08:27 <Cogitri> I think so, yes
2020-03-16 20:08:40 <_ikke_> I'll enable stable branches as well
2020-03-16 20:08:56 <_ikke_> done
2020-03-16 20:18:57 <clandmeter> _ikke_: thanks for the help :)
2020-03-16 20:19:39 <_ikke_> It's teamwork :)
2020-03-16 21:02:06 <maxice8> @Cogitri i'm working on the scripts
2020-03-16 21:02:34 <maxice8> would be nice if you could do https://github.com/maxice8/mkmr/issues/4 so we can have a CLI tool to merge merge requests
2020-03-16 21:03:00 <Cogitri> Is the "rebasing isn't possible" because the contributor hasn't checked the checkbox to allow contributors to add commits in !5360 ?
2020-03-16 21:03:16 <Cogitri> maxice8: Sounds good
2020-03-16 21:03:38 <maxice8> If you want i can make a 0.0.6 release and you can tell the Alpine Mailing List about it
2020-03-16 21:03:56 <maxice8> it workish enough i guess even though the code is not great
2020-03-16 21:14:08 <Cogitri> Well, is it still functional now that we've changed the origin?
2020-03-16 21:21:35 <maxice8> origin ?
2020-03-16 21:32:16 <mps> what is git command to change origin?
2020-03-16 21:32:46 <maxice8> @Cogitri i think you mean upstream remote
2020-03-16 21:32:47 <mps> and do we need to keep git.a.o in our remote list
2020-03-16 21:32:50 <maxice8> origin remote is always the same to mkmr
2020-03-16 21:33:02 <maxice8> @mps no, it is a mirror, you can fetch from gitlab.a.o all the same
2020-03-16 21:35:07 <mps> tbh, I forgot commands to manipulate this
2020-03-16 21:38:09 <maxice8> git remote set-url upstream https://gitlab.alpinelinux.org/alpine/aports
2020-03-16 21:38:30 <maxice8> git remote set-url upstream --push git@gitlab.alpinelinux.com:alpine/aports.git
2020-03-16 21:40:09 <mps> maxice8: thanks
2020-03-16 21:40:39 <mps> in meantime I edited .git/config and set it by hands, looks like it works
2020-03-16 21:41:02 <maxice8> it should, git config basically does read/write operations in it
2020-03-16 21:41:05 <mps> at top now is community/breeze-icons: make grep call -q instead of --quiet
2020-03-16 21:41:34 <mps> and 'git push origin' now goes to gitlab?
2020-03-16 21:42:30 <maxice8> if you set your remote called 'origin' to gitlab.a.o, yes
2020-03-16 21:42:49 <maxice8> origin should be https://gitlab.alpinelinux.org/mps/aports.git
2020-03-16 21:42:52 <maxice8> the push url should be the ssh equivalent of that
2020-03-16 21:43:00 <maxice8> (that is all assuming you use ssh keys to push)
2020-03-16 21:43:02 <mps> here it is http://tpaste.us/LYEx
2020-03-16 21:43:11 <maxice8> (if you use a personal access token via https:// then have both be https://)
2020-03-16 21:43:38 <maxice8> mps: basically yeah, http://ix.io/2erd
2020-03-16 21:43:45 <mps> no, I want to push same as before
2020-03-16 21:45:10 <mps> maxice8: thanks again, hope I will not make a mess when push something
2020-03-16 21:45:23 <maxice8> push to origin and make a merge request
2020-03-16 21:45:41 <mps> I thought to upgrade thunderbird but will wait day or two
2020-03-16 21:45:44 <maxice8> then you can use the webUI (and in the future you might be able to use mkmr to merge merge requests) to merge it in a safer manner
2020-03-16 21:46:38 <mps> hmm, looks like I will wait some time to see how this all works
2020-03-16 21:46:57 <maxice8> if you wish to push directly you can push to upstream (don't use --force N E V E R)
2020-03-16 21:47:31 <mps> hehe, I remember that --force is banned
2020-03-16 21:48:22 <mps> ah, I see difference in your 'git remote'
2020-03-16 21:49:37 <Cogitri> Force won't do anything anyway
2020-03-16 21:49:47 <Cogitri> Since the Gitlab branches are protected
2020-03-17 03:05:28 <maxice8> gitlab merge requests are apparently a pain to merge
2020-03-17 07:41:07 <Cogitri> Morning everyone
2020-03-17 07:41:19 <_ikke_> morning
2020-03-17 07:52:07 <clandmeter> morning
2020-03-17 07:52:16 <clandmeter> any issues with the switch?
2020-03-17 07:52:29 <clandmeter> maxice8: ?
2020-03-17 07:53:01 <maxice8> No, just very slow if done via webif or API
2020-03-17 07:54:07 <clandmeter> what kind of slow?
2020-03-17 07:54:26 <maxice8> requires rebase after each merge
2020-03-17 07:54:33 <clandmeter> ah ok
2020-03-17 07:54:42 <clandmeter> not in performance slowness
2020-03-17 07:55:01 <maxice8> yes, the performance is fine and will be great for people from the mailing list once i get mkmr out
2020-03-17 07:55:54 <_ikke_> We either have the choice to rebase each mr and properly merge it, or rebase yourself and close the MR
2020-03-17 07:56:02 <_ikke_> that's just how it works
2020-03-17 07:56:28 <_ikke_> or rebase yourself, and force push, if you have the permission
2020-03-17 07:57:18 <maxice8> Already do 1 and 3
2020-03-17 07:57:49 <maxice8> I would like to be able to do them without having to do a rebase step every single time
2020-03-17 07:57:55 <maxice8> GitHub can do Rebase and Merge in a single step
2020-03-17 08:16:15 <mps> tbh, I don't understand anything now :|
2020-03-17 08:22:01 <mps> what means that some of us removed from https://gitlab.alpinelinux.org/alpine/aports/-/project_members list? we don't have rights to push commits to gitlab? or something else
2020-03-17 08:25:39 <clandmeter> we manage the perms in a diff location now
2020-03-17 08:26:37 <_ikke_> mps: note that we manage permissions through groups now
2020-03-17 08:26:49 <_ikke_> So you for example are part of Developers
2020-03-17 08:27:44 <mps> aha, where we can see this
2020-03-17 08:28:54 <_ikke_> https://gitlab.alpinelinux.org/groups/developers/-/group_members
2020-03-17 08:29:42 <mps> I see
2020-03-17 08:30:54 <mps> looks like I have to find time to read more about how gitlab works (which will not happen soon, I think)
2020-03-17 08:31:20 <mps> anyway, thanks for explanation
2020-03-17 08:42:18 <_ikke_> This is a relatively new feature where you can invite groups
2020-03-17 08:42:29 <_ikke_> it makes it easier for us to handle permissions
2020-03-17 10:05:19 <nmeum> Cogitri: re evince: here is a backtrace https://tpaste.us/0Pjd
2020-03-17 10:07:47 <Cogitri> Could you also install glib-dbg please?
2020-03-17 10:07:56 <nmeum> I did
2020-03-17 10:08:09 <nmeum> that's why you see glib function names in the backtrace in the first place
2020-03-17 10:08:12 <nmeum> e.g. g_log_default_handler
2020-03-17 10:08:23 <nmeum> I am investigating this currently
2020-03-17 10:09:10 <Cogitri> Huh, it still shows loads of ?? though 🤔
2020-03-17 10:09:30 <nmeum> yep, no idea why atm
2020-03-17 10:09:54 <nmeum> currently trying to figure out if this is a know issue
2020-03-17 10:10:18 <nmeum> https://gitlab.gnome.org/GNOME/evince/issues/1346
2020-03-17 10:13:33 <nmeum> hm
2020-03-17 10:13:40 <nmeum> which package provides the setting schema org.gnome.desktop.lockdown?
2020-03-17 10:15:28 <nmeum> seems like evinces crashes on purpose because that setting schema is not found
2020-03-17 10:16:36 <Cogitri> It'd log that to the terminal then though
2020-03-17 10:17:14 <Cogitri> `/usr/share/glib-2.0/schemas/org.gnome.desktop.lockdown.gschema.xml is owned by gsettings-desktop-schemas-3.36.0-r0`
2020-03-17 10:17:21 <nmeum> it does log it
2020-03-17 10:17:21 <Cogitri> I'll go ahead and add a dep
2020-03-17 10:17:30 <Cogitri> I guess GNOME pulled that in for me already
2020-03-17 10:17:30 <nmeum> wait a see
2020-03-17 10:17:35 <nmeum> let me test if it works
2020-03-17 10:17:39 <Cogitri> Sure
2020-03-17 10:17:56 <nmeum> I can also add the dep
2020-03-17 10:18:06 <nmeum> will test it and push a fix if it works
2020-03-17 10:19:10 <Cogitri> Or you do that, thanks for debugging it :)
2020-03-17 10:22:01 <nmeum> did we switch the primary host for aports.git to gitlab? :)
2020-03-17 10:22:52 <Cogitri> Yes
2020-03-17 10:23:04 <Cogitri> Did someone not check out the ML? :P
2020-03-17 10:23:19 <nmeum> haha, indeed
2020-03-17 10:23:33 <nmeum> but happy that this finally happend \o/
2020-03-17 10:24:37 <nmeum> ok, pushed the fix. thanks for pointing me to the package :)
2020-03-17 10:32:11 <_ikke_> hmm, it looks like only armhf is responding to builds
2020-03-17 10:32:18 <_ikke_> ncopa: ^
2020-03-17 10:32:27 <_ikke_> I don't see any other arches trying to build atm
2020-03-17 11:18:09 <nmeum> does gitlab currently detect if a MR has been merged and closes it automatically?
2020-03-17 11:18:14 <nmeum> if so: how does it do that?
2020-03-17 11:19:55 <Cogitri> It only detects that if the git sha1 is the same
2020-03-17 11:20:02 <Cogitri> So only if you merge without rebasing
2020-03-17 11:20:15 <nmeum> ah
2020-03-17 11:20:30 <Cogitri> But now you should merge via the WebUI or the API anyway, so it should always show that
2020-03-17 11:21:50 <nmeum> right
2020-03-17 11:26:22 <_ikke_> No, you don't need to merge with the api or webif
2020-03-17 11:26:38 <_ikke_> but if you rebase, you would need to make sure the source branch is updated as well
2020-03-17 11:27:02 <Cogitri> Well, you could apply the patch locally and push to master too, but that's more effort and more error prone
2020-03-17 11:27:20 <Cogitri> (And either rebase the MR before that, or close it yourself afterwards)
2020-03-17 11:27:21 <_ikke_> That's what we have been doing for ages :)
2020-03-17 11:27:40 <Cogitri> Well yes, but we didn't use Gitlab at that time
2020-03-17 11:27:48 <_ikke_> Even with gitlab
2020-03-17 11:28:03 <_ikke_> but what we did not do is make sure the source branch was updated
2020-03-17 11:49:42 <Cogitri> Yup, but I think it's nice when merged stuff is actually marked as merged and not as closed
2020-03-17 11:49:58 <Cogitri> Anyway, there are many way to do it, I suppose :)
2020-03-17 11:50:14 <Cogitri> Hopefully I'll get to working on mkmr soon so interaction with the API will be easier
2020-03-17 11:50:46 <Cogitri> Also, for something completely different: it's not possible to upgrade indiviual packages with apk, is it?
2020-03-17 11:51:45 <_ikke_> I think apk add on the packge should do
2020-03-17 11:52:37 <Cogitri> I'll try that, thanks!
2020-03-17 11:52:49 <_ikke_> Hmm, no, that does not work
2020-03-17 11:53:25 <Cogitri> Ah :/
2020-03-17 11:57:04 <Cogitri> Seems like I can hack around it with the same mechanism `apk upgrade --self-upgrade-only` does
2020-03-17 11:57:47 <ncopa> _ikke_: looks like the other buildres are busy already with some kde stuff
2020-03-17 12:05:43 <_ikke_> ncopa: ah ok
2020-03-17 12:06:10 <_ikke_> I did not check build.a.o
2020-03-17 12:06:15 <_ikke_> just noticed the commit channel
2020-03-17 12:07:33 <Cogitri> I think they might be stuck though?
2020-03-17 12:18:49 <Cogitri> Seems pretty stuck to me
2020-03-17 12:20:02 <mps> Cogitri: individual pkgs upgrade works with 'apk add -u pkgname', and not 'apk upgrade'
2020-03-17 12:20:26 <Cogitri> Ah, thanks :)
2020-03-17 12:20:53 <Cogitri> Somehow I had expected I could just do `apk upgrade $pkgname`
2020-03-17 12:21:05 <_ikke_> kcalendarcore
2020-03-17 12:21:09 <mps> even version, apk add pkgname=ver
2020-03-17 12:21:24 <_ikke_> that would pin it though
2020-03-17 12:21:31 <mps> yes
2020-03-17 12:21:34 <_ikke_> meaing it won't upgrade after that
2020-03-17 12:21:36 <_ikke_> meaning*
2020-03-17 12:22:12 <mps> after pinned, apk add -u pkgname works, iirc
2020-03-17 12:22:52 <Cogitri> Ah yes, I don't want pinning though
2020-03-17 12:23:16 <_ikke_> PureTryOut[m]: Cogitri kcalendarcore seems to hang on tests, can you look at it?
2020-03-17 12:24:33 <PureTryOut[m]> Those are some useless error messages...
2020-03-17 12:25:36 <_ikke_> I can check on the builder
2020-03-17 12:27:11 <_ikke_> I don't see additional logs
2020-03-17 12:27:21 <_ikke_> PureTryOut[m]: but I had to kill the process
2020-03-17 12:27:30 <_ikke_> it was using 100% cpu on one core
2020-03-17 12:35:08 <mps> uh, phones. Cogitri, forgot to tell that the 'apk add -u pkgname' will also upgrade deps for package if they exist
2020-03-17 13:35:27 <ncopa> PureTryOut[m]: the test hangs in my dev env as well
2020-03-17 13:35:46 <ncopa> there are no error message. the test just hangs
2020-03-17 13:35:54 <ncopa> 325/487 Test #325: RecursOn-ConnectDaily1a.ics .........................   Passed    0.03 sec
2020-03-17 13:35:54 <ncopa>         Start 326: RecursOn-ConnectDaily2.ics
2020-03-17 13:36:47 <ncopa> was running pn ppc64le and arm builders for at least 14-16hours
2020-03-17 13:37:18 <PureTryOut[m]> I guess just disable it
2020-03-17 13:46:49 <_ikke_> ncopa: I killed it on x86* already
2020-03-17 14:21:31 <maxice8> for kcalendarcore ?
2020-03-17 14:22:34 <_ikke_> yes
2020-03-17 14:33:57 <ncopa> PureTryOut[m]: do you know how to disable it?
2020-03-17 14:37:39 <PureTryOut[m]> ncopa: afaik it's already been disabled, but you can just look into the package how other tests in there are disabled
2020-03-17 14:45:50 <ncopa> ah, you already did it. thanks
2020-03-17 14:47:11 <PureTryOut[m]> I didn't, maxice8 did
2020-03-17 14:47:13 <PureTryOut[m]> (I don't have the rights)
2020-03-17 15:52:24 <_ikke_> someone needs to properly look at breeze-icons, it keeps failing for all sorts of reasons
2020-03-17 16:20:32 <PureTryOut[m]> The MR got merged too quickly, CI didn't pass yet
2020-03-17 16:20:52 <PureTryOut[m]> I don't have too much time per day atm to look at the failures with much haste
2020-03-17 16:26:12 <_ikke_> I'll take a look at it
2020-03-17 18:27:04 <nmeum> mps: merged the urxvt MR, thanks for pointing that out
2020-03-17 18:27:38 <mps> nmeum: np
2020-03-17 20:21:00 <PureTryOut[m]> ncopa: do you know if the patches to Chromium used in Alpine are being upstreamed?
2020-03-17 20:21:50 <PureTryOut[m]> When updating QtWebengine I basically had to copy the patches used by Chromium, and upstreaming them all would definitely decrease the effort to update those packages
2020-03-17 20:44:16 <maxice8> kcalendarcore is locking up the builders again
2020-03-17 20:45:11 <_ikke_> wasn't that test disabled?
2020-03-17 20:45:30 <maxice8> i thought i did
2020-03-17 20:45:42 <maxice8> turns out RecursOn-ConnectDaily(2|3|6) doesn't work somehow
2020-03-17 20:45:49 <maxice8> i just disabled them outright with !check now
2020-03-17 20:45:59 <maxice8> so if someone resets them it should be ok as the tests won't even run
2020-03-17 20:47:30 <_ikke_> I'm killing the processes now
2020-03-17 20:47:39 <maxice8> ty
2020-03-17 20:47:44 <_ikke_> This should be reported upstream I guess?
2020-03-17 20:50:43 <_ikke_> everything except ppc64le and s390x has been fixed
2020-03-17 20:51:58 <_ikke_> build-edge-s390x is missing from build.a.o
2020-03-17 20:54:30 <_ikke_> PureTryOut[m]: ping
2020-03-17 20:55:09 <PureTryOut[m]> Yeah I'll get to it later, disabling them all for now is fine
2020-03-17 20:55:19 <PureTryOut[m]> (about those tests)
2020-03-17 20:55:39 <_ikke_> This is about breeze
2020-03-17 20:55:50 <_ikke_> I fixed the sed issue with a patch
2020-03-17 20:56:03 <_ikke_> but apparently there are quite some symlinks that are broken (test failure)
2020-03-17 21:06:02 <_ikke_> PureTryOut[m]: I pushed on fix, but the symlink tests will still fail
2020-03-17 21:07:06 <PureTryOut[m]> I'll note again that it shouldn't have been merged yet till CI was green. I'll mark as WIP next time
2020-03-17 21:07:21 <_ikke_> PureTryOut[m]: I totally agree
2020-03-17 21:07:50 <Cogitri> Sorry about that
2020-03-17 22:38:26 <mps> in !5502 I see 'Merge' button, is it safe to click it?
2020-03-17 22:38:58 <maxice8> yes
2020-03-17 22:39:04 <mps> and check 'Delete source branch' is ok
2020-03-17 22:40:02 <mps> looks like it works
2020-03-17 22:40:10 <mps> maxice8: thanks :)
2020-03-17 22:41:11 <mps> and it show 'Merged' and not 'Closed', nice
2020-03-17 22:41:26 <maxice8> That is useful for tracking what got in and what didn't
2020-03-17 22:41:45 <maxice8> which is why i want to merge via the webif and the gitlab API instead of merging locally and closing the MR
2020-03-17 22:49:50 <mps> yes, makes sense
2020-03-17 22:59:51 <maxice8> I can't rebase MRs even from people that grant permission to people that can merge to the target branch
2020-03-17 23:00:03 <maxice8> i can merge my own MRs and Rebase them, so i don't know why i can't do that with other people that allow it
2020-03-17 23:01:53 <mps> I have no idea
2020-03-18 07:19:19 <_ikke_> maxice8: ugh, you just pre-empted me for pushing git :P
2020-03-18 07:19:39 <maxice8> I had an MR open :D
2020-03-18 07:19:56 <_ikke_> heh
2020-03-18 07:53:05 <Cogitri> PureTryOut[m]: Re breeze-icons: https://git.exherbo.org/kde.git/commit/?id=18fcdb4
2020-03-18 07:53:51 <_ikke_> Cogitri: I fixed that one already
2020-03-18 07:54:20 <Cogitri> Oh, okie
2020-03-18 07:54:30 <_ikke_> maxice8: you disabled the symlink test, but does that not mean the package is broken?
2020-03-18 07:54:36 <_ikke_> ie, some icons not working etc
2020-03-18 07:55:17 <maxice8> I don't know, i just don't want to block the builders
2020-03-18 07:55:50 <_ikke_> Soemone should follow up though
2020-03-18 07:56:54 <_ikke_> We run the tests to detect things are broken
2020-03-18 07:57:05 <_ikke_> disabling tests when things are broken defeats the purpose
2020-03-18 08:03:22 <awilfox> what packages are installed by default on a computer with setup-alpine?  it appears that it just installs whatever is in the setup media's /etc/apk/world + acct,linux-vanilla,alpine-base
2020-03-18 08:03:31 <awilfox> but where do I find what is included on the setup media?
2020-03-18 08:04:19 <awilfox> ( I am looking at https://git.alpinelinux.org/alpine-conf/tree/setup-disk.in#n472 )
2020-03-18 08:05:08 <_ikke_> awilfox: https://gitlab.alpinelinux.org/alpine/aports/blob/master/scripts/mkimg.base.sh#L300
2020-03-18 08:05:10 <_ikke_> this?
2020-03-18 08:18:37 <awilfox> _ikke_: yep.  thank you so much
2020-03-18 08:18:54 <_ikke_> np
2020-03-18 08:19:47 <mps> interesting benchmark about io_uring https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-IO-uring-Tests
2020-03-18 08:20:40 <mps> it's a pity we will not have kernel 5.6 in next release
2020-03-18 09:07:58 <maxice8> oh, that does look nice
2020-03-18 09:08:07 <maxice8> mps: i answered your queries on ncurses
2020-03-18 09:10:59 <mps> maxice8: I saw, thanks
2020-03-18 09:12:21 <mps> when I find time today I will again here how I reintroduces  ncurses-termninfo to ncurses
2020-03-18 09:12:40 <mps> s/will/will ask/
2020-03-18 09:12:40 <alpine-meetbot> mps meant to say: when I find time today I will ask again here how I reintroduces  ncurses-termninfo to ncurses
2020-03-18 09:13:59 <mps> now started phone calls from clients about switching them to work from home (because of this hysteria with 'virus')
2020-03-18 10:59:30 <PureTryOut[m]> How do you guys properly keep track of packages you maintain that get new versions?
2020-03-18 11:01:34 <maxice8> Repology
2020-03-18 11:01:50 <maxice8> Each maintainer gets its own RSS/html feed
2020-03-18 11:02:25 <PureTryOut[m]> got a link?
2020-03-18 11:05:59 <_ikke_> https://repology.org/
2020-03-18 11:07:01 <_ikke_> https://repology.org/projects/?search=&maintainer=bribbers%40disroot.org&category=&inrepo=alpine_edge&notinrepo=&repos=&families=&repos_newest=&families_newest=&outdated=on
2020-03-18 11:08:19 <_ikke_> but that is mostly after the fact (relies on someone else already updating the package)
2020-03-18 11:08:28 <_ikke_> for projects that are hosted on github, I subscribe to releases
2020-03-18 11:09:21 <Cogitri> GNOME has a mailing list for releases, I'm subscribed to that
2020-03-18 11:14:50 <PureTryOut[m]> Hmm, repology seems nice, but it doesn't work with non-release version (e.g. git packages)
2020-03-18 11:14:57 <_ikke_> PureTryOut[m]: indeed
2020-03-18 11:15:52 <PureTryOut[m]> Maybe this can be combined with https://release-monitoring.org
2020-03-18 11:16:00 <_ikke_> PureTryOut[m]: I tried to have those excluded in repology, but for some reason the pattern doesn't work
2020-03-18 11:32:53 <PureTryOut[m]> Hmm
2020-03-18 11:35:43 <maxice8> I think repology will be fine for most since nobody is in a run to update stuff so someone else from another distro will update it before
2020-03-18 11:36:08 <PureTryOut[m]> So is it an idea to combine https://release-monitoring for checking upstream releases and https://repology.org for checking Alpine versions into some Alpine page/service with RSS feed?
2020-03-18 11:36:23 <maxice8> And for projects I want to rush to update I use RSS feeds in newsboat
2020-03-18 11:48:32 <mps> I'm subscribed to some upstream MLs, on some upstream irc channels, and look from time to time sites of upstream which I use or care of them
2020-03-18 11:48:57 <mps> sometimes also skim through repology
2020-03-18 11:50:01 <mps> but I do this mostly to see if there are security issues or other problems, not because I want to push new versions
2020-03-18 11:50:50 <mps> reading some news sites also helps
2020-03-18 12:07:28 <Cogitri> PureTryOut[m]: Why would you do that though?
2020-03-18 12:07:39 <Cogitri> Chances are most people only care for the packages they maintain anyway
2020-03-18 12:08:14 <PureTryOut[m]> Sure, so give it a filter to only check for a specified maintainer
2020-03-18 12:09:29 <PureTryOut[m]> It's just that I like to know when a package I maintain gets a new release, and although something like Repology gets close, the fact that you have to wait for a different distribution to update it first makes it not perfect. I think combining it with https://release-monitoring.org would make it perfect
2020-03-18 12:10:13 <PureTryOut[m]> Then again, Repology should probably support that itself
2020-03-18 12:13:47 <PureTryOut[m]> Hmm https://repology.org/repository/alpine_edge/problems
2020-03-18 12:13:53 <PureTryOut[m]> Lots of URL problems
2020-03-18 12:22:25 <AinNero> oh, didnt i take maintainership of tlp?
2020-03-18 12:22:48 <_ikke_> Is maintained by Ivan Tham atm
2020-03-18 12:22:51 <AinNero> pickfire: you werent using tlp anymore, right?
2020-03-18 12:23:09 <pickfire> AinNero: I am still using but not in alpine.
2020-03-18 12:23:40 <pickfire> AinNero: I thought you and another person here took maintainership?
2020-03-18 12:24:04 <AinNero> ill change it the next time i touch the APKBUILD
2020-03-18 12:24:27 <_ikke_> Yeah, last update did not change the maintainer
2020-03-18 12:24:36 <_ikke_> f99d44deac6b54d18a146f09beb727b296250ef7
2020-03-18 12:59:25 <_ikke_> ncopa: build-edge-s390x is missing on msg.a.o..
2020-03-18 13:04:36 <_ikke_> in build.a.o I meant
2020-03-18 13:09:17 <ncopa> ok. let me check that
2020-03-18 13:10:59 <ncopa> looks like its building gnome-keyring
2020-03-18 13:14:24 <ncopa> i think it hanged in gnome-keyring test
2020-03-18 13:23:45 <Cogitri> Oh yes, that got stuck a few days ago on the other builders too
2020-03-18 13:23:52 <Cogitri> I disabled the tests for now since they work locally
2020-03-18 13:57:18 <oneinsect> almost there but need some clarity, why is musl repo https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD making sub-packages?
2020-03-18 13:58:11 <oneinsect> there is case "$BOOTSTRAP" which makes musl-dev and musl-devel-utils?
2020-03-18 13:58:22 <mps> oneinsect: to split tools, dev and etc...
2020-03-18 13:59:04 <oneinsect> hmmm
2020-03-18 14:00:26 <_ikke_> musl is ofcourse special
2020-03-18 14:00:32 <_ikke_> because it needs to be available early
2020-03-18 14:00:40 <mps> you can read APKBUILD, it is shell script
2020-03-18 14:00:51 <_ikke_> mps: yes, but that does not always make the goal clear
2020-03-18 14:01:43 <oneinsect> one final task remaining in my endevour is to replace the musl apkbuild with glibc apkbuild and i am trying to understand what all packages and subpackages musl is building and for what
2020-03-18 14:01:47 <mps> libc is always at the top for bootstrap
2020-03-18 14:03:18 <_ikke_> musl is built in multiple phases
2020-03-18 14:03:44 <oneinsect> yes if I look at bootstrap.sh phase 1 and then phase 2 etc
2020-03-18 14:03:57 <_ikke_> It looks like in the first phase (nocc), it is just packaging the headers
2020-03-18 14:04:22 <_ikke_> the package is musl-dev, it calls make .. install-headers
2020-03-18 14:04:36 <oneinsect> yes required for building gcc (phase 1)
2020-03-18 14:05:03 <oneinsect> then there is also nolibc case
2020-03-18 14:05:23 <_ikke_> Apparently it does not have a subpackage musl-utils then
2020-03-18 14:05:38 <oneinsect> hmmm
2020-03-18 14:05:55 <_ikke_> It does not build getent, getconf and iconv
2020-03-18 14:07:21 <oneinsect> also one more question when I saw subpackages="$pkgname-libintl:libintl:noarch	$pkgname-dev	$pkgname-dbg	libc6-compat:compat:noarch
2020-03-18 14:07:36 <oneinsect> does libintl function get called? in https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD
2020-03-18 14:07:57 <_ikke_> yes, when splitting subpackages, it calls those functions
2020-03-18 14:07:59 <oneinsect> similarly compat() function
2020-03-18 14:08:01 <oneinsect> aha
2020-03-18 14:08:49 <oneinsect> $pkgname-libintl:libintl:noarch ---- how is this interpreted what does the colon stand for like?
2020-03-18 14:08:50 <_ikke_> <pkgname>[[:<function>]:<arch>]
2020-03-18 14:08:53 <_ikke_> ^^
2020-03-18 14:08:58 <oneinsect> aha thanks
2020-03-18 14:10:15 <oneinsect> why does the the pkgdesc="compatibility libraries for glibc" in compat() say glibc?
2020-03-18 14:11:00 <_ikke_> Because that
2020-03-18 14:11:03 <_ikke_> that's what they are?
2020-03-18 14:11:08 <oneinsect> hmmmm
2020-03-18 14:20:12 <oneinsect> okie found https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/glibc but it seems to be dependent on systemd and then this https://github.com/void-linux/void-packages/blob/master/srcpkgs/glibc/template can anyone help me port one of those templates to APKBUILD
2020-03-18 14:21:31 <oneinsect> further there is one more but not as complete as above https://raw.githubusercontent.com/sgerrand/alpine-pkg-glibc/master/APKBUILD which in turn uses the builder artifacts from https://raw.githubusercontent.com/sgerrand/docker-glibc-builder/master/builder
2020-03-18 14:39:26 <oneinsect> so any help?
2020-03-18 14:50:47 <oneinsect> ooh my god, these glibc templates suck so bad, taking a look at gentoo openrc https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.31-r1.ebuild
2020-03-18 15:44:24 <crashoverride> does alpine support Xorg running under xen?
2020-03-18 15:44:26 <crashoverride> or not yet?
2020-03-18 15:46:48 <ncopa> i guess the correct answer is not yet. i dont think any developers has tested it
2020-03-18 15:48:17 <crashoverride> I know I have tried it like years ago
2020-03-18 15:48:19 <crashoverride> and it didn't work
2020-03-18 15:48:41 <crashoverride> ok so aside from docker and manual jailing, what else can I use to run processes in another context?
2020-03-18 15:48:46 <crashoverride> does qemu work?
2020-03-18 15:48:57 <crashoverride> I guess with kvm?
2020-03-18 15:49:05 <_ikke_> What's the usecase?
2020-03-18 15:49:14 <crashoverride> virtualizing anything I guess
2020-03-18 15:49:15 <_ikke_> And what do you want to protect against?
2020-03-18 15:49:16 <crashoverride> not sure yet.
2020-03-18 15:49:21 <crashoverride> it's local dev.
2020-03-18 15:49:28 <crashoverride> I won't need X in a remote env.
2020-03-18 15:49:33 <crashoverride> so then it'll be Xen
2020-03-18 15:49:44 <crashoverride> or, you know, "the cloud"(tm)
2020-03-18 15:49:53 <ncopa> i use qemu with kvm on my desktop
2020-03-18 15:49:57 <crashoverride> ok
2020-03-18 15:50:02 <_ikke_> s/the cloud/someone else's computer/
2020-03-18 15:50:08 <ncopa> with virt-manager
2020-03-18 15:50:08 <crashoverride> I'm assuming "deskop" means X here ;)
2020-03-18 15:50:18 <crashoverride> _ikke_: indeed.
2020-03-18 15:50:20 <ncopa> yup. X with xfce
2020-03-18 15:50:25 <crashoverride> ncopa: perfect.
2020-03-18 15:50:36 <crashoverride> so I can just install normal alpine, and use either docker or qemu
2020-03-18 15:50:39 <AinNero> im using blank qemu with kvm alot
2020-03-18 15:50:41 <crashoverride> perfect, thanks a bunch.
2020-03-18 15:50:53 <crashoverride> I won't waste time with jails, it's not like it's OpenBSD :P
2020-03-18 15:51:04 <ncopa> :)
2020-03-18 15:51:18 <crashoverride> k guys, have a nice one, bis spaeter.
2020-03-18 15:52:46 <oneinsect> why does life have to be so painful
2020-03-18 15:53:46 <crashoverride> oneinsect: pain is weakness leaving the body. Just stop being week.
2020-03-18 15:53:56 <crashoverride> 
ACTION shows himself the door.

2020-03-18 15:53:59 <oneinsect> lol
2020-03-18 15:54:18 <oneinsect> glibc is the weakness
2020-03-18 15:54:50 <oneinsect> its refusing to leave nor enter properly
2020-03-18 15:56:16 <oneinsect> also why does the linux-headers package depend on perl and rync? w
2020-03-18 15:56:57 <oneinsect> https://git.alpinelinux.org/aports/tree/main/linux-headers/APKBUILD
2020-03-18 15:58:25 <oneinsect> makedepends="perl rsync" any thoughts?
2020-03-18 15:58:38 <_ikke_> no idea myself :)
2020-03-18 15:58:41 <_ikke_> maybe try building it
2020-03-18 15:59:47 <oneinsect> darn perl was once a dependency but i guess that was slowly removed! i will try
2020-03-18 16:02:06 <mps> oneinsect: because they are needed to build it
2020-03-18 16:02:28 <mps> no, kernel still depends on perl to build
2020-03-18 16:03:27 <mps> I found patches to remove perl deps for kernel but not sure if they should be add to alpine aports
2020-03-18 16:04:43 <clandmeter> and rsync?
2020-03-18 16:05:57 <mps> no, didn't found anything to remove rsync deps, though must say that I'm not searched
2020-03-18 16:06:19 <clandmeter> https://git.alpinelinux.org/aports/commit/main/linux-headers/APKBUILD?id=b0de7d61ddb7a3a48d97277449e888c69dcc478c
2020-03-18 16:06:48 <mps> but looked how it works and think it could be hacked with some shell tricks, maybe
2020-03-18 16:06:53 <clandmeter> the info why its added is not added.
2020-03-18 16:07:13 <mps> really, so I forgot that
2020-03-18 16:07:43 <clandmeter> it says that its added to makedepends, which you obviously can see :)
2020-03-18 16:08:24 <mps> better anything than nothing :)
2020-03-18 16:08:44 <_ikke_> hence that it's more important to add why then what :)
2020-03-18 16:09:30 <mps> ehm, we should finally decide are we for more verbose commit msgs or we are favor minimal
2020-03-18 16:09:51 <_ikke_> I'm for informative commit messages :)
2020-03-18 16:09:52 <clandmeter> verbose is always better
2020-03-18 16:10:17 <clandmeter> this is useless. sorry no offence intended.
2020-03-18 16:10:22 <Cogitri> Yes, but the extra info has to be useful
2020-03-18 16:10:24 <clandmeter> ive done it too
2020-03-18 16:10:43 <_ikke_> If it's a simple upgrade, no need to explain it
2020-03-18 16:10:57 <_ikke_> no need to reiterate every change
2020-03-18 16:11:05 <clandmeter> sometimes you also see. disable build due to build failure.
2020-03-18 16:11:06 <_ikke_> Focus on why, rather than what
2020-03-18 16:11:17 <_ikke_> I always add the specific build failure as well
2020-03-18 16:13:40 <oneinsect> https://www.youtube.com/watch?v=O_wcpXF5ZRY as per that talk he removed perl dependencies
2020-03-18 16:14:00 <oneinsect> for linux kernel compilation
2020-03-18 16:14:13 <_ikke_> Ah, Rob Landley
2020-03-18 16:14:15 <mps> little contemplation and I come that the 'add rsync to makedepends' obvious. it means that rsync is needed
2020-03-18 16:15:40 <oneinsect> i mean Rob Landley did substantial work to make linux kernel compilation perl free
2020-03-18 16:16:16 <oneinsect> he had said many times, we had to fight ages to get that mind set out
2020-03-18 16:16:37 <oneinsect> and why rync and what does rync exactly do?
2020-03-18 16:16:41 <oneinsect> in that apkbuild
2020-03-18 16:17:03 <_ikke_> Well, the APKBUILD itself is not using it
2020-03-18 16:17:07 <mps> rsync is used in kernel Makefile
2020-03-18 16:17:09 <_ikke_> so it must be something in the build system that uses it
2020-03-18 16:17:12 <oneinsect> ooooh
2020-03-18 16:18:22 <mps> I thin kisslinux have patches or sed script to remove perl from build deps of kernel
2020-03-18 16:20:47 <oneinsect> one more question why have a libc-dev package for just 4 headers and how does it pull in the correct libc https://git.alpinelinux.org/aports/tree/main/libc-dev/APKBUILD
2020-03-18 16:21:36 <dalias> ?
2020-03-18 16:22:09 <dalias> that package is poorly named and probably a remnant of uclibc
2020-03-18 16:22:24 <mps> it is metapackage
2020-03-18 16:22:38 <mps> apk info -r libc-dev
2020-03-18 16:22:44 <dalias> what it actually does is provide some legacy bsd headers that are entirely standalone and have nothing to do with libc
2020-03-18 16:23:00 <mps> sorry
2020-03-18 16:23:07 <mps> apk info -R libc-dev
2020-03-18 16:23:24 <_ikke_> The only thing it pulls in is $LIBC-utils
2020-03-18 16:23:49 <dalias> and musl-dev
2020-03-18 16:24:15 <_ikke_> right
2020-03-18 16:24:26 <_ikke_> missed that one
2020-03-18 16:24:43 <mps> dalias: imagine someone new to musl distro who want to install libc-dev as on glibc distro
2020-03-18 16:26:19 <mps> and a lot of posts on reddit, twiter, SO with messages like this: alpine is bad distro, they don't have even basic as libc-dev
2020-03-18 16:26:43 <oneinsect> i mean it is required by packages like build-base, g++ etc as per https://pkgs.alpinelinux.org/package/edge/main/x86/libc-dev
2020-03-18 16:26:54 <oneinsect> almost 10 packages depend on it
2020-03-18 16:26:56 <dalias> mps, i dont think it's bad for libc-dev to exist
2020-03-18 16:27:07 <dalias> but i think the contents are wrong for what it is
2020-03-18 16:27:22 <dalias> libc-dev should be purely a metapackage pulling in musl-dev and possibly other essentials
2020-03-18 16:27:29 <mps> ah, you mean description
2020-03-18 16:27:39 <dalias> not the package containing these bsd header-only libraries
2020-03-18 16:28:45 <mps> I don't think it contains headers, it is empty. 'apk info -R libc-dev' => musl-dev
2020-03-18 16:29:05 <oneinsect> but i see headers here
2020-03-18 16:29:06 <oneinsect> https://git.alpinelinux.org/aports/tree/main/libc-dev?h=master
2020-03-18 16:29:14 <dalias> mps, look at the actual APKBUILD & dir
2020-03-18 16:29:40 <dalias> it contains bsd header-only libraries that glibc & uclibc ship with libc
2020-03-18 16:29:46 <_ikke_> it's in a bsdcompat sub package
2020-03-18 16:29:58 <_ikke_> bsd-compat-headers
2020-03-18 16:30:16 <oneinsect> why have glibc or uclibc bsd-compact-headers?
2020-03-18 16:30:46 <_ikke_> oneinsect: alpine used to use uclibc before 3.x
2020-03-18 16:31:03 <mps> dalias: it install sgidefs.h for mips
2020-03-18 16:31:25 <oneinsect> strangely libc-utils is required by packages like abuild, alpine-base which i doubt even use those
2020-03-18 16:32:08 <_ikke_> alpine-base makes sure it's installed by default
2020-03-18 16:32:09 <oneinsect> this is confusing for someone new like me who hasnt been with the journey of Alpine
2020-03-18 16:32:57 <_ikke_> abuild uses getent
2020-03-18 16:33:08 <oneinsect> aha
2020-03-18 16:33:08 <_ikke_> so it needs libc-utils (musl-utils)
2020-03-18 16:33:25 <_ikke_> alpine-base also makes sense. It means any system has getent / getconf / iconv
2020-03-18 16:33:39 <_ikke_> (alpine-base is a metapackage)
2020-03-18 16:34:29 <oneinsect> both libc-utils and libc-dev point to the same git repo
2020-03-18 16:34:44 <oneinsect> how are they different then?
2020-03-18 16:34:44 <_ikke_> libc-utils is a subpackge of libc-dev
2020-03-18 16:34:56 <_ikke_> and libc-utils is a metapackage, pulling in musl-utils
2020-03-18 16:35:06 <_ikke_> same for libc-dev, pulling in musl-dev
2020-03-18 16:35:15 <oneinsect> okie understood and bsd-compat-headers also points to the same git as above
2020-03-18 16:35:39 <_ikke_> Look at the origin field in pkgs.a.o
2020-03-18 16:38:35 <oneinsect> yeaaa but why have so many subpackages, metapackages, different names
2020-03-18 16:38:43 <oneinsect> cant we simply these?
2020-03-18 16:38:59 <_ikke_> subpackages keep things small
2020-03-18 16:39:09 <oneinsect> simplify*
2020-03-18 16:39:19 <_ikke_> metapackages allows us to change things without having to change it everywhere
2020-03-18 16:39:48 <_ikke_> things can pull in libc-dev without having to know what libc library we use
2020-03-18 16:40:01 <oneinsect> aha
2020-03-18 16:43:52 <_ikke_> Depending what you need to achieve, you could just creates a 2nd LLD rule that discovers all of the sub items
2020-03-18 16:44:28 <_ikke_> ie, one LLD rule that would discover directories, another that discovers all files in those directories
2020-03-18 16:44:43 <oneinsect> well i am trying to understand how to replace musl and trying to understand if packages libc-dev etc are needed for it
2020-03-18 16:44:49 <_ikke_> uups
2020-03-18 16:44:51 <_ikke_> wrong chat
2020-03-18 16:44:56 <oneinsect> :-D
2020-03-18 16:45:46 <_ikke_> oneinsect: it's needed later
2020-03-18 16:46:08 <_ikke_> but you can just build it with the correct CLIBC env variable set
2020-03-18 16:47:28 <oneinsect> i have figure out 53 packages are built as core packages but then those 53 packages have other make dependencies which abuild -r probably does a recursive build but then i need to find all those and replace with glibc
2020-03-18 16:47:32 <oneinsect> figured*
2020-03-18 16:47:55 <_ikke_> abuild -r is not recursive
2020-03-18 16:47:59 <oneinsect> oooh
2020-03-18 16:48:30 <_ikke_> tools like buildrepo can help you to recursively build packages in the right order
2020-03-18 16:49:10 <oneinsect> https://github.com/alpinelinux/aports/blob/master/scripts/bootstrap.sh ---there is a for loop for ordered cross-build, how does abuild then figure out say linux-headers depend on perl and build perl first?
2020-03-18 16:49:26 <oneinsect> perl is not listed in the ordered cross build
2020-03-18 16:50:32 <_ikke_> oneinsect: I assume they use existing rsync / perl
2020-03-18 16:50:49 <oneinsect> oooh my god!
2020-03-18 16:51:59 <_ikke_> bootstrapping from scratch is really hard :)
2020-03-18 16:52:20 <oneinsect> i have dedicated chroot of alpine with only glibc, gcc, binutils ready to build rest of system but then i have figure which one first to build since this chroot does have perl itself
2020-03-18 16:52:22 <_ikke_> but it would not matter if you use perl / rsync based on musl
2020-03-18 16:52:34 <oneinsect> not*
2020-03-18 16:52:35 <_ikke_> does or does not?
2020-03-18 16:52:36 <_ikke_> right
2020-03-18 16:53:13 <oneinsect> this is getting crazier day by day... i fear i may loose my mind eventually
2020-03-18 16:53:15 <oneinsect> :-D
2020-03-18 16:55:50 <oneinsect> ooh lord save _ikke_: and others from the wrath of glibc systems in future!
2020-03-18 19:17:30 <AinNero> maxice8: MR updated
2020-03-18 19:28:06 <maxice8> @AinNero: thanks, could you make your fork of aports public, i can't automatically rebase it if it is an internal project
2020-03-18 19:28:28 <_ikke_> He couldn't
2020-03-18 19:28:55 <maxice8> @ikke: sorry but i'll be bothering you a lot with requests to publicize repos :D
2020-03-18 19:29:08 <AinNero> yes i cant
2020-03-18 19:29:17 <AinNero> maxice8: cant you grab a ref via my MR?
2020-03-18 19:29:42 <maxice8> i can push it manually but then the MR will be closed, not merged and thus we can't track which MRs were merged via the merged status
2020-03-18 19:29:54 <maxice8> Before we switched to gitlab as canonical repository i would do that
2020-03-18 19:30:03 <maxice8> https://github.com/maxice8/meltryllis/blob/master/bin/mgmr
2020-03-18 19:30:38 <_ikke_> it's public now
2020-03-18 19:35:03 <maxice8> thanks :D
2020-03-18 20:36:11 <mps> built linux-header without perl makedeps with patch from https://k1ss.org/dist/kernel-no-perl.patch
2020-03-18 20:36:43 <mps> ncopa: what you think about it? should we add it?
2020-03-18 20:38:32 <Cogitri> Do we really need to patch our kernel for that? Is Perl such a problem?
2020-03-18 20:43:34 <mps> Cogitri: I don't think strongly that we need it removed but some people expressed idea to remove perl and rsync from makedepends
2020-03-18 20:46:51 <Cogitri> Well, if it makes bootstrapping easier then it might be worth it, but I think we need Perl during bootstrap anyway, don't we?
2020-03-18 20:48:30 <mps> never seriously tried to bootstrap anything (just played few times)
2020-03-18 20:50:12 <Cogitri> I can recommend doing a LFS system once for fun, was pretty interesting
2020-03-18 20:50:17 <Cogitri> (And also frustrating at times)
2020-03-18 20:50:27 <Cogitri> And when you do it in a chroot you can trash it at any time
2020-03-18 20:51:00 <mps> that is what I did about two decades ago, and now I can't find fun it :)
2020-03-18 20:51:45 <mps> from lilo, kernel, libc, gcc ....
2020-03-18 20:52:02 <mps> now I even don't like to talk about it
2020-03-18 20:52:59 <mps> and, about 30 years ago I made even primitive OS for 6502 cpu
2020-03-18 20:53:56 <mps> it had just few drivers, screen, keyboard, serial and parallel port and raw floppy FS
2020-03-18 20:54:45 <mps> but then I was too young and without experience :)
2020-03-18 20:56:16 <AinNero> maxice8: thanks
2020-03-18 21:06:38 <maxice8> AinNero: welcome
2020-03-18 21:19:14 <maxice8> @ikke please make public https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5540
2020-03-18 21:20:31 <_ikke_> done
2020-03-18 21:20:39 <maxice8> thanks! :D
2020-03-18 21:39:08 <maxice8> @ikke: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5558
2020-03-19 07:22:34 <maxice8> gitlab v4 api allows rebasing a merge request with skip_ci
2020-03-19 07:22:39 <maxice8> which won't create a new CI pipeline
2020-03-19 07:22:50 <_ikke_> hmm, interesting
2020-03-19 07:22:58 <maxice8> https://docs.gitlab.com/ee/api/merge_requests.html#rebase-a-merge-request
2020-03-19 07:26:46 <_ikke_> Maybe would do something based on labels
2020-03-19 07:26:50 <_ikke_> some automation
2020-03-19 07:27:18 <maxice8> I'm going to start writing mgmr (for mkmr) in a few hours
2020-03-19 07:27:41 <maxice8> it will basically be a poor's man GitLab-EE's merge train
2020-03-19 07:29:42 <_ikke_> Please do build in some kind of delay or something to give others also a change to get things merged
2020-03-19 07:29:53 <_ikke_> s/change/chance
2020-03-19 07:29:53 <alpine-meetbot> _ikke_ meant to say: Please do build in some kind of delay or something to give others also a chance to get things merged
2020-03-19 07:30:54 <maxice8> that will be a terrible experience enough already even without a random delay
2020-03-19 07:31:38 <_ikke_> yes, but can you also imagine the frustration of someone else trying to merge something but keeps getting pre-empted/
2020-03-19 07:32:03 <maxice8> That will happen regardless if they use my cli or not
2020-03-19 07:32:20 <maxice8> it is just a fact of 2 or more people trying to merge into a single codebase
2020-03-19 07:32:26 <_ikke_> Of course
2020-03-19 07:32:47 <maxice8> A fix would have a merge-request-bot that you would write something like a comment saying to merge and it would add into a global merge queue
2020-03-19 07:32:50 <_ikke_> I was thinking of using labels to mark things ready for merge
2020-03-19 07:33:02 <_ikke_> and then automate the rebase + merging
2020-03-19 07:33:10 <_ikke_> yes
2020-03-19 07:33:21 <_ikke_> labels would be suitable for that
2020-03-19 07:33:42 <maxice8> in  my research previously i found this https://github.com/smarkets/marge-bot
2020-03-19 07:37:39 <maxice8> I planned on packaging it but the dependency 'maya' leads down to a fun rabbit hole of dependency upon dependency
2020-03-19 07:38:50 <_ikke_> fun
2020-03-19 07:54:45 <_ikke_> maxice8: Checksum failure for etcd on s390x
2020-03-19 07:55:14 <_ikke_> and other arches
2020-03-19 07:57:04 <maxice8> oops
2020-03-19 07:57:17 <maxice8> $pkgname.yaml fetches from a versioned source but isn't versioned itself
2020-03-19 07:57:27 <maxice8> sounds like a recipe for disaster
2020-03-19 07:58:55 <oneinsect> be right back
2020-03-19 08:04:11 <_ikke_> maxice8: another error :-)
2020-03-19 08:06:31 <mps> new mesa release with fixes https://lists.freedesktop.org/archives/mesa-dev/2020-March/224277.html
2020-03-19 08:07:21 <maxice8> feel free to update it, i tried it late yesterday and the source= was sleeping instead of transferring me the tarball
2020-03-19 08:08:43 <maxice8> plus i'm focused on mgmr :D
2020-03-19 08:09:35 <mps> I don't have time (sorry). because that I posted here if someone have time to look at it. but I'm in hurry for new release, current work enough good, so easy :)
2020-03-19 08:10:13 <mps> i'm not in hurry* (except when type :) )
2020-03-19 08:10:36 <_ikke_> maxice8: options="chmod-clean" :)
2020-03-19 08:11:56 <maxice8> etcd is trying to f with me, i'll qualify that it passed CI because it didn't have the first and last problems (1st and 3rd)
2020-03-19 09:02:22 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5575
2020-03-19 09:02:26 <maxice8> first MR merged with my new mgmr :D
2020-03-19 09:02:57 <_ikke_> aaaand build failures :D
2020-03-19 09:03:47 <maxice8> :D can't be perfect
2020-03-19 09:17:37 <Cogitri> lol
2020-03-19 11:34:09 <maxice8> @ikke: https://github.com/maxice8/mkmr/pull/24/files
2020-03-19 12:28:23 <timlegge> Anyone around to look at MR35 on abuild?  Its a number of fixes to apkbuild-cpan I also have MR37 which moves it to use the metacpan API just undecided about merging it into apkbuild-cpan or creating a ne apkbuild-mcpan
2020-03-19 12:28:35 <timlegge> I suspect merging is best
2020-03-19 12:29:36 <_ikke_> ncopa maintains abuild
2020-03-19 12:29:43 <mps> timlegge: yes, merge is better
2020-03-19 12:30:31 <mps> I started to fix it with metacpan API year ago but never finished. Thanks for your work
2020-03-19 12:31:33 <timlegge> no prob
2020-03-19 13:15:46 <oneinsect> can I please borrow a hammer from someone, glibc is acting up!
2020-03-19 14:53:43 <Thermi> Where do I report issues with busybox to?
2020-03-19 14:55:48 <Cogitri> Depends
2020-03-19 14:56:07 <Cogitri> If we configured it wrong then on gitlab.alpinelinux.org/alpine/aports/issues
2020-03-19 14:56:20 <Cogitri> If upstream did it wrong then on whatever bug tracker they use
2020-03-19 14:56:27 <Cogitri> If in doubt open an issue on our Gitlab
2020-03-19 15:03:47 <Thermi> Problem is that rm'ing in a docker container a directory with multiple subdirs and files that is on a volume fails because it does not correctly iterate over the files and attempts to remove directories with files in it, which fails
2020-03-19 15:19:17 <Thermi> Looks like that: rm: can't remove '/home/buildozer/aports/main/gcc/src/gcc-9.2.0/libgo/go/cmd/go/testdata/script': Directory not empty
2020-03-19 16:24:13 <ncopa> im gonna test tag an edge snapshot
2020-03-19 16:24:25 <_ikke_> alright
2020-03-19 16:25:49 <ncopa> tag was not synced
2020-03-19 16:26:19 <ncopa> hum, maybe it was
2020-03-19 16:29:34 <_ikke_> refs/tags/v20200319
2020-03-19 16:29:42 <_ikke_> that was from git.a.o
2020-03-19 16:34:41 <ncopa> yeah
2020-03-19 19:42:03 <Cogitri> ikke: Please make this public: https://gitlab.alpinelinux.org/optix2000/aports
2020-03-19 19:42:46 <_ikke_> done
2020-03-19 19:43:03 <Cogitri> Thanks
2020-03-19 21:23:52 <timlegge> not sure if you guys saw that as part of development/testing the snmp for power I made  https://github.com/timlegge/docker-snmpsim-openDCIM
2020-03-19 21:25:31 <timlegge> It is avaiable as a docker container from https://hub.docker.com/r/timlegge/docker-snmpsim-opendcim and allows you to use a simulator for a number of openDCIM related peices of hardware
2020-03-19 21:26:03 <timlegge> Includes, switches, PDU, XFer switches, temperature sensors, etc
2020-03-19 21:29:13 <timlegge> Might be useful combined with the demo site to show how snmp functionality works for multiple hardware types if you don't alread have something in place
2020-03-19 21:38:48 <Cogitri> That...sounds complex
2020-03-19 21:49:30 <timlegge> oof wron channel :-)
2020-03-19 21:49:38 <timlegge> oops wrong...
2020-03-19 21:49:56 <_ikke_> ha!
2020-03-19 21:50:58 <timlegge> I really like Quassel for but it is a lot easier to choose the wrong channel
2020-03-19 21:51:21 <timlegge> s/for but/for irc but/
2020-03-19 21:51:21 <alpine-meetbot> timlegge meant to say: I really like Quassel for irc but it is a lot easier to choose the wrong channel
2020-03-19 22:45:00 <maxice8> @ikke: please make public https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5604 :D
2020-03-19 23:27:12 <timlegge> updated a couple of older APKBUILDS in !5605 including some bsd licence strangeness that you may want to review
2020-03-19 23:30:06 <maxice8> I'll take a look later
2020-03-19 23:44:12 <timlegge> thanks
2020-03-20 02:36:23 <andypost[m]> "No space left on device" CI s390x https://gitlab.alpinelinux.org/andypost/aports/-/jobs/69744
2020-03-20 05:31:06 <_ikke_> Cogitri: gdnsd test suite is using 154G of data :-/
2020-03-20 06:32:24 <Cogitri> _ikke_: Ah, I don't think you meant to ping me though?
2020-03-20 06:34:48 <_ikke_> I found it under your namespace on the CI hosts
2020-03-20 06:35:05 <Cogitri> Huh
2020-03-20 06:35:06 <Cogitri> I didn't build that though
2020-03-20 06:35:16 <_ikke_> hmm
2020-03-20 06:39:27 <_ikke_> Seems like CI build was building too much
2020-03-20 06:39:35 <_ikke_> There were jobs running for 10h
2020-03-20 06:50:29 <Cogitri> Oh :/
2020-03-20 08:46:54 <_ikke_> Cogitri: I received your mail on the mailing list perfectly fine
2020-03-20 08:51:10 <Cogitri> Nice
2020-03-20 08:52:35 <Cogitri> Protonmail's bridge is broken once again so I can't do IMAP/SMTP :c
2020-03-20 08:52:57 <Cogitri> I'm really thinking about switching everything over to my own mailing server now, but I think maintaining a mail server isn't that much fun
2020-03-20 08:53:10 <_ikke_> I've been maintaining one for years
2020-03-20 08:53:30 <_ikke_> You need a good spam filter
2020-03-20 08:54:42 <Cogitri> Oh, that makes me more hopeful
2020-03-20 08:55:10 <_ikke_> I've setup SPF records
2020-03-20 08:55:20 <_ikke_> but not a lot more
2020-03-20 08:57:08 <Cogitri> Neat
2020-03-20 08:57:47 <mps> Cogitri: what _ikke_ says, and I maintain personal mail server for year, not much hard once you setup it
2020-03-20 08:58:24 <mps> postfix, postgrey, dovecot is all I use
2020-03-20 08:58:26 <_ikke_> Cogitri: just make sure you are not an open relay :)
2020-03-20 08:58:58 <TBK[m]> I have also been hosting my own mailserver for a decade+ currently I use
2020-03-20 08:58:58 <TBK[m]> mailcow-dockerized with spf, dkim and dmarc records
2020-03-20 09:00:39 <Cogitri> Well, I think I'm general pretty afraid of doing something wrong during setup and leaving some open door for hackers
2020-03-20 09:01:20 <mps> ah, yes, spf and dkim, I forgot them. long time I set them and they 'evaporated'
2020-03-20 09:01:52 <mps> 'closing' relaying is not hard
2020-03-20 09:01:54 <_ikke_> Cogitri: Just try to test your setup
2020-03-20 09:02:48 <Cogitri> Ah?
2020-03-20 09:03:08 <_ikke_> Just try to connect to your mailserver and see if it allows you to send e-mails to other domains
2020-03-20 09:03:48 <_ikke_> Cogitri: there are also online tools that can test your mail setup
2020-03-20 09:04:00 <mps> only if you send bulk mail (spammers pays you) you can have issues with big mail providers (google, yahoo ...)
2020-03-20 09:04:36 <TBK[m]> I recommend using some service to monitor your ip/domain for blacklisting
2020-03-20 09:06:40 <mps> 
ACTION wonders when see competent people with gmail.com (or similar) mail address

2020-03-20 09:13:53 <markand> Cogitri, opensmtpd is literally several lines
2020-03-20 09:13:57 <markand> of configuration
2020-03-20 09:14:48 <markand> in france we also have some DNS providers that offer mailboxes for free when you buy a domain name (gandi.net)
2020-03-20 09:15:05 <markand> so you can have your very own mail address without having to setup a mail server
2020-03-20 09:16:38 <mps> markand: though I'm user of gandi for years and can use their mail servers, I still prefer to run my own
2020-03-20 09:17:17 <markand> me too
2020-03-20 09:33:18 <mps> Ariadne: -1 for proposal about iproute2
2020-03-20 09:33:37 <Ariadne> why?
2020-03-20 09:34:21 <mps> because bb iproute is enough for most use cases
2020-03-20 09:34:21 <Ariadne> have you audited busybox iproute2
2020-03-20 09:35:07 <mps> following your reasoning we will add a lot of 'better' pkgs
2020-03-20 09:35:37 <markand> recent versions of iproute2 breaks openconnect btw
2020-03-20 09:35:56 <Ariadne> does openconnect even work on alpine
2020-03-20 09:36:45 <mps> markand: yes, any software useful without bugs is illusion (except maybe djbdns)
2020-03-20 09:37:09 <mps> markand: yes, any useful software without bugs is illusion (except maybe djbdns)
2020-03-20 09:37:10 <markand> :-)
2020-03-20 09:38:41 <Ariadne> busybox iproute2 only works for configuring addresses and routes
2020-03-20 09:38:47 <Ariadne> real iproute2 can replace many utilities
2020-03-20 09:38:53 <Ariadne> with a consistent interface
2020-03-20 09:39:52 <mps> I think we all know differences between bb iproute and iproute2
2020-03-20 09:39:58 <Ariadne> so while your -1 is noted, i really don't give a flying fuck about it as it's not justified
2020-03-20 09:40:35 <mps> you asked in ML about opinion, and post it here
2020-03-20 09:41:03 <Ariadne> and you can reply with a full justification of why you believe so on the ML
2020-03-20 09:41:08 <Ariadne> or you can get the fuck out of this project
2020-03-20 09:41:24 <Ariadne> simple as that
2020-03-20 09:41:26 <mps> hmm, please stop with this
2020-03-20 09:41:49 <Cogitri> Yes, let's please not get offensive here
2020-03-20 09:44:16 <Ariadne> i asked for opinions submitted via the ML
2020-03-20 10:03:20 <ncopa> Ariadne: please calm down
2020-03-20 10:04:58 <Ariadne> i am perfectly calm, but did not ask for IRC discussion, but instead ML discussion.
2020-03-20 10:05:25 <Ariadne> it does not matter, there is no consensus for the change
2020-03-20 10:29:52 <Ariadne> mps: I am quite serious by the way.  no more of this coming into IRC to comment on things.  if you have something to say, you can send it to the ML like everyone else.  I will be ignoring anything you send to IRC that should be on the ML.
2020-03-20 10:30:51 <Ariadne> until such time that the ML is replaced with something else, ML conversations should be done on the ML.
2020-03-20 10:32:22 <mps> you are not one who will tell me how I will communicate
2020-03-20 10:43:03 <Cogitri> I do feel like decision making shouldn't be done on the IRC though since that's very hard to backtrack
2020-03-20 10:45:31 <_ikke_> And it's not widely visible
2020-03-20 10:45:46 <Cogitri> Yup
2020-03-20 10:46:11 <TBB> exactly. irc is good for discussion but it should lead to condensed documentation in another medium
2020-03-20 11:00:11 <ncopa> I agree that important decisions should be discussed on ML, til we have replaced it with other medium
2020-03-20 11:08:23 <mps> hmm, anyone counted number of their words/sentences about serious things/decisions on IRC and ML
2020-03-20 11:11:48 <AinNero> ML should be first class for decision making
2020-03-20 11:12:04 <AinNero> not everyone lives in a western timezone
2020-03-20 11:23:56 <ncopa> AinNero: good point
2020-03-20 11:25:33 <ncopa> I understand that ML is not ideal for everyone, but that is what we have for now, so I ask that we use that.
2020-03-20 11:26:37 <_ikke_> The ML also has a low barier of entry
2020-03-20 11:31:22 <ncopa> my screen is flickering and X hangs every second or third minute
2020-03-20 11:31:47 <ncopa> i can un-hang it by switch to framebuffer console and back to xorg
2020-03-20 11:32:05 <ncopa> i don tknow if it is due to regression in recent kernel or due to chromium
2020-03-20 11:32:13 <ncopa> but its a bit annoying
2020-03-20 11:32:36 <maxice8> Using an intel GPU ?
2020-03-20 11:34:18 <ncopa> yes
2020-03-20 11:34:32 <maxice8> Had spurious problems like that since 5.x
2020-03-20 11:34:51 <ncopa> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
2020-03-20 11:40:04 <ncopa> maxice8: do you know if there are any upstream report for it?
2020-03-20 11:42:50 <maxice8> no
2020-03-20 11:43:57 <TBK[m]> ncopa: maybe https://gitlab.freedesktop.org/drm/intel/issues/166
2020-03-20 11:48:21 <Cogitri> Hm, oddly enough I'm not hit by any of those intel issues on my 8705G
2020-03-20 11:48:25 <Cogitri> I use GNOME Wayland though
2020-03-20 11:54:08 <ncopa> it could be chromium related also. dunno
2020-03-20 11:55:24 <Cogitri> FWIW I use FF
2020-03-20 11:56:11 <Cogitri> Chromium looks funny on GNOME Wayland for some reason
2020-03-20 11:56:33 <Cogitri> QtWebEngine had the same failure but that was fixed in QtWebEngine 5.14, dunno how it's not fixed in Chromium
2020-03-20 11:56:50 <Cogitri> 
ACTION uploaded an image: Screenshot from 2020-03-20 12-55-48.png (52KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/mMBWVDnXRjMBtthwGmpAQcxe >

2020-03-20 11:59:00 <maxice8> oh wow, that looks like a screenshot of a Bill Wurtz music video
2020-03-20 13:18:12 <Cogitri> nmeum: I think something about Go is very broke
2020-03-20 13:18:34 <Cogitri> On my server (x86_64) I get `/usr/bin/gotop: line 2: syntax error: unexpected newline` when running gotop
2020-03-20 13:18:43 <Cogitri> And on my desktop `The file '/usr/bin/gotop' is marked as an executable but could not be run by the operating system.`
2020-03-20 13:18:47 <Cogitri> Both running on edge
2020-03-20 13:19:13 <nmeum> well that doesn't sound good
2020-03-20 13:19:33 <nmeum> ncopa: did you get around to reviewing my GOFLAGS change yet?
2020-03-20 13:22:39 <ncopa> ah, sorry. got distracted by other stuff
2020-03-20 13:22:45 <kaey> Cogitri: what does ldd /usr/bin/gotop says?
2020-03-20 13:24:51 <ncopa> $ file /usr/bin/gotop
2020-03-20 13:25:04 <ncopa>  /usr/bin/gotop: current ar archive
2020-03-20 13:26:04 <ncopa> $ ar -t /usr/bin/gotop
2020-03-20 13:26:04 <ncopa> __.PKGDEF
2020-03-20 13:26:04 <ncopa> _go_.o
2020-03-20 13:27:03 <Cogitri> kaey: /lib/ld-musl-x86_64.so.1: /usr/bin/gotop: Not a valid dynamic program
2020-03-20 13:38:58 <kaey> binary was moved to cmd/gotop. APKBUILD needs updating
2020-03-20 13:39:22 <kaey> instead of "go build ." use "go build ./cmd/gotop"
2020-03-20 13:40:34 <kaey> running something like --version in check would have caught this btw
2020-03-20 13:48:12 <Cogitri> Or running actual tests
2020-03-20 13:50:07 <kaey> have you seen many e2e tests for commandline tools? I didn't
2020-03-20 13:50:33 <kaey> and running go test ./... wouldn't help in this case
2020-03-20 13:51:50 <Cogitri> It's certainly possible to make tests for CLI tools
2020-03-20 14:36:27 <nmeum> pushed a fix for gotop
2020-03-20 14:38:48 <nmeum> the trick is to run go build with ./... and specify a directory as the output destination, iirc it should build all subpackages then
2020-03-20 14:39:38 <nmeum> a newapkbuild template for go packages would probably be handy at some point
2020-03-20 14:41:48 <_ikke_> nmeum: agreed
2020-03-20 14:41:54 <_ikke_> but there are several flavors afaik
2020-03-20 14:42:22 <nmeum> yep
2020-03-20 14:42:59 <nmeum> maybe a wiki page, like we have/had for python packages, would make more sense
2020-03-20 16:59:19 <_ikke_> Cogitri: something is going wrong again with your CI pipeline :-/
2020-03-20 17:01:22 <Cogitri> Huh, how is that happening?
2020-03-20 17:01:40 <Cogitri> What pipeline?
2020-03-20 17:01:45 <_ikke_> gedit
2020-03-20 17:03:18 <_ikke_> Is your forks master behind?
2020-03-20 17:03:42 <_ikke_> Or your local master
2020-03-20 17:03:52 <Cogitri> My local master might be behind
2020-03-20 17:04:01 <Cogitri> But are we expected to keep that upgraded?
2020-03-20 17:04:09 <Cogitri> (lokal as in my fork's)
2020-03-20 17:04:26 <Cogitri> gedit should be (almost) up-to-date, at least it was when I pushed it
2020-03-20 17:04:35 <_ikke_> No, it should not use your forks master, it will explicitly fetch master from aporrts
2020-03-20 17:18:55 <Cogitri> Huh
2020-03-20 17:20:10 <Cogitri> Well, I currently have a rather high timeout on my aports tree, so maybe it happens for everyone but it only manifests in my tree?
2020-03-20 17:21:23 <_ikke_> It would manifest in jobs timing out, but I did not get a lot of reports about that
2020-03-20 17:21:38 <_ikke_> Since the last change I made anyway
2020-03-20 17:22:34 <_ikke_> Cogitri: I'll try to take a look what is going on
2020-03-20 17:23:06 <Cogitri> Thank you
2020-03-20 18:28:45 <ncopa> mps: sorry, i messed up !3482. i wanted to push force it but instead i deleted your branch
2020-03-20 18:29:19 <ncopa> i have also create a new branch with same name and one with same name but with `mps/` prefix
2020-03-20 18:29:49 <ncopa> i pushed it to 3.11-stable though. sorry for creating a mess. still trying to figure out how to properly merge MRs in gitlab
2020-03-20 18:29:59 <ncopa> i think i know what i should have done
2020-03-20 18:31:16 <ncopa> you may want delete the 3.11-stable-gcc-9.2-fix-returning-padded-struct and mps/3.11-stable-gcc-9.2-fix-returning-padded-struct branches
2020-03-20 18:37:19 <mps> ncopa: aha
2020-03-20 18:37:38 <mps> did you fixed them?
2020-03-20 18:43:23 <mps> I will look later
2020-03-20 18:51:27 <mps> Cogitri: good news for FF with musl, https://hg.mozilla.org/mozilla-central/rev/5b5137d9329c4fe789c933337a950b2cc0c16618
2020-03-20 18:53:47 <Cogitri> Neat
2020-03-20 18:54:53 <ncopa> \o/ thats awesome!
2020-03-20 18:55:24 <Cogitri> Now if Chromium did the same... :P
2020-03-20 18:55:45 <_ikke_> Do we patch that ourselves currently?
2020-03-20 18:55:49 <Cogitri> I mean I don't use Chromium but QtWebEngine crashes from time to time which is annoying
2020-03-20 18:55:53 <Cogitri> I don't remember doing that
2020-03-20 18:56:07 <Cogitri> But maybe we don't enable breakpad since that is for error reporting anyway
2020-03-20 18:57:22 <mps> as I read on the net chromium upstream is reluctant to accept musl fixes
2020-03-20 19:27:59 <Cogitri> ikke: Please make this public: https://gitlab.alpinelinux.org/z3ntu/aports
2020-03-20 19:28:22 <_ikke_> done
2020-03-20 19:28:39 <_ikke_> <30 seconds :)
2020-03-20 19:29:22 <Cogitri> And https://gitlab.alpinelinux.org/mksully22/aports
2020-03-20 19:29:48 <_ikke_> done
2020-03-20 19:30:22 <Cogitri> Merci
2020-03-20 19:37:41 <TBK[m]> mps: I thought musl support was improving in the google camps because of fuchsia/zircon
2020-03-20 19:38:04 <Cogitri> Oh, that uses musl? :o
2020-03-20 19:38:26 <mps> TBK[m]: afaik, google forked musl at some time
2020-03-20 19:39:12 <mps> but according to dalias they did it in 'wrong way', or I understood it as such
2020-03-20 19:39:54 <dalias> well they just started putting gratuitous google style c++ all over the place
2020-03-20 19:39:57 <TBK[m]> https://fuchsia.googlesource.com/fuchsia/+/master/zircon/third_party/ulib/musl
2020-03-20 19:40:00 <mps> and dalias can explain whole mess better
2020-03-20 19:40:08 <dalias> with no care for whether there were safety properties violated by that
2020-03-20 19:40:13 <mps> ah, so fast :)
2020-03-20 19:40:49 <Cogitri> mps: Do you want others to look/merge your MRs on Gitlab?
2020-03-20 19:40:56 <TBK[m]> they do love their cpp and go...
2020-03-20 19:41:17 <Cogitri> I'm just going through MRs but I'm always reluctant about merging other dev's stuff in case they prefer merging it themselves
2020-03-20 19:41:20 <mps> Cogitri: I'm not against. what I have to do?
2020-03-20 19:41:41 <timlegge> Cogitri: Thanks for the merge.  BTW, can I continue to use that branch for future updated to older perl APKBUILD files as long as I rebase or should I delete and create a new branch at that time?
2020-03-20 19:42:26 <_ikke_> timlegge: as long as that branch is a decendent from master
2020-03-20 19:42:32 <mps> if I don't want something to be merged I put [WIP] prefix or some of the labels which clearly tell it is not ready
2020-03-20 19:43:01 <_ikke_> timlegge: git log --oneline master..HEAD should not return anything
2020-03-20 19:43:48 <Cogitri> ikke: https://gitlab.alpinelinux.org/wener/aports :)
2020-03-20 19:43:55 <timlegge> okay, so just rebase my tree from master when I add new updates and
2020-03-20 19:44:04 <Cogitri> mps: Ah, okie, good :)
2020-03-20 19:44:15 <Cogitri> timlegge: Exactly, you can keep using the branch if you so desire
2020-03-20 19:44:21 <_ikke_> Cogitri: odne
2020-03-20 19:44:29 <Cogitri> I personally prefer setting the branch name to whatever package I work on right now
2020-03-20 19:44:31 <Cogitri> Thanks
2020-03-20 19:45:25 <timlegge> perfect thanks - I have been working through a few older perl modules so that apkbuild-cpan check works on all of them without an error
2020-03-20 19:45:39 <Cogitri> Neat, thanks for your work :)
2020-03-20 19:45:54 <Cogitri> Could someone who knows init.d scripts/ceph a bit take a look at !5422 ?
2020-03-20 19:48:06 <timlegge> with the apkbuild-mcpan in my abuild clone you can look through all of them in a script runng that to see what packages need an update only 4 erros yester day and that merge fixed one of them
2020-03-20 19:48:19 <timlegge> s/look/loop/
2020-03-20 19:48:19 <alpine-meetbot> timlegge meant to say: with the apkbuild-mcpan in my abuild clone you can loop through all of them in a script runng that to see what packages need an update only 4 erros yester day and that merge fixed one of them
2020-03-20 19:48:57 <timlegge> i really need to learn to type/spell
2020-03-20 19:49:15 <_ikke_> Cogitri: It's complex, but I don't see anything out of the ordinary. It's mostly declarative, just a large start_pre function that does a lot of things
2020-03-20 19:49:47 <timlegge> not that you really want to pound metacpan for all packages regularly though
2020-03-20 19:50:07 <Cogitri> "Does lots of things" is what I concluded too :P
2020-03-20 19:50:34 <Cogitri> Oh well, I guess I'll old off for maxice8 or someone to merge that
2020-03-20 19:50:37 <_ikke_> Not sure if the pgrep is really necessary
2020-03-20 19:50:42 <Cogitri> Would also be good to have more eyes on !4704 since the ML thread for that is dead (@ncopa ?)
2020-03-20 19:53:50 <Cogitri> ikke: https://gitlab.alpinelinux.org/jeanlf/aports :/
2020-03-20 19:54:22 <_ikke_> done
2020-03-20 19:55:38 <Cogitri> Thanks
2020-03-20 20:17:39 <mps> Cogitri: did you tested that firefox with pulseaudio works?
2020-03-20 20:21:09 <Cogitri> Seems to work for me
2020-03-20 20:21:25 <Cogitri> And it detects pulseaudio's libs just fine for me
2020-03-20 20:24:35 <mps> does it works with alsa, without PA
2020-03-20 20:25:26 <mps> I tried to build it but didn't got libpulse added in deps, so couldn't test
2020-03-20 20:30:22 <Cogitri> Well, that just worked for me
2020-03-20 20:30:27 <Cogitri> I guess you can test once the builders are done
2020-03-20 20:30:45 <Cogitri> And if it really doesn't work we can revert it or advise users to use apulse
2020-03-20 20:30:52 <mps> ofc
2020-03-20 20:30:54 <mps> np
2020-03-20 20:31:10 <Cogitri> :)
2020-03-20 20:31:15 <mps> but if you tested it I don't need :)
2020-03-20 22:15:02 <mps> apk info -R firefox | grep pulse => nothing shown
2020-03-20 22:15:30 <mps> apk version firefox => firefox-74.0-r1                         = 74.0-r1
2020-03-20 22:16:17 <mps> apk policy firefox => http://nl.alpinelinux.org/alpine/edge/community
2020-03-21 09:27:39 <Cogitri> mps: FF shows up as program and not as ALSA output in Pulse's application control though
2020-03-21 09:33:38 <Cogitri> So I think PA support does work, I have no clue why it doesn't depend on libpulse though
2020-03-21 09:41:11 <mps> Cogitri: and it works without PA here, tested on aarch64
2020-03-21 09:41:43 <mps> s/works/worked/
2020-03-21 09:41:43 <alpine-meetbot> mps meant to say: Cogitri: and it worked without PA here, tested on aarch64
2020-03-21 09:41:50 <Cogitri> Neat
2020-03-21 09:42:07 <mps> I downgrade it to -esr after testing
2020-03-21 09:43:20 <mps> for me, -esr is less cpu hungry than latest versions
2020-03-21 14:32:41 <Cogitri> ikke: https://gitlab.alpinelinux.org/eanu/aports, please :)
2020-03-21 15:30:08 <_ikke_> Done
2020-03-21 15:30:59 <Cogitri> Thank you
2020-03-21 15:33:20 <oneinsect> guys
2020-03-21 15:33:32 <oneinsect> https://pkgs.alpinelinux.org/package/edge/main/x86/binutils why does binutils depend on musl for runtime?
2020-03-21 15:33:50 <oneinsect> the build dependency ofcourse doesnt contain any reference to musl
2020-03-21 15:33:52 <oneinsect> https://git.alpinelinux.org/aports/tree/main/binutils/APKBUILD
2020-03-21 15:34:27 <_ikke_> oneinsect: abuild traces the run-time shared library dependencies
2020-03-21 15:35:40 <oneinsect> but why should binutils depend on musl?
2020-03-21 15:36:02 <_ikke_> I have no idea myself :)
2020-03-21 15:36:57 <_ikke_> There are binaries that depend on musl
2020-03-21 15:37:03 <Cogitri> Because it contains C binaries
2020-03-21 15:37:12 <Cogitri> And those of course link to the C lib
2020-03-21 15:37:40 <Cogitri> You'll have the same behaviour for every other native packages, everything links to musl in one way or another
2020-03-21 15:38:16 <oneinsect> yes as you said it depends on gcc to be compiled though and also depends on musl to provide libc
2020-03-21 15:38:37 <oneinsect> so musl has to be built first
2020-03-21 15:38:46 <oneinsect> with a bootstrap compiler
2020-03-21 15:39:13 <oneinsect> and then build binutils and then build full gcc with links to the above built musl
2020-03-21 15:39:41 <oneinsect> what a hell hole if I now consider glibc
2020-03-21 15:40:35 <Cogitri> Bootstrapping propably won't be fun, yes
2020-03-21 15:41:11 <dalias> *sigh* of course binutils depends on musl because it calls the standard C functions....
2020-03-21 15:41:30 <dalias> and on alpine musl is the package that provides them
2020-03-21 15:41:57 <oneinsect> hmmmm
2020-03-21 15:42:41 <oneinsect> i wish these amd 4800U laptop release soon, those are 8 core, 16 threads under 15watts and they will help with the compilation times
2020-03-21 15:43:06 <dalias> wow sounds nice
2020-03-21 15:43:20 <oneinsect> the i9-9880H 8-core ones are very expensive
2020-03-21 15:43:32 <oneinsect> and those are 45watt tdp
2020-03-21 15:44:06 <oneinsect> https://www.amd.com/en/products/apu/amd-ryzen-7-4800u
2020-03-21 15:44:33 <oneinsect> there is a H version in amd also https://www.amd.com/en/products/apu/amd-ryzen-7-4800h but i dont need so much power
2020-03-21 15:48:49 <Cogitri> The new Ryzen CPUs are very nice indeed :)
2020-03-21 15:49:00 <Cogitri> Does chrpath work for you guys?
2020-03-21 15:49:07 <Cogitri> I currently get:
2020-03-21 15:49:07 <Cogitri> ```
2020-03-21 15:49:07 <Cogitri> elf_open: No such file or directory
2020-03-21 15:49:07 <Cogitri> ```
2020-03-21 15:49:07 <Cogitri> open: No such file or directory
2020-03-21 15:49:11 <TBK[m]> as I recall intel and amd does not measure tdp the same way so the values can not be compared
2020-03-21 15:49:15 <Cogitri> When I run chrpath -d <any binary>
2020-03-21 15:49:38 <dalias> i dont understand how there are different legitimate ways of measuring tdp
2020-03-21 15:50:51 <dalias> seems obvious: you run it with a current-limiting power supply with a peak load test program running, and if it crashes, you retry with higher limit
2020-03-21 15:51:29 <TBK[m]> no industry standard so each invent their own way, ofc favoring their product
2020-03-21 15:52:09 <dalias> but it seems to me that any such way would not be just "their own way" but rather complete and utter bullshit
2020-03-21 15:52:20 <Cogitri> I certainly do hope the new Ryzen mobile CPUs don't get as hot as it 9th gen I9s, my work "lap"top burns my lap
2020-03-21 15:52:22 <dalias> either it can run with the power you claim, or it can't
2020-03-21 15:54:46 <TBK[m]> try to read about intel's scenario design power (sdp) :S
2020-03-21 15:55:21 <dalias> ...
2020-03-21 15:55:59 <dalias> presumably they have real tdp numbers they give laptop/motherboard manufacturers under nda...
2020-03-21 15:56:08 <dalias> since you kinda need those to engineer the board
2020-03-21 15:56:43 <TBK[m]> I hope so
2020-03-21 17:40:26 <oneinsect> guys quickly what depends_dev depends mean in APKBUILD
2020-03-21 17:41:00 <oneinsect> sorry what does depends_dev= xyz ... mean in APKBUILD
2020-03-21 17:41:19 <oneinsect> okie run-time dependency packages
2020-03-21 17:41:30 <Cogitri> It's dependency for the -dev subpackage
2020-03-21 17:42:20 <oneinsect> i mean like how does this work? I am building perl for the first time https://git.alpinelinux.org/aports/tree/main/perl/APKBUILD and how does it expect to have a run-time dependency package?
2020-03-21 17:42:33 <oneinsect> of perl-utils
2020-03-21 17:42:40 <oneinsect> depends_dev="perl-utils"
2020-03-21 17:42:57 <oneinsect> without actually having perl in the chroot of alpine
2020-03-21 17:43:17 <oneinsect> how do you guys solve such problem while compiling if its from scratch
2020-03-21 17:44:42 <_ikke_> oneinsect: for new releases, they are bootstrapped with edge
2020-03-21 17:44:54 <oneinsect> ummmmm
2020-03-21 17:44:57 <_ikke_> so you start with dependencies from dev until you are self-supporting
2020-03-21 17:45:07 <_ikke_> s/dev/edge
2020-03-21 17:45:07 <alpine-meetbot> _ikke_ meant to say: so you start with dependencies from edge until you are self-supporting
2020-03-21 17:45:45 <maxice8> depends_dev isn't required to build the package
2020-03-21 17:46:11 <oneinsect> but it is required to run? if its not required why mention it in the APKBUILD?
2020-03-21 17:46:34 <_ikke_> It's required for using the dev package, ie, when you are building other packages against it
2020-03-21 17:46:54 <oneinsect> hmmmm
2020-03-21 17:47:14 <oneinsect> but i would anyway do an apk install of it right
2020-03-21 17:47:27 <oneinsect> if perl is required
2020-03-21 17:48:37 <oneinsect> naa never mind
2020-03-21 17:50:13 <oneinsect> so perl-utils is Run-time dependency package(s) for the perl-dev subpackage - ofcourse
2020-03-21 17:50:22 <_ikke_> yes, exactly
2020-03-21 17:50:43 <_ikke_> so, when building something against perl (most likely, perl libraries)
2020-03-21 17:51:49 <oneinsect> i still cant around the logic of mentioning a run-time requirement in the APKBUILD file which should mention only compile time dependencies?
2020-03-21 17:52:35 <Cogitri> Why would it only mention compile time dependencies?
2020-03-21 17:53:04 <oneinsect> so it should also be mentioning run-time dependencies....hmmmm
2020-03-21 17:53:06 <Cogitri> Then dynamic languages would be broken in Alpine since those mostly only have runtime deps
2020-03-21 17:53:59 <_ikke_> apk needs to know what packages to install as dependencies
2020-03-21 17:54:06 <oneinsect> i thought a seperate function did the job of finding the run-time dependencies while packing them as apk files
2020-03-21 17:54:17 <oneinsect> yeaaa
2020-03-21 17:54:24 <_ikke_> yes, but those only work for shared libraries
2020-03-21 17:54:37 <_ikke_> There are other dependencies than just shared libraries
2020-03-21 17:54:50 <Cogitri> E.g. python deps
2020-03-21 17:55:02 <_ikke_> or commands
2020-03-21 17:55:07 <oneinsect> ummmmm
2020-03-21 17:55:30 <oneinsect> this is so tiring!
2020-03-21 17:55:53 <_ikke_> oneinsect: it helps to assume these things are there not needlesly, ie, they do have a purpose
2020-03-21 17:56:13 <oneinsect> indeed
2020-03-21 17:56:14 <kpcyrd> are there any plans to release a new version of abuild? :)
2020-03-21 18:00:48 <_ikke_> Maybe right before the toolchain freeze
2020-03-21 18:20:36 <oneinsect> quick question if i define the user variable replaces="musl-dev musl-utils" for like two or more packages, will both packages apks replace those jointly or only the recent most package will replace those packages
2020-03-21 18:25:42 <oneinsect> Package(s) that this package replaces. This package will "take over" files owned by packages listed in the replaces variable. This is useful when files move from one package to another, or when a package gets renamed.
2020-03-21 18:25:57 <oneinsect> can those package(s) jointly replace a single package?
2020-03-21 18:37:28 <Cogitri> ikke: https://gitlab.alpinelinux.org/bratkartoffel/aports
2020-03-21 18:37:58 <Cogitri> oneinsect: Not sure if that's possible, so I guess you'll have to try
2020-03-21 18:38:07 <oneinsect> hmmmm
2020-03-21 18:45:18 <_ikke_> Cogitri: done
2020-03-21 18:47:47 <mps> Cogitri: when you are here, can the !1051 be closed
2020-03-21 18:48:15 <Cogitri> No, there's a change for -esr too
2020-03-21 18:48:56 <mps> please don't do that for -esr
2020-03-21 18:49:20 <Cogitri> Why?
2020-03-21 18:50:10 <mps> most alpine users doesn't want PA deps
2020-03-21 18:50:21 <Cogitri> ...but it doesn't introduce one during runtime
2020-03-21 18:50:42 <mps> libpulse, I mean
2020-03-21 18:50:53 <mps> though, mpv already have it
2020-03-21 18:51:36 <mps> hmm, my useless appeal. ok, do what you prefer, I give up
2020-03-21 18:52:54 <mps> ohm and audacious-plugins deps to libpulse
2020-03-21 18:53:54 <mps> could someone help with !5446
2020-03-21 18:54:31 <mps> can't see why ncurses depends on ncurses-terminfo after building this ME
2020-03-21 18:55:48 <mps> MR*
2020-03-21 19:25:37 <mps> looks like I found solution. thanks maxice8 for hint in MR comment
2020-03-21 20:40:15 <maxice8> Welcome :D
2020-03-21 20:55:18 <Ariadne> i would like to split the audacious-plugins package, actually
2020-03-21 20:55:39 <Ariadne> but we can wait until 4.0 is released for that
2020-03-21 21:12:41 <oneinsect> i wish there was just basic gcc with just c compiler that was static built, just like apk.static etc, it could have made bootstrapping so much easier
2020-03-21 21:14:26 <oneinsect> right now dependent on crosstools-ng
2020-03-21 21:16:58 <oneinsect> good night folks
2020-03-21 21:20:30 <timlegge> what to do with the license when its GPL-1.0-or-later OR Artistic-1.0-Perl but uulib/ecb.h     distributed unter GPL and uulib/crc32.c   3-clause BSD
2020-03-21 21:23:15 <_ikke_> You append them with AND
2020-03-21 21:23:30 <_ikke_> but you need to put the first to between ()
2020-03-21 21:23:48 <timlegge> makes sense
2020-03-21 21:23:52 <timlegge> thanks
2020-03-21 21:26:22 <Cogitri> Can someone else try to merge !5670 ? It just spins forever for me when merging
2020-03-21 21:26:51 <_ikke_> done
2020-03-21 21:34:24 <Cogitri> Thanks
2020-03-22 00:28:15 <timlegge> !5675 moves main/perl-common-sense: move from community as it is a dependency for main/perl-convert-uulib I know there were some discussions around main recently.
2020-03-22 00:28:46 <timlegge> There were a couple of main dependencies on perl-convert-uulib
2020-03-22 04:54:14 <maxice8> @timlegge that is a good reason to be on main/, i'm just trying to remove undue burden on maintainers/package not being properly cared by moving from 2 year (first 6 months bugfixes) security support to 6 months bugfixes support
2020-03-22 05:00:37 <Ariadne> i feel like the $license field is really not sufficient
2020-03-22 05:00:56 <Ariadne> i think we should figure out a replacement
2020-03-22 05:01:03 <maxice8> like ?
2020-03-22 05:01:08 <Ariadne> debian/copyright
2020-03-22 05:01:21 <Ariadne> some sort of YAML thing
2020-03-22 05:01:37 <Ariadne> src/foo/bar: GPL
2020-03-22 05:01:37 <maxice8> From what i understand that is just a separate file that tells which files are under which license
2020-03-22 05:01:43 <Ariadne> src/foo/bar/baz.c: BSD-2-Clause
2020-03-22 05:01:56 <Ariadne> maxice8: yes, and $license does not provide sufficient detail
2020-03-22 05:02:12 <Ariadne> $license tells us there are components under license X, Y and Z
2020-03-22 05:02:21 <Ariadne> but not what those components are
2020-03-22 05:02:27 <Ariadne> or how the licenses are related to each other
2020-03-22 05:02:48 <maxice8> sounds sufficient for most cases, SPDX has WITH and AND for relationship between licenses
2020-03-22 05:03:03 <Ariadne> for example, in audacious-plugins $license was set to ISC, but only some plugins are ISC.  others are GPL, BSD-2-Clause, BSD-3-Clause, etc
2020-03-22 05:05:21 <[[sroracle]]> Ariadne: i agree. this is something i've wanted to pursue with adelie but it would probably have to be a very gradual transition (e.g. on next package touch)
2020-03-22 05:06:31 <[[sroracle]]> licensecheck can lend some automation but as i understand it it has quite a large dep tree
2020-03-22 05:07:38 <[[sroracle]]> apk would also need to be adjusted somehow to accommodate this
2020-03-22 05:17:04 <maxice8> Is that going to be a separate file?
2020-03-22 07:20:52 <Ariadne> maxice8: probably not
2020-03-22 07:21:39 <Cogitri> Sounds like a lot of work for something many don't care about
2020-03-22 07:22:38 <maxice8> i see, when you say it i think of debian/copyright which is very big, If you can write about how it would look like in an APKBUILD i wouldn't mind adding it as something optional that can be used instead of license=, at the moment license= fills up lots of the current usage requirements for users.
2020-03-22 07:22:54 <Ariadne> just because somebody does not care about tracking legal compliance does not mean that the work is not important
2020-03-22 07:23:55 <Cogitri> Yes, but the other work on aports/ is important too
2020-03-22 07:24:04 <Cogitri> And we have both hands full with work
2020-03-22 07:24:22 <Ariadne> shipping an operating system is hard, lets go shopping!
2020-03-22 07:30:35 <Ariadne> (and for most packages, the required changes would be both trivial and automatable)
2020-03-22 07:31:58 <maxice8> or have copyright a piece that can be used optionally instead of license=
2020-03-22 07:33:18 <Ariadne> maxice8: i don't see much value in that.  many $license entries are plain wrong.  audacious is not and never was solely licensed under ISC.
2020-03-22 07:34:26 <Ariadne> but license1 AND license2 AND license3 AND license4 AND license5 does not really sufficiently (or even accurately) explain the licensing of a complex software like audacious
2020-03-22 07:34:47 <maxice8> good good
2020-03-22 07:35:00 <maxice8> then use copyright for that
2020-03-22 07:35:31 <Ariadne> $license as shorthand to create a stub copyright entry is fine with me, as long as packages will be fixed
2020-03-22 07:38:30 <maxice8> sounds good by me, as long as i don't have to deal with this hypothetical copyright thing most of the time
2020-03-22 07:39:05 <Ariadne> for the simple case, we could just generate it from the SPDX label in $license
2020-03-22 08:56:05 <_ikke_> Cogitri: not sure if you are involved, but: https://gitlab.alpinelinux.org/alpine/aports/issues/11320
2020-03-22 08:57:18 <Ariadne> why
2020-03-22 08:57:21 <Ariadne> did he do something
2020-03-22 08:57:45 <_ikke_> Last time I asked about it, he mentioned something about opengl
2020-03-22 08:57:53 <Ariadne> okay
2020-03-22 08:57:58 <Ariadne> time to investigate
2020-03-22 08:58:16 <Ariadne> if this is a "pmOS needs it" i am going to scream
2020-03-22 08:58:24 <Ariadne> pray I don't scream
2020-03-22 08:59:22 <Ariadne> case "$CTARGET_ARCH" in
2020-03-22 08:59:22 <Ariadne>         arm*|aarch64) opengl="-opengl es2";;
2020-03-22 08:59:23 <Ariadne> oh no
2020-03-22 08:59:44 <Ariadne> i am feeling like this is going to be a "pmOS needs it"
2020-03-22 09:00:11 <Ariadne> commit 9c1099ca56f6b518c931b11c93c9b6a444260476
2020-03-22 09:00:11 <Ariadne> Author: Bart Ribbers <bribbers@disroot.org>
2020-03-22 09:00:11 <Ariadne> Date:   Tue Feb 25 09:21:07 2020 +0100
2020-03-22 09:00:11 <Ariadne>     community/qt5-qtbase: use OpenGLES on ARM
2020-03-22 09:00:17 <Ariadne> yes
2020-03-22 09:00:22 <Ariadne> this is a "pmOS needs it"
2020-03-22 09:00:26 <Ariadne> well
2020-03-22 09:00:33 <Ariadne> thanks guys you totally broke tons of packages on ARM
2020-03-22 09:00:43 <Ariadne> think we are going to need to find a different way here
2020-03-22 09:02:11 <Cogitri> +
2020-03-22 09:02:25 <Cogitri> It's not a "pmOS" needs it, it's a "most arm boards need this"
2020-03-22 09:02:53 <Ariadne> uh huh
2020-03-22 09:03:04 <Ariadne> i mean, i do understand that
2020-03-22 09:03:19 <Ariadne> but you can't just change the behaviour of Qt on ARM
2020-03-22 09:03:40 <Ariadne> basically any package that touches OpenGL on Qt on ARM fails to compile now
2020-03-22 09:04:03 <Ariadne> unless you do workarounds like https://github.com/audacious-media-player/audacious-plugins/commit/a51aa5fc4133da3359854d1ba03584a1f97a360f.patch
2020-03-22 09:04:39 <Ariadne> also, "most arm boards" don't need this
2020-03-22 09:05:40 <Ariadne> my raspberry pi 4 does not need this, it has a Gallium3D driver that just works
2020-03-22 09:06:03 <Ariadne> my chromebooks do not need this, because there is no driver for them anyway except for a binary blob
2020-03-22 09:09:14 <Ariadne> i will accept that some ARM boards have binary blob drivers that only implement OpenGLES
2020-03-22 09:11:22 <Ariadne> Cogitri: i am reverting this change, it breaks too much stuff
2020-03-22 09:11:27 <Ariadne> Cogitri: we need to find another way
2020-03-22 09:11:56 <Ariadne> Cogitri: we cannot have a Qt that compiles differently on some archs than others, that is just insane
2020-03-22 09:12:39 <Ariadne> what a fucking mess
2020-03-22 09:13:32 <Ariadne> PureTryOut[m]: ping
2020-03-22 09:16:49 <PureTryOut[m]> Yeah I read it, but I refuse to respond if you're that aggressive about it
2020-03-22 09:17:10 <Ariadne> great
2020-03-22 09:18:14 <Ariadne> PureTryOut[m]: then i will revert the change
2020-03-22 09:18:47 <Ariadne> because as it stands, Qt5OpenGL is unusable on ARM
2020-03-22 09:18:53 <Cogitri> Do that then, I don't want to work with you either if you're so aggressive about it.
2020-03-22 09:19:16 <Ariadne> great
2020-03-22 09:24:03 <Ariadne> Cogitri: well i am sorry that i am in a grouchy mood about this
2020-03-22 09:25:05 <Ariadne> Cogitri: and i would like to find a solution that results in a usable (as in you can compile apps against it) Qt5OpenGL that also is accelerated in all cases on ARM
2020-03-22 09:26:20 <Ariadne> but at present, the situation is that on ARM if you use Qt5OpenGL, you wind up with OpenGLES API instead of OpenGL API as expected
2020-03-22 09:26:25 <Cogitri> Well, that sounds better already :)
2020-03-22 09:26:45 <Ariadne> which, presumably is not intended
2020-03-22 09:27:07 <Cogitri> Hm, but can we support both APIs at the same time?
2020-03-22 09:27:16 <Ariadne> i'm not sure
2020-03-22 09:27:22 <Ariadne> in theory, yes
2020-03-22 09:27:41 <Ariadne> that is what -opengl on its own is supposed to do, then the application developer chooses which kind of OpenGL context he wants
2020-03-22 09:27:46 <Ariadne> normal OpenGL or OpenGLES
2020-03-22 09:27:54 <Ariadne> the problem is
2020-03-22 09:28:07 <Ariadne> -opengl es2 changes the default context from OpenGL to OpenGLES
2020-03-22 09:29:36 <Ariadne> the real problem is these damn binary blob drivers that are OpenGLES-only
2020-03-22 09:29:44 <Ariadne> the ones that come from android BSPs presumably
2020-03-22 09:30:04 <Ariadne> my ARM devices either have no driver or they have a proper Gallium3D driver
2020-03-22 09:30:16 <Ariadne> so i either get swrast or hw accel
2020-03-22 09:31:27 <Ariadne> i am not sure how to solve this, but reverting at least makes things compile with swrast in meantime
2020-03-22 09:31:36 <Ariadne> so i think we should do that regardless
2020-03-22 09:31:51 <maxice8> so -opengl can be passed on a per-program basis to select against with GL (openGL or openGLES) to compile against ?
2020-03-22 09:32:05 <Ariadne> no, it's a qtbase config flag
2020-03-22 09:32:16 <Ariadne> what programs can do is
2020-03-22 09:32:22 <Ariadne> there is QOpenGLFunctions
2020-03-22 09:32:35 <Ariadne> and with that you can say "i want OpenGLES API" or "i want OpenGL API"
2020-03-22 09:32:43 <Ariadne> but if you use QOpenGLFunctions it defaults to OpenGL API
2020-03-22 09:32:47 <Ariadne> so a lot of apps are broken
2020-03-22 09:33:22 <Ariadne> because we flipped the default
2020-03-22 09:33:33 <Ariadne> and the problem i think is
2020-03-22 09:33:51 <Ariadne> Qt5OpenGL compiled with OpenGLES default is not ABI compatible with Qt5OpenGL compiled with OpenGL default
2020-03-22 09:34:04 <Ariadne> if it were, i would just suggest having two packages for Qt5OpenGL
2020-03-22 09:36:56 <Ariadne> it is an annoying problem
2020-03-22 09:37:27 <afontain_> wouldn't it make sense to apply a patch similar to the one you linked above?
2020-03-22 09:38:00 <Ariadne> no
2020-03-22 09:38:05 <maxice8> That would need patching most programs i think
2020-03-22 09:38:06 <Ariadne> because that patch actually will not work
2020-03-22 09:38:08 <afontain_> (note that I don't know much about Qt or GL)
2020-03-22 09:38:19 <Ariadne> instead, it will crash
2020-03-22 09:38:46 <Ariadne> i did that patch first because i did not think the default was flipped on ARM
2020-03-22 09:40:13 <Ariadne> basically
2020-03-22 09:40:24 <Ariadne> for -opengl es2 to "just work", all programs we compile
2020-03-22 09:40:31 <Ariadne> have to properly use QOpenGLFunctions
2020-03-22 09:40:47 <Ariadne> so this is something that would involve a lot of patching
2020-03-22 09:41:40 <Ariadne> most Qt5OpenGL desktop consumers do not use QOpenGLFunctions
2020-03-22 09:43:02 <Ariadne> or in the case of audacious, use them incompletely
2020-03-22 09:44:08 <Ariadne> because the way QOpenGLFunctions works is, it gives you a subset of the OpenGL API
2020-03-22 09:44:16 <Ariadne> and translates that to whatever
2020-03-22 09:46:30 <Ariadne> and then some programs explicitly request QOpenGLFunctions_4 or whatever
2020-03-22 09:46:36 <Ariadne> and if you compile with -opengl es2
2020-03-22 09:46:43 <Ariadne> then QOpenGLFunctions_4 does not exist
2020-03-22 09:46:53 <Ariadne> _ikke_ was bit by this recently
2020-03-22 09:48:09 <_ikke_> shotcut fails to build on arm
2020-03-22 10:07:48 <Ariadne> solution: http://ptitseb.github.io/gl4es/
2020-03-22 10:11:33 <Ariadne> Cogitri: since there is GL4ES, i think the best way is to revert this change to qt5 and package GL4ES for use on OpenGLES-only ARM devices
2020-03-22 10:12:04 <Ariadne> Cogitri: this would allow for mostly working accelerated Desktop OpenGL on these devices
2020-03-22 10:12:18 <Cogitri> If that thing works and performs somewhat well then that's fine by me, but I don't use ARM devices
2020-03-22 10:13:21 <Ariadne> it looks like it is workable
2020-03-22 10:14:39 <Ariadne> it can run minecraft anyway
2020-03-22 10:18:43 <Ariadne> https://www.youtube.com/watch?v=VUoeHWuwlMU
2020-03-22 10:18:46 <Ariadne> performance seems good
2020-03-22 10:18:49 <Ariadne> that's on an ODroid
2020-03-22 10:21:53 <Cogitri> Neat
2020-03-22 10:25:15 <maxice8> i can package GL4ES right now
2020-03-22 10:25:16 <Ariadne> PureTryOut[m]: given that Qt5OpenGL compiled against OpenGLES breaks source compatibility, and there is GL4ES library that provides a desktop OpenGL implementation that works on OpenGLES-only systems, i think we should revert and package GL4ES.  do you agree?
2020-03-22 10:27:43 <Ariadne> maxice8: great
2020-03-22 10:28:21 <Ariadne> maxice8: it will need to replaces= on the mesa-libgl or whatever it is package
2020-03-22 10:28:45 <maxice8> ok, i'm updating catch2 atm and will package it after
2020-03-22 10:31:56 <maxice8> @Ariadne https://github.com/ptitSeb/gl4es/blob/master/CMakeLists.txt there are some switches that i quite do not understand
2020-03-22 10:32:04 <Ariadne> i'll look at it
2020-03-22 10:32:33 <maxice8> There are some that appear to be device specific
2020-03-22 10:32:54 <Ariadne> yeah
2020-03-22 10:33:05 <Ariadne> those seem to be hacks for specific GPU drivers
2020-03-22 10:33:58 <Ariadne> for example
2020-03-22 10:34:14 <Ariadne> it can provide desktop OpenGL using the binary blob broadcom driver
2020-03-22 10:34:17 <Ariadne> for original raspberry pi
2020-03-22 10:34:33 <Ariadne> i think for now we don't have to worry about these so much :)
2020-03-22 10:36:14 <maxice8> I see, i'll provide an APKBUILD with default values and people from pmOS and others that need the GLES stuff can look and tweak
2020-03-22 10:37:37 <Ariadne> that seems like a good starting point
2020-03-22 10:44:37 <maxice8> gl4es has no install target, what?
2020-03-22 10:54:19 <minecrell> Btw, I don't think there is any device in pmOS that uses binary blob drivers. Most (all?) devices with working GPU use open-source Mesa. I'm not sure why we needed that change, though someone said in the past that GLES works better than OpenGL even for Mesa on ARM devices.
2020-03-22 10:55:21 <_ikke_> Ariadne: shotcut is no building on arm as well
2020-03-22 10:55:26 <_ikke_> s/no/now/
2020-03-22 10:55:26 <alpine-meetbot> _ikke_ meant to say: Ariadne: shotcut is now building on arm as well
2020-03-22 10:56:49 <Ariadne> minecrell: some devices on ARM with open source drivers are still restricted to OpenGLES functionality
2020-03-22 10:57:12 <Ariadne> this is also a thing with other embedded hardware
2020-03-22 10:57:15 <_ikke_> hmff
2020-03-22 10:58:14 <Ariadne> maxice8: yes, it just generates a stub libGL from what I see.
2020-03-22 10:59:14 <Ariadne> minecrell: at any rate mesa-opengles plus gl4es should be a big win for pmOS in future
2020-03-22 11:01:28 <maxice8> @Ariadne i guess i should install it to somewhere other than /usr/lib so it doesn't conflict with mesa-gl and then ask for LD_LIBRARY_PATH, or  have it in the same path but have replaces="mesa-gl" ?
2020-03-22 11:05:06 <minecrell> Ariadne: I guess in the next days we will see how well desktop OpenGL works. I think we haven't actually tried it on most devices because the qt5-qtbase fork in pmOS was done long ago (the change in Alpine was made to get rid of it)
2020-03-22 11:06:15 <z3ntu> Could somebody with an Alpine wiki account please fix the archive links at https://wiki.alpinelinux.org/wiki/Alpine_Linux:Mailing_lists ? (probably also the subscribe/unsubscribe/help emails)
2020-03-22 11:06:56 <maxice8> @Ariadne !5688
2020-03-22 11:07:21 <Cogitri> z3untu: sure thing
2020-03-22 11:09:15 <Cogitri> Actually, does one need special permissions to edit that page?
2020-03-22 11:09:30 <Cogitri> I can't seem to edit it, do you know something about that, ikke?
2020-03-22 11:09:32 <_ikke_> Can't you edit it?
2020-03-22 11:09:44 <_ikke_> Yeah, it looks like it's protected
2020-03-22 11:28:18 <Cogitri> Can you maybe allow me to edit it or change the links?
2020-03-22 11:29:53 <_ikke_> Was trying to verify why it was protected in the first
2020-03-22 11:29:55 <_ikke_> place
2020-03-22 11:30:04 <Cogitri> Ah, okay
2020-03-22 11:55:16 <_ikke_> Cogitri: you should be able to adjust it now
2020-03-22 11:55:48 <Cogitri> Thanks :)
2020-03-22 12:05:20 <Cogitri> z3untu: I think the links should be fixed now
2020-03-22 13:31:00 <z3ntu> Cogitri: thanks!
2020-03-22 13:40:59 <maxice8> hey, i'm going to merge icu 66.1 update soon,  any objections ?
2020-03-22 13:45:10 <Cogitri> Would be nice if qtweb{engine,kit} could be tested before that
2020-03-22 13:45:22 <Cogitri> Does Quasseln work now?
2020-03-22 13:52:57 <maxice8> quassel is due to new qt not ICU
2020-03-22 13:53:42 <andypost[m]> Also postgresql could be affected
2020-03-22 14:07:56 <Cogitri> Quassel should be fixed nontheless to not block the builders
2020-03-22 14:08:15 <maxice8> it won't block, it won't be rebuilt
2020-03-22 14:08:31 <Cogitri> Ah, but doesn't it link against icu?
2020-03-22 14:08:38 <maxice8> yes
2020-03-22 14:08:54 <Cogitri> So won't it be broken then?
2020-03-22 14:09:00 <maxice8> yes
2020-03-22 17:28:40 <oneinsect> the virus is mutating and its bad, really bad
2020-03-22 17:28:49 <oneinsect> i wonder how you all are coping up
2020-03-22 17:29:31 <_ikke_> Mostly avoiding contact as much as possible
2020-03-22 17:29:56 <oneinsect> hmmmm
2020-03-22 17:30:12 <oneinsect> wonder how long will it continue like this
2020-03-22 17:31:02 <mps> till we open eyes
2020-03-22 17:31:37 <mps> or move to #alpine-offtopic
2020-03-22 17:34:44 <maxice8> oneinsect (IRC) until a vaccine is created or it isn't much of a threat anymore
2020-03-22 17:35:09 <maxice8> To be fair if we could keep the heightened hygiene standards even after it would be very nice
2020-03-22 17:36:27 <artok> well, we're gettin meds to help under virus, if not vaccines against it
2020-03-22 17:37:00 <_ikke_> Let's heed mps advise and move this to #alpine-offtopic
2020-03-22 17:37:57 <dalias> *nod*
2020-03-22 17:38:18 <maxice8> Oh, didn't realise it wasn't offtopic, just assumed it was, sorry
2020-03-22 17:38:35 <artok> true.. so: did we have now rpi kernel on edge that works
2020-03-22 17:39:50 <artok> might as well test it =)
2020-03-22 17:49:40 <artok> nah, no usb drivers found, system died
2020-03-22 17:49:51 <artok> rpi4, root on usb
2020-03-22 17:50:10 <Cogitri> f
2020-03-22 17:57:15 <artok> and now I've lost all my sd card adapters =D
2020-03-22 18:02:34 <mps> artok: I started to work on 5.6-rcX kernel which have drivers for RPi4 but didn't finished (not much free time these days)
2020-03-22 18:03:34 <mps> if you have time and resources you can try to build it and if it works
2020-03-22 18:04:00 <mps> even if I build it I can't test because I don't have RPi4 board
2020-03-22 18:08:21 <artok> well, I was kicked out of work because of the virus, if no gigs appear suddenly, I have time to do various stuff
2020-03-22 18:08:27 <artok> =D
2020-03-22 18:09:12 <Cogitri> Well, I have my laptop with me to do homeoffice hooray :P
2020-03-22 18:09:36 <maxice8> @ikke: https://github.com/maxice8/mkmr/pull/39 added edmr, a script to update the status of merge requests
2020-03-22 18:16:59 <mps> artok: I hope that next week I will create testing/linux-{how_to_name_it} kernel 5.6-rc7 in aports specifically for armv7 and aarch64 with drivers for more SBCs
2020-03-22 18:17:06 <artok> who did https://wiki.alpinelinux.org/wiki/Raspberry_Pi_-_Headless_Installation ?
2020-03-22 18:17:32 <mps> ok, I have intention to do that, but who knows what will happen in next days
2020-03-22 18:17:46 <oneinsect> whats special in 5.6-rc7? significant updates for arm drivers?
2020-03-22 18:18:01 <mps> oneinsect: yes
2020-03-22 18:18:31 <craftyguy> hmm has alpine's gitlab gone off the rails? if I make a new branch off of aports/master (with no new commits), then push to a new branch in my fork, gitlab offers to make a new MR to alpine/aports/master with 3195 commits in it
2020-03-22 18:19:20 <craftyguy> HEAD on my branch is the same as alpine/aports/master, so I'm not sure what is going on. it's preventing me from making a MR for adding a new package to aport :/
2020-03-22 18:20:29 <craftyguy> hmm, maybe I goofed up somewhere..
2020-03-22 18:22:00 <mps> btw, how to name 'bleeding edge' kernel? linux-edge?
2020-03-22 18:22:18 <artok> linux-corona
2020-03-22 18:22:33 <artok> if you have config somewhat ready, I could build and test
2020-03-22 18:22:35 <mps> linux-crown sounds better
2020-03-22 18:23:00 <craftyguy> wtf is going on here: https://gitlab.alpinelinux.org/craftyguy/aports/merge_requests/2/commits
2020-03-22 18:23:35 <mps> artok: I have x86_64, and begging of the armv7 configs
2020-03-22 18:23:53 <Cogitri> craftguy: You made a MR against your fork and not upstream aports
2020-03-22 18:24:02 <Cogitri> And I guess the master of your fork is old
2020-03-22 18:24:09 <mps> and some tweaks of aarch64 but for now tested only on rk3399
2020-03-22 18:24:29 <craftyguy> 
ACTION hates gitlab's interface

2020-03-22 18:25:16 <Cogitri> Can I maybe entise you to try mkmr? :P
2020-03-22 18:25:23 <Cogitri> 
ACTION goes make a ML post for that

2020-03-22 18:26:08 <craftyguy> FYI the link that gitlab returned when pushing to my branch was to make a merge request against my own fork. that's not right
2020-03-22 18:27:37 <timlegge> craftyguy: after you do a few MRs it seems to figure ot out.  but I generally go to alpine/aports after I push a branch and it offers a MR button that seems to do what I want.  there is a change branch at the top of the MR
2020-03-22 18:41:19 <z3ntu> craftyguy: same behavior for me. really really annoying though
2020-03-22 18:44:40 <Cogitri> Huh, that's not right indeed
2020-03-22 18:45:04 <Cogitri> _ikke_: Do you know what's that about? Usually it should return a link to make a MR against upstream not the fork
2020-03-22 18:45:23 <_ikke_> craftyguy: what's the repo?
2020-03-22 18:45:30 <_ikke_> It usually means it's not a proper fork
2020-03-22 18:46:52 <craftyguy> _ikke_: https://gitlab.alpinelinux.org/craftyguy/aports
2020-03-22 19:24:59 <Cogitri> ikke: https://gitlab.alpinelinux.org/allgdante/aports  :)
2020-03-22 19:32:44 <AinNero> uh, my aports have this behavior, too
2020-03-22 19:33:08 <AinNero> i accidentally did my first MR against my own fork because i wasnt used to this default behavior
2020-03-22 19:33:14 <artok> I totally killed my rpi installation...
2020-03-22 19:34:23 <artok> is there any info on what to add into apkovl.tar.gz to get some scripts running on boot?
2020-03-22 19:35:14 <artok> or just "reverse engineer"
2020-03-22 19:42:22 <AinNero> artok: its an tarball you can untar, edit as you wish and tar again
2020-03-22 19:42:34 <AinNero> contents are plaintext files as they lie in /etc
2020-03-22 19:42:37 <artok> yah, that is understood
2020-03-22 19:43:03 <AinNero> there is the /etc/local.d mechanism
2020-03-22 19:43:37 <AinNero> add your script there with chmod +x
2020-03-22 19:43:46 <artok> so to make self configurable system, I just create one and .. yah
2020-03-22 19:44:16 <AinNero> and then add /etc/init.d/local to the default runlevels
2020-03-22 19:47:08 <artok> well my dream is to boot from sd, configure attached USB mass media as root system, reboot and start installing needed software to the system
2020-03-22 19:48:09 <artok> all automatic
2020-03-22 20:05:29 <craftyguy> Cogitri: thanks for reviewing my MR, I appreciate the feedback. One day I'll get the hang of this :P
2020-03-22 20:13:55 <Cogitri> :)
2020-03-22 20:18:48 <Cogitri> _ikke_: https://gitlab.alpinelinux.org/craftguy/aports doesn't seem to be public yet
2020-03-22 20:23:13 <craftyguy> public?
2020-03-22 20:46:04 <Cogitri> craftyguy: We currently need to make aports repo public (only admins can do that) in order to be able to rebase & merge MRs
2020-03-22 20:46:22 <Cogitri> It's a really unfortunate limitation in Gitlab right now
2020-03-22 20:47:52 <Cogitri> Ah, but since you've rebased yourself I can merge it :)
2020-03-22 20:50:53 <_ikke_> Cogitri: it does not seem to exist?
2020-03-22 20:52:04 <craftyguy> _ikke_: I think he meant: https://gitlab.alpinelinux.org/craftyguy/aports
2020-03-22 20:52:16 <_ikke_> yea
2020-03-22 20:52:41 <_ikke_> Now it's public
2020-03-22 20:52:44 <craftyguy> Cogitri: I figured you might have wanted to rebase, hence the request to push to it :P
2020-03-22 20:52:55 <craftyguy> so is there no way I could have made my repo public?
2020-03-22 20:53:15 <_ikke_> no
2020-03-22 20:53:23 <craftyguy> weird. ok
2020-03-22 20:53:31 <_ikke_> We want to prevent spam
2020-03-22 20:53:45 <craftyguy> oh, that makes sense then
2020-03-22 21:22:34 <Ariadne> maxice8 great will review
2020-03-22 23:21:03 <timlegge> anyone have time to review  !5706 I pulled out the packages that had dependencies on other testing packages.  Will do those seperately
2020-03-23 00:04:03 <Ariadne> timlegge: i have acked it
2020-03-23 00:04:49 <Ariadne> TBK[m]: hi, can you add an explicit dependency on musl-dev>=1.1.21-r4 since it depends on the fixed headers?
2020-03-23 00:11:11 <timlegge> Ariande: Thanks
2020-03-23 08:32:40 <artok> linux firmware
2020-03-23 08:41:55 <artok> oops.. well that Is needed to initramfs to get rpi working, it seems
2020-03-23 09:09:16 <Cogitri> What's the deadline for 3.12 feature freeze again?
2020-03-23 09:12:35 <Ariadne> well
2020-03-23 09:12:36 <Ariadne> now
2020-03-23 09:12:38 <Ariadne> ideally
2020-03-23 09:12:49 <Ariadne> but covid-19 has fucked up everyone's shit, so i think we should delay a week or two
2020-03-23 09:13:22 <Ariadne> keep in mind the first freeze is just a soft freeze
2020-03-23 09:16:09 <_ikke_> I think we start with a toolchain freeze, right?
2020-03-23 09:16:41 <Cogitri> I'm asking because of https://gitlab.alpinelinux.org/alpine/aports/issues/11306#note_75898
2020-03-23 09:16:48 <Cogitri> It would be very nice to get LDC on more arches for 3.12
2020-03-23 09:32:22 <Ariadne> _ikke_: yes, and i think we intend to stick with GCC9 for 3.12
2020-03-23 09:32:46 <Cogitri> 9.3?
2020-03-23 09:34:27 <Ariadne> is it out?
2020-03-23 09:35:17 <Cogitri> Yes
2020-03-23 09:35:29 <Cogitri> https://gcc.gnu.org/gcc-9/
2020-03-23 09:35:33 <Cogitri> Since 11 days
2020-03-23 09:35:56 <mps> it will need some patches for musl
2020-03-23 09:36:17 <mps> to work with musl*
2020-03-23 09:36:54 <mps> binutils-2.34 also
2020-03-23 09:37:32 <Ariadne> i think we should stay on 9.2 then
2020-03-23 09:38:16 <Cogitri> But the 3.12 release is in like 3 months
2020-03-23 09:38:21 <Cogitri> I think 9.3 should be in 3.12
2020-03-23 09:39:14 <_ikke_> The scheduled date is May, so closed to 2 months
2020-03-23 09:39:34 <mps> I highlited ncopa here about 10 day ago about gcc 9.3, and left him to decide
2020-03-23 09:40:06 <mps> because that I didn't made gcc 9.3 upgrade MR, waiting for BDFL to decide
2020-03-23 09:41:06 <_ikke_> Well, you are free to make a MR :-)
2020-03-23 09:41:12 <_ikke_> you don't need permission for that
2020-03-23 09:41:27 <Cogitri> That'd certainly be nice, yes
2020-03-23 09:42:01 <mps> _ikke_: yes, I know but didn't wanted to make it before hear what BDFL have to say
2020-03-23 09:42:06 <Cogitri> Err right, it's in May, apparently the coffe didn't kick in yet that I can't do December + 6 months :P
2020-03-23 09:42:29 <mps> because some patches will be needed
2020-03-23 09:43:10 <Cogitri> Well, is that unusual?
2020-03-23 09:43:51 <mps> Cogitri: look current pile of patches in main/gcc
2020-03-23 09:44:37 <mps> 37
2020-03-23 09:44:57 <Cogitri> So I think a few more aren't unusual
2020-03-23 09:45:06 <Cogitri> It's really bad now many downstream patches we have
2020-03-23 09:46:42 <Cogitri> ikke: https://gitlab.alpinelinux.org/pglaum/aports por favor
2020-03-23 09:47:53 <_ikke_> done
2020-03-23 09:50:17 <Cogitri> And https://gitlab.alpinelinux.org/otlabs/aports s'il vous plaît
2020-03-23 09:50:52 <_ikke_>  merci
2020-03-23 10:49:52 <Cogitri> Can we please get a new abuild release? It's a bit annoying (and confusing for new users) that newapkbuild still generates APKBUILDs with Release/release as buildtype for CMake/Meson
2020-03-23 10:51:09 <Cogitri> There are also loads of MRs awaitin a merge
2020-03-23 10:55:05 <Ariadne> i think if people want things done, they should do them and open discussions on mailing list to see if consensus exists if they are unsure
2020-03-23 10:58:02 <Cogitri> Well, I don't have commit permissions to abuild
2020-03-23 11:00:47 <Cogitri> So I can't really do anything about that without someone to merge the things
2020-03-23 11:01:31 <Ariadne> no, of course not.  but abuild is just a software.
2020-03-23 11:01:42 <Ariadne> i meant in the general sense
2020-03-23 11:04:04 <Cogitri> Uhh..sure, discussing changes which need more input from others sounds good
2020-03-23 11:08:08 <Thermi> fabled: I noticed that bootstrap.sh doesn't work correctly if you try to resume building after it failed at some package. It causes makedepends errors. I don't know if it's because some packets are left in the host apk database or not. Deleting sysroot doesn't help. To make it work again, I have to at least create a new docker container, remove the packages directory and the sysroot, then start anew. That's slightly annoying to say the least. :/
2020-03-23 11:09:01 <fabled> Thermi, depends on the when exactly it gets interrupted. but it's likely due to the host cross compiler or similar
2020-03-23 11:09:20 <Thermi> fabled: It's always due to a problem with the package or its source files
2020-03-23 11:09:29 <Thermi> Never due to the host compiler actually screwing up
2020-03-23 11:09:45 <fabled> yes, i mean that there's stuff left in the host installed
2020-03-23 11:09:51 <fabled> likely wrong cross-compiler
2020-03-23 11:10:09 <Thermi> But the cross compiler is always the same one?
2020-03-23 11:10:24 <fabled> no
2020-03-23 11:10:31 <fabled> well
2020-03-23 11:10:41 <fabled> gcc-pass2-$TARGET is created first
2020-03-23 11:10:44 <Thermi> Well, yeah
2020-03-23 11:10:47 <fabled> only later gcc-$TARGET
2020-03-23 11:10:48 <Thermi> it fails after that at some point
2020-03-23 11:10:53 <fabled> they conflict each other
2020-03-23 11:10:56 <Thermi> after the cross compiler was already built
2020-03-23 11:11:02 <Thermi> and the last stage one was installed
2020-03-23 11:11:10 <Thermi> it's in the big package list at the end of bootstrap.sh
2020-03-23 11:11:15 <Thermi> that's where it fails
2020-03-23 11:11:32 <Thermi> e.g. fortify-headers or one of the kernel packages if I much around with that
2020-03-23 11:37:58 <J_Alpit> Hi, my first contact with alpine linux. One first question I did not see yet answered. Does alpine has support for bluetooth low energy?
2020-03-23 11:39:30 <Cogitri> I don't know bluetooth on the desktop too well, but since we package bluez I don't see why we wouldnt
2020-03-23 11:40:21 <J_Alpit> Great!
2020-03-23 11:40:46 <Cogitri> My HP Stylus thingie connected just fine with my Spectre X360 and I think that uses BLE, so I think it should work
2020-03-23 11:41:19 <J_Alpit> By the way, is bluez considered a kernel module (GPL exception applied) or a regular GPL program?
2020-03-23 11:42:22 <Cogitri> I don't know the licensing situation around the GPL that well, but bluez is a seperate packagefrom the kernel, so I'd guess it's the latter
2020-03-23 11:45:44 <J_Alpit> Is t possible to install alpine without graphic console?
2020-03-23 11:46:07 <Thermi> Yes
2020-03-23 11:48:20 <fabled> Cogitri, added apk.pc in follow up commit (credited it to you); seems I forgot it in the original commit....
2020-03-23 11:49:39 <J_Alpit> Great! What about stability? can it replaces ubuntu as an application server (port 80)?  :-)
2020-03-23 11:51:38 <Cogitri> fabled: Oh, thank you: )
2020-03-23 11:52:03 <mps> J_Alpit: this channel is for development and you will hear only praises
2020-03-23 11:52:24 <Cogitri> Can you maybe also take a look at https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10676? I currently need to re-write some stuff in D because it's only available in the headers and as such not available in libapk (and other langs)
2020-03-23 11:52:44 <Cogitri> J_Alpit: It'd be appreciated if you could switch to #alpine-linux for user questions :)
2020-03-23 11:53:53 <J_Alpit> Sorry, moving now...
2020-03-23 11:56:10 <timlegge> perl-chi from !5717 does not seem to have made it to the x86_64 packages.  The rest of the arches are there
2020-03-23 12:49:05 <Cogitri> _ikke_: https://gitlab.alpinelinux.org/liske/aports
2020-03-23 12:52:50 <_ikke_> done
2020-03-23 12:54:32 <Cogitri> Thanks
2020-03-23 13:58:43 <_ikke_> TBK[m]: rsyslog checksum failures
2020-03-23 14:00:23 <Cogitri> I think that's the builders?
2020-03-23 14:00:31 <Cogitri> It worked just fine for me on a local compile
2020-03-23 14:00:55 <Cogitri> Although it is weird that all of them fail, huh
2020-03-23 14:01:47 <Cogitri> Just deleted the distfile and fetched it again, the checksum still works for me 🤔
2020-03-23 14:17:24 <_ikke_> Abuild renames the files when checksums mismatch, so it would be downloaded again each time
2020-03-23 14:19:12 <Cogitri> Ah yes, but if I had a distfile downloaded that maches the checksum abuild doesn't download it again
2020-03-23 14:19:31 <Cogitri> I though that maybe upstream changed the checksum between the time I downloaded the rsyslog tarball and us merging that MR
2020-03-23 14:19:38 <Cogitri> But it appears that's not the case?
2020-03-23 14:23:44 <Hello71> mysterious checksum failures from different locations? my money is on poorly programmed WAFs
2020-03-23 14:26:07 <ncopa> Cogitri: re b3885777f00606b1f3e553143ad336afa267a46e, you could have don the chrpath in the package() function. then you wouldnt need set LD_LIBRARY_PATH for check.
2020-03-23 14:26:13 <timlegge> Had to submit  !5727 to bump versions as a bunch of packages chhanged in !5717 never made it to x86_64 and stayed in testing
2020-03-23 14:28:41 <Cogitri> ncopa: Yes, but the binaries actually had a RPATH to the stage1 libs
2020-03-23 14:28:45 <Cogitri> Which isn't what we want anyway
2020-03-23 14:29:04 <Cogitri> (We want to test against the final libs that are actually installed and not the stage1 libs)
2020-03-23 14:29:15 <Cogitri> I guess I should've noted that in the commit, sorry about that
2020-03-23 14:32:58 <ncopa> no worries
2020-03-23 14:49:39 <mps> ncopa: 3.11 release need ncurses fix
2020-03-23 14:50:00 <mps> before next 3.11.5 I mean
2020-03-23 14:51:01 <mps> just got 'tset: unknown terminal type vt100' on login over serial console on armv7 SBC
2020-03-23 14:52:44 <mps> ncopa: maxice8: !5446
2020-03-23 14:52:53 <maxice8> @mps yes ?
2020-03-23 14:52:56 <maxice8> want me to backport it ?
2020-03-23 14:53:04 <mps> please comment
2020-03-23 14:53:12 <mps> review*
2020-03-23 14:54:03 <mps> if you think it is not ok then you need add vt100 (and some other) to ncurses-terminfo-base
2020-03-23 14:54:44 <mps> but, yes, this MR or something other should be backported to 3.11
2020-03-23 14:56:02 <mps> I'm going to bacpkport (after coffee :) ) !5446 locally and test to see if it will fix issue
2020-03-23 14:57:33 <maxice8> eeeeh, looks fine to me assuming you fixed the problem i pointed out in my last comment
2020-03-23 15:00:36 <mps> not sure 100% but it works on my current box
2020-03-23 15:01:02 <mps> i.e, no ncurses-terminfo, only ncurses-terminfo-base
2020-03-23 15:01:17 <mps> and building for armv7 to test
2020-03-23 15:02:04 <maxice8> works for me, i only use linux and alacritty
2020-03-23 15:02:37 <mps> well, I use more of them for different case
2020-03-23 15:16:34 <mps> yes, it works on armv7 over serial console, using screen as serial terminal emulator. i.e. found vt100
2020-03-23 15:38:43 <timlegge> maxice8 I saw your comment on !5727.  I'm trying to resolve https://pkgs.alpinelinux.org/packages?name=perl-chi&branch=edge
2020-03-23 15:39:28 <timlegge> most of the arches moved to community but several stayed in testing
2020-03-23 17:06:12 <mps> is pkgname-5.6-rc5-r0 valid version for apk
2020-03-23 17:06:40 <mps> 'r' two times after '-'
2020-03-23 17:06:46 <_ikke_> I don't think so
2020-03-23 17:06:59 <_ikke_> there is apk version -c / -t
2020-03-23 17:07:17 <mps> yes, I checked
2020-03-23 17:08:06 <mps> what about linux-rc-5.6-r0
2020-03-23 17:08:36 <Hello71> shouldn't it be _rc6
2020-03-23 17:08:38 <Hello71> 5
2020-03-23 17:08:39 <mps> no, doesn't make sense to follow version
2020-03-23 17:08:58 <_ikke_> yes _rc5 is valid
2020-03-23 17:09:17 <mps> Hello71: I tested _ and it works, but is somewhat ugly (for me at least)
2020-03-23 17:09:29 <_ikke_> it's just how it's supposed to be
2020-03-23 17:09:29 <mps> _r
2020-03-23 17:10:15 <Hello71> according to https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgver it is not valid to have letters then numbers in pkgver
2020-03-23 17:11:12 <mps> all letter works except 'r'
2020-03-23 17:11:27 <mps> it is reserved for pkgrel
2020-03-23 17:15:14 <ncopa> pkgname-5.6-rc5-r0 is not really a valid version
2020-03-23 17:15:34 <ncopa> if its accepted, then it takes -rc5-r0 as revision number
2020-03-23 17:16:17 <mps> I know, but had hope that there is 'trick' which can be used
2020-03-23 17:16:41 <_ikke_> yes, using _ :)
2020-03-23 17:16:53 <mps> :)
2020-03-23 17:16:57 <Hello71> hm, I forgot, you can't use ${a/b/c} expansion in APKBUILD can you
2020-03-23 17:17:10 <_ikke_> We do allow that
2020-03-23 17:17:22 <ncopa> you can use it, but better avoid if possible
2020-03-23 17:17:22 <Hello71> oh. I was thinking that if you wan't do that then it's kind of annoying
2020-03-23 17:17:41 <Hello71> ${_pkgver/-/_}?
2020-03-23 17:17:51 <Hello71> what's wrong with that
2020-03-23 17:18:41 <ncopa> what is "wrong" is that it is not posix shell, but it is supported by busybox ash so we tolerate it for now
2020-03-23 17:18:44 <mps> there are APKBUILDs with this
2020-03-23 17:19:08 <_ikke_> and the alternative is expensive
2020-03-23 17:19:25 <_ikke_> we also allow local, which is also not posix
2020-03-23 17:19:57 <ncopa> yup. its kinda useful
2020-03-23 17:20:00 <Cogitri> Yup, I think it's the best thing we can do
2020-03-23 17:20:03 <ncopa> even dash supports local
2020-03-23 17:20:15 <Cogitri> Using tr or something for splitting is annoying and expensive
2020-03-23 17:20:35 <ncopa> you can use 2-3 lines instead:
2020-03-23 17:20:54 <_ikke_> Yes, ncopa wants to avoid forking in the global scope, because tools like ap source all APKBUILDs
2020-03-23 17:21:40 <ncopa> _ver=${pkgver%-*}; _suffix=${pkgver##*-}; _newver=${_ver}_$suffix
2020-03-23 17:21:42 <Hello71> *everybody* wants to avoid forking in global scope. even gentoo mess does
2020-03-23 17:22:15 <Hello71> ncopa: cool, now do ${a//b/c} ;)
2020-03-23 17:22:44 <ncopa> thats trickier
2020-03-23 17:23:16 <Hello71> I mean, I'm sure you can do it with a loop
2020-03-23 17:23:28 <Hello71> but like... ow
2020-03-23 17:23:28 <Cogitri> Let's please keep the de-facto standard thing :)
2020-03-23 17:23:54 <ncopa> we should try get those into posix ;)
2020-03-23 17:24:11 <Hello71> another option is to have a global helper function
2020-03-23 17:27:05 <Cogitri> Which would mean moving from a de-facto standard to something custom
2020-03-23 17:27:13 <Cogitri> And changing many, many APKBUILDs
2020-03-23 17:27:55 <ncopa> i have though about global helper funcs
2020-03-23 17:28:06 <ncopa> but regardless what we do, its messy or hackish
2020-03-23 17:28:12 <Cogitri> Yup
2020-03-23 17:28:40 <ncopa> so i think its better to support ${a/b/c} (and local)
2020-03-23 17:28:47 <ncopa> but avoid if possible
2020-03-23 17:29:15 <ncopa> i mean, avoid when its easy to do so
2020-03-23 17:29:16 <_ikke_> But most of the time when you use it, it's not avoidable
2020-03-23 17:29:19 <Cogitri> Yes
2020-03-23 17:29:30 <Cogitri> I don't think we use those in avoidable cases often
2020-03-23 17:30:09 <Cogitri> For something completely different: Thanks for looking at abuild, ncopa. Maybe you could take a look at https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/35 and tag a new release afterwards?
2020-03-23 17:30:35 <Hello71> well that just raises the question of what is "avoidable". with the pkgver you can surely manually write one variable with - and one with _ when you bump
2020-03-23 17:30:38 <Hello71> it's just a pain
2020-03-23 17:36:26 <u0jQx9gPyrYg> i have a strange heisenbug while trying to package the intel openCL runtime: in the unittests this sigaction(SIGSEGV, &pageFaultManagerHandler, &previousHandler); is installed, and then triggered with std::raise(SIGSEGV);, and then checked if the sighandler was indeed invoked. randomly (about 1 in 2-3 attempts) this fails, an instead throws a segfault. any idea why this is so
2020-03-23 17:36:28 <u0jQx9gPyrYg> non-deterministic?
2020-03-23 17:37:00 <u0jQx9gPyrYg> when i try the same under gdb, the tests always succeed
2020-03-23 17:40:36 <timlegge> ncopa:  https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/35 introduces a depend on MetaCPAN::Client.  I am moving it to community today but should it go to main?
2020-03-23 17:41:33 <ncopa> timlegge: yes, it should go to main
2020-03-23 17:42:42 <timlegge> ncop: okay.  Will get it and its depends moving. to main tonight
2020-03-23 17:43:25 <timlegge> s/ncop:/ncopa:/
2020-03-23 17:43:25 <alpine-meetbot> timlegge meant to say: ncopa: okay.  Will get it and its depends moving. to main tonight
2020-03-23 17:43:37 <Hello71> u0jQx9gPyrYg: probably you have a double segfault
2020-03-23 17:44:02 <Hello71> can be caused by out of stack space
2020-03-23 17:45:27 <u0jQx9gPyrYg> the unittest does not really exhaust stackspace
2020-03-23 17:45:39 <u0jQx9gPyrYg> its a quite simple one, in a seperate executable
2020-03-23 17:45:49 <mps> ncopa: we need to fix ncurses for 3.11
2020-03-23 17:46:11 <ncopa> mps: what is the problem with ncurses for 3.11?
2020-03-23 17:46:19 <mps> does it makes sense to simply backport it from edge
2020-03-23 17:46:38 <ncopa> depends on the problem and how intrusive the changes in edge are
2020-03-23 17:46:47 <mps> some terminfo are 'lost', vtXXX and maybe something else
2020-03-23 17:46:54 <ncopa> we want avoid unexcpected surprises
2020-03-23 17:47:04 <ncopa> do we have an issue with the details?
2020-03-23 17:47:16 <mps> I already backported it to my two machines
2020-03-23 17:47:20 <_ikke_> Was due to the symlink removal, right?
2020-03-23 17:48:34 <mps> no, because we wanted to get rid of big ncurses-terminfo, and make ncurses to dopend only on ncurses-terminfo-base
2020-03-23 17:49:22 <ncopa> i dont think we want to make that kind of changes in stable branch
2020-03-23 17:49:24 <mps> but that could lead to problem with some other pkgs which depends on ncurses-terminfo
2020-03-23 17:49:33 <mps> ok
2020-03-23 17:49:55 <mps> than we need to add vt100 at least to it
2020-03-23 17:50:26 <_ikke_> mps: iirc, that was done by removing a symlink that caused abuild to add it as a dependency
2020-03-23 17:50:49 <mps> _ikke_: yes
2020-03-23 18:03:27 <mps> got 5.6-rc7 kernel built with APKBUILD working on allwinner A20, though with some quirks
2020-03-23 18:18:33 <timlegge> ncopa: I rebased  https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/35 so it will merge
2020-03-23 19:33:32 <ncopa> mps: can you please test -pre release? 20200323 https://dev.alpinelinux.org/~ncopa/armv7/out/
2020-03-23 19:35:31 <mps> in a half hour, if this is ok?
2020-03-23 19:35:48 <mps> I'm out of home right now
2020-03-23 19:39:46 <mps> does armv7 works on RPi zero?
2020-03-23 19:39:56 <ncopa> ok. np. the x86_64 build is not done yet anyway
2020-03-23 19:40:04 <mps> I tested only armhf on RPi zero
2020-03-23 19:45:41 <ncopa> hum, the build is wrong
2020-03-23 19:46:12 <ncopa> didnt pick up the new kernel
2020-03-23 19:47:44 <mps> ah
2020-03-23 20:00:21 <ncopa> it has been updated. i tested the alpine-rpi armv7 on rpi4
2020-03-23 20:00:27 <ncopa> it boots and installer passes
2020-03-23 20:01:12 <ncopa> mps: in case you want test the armv7 lts kernel: https://dev.alpinelinux.org/~ncopa/armv7/
2020-03-23 20:05:49 <mps> ncopa: does serial console works in your test
2020-03-23 20:13:26 <ncopa> i havent tested
2020-03-23 20:13:38 <ncopa> but i got impatient. and pushed 3.11.5 already
2020-03-23 20:17:18 <mps> on allwinner a20 kernel boot, rootfs mounted => EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
2020-03-23 20:17:35 <mps> oh
2020-03-23 20:17:40 <mps> :/
2020-03-23 20:17:54 <mps> mkdir: can't create directory '/sysroot//proc': Read-only file system
2020-03-23 20:20:03 <ncopa> was that introduced with 3.11.5?
2020-03-23 20:20:03 <Hello71> Opts: (null)
2020-03-23 20:20:19 <ncopa> was that introduced with this kernel?
2020-03-23 20:20:25 <mps> ncopa: I think so, but not sure
2020-03-23 20:20:44 <Hello71> huh, apparently it's supposed to be (null)
2020-03-23 20:20:50 <ncopa> does release notes look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.5-released.html
2020-03-23 20:20:51 <mps> now only can wait for release tarball and check
2020-03-23 20:21:10 <ncopa> mps: you can test the 3.11.3 release tarball, to compare
2020-03-23 20:21:34 <mps> yes, I will
2020-03-23 20:23:45 <mps> creating mmc card
2020-03-23 20:26:14 <mps> uh, downloaded wrong tarball
2020-03-23 20:30:42 <ncopa> release tarballs should be available now
2020-03-23 20:32:16 <mps> congrats :)
2020-03-23 20:32:40 <mps> now I will test rpi zero
2020-03-23 20:33:17 <Cogitri> Nice :)
2020-03-23 20:42:23 <mps> rpi zero boots: Kernel 5.4.27-0-rpi on an armv6l (/dev/ttyAMA0)
2020-03-23 20:42:43 <ncopa> ok, only the last item on release checklist is left: celebrate! \o/
2020-03-23 20:42:45 <mps> cat /etc/alpine-release => 3.11.5
2020-03-23 20:43:25 <mps> wait setup-alpine && reboot finish :)
2020-03-23 20:43:28 <ncopa> thank you everyone for making alpine an awsome distro with an awesome community!
2020-03-23 20:47:22 <mps> rpi zero passed setup-alpine && reboot :)
2020-03-23 20:47:50 <mps> on serial console, I don't have micro hdmi cable
2020-03-23 20:48:43 <Hello71> rpi zero has mini hdmi
2020-03-23 20:48:59 <mps> later will check what is issue uboot-3.11.5-armv7 tarball
2020-03-23 20:49:07 <Cogitri> ncopa: Thanks for taking care of the release :)
2020-03-23 20:49:29 <mps> Hello71: something small, yes. I thought it is micro
2020-03-23 20:52:27 <mps> and 'lbu commit -e' now works :)
2020-03-23 20:54:12 <mps> I prepared script for fast install rpi zero tarballs on mmc card, now I can test release easier
2020-03-23 22:01:03 <TBK[m]> build-edge-armhf & build-edge-armv7 seems to be stuck
2020-03-23 22:04:35 <_ikke_> looking at it
2020-03-23 22:06:02 <TBK[m]> ah at last an error message
2020-03-23 22:07:59 <TBK[m]> _ikke_: I guess you prodded them in some way :)
2020-03-23 22:07:59 <_ikke_> yes, killed the process
2020-03-23 22:08:03 <_ikke_> yup
2020-03-23 22:18:25 <mps> ncopa: alpine-uboot-3.11.5-armv7.tar.gz is good. It was my mistake in boot parameters when tested it few hours ago
2020-03-23 22:26:34 <mps> except kernel is missing drivers and settings for sunxi (allwinner A20 and other), but that is not new
2020-03-23 23:42:46 <Hello71> ncopa: how do you feel about using somask to hide optional dependencies
2020-03-24 08:27:45 <Ariadne> going to do a mass rebuild using rootbld soon
2020-03-24 08:28:06 <Ariadne> as soon as the prerequisite equipment isn't folding covid-19 proteins anyway
2020-03-24 08:46:01 <TBK[m]> What command do I need to use to get build-3-11-s390x to retry?
2020-03-24 08:48:01 <ncopa> TBK[m]: algitbot: retry 3.11-stable
2020-03-24 08:48:36 <TBK[m]> ncopa: thanks :)
2020-03-24 08:52:28 <ncopa> Hello71: how do you define optional dependencies?
2020-03-24 08:53:02 <ncopa> i think optional dependencies can be splitted into subpackages
2020-03-24 08:55:20 <Cogitri> Ariadne: Good luck, loads of stuff doesn't specify options="net" right now
2020-03-24 08:55:50 <Ariadne> Cogitri: yes, the goal of the exercise is to identify and fix those packages
2020-03-24 08:56:51 <Cogitri> Okie
2020-03-24 08:57:40 <ncopa> Ariadne: awesome! thanks!
2020-03-24 08:59:57 <Ariadne> as well as find other weirdness in packages
2020-03-24 09:00:17 <Ariadne> like main/gcr depending on d-bus being pre-configured :P
2020-03-24 09:00:26 <Ariadne> not sure what to do about that one
2020-03-24 09:02:16 <Cogitri> It's not gcr
2020-03-24 09:02:27 <Cogitri> It's every package that needs dbus for tests
2020-03-24 09:04:46 <_ikke_> Would be nice to have something like xvfb for dbus
2020-03-24 09:05:01 <Cogitri> There is, dbus-launch
2020-03-24 09:05:11 <Ariadne> aha
2020-03-24 09:05:12 <Cogitri> But that needs the machine-id
2020-03-24 09:05:23 <Cogitri> And we moved the generation of that to the init.d script instead of having it in the post-install hook for some reason
2020-03-24 09:05:29 <Ariadne> Cogitri: i think we should revert this machine-id change
2020-03-24 09:05:34 <Ariadne> :)
2020-03-24 09:05:53 <Ariadne> you certainly have *my* blessing to do so
2020-03-24 09:05:58 <Cogitri> First, we should see why the change was made
2020-03-24 09:06:11 <Cogitri> I think we shouldn't be too trigger happy about reverting stuff
2020-03-24 09:06:17 <Ariadne> well
2020-03-24 09:06:24 <Ariadne> that is predecated with
2020-03-24 09:06:31 <Ariadne> fixing whatever defect caused it to be changed to begin with
2020-03-24 09:06:32 <_ikke_> I think because people don't want to have this machine-id automatically generate if they don't use dbus
2020-03-24 09:06:36 <Ariadne> obviously :)
2020-03-24 09:06:44 <Cogitri> It's a <1KB text file
2020-03-24 09:06:51 <Cogitri> It really doesn't matter having that
2020-03-24 09:07:06 <_ikke_> It's about (perceived) privacy, not filesize
2020-03-24 09:07:31 <Cogitri> Then they should echo "please break my dbus" > /var/lib/dbus/machine-id
2020-03-24 09:07:35 <Ariadne> the machine-id is not shared with any third parties
2020-03-24 09:07:42 <Cogitri> The DBus ID really doesn't have *anything* to do with privacy
2020-03-24 09:07:54 <Ariadne> yeah, it's just for conflict resolution
2020-03-24 09:08:06 <Ariadne> so you dont have two dbus with the same ID
2020-03-24 09:08:15 <Cogitri> If that's the reason then let's revert it, I suppose.
2020-03-24 09:08:51 <Cogitri> It breaks tests on CI for all packages which need dbus right now
2020-03-24 09:08:54 <_ikke_> How can you have two dbus instances?
2020-03-24 09:09:09 <Ariadne> most systems have two
2020-03-24 09:09:13 <Ariadne> one for session
2020-03-24 09:09:15 <Ariadne> one for system-wide
2020-03-24 09:09:19 <_ikke_> ah ok
2020-03-24 09:09:32 <Ariadne> every d-bus has its own id
2020-03-24 09:09:41 <Ariadne> i am calling it d-bus on purpose
2020-03-24 09:09:45 <_ikke_> but wouldn't the machine-id be the same then?
2020-03-24 09:09:49 <Ariadne> no
2020-03-24 09:09:55 <Ariadne> the machine-id is the uuid for the system bus
2020-03-24 09:10:02 <Ariadne> its complicated
2020-03-24 09:10:04 <Ariadne> it's d-bus
2020-03-24 09:10:07 <Ariadne> it's crap
2020-03-24 09:10:30 <Ariadne> just smile, put  your fingers in your ears and say lalalalala until the freedesktop.org representative walks away
2020-03-24 09:10:35 <Cogitri> (It's actually kinda nice if you want to do IPC)
2020-03-24 09:10:59 <Ariadne> i mean, sure
2020-03-24 09:11:21 <Ariadne> but if you don't, just follow above advice
2020-03-24 09:11:25 <maxice8> i'm going to release mkmr 0.0.11 soonish
2020-03-24 09:11:27 <Cogitri> Anyway, can you maybe revert that change and close the gcr issue then? Next lesson (aka. Zoom meeting) starts soon for me.
2020-03-24 09:11:52 <Ariadne> Cogitri: yes i will sort it
2020-03-24 09:12:08 <Cogitri> Thank you :)
2020-03-24 09:12:45 <Ariadne> ohh
2020-03-24 09:12:46 <Ariadne> uhh
2020-03-24 09:12:50 <Ariadne> thats not why at all
2020-03-24 09:13:04 <Ariadne> the startup script part is a backup
2020-03-24 09:13:20 <Ariadne>       Failed to generate UUID: Could not open /dev/urandom: No such file or directory
2020-03-24 09:13:20 <Ariadne>       ERROR: dbus-1.12.16-r0.post-install: script exited with error 1
2020-03-24 09:13:22 <Ariadne> this is why
2020-03-24 09:13:48 <Cogitri> Our builders don't have /dev/urandom?
2020-03-24 09:13:53 <Ariadne> no
2020-03-24 09:13:59 <Ariadne> when doing apk add --root ...
2020-03-24 09:14:03 <Ariadne> there is no /dev/urandom
2020-03-24 09:14:54 <Cogitri> But that did work on the other builders before we changed it, didn't it?
2020-03-24 09:17:02 <Ariadne> yes
2020-03-24 09:17:11 <Ariadne> however, my point is
2020-03-24 09:17:32 <Cogitri> Well, either we enable dbus on the mips64 builder too or we distribute a dummy machine-id, I suppose.
2020-03-24 09:17:33 <Ariadne> to resolve the original concern, we need to make sure /dev/urandom is present in apk --root
2020-03-24 09:17:52 <Ariadne> no
2020-03-24 09:17:59 <Ariadne> that's not the proble
2020-03-24 09:18:00 <Ariadne> m
2020-03-24 09:18:06 <Ariadne> i can generate a machine-id who cares
2020-03-24 09:18:16 <Ariadne> the problem that lead to this commit being made
2020-03-24 09:18:25 <Ariadne> is if you do apk add --root whatever dbus-thing-here
2020-03-24 09:18:28 <Ariadne> you get that ERROR
2020-03-24 09:18:53 <Ariadne> anyway ...
2020-03-24 09:18:56 <Cogitri> Not with our current dbus package which only generates the machine-id via init.d though?
2020-03-24 09:19:04 <Cogitri> So if we keep that as--
2020-03-24 09:19:07 <Ariadne> yeah
2020-03-24 09:19:16 <Cogitri> as-is we can distribute a dummy machine-id or smth
2020-03-24 09:19:21 <Ariadne> sure
2020-03-24 09:19:23 <Ariadne> works for me
2020-03-24 09:19:55 <Cogitri> Good. Would we need to detect in the init.d script if the dummy ID is present and overwrite that?
2020-03-24 09:20:00 <Ariadne> yes
2020-03-24 09:20:08 <Cogitri> Okie
2020-03-24 09:31:04 <Ariadne> so anyway it's d-bus
2020-03-24 09:31:06 <Ariadne> and x-windows
2020-03-24 09:31:26 <Ariadne> if you refer to these as such, it will keep the freedesktop.org people away from you
2020-03-24 09:31:31 <Ariadne> it's like a spray bottle
2020-03-24 09:34:56 <Cogitri> DBus certainly does look nicer
2020-03-24 09:35:31 <Ariadne> it's like garlic and vampires
2020-03-24 09:35:53 <Ariadne> ncopa: regarding the python bluetooth.h thing
2020-03-24 09:36:04 <Ariadne> ncopa: there's not really anything for upstream toc omment on
2020-03-24 09:36:33 <Ariadne> ncopa: upstream's position will be "install bluez first you idiots", to which you need python3 to install bluez
2020-03-24 09:36:48 <Ariadne> because parts of bluez dep chain are now built using meson
2020-03-24 09:37:12 <Ariadne> and as such this is why i have a love-hate relationship with meson
2020-03-24 09:40:03 <Cogitri> Well, !5722 works around that AFAICS
2020-03-24 09:42:18 <Ariadne> nini
2020-03-24 09:50:05 <ncopa> im looking at the dbus uudi thing now
2020-03-24 09:50:44 <Cogitri> Thank you
2020-03-24 09:51:07 <ncopa> dbus code has lots of function with _ prefix
2020-03-24 09:51:12 <ncopa> which is reserved
2020-03-24 09:54:20 <Cogitri> C is fun :^)
2020-03-24 10:40:24 <Cogitri> andypost[m]: I'm getting `PHP Warning:  Version warning: Imagick was compiled against ImageMagick version 1801 but version 1802 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0` on Edge right now 🤔
2020-03-24 10:40:34 <Cogitri> I did restart php-fpm after the recent php upgrade
2020-03-24 10:51:03 <_ikke_> maybe php needs to be rebuilt against the latest imagemagick?
2020-03-24 10:51:11 <_ikke_> andypost[m]: ^ ?
2020-03-24 10:55:57 <Cogitri> Seems like rebuilding php7-pecl-imagick fixed it
2020-03-24 10:56:22 <_ikke_> ah right, they are separate modules
2020-03-24 10:57:54 <Cogitri> !5760
2020-03-24 11:50:35 <Cogitri> Does someone happen to know FUSE? It appears it's somewhat broken on musl so we have to disable FUSE useable in flatpak-builder for now (!5738)
2020-03-24 12:22:11 <Hello71> fuse has always been weirdly broken with any unconventional build system... as I recall, on Gentoo, if you build fuse with ld.gold you also get some sort of mysterious runtime issues
2020-03-24 12:26:25 <Hello71> also, about the dbus machine-id: one reason to do it in init.d instead of post-install is that this decreases the odds of people accidentally cloning a bunch of machines with identical machine-id.
2020-03-24 12:26:41 <PureTryOut[m]> Hmm abuild complains about an invalid pkgconf version (it has a + in it), but this is just what upstream has it set too... https://git.sailfishos.org/mer-core/usb-moded/commit/c0302c87a45eacc8ea237f89f8d4743f07a3e38f
2020-03-24 12:27:09 <Hello71> otoh that's mostly an issue with systemd, where machine-id is used for a bunch of other stuff. with dbus it's not really an issue because nobody uses dbus over network anyways
2020-03-24 12:27:52 <Cogitri> Without wanting to be harsh, but I'd count that as user error
2020-03-24 12:28:49 <_ikke_> counterpoint, we generate ssh host keys on service init
2020-03-24 12:29:56 <PureTryOut[m]> Actually, everything after "0.86.0" seems to be invalid
2020-03-24 13:23:51 <Cogitri> Huh, that sure is a weird version spec
2020-03-24 13:24:13 <Cogitri> We usually consider + invalid since that's for vendor specific versions (e.g. Ubuntu uses +$ver for Ubuntu version increases)
2020-03-24 13:31:34 <PureTryOut[m]> It doesn't like the "mer" bit either, just replacing + for e.g. a - doesn't help
2020-03-24 13:31:46 <Cogitri> Oh :/
2020-03-24 13:31:46 <PureTryOut[m]> For now I just patched the file to just be "0.86.0"...
2020-03-24 13:32:59 <Cogitri> Should probably be 0.86.0.<merver> I guess?
2020-03-24 13:33:36 <PureTryOut[m]> Idk maybe
2020-03-24 13:38:30 <z3ntu> PureTryOut: in pmaports we have a few packages where that version gets fixed up, e.g. mesa-git (with a -devel suffix or something)
2020-03-24 14:05:41 <ncopa> What is "mer" in there?
2020-03-24 14:05:48 <ncopa> +mer...
2020-03-24 14:06:27 <PureTryOut[m]> I guess the Mer project at some point forked the package from somewhere else and now they version it with mer to indicate it's a Mer package? Idk
2020-03-24 14:06:52 <ncopa> how should pkg-config --atleat-version or --max-version compare +mer4 with +git4?
2020-03-24 14:09:41 <PureTryOut[m]> Idk. I'm pretty sure the version they use is invalid so it's not an abuild problem
2020-03-24 14:34:53 <ncopa> should report it upstream i guess
2020-03-24 14:38:20 <Cogitri> mforney: Can you take a look at #11325 ? It appears this only happens with Samu
2020-03-24 14:38:24 <Cogitri> It works just fine with Ninja.
2020-03-24 14:39:21 <mps> isn't meson some microsoft build tool?
2020-03-24 14:39:54 <Cogitri> ...no
2020-03-24 14:40:02 <ncopa> :D
2020-03-24 14:41:07 <mps> there are more than one 'meson' term in IT, so I'm puzzled
2020-03-24 14:46:37 <maxice8> no
2020-03-24 14:47:40 <maxice8> meson is a build system and there is meson-tools which is "Tools of Amlogic Meson ARM platforms"
2020-03-24 15:09:42 <artok> mps reason for rpi4 not booting after kernel upgrade might be: kernel image creates new overlays under dtbs-rpi4 directory on /boot, not into /boot (root of the vfat on sdcard)
2020-03-24 15:10:10 <artok> another "copy one directory up" thingie
2020-03-24 15:10:17 <artok> s/copy/move
2020-03-24 15:10:18 <alpine-meetbot> artok meant to say: another "move one directory up" thingie
2020-03-24 15:10:53 <mps> artok: could be, you can test you have board
2020-03-24 15:11:34 <mps> and, yes, your note sounds right
2020-03-24 15:12:26 <mps> hmm, right: local INSTALL_DTBS_PATH="$_outdir"/boot/dtbs-$_buildflavor
2020-03-24 15:12:41 <artok> yah, that is wrong
2020-03-24 15:13:44 <mps> <nitpick mode> it is not wrong, RPi is wrong
2020-03-24 15:14:11 <mps> rpi bootloader*
2020-03-24 15:14:29 <artok> as the "kernel and initramfs can't be inside subfolder"
2020-03-24 15:15:17 <mps> on rpi zero they are under subfolder^Wsubdir
2020-03-24 15:23:05 <mps> rpi (company) have to give job to one of the alpine developers
2020-03-24 15:28:15 <artok> aand then there is something with firmware that is not good..
2020-03-24 15:32:51 <artok> ah that's because they're older ones
2020-03-24 15:34:32 <mps> sorry for grumpy OT, that is because they are based on broadcom chips, which are mostly closed
2020-03-24 15:34:59 <artok> totally understood that one
2020-03-24 15:57:14 <artok> and now, firefox crashes when ever trying to write password to any login
2020-03-24 16:05:47 <Cogitri> Huh, that reminds me of #10451, artok
2020-03-24 16:06:02 <Cogitri> It's weird that I haven't been hit with that issue once across my machines 🤔
2020-03-24 16:12:42 <PureTryOut[m]> Oh I had that problem, but was fixed since upgrading to latest version
2020-03-24 16:31:23 <artok> that is totally the one
2020-03-24 16:32:48 <artok> ...but 68.6.0esr
2020-03-24 16:33:59 <Cogitri> Ah, I only ever use FF non esr
2020-03-24 16:34:46 <artok> well esr is dying
2020-03-24 16:34:54 <artok> this time
2020-03-24 16:41:27 <artok> eh..I'm getting flatpak stuff on the error also
2020-03-24 16:42:12 <artok> https://hastebin.com/anediduyus.pl
2020-03-24 16:43:23 <mps> esr works fine for me
2020-03-24 16:48:05 <artok> flatpak installed 75 works
2020-03-24 17:58:47 <kpcyrd> does linux-vanilla still exist? I can't find it in edge and the link at https://wiki.alpinelinux.org/wiki/Kernels is dead
2020-03-24 18:08:33 <_ikke_> I think it was removed
2020-03-24 18:08:40 <_ikke_> It's basically linux-lts now
2020-03-24 18:16:36 <kpcyrd> _ikke_: not sure how old my VM is, but it's still on linux-vanilla, should I uninstall it and install -lts instead?
2020-03-24 18:16:56 <_ikke_> Yes, that would make sense
2020-03-24 18:17:31 <mps> kpcyrd: you can install -lts besides -vanilla, have it as rescue kernel
2020-03-24 18:22:50 <kpcyrd> how do I select the kernel that is automatically booted?
2020-03-24 18:23:47 <mps> in /etc/update-extlinux.conf
2020-03-24 18:23:56 <mps> default=lts
2020-03-24 18:25:46 <mps> or for grub in /etc/default/grub
2020-03-24 19:12:37 <mforney> Cogitri: investigating now, thanks for reporting
2020-03-24 19:16:13 <Cogitri> Thanks :l
2020-03-24 19:16:21 <Cogitri> s/l/)/
2020-03-24 19:16:22 <alpine-meetbot> Cogitri meant to say: Thanks :)
2020-03-24 19:23:13 <artok> funny.. ioctl on rpi doesn't work for re-reading usb stick partition tables
2020-03-24 19:51:21 <mforney> Cogitri: do you know if dmd has a way to output gcc-style Makefile dependencies? if it does not, meson should probably not be setting depfile in the d_COMPILER rule
2020-03-24 19:53:56 <Cogitri> "Makefile dependencies"?
2020-03-24 19:54:56 <Cogitri> Anyway, FYI there are 3 different D compilers, one of them being GDC (GCC for D), so I guess if GCC can do it GDC might too
2020-03-24 19:55:28 <Cogitri> mforney: ^ (in case you didn't see that)
2020-03-24 19:58:31 <mforney> ah, if gcc can do it, that might explain it. still though, meson has to use different options anyway, so probably should only emit depfile when the compiler supports it
2020-03-24 19:59:30 <mforney> by Makefile dependencies, i mean like how gcc can write a Makefile snippet with header dependencies using the -M option
2020-03-24 19:59:32 <Cogitri> I'm not well versed with Makefiles since I don't know what you're referring too, maybe dmd and ldc do support it
2020-03-24 19:59:48 <Cogitri> Ah, didn't now it could do that
2020-03-24 20:00:07 <Cogitri> Anyway, thanks for looking into the issue :)
2020-03-24 20:00:36 <mforney> and then you can include that snippet in your Makefile to rebuild sources when the included headers change, without having to specify that dependency explicitly
2020-03-24 20:01:00 <mforney> ninja has special support for reading the Makefile snippets so that it can have the same feature
2020-03-24 20:01:29 <_ikke_> maxice8: ping, py3-twisted is still fialing
2020-03-24 20:19:23 <oneinsect> folks any plans to shift from gcc to clang or similar?
2020-03-24 20:22:00 <Cogitri> If you give us a reason to do so, sure
2020-03-24 20:22:21 <Cogitri> I mean I do like CLang for my personal projects but right now GCC just works for us
2020-03-24 20:22:52 <Cogitri> In the long-term I would like to switch to CLang in Alpine but right now there's more important stuff to do
2020-03-24 20:23:32 <ncopa> maxice8: please dont remove dns-root-hints yet #11324
2020-03-24 20:23:56 <ncopa> i'll try comment on it tomorrow
2020-03-24 20:25:01 <mps> oneinsect: just for change? any founded reason?
2020-03-24 20:25:51 <oneinsect> not really any particular reason, clang seems a bit easier to bootstrap
2020-03-24 20:27:59 <Cogitri> It might be, but since some stuff doesn't build with CLang yet (like parts of the kernel), it will be way harder to tun CLang in the long run.
2020-03-24 20:29:47 <artok> clang easier to bootstrap than gcc? PGO optimized isn't =)
2020-03-24 20:30:02 <artok> or wasn't, haven't checked the status now
2020-03-24 20:30:18 <Cogitri> Pardon?
2020-03-24 20:30:19 <oneinsect> ummmmm
2020-03-24 20:30:26 <mps> some kind NIH sindrome
2020-03-24 20:31:18 <Cogitri> I don't think GCC supports bootstrapping w/ PGO, does it?
2020-03-24 20:31:25 <mps> (I'm not satisfied with this world, and I want to create new one, instead of help to fix current)
2020-03-24 20:31:39 <Cogitri> And if it does I don't think we use that
2020-03-24 20:31:43 <maxice8> Can you disable tests for the arches? They work on CI but not in the builders
2020-03-24 20:32:16 <artok> Cogitri: yeah no, but clang isn't that easier when you plan to take all it's powers out
2020-03-24 20:36:09 <Cogitri> Uh sure
2020-03-24 20:36:31 <Cogitri> Not that I tried to suggest that we should do that
2020-03-24 20:38:28 <artok> we just got into that topic. yes.
2020-03-24 20:39:49 <artok> and just as we speak, llvm 10 is released
2020-03-24 20:40:13 <Cogitri> Neat, gotta upgrade that at the weekend
2020-03-24 20:40:31 <Cogitri> Let's see how much stuff doesn't build against the new API :^)
2020-03-24 20:41:26 <_ikke_> maxice8: maybe it means its broken
2020-03-24 20:41:35 <_ikke_> maxice8: disabling tests justs hides broken things
2020-03-24 20:47:48 <oneinsect> in this script https://github.com/alpinelinux/aports/blob/master/scripts/bootstrap.sh line 87 which is as follows CTARGET=$TARGET_ARCH BOOTSTRAP=nobase APKBUILD=$(apkbuildname gcc) abuild -r
2020-03-24 20:47:49 <oneinsect>  however the nobase bootsrap variable is not present as a case in gcc APKBUILD
2020-03-24 20:48:12 <oneinsect> why have that variable at all in the boostrap.sh
2020-03-24 20:48:14 <oneinsect> ?
2020-03-24 20:48:28 <Cogitri> Maybe it's just cruft
2020-03-24 20:49:45 <oneinsect> hmmmm
2020-03-24 20:49:53 <_ikke_> BOOTSTRAP exists, but nobase is not being used apparently
2020-03-24 20:50:03 <oneinsect> yes correct
2020-03-24 20:50:03 <Cogitri> ikke: https://gitlab.alpinelinux.org/allgdante/aports
2020-03-24 20:50:26 <_ikke_> done
2020-03-24 20:50:33 <_ikke_> I want to make a script that just makes all aport forks pulbic
2020-03-24 20:50:41 <oneinsect> was it supposed to be used later?
2020-03-24 20:50:49 <Cogitri> Yes, I was looking into that too
2020-03-24 20:50:57 <Cogitri> But the Gitlab API isn't that nice for that use case
2020-03-24 20:51:23 <_ikke_> seriously? :(
2020-03-24 20:51:53 <_ikke_> oneinsect: not sure if that's the intention, but setting it to nobase at least excludes the nolibc case
2020-03-24 20:52:17 <oneinsect> hmmmm
2020-03-24 20:53:19 <_ikke_> checking the git history now to see if it was ever used
2020-03-24 20:54:11 <_ikke_> Hmm, no, cannot find anything having used nobase in the past
2020-03-24 20:54:49 <Cogitri> ikke: Well, I tried solving it via the MR API, maybe there's some API for repo creation too that would fit this usecase better...let's see
2020-03-24 20:54:54 <oneinsect> also how does abuild intercept the variables EXTRADEPENDS_TARGET and EXTRADEPENDS_HOST pass to it
2020-03-24 20:55:02 <oneinsect> passed*
2020-03-24 20:55:55 <Cogitri> I guess https://docs.gitlab.com/ee/api/projects.html could work for this
2020-03-24 20:57:26 <oneinsect> does it compile or install them?
2020-03-24 21:02:31 <Cogitri> ikke: Another one: https://gitlab.alpinelinux.org/uuser/aports
2020-03-24 21:02:41 <oneinsect> brb
2020-03-24 21:02:42 <Cogitri> oneinsect: I guess you'll have to check abuild's source for that
2020-03-24 21:02:54 <oneinsect> yes will do
2020-03-24 21:13:44 <maxice8> hey
2020-03-24 21:13:46 <maxice8> i need someone to host the source archive of icu from 3.8-stable
2020-03-24 21:13:46 <maxice8> it is no longer available
2020-03-24 21:13:58 <maxice8> and i need to build it again because of a security issues
2020-03-24 21:15:15 <artok> github!
2020-03-24 21:15:26 <maxice8> i mean on dev.a.o
2020-03-24 21:31:41 <artok> oh they had minor update
2020-03-24 21:33:30 <nmeum> PureTryOut[m]: do you still use snapcast? does the snapcast-client service work for you currently?
2020-03-24 21:39:23 <nmeum> hm, seems happen only when starting snapclient with -d
2020-03-24 21:41:39 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5782
2020-03-24 21:41:41 <nmeum> ^ that fixes it for me
2020-03-24 22:00:51 <nmeum> maxice8: if you agree with !5782, I can just go ahead and merge it myself ;)
2020-03-24 22:07:58 <_ikke_> maxice8: Cogitri all current aport forks should be public now
2020-03-24 22:10:00 <maxice8> sweet
2020-03-24 22:10:09 <maxice8> thanks a bunch
2020-03-24 22:10:31 <maxice8> sadly my poke kdaudt per minute ratio is ruined
2020-03-24 22:10:48 <_ikke_> :P
2020-03-24 22:45:46 <artok> mps there seems to be bunch of updates into 5.4.27 rpi
2020-03-25 00:56:48 <artok> seems that dbs etc aren't properly updated when 3.11.* is updated
2020-03-25 01:10:27 <artok> fresh install on rpi from the current package, and we're good to go
2020-03-25 07:47:33 <Cogitri> Morning
2020-03-25 07:47:46 <Cogitri> artok: That should definitely work, maybe you pinned the version?
2020-03-25 07:54:53 <PureTryOut[m]> nmeum: not atm, my server portion of it is kinda broken atm, but supervise-daemon is a good change anyway 👍️
2020-03-25 08:36:06 <_ikke_> maxice8: restarting the build container apparently fixed py3-twisted
2020-03-25 08:39:35 <Cogitri> Huh
2020-03-25 08:40:06 <_ikke_> I already stopped processed that were hanging around, but that did not help
2020-03-25 08:40:17 <_ikke_> the error was relate to 'address already in use'
2020-03-25 08:44:09 <Cogitri> So I guess the tests don't terminate properly?
2020-03-25 08:44:49 <_ikke_> I didn't see any python processes running
2020-03-25 08:55:22 <Cogitri> Huh
2020-03-25 09:13:00 <artok> Cogitri: didn't pin, to my knowledge
2020-03-25 09:16:41 <mps> artok: is the 5.4.27 rpi better than previous versions
2020-03-25 09:17:24 <mps> or worse? I didn't understood you comment
2020-03-25 09:20:15 <_ikke_> Cogitri: any idea what I could look for? netstat does not show anything, nore does htop
2020-03-25 09:21:51 <Cogitri> Not really, `sudo netstat -tulpn` usually does the trick for me
2020-03-25 09:22:13 <Cogitri> Maybe the test just doesn't like being run with too many build jobs?
2020-03-25 09:22:26 <_ikke_> But strange it works as soon as I restart the builder
2020-03-25 09:23:01 <_ikke_> It's only listening on 22
2020-03-25 09:27:34 <_ikke_> Need to find out what those tests actually are trying to do
2020-03-25 09:29:32 <artok> mps: they have changed something on their repo, just notification.
2020-03-25 09:29:44 <artok> not yet tested, build checked
2020-03-25 09:30:19 <mps> aha, who are 'they'? upstream?
2020-03-25 09:30:53 <artok> upstream..
2020-03-25 09:39:09 <mps> Cogitri: you mean to try to build !5777 in lxc?
2020-03-25 09:40:32 <Cogitri> mps: I just wanted to notify you that CI fails for your MR
2020-03-25 09:41:10 <mps> it is not my MR
2020-03-25 09:41:59 <Cogitri> Oh, derp
2020-03-25 09:42:28 <mps> and, gitlab inform creator of MR automatically if it fails for any reason
2020-03-25 09:42:42 <Cogitri> Apparently I was only half awake when looking up who the author of that MR was
2020-03-25 09:42:59 <_ikke_> https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
2020-03-25 09:43:05 <mps> take second cup of coffee :)
2020-03-25 09:43:21 <Cogitri> Yes, but I think many people either ignore those or disabled notifications for that
2020-03-25 09:43:35 <Cogitri> Heh, I've just started with my first cup :P
2020-03-25 09:44:08 <mps> notifications arrives in my mailbox, maybe people have to set it in their profile
2020-03-25 09:44:08 <PureTryOut[m]> > needing coffie to wake up
2020-03-25 09:44:13 <PureTryOut[m]> *coffee
2020-03-25 09:44:44 <mps> _ikke_: yes, interesting, I followed this on #musl
2020-03-25 09:45:46 <_ikke_> PureTryOut[m]: Your dutch is slipping out :P
2020-03-25 09:45:55 <PureTryOut[m]> Yeah I noticed that
2020-03-25 09:47:00 <mps> more natural writing grammar :)
2020-03-25 09:51:06 <mps> ncopa: does 'community/wireguard-lts: rebuild against kernel 5.4.28-r0' aarch64 fix
2020-03-25 09:58:44 <mps> hmm, this ^ is related to kernel problem not wireguard-lts, sorry for noise
2020-03-25 10:03:14 <mps> Cogitri: btw, I killed one test process which uses 'timeout' and hangs on it for !5777 and it finished build in lxc
2020-03-25 10:51:20 <mps> is it safe to remove 'cd $builddir' for pkgs in main for edge?
2020-03-25 10:52:09 <maxice8> yes
2020-03-25 10:52:46 <Cogitri> All stable releases support that now I think
2020-03-25 10:53:06 <mps> thanks
2020-03-25 11:39:24 <timlegge> I reopend !5718 to move perl-metacpan to community.   The dependencies for it finally made it to the community packages
2020-03-25 11:39:50 <timlegge> Iwill retink my initial plan to move it to main.  too many perl dependencies
2020-03-25 11:39:54 <timlegge> likely
2020-03-25 15:28:56 <Hello71> doesn't apkbuild-lint warn about that now
2020-03-25 15:29:39 <maxice8> warn about what ?
2020-03-25 15:30:09 <_ikke_> I guess cd "$builddir"
2020-03-25 15:30:18 <maxice8> yes it warns
2020-03-25 15:30:20 <Hello71> _ikke_: maybe you have SO_REUSEADDR problems
2020-03-25 15:30:53 <_ikke_> Hello71: perhaps, but at some point I think these ports should be released
2020-03-25 15:32:01 <Hello71> I think it is 2 minutes on Linux by default
2020-03-25 15:32:26 <_ikke_> Hello71: immediately after restarting the build container, the tests all passed
2020-03-25 15:32:36 <Hello71> yeah, 2*MSL=2*1=2 minutes
2020-03-25 15:33:05 <_ikke_> Hello71: and shouldn't I see those connections still in netstat?
2020-03-25 15:33:14 <Hello71> not if you put -l
2020-03-25 15:33:21 <_ikke_> I didn't
2020-03-25 15:33:27 <_ikke_> I checked both
2020-03-25 15:33:31 <Hello71> Cogitri said to put -l
2020-03-25 15:33:39 <_ikke_> yes, but I already checked it before that
2020-03-25 15:33:47 <_ikke_> both with and without
2020-03-25 15:34:18 <Hello71> yes, TIME_WAIT should be in netstat/ss. idk then
2020-03-25 15:47:11 <Cogitri> Hello71: Huh?
2020-03-25 15:53:24 <Cogitri> Ah, you mean for netstat -tulpn
2020-03-25 15:53:43 <Cogitri> Thought you were still taking about apkbuild-linter
2020-03-25 16:37:50 <artok> hmm.. ninja is under unmaintained
2020-03-25 16:39:12 <_ikke_> We switched to Samurai as drop-in replacement for Ninja
2020-03-25 16:42:20 <artok> ok
2020-03-25 16:53:18 <dalias> what is diff between ninja and samurai?
2020-03-25 16:53:38 <dalias> and why are there like 5 new ridiculous make replacements that everyone's using now?
2020-03-25 16:54:16 <_ikke_> dalias: https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E
2020-03-25 16:55:13 <dalias> oh nice
2020-03-25 16:59:09 <Cogitri> Ninja/Samu is pretty neat
2020-03-25 16:59:21 <Cogitri> (Certainly nicer than Make anyway)
2020-03-25 16:59:27 <dalias> "because
2020-03-25 16:59:27 <dalias> no one writes ninja build files by hand - they're always written by
2020-03-25 16:59:28 <dalias> tools"
2020-03-25 16:59:30 <dalias> lol
2020-03-25 16:59:38 <dalias> would that be meson or something?
2020-03-25 16:59:46 <Cogitri> Yes, Meson or CMake or smth
2020-03-25 16:59:54 <dalias> eew
2020-03-25 17:00:07 <dalias> i wish there were a replacement for cmake like samurai replaces ninja
2020-03-25 17:00:16 <Cogitri> They're usually quite a bit faster than Make
2020-03-25 17:00:18 <Cogitri> (Especially for rebuilds, although that doesn't matter much for us)
2020-03-25 17:00:20 <dalias> cmake is some gigantic c++ shit that takes like 2 hours to build
2020-03-25 17:00:33 <Cogitri> Uhh...not really, but OK
2020-03-25 17:00:35 <dalias> for what should be ~20kloc of functionality
2020-03-25 17:00:49 <dalias> building cmake takes longer than building gcc
2020-03-25 17:01:01 <Cogitri> I personally prefer Meson, but even CMake is a step up over Autotools
2020-03-25 17:01:12 <Cogitri> That's just not true, at least it's not on any of my machines
2020-03-25 17:02:14 <dalias> i'll time it again next time i build
2020-03-25 17:02:34 <dalias> meson is python right?
2020-03-25 17:02:50 <maxice8> yes
2020-03-25 17:03:04 <dalias> does it need a bunch of random python deps installed, or just python base?
2020-03-25 17:03:12 <maxice8> just python base
2020-03-25 17:03:17 <dalias> that's not too bad
2020-03-25 17:03:28 <dalias> annoying, but meh
2020-03-25 17:03:35 <maxice8> i believe they make it a promise to only use base python3
2020-03-25 17:03:45 <dalias> that's good
2020-03-25 17:03:56 <dalias> suggests competent maintainership that actually cares about not breaking things
2020-03-25 17:04:31 <Cogitri> Meson is pretty nice, yes
2020-03-25 17:04:40 <Cogitri> It's the one build system that I don't dread touching
2020-03-25 17:04:46 <maxice8> The configuration language of meson is not tied to a language, you can write something that reads meson.build files in any language
2020-03-25 17:05:03 <maxice8> Python3 was just the chosen language by the people that made meson to implement it
2020-03-25 17:06:50 <dalias> that's also good
2020-03-25 17:07:10 <dalias> i really hate stuff that's python based and uses python expressions that get eval'd in its data/config format
2020-03-25 17:19:37 <mps> 
ACTION wonders how the big project like linux kernel succeed to use only Makefile

2020-03-25 17:20:26 <_ikke_> The kernel does not require autoconf
2020-03-25 17:21:13 <_ikke_> I mean, the kernel stands on its own
2020-03-25 17:34:29 <Hello71> I don't think it's possible to make cmake take longer to compile than gcc without breaking bootstrap
2020-03-25 17:34:54 <_ikke_> How is bootrstrapping related to build time?
2020-03-25 17:35:27 <Hello71> well i was thinking about ccache
2020-03-25 17:35:42 <Hello71> but you can't ccache a gcc build except for stage 1
2020-03-25 17:45:41 <mps> _ikke_: forgot to tell you this morning about zig, I dislike authors insisting of 'no tabs' for indenting
2020-03-25 17:48:38 <_ikke_> mps: I long ago stoped caring about tabs vs spaces
2020-03-25 17:48:57 <_ikke_> I just care that it's used consistent
2020-03-25 17:50:38 <mps> I prefer to use my well, preference, not to be forced to 'one true indent characters' (to rephrase OTBS)
2020-03-25 17:51:49 <dalias> hello71, what do you mean by breaking bootstrap?
2020-03-25 17:54:33 <dalias> _ikke_, the whole point of gnu style is not to be consistent but instead mix in tabs wherever you need 8 spaces :-p
2020-03-25 17:54:42 <dalias> it's hideous :)
2020-03-25 17:56:48 <TBB> oh but there -is- one true ind... oh nevermind :)
2020-03-25 17:57:56 <_ikke_> mps: different projects have different standards, so if you want to contribute, you have to go with whatever the project choose
2020-03-25 17:57:59 <dalias> hello71, i don't use bootstrap building gcc
2020-03-25 17:59:13 <mps> _ikke_: I don't agree, compiler is tool not a project
2020-03-25 17:59:34 <_ikke_> mps: I was talking in general, not specifically about zig
2020-03-25 18:00:39 <mps> then, I agree with you
2020-03-25 18:01:09 <mps> imagine that gcc insist on only using tabs in C source :)
2020-03-25 18:02:20 <_ikke_> Like I said, I stopped caring about it :)
2020-03-25 18:03:03 <_ikke_> I'd set my editor to use tabs instead of spaces and go on with my life
2020-03-25 18:04:54 <TBK[m]> _ikke_: Can I get you to take a look at build-edge-ppc64le & build-edge-s390x?
2020-03-25 18:05:07 <_ikke_> The former, no, the latter yes
2020-03-25 18:05:24 <mps> _ikke_: you will be surprised when you start to program in zig :)
2020-03-25 18:05:47 <_ikke_> TBK[m]: Java is fun
2020-03-25 18:07:29 <artok> fun like putting toothpicks under fingernails
2020-03-25 18:07:50 <TBK[m]> _ikke_: ehh, it is not my cup of ....
2020-03-25 18:08:13 <_ikke_> artok: exactly
2020-03-25 18:09:35 <_ikke_> hmm, kill -9 does not work ...
2020-03-25 18:10:57 <_ikke_> ok
2020-03-25 18:12:51 <_ikke_> Lots of processes just stuck, I need to 'reap' them all manually
2020-03-25 18:13:14 <TBK[m]> :(
2020-03-25 18:13:43 <_ikke_> It's continuing now
2020-03-25 18:46:34 <mps> anyone using iwd? I'm thinking to build it with internal ell lib instead of external
2020-03-25 18:46:54 <mps> any objection, opinion or comment
2020-03-25 18:50:55 <artok> iwd backend on networkmanager doesn't support open networks so I stopped using it
2020-03-25 18:53:42 <maxice8> @mps is there a reason to do it internal?
2020-03-25 19:07:29 <mps> maxice8: yes, ell is somewhat buggy
2020-03-25 19:07:57 <mps> and I fear to upgrade it because it could break bluez pkg
2020-03-25 19:08:22 <mps> you probably noticed that I put S-Hold label in MR
2020-03-25 19:09:31 <mps> and iwd upstream told that is safer to build iwd with internal ell, till it API stabilizes, at least
2020-03-25 19:13:57 <maxice8> I see
2020-03-25 19:14:11 <maxice8> Then no objections from me
2020-03-25 19:15:33 <mps> thanks
2020-03-25 19:16:22 <mps> and we should hold ell on 0.28 or before upgrading to 0.30 test with bluez
2020-03-25 19:17:01 <artok> what is the proper way to tell APKBUILD to use clang ?
2020-03-25 19:17:16 <mps> maybe I should create MR so someone who uses bluetooth can test it
2020-03-25 19:23:07 <artok> or.. nevermind, it is cmake
2020-03-26 07:18:58 <_ikke_> rip maxice8 / cogitri (I guess their matrix bridge disconnected / crashed)
2020-03-26 07:21:01 <Cogitri> Ah no, I just restarted the server for a kernel upgrade
2020-03-26 07:21:27 <_ikke_> heh
2020-03-26 07:22:03 <Cogitri> I don't have something as fancy as live patching and I guess it doesn't matter much for the 60 secs of downtime I have anyway :P
2020-03-26 07:22:30 <_ikke_> nope
2020-03-26 07:22:34 <_ikke_> not worth the effort
2020-03-26 07:23:57 <Cogitri> Maybe I should add it for my homeserver though, since that thing needs more like 5 mins to reboot and hosts my DNS and stuff
2020-03-26 07:24:35 <Cogitri> Or maybe I should finally migrate that to my OpenWRT router which has basically 0 downtime :P
2020-03-26 07:29:11 <Cogitri> Oof, my dovecot isn't happy anymore though
2020-03-26 09:26:36 <Cogitri> Oh my, the Apparmor upgrade broke that for me
2020-03-26 09:27:05 <Cogitri> That took me a bit to find out, just getting permission denied on a file which clearly is accessible for the user is weird :P
2020-03-26 14:42:01 <zfoo> I downloaded the mini rootfs alpine image for a container and noticed I couldn't get an ipv4 by default like I could with the default image from the LXD image server. Upon closer look the mini rootfs is missing everything for startup (rc/init scripts and openrc). Is the mini rootfs intended to work as a container image?
2020-03-26 14:42:49 <_ikke_> yes
2020-03-26 14:47:45 <zfoo> But you're not able to start or manage services
2020-03-26 14:48:34 <_ikke_> Well, more like a docker container
2020-03-26 14:48:45 <_ikke_> not one running a 'full' os with init
2020-03-26 14:49:01 <zfoo> I see, that makes sense
2020-03-26 17:37:37 <timlegge> anyone able to look at !5718
2020-03-26 18:01:16 <_ikke_> timlegge: two commits mention 'move from community', but should be 'move from testing'
2020-03-26 18:15:03 <maxice8> Should T-Security issues that are normally confidential be made public after a certain period of time even if unfixed ?
2020-03-26 18:19:44 <ncopa> maxice8: we normally dont do that. the only reason those are confidential is that we dont want make it easy to automatically generate a list of known unfixed issues
2020-03-26 18:20:37 <ncopa> i guess we can open them when we close the issue (eg decide that we wont fix)
2020-03-26 18:42:48 <kpcyrd> out of interest, how do the 3.11.x stable releases work in alpine? is it security updates only or could I theoretically backport updates of packages as well?
2020-03-26 18:43:14 <Cogitri> Backporting fixes is supported for 6 months
2020-03-26 18:43:16 <_ikke_> typically only patch fixes
2020-03-26 18:43:38 <Cogitri> Or patch releases, so we don't break things while updating
2020-03-26 18:50:26 <kpcyrd> got it, thanks :)
2020-03-26 20:14:54 <timlegge> _ikke_: I've fixed up !5718
2020-03-26 21:14:31 <maxice8> apparently new linux broke my headset :D
2020-03-26 21:24:24 <maxice8> neither pulse nor alsa can find it anymore
2020-03-26 21:24:58 <TBK[m]> usb or minijack?
2020-03-26 21:26:59 <maxice8> Jack
2020-03-26 21:41:48 <Cogitri> wfm
2020-03-26 22:03:48 <maxice8> huh
2020-03-26 22:03:58 <maxice8> they are now the same sink for pulseaudio but are different ports
2020-03-26 22:04:07 <maxice8> so it doesn't automatically switch to it
2020-03-26 22:19:26 <clandmeter> are x86 runners stuck or just too much in the queue?
2020-03-26 22:20:25 <Hello71> working fine for me
2020-03-26 22:20:58 <clandmeter> i think Cogitri is using all slots
2020-03-26 22:21:32 <clandmeter> but it doesnt show x86
2020-03-26 22:21:34 <Hello71> lol
2020-03-26 22:21:45 <Hello71> maybe, my jobs started first
2020-03-26 22:23:11 <clandmeter> i need to reserve some runners just for infra
2020-03-26 22:24:59 <clandmeter> my admin super powers are completely useless :)
2020-03-27 00:14:51 <gjabell> Wofi no longer builds due to it having autogen'd tarballs
2020-03-27 00:15:02 <gjabell> What's the best way to handle that to get it building again?
2020-03-27 06:01:47 <Cogitri> gjabell: You mean the shasum is different every time? Tell upstream to fix their download server
2020-03-27 08:38:10 <mps> main/libcap https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=551bbc17d64237da0555a817fd4552bd706dd987
2020-03-27 08:38:38 <mps> ncopa: ^
2020-03-27 08:41:58 <Cogitri> ikke: https://gitlab.alpinelinux.org/kaey/aports
2020-03-27 08:54:07 <maxice8> !5890
2020-03-27 09:01:10 <mps> maxice8: main/acpica: move from main ?
2020-03-27 09:01:43 <mps> from or to ?
2020-03-27 09:20:42 <kaey> Cogitri: option to make repo public is grayed out for me btw
2020-03-27 09:20:55 <_ikke_> yes, that is by design
2020-03-27 09:22:23 <_ikke_> Cogitri: I ran my script again
2020-03-27 09:23:08 <Cogitri> Oh, you have a script for that now? Fancy
2020-03-27 09:23:52 <Cogitri> Seems to work :)
2020-03-27 09:24:13 <_ikke_> Yeah, it makes all internal aport forks public
2020-03-27 09:39:14 <insep[m]1> hey, is it possible to define functions for apkbuild outside of apkbuild?
2020-03-27 09:40:41 <Cogitri> You mean for using the function across multiple APKBUILDs?
2020-03-27 09:40:46 <Cogitri> It'd need to be in abuild then
2020-03-27 09:45:55 <insep[m]1> and is it possible to define such? afaict abuild doesn't source anything but /usr/share/abuild/functions.sh, maybe it's possible to modify abuild in such way where it also sources scripts from /etc/abuild.d/?
2020-03-27 09:46:10 <maxice8> i'd rather not
2020-03-27 09:46:55 <Cogitri> Yes, let's not, if you want a function available put it in that file
2020-03-27 09:47:31 <insep[m]1> okay :(
2020-03-27 09:48:50 <Cogitri> Does someone know why openjdk13 doesn't show up on ppc64le? https://pkgs.alpinelinux.org/packages?name=openjdk13&branch=edge
2020-03-27 09:49:23 <Cogitri> It is enabled on that arch: https://gitlab.alpinelinux.org/alpine/aports/blob/master/testing/openjdk13/APKBUILD#L9
2020-03-27 09:50:14 <_ikke_> Cogitri: it's stuck
2020-03-27 09:50:16 <_ikke_> afaik
2020-03-27 09:50:38 <Cogitri> Ah, but b.a.o doesn't list that
2020-03-27 09:50:55 <_ikke_> Cogitri: If you look carefull, you'd see it's nost listed at all anymore
2020-03-27 09:52:04 <Cogitri> Oh, huh
2020-03-27 09:53:36 <_ikke_> clandmeter: ping
2020-03-27 10:44:52 <clandmeter> _ikke_: ping
2020-03-27 10:45:09 <clandmeter> ci is broken
2020-03-27 10:45:53 <_ikke_> clandmeter: ppc64 edge builder is broken
2020-03-27 10:45:56 <clandmeter> ah its just stupid
2020-03-27 10:46:19 <clandmeter> how can i retry all parts of a pipeline?
2020-03-27 10:46:55 <clandmeter> you want to to restart that builder?
2020-03-27 10:47:06 <_ikke_> I'm kind of busy
2020-03-27 10:47:24 <clandmeter> s/to/me
2020-03-27 10:47:24 <alpine-meetbot> clandmeter meant to say: you want me to restart that builder?
2020-03-27 10:47:38 <_ikke_> yes, would be nice
2020-03-27 10:48:23 <clandmeter> build-edge-ppc64le this one?
2020-03-27 10:48:30 <_ikke_> yes
2020-03-27 10:48:58 <clandmeter> done
2020-03-27 10:49:59 <_ikke_> Ok, it's continuing again
2020-03-27 10:55:22 <ncopa> binutils-2.34 is out. are there any good reason to not upgrade?
2020-03-27 10:55:55 <mps> ncopa: I don't so, I looked at it about week ago
2020-03-27 10:56:06 <Cogitri> I guess we should upgrade together with the new GCC
2020-03-27 10:56:08 <mps> looks fine, though didn't tested
2020-03-27 11:01:02 <mps> here are some patches for binutils 2.34 to look at https://github.com/openwrt/openwrt/tree/master/toolchain/binutils/patches/2.34
2020-03-27 11:01:59 <mps> and here for gcc 9.3.0 https://github.com/openwrt/openwrt/tree/master/toolchain/gcc/patches/9.3.0
2020-03-27 12:21:01 <maxice8> i like the title 063082ba2278c67bb5429c5a2363e25f55462a67
2020-03-27 12:21:28 <_ikke_> haha :P
2020-03-27 12:32:14 <PureTryOut[m]> I just updated my local docker-abuild, and now it fails to run with `Error: unwritable ~/.abuild [drwxr-xr-x]`. Those permissions seem pretty writeable to me, but I guess it now runs as a different user?
2020-03-27 12:43:55 <PureTryOut[m]> Cogitri: you use docker-abuild right? Can you run it with latest commit?
2020-03-27 12:51:04 <Cogitri> Sure
2020-03-27 12:56:02 <Cogitri> wfm
2020-03-27 12:56:31 <Cogitri> My abuild also has 755 as permissions
2020-03-27 12:56:52 <Cogitri> s/abuild/~\/.abuild/
2020-03-27 12:56:52 <alpine-meetbot> Cogitri meant to say: My ~/.abuild also has 755 as permissions
2020-03-27 12:57:12 <Cogitri> Oh nice, hadn't expected it to handle escaping the /
2020-03-27 13:06:38 <minecrell> Cogitri: Can you cancel this one? https://gitlab.alpinelinux.org/Cogitri/aports/pipelines/11155 it seems to rebuild tons of packages (see https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/75816/raw)
2020-03-27 13:06:48 <minecrell> all of main or something, lol
2020-03-27 13:07:37 <_ikke_> done
2020-03-27 13:08:00 <minecrell> thanks
2020-03-27 13:08:39 <PureTryOut[m]> It works for you? Wut, how
2020-03-27 13:09:11 <PureTryOut[m]> dabuild sets it to 755 so that isn't the problem
2020-03-27 13:09:18 <PureTryOut[m]> Do you have a system user I don't or something?
2020-03-27 13:13:21 <Cogitri> Hm, I don't think so
2020-03-27 13:13:22 <Cogitri> dabuild uses the builder user internally but I don't have that
2020-03-27 13:13:34 <Cogitri> I do have a symlink from $HOME to /home/builder though, so that build paths in error messages are correct
2020-03-27 13:14:18 <Cogitri> (As in that it says /home/builder/.../somefile.c doesn't compile and I can just copy and paste the path then)
2020-03-27 13:14:23 <Cogitri> I don't think that's relevant though
2020-03-27 13:14:31 <Cogitri> I'm also in the abuild group
2020-03-27 13:16:10 <PureTryOut[m]> Yeah so am I...
2020-03-27 13:16:15 <PureTryOut[m]> Not sure what's wrong then
2020-03-27 13:17:09 <Hello71> Cogitri: ssabuilds~/.abuilds ;)
2020-03-27 13:17:34 <Hello71> sssnakesssss
2020-03-27 13:18:34 <Hello71> PureTryOut[m]: is your filesystem read only
2020-03-27 13:19:16 <PureTryOut[m]> Obviously not...
2020-03-27 13:20:29 <Hello71> it's happened to me before -.-
2020-03-27 13:21:06 <PureTryOut[m]> A read-only /home?
2020-03-27 13:23:01 <Hello71> errors=remount-ro is a thing
2020-03-27 14:52:21 <minecrell> _ikke_, maxice8: these two look stuck too: https://gitlab.alpinelinux.org/Leo/aports/-/jobs/75915, https://gitlab.alpinelinux.org/Leo/aports/-/jobs/75922
2020-03-27 14:53:14 <maxice8> s390x is known to get stuck during git fetch
2020-03-27 14:53:25 <minecrell> :/
2020-03-27 14:54:22 <TBK[m]> there is also the issue of GL not killing the lingering CI jobs after a MR has been merged
2020-03-27 14:55:27 <minecrell> maxice8: thanks, now the s390x pipeline I was waiting for is running :)
2020-03-27 14:56:20 <Cogitri> TBK[m]: If you delete the source branch it at least kills the CI job
2020-03-27 14:58:52 <TBK[m]> not always from my experience, if the runner is queued, MR is merge, source deleted, now the runner starts and fails on git fetch
2020-03-27 14:59:30 <_ikke_> correct
2020-03-27 14:59:56 <Cogitri> Yes, it fails but at least it doesn't run again for no reason
2020-03-27 15:00:01 <Cogitri> But the failing is very annoying too,y es
2020-03-27 15:00:25 <_ikke_> note that it's rebasing the MR that causes CI to run, not the merging itself
2020-03-27 15:01:21 <Cogitri> Yes, ideally Gitlab would have a rebase&merge button like GitHub
2020-03-27 15:03:08 <TBK[m]> _ikke_: talking about runners :D https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/merge_requests/3/pipelines
2020-03-27 15:03:49 <maxice8> rebase in the gitlab api has skip_ci parameter and i put it in mgmr but it apparently doesn't work
2020-03-27 15:03:52 <maxice8> https://docs.gitlab.com/ee/api/merge_requests.html
2020-03-27 15:18:35 <insep[m]1> <insep[m]1 "hey, is it possible to define fu"> also forgot to provide context for that one, pmOS has functions for kernel apkbuilds, but they are just shell scripts in /usr/bin, so we have to pass all needed variables as arguments
2020-03-27 15:34:04 <minecrell> insep[m]1: you can source it
2020-03-27 15:34:09 <minecrell> then you have all variables
2020-03-27 15:34:28 <minecrell> I tried that for downstreamkernel_prepare actually, but thought it looks a bit too weird
2020-03-27 15:53:22 <mps> ncopa: maxice8: !5446 should be pushed or add vtXXX terminals to current ncurses-terminfo-base
2020-03-27 15:54:05 <mps> using serial console is currently problematic
2020-03-27 15:54:20 <mps> on edge, I mean
2020-03-27 16:00:21 <insep[m]1> <minecrell "insep: you can source it"> yeah, but `. /usr/bin/downstreamkernel_prepare` looks a bit weird because that `. ` and i'll need to save compatibility with all other kernels
2020-03-27 16:01:33 <insep[m]1> well, i can break compatibility in prepare and test it, since just prepare on 100+ kernels shouldn't take too long, but package will take a long time :\
2020-03-27 16:05:40 <minecrell> insep[m]1: we have built all kernels before
2020-03-27 16:05:45 <minecrell> it can be done
2020-03-27 16:12:28 <insep[m]1> it can be done, but takes a lot of time
2020-03-27 16:29:35 <minecrell> insep[m]1: it's worth it if you make useful changes IMO
2020-03-27 16:36:03 <insep[m]1> is out-of-tree useful enough? :D
2020-03-27 16:36:20 <insep[m]1> i mean, it can remove a lot of patches
2020-03-27 16:36:32 <insep[m]1> also let's move this discussion to pmos rooms ;)
2020-03-27 17:04:34 <Cogitri> Didn't we have a -R switch to abuild so it builds deps itself?
2020-03-27 17:05:03 <_ikke_> It has been removed
2020-03-27 17:06:03 <Cogitri> Oh, that's unfortunate
2020-03-27 17:06:17 <Cogitri> Well, I guess I'll use an old version of abuild for apk-polkit's tests then
2020-03-27 17:08:51 <Cogitri> Or can I somehow set what dir abuild looks for deps in?
2020-03-27 17:09:09 <_ikke_> abuild just uses apk to install deps
2020-03-27 17:09:22 <_ikke_> just add the directory in /etc/apk/repositories
2020-03-27 17:11:02 <Cogitri> Well, I want the tests to run inprivileged, so I can't really do that
2020-03-27 17:11:14 <Cogitri> I guess I'll have to set APK and add -X to that
2020-03-27 17:15:24 <Cogitri> Huh, it should be possible to init an APK db without root permissions like so, right? `apk add --initdb --root="$(pwd)/apk" build-base`
2020-03-27 17:15:35 <Cogitri> $(pwd)/apk being a dir the user can write to
2020-03-27 17:19:06 <Cogitri> Huh, it even creates the base folder structure but still complains it doesn't have permissions
2020-03-27 17:30:23 <zfoo> I have a new apline linux container (mini rootfs image) and upon boot the runlevel is 'shutdown' and when I run 'openrc default' I get the error 'not foundopenrc-run.sh'
2020-03-27 17:32:47 <_ikke_> zfoo: minirootfs is not meant to run with an init system
2020-03-27 17:33:00 <_ikke_> the target is things like docker containers
2020-03-27 17:34:46 <TBK[m]> _ikke_: please terminate https://gitlab.alpinelinux.org/Leo/aports/-/jobs/75991
2020-03-27 17:35:23 <_ikke_> done
2020-03-27 17:35:40 <TBK[m]> merci
2020-03-27 17:36:41 <zfoo> _ikke_, sorry, I my mistake, this image was built via 'alpine-make-rootfs' and it has openrc and a /etc/rc.conf and the /etc/runlevels scripts
2020-03-27 17:38:06 <_ikke_> zfoo: is the openrc package actually installed? It has the openrc-run.sh script
2020-03-27 17:44:55 <zfoo> _ikke_: it wasn't, I installed it, now the error is 'not foundgendepends.sh' but the script 'gendepends.sh' exist under /lib/rc/sh
2020-03-27 17:45:25 <_ikke_> No idea then
2020-03-27 18:39:02 <oneinsect> while build make using abuild, during the final rootpkg command, i get this error ERROR: make: libdl.so.2: path not found
2020-03-27 18:39:02 <oneinsect>  even though libdl.so.2 is there
2020-03-27 18:39:19 <oneinsect> any idea where rootpkg looks for in the system for libdl.so.2
2020-03-27 18:41:41 <oneinsect> while building*
2020-03-27 18:43:24 <oneinsect> okie it looks in /lib/x86_64-linux-gnu and not /usr/lib/x86_64-linux-gnu
2020-03-27 18:43:28 <oneinsect> wonder why
2020-03-27 18:45:32 <maxice8> huh, binutils 2.34 installs to /usr/x86_64-alpine-linux-musl/{bin,lib}
2020-03-27 18:45:49 <oneinsect> its make package
2020-03-27 18:51:04 <oneinsect> i am trying to compile make itself
2020-03-27 18:51:17 <oneinsect> it does create apk but cannot find that so.2
2020-03-27 19:12:15 <artok> config.guess and so on don't understand always alpine, the musl
2020-03-27 19:25:18 <oneinsect> hmmmm
2020-03-27 22:16:23 <mps> maxice8: are you around?
2020-03-27 22:16:32 <maxice8> Yes
2020-03-27 22:17:12 <mps> sorry for disturbing, which box should I tick to allow you to push ell
2020-03-27 22:17:24 <maxice8> Can't remember right now
2020-03-27 22:17:58 <mps> should I 'Edit' and then check box 'Allow commits from members who can merge to the target branch'
2020-03-27 22:18:10 <maxice8> i believe that is the one yes
2020-03-27 22:18:16 <mps> ok, will do
2020-03-28 01:16:30 <timlegge> maxice8: are you around?
2020-03-28 08:37:47 <mps> who is our lxc 'master'?
2020-03-28 08:54:36 <mps> ok, whoever is, please look at !5928
2020-03-28 08:55:27 <mps> I'm backported it to my local 3.11-stable and using it, didn't noticed any serious problem yet
2020-03-28 10:30:17 <Cogitri> TBK[m]: I think it's best to not merge things right now, the builders are busy w/ libreoffice right now
2020-03-28 10:30:58 <TBK[m]> yeah
2020-03-28 10:31:52 <_ikke_> they are failing on libreoffice right now ;-)
2020-03-28 10:32:10 <TBK[m]> !5935
2020-03-28 10:32:19 <_ikke_> and epiphany
2020-03-28 10:33:21 <Cogitri> I guess the bump for webkit2gtk got lost in the rebasing
2020-03-28 10:34:06 <Cogitri> Pushed a fix
2020-03-28 12:59:10 <_ikke_> now rethingdb is still failing
2020-03-28 13:20:08 <TBK[m]> at lease it is not related to icu :D
2020-03-28 13:44:05 <mps> uh, rebase from GL UI triggers CI again
2020-03-28 13:46:46 <Cogitri> Yes, to test against new changes
2020-03-28 13:47:12 <Cogitri> Sadly there's no "rebase and merge" button to be able to rebase and merge in one go to avoid triggering CI for no reason when you want to merge anyway.
2020-03-28 13:47:34 <maxice8> plus calling rebase via gitlab v4 api doesn't work even when skip_ci is passed on the parameters
2020-03-28 13:58:21 <_ikke_> maxice8: maybe only if you have sufficient rights?
2020-03-28 14:00:58 <_ikke_> https://gitlab.com/gitlab-org/gitlab/issues/38141
2020-03-28 14:01:01 <_ikke_> Seems pretty recent
2020-03-28 14:01:24 <_ikke_> hmm, 12.7
2020-03-28 14:01:28 <_ikke_> Which we are already on
2020-03-28 14:05:36 <timlegge> maxice8: got a question.  How did you know the version of perl-file-chdir needed an update?  Its not listed on metacpan as the latest.  It was released but not indexed
2020-03-28 14:06:10 <timlegge> wondering whether it is something I should add to apkbuild-cpan
2020-03-28 14:06:47 <maxice8> repology
2020-03-28 14:06:52 <maxice8> It indexes cpan
2020-03-28 14:07:27 <maxice8> https://repology.org/maintainer/timlegge%40gmail.com/feed-for-repo/alpine_edge
2020-03-28 14:07:44 <maxice8> this is your html feed, there is also an RSS one, it will show when one of your packages is outdated
2020-03-28 14:08:42 <timlegge> well that is a useful page to know about.  Thanks
2020-03-28 18:32:13 <Cogitri> Can we somehow check for all packages in a repo that they have consistent linking?
2020-03-28 18:33:47 <maxice8> ikke: please make public https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5940
2020-03-28 18:34:08 <_ikke_> done
2020-03-28 18:34:16 <maxice8> ty
2020-03-28 20:19:03 <mps> found where apk is stuck on armv7 and kernel 5.6-rc series
2020-03-28 20:19:18 <mps> renameat(3, "lib/apk/db/installed.new", 3, "lib/apk/db/installed"
2020-03-28 20:20:12 <mps> is that musl or apk issue
2020-03-28 20:26:03 <_ikke_> Do you also know *why* it's stuck?
2020-03-28 20:26:41 <mps> _ikke_: strace stop here => renameat(3, "lib/apk/db/installed.new", 3, "lib/apk/db/installed"
2020-03-28 20:27:47 <_ikke_> Right, but why is it stuck on a systemcall?
2020-03-28 20:28:37 <mps> really have no idea, maybe renameat is changed in kernel for arm32
2020-03-28 20:29:00 <mps> it works fine on aarc64
2020-03-28 21:18:47 <TBK[m]> my mr !5957 fails only on arm7 could somebody with go + arm7 insight take a look?
2020-03-28 21:40:28 <mps> TBK[m]: if no one do that till tomorrow remind me and I will look
2020-03-28 21:53:22 <TBK[m]> mps: ok :)
2020-03-28 22:50:12 <artok> hmm.. samurai doesn't have yet all ninja thingies
2020-03-29 00:56:26 <bl4ckb0ne> is there something wrong with libgcc on the latest update?
2020-03-29 00:56:48 <bl4ckb0ne> i have `ERROR: libgcc-9.3.0-r0: network connection aborted` when I upgrade
2020-03-29 00:57:07 <bl4ckb0ne> and `(1/1) [APK unavailable, skipped] Reinstalling libgcc (9.2.0-r6)` when I do `apk fix libgcc`
2020-03-29 00:57:43 <artok> what is your repo?
2020-03-29 00:57:47 <artok> dl-cdn ?
2020-03-29 00:58:11 <bl4ckb0ne> my mirror?
2020-03-29 01:15:11 <artok> yah
2020-03-29 01:22:03 <bl4ckb0ne> http://alpine.mirror.vexxhost.ca and http://alpinelinux.mirror.iweb.com
2020-03-29 01:30:03 <artok> check if there is problem with mirrors
2020-03-29 01:31:00 <bl4ckb0ne> might be my shitty connection
2020-03-29 02:12:05 <c705> hello. https://lkml.org/lkml/2020/2/21/812 regarding r8169 module. I feel like linux-lts is susceptible to this bug (5.4.28-0-lts). Should I make a bug report and/or is this being tracked?
2020-03-29 06:13:35 <_ikke_> c705: feel free to open a ticket about it
2020-03-29 06:58:05 <Cogitri> Bumping LLVM to 10 now
2020-03-29 08:41:21 <Cogitri> mps: Could you look into building zig w/ llvm10?
2020-03-29 08:41:36 <Cogitri> Upstream hasn't released a new package for some time now apparently
2020-03-29 08:41:51 <Cogitri> And we can't keep it at the old version because it also needs lld and clang which we don't version
2020-03-29 08:42:01 <_ikke_> Cogitri: ping
2020-03-29 08:43:59 <Cogitri> Pong
2020-03-29 08:44:27 <_ikke_> Trying to figure out why your pipelines keep trying to build the 'world'
2020-03-29 08:44:42 <Cogitri> Ah, something I can help with?
2020-03-29 08:44:51 <_ikke_> Can it be something in your workflow?
2020-03-29 08:45:03 <_ikke_> I'm currently looking at the repo as it's on the ci-builder
2020-03-29 08:45:42 <_ikke_> http://tpaste.us/NmWv
2020-03-29 08:45:58 <Cogitri> My workflow currently is:
2020-03-29 08:45:58 <Cogitri> * Switch to new branch locally
2020-03-29 08:45:58 <Cogitri> * Make merge request with mkmr
2020-03-29 08:45:58 <Cogitri> * (Force) push to my fork, in case I still have an old version of my branch around
2020-03-29 08:45:58 <_ikke_> At the top you see master
2020-03-29 08:46:32 <Cogitri> Huh, but I think I only pushed the rethinkdb change to gitlab upstream, didn't I?
2020-03-29 08:46:52 <_ikke_> master is upstream master
2020-03-29 08:47:22 <_ikke_> What I'm confused about is that HEAD is 51b91b11 (HEAD, refs/pipelines/11467) community/gnome-user-docs: upgrade to 3.36.0
2020-03-29 08:47:35 <_ikke_> But this also exists: 495ed67f (origin/gnome-user-docs) community/gnome-user-docs: upgrade to 3.36.1
2020-03-29 08:48:31 <Cogitri> Huh, how does it pull in things from another branch
2020-03-29 08:48:36 <Cogitri> And another repo
2020-03-29 08:48:49 <_ikke_> I deliberately fetch upstream master
2020-03-29 08:48:52 <_ikke_> to compare against
2020-03-29 08:48:56 <_ikke_> to find out what has changed
2020-03-29 08:50:06 <Cogitri> Ah?
2020-03-29 08:51:05 <_ikke_> But this fails if the source and target branch are not 'connected'
2020-03-29 08:52:39 <Cogitri> Ah, but isn't it normal that the source branch and target branch have branched off each other a fair bit?
2020-03-29 08:53:49 <Cogitri> Can you check if my llvm10 MR causes the same behaviour?
2020-03-29 08:54:29 <Cogitri> That should be on top of upstream/master with just my new LLVM10 commits on top
2020-03-29 09:00:11 <_ikke_> What I've seen so far is that, with a clean repo (no earlier shallow clones), when you fetch master, it will fetch everything up to the graft point
2020-03-29 09:00:17 <_ikke_> Which is exactly what we need
2020-03-29 09:00:29 <_ikke_> But if you look at the output I pasted
2020-03-29 09:00:35 <_ikke_> HEAD is below the graft point
2020-03-29 09:01:25 <_ikke_> Cogitri: Were you testing gnome-user-docs 3.36.0 or 3.36.1?
2020-03-29 09:02:02 <_ikke_> I would assume you were testin 3.36.1
2020-03-29 09:02:13 <_ikke_> I'm confused why HEAD is pointing to the 3.36.0 commit
2020-03-29 09:03:09 <_ikke_> Did you push these in close succesion?
2020-03-29 09:03:58 <Cogitri> Hum, I think if I open a MR before I push to my fork it opens a MR against the current status of that branch on my fork
2020-03-29 09:04:56 <Cogitri> I didn't push those in close succesion, so I guess I forgot to push to my fork first, created the MR against my old origin/gnome-user-docs (which bumped to 3.36.0 and was some week old or so) and then force pushed (which was the newest upstream/master and contained 3.36.1)
2020-03-29 09:08:59 <_ikke_> right, so the CI job runs on your old commit, not the new one you intend
2020-03-29 09:09:10 <Cogitri> Yes
2020-03-29 09:09:22 <_ikke_> And it also causes more grafts / shallow points
2020-03-29 09:09:34 <Cogitri> Sorry about that, didn't really pay attention to what order I did that in
2020-03-29 09:09:57 <_ikke_> I do want to figure out how to properly handle it though
2020-03-29 09:11:05 <Cogitri> Oh, okie
2020-03-29 09:11:49 <_ikke_> But for now, would it be possible to make sure you first push your changes before you make an MR?
2020-03-29 09:12:49 <_ikke_> (which is good in any case, otherwise CI has to run again after you changed your push
2020-03-29 09:12:54 <_ikke_> pushed your change*
2020-03-29 09:13:46 <Cogitri> Yes, I'll try to keep it in mind
2020-03-29 09:15:43 <_ikke_> c705 │ hello. https://lkml.org/lkml/2020/2/21/812 regarding r8169 module. I feel like linux-lts is susceptible to this bug (5.4.28-0-lts). Should I make a bug report and/or is this being tracked?
2020-03-29 09:15:51 <_ikke_> ctrl-?ctrl-?meta-j1
2020-03-29 09:15:57 <mps> Cogitri: hmm, maybe zig should be fixed to llvm9
2020-03-29 09:16:01 <_ikke_> Sorry, I'm messing mu :)
2020-03-29 09:16:26 <mps> s/fixed/locked/
2020-03-29 09:16:26 <alpine-meetbot> mps meant to say: Cogitri: hmm, maybe zig should be locked to llvm9
2020-03-29 09:16:40 <Cogitri> mps: We cant do that
2020-03-29 09:16:48 <Cogitri> Since it also needs clang and lld
2020-03-29 09:16:55 <Cogitri> And we don't have multiple versions of that around
2020-03-29 09:17:01 <Cogitri> And mixing versions is a recipe for doom
2020-03-29 09:17:02 <mps> ah
2020-03-29 09:17:25 <mps> then we should hold llvm to 9
2020-03-29 09:17:37 <Cogitri> Upstream recommended to just upgrade to git master
2020-03-29 09:17:49 <Cogitri> No, let's not keep LLVM a major version down because of one package
2020-03-29 09:17:53 <mps> which upstream
2020-03-29 09:17:58 <Cogitri> Zig Upstream
2020-03-29 09:18:01 <mps> aha
2020-03-29 09:18:25 <Cogitri> Zig wants to make a new release on April 13 and I would rather not wait until then to bump LLVM to 10 because it gets uncomfortable close to 3.12 then
2020-03-29 09:18:32 <mps> could you point me to url, please
2020-03-29 09:18:43 <Cogitri> We talked in #zig on freenode
2020-03-29 09:19:05 <mps> ah, I left channel some time ago
2020-03-29 09:19:59 <mps> ok, will look at it later today if I find some time, if not tomorrow will look for sure. thanks for info
2020-03-29 09:20:11 <Cogitri> 
ACTION uploaded an image: image.png (107KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/EIaacIGTyKlNJajuCUBkCzRP >

2020-03-29 09:20:29 <Cogitri> Thank you. The LLVM10 MR is !5975
2020-03-29 09:20:35 <Cogitri> Only creduce and zig are left to be fixed now
2020-03-29 09:22:35 <mps> zig author told me about month or two ago that he will fix some issue for musl, and I thought to ask him when the new release will be, but free time 'kills me'
2020-03-29 09:29:41 <mps> btw, we need do something about crystal before freeze
2020-03-29 09:30:46 <Cogitri> Err yes, but let's do one thing at a time :)
2020-03-29 09:32:28 <mps> :)
2020-03-29 10:35:27 <TBK[m]> _ikke_: please unlock !5464
2020-03-29 10:36:31 <Ariadne> i still need to finish -fno-common builds
2020-03-29 10:42:04 <Cogitri> Can I force abuild to go ahead even with missing makedepends?
2020-03-29 10:42:26 <Cogitri> I want to write tests for apk-polkit but right now I'd need to install build-base to build the test apk packages for that
2020-03-29 10:42:50 <Cogitri> And installing GCC and stuff to a test root for every test seems really anoying
2020-03-29 10:43:01 <Ariadne> abuild clean unpack prepare build rootpkg update_abuildrepo
2020-03-29 10:43:12 <Ariadne> that's the "hard" way
2020-03-29 10:43:45 <Cogitri> Hm, it still tells me: `ERROR: test-a: Missing dependencies (use -r to autoinstall them): build-base`
2020-03-29 10:44:13 <Ariadne> shouldn't
2020-03-29 10:44:19 <Ariadne> that error comes from installdeps phase
2020-03-29 10:44:22 <Ariadne> which is skipped
2020-03-29 10:44:23 <Cogitri> Ah derp, typo'ed, sorry about that
2020-03-29 10:44:26 <Cogitri> Thanks for the tip :)
2020-03-29 10:53:00 <Cogitri> Hm, seems like it's not quite happy still though: http://dpaste.com/1FEBYW3
2020-03-29 10:53:44 <Cogitri> The APKBUILD is here: https://gitlab.alpinelinux.org/Cogitri/apk-polkit/blob/master/tests/apkd/repo/test-a/APKBUILD
2020-03-29 10:55:14 <Cogitri> Ohh, seems like it's an issue with running multiple tests at once, my bad
2020-03-29 10:58:41 <mps> TBK[m]: !5957 fails on tests in armv7 lxc
2020-03-29 11:01:27 <_ikke_> TBK[m]: done
2020-03-29 11:12:07 <Cogitri> Ariadne: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5975#note_77500 I was under the impression that only GCC 10 switched to enabling fno-common, not CLang 10
2020-03-29 11:12:24 <Ariadne> both are
2020-03-29 11:13:00 <TBK[m]> mps: thanks for taking a look
2020-03-29 11:13:08 <Ariadne> oh
2020-03-29 11:13:15 <Ariadne> i guess it is clang 11 that is going to -fno-common
2020-03-29 11:13:46 <Cogitri> Possibly, at least I'd expect them to mention that in the release notes
2020-03-29 11:14:03 <Cogitri> So I don't think it's in 10
2020-03-29 11:14:08 <Cogitri> I can test by building wget though :P
2020-03-29 11:16:16 <Cogitri> Seems like the fallout from that is rather severe
2020-03-29 11:21:56 <mps> TBK[m]: didn't dived deep but looks like it have issue to set and access some network services/tools
2020-03-29 11:25:30 <Cogitri> Ariadne: Hooray, apk-polkit's tests work on distros other than Alpine now, thank you very much for the help :)
2020-03-29 11:30:06 <mps> we cannot have '+' in pkgver? I didn't seen it yet so maybe I'm wrong
2020-03-29 11:43:26 <maxice8> !5982 for weechat users
2020-03-29 11:47:03 <mps> hmm, what's wrong here: 'ERROR: zig: 0.5.0_git86795c03f is not a valid version'
2020-03-29 11:48:40 <_ikke_> hmm, looks alright
2020-03-29 11:48:50 <mps> while I see such example: main/xf86-video-intel/APKBUILD:pkgver=2.99.917_git20170325
2020-03-29 11:50:42 <mps> uhm, pkgver=0.5.0_git8679503 (i.e. without c and f character is ok)
2020-03-29 11:51:02 <mps> is that bug
2020-03-29 11:55:23 <Ariadne> not exactly
2020-03-29 11:55:31 <Ariadne> 20170325 is a date
2020-03-29 11:55:43 <Ariadne> the idea of using a git hash for version is... well
2020-03-29 11:55:49 <Ariadne> how do you know which version is newer
2020-03-29 11:55:52 <Ariadne> :)
2020-03-29 12:49:11 <mps> Cogitri: trying zig, 'CMake Error at cmake/Findllvm.cmake:33 (message) \n  expected LLVM 10.x but found 9.0.1'
2020-03-29 12:50:51 <mps> _ikke_: are you lxc 'master' on alpine infra?
2020-03-29 12:51:07 <_ikke_> Not really
2020-03-29 12:51:12 <_ikke_> I just use them
2020-03-29 12:51:21 <mps> ah, sorry then
2020-03-29 12:51:23 <_ikke_> np
2020-03-29 12:51:38 <mps> I need someone to look at !5928
2020-03-29 12:51:51 <_ikke_> perhaps clandmeter
2020-03-29 12:52:12 <mps> but he is on phone these days :)
2020-03-29 12:53:25 <minecrell> mps: Do you have another comment for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5905? I'm not sure I understand what you are trying to say there. How do you suggest to fix the issue?
2020-03-29 12:54:18 <mps> minecrell: I agree that it should be 'fixed' somehow, but I still think patches are not good idea
2020-03-29 12:54:37 <mps> as you can see in git log I removed it
2020-03-29 12:54:45 <minecrell> mps: Well, I think we should patch the source of the problem
2020-03-29 12:54:52 <minecrell> the single line is also trivial to rebase
2020-03-29 12:55:02 <minecrell> but of course it should just be merged upstream
2020-03-29 12:55:05 <minecrell> dunno why they didn't
2020-03-29 12:55:21 <mps> I think this should be discussed with musl upstream first
2020-03-29 12:56:59 <mps> minecrell: I don't want to say that this shouldn't be fixed, but we should come to optimal solution
2020-03-29 12:57:29 <minecrell> mps: Why? This has nothing to do with musl. This is just like all the other situations when something accidentally depends on internal definitions from glibc headers
2020-03-29 12:57:39 <Cogitri> mps: Huh, on zig master? They (zig upstream) said that LLVM10 support has been merged a few days ago
2020-03-29 12:57:50 <minecrell> from: https://www.musl-libc.org/faq.html "Assuming that including one header will cause symbols from another unrelated header to be exposed. This is an application bug, and fixing it is as simple as adding the missing #include directives."
2020-03-29 12:58:21 <mps> minecrell: I understand, but anyway.
2020-03-29 12:58:43 <mps> and I agree, linux kernel too much glibc-ed
2020-03-29 12:59:12 <minecrell> it would be rather worth to poke upstream (Linux) about the patch I added imo
2020-03-29 12:59:46 <mps> yes
2020-03-29 13:00:25 <mps> and, I'm not opposed to patch kernel headers, just told what I think
2020-03-29 13:00:46 <mps> decision to patch or not should be on maintainer, not me
2020-03-29 13:01:01 <minecrell> ok
2020-03-29 13:01:10 <minecrell> I was just happy to get linux-tools working, lol
2020-03-29 13:01:18 <mps> also I would
2020-03-29 13:01:23 <mps> :)
2020-03-29 13:02:30 <mps> actually I built some of tools on armv7 and aarch64, lsgpio and lsiio already, but for private use because I didn't prepared them for release/push
2020-03-29 13:03:29 <mps> and, another note, I think kernel headers should be built from linux-lts aport and not separate package
2020-03-29 13:04:19 <mps> afaik, it never breaks ABI/API in stable releases
2020-03-29 13:05:31 <mps> Cogitri: yes, I've seen. Just wanted to note you that I'm working on it and that it will be ready when llvm10 is pushed and built
2020-03-29 13:06:23 <minecrell> mps: I have another pending change for the iio tools, because these are the ones I had to build manually several times now, and it was kind of annoying. But first need to get linux-tools working at all :)
2020-03-29 13:06:38 <Cogitri> Ah okay, I thought you wanted to say that zig is still broken
2020-03-29 13:06:41 <mps> I have to try to fix apk issue with kernel 5.6-rc on armv7, this takes my nerves out-of
2020-03-29 13:06:48 <Cogitri> Well, if zig is good to go LLVM will be good to go by later today too
2020-03-29 13:07:36 <mps> Cogitri: TBH, I'm tired to build llvm10 localy :)
2020-03-29 13:08:30 <mps> minecrell: yes, also I wanted to fix linux-tools to make more tools from it and on more archs
2020-03-29 13:08:59 <Cogitri> Why don't you just download the zip from the MR, mps?
2020-03-29 13:10:26 <mps> minecrell: because that in last time I care to upgrade linux-tools, I want it to be better and planned to move to community when I (or anyone else) make it a better
2020-03-29 13:10:51 <mps> Cogitri: hmm, it is built in CI? :) good idea
2020-03-29 13:12:06 <Cogitri> Oh, the pipeline fails right now though, so it doesn't upload a tarball :/
2020-03-29 13:12:18 <mps> yes, I see
2020-03-29 13:19:01 <clandmeter> mps: where are the lxc release notes?
2020-03-29 13:21:38 <mps> clandmeter: I don't seen them, only looked at github commit history
2020-03-29 13:21:57 <clandmeter> is 4 lts?
2020-03-29 13:22:24 <mps> but I built it and run on my local x86_64 few days without issue, for now
2020-03-29 13:23:29 <mps> didn't seen LTS note, but didn't searched for it. maybe I will look later
2020-03-29 13:25:33 <mps> I just went out, will look later and inform you
2020-03-29 13:25:57 <clandmeter> ok :)
2020-03-29 13:26:03 <clandmeter> im not on mobile now
2020-03-29 13:26:06 <clandmeter> for ones
2020-03-29 13:27:12 <mps> but I'm :)
2020-03-29 13:46:23 <mps> clandmeter: looks like lxc 4.0.0 is not LTS, https://linuxcontainers.org/lxc/introduction/ note under 'Extended support'
2020-03-29 13:46:31 <mps> I missed that
2020-03-29 13:46:35 <mps> sorry
2020-03-29 14:25:40 <clandmeter> Maybe it needs to be announced
2020-03-29 14:26:49 <clandmeter> When was it released?
2020-03-29 14:30:24 <mps> https://github.com/lxc/lxc/releases
2020-03-29 14:30:36 <mps> 2020-03-24
2020-03-29 16:11:29 <mps> uh, mesa downgraded
2020-03-29 16:14:42 <Cogitri> Apparently are some graphical glitches in 20.x
2020-03-29 16:15:03 <mps> I didn't noticed any
2020-03-29 16:15:05 <maxice8> Certainly there are in Xwayland with intel
2020-03-29 16:15:30 <mps> ah, I don't use wayland
2020-03-29 16:15:49 <mps> anyway, how will downgrade work
2020-03-29 16:16:44 <Cogitri> You're only downgraded if you do `apk upgrade -a`
2020-03-29 16:17:22 <mps> uhmm
2020-03-29 16:18:46 <mps> do we have bug report about the problem?
2020-03-29 16:22:21 <Cogitri> 
ACTION uploaded an image: image.png (100KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/onUhJVLQiqCYjrnEvWrdMVUc >

2020-03-29 16:22:29 <Cogitri> This happens with mesa 20.x
2020-03-29 16:23:13 <mps> nice looking :)
2020-03-29 16:25:02 <_ikke_> Cogitri: Is it normal that https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/78236 is still running?
2020-03-29 16:25:53 <Cogitri> 2 hours doesn't seem to bad for a LLVM + all dependants rebuile
2020-03-29 16:26:06 <Cogitri> Seems to be building Rust right now, that might take a while :P
2020-03-29 16:26:11 <_ikke_> ok
2020-03-29 16:26:19 <Cogitri> It's only building the changes I did though, so no need to cancel it
2020-03-29 16:26:34 <_ikke_> good
2020-03-29 16:26:45 <_ikke_> Just wanted to verify
2020-03-29 16:27:06 <Cogitri> Okie :)
2020-03-29 16:27:22 <Cogitri> Are all my other branches fine? I paid attention to the order of pushing and creating the MR this time
2020-03-29 16:27:35 <mps> Cogitri: btw, screenshot you posted this morning about zig: zig is in testing so it is not in 3.11-stable, but I'm sure you know this
2020-03-29 16:27:57 <Cogitri> Oh, oops, somehow I didn't double check that and just assumed it's in stable
2020-03-29 16:28:05 <mps> np
2020-03-29 16:28:17 <mps> just wanted to note
2020-03-29 16:28:35 <Cogitri> Okie, thanks for the heads up
2020-03-29 16:28:48 <mps> we all make mistakes, especially on chats :)
2020-03-29 16:36:49 <Hello71> Cogitri: did you try setting MESA_LOADER_DRIVER_OVERRIDE=i965
2020-03-29 16:37:17 <Hello71> hm, mesa still in testing on Arch
2020-03-29 16:38:07 <Cogitri> I use an AMD GPU, so I doubt that does something
2020-03-29 16:38:16 <Cogitri> It only happens with Chromium though
2020-03-29 16:38:45 <Cogitri> Chromium in XWayland and Steam (which also uses Chromium for the browser) had this and QtWebEngine in MellowPlayer (although QtWebEngine fixed itself after the upgrade to 5.14.1)
2020-03-29 16:38:50 <Hello71> uh... well then your graphics corruption will be solved because it won't start
2020-03-29 16:38:58 <Cogitri> Heh :P
2020-03-29 16:39:10 <Cogitri> Technically problem solved
2020-03-29 17:13:04 <minecrell> maxice8, Cogitri: Is the mesa problem reported upstream? Haven't noticed any problems anywhere. I'm pretty sure 20.x.x fixed a few freedreno problems so the downgrade isn't great for me :\
2020-03-29 17:14:12 <Cogitri> Yes, I also don't think the upgrade is great :/
2020-03-29 17:14:18 <Cogitri> s/up/down/ derp
2020-03-29 17:14:18 <alpine-meetbot> Cogitri meant to say: Yes, I also don't think the downgrade is great :/
2020-03-29 17:14:37 <Cogitri> I asked maxice8 to report it upstream
2020-03-29 17:29:36 <Cogitri> Reverting the downgrade now, minecrell
2020-03-29 17:30:07 <Cogitri> The downgrade probably hurts more people than the upgrade did since it's apparently only triggered by XWayland users
2020-03-29 17:30:35 <Cogitri> And then only if hardware accel is enabled
2020-03-29 17:30:49 <Cogitri> maxice8: ^ Try disabling hardware accel, that fixed it for it in Chromium
2020-03-29 17:41:52 <maxice8> reverted and llvm10 is in
2020-03-29 18:06:49 <crashoverride> guys, there's *no* lxde packages at all in alpine?
2020-03-29 18:06:58 <crashoverride> :/
2020-03-29 18:07:46 <Cogitri> Well, you can be the one to introduce and maintain that :)
2020-03-29 18:08:28 <crashoverride> I know, but I totally expected lxde to exist in alpine
2020-03-29 18:08:39 <crashoverride> I mean, there is xfce...
2020-03-29 18:09:13 <crashoverride> ncopa: ^ is there really no lxde or am I missing the package somehow?
2020-03-29 18:09:42 <Cogitri> No, there's no such package
2020-03-29 18:09:58 <Cogitri> And how is having xfce a reason for having lxde
2020-03-29 18:09:58 <crashoverride> Cogitri: oh, so you know for sure?
2020-03-29 18:10:30 <crashoverride> Cogitri: alpine is historically a lightweight distro
2020-03-29 18:10:45 <Cogitri> https://pkgs.alpinelinux.org/packages?name=lxde&branch=edge
2020-03-29 18:10:56 <crashoverride> Cogitri: so it would make sense to introduce the lightweight options first
2020-03-29 18:11:09 <Cogitri> pkgs.a.o doesn't lie
2020-03-29 18:11:10 <crashoverride> Cogitri: yeah so you did exactly what I did
2020-03-29 18:11:16 <crashoverride> Cogitri: no but naming does
2020-03-29 18:11:26 <maxice8> there is no lxde, i assume because nobody packaged it or it rotted away
2020-03-29 18:11:26 <Cogitri> It makes sense to introduce whatever the maintainers want
2020-03-29 18:12:04 <crashoverride> what if the package is named Lightweight-X11-Desktop-Environment
2020-03-29 18:12:15 <crashoverride> then we wouldn't find it
2020-03-29 18:12:20 <Cogitri> Well, it's not
2020-03-29 18:12:35 <Cogitri> And even if it did I'd hope it would include lxde in the description or something
2020-03-29 18:12:52 <crashoverride> fair
2020-03-29 18:13:08 <crashoverride> maxice8: that sucks
2020-03-29 18:13:12 <crashoverride> okay, thanks guys
2020-03-29 18:13:53 <maxice8> isn't lxde abandoned in favor of lxqt ?
2020-03-29 18:14:19 <crashoverride> maxice8: oh
2020-03-29 18:14:32 <crashoverride> maxice8: that's a thing, you're right
2020-03-29 18:14:38 <maxice8> regardless i also think lxqt isn't it, there is a lxqt-build-tools package in testing/
2020-03-29 18:15:03 <maxice8> i guess someone started contributing it and forgot it or it was removed due to no maintainers for it
2020-03-29 18:15:18 <crashoverride> no but that would explain a lot about why it's not here tho
2020-03-29 18:16:14 <maxice8> The most probable explanation is nobody did the work for it yet
2020-03-29 18:19:46 <crashoverride> sure, but what I meant is: who'd put the work in a dead project?
2020-03-29 18:21:08 <c705> you!
2020-03-29 18:30:56 <paper_> hi, could someone look at this? I can't figure out why tox.ini isn't getting patched https://gitlab.alpinelinux.org/paper/aports/commit/637815bd3ec7242f417a39507932613296cfc4ac abuild -r output: https://ttm.sh/ECu.txt
2020-03-29 18:32:55 <paper_> and what does this mean in CI? fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address
2020-03-29 18:33:46 <_ikke_> paper_: I don't see a tox.ini in the source
2020-03-29 18:35:05 <paper_> ah, that's a stupid mistake, I didn't notice it isn't in the release
2020-03-29 18:35:20 <paper_> thanks a lot
2020-03-29 18:51:45 <nmeum> the latest xorg-server upgrade broke xdm for me, xdm writes PAM authentication failures to /var/log/xdm even with a correct password
2020-03-29 18:51:55 <nmeum> something also writes "No worthy mechs found" to authlog no idea what yet
2020-03-29 18:52:02 <nmeum> downgrade xorg-server fixed it for me
2020-03-29 18:54:52 <Cogitri> Huh, how would a xorg server upgrade break PAM?
2020-03-29 18:55:04 <Cogitri> Or rather, a switch from configure to meson
2020-03-29 18:55:06 <Cogitri> fwiw it works fine in GNOMW
2020-03-29 18:55:10 <Cogitri> s/W/E/
2020-03-29 18:55:10 <alpine-meetbot> Cogitri meant to say: fwiw it works fine in GNOME
2020-03-29 18:55:29 <nmeum> hm, seems the upgrade to meson turned xcsecurity off
2020-03-29 18:55:32 <nmeum> maybe that's related
2020-03-29 18:55:34 <nmeum> let me check
2020-03-29 18:56:20 <nmeum> > -Dxdm-auth-1=false
2020-03-29 18:56:21 <nmeum> ah
2020-03-29 18:56:45 <nmeum> there are a bunch of configuration changes in that commit it seems
2020-03-29 18:57:58 <Cogitri> maxice8: ^
2020-03-29 18:59:48 <maxice8> I see
2020-03-29 19:00:04 <maxice8> that was an MR that was living for a few weeks and nobody raised a fuss after i mentioned it a few times here
2020-03-29 19:00:29 <nmeum> well…happens
2020-03-29 19:00:47 <nmeum> I will do some tests and push a fix for xdm as soon as I am done with that
2020-03-29 19:00:48 <maxice8> 90% of the time
2020-03-29 19:01:11 <maxice8> !6002
2020-03-29 19:03:09 <nmeum> already have a commit in my local repo
2020-03-29 19:03:15 <nmeum> what about xrsecurity
2020-03-29 19:04:10 <maxice8> added it
2020-03-29 19:04:14 <nmeum> that seems to have been explicitly enabled previously but isn't anymore. any reason why that's the case?
2020-03-29 19:04:32 <maxice8> Most likely lost in the translation
2020-03-29 19:04:55 <maxice8> i copied the initial call to configure meson from the arch linux PKGBUILD and tried to adapt to ours
2020-03-29 19:04:57 <maxice8> must have missed it
2020-03-29 19:04:58 <nmeum> I will do some more tests
2020-03-29 19:05:07 <nmeum> will push my commit as soon as I am done with that
2020-03-29 19:18:06 <nmeum> hmok
2020-03-29 19:18:41 <nmeum> seems to work, pushed my local commits
2020-03-29 19:39:56 <maxice8> ikke: please make public https://gitlab.alpinelinux.org/alpine/aports/merge_requests/6003
2020-03-29 19:41:57 <_ikke_> done
2020-03-29 19:42:12 <maxice8> ty
2020-03-29 19:43:29 <paper_> sorry, I didn't realise editing by collaborators was turned off
2020-03-29 19:44:24 <crashoverride> do you guys know that firefox segfaults on a fresh upgrade to 3.11?
2020-03-29 19:44:34 <crashoverride> I did apk add firefox-esr
2020-03-29 19:44:39 <crashoverride> firefox
2020-03-29 19:44:44 <crashoverride> and bam, segfault
2020-03-29 19:45:02 <crashoverride> now moving over to edge
2020-03-29 19:45:09 <crashoverride> just in case it helps
2020-03-29 19:46:48 <Cogitri> You use linux-lts, right?
2020-03-29 19:50:41 <crashoverride> nevermind, I solved the problem
2020-03-29 19:51:32 <mps> Cogitri: clang10, llvm10, lld10 are now default?
2020-03-29 19:53:06 <mps> according to git log they are. sorry for disturbance
2020-03-29 20:10:27 <Cogitri> No worries
2020-03-29 20:10:29 <Cogitri> Yes, they're the default now
2020-03-29 20:10:35 <Cogitri> Only llvm is versioned so clang and lld always are the latest version
2020-03-29 21:13:10 <mps> hmm, again '>>> ERROR: zig: 0.5.0_20200329 is not a valid version'
2020-03-29 21:13:24 <mps> why?
2020-03-29 21:13:29 <[[sroracle]]> you're missing "git" before the date
2020-03-29 21:13:39 <[[sroracle]]> 0.5.0_git20200329
2020-03-29 21:13:49 <mps> ah, will try. thanks
2020-03-29 22:15:58 <PaXboi> Hello to alpine-devel. I am trying to build WINE 5.5 on Alpine Linux x86. However, the build fails to complete due to gcc segfaulting. Are there problems building modern WINE on this platform? Here is a build log: https://pastebin.com/6f0ytJKY
2020-03-29 22:22:47 <afontain_> I'd say reports of gcc segfaulting should go to gcc devs
2020-03-29 22:23:44 <mps> PaXboi: do you have enough RAM to build wine
2020-03-29 22:24:21 <PaXboi> yes, my build machine has 16gb... although i am trying to build it in an x86 chroot on an x86_64 machine
2020-03-29 22:25:12 <mps> hm, maybe gcc 9.3 havea bug on x86 32bit
2020-03-29 22:25:54 <Cogitri> A backtrace of the coredump would certainly help.
2020-03-29 22:26:09 <PaXboi> you're right, ill look into that
2020-03-29 22:26:51 <mps> Cogitri: you are still here, zig is ready, have to polish APKBUILD a little before push
2020-03-29 22:27:06 <Cogitri> Okie, good :)
2020-03-29 22:27:31 <Cogitri> Thanks for taking care of that
2020-03-29 22:28:04 <Cogitri> PaXboi: Shameless plug, but corecollector can help you with obtaining the coredump and getting a backtrace
2020-03-29 22:28:42 <mps> well, we are team, despite a little disorganized :)
2020-03-29 22:30:09 <PaXboi> i have a coredump. i suppose ill open it up in gdb, can't remember the last time i had to do this
2020-03-29 22:31:46 <PaXboi> oh actually, thats interesting, it was not generated by gcc. it's from some wine tool gcc built. don't know how i missed that
2020-03-29 22:33:11 <Cogitri> Yeah, kind of anticipated that
2020-03-29 22:33:38 <Cogitri> Since GCC usually throws some error handling code into SEGFAULTs which tell you to report a bug
2020-03-29 22:36:23 <PaXboi> i see. the segfault is from a function in musl. not too experienced in this. is there a way i can get debug symbols or something for musl so i can see what function is causing the segfault?
2020-03-29 22:43:55 <PaXboi> i have debug symbols. anyone know what this means?
2020-03-29 22:43:56 <PaXboi> Program received signal SIGSEGV, Segmentation fault.0xf7fc44fe in do_relocs (dso=dso@entry=0xf7ffcc00 <app>, rel=0x565559e8, rel_size=23632, stride=2) at ldso/dynlink.c:460460	ldso/dynlink.c: No such file or directory.
2020-03-29 22:44:19 <PaXboi> my bad: https://pastebin.com/feNt2fgs
2020-03-29 22:44:25 <Hello71> well according to this log you posted, the program "widl" crashed
2020-03-29 22:47:15 <PaXboi> yes, gcc builds the "widl" program (some wine tool) and the makefile calls it on something. it segfaults which appears to be a musl problem (with dynamic linking?). this is preventing new builds of wine on alpine.
2020-03-29 23:03:57 <PaXboi> statically linking widl fixes it, but wine still fails to build because something else is broken
2020-03-29 23:04:06 <PaXboi> probably musl bug
2020-03-29 23:21:40 <PaXboi> i'm making very good progress in getting wine 5.5 to build. if i do manage to get it working, ill submit a pull request on aports.
2020-03-29 23:22:41 <PaXboi> well for wine 5.0 stable, anyway
2020-03-29 23:25:19 <PaXboi> actually, perhaps not. i thought it was public on gitlab or something. should i just submit a patch to the maintainer or something?
2020-03-30 01:45:21 <dalias> is there an easy way to configure alpine's fsck service to run automatically iff kernel mounts rootfs ro because of errors?
2020-03-30 05:38:35 <mps> dalias: isn't that configured by sixth (last) field in /etc/fstab
2020-03-30 05:40:31 <mps> and 'rc-update add fsck boot'
2020-03-30 06:55:01 <Ariadne> heads up: libucontext 0.10 has been pushed, which supercedes the adelie fork which was never pushed into alpine anyway
2020-03-30 06:55:12 <Ariadne> so we are going from 0.1.3 to 0.10
2020-03-30 06:58:07 <Cogitri> Oh, quite the jump
2020-03-30 06:58:14 <Ariadne> not really
2020-03-30 06:58:22 <Ariadne> adelie decided to bump it to 0.9 from 0.1.3
2020-03-30 06:59:40 <Cogitri> Oh
2020-03-30 06:59:53 <Cogitri> That's an interesting version scheme
2020-03-30 07:43:10 <Ariadne> so, how does one bootstrap rust on alpine
2020-03-30 07:45:53 <mps> when I introduced zig in aports I made mistake, created zig pkg and zig-dev subpkg
2020-03-30 07:46:29 <mps> now I want to remove zig-dev and merge it to zig pkg
2020-03-30 07:46:44 <mps> and upgrade zig
2020-03-30 07:47:32 <mps> should I add 'provides' or 'replaces' in APKBUILD, or something else
2020-03-30 07:49:26 <mps> or, by upgrading zig without zig-dev subpkg it will magically disappear from repos
2020-03-30 07:52:29 <Ariadne> zig should have provides/replaces on zig-dev
2020-03-30 07:52:49 <Ariadne> to ensure upgrades work
2020-03-30 07:53:01 <Ariadne> or you can just delete it
2020-03-30 07:53:06 <Ariadne> if the package is in testing
2020-03-30 07:53:09 <Ariadne> who cares
2020-03-30 07:53:10 <Ariadne> :p
2020-03-30 07:54:08 <Cogitri> Ariadne: You'll need some base rust tarball to bootstrap from
2020-03-30 07:54:32 <Ariadne> so how do i generate that
2020-03-30 07:54:39 <Ariadne> how does that interact with the APKBUILD etc
2020-03-30 07:54:42 <Cogitri> Not sure if they provide mips64 musl tarballs, so you'll probably have to crosscompile that yourself
2020-03-30 07:54:54 <Cogitri> It doesn't interact with the APKBUILD at all.
2020-03-30 07:55:14 <Cogitri> Bootstrapping an arch for Rust currently has to be done manually
2020-03-30 07:55:51 <Ariadne> so basically make a container with a working rustc/cargo
2020-03-30 07:56:01 <Ariadne> and then build rust package inside that container
2020-03-30 07:56:04 <mps> hmm, first remove zig, and then add 'new aport'
2020-03-30 07:56:19 <Ariadne> mps: that would also do it
2020-03-30 07:56:51 <Cogitri> No, basically get a working tarball of Rust on that arch and then set LD_LIBRARY_PATH and PATH to use that for bootstrapping
2020-03-30 07:57:14 <Ariadne> ok
2020-03-30 07:57:29 <Ariadne> and then use that to generate an apk
2020-03-30 07:57:33 <Ariadne> which can be installed on builder
2020-03-30 07:57:35 <Ariadne> got it
2020-03-30 07:58:01 <Cogitri> See 6c8381ba967cd3842484965f3f7c1200a42a5539 for how I did it on other arches
2020-03-30 08:07:53 <Ariadne> it occured to me
2020-03-30 08:07:59 <Ariadne> that since we have libucontext
2020-03-30 08:08:05 <Ariadne> we can make gccgo work again too
2020-03-30 08:08:09 <Ariadne> not just D
2020-03-30 08:08:51 <Cogitri> Would gccgo be for (basically) boostrapping only too?
2020-03-30 09:13:12 <minecrell> Cogitri: bcc doesn't seem to build anymore with weird llvm errors :\
2020-03-30 09:13:26 <minecrell> https://gitlab.alpinelinux.org/Minecrell/aports/-/jobs/79050#L1898
2020-03-30 09:13:38 <minecrell> this worked fine few days ago, I supect the clang/llvm update
2020-03-30 09:15:46 <minecrell> maybe it would be enough to bump it to llvm 10? idk
2020-03-30 09:24:17 <Cogitri> Probably
2020-03-30 09:24:24 <Cogitri> Very weird that it only fails now though
2020-03-30 09:24:38 <Cogitri> And weird that apk doesn't show it as dependant on llvm9
2020-03-30 09:25:01 <ncopa> ah.. looks like it uses clang + llvm9
2020-03-30 09:25:06 <Cogitri> Ah no, not weird that it fails, it needs llvm and clang and you can't mix llvm9 with clang10
2020-03-30 09:25:07 <ncopa> i wonder if clang was updated to 10
2020-03-30 09:25:12 <Cogitri> Fixing it
2020-03-30 09:25:12 <Cogitri> Yes
2020-03-30 09:25:19 <minecrell> yep, llvm10 works
2020-03-30 09:25:39 <minecrell> do you want to fix that separately or should I just push it to https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5905?
2020-03-30 09:25:53 <Cogitri> I'll fix it right now
2020-03-30 09:26:14 <ncopa> may be more of those
2020-03-30 09:26:53 <Cogitri> Possibly, the annoying thing is that I have to go through APKBUILDs to see if they only need clang-dev to use it as CC/CXX or if they link to libclang
2020-03-30 09:28:18 <mps> ncopa: good morning, you should decide what to do with crystal before freeze, best would be if you decide RSN
2020-03-30 09:28:59 <ncopa> i'd like to fix it
2020-03-30 09:29:12 <mps> :)
2020-03-30 09:29:25 <ncopa> fix build with new llvm
2020-03-30 09:29:55 <mps> if you can I will be happy, but I have no idea how
2020-03-30 09:34:03 <Cogitri> I guess I'll go through clang-dev / llvm-static dependants later today
2020-03-30 09:38:26 <ncopa> what more should we fix/update before feature freeze?
2020-03-30 09:47:57 <minecrell> ncopa: FYI, I rebased https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5905 again after the llvm fix and it seems to build fine now :)
2020-03-30 09:49:04 <Cogitri> !5870 would be good to have I suppose
2020-03-30 09:51:56 <kaey> Cogitri: why did you change paths for man pages in bpftrace? https://git.alpinelinux.org/aports/commit/testing/bpftrace/APKBUILD?id=32cfcc20369ef63b64311b080ce4116c9a82828d
2020-03-30 09:54:34 <mps> maybe it is time to 'triage' (to be in trend :) ) packages which could/should be removed or moved to unmaintained
2020-03-30 09:59:48 <Cogitri> kaey: Upstream changed the location
2020-03-30 09:59:57 <andypost[m]> @ncopa please check gd and zendfamework !5729 !5809
2020-03-30 10:00:04 <Cogitri> The moving didn't seem necessary to me anymore.
2020-03-30 10:02:19 <kaey> well it's not packaged correctly now, tool docs shouldn't be in shared MANPATH, because tolls themselves are not in PATH and they conflict with docs from bcc, which provides same tools
2020-03-30 10:02:31 <kaey> s/toll/tool
2020-03-30 10:02:32 <alpine-meetbot> kaey meant to say: well it's not packaged correctly now, tool docs shouldn't be in shared MANPATH, because tools themselves are not in PATH and they conflict with docs from bcc, which provides same tools
2020-03-30 10:03:27 <Cogitri> Oh, didn't know bcc provided the same docs
2020-03-30 10:04:35 <Cogitri> Since you seem to know the situation better, could you make a MR maybe?
2020-03-30 10:05:43 <kaey> ok, later
2020-03-30 10:06:17 <Cogitri> Thank you :)
2020-03-30 10:14:48 <mps> _ikke_: when you upgrade zig (when it finish build) you can do this on x86_64 'zig cc hello.c -target aarch64-linux-musl', then copy to aarch64 and run
2020-03-30 10:16:21 <Cogitri> ncopa: I don't think freezing Rust really is a good idea since they don't do stable patch releases
2020-03-30 10:17:04 <_ikke_> mps: ?
2020-03-30 10:20:01 <mps> you posted url few days ago about this
2020-03-30 10:20:47 <_ikke_> yes
2020-03-30 10:21:36 <mps> I tested it on alpine
2020-03-30 10:22:03 <mps> thought you are interested in it
2020-03-30 11:03:11 <_ikke_> Linux 5.6 has been released
2020-03-30 11:14:25 <mps> _ikke_: Linux zarya 5.6.0-1-gru #2 SMP PREEMPT Mon Mar 30 10:24:20 CEST 2020 aarch64 GNU/Linux
2020-03-30 11:14:48 <mps> running on my chromebook
2020-03-30 11:18:34 <clandmeter> heh
2020-03-30 11:20:30 <_ikke_> mps: nice
2020-03-30 11:21:52 <mps> I still not found good name for linux-to_be_in_testing
2020-03-30 11:22:23 <_ikke_> latest-stable sounded good to me
2020-03-30 11:22:38 <mps> and need to find fix for apk on armv7 with 5.6
2020-03-30 11:23:34 <mps> _ikke_: ok, you are godfather :) will name it linux-stable
2020-03-30 11:24:49 <mps> looks like apk tools have a bug related to renameat2 syscall
2020-03-30 11:46:59 <mps> oh, my internet failed
2020-03-30 12:02:41 <minecrell> ncopa: "aborted the automatic merge because target branch was updated", I get the feeling the new way to merge MRs isn't ideal for changes that require a bit of time in CI :)
2020-03-30 12:03:04 <Ariadne> yes
2020-03-30 12:03:11 <Cogitri> Yes, tha doesn't really work with multiple devs
2020-03-30 12:03:26 <Cogitri> I usually just check the CI works and then rebase and merge in one go
2020-03-30 12:03:28 <Ariadne> it does with non-ff merges
2020-03-30 12:03:43 <Cogitri> Well yes
2020-03-30 12:03:46 <Cogitri> But we don't do that
2020-03-30 12:38:53 <minecrell> mps: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/6032
2020-03-30 12:41:09 <minecrell> yay it fails on s390x, great
2020-03-30 12:41:16 <mps> minecrell: that need 'more' works on APKBUILD
2020-03-30 12:41:39 <mps> I expected its fail
2020-03-30 12:42:33 <minecrell> Why?
2020-03-30 12:43:00 <mps> did you looked in linux tree tools dir deeply
2020-03-30 12:43:22 <minecrell> how deeply?
2020-03-30 12:43:36 <minecrell> guess not
2020-03-30 12:43:55 <mps> Marianne deep in Pacific
2020-03-30 12:44:54 <mps> https://en.wikipedia.org/wiki/Mariana_Trench
2020-03-30 12:44:55 <alpine-meetbot> [WIKIPEDIA] Mariana Trench | "The Mariana Trench or Marianas Trench is located in the western Pacific Ocean about 200 kilometres (124 mi) east of the Mariana Islands; it is the deepest trench on Earth. It is crescent-shaped and measures about 2,550 km (1,580 mi) in length and 69 km (43 mi) in width. The maximum known depth is 10..."
2020-03-30 12:45:41 <mps> oh, what's that?
2020-03-30 12:46:41 <mps> every tool under tools have specific build requirements and not all can be built on all arches
2020-03-30 12:47:05 <minecrell> I understand that (for some tools), but iio should be pretty generic...
2020-03-30 12:48:59 <mps> I don't know if it works on s390x, or ppc64
2020-03-30 12:50:21 <_ikke_> wg 1.0.0 released as well
2020-03-30 12:51:19 <mps> tools?
2020-03-30 12:51:57 <_ikke_> Headline is "Wireguard 1.0. for Linux 5.6.0 released"
2020-03-30 12:52:32 <mps> wg driver is in 5.6
2020-03-30 12:52:38 <_ikke_> yes
2020-03-30 12:53:03 <_ikke_> I guess the code for wg that landed in 5,6 is what they consider 1.0.0
2020-03-30 12:55:33 <mps> where did you read this announce
2020-03-30 12:55:46 <mps> nothing in their git
2020-03-30 12:56:41 <Hello71> http://google.com/search?q=Wireguard+1.0.+for+Linux+5.6.0+released
2020-03-30 12:57:31 <minecrell> mps: so I have fixed the s390x build failure, but I'm not sure you will like the fix
2020-03-30 12:57:42 <minecrell> it requires backporting a patch from upstream :p
2020-03-30 12:57:52 <PureTryOut[m]> > Google
2020-03-30 12:58:15 <_ikke_> mps: anouncement on WG mailing list
2020-03-30 12:58:18 <mps> minecrell: I don't care, TBH
2020-03-30 12:58:18 <_ikke_> https://lore.kernel.org/wireguard/CAHmME9qOpDeraWo5rM31EWQW574KEduRBTL-+0A2ZyqBNDeYkg@mail.gmail.com/T/#u
2020-03-30 12:59:07 <mps> _ikke_: I see
2020-03-30 12:59:35 <Shiz> Cogitri: ohey
2020-03-30 12:59:47 <Shiz> i heard there was some issue with rust triplets?
2020-03-30 13:00:08 <mps> usa4 is not accessible for me now, and there is my WG git tree
2020-03-30 13:02:53 <minecrell> mps: I could do the gpio tools too while I'm at it, but I haven't used them yet so wasn't sure if you'd prefer packaging them at some point
2020-03-30 13:02:56 <Cogitri> Shiz: Yes, see https://github.com/rust-lang/rust/issues/62447
2020-03-30 13:03:28 <Shiz> Cogitri: i wrote the patch we use, so maybe i can be of some assistance
2020-03-30 13:06:21 <Cogitri> Yes, that'd be nice
2020-03-30 13:07:23 <mps> minecrell: if you want do it. anyway I package myself all pkgs with which I'm not satisfied how they are packaged in aports
2020-03-30 13:08:27 <minecrell> mps: I'll check if it builds on first try. Feel free to tear everything apart, I just want the iio tools packaged somehow since I need them occasionally :)
2020-03-30 13:09:47 <Ariadne> Cogitri: i'm confused about how libucontext is used by GDC.
2020-03-30 13:09:51 <mps> minecrell: actually I'm thinking of building tools from testing/linux-stable (when it become ready)
2020-03-30 13:10:08 <Ariadne> Cogitri: i do not see anything that actually includes -lucontext in any linking stage
2020-03-30 13:10:30 <minecrell> mps: also fine with me :)
2020-03-30 13:10:40 <minecrell> having newer versions might even be better
2020-03-30 13:10:47 <minecrell> afaik perf is somewhat kernel specific
2020-03-30 13:13:58 <mps> yes, because that linux-tools follows linux-{vanilla,lts}
2020-03-30 13:17:14 <Cogitri> Ariadne: Not sure about that
2020-03-30 13:17:37 <Shiz> Cogitri: so what happens right now is that we expect the build system to not care about the target triplet until it needs to build a compiler for it
2020-03-30 13:18:00 <Ariadne> Cogitri: i suspect the GDC on s390x is not generating useful binaries
2020-03-30 13:18:03 <Shiz> stage0 is downloaded, which then compiles our sources including our new target triplet (stage1), which then compiles the compiler for our actual target triplet (stage2)
2020-03-30 13:18:43 <Cogitri> Ariadne: Hm, can't really test that, but it didn't link at all without ucontext
2020-03-30 13:18:49 <Shiz> stage0 has no knowledge of our target triplet, stage1 knows about the triplet but doesn't target it by default, stage2 knows about it and targets it
2020-03-30 13:18:55 <Ariadne> Cogitri: i can test it right now
2020-03-30 13:18:56 <Shiz> (if memory serves, and if nothing changed)
2020-03-30 13:19:02 <Cogitri> Thanks
2020-03-30 13:19:28 <Shiz> there could be a build system regression that requires stage0 to know about the eventual target triplet
2020-03-30 13:19:30 <Cogitri> Shiz: Yes, about right. The problem is that crt_static is enabled for some reason
2020-03-30 13:19:32 <Ariadne> Cogitri: do you have a sample 'hello world' D program
2020-03-30 13:19:36 <Shiz> it'd be the first thing i'm thinking of
2020-03-30 13:20:10 <Cogitri> ```
2020-03-30 13:20:10 <Cogitri>     writeln("hello world");
2020-03-30 13:20:10 <Cogitri> import std.stdio;
2020-03-30 13:20:10 <Cogitri> void main() {
2020-03-30 13:20:10 <Cogitri> }
2020-03-30 13:20:11 <Cogitri> ```
2020-03-30 13:20:12 <Shiz> Cogitri: for some reason, even with the Alpine target triplet?
2020-03-30 13:20:19 <Shiz> or for some reason in -unknown-musl
2020-03-30 13:20:21 <Ariadne> mmmkay
2020-03-30 13:20:30 <Cogitri> It only happens in the Alpine target triplet.
2020-03-30 13:20:31 <Cogitri> See the Rust issue
2020-03-30 13:20:53 <Cogitri> Even if I make an Alpine triplet that is exactly the same as the unkown-musl triplet
2020-03-30 13:21:04 <Cogitri> It works just fine with the unknown-musl triplets right now
2020-03-30 13:21:29 <Cogitri> I guess we might have to feed rustc some triplet definitions in JSON so it disables crt_static
2020-03-30 13:23:08 <Shiz> i wonder if they added additional triplet storage
2020-03-30 13:23:19 <Shiz> if i have access to my x86_64 build box still, i'll check
2020-03-30 13:23:22 <Shiz> this evening
2020-03-30 13:23:27 <Cogitri> Thank you
2020-03-30 13:23:31 <Ariadne> 
ACTION patiently waits for the s390x VM to boot

2020-03-30 13:23:51 <Ariadne> z/VM is pretty obnoxious, -10/10 wouldn't recommend
2020-03-30 13:24:35 <Ariadne> Cogitri: i'm confused as to how GDC gets linked to libucontext to begin with
2020-03-30 13:25:07 <Cogitri> I didn't question that, but evidently having it installed fixes the linking
2020-03-30 13:25:41 <Ariadne> interestingly, libgphobos does link against it
2020-03-30 13:26:24 <mps> _ikke_: https://git.zx2c4.com/wireguard-linux-compat/about/
2020-03-30 13:26:53 <Ariadne>         /lib/ld-musl-s390x.so.1 (0x3ffb5300000)
2020-03-30 13:26:53 <Ariadne>         libucontext.so.0 => /lib/libucontext.so.0 (0x3ffb5100000)
2020-03-30 13:26:55 <Ariadne> indeed
2020-03-30 13:27:04 <Ariadne> okay weird but not arguing
2020-03-30 13:27:59 <Ariadne> s390x:~# gdc -o test test.d
2020-03-30 13:27:59 <Ariadne> s390x:~# ./test
2020-03-30 13:27:59 <Ariadne> hello world
2020-03-30 13:28:00 <Ariadne> ok
2020-03-30 13:28:02 <Ariadne> guess it works
2020-03-30 13:28:20 <Cogitri> Neat
2020-03-30 13:29:20 <Ariadne> ET_DYN libgcc_s.so.1,libucontext.so.0,libc.musl-s390x.so.1 ./test
2020-03-30 13:29:32 <Ariadne> okay
2020-03-30 13:31:05 <Ariadne> i have halted mips64 builder to see what the f is up with this gcc-9.3.0 over there
2020-03-30 13:33:23 <Ariadne> also, libucontext 0.1.3 and 0.9 had some defects on s390x
2020-03-30 13:33:28 <Ariadne> i have addressed them in libucontext 0.10
2020-03-30 14:02:25 <PureTryOut[m]> Could somebody rebuild libphonenumber on x86? It seems to be broken, I can't build a package depending on it and it fails on undefined references to stuff in that package
2020-03-30 14:17:01 <mps> _ikke_: re WG: found little time to read about it, no big changes in last few days, just promoted/christened to 1.0.0
2020-03-30 14:17:19 <_ikke_> mps: yes, I figured as much
2020-03-30 14:51:35 <PureTryOut[m]> Could somebody rebuild libphonenumber on x86? It seems to be broken, I can't build a package depending on it and it fails on undefined references to stuff in that package
2020-03-30 14:51:40 <PureTryOut[m]> It currently blocks the pmOS x86 builder
2020-03-30 14:53:35 <_ikke_> PureTryOut[m]: why specific on x86?
2020-03-30 14:54:24 <PureTryOut[m]> Because specificaly that one is broken
2020-03-30 14:54:47 <PureTryOut[m]> The same package builds fine on all other arches, so just the x86 one is broken
2020-03-30 14:54:53 <PureTryOut[m]> See https://builds.sr.ht/~postmarketos/job/177885#task-pmbootstrap_build
2020-03-30 14:55:08 <PureTryOut[m]> Actually, better url https://builds.sr.ht/~postmarketos/job/177885#task-pmbootstrap_build-1153
2020-03-30 14:55:19 <_ikke_> But why would a rebuild fix it?
2020-03-30 14:55:39 <PureTryOut[m]> Because libphonenumber is known to have race conditions
2020-03-30 14:55:52 <PureTryOut[m]> And this one is exactly like one
2020-03-30 14:55:57 <_ikke_> Ok, but we would need to rebuild it on all arches
2020-03-30 14:56:03 <_ikke_> we cannot rebuilt it on just one arch
2020-03-30 14:56:04 <Ariadne> there's no such thing as a "race condition"
2020-03-30 14:57:00 <Ariadne> these are ABI mismatches, and they're caused by not specifying precise dependencies when necessary
2020-03-30 14:57:15 <PureTryOut[m]> Oh so just a pkgrel bump then
2020-03-30 14:57:24 <Ariadne> yes, but it will happen again
2020-03-30 14:57:32 <Ariadne> if the dependencies are not properly specified
2020-03-30 14:57:34 <PureTryOut[m]> _ikke_: libphonenumber is one of those packages where it might fail to build 3 or so times, and then the fourth time suddenly goes through fine. This happened multiple times on CI and the builders, and now the same error happens with one of our packages depending on it
2020-03-30 14:57:45 <Ariadne> ?????
2020-03-30 14:58:02 <_ikke_> PureTryOut[m]: maybe we need to figure out why then
2020-03-30 14:58:33 <Ariadne> what _ikke_ said
2020-03-30 14:58:52 <Ariadne> that means there is a problem and we need to solve it, not just rebuild things and hope for the best
2020-03-30 14:59:03 <PureTryOut[m]> Why would it? This same dependency tree build fine on multiple other architectures
2020-03-30 14:59:08 <_ikke_> PureTryOut[m]: Is it the build system that is broken?
2020-03-30 14:59:20 <_ikke_> ie, missing internal dependencies
2020-03-30 15:00:02 <PureTryOut[m]> I do not know
2020-03-30 15:00:05 <Ariadne> /home/buildozer/aports/main/gcc/src/gcc-9.3.0/libphobos/libdruntime/core/sys/posix/fcntl.d:874:9: error: static assert  "Platform not supported"
2020-03-30 15:00:07 <Ariadne> :(
2020-03-30 15:00:09 <PureTryOut[m]> I don't know why libphonenumber is broken like this. I just know rebuilding it works lol
2020-03-30 15:00:22 <_ikke_> Did you try reporting it upstream?
2020-03-30 15:02:23 <PureTryOut[m]> Ariadne: I mean obviously, but right now I want our builders unblocked. Guess I'll fork the package to pmOS repos in the meantime...
2020-03-30 15:02:44 <_ikke_> PureTryOut[m]: or just submit a pkgrel bump patch
2020-03-30 15:03:04 <_ikke_> That's the only way to rebuild packages
2020-03-30 15:03:05 <Ariadne> give me a moment and i will take care of it
2020-03-30 15:03:07 <Ariadne> but
2020-03-30 15:03:22 <Ariadne> at your leisure, please fix it correctly
2020-03-30 15:04:32 <PureTryOut[m]> If that's accepted then sure
2020-03-30 15:04:36 <PureTryOut[m]> Cool 👍️
2020-03-30 15:04:43 <PureTryOut[m]> Of course, if I figure out what the hell is going on
2020-03-30 15:05:02 <Ariadne> rebuild submitted to builders
2020-03-30 15:05:59 <_ikke_> and failed :-/
2020-03-30 15:06:08 <_ikke_> "undefined reference to `i18n::phonenumbers::PhoneMetadata::~PhoneMetadata()'"
2020-03-30 15:06:19 <Ariadne> i figured out the problem
2020-03-30 15:06:35 <Cogitri> Oh? :o
2020-03-30 15:06:37 <Ariadne> it's building static lib and shared lib
2020-03-30 15:06:50 <Ariadne> the 'race condition' is that the broken ass static lib is picked by linker first
2020-03-30 15:07:09 <Ariadne> solution: configure it to not build the static lib
2020-03-30 15:07:52 <Ariadne> no i don't know how to do that
2020-03-30 15:07:56 <Ariadne> that part is on somebody else
2020-03-30 15:08:14 <Ariadne> back to fixing GDC on musl
2020-03-30 15:08:19 <_ikke_> Ariadne: out of interest, how did you find that?
2020-03-30 15:08:30 <Ariadne> i read the error messages
2020-03-30 15:08:35 <_ikke_> Linking static ...?
2020-03-30 15:08:42 <Ariadne> they refer to libphonenumber.a
2020-03-30 15:08:46 <Ariadne> that's a static lib :)
2020-03-30 15:08:54 <_ikke_> Right
2020-03-30 15:09:01 <Cogitri> Ariadne: What's there to fix with gdc?
2020-03-30 15:09:13 <Ariadne> Cogitri: i need to teach it about MIPS64
2020-03-30 15:09:30 <Ariadne> or really, just MIPS in general
2020-03-30 15:09:38 <Cogitri> Ah, so s/musl/mips64/ there
2020-03-30 15:09:52 <Cogitri> Well, I don't think that'll be a good experience, GDC has a rather outdated libphobos
2020-03-30 15:11:18 <_ikke_> PureTryOut[m]: kdav is missing deps on armhf
2020-03-30 15:12:30 <Ariadne> Cogitri: hmm okay, i'll just drop D support on MIPS64 for now
2020-03-30 15:12:39 <Ariadne> we can revisit when we make GCC 10 jump
2020-03-30 15:12:47 <Cogitri> Probably a good idea, yes
2020-03-30 15:13:03 <Ariadne> but it seems to only be one file that needs fixing
2020-03-30 15:16:49 <PureTryOut[m]> Interesting, good find!
2020-03-30 15:16:50 <PureTryOut[m]> That should be relatively easy to solve then, let's try it a few times locally
2020-03-30 15:18:19 <Ariadne> hah
2020-03-30 15:18:22 <Ariadne> it built
2020-03-30 15:18:27 <Ariadne> Cogitri: i have a patch
2020-03-30 15:20:14 <Cogitri> Well, is it actually functional though?
2020-03-30 15:20:24 <Cogitri> Try building corecollector or smth and run the test suite
2020-03-30 15:21:59 <Ariadne> is that packaged in alpine already
2020-03-30 15:26:34 <PureTryOut[m]> Ariadne: actually, I don't see how libphonenumber building a static library is the problem? The compilation failure seems to happen before it links the static library
2020-03-30 15:26:49 <Cogitri> Ariadne: Yes, it's in community
2020-03-30 15:26:57 <Ariadne> PureTryOut[m]: you don't link a static library
2020-03-30 15:27:51 <_ikke_> A static library is 'embedded' (partially) in an executable right?
2020-03-30 15:29:02 <PureTryOut[m]> You'd think so, but the log says "[ 72%] Linking CXX static library libphonenumber.a"
2020-03-30 15:32:21 <Ariadne> its linking the test that causes the error
2020-03-30 15:32:30 <Ariadne> and the error is because libphonenumber.a is busted
2020-03-30 15:32:44 <Ariadne> if you get rid of libphonenumber.a it really will work i assure you
2020-03-30 15:49:34 <ncopa> i guess the fix is to simply ad -steatic subpackage. i can look at that now
2020-03-30 15:49:43 <ncopa> add -static*
2020-03-30 15:50:28 <ncopa> looks like we already have a -static
2020-03-30 15:58:52 <Cogitri> Not sure how that would change anything, ncopa
2020-03-30 15:59:08 <Cogitri> Since libphonenumber fails when linking its own static subpkg
2020-03-30 16:03:02 <ncopa> hum ok, maybe i just misunderstood what theproblem was
2020-03-30 18:00:56 <vkrishn> hi, I have kinda made better reprentation of the gitflow I mentioned earlier
2020-03-30 18:00:59 <vkrishn> https://gist.github.com/insteps/7bd63123e195b40b23044596d4e4eced
2020-03-30 18:01:08 <vkrishn> pls see attached image
2020-03-30 18:01:36 <vkrishn> I am open to suggestions
2020-03-30 18:03:51 <Cogitri> That graph is very confusing to me somehow
2020-03-30 18:04:04 <Cogitri> A proper flowchart would probably be easier to read
2020-03-30 18:04:57 <vkrishn> ok, will think of it in next version
2020-03-30 18:40:04 <Hello71> jesus christ my eyes
2020-03-30 19:25:10 <zfoo> running 'apk update' I'm currently seeing error when it tries to download the APKINDEX tarballs, error is 'temporary error'
2020-03-30 20:37:14 <mps> hmm, busybox doesn't have -printf which is needed for kernel 5.6 'find: unrecognized: -printf'
2020-03-30 20:37:42 <mps> option is to add coreutils to makedepends
2020-03-30 20:38:13 <mps> though kernel builds even with busybox
2020-03-30 20:39:24 <c705> mps: ugh, coreutils just for -printf?
2020-03-30 20:39:37 <c705> its like smacking a nail in with a sledgehammer
2020-03-30 20:39:49 <mps> right :)
2020-03-30 20:40:19 <mps> but, coreutils is not much bigger than busybox
2020-03-30 20:41:13 <mps> but coreutils doesn't contain find, heh
2020-03-30 20:41:54 <mps> findutils apk
2020-03-30 20:43:08 <mps> btw, does this version looks ok inux-stable-5.6-r0.apk? kernel is 5.6 (two numbers)
2020-03-30 20:43:33 <Cogitri> Seems good to me
2020-03-30 20:44:35 <mps> next version will be linux-stable-5.6.1-r0.apk
2020-03-30 20:44:54 <mps> yes, I think so also
2020-03-30 21:07:18 <c705> mps: cool! so linux-stable is coming to apks?
2020-03-30 21:07:46 <mps> yes, I'm testing it
2020-03-30 21:08:26 <mps> for now only x86_64 and armv7 (and aarch64 is there but didn't tested it much)
2020-03-30 21:09:34 <c705> cool! when can I expect that to be availiable? i'll start building my kernel with it so I can do further qa
2020-03-30 21:09:54 <mps> of the arm64 hardware I only have chromebook
2020-03-30 21:11:08 <mps> well, I depends how it will work on tests, though I run 5.5.13 on x86_64 without problem
2020-03-30 21:11:08 <c705> sorry, i meant x64
2020-03-30 21:12:10 <mps> and 5.6 built today for aarch64, works fine (except drivers I reported bug upstream but didn't fixed yet)
2020-03-30 21:12:38 <mps> in a few days I hope I will push it in aports
2020-03-30 21:13:29 <c705> oh boy oh boy
2020-03-30 21:13:41 <c705> bless you for all the free work you do. I hope to get more involved
2020-03-30 21:14:12 <mps> well, would be appreciated
2020-03-30 21:14:54 <mps> first versions will need help with drivers which should/must be enabled
2020-03-30 21:15:46 <mps> and probably will have some bugs in configs
2020-03-30 21:15:58 <c705> how do you do your kernel tests? build an iso and boot via qemu or something?
2020-03-30 21:16:24 <mps> but I hope with help of users and devs it will be polished
2020-03-30 21:16:35 <mps> real install on real boxes
2020-03-30 21:17:04 <c705> i see. my use case for alpine is run live always. I don't install
2020-03-30 21:17:05 <mps> want to see how it works on real hardware
2020-03-30 21:17:38 <Hello71> need for -printf seems questionable in the first place
2020-03-30 21:17:46 <Hello71> seems like it could be done with a subshell and cd
2020-03-30 21:18:00 <mps> uhm, ' main/xorg-server: make Xorg setuid | http://dup.pw/aports/def122fb'
2020-03-30 21:18:40 <mps> Hello71: I wouldn't patch linux Makefile for this
2020-03-30 21:19:07 <Hello71> patch upstream?
2020-03-30 21:19:32 <Hello71> if you ignore it then you can't run bpf
2020-03-30 21:19:54 <Hello71> well I guess with standard linux you can just install kernel headers separately
2020-03-30 21:20:36 <mps> bpf?
2020-03-30 21:21:16 <Hello71> ebpf i mean
2020-03-30 21:21:44 <mps> ah, thing I disabled for linux-stable :)
2020-03-30 21:28:06 <mps> c705: linux-stable-5.6 works on armv7
2020-03-30 21:28:26 <mps> no more renameat2 problem :)
2020-03-30 21:28:34 <mps> \o/
2020-03-30 21:29:41 <mps> hm, to early :(
2020-03-30 21:33:10 <c705> ):
2020-03-30 22:39:10 <zfoo> apk update is currently giving me this error: ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.11/main: temporary error
2020-03-30 22:58:25 <c705> zfoo: try a different mirror?
2020-03-30 23:02:28 <zfoo> c705: tried a few and all give me the same error
2020-03-31 04:32:54 <_ikke_> zfoo: that's a dns issue
2020-03-31 04:33:08 <_ikke_> Check your nameservers
2020-03-31 05:47:26 <ncopa> maxice8: fyi, i fixed the gnu screen patch: 9579edd780321f85280a40a215548b1483c49b61
2020-03-31 06:26:45 <Cogitri> ncopa: Do you have an opinion about keeping Rust updated in stable releases?
2020-03-31 06:26:59 <Cogitri> Because if we don't want to do that I'll probably have to move FF back to testing
2020-03-31 07:08:20 <russkel> hi all, hope you're all keeping well
2020-03-31 07:09:04 <russkel> is the issue with ppc64le CI instance not updating their packages in a timely manner known?
2020-03-31 07:09:43 <russkel> !3000 is failing because of proj-7.0.0-r0, r1 was merged days ago
2020-03-31 07:10:32 <russkel> armv7 was also the same, but it got back in line a couple of hours ago
2020-03-31 07:11:05 <_ikke_> russkel: no, there is nothing known about that
2020-03-31 07:11:26 <_ikke_> russkel: But if the s390x builder is stuck, the package might not have been built yet
2020-03-31 07:11:35 <russkel> then I am bringing it to the attention to the right people
2020-03-31 07:11:47 <russkel> please refresh and see that check failed
2020-03-31 07:12:04 <_ikke_> https://pkgs.alpinelinux.org/packages?name=proj&branch=edge
2020-03-31 07:12:11 <_ikke_> ppc64le is still on r0
2020-03-31 07:12:27 <russkel> now why is that
2020-03-31 07:12:34 <_ikke_> ppc64le builder is stuck on firefox-esr right now
2020-03-31 07:12:39 <russkel> ahhhhh
2020-03-31 07:13:53 <russkel> the builder getting stuck is a common occurrence ?
2020-03-31 07:13:57 <_ikke_> yes
2020-03-31 07:14:15 <_ikke_> build failures happen commonly due to some reason or another
2020-03-31 07:15:22 <_ikke_> maxice8: firefox-esr fails on ppc64le because llvm-objdump is not found
2020-03-31 07:22:53 <Cogitri> Ah, that's on me
2020-03-31 07:22:53 <Cogitri> Apparently it depends on llvm9-dev
2020-03-31 07:22:59 <Cogitri> When it should depend on llvm-dev
2020-03-31 07:23:31 <_ikke_> Heh, i was doubting between tagging your and maxice8
2020-03-31 07:25:12 <Cogitri> Hehe ^^
2020-03-31 07:25:32 <Cogitri> I can push a fix in half an hour if you don't beat me to it
2020-03-31 07:25:41 <russkel> knew it was Cogitri holding things up /me sighs
2020-03-31 07:25:45 <russkel> ;)
2020-03-31 07:26:23 <_ikke_> Cogitri: I have no time to look into it myself
2020-03-31 07:37:42 <Cogitri> Okie, I'll change it in a bit then
2020-03-31 07:37:47 <Cogitri> russkel: of course :P
2020-03-31 07:37:50 <Bridouz> o/
2020-03-31 07:38:52 <Bridouz> I have a question regarding packaging. I'm trying to build MuseScore for Alpine. All seems right except that build fails saying : "ERROR: musescore*: Packages must not put anything under /srv, /usr/local or /opt"
2020-03-31 07:39:08 <Bridouz> And I do not know how to override it to righteous locations.
2020-03-31 07:41:23 <Bridouz> Does "make DESTDIR="$pkgdir" PREFIX=/usr install" does the trick ?
2020-03-31 07:42:03 <_ikke_> Bridouz: should work in most cases
2020-03-31 07:42:13 <_ikke_> is there a configure script?
2020-03-31 07:44:05 <Bridouz> no configure script, cmake is used here
2020-03-31 07:44:39 <Bridouz> I restarted the build and added "PREFIX=/usr", will see how it goes
2020-03-31 07:45:13 <_ikke_> Bridouz: DESTDIR usually is only necessary for make install btw
2020-03-31 07:48:07 <mps> why do we need this def122fb74fd9bb24179efe4d463c3c460e882a8
2020-03-31 07:48:47 <mps> isn't this security risk
2020-03-31 07:49:57 <Cogitri> No
2020-03-31 07:50:10 <Cogitri> Or rather yes, but it's required
2020-03-31 07:50:15 <Cogitri> You can choose between making Xorg suid or pulling in elogind
2020-03-31 07:50:51 <Cogitri> And even before that changes Xorg was SUID in -r3, it was stripped by accident in -r4
2020-03-31 07:50:59 <Cogitri> s/changes/change/
2020-03-31 07:50:59 <alpine-meetbot> Cogitri meant to say: And even before that change Xorg was SUID in -r3, it was stripped by accident in -r4
2020-03-31 07:51:54 <mps> isn't enough chgrp Xorg to input
2020-03-31 08:04:35 <Cogitri> https://wiki.gentoo.org/wiki/Non_root_Xorg not really
2020-03-31 08:04:40 <Cogitri> And doing non setuid means every user needs to be in the right groups
2020-03-31 08:04:59 <Cogitri> And if they are they have additional permissions they can snoop on other users
2020-03-31 08:06:49 <Cogitri> So if you don't want SUID using elogind is your best choice
2020-03-31 08:11:13 <mps> user need to be in input group anyway
2020-03-31 08:41:45 <Bridouz> OK, build failed again. I explored the MakeFile and it appears that PREFIX is set to /usr/local.
2020-03-31 08:42:48 <Bridouz> So, with my merely acceptable linux knowledge I assume that `make PREFIX=/usr install` is the right thing to do but I also have to add `make PREFIX=/usr` in build()
2020-03-31 08:46:29 <Cogitri> It's PREFIX="$pkgdir"/in
2020-03-31 08:47:40 <_ikke_> huh?
2020-03-31 08:50:18 <Bridouz> make PREFIX=/usr
2020-03-31 08:50:22 <Bridouz> then make DESTDIR="$pkgdir" PREFIX=/usr install
2020-03-31 08:50:25 <Bridouz> no ?
2020-03-31 08:50:34 <_ikke_> That sounds right
2020-03-31 08:50:57 <Cogitri> Oh yes, if your makefile supports destdir then that'd be right
2020-03-31 08:51:07 <Bridouz> Build restarted, see you in ~45mn
2020-03-31 08:51:08 <mps> if makefile have DESTDIR var
2020-03-31 08:51:11 <Cogitri> (Sorry, I'm used to mediocre makefiles which don't support it)
2020-03-31 08:51:25 <Cogitri> 
ACTION looks at apk-tools :/ 

2020-03-31 08:51:38 <_ikke_> But why would PREFIX="$pkdir/in" make sense?
2020-03-31 08:51:53 <Cogitri> That should've been PREFIX="$pkgdir/usr", sorry
2020-03-31 08:51:59 <_ikke_> aha
2020-03-31 08:52:04 <Bridouz> So if the musescore makefile does not have a DESTDIR variable I must not put int in APKGBUILD ?
2020-03-31 08:52:30 <Cogitri> It's not that you must not do it, it's just that it might not actually change something if you specify it
2020-03-31 08:52:35 <Cogitri> But it'd be best to just try it :)
2020-03-31 08:53:17 <Bridouz> ok, thanks. So make PREFIX=/usr then make DESTDIR="$pkgdir" PREFIX=/usr should work ?
2020-03-31 08:53:18 <_ikke_> Bridouz: protip
2020-03-31 08:53:27 <_ikke_> use abuild -rK to keep the source files
2020-03-31 08:53:43 <_ikke_> and use abuild package to redo only the package stage
2020-03-31 08:53:51 <mps> if it doesn't have DESTDIR it is useless to put it but will not be problem
2020-03-31 08:54:38 <mps> does the package have configure script
2020-03-31 08:55:27 <_ikke_> mps: Already asked that :)
2020-03-31 08:55:54 <mps> ah, ok. (waiter, please another coffee :) )
2020-03-31 08:56:22 <mps> s/waiter/waitress/
2020-03-31 08:56:22 <alpine-meetbot> mps meant to say: ah, ok. (waitress, please another coffee :) )
2020-03-31 08:56:47 <Bridouz> https://github.com/musescore/MuseScore
2020-03-31 08:56:55 <Bridouz> no configuration file, only cmakelist
2020-03-31 08:58:50 <mps> ah, it uses cmake
2020-03-31 08:58:55 <_ikke_> DESTDIR is not used in the Makefile
2020-03-31 08:59:13 <mps> yes, PREFIX should be enough
2020-03-31 09:00:03 <_ikke_> It looks like the makefile assumes it's installed on the target
2020-03-31 09:00:20 <_ikke_> Bridouz: maybe specify UPDATE_CACHE=false
2020-03-31 09:00:30 <_ikke_> https://github.com/musescore/MuseScore/blob/master/Makefile#L45
2020-03-31 09:01:47 <Bridouz> Ok, added and build restarted
2020-03-31 09:05:31 <_ikke_> The Makefile apparently is just a frontend to cmake
2020-03-31 09:06:40 <Bridouz> Yes that's what I understood
2020-03-31 09:08:39 <_ikke_> Setting PREFIX to $pkgdir/usr should work then
2020-03-31 09:48:03 <ncopa> re eBPF: https://seclists.org/oss-sec/2020/q1/127
2020-03-31 09:52:35 <mps> heh :)
2020-03-31 09:53:02 <mps> some thing repeating and repeating ....
2020-03-31 09:53:09 <mps> things*
2020-03-31 09:54:26 <ncopa> which is why i was skeptic to enablel eBPF
2020-03-31 09:55:01 <mps> I'm preparing linux-stable package without it
2020-03-31 09:55:49 <mps> and wanted to add '# !!! do not enable *BPF' in comment
2020-03-31 09:56:14 <mps> btw, APKBUILD for kernel have issue
2020-03-31 09:57:07 <mps> doesn't create correct apk if pkgver is x.x (two numbers), x.x.x works fine
2020-03-31 09:58:36 <ncopa> i guess you can use 5.6.0?
2020-03-31 09:58:37 <mps> doesn't set _abi_release correctly in _package()
2020-03-31 09:58:37 <russkel> thanks Cogitri I pushed a new APKBUILD
2020-03-31 09:58:52 <russkel> why did I think MIT license had MIT written in the LICENSE file?
2020-03-31 09:58:56 <mps> ncopa: yes, I think so
2020-03-31 09:59:51 <mps> but have to 'play' with 'source' field, with 'case $pkgver in ...'
2020-03-31 10:03:07 <mps> btw, I have a bug with apk on armv7 arch with kernel 5.6 and 5.6-rc, it stuck at renameat2 syscall
2020-03-31 10:03:36 <mps> on aarch64 and x86_64 with kernel 5.6 it works fine
2020-03-31 10:03:54 <ncopa> what filesystem?
2020-03-31 10:04:12 <mps> f2fs and ext4
2020-03-31 10:06:59 <mps> but I think it is not related to FS, everything else works fine, untar linux kernel does works fine, while apk add tmux-doc stuck apk to death
2020-03-31 10:10:53 <Ariadne> ncopa: yes, but you have to explicitly take steps to enable eBPF on alpine.
2020-03-31 10:14:55 <Ariadne> 
ACTION patiently waits for somebody to use this 'linux-stable' package and complain their eBPF does not work

2020-03-31 10:19:56 <AinNero> oh, an ePBF CVE
2020-03-31 10:19:58 <AinNero> was about time
2020-03-31 10:20:05 <AinNero> * eBPF
2020-03-31 10:20:32 <Ariadne> i'm not particularly in favor of having kernels that omit features other kernels have in the repos
2020-03-31 10:22:41 <AinNero> if you have to maintain infrastructure, you start judging software by its reliability and stability, not its features and blink
2020-03-31 10:23:36 <Ariadne> cool
2020-03-31 10:24:19 <Ariadne> you also judge software by it's suitability for purpose
2020-03-31 10:24:25 <ncopa> yeah, i think disabled by default is the way to go
2020-03-31 10:24:51 <Ariadne> and 'linux-stable' isn't even a good name for this package
2020-03-31 10:25:09 <ncopa> still, it makes me uncomfortable. not sure we can do anything about it more than keep it disabled by default
2020-03-31 10:25:48 <Ariadne> well, it is like giving a person any kind of giant weapon
2020-03-31 10:25:58 <Ariadne> you have to hope they don't shoot themselves in the foot
2020-03-31 10:26:45 <Ariadne> reality is, to use eBPF programs you have to have access to the machine already (unless some person has enabled unprivileged BPF, in which case, welp, good luck)
2020-03-31 10:27:32 <Ariadne> so in most cases, the answer to "running rootkit.bpf roots my machine" is "don't run rootkit.bpf"
2020-03-31 10:36:14 <ncopa> mps: im not sure a linux-stable kernel is a good idea
2020-03-31 10:38:34 <Ariadne> we already have a mess of configs to keep consistent
2020-03-31 10:38:50 <Ariadne> the only reason i added a kernel specifically for octeon is because octeon stuff boots on a damn hypervisor thing
2020-03-31 10:39:16 <Ariadne> we also have third-party modules to deal with
2020-03-31 10:48:28 <mps> ncopa: ask its godfather ( _ikke_ ) :)
2020-03-31 10:49:31 <_ikke_> :D
2020-03-31 10:49:38 <mps> and look here, https://www.kernel.org/ latest stable kernels is named 'stable'
2020-03-31 10:49:47 <mps> are*
2020-03-31 10:49:53 <_ikke_> mps: I think ncopa is talking about the package itself, not the name
2020-03-31 10:49:55 <Ariadne> mps: well either way, the configs need to be consistent with LTS.
2020-03-31 10:50:07 <ncopa> both
2020-03-31 10:50:09 <_ikke_> ok
2020-03-31 10:50:30 <_ikke_> Ariadne: agree, changing to a newer kernel should not lead to losing functionality
2020-03-31 10:50:31 <mps> I named it linux-edge initially
2020-03-31 10:50:37 <ncopa> and i think its good if config consistent with linux-lts
2020-03-31 10:51:07 <mps> no, it will not be good
2020-03-31 10:51:08 <Ariadne> mps: i think that fits better with our own branch scheme
2020-03-31 10:51:14 <ncopa> it is already a challenge to keep the current -lts configs consistent across the arches
2020-03-31 10:51:58 <mps> I plan to keep it only in testing, and as such it will be, well testing kernel
2020-03-31 10:52:00 <ncopa> the problem with linux-stable name is that it may confuse users "i want whatever that is stable for my production. not this 'lts' whatever that is"
2020-03-31 10:52:35 <ncopa> i planned to keep the firefox package in testing only and firefox-esr for stable releases
2020-03-31 10:52:41 <mps> whatever name is selected it will be confusing to some
2020-03-31 10:52:46 <ncopa> that was the plan. now firefox is in community
2020-03-31 10:52:46 <Ariadne> mps: yes, but testing something that is not consistent with what LTS has enabled (you could enable more or disable *deprecated* features) is not useful
2020-03-31 10:53:27 <mps> and I few time raised question to move FF back to testing
2020-03-31 10:54:12 <Ariadne> let us use eBPF as an example, you dislike it, but users may wish to test new eBPF functionality available in new kernel.  if they install this proposed kernel, they will lose the eBPF functionality they already are using because you dislike eBPF.
2020-03-31 10:54:12 <ncopa> right. so i am afraid that we will end up spending time debating if 'linux-stable' should move to community or main in the future
2020-03-31 10:54:40 <mps> well, we should give maintainers 'veto' rights
2020-03-31 10:55:14 <mps> or, at the end to BDFL, if big conflicts appears
2020-03-31 10:55:17 <Ariadne> we should, but we also reserve the right to veto maintenance from maintainers who do not wish to play nice
2020-03-31 10:55:19 <ncopa> we may still end up need spend time on it
2020-03-31 10:55:50 <ncopa> so, in general, i don't mind that you maintain your own kernel, as long as it does not drain resources from the rest of us
2020-03-31 10:55:53 <mps> let me explain a little
2020-03-31 10:56:48 <ncopa> ok?
2020-03-31 10:56:55 <mps> I'm working on it because some people on #alpine-linux asked me to make it, not because I think it must be in aports
2020-03-31 10:57:32 <mps> and because these people are not satisfied with our default kernels
2020-03-31 10:57:50 <Ariadne> well, obviously, you can distribute whatever kernel packages you wish in whatever third-party repo you want
2020-03-31 10:58:09 <mps> and, after they asked I thought that is ok to create it and push
2020-03-31 10:58:39 <Ariadne> it's okay as long as it is consistent with what we are already shipping
2020-03-31 10:58:53 <mps> not because *I want* it in repos
2020-03-31 10:58:58 <Ariadne> if it is going to be in alpine repos
2020-03-31 10:59:03 <ncopa> in general, i dont mind that. we should just be aware of the consequences
2020-03-31 10:59:24 <ncopa> what i wonder now is, why are they not happy with the default kernels we provide?
2020-03-31 10:59:32 <Ariadne> but the reality is, people are going to see this kernel as part of kernel maintenance pipeline
2020-03-31 10:59:37 <ncopa> if those are broken, we should maybe fix those
2020-03-31 10:59:53 <mps> I think gnome/kde shouldn't be in repos, but I never told or asked for removal or anything about them
2020-03-31 11:00:12 <Ariadne> gnome/kde aren't the kernel
2020-03-31 11:00:26 <ncopa> there will always be users who have special requests or wants somethign special
2020-03-31 11:00:40 <ncopa> and some will also add patches to add their needs
2020-03-31 11:00:47 <ncopa> but then they want us to maintain it
2020-03-31 11:01:02 <ncopa> this is where it causes consequences for us
2020-03-31 11:01:16 <mps> yes, look testing/linux-amlogic
2020-03-31 11:01:30 <Ariadne> for example, the mips64 builder runs on a vendor-supplied kernel because octeon3 drivers are not fully upstreamed
2020-03-31 11:01:39 <Ariadne> i maintain that package out of tree :p
2020-03-31 11:01:40 <ncopa> im not saying we shouldnt do it. im saying we should be careful and think of the consequences before we do it
2020-03-31 11:02:22 <ncopa> and if we decide to actually add it, then we should try do it in a way to minimize maintenence burden
2020-03-31 11:02:25 <ncopa> and support
2020-03-31 11:02:49 <Ariadne> i predict that users are going to be users with any kernel package
2020-03-31 11:03:00 <mps> as I understand we don't have any promise for packages in testing
2020-03-31 11:03:10 <Ariadne> they are going to install it and complain when it is missing some feature be it third-party or just not enabled because the maintainer disagrees with it
2020-03-31 11:03:42 <ncopa> mps: correct, but people dont always get that. and we relatively often get bug reports due to people mixing edge/testing with stable stuff
2020-03-31 11:03:48 <ncopa> that hey have ran for years
2020-03-31 11:03:52 <ncopa> and suddently things break
2020-03-31 11:03:56 <ncopa> and wants us to fix it
2020-03-31 11:04:04 <mps> and, I thought to make it somewhere on the net and not in alpine
2020-03-31 11:04:20 <ncopa> that would be perfectly fine
2020-03-31 11:04:32 <ncopa> if you provide that in 3rd party repos
2020-03-31 11:04:46 <mps> but people asks and asks. I don't know what is better idea
2020-03-31 11:05:00 <ncopa> what are they asking for?
2020-03-31 11:05:05 <ncopa> kernel without eBPF?
2020-03-31 11:05:15 <mps> they ask for new kernels
2020-03-31 11:05:15 <ncopa> or 5.6 kernel with wireguard?
2020-03-31 11:05:17 <ncopa> yeah
2020-03-31 11:05:30 <mps> new features
2020-03-31 11:05:48 <Ariadne> yes, and that part is fine.  the problem is removing features that are disagreed with
2020-03-31 11:05:51 <mps> not eBPF :)
2020-03-31 11:06:06 <Ariadne> if it is going to be 'official', then it needs to add to what is already there, not remove
2020-03-31 11:06:14 <ncopa> i think it would be nice if we could provide a testing kernel
2020-03-31 11:06:20 <mps> most alpine users don't want eBPF
2020-03-31 11:06:24 <ncopa> we jsut need to be smart on how we do it
2020-03-31 11:06:59 <Ariadne> mps: i think that most alpine users don't have any direct usecase for eBPF
2020-03-31 11:07:15 <ncopa> i think we could add testing/linux-testing or testing/linux-mainline or similar, but it woudl be nice if we could reduce number of supported arches
2020-03-31 11:07:19 <Ariadne> mps: *but* i do not think most alpine users want or explicitly don't want eBPF.  reality is most do not care.
2020-03-31 11:07:32 <ncopa> and i think we should be consistent with the -lts config as much as possible
2020-03-31 11:07:50 <mps> though I think alpine users who needs new features should build kernels thmeselves
2020-03-31 11:08:29 <mps> ok, I will step back on this
2020-03-31 11:08:35 <ncopa> that is the current official point of view yes. however we decided some time ago that ebpf was ok to bring in to the -lts kernel
2020-03-31 11:08:52 <ncopa> so now we have to support it...
2020-03-31 11:09:14 <Ariadne> (in a default disabled state.  you have to adjust sysctl.conf and reboot to get eBPF)
2020-03-31 11:09:55 <Ariadne> which is the only thing i am personally comfortable with providing in alpine anyway
2020-03-31 11:12:27 <Ariadne> i wish OpenBLAS could be built without assembly instructions :(
2020-03-31 11:12:51 <Ariadne> mips64 is soft-float because octeon1/octeon2 have a buggy FPU and loongson, well, LOL
2020-03-31 11:12:55 <ncopa> i wish crystal built with llvm10 on aarch64....
2020-03-31 11:13:16 <Ariadne> i guess we will have to give up on crystal on aarch64
2020-03-31 11:13:28 <Ariadne> i don't like these "new" programming languages
2020-03-31 11:13:47 <Ariadne> they have this "just cross-compile your code on your x86_64 box and pray" mentality
2020-03-31 11:15:07 <ncopa> mps: re 29c6464be19088283c52dd74e90bbbd4f9829a6c
2020-03-31 11:15:46 <ncopa> it introduces this patch fix-spec-std-kernel-spec.cr.patch
2020-03-31 11:15:58 <ncopa> and it does not apply to crystal 0.33.0
2020-03-31 11:15:58 <Ariadne> "oh well, your code passes tests on x86_64, so it's fine on aarch64"
2020-03-31 11:16:16 <ncopa> what was the patch about?
2020-03-31 11:17:18 <mps> ncopa: this is only to skip test which not work, confirmed upstream
2020-03-31 11:17:34 <ncopa> aha! ok. thanks
2020-03-31 11:17:49 <Ariadne> yeah
2020-03-31 11:17:53 <Ariadne> pending keyword makes it skip
2020-03-31 11:18:13 <Ariadne> same as @skip_test in elixir
2020-03-31 11:18:21 <Ariadne> or whatever it is
2020-03-31 11:18:25 <mps> there is MR for crystal 0.32.1 which should be first to build, and snapshot to use for build 0.33.0
2020-03-31 11:19:22 <mps> I think i have 0.32.1 static tarball locally, will look when I come back to home
2020-03-31 11:19:40 <ncopa> i uploaded 0.32.0 for aarch64
2020-03-31 11:20:19 <ncopa> and i am testing building 0.33.0 with llvm 10 with the crystal 0.32.0 binary
2020-03-31 11:20:22 <mps> does it build and pass check?
2020-03-31 11:20:33 <ncopa> dont know yet
2020-03-31 11:20:37 <ncopa> it is still building
2020-03-31 11:20:42 <mps> ah
2020-03-31 11:20:49 <ncopa> i build 0.32.0 with llvm5
2020-03-31 11:21:22 <Cogitri> Oof
2020-03-31 11:21:23 <mps> 0.32.1 builds on aarch64 but it is useles, crashes on simple programs
2020-03-31 11:21:40 <Ariadne> that's like GDC on MIPS64
2020-03-31 11:22:11 <Ariadne> but i should have a fix for that soon
2020-03-31 11:22:26 <mps> upstream told they are not support aarch64 for now
2020-03-31 11:23:24 <Ariadne> anything we can do to change that situation ?
2020-03-31 11:23:42 <mps> disable aarch64
2020-03-31 11:23:58 <Ariadne> i meant to get them to fix it
2020-03-31 11:24:19 <mps> we tried, but without luck
2020-03-31 11:28:10 <mps> ncopa: I have crystal-0.32.1-x86_64-alpine-linux-musl.tar.gz which is needed for building 0.33.0
2020-03-31 11:28:51 <mps> I can put it in my usa4 lxc if you want to use it for 0.33.0
2020-03-31 11:28:52 <zfoo> _ikke_: thanks, was able to resolve the issue
2020-03-31 11:29:30 <mps> ncopa: also there is !4237
2020-03-31 11:38:07 <ncopa> ok, 0.33.0 fails with same error as before
2020-03-31 11:38:16 <ncopa> when buildt with llvm10
2020-03-31 13:32:07 <maxice8> @ncopa the screen patch wasn't applying before ?
2020-03-31 13:33:02 <ncopa> correct. and the patch needed tiny edit since the patched file had moved
2020-03-31 13:33:11 <ncopa> but its all good now i think
2020-03-31 13:33:23 <ncopa> we help each other ;)
2020-03-31 13:33:27 <maxice8> I see
2020-03-31 13:33:30 <maxice8> need to bump the pkgrel
2020-03-31 13:33:34 <maxice8> so it is built with the patch applied then
2020-03-31 13:33:49 <ncopa> no, the build failed
2020-03-31 13:33:57 <maxice8> it failed ? for me it silently didn't apply
2020-03-31 13:34:03 <maxice8> with my modern abuild
2020-03-31 13:34:23 <ncopa> it failed loud and clear
2020-03-31 13:34:28 <ncopa> on the builders, and in my dev env
2020-03-31 13:34:38 <ncopa> try revert it and see what happens
2020-03-31 13:34:48 <maxice8> i am trying on 3.11 which is a backport of that and it succeeds
2020-03-31 13:35:20 <ncopa> $ abuild -r 2>&1 | tpaste
2020-03-31 13:35:20 <ncopa> http://tpaste.us/DDQO
2020-03-31 13:36:13 <ncopa> and even if i try apply that patch:
2020-03-31 13:36:59 <maxice8> huh
2020-03-31 13:37:09 <maxice8> i must have a good distfile stored then because i didn't hit that
2020-03-31 13:37:15 <maxice8> i did hit the failure to apply because the src/ dir doesn't exist
2020-03-31 13:38:04 <ncopa> $ curl --silent https://git.savannah.gnu.org/cgit/screen.git/patch/?id=68386dfb1fa33471372a8cd2e74686758a2f527b | patch -p1 2>&1 | tpaste
2020-03-31 13:38:04 <ncopa> http://tpaste.us/b4lZ
2020-03-31 13:38:27 <maxice8> yes that is the error i hit when i added CVE-2020-9366:: to the URL
2020-03-31 13:38:45 <ncopa> i manually edited the patch
2020-03-31 13:38:51 <maxice8> i know
2020-03-31 13:39:04 <ncopa> anyway, its all good now i think
2020-03-31 13:39:35 <ncopa> i fixed it because the builders failed
2020-03-31 13:39:52 <ncopa> 3.9 and 3.8 are good though
2020-03-31 13:40:04 <maxice8> thanks
2020-03-31 13:40:35 <ncopa> as i said, we help each other, to thanks to you too :)
2020-03-31 13:41:37 <maxice8> btw, do we support other security issues besides CVE ?
2020-03-31 13:41:54 <maxice8> gnutls has GNUTLS-SA- and Xen has XSA-
2020-03-31 13:42:37 <maxice8> i'm upgrading gnutls to 3.6.13 and they have GNUTLS-SA-2020-03-31 (their security advisory) which doesn't have an equivalent CVE yet
2020-03-31 13:42:50 <maxice8> if people google that they will most likely land somewhere around here https://gnutls.org/security-new.html#GNUTLS-SA-2020-03-31
2020-03-31 14:28:16 <mps> Cogitri: ls -l /usr/bin/Xorg => -rwxr-xr-x 1 root root 2056520 Mar 30 00:53 /usr/bin/Xorg
2020-03-31 14:28:23 <mps> and it works fine
2020-03-31 14:38:00 <ncopa> maxice8: it is a good question. we should find a solution for it
2020-03-31 14:46:59 <Cogitri> mps: Yes, what groups are you in though?
2020-03-31 14:47:07 <Cogitri> You probably need way more permissions for your users now
2020-03-31 14:47:23 <Cogitri> Which might not be what you want either
2020-03-31 14:48:27 <mps> groups=1000(mps),18(audio),23(input),27(video),28(netdev),34(kvm),300(abuild)
2020-03-31 14:58:52 <Hello71> what about elogind
2020-03-31 15:01:47 <Cogitri> Elogind would be the best way to avoid setuid, but I doubt many would approve adding that dependency for xorg :P
2020-03-31 15:11:30 <maxice8> @ncopa i mean, it is not a matter if the system supports it, it can be made to support it
2020-03-31 15:11:50 <maxice8> the question is, do we want to write out other security identifiers besides CVE, like TALOS-, XSA (for xen), GNUTLS-SA, etc ?
2020-03-31 15:12:03 <maxice8> or should we wait for a CVE for those ?
2020-03-31 15:12:12 <maxice8> i need that answer so i can adapt secfixes-check from atools accordingly
2020-03-31 15:13:10 <ncopa> ok. will think about it a bit
2020-03-31 15:13:21 <ncopa> th eproblem is that not everyone uses CVE
2020-03-31 15:13:30 <ncopa> they may have their own security issue id
2020-03-31 15:13:44 <ncopa> and the sec id may correspond to a CVE
2020-03-31 15:13:54 <ncopa> or CVE may be missing
2020-03-31 15:14:37 <ncopa> the way i did with xen and XSA was that i specified both CVE and XSA on same line where they described the same issue
2020-03-31 15:15:01 <Hello71> Cogitri: imo if you're installing x you already don't have a "minimal system"
2020-03-31 15:15:30 <Hello71> and if you absolutely insist then you can chmod +s or add groups yourself
2020-03-31 15:15:55 <Cogitri> The chmod +s wouldn't strip the elogind dep though
2020-03-31 15:16:02 <Cogitri> A xorg-server-elogind might be a good idea though
2020-03-31 15:18:40 <maxice8> @ncopa i think listed CVE plus the primary security advisory of the project like XSA should be enough
2020-03-31 15:19:02 <maxice8> would be nice to have written it down somewhere for people looking at the secdb
2020-03-31 15:19:33 <maxice8> There is also the issue that some security advisories that are not CVE might refer to multiple i know one GNUTLS-SA that has 2 CVEs assigned to it
2020-03-31 15:20:34 <maxice8> https://gnutls.org/security-new.html#GNUTLS-SA-2020-03-31 scroll down to GNUTLS-SA-2017-03-25, it has 3 CVEs relevant to it
2020-03-31 15:22:31 <Hello71> Cogitri: isn't that just regular xorg-server except without -s
2020-03-31 15:22:41 <Hello71> s/-/+/
2020-03-31 15:22:41 <alpine-meetbot> Hello71 meant to say: Cogitri: isn't that just regular xorg+server except without -s
2020-03-31 15:22:54 <Hello71> wait, no, it has to actually be linked
2020-03-31 15:23:20 <Hello71> for some reason I thought it was a runtime only dependency
2020-03-31 15:23:26 <Cogitri> Nop
2020-03-31 15:58:48 <maxice8> !6085
2020-03-31 17:42:06 <oneinsect> hola folks is there a way (any option) i could for install a package even though it breaks
2020-03-31 17:42:12 <oneinsect> force*
2020-03-31 17:42:40 <oneinsect> like apk -force add alpine-baselayout
2020-03-31 17:46:03 <maxice8> @ncopa https://gitlab.alpinelinux.org/Leo/atools/issues/27#note_78023
2020-03-31 17:47:41 <ncopa> maxice8: will follow up next week
2020-03-31 17:48:02 <maxice8> Alright
2020-03-31 17:49:12 <oneinsect> thanks found it
2020-03-31 17:52:00 <c705> !11344
2020-03-31 17:52:10 <c705> how can i check the contents of my initramfs from the live system
2020-03-31 18:47:43 <_ikke_> bummer, skip_ci doesn't even work for admins :o
2020-03-31 18:51:39 <maxice8> @ncopa thanks
2020-03-31 18:51:42 <maxice8> @ikke: big sad
2020-03-31 18:52:05 <_ikke_> I did notice it's a put request, so maybe you have to specify it in the body?
2020-03-31 18:52:36 <_ikke_> https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/lib/api/merge_requests.rb#L517
2020-03-31 20:30:44 <Cogitri> Does someone happen to know coredumps a bit? I'm a bit clueless why gdb would complain about CRC mismatches like here: https://gitlab.com/postmarketOS/pmaports/-/issues/536#note_315062216
2020-03-31 20:31:03 <Cogitri> Since we built the dbg package and the non dbg package in one go
2020-03-31 21:11:16 <_ikke_> maxice8: build failure for mkmr :)
2020-03-31 21:11:29 <_ikke_> patch that doesn't apply
2020-03-31 21:12:59 <maxice8> Oof
2020-03-31 21:13:08 <maxice8> Am playing cards with family
2020-03-31 21:14:22 <_ikke_> Is it just a matter of removing the patch?
2020-03-31 21:14:46 <_ikke_> ok, doing PUT with '{"skip_ci": true}' does not work either
2020-03-31 21:17:02 <maxice8> Yes
2020-03-31 21:17:12 <maxice8> I frequently backport fixes from mkmr upstream
2020-03-31 21:18:21 <_ikke_> nod
2020-03-31 22:15:50 <Hello71> Cogitri: usually it means you did not ;)