2019-12-01 00:01:16 <clandmeter> woot
2019-12-01 00:31:59 <clandmeter> _ikke_: any problem with https://tpaste.us/XgKl and moving it to community?
2019-12-01 02:11:22 <sh4rm4^bnc> can someone fix the greedy permission gitlab app want from gitlab oauth users ?
2019-12-01 02:11:48 <sh4rm4^bnc> the app owner seems to be https://gitlab.com/kdaudt
2019-12-01 02:19:07 <sh4rm4^bnc> the only thing it really needs permission for, is checking the user profile, but not the ability to delete or modify my repos...
2019-12-01 04:06:18 <russkel> 
ACTION prod

2019-12-01 04:06:26 <russkel> can I get a final review on this please https://github.com/alpinelinux/aports/pull/12044 ?
2019-12-01 08:55:56 <Cogitri> russkel: Ah yes, someone with access to main/ gotta merge that
2019-12-01 08:56:36 <russkel> =)
2019-12-01 08:59:24 <_ikke_> Cogitri: a review is still helpful :-)
2019-12-01 08:59:53 <Cogitri> Yup, I already approved it :P
2019-12-01 09:10:50 <_ikke_> clandmeter: fine with me
2019-12-01 09:11:09 <clandmeter> :)
2019-12-01 09:56:58 <mps> sh4rm4^bnc: oauth, price for commodity :)
2019-12-01 10:56:26 <mps> north1: when you already looking for my MR's :), would you mind to look !1784
2019-12-01 10:56:41 <mps> simple removal of stale patch
2019-12-01 10:58:25 <mps> north1: btw, thanks for ncurses push
2019-12-01 11:37:34 <_ikke_> sh4rm4^bnc: Yes, will be looking into it
2019-12-01 11:56:40 <_ikke_> fyi, I'm restarting gitlab to apply new settingd
2019-12-01 12:03:26 <_ikke_> sh4rm4^bnc: is this better? http://tpaste.us/LYmV
2019-12-01 12:12:12 <mps> hmm, TBK is not active on alpine IRC? want to ask to upgrade redis
2019-12-01 12:12:46 <_ikke_> not that I'm aware of
2019-12-01 12:13:29 <mps> would be nice to have latest stable redis in 3.11
2019-12-01 12:13:47 <_ikke_> make a merge request and tag him I guess :)
2019-12-01 12:13:47 <mps> ok, will make MR and see
2019-12-01 12:13:50 <_ikke_> heh
2019-12-01 12:13:57 <mps> heh ;-
2019-12-01 12:14:05 <mps> )
2019-12-01 12:16:30 <_ikke_> We have the same set of packages failing each time, would be nice if we can make some progress on those
2019-12-01 12:18:15 <mps> _ikke_: I found solution for upx by disabling '-no-pie' test but not sure should I do that
2019-12-01 12:19:03 <mps> i.e. disable this test
2019-12-01 12:19:21 <mps> what is your advice
2019-12-01 12:19:58 <_ikke_> Maybe disable test for now + open an issue somewhere
2019-12-01 12:21:13 <mps> my question (and I'm not sure about answer) who need -no-pie nowadays
2019-12-01 12:21:37 <_ikke_> cannot say anything about that
2019-12-01 12:23:09 <Cogitri> I think people on i386 might want to disable it for a few percents more performance (PIE/PIC have a higher performance impact on 32-bit) but imho disabling it is a terrible idea anyway
2019-12-01 12:28:07 <mps> Cogitri: upx is not built with -no-pie, just test something together with static, '-static -no-pie'
2019-12-01 12:51:31 <Cogitri> Ah
2019-12-01 13:45:00 <mps> _ikke_: !1795 fails with segfault on armv7 CI, I tried on armv7 lxc and it pass build without issue
2019-12-01 13:47:07 <_ikke_> mps: let me check if I can reproduce that on the host
2019-12-01 13:55:42 <_ikke_> mps: building it now in the same container
2019-12-01 13:55:59 <_ikke_> mps: you could even do that yourself
2019-12-01 13:56:15 <_ikke_> if you care to learn the docker commands for that sometime :)
2019-12-01 13:56:31 <_ikke_> mps: I get the segfault at least
2019-12-01 13:56:57 <mps> _ikke_: i wrote that i did and it passes on lxc
2019-12-01 13:57:21 <_ikke_> mps: sorry, I mean docker container
2019-12-01 13:57:25 <_ikke_> the sameone as the CI uses
2019-12-01 13:57:42 <mps> aha, ok
2019-12-01 13:58:22 <_ikke_> hmm, someone just wrote their own checks for upx
2019-12-01 13:58:34 <_ikke_> in the APKBUILD
2019-12-01 13:59:29 <mps> so, it segfaults in docker and not in lxc
2019-12-01 14:00:25 <mps> _ikke_: where is this APKBUILD
2019-12-01 14:00:31 <_ikke_> If I just run ./upxtest, I get "illegal instruction"
2019-12-01 14:00:37 <_ikke_> mps: the one from your merge request
2019-12-01 14:00:55 <_ikke_> I just applied your patch
2019-12-01 14:02:10 <_ikke_> ok, I needed to specify an argument, now I get the segfault
2019-12-01 14:02:58 <_ikke_> ugh, anoying "ptrace not permitted"
2019-12-01 14:05:54 <_ikke_> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2019-12-01 14:06:25 <mps> _ikke_: I run ./upxtest in lxc and got '1,0x1000200030004001'
2019-12-01 14:06:56 <mps> it passed other CI's, only failed on armv7
2019-12-01 14:07:22 <_ikke_> I have no idea why it fails, if you have tips or want me to run / test things, lmk
2019-12-01 14:07:25 <mps> ok, s390x doesn't work
2019-12-01 14:07:48 <_ikke_> yeah, somehow s390x keeps getting stuck on cloning the repo
2019-12-01 14:07:57 <mps> no, I wanted to point you this issue with armv7 CI
2019-12-01 14:08:40 <_ikke_> Somehow this code does not compile properly on armv7 in docker: https://tpaste.us/Z0j9
2019-12-01 14:09:35 <_ikke_> One potential issue could be that we run this on aarch64 in 32 bits mode
2019-12-01 14:11:56 <mps> this compiles fine on lxc armv7, and I think it also runs on arm64 (usa4)
2019-12-01 14:12:09 <_ikke_> right
2019-12-01 14:12:45 <_ikke_> I have no clue
2019-12-01 14:13:01 <_ikke_> mps: what does uname -m return?
2019-12-01 14:13:34 <mps> mps-edge-armv7 4.19.78-1-vanilla #2-Alpine SMP Wed Oct 9 08:29:48 UTC 2019 armv8l Linux
2019-12-01 14:13:46 <_ikke_> ok, armv8l for me as well
2019-12-01 14:14:39 <mps> lscpu => http://tpaste.us/lYyN
2019-12-01 14:14:51 <_ikke_> but it's just some self-created test
2019-12-01 14:20:33 <mps> so, we can remove it?
2019-12-01 14:24:48 <_ikke_> normally we don't define our own tests / checks in check()
2019-12-01 14:38:36 <mps> agree
2019-12-01 14:39:48 <mps> now we know a more about the problem, but wouldn't remove this now, prefer if that do maintainer or ncopa
2019-12-01 14:40:13 <mps> s/but/but I/
2019-12-01 14:40:13 <alpine-meetbot> mps meant to say: now we know a more about the problem, but I wouldn't remove this now, prefer if that do maintainer or ncopa
2019-12-01 16:35:13 <mps> hm, pglogical_compat.h: No such file or directory
2019-12-01 16:37:43 <_ikke_> nothing that provides it
2019-12-01 16:38:23 <mps> didn't looked, hope someone who worked with it will know
2019-12-01 16:40:40 <sh4rm4^bnc> _ikke_, yeah that looks much better
2019-12-01 16:40:42 <sh4rm4^bnc> trying it now
2019-12-01 16:42:02 <_ikke_> sh4rm4^bnc: documentation around that is a bit lacking, so I had to google around to find out the scopes that are supported
2019-12-01 16:42:15 <_ikke_> and just found an example that mention this
2019-12-01 17:17:49 <mps> hm, postgresql-pglogical is move to GH and is buggy much too
2019-12-01 17:29:52 <mps> oh, this one https://github.com/2ndQuadrant/pglogical/issues/223
2019-12-01 17:30:18 <mps> it is not yet ready for postgresql-12
2019-12-01 17:31:00 <mps> should be disabled for now?
2019-12-01 17:56:50 <mps> perl-xml-libxslt fails only on 32bit, in one test file
2019-12-01 19:47:27 <mps> kernel 4.19.87 is out
2019-12-01 20:09:26 <sh4rm4^bnc> _ikke_, seems to work. i filed issue 11001 as requested.
2019-12-01 20:10:16 <sh4rm4^bnc> wow, that bot is so smart it certainly has a HUGE AI built-in! (j/k)
2019-12-02 08:14:52 <ncopa> morning
2019-12-02 08:16:44 <mps> \o
2019-12-02 08:17:49 <mps> ncopa: you will probably upgrade kernel? 4.19.87?
2019-12-02 08:18:09 <ncopa> looks like it is xmltv, patchwork, llvm5 and postgresql-pglogical that are the current blockers
2019-12-02 08:18:24 <ncopa> yeah, im upgrading the vanilla kernel 4.19.87
2019-12-02 08:18:25 <mps> please look at the !1790 when you do upgrade
2019-12-02 08:19:58 <mps> well, _ikke_ and I discussed some of these blockers, backlog of this channel has our discusssion
2019-12-02 08:20:47 <mps> postgresql-pglogical isn't upgraded upstream to work with postgresql 12, which is in edge
2019-12-02 08:22:12 <_ikke_> latest ghc can use llvm6 (rather than 5), but I had issues compiling it (linker issues)
2019-12-02 08:22:50 <mps> and only ghc and crystal deps on llvm5
2019-12-02 08:25:36 <mps> and upx fails, i made !1795 to fix it
2019-12-02 08:27:06 <mps> but _ikke_ and I ask why is the custom check is added in APKBUILD there
2019-12-02 08:28:50 <mps> _ikke_: could you look !1784
2019-12-02 08:29:21 <mps> it's simple, and I need it pushed before fixing segfault there
2019-12-02 08:29:45 <_ikke_> ok,
2019-12-02 08:30:22 <mps> will wait till night from upstream and if they don't answer will add fixes from void linux
2019-12-02 08:31:16 <_ikke_> pushed
2019-12-02 08:32:06 <mps> I see, thanks. (will not have to go through rebasing my messed branches :) )
2019-12-02 08:33:45 <mps> and, I think we should disable postgresql-pglogical till upstream releases version which supports postgresql 12
2019-12-02 09:07:41 <mps> _ikke_: I see ghc 8.8.1 https://www.haskell.org/ghc/download_ghc_8_8_1.html#sources
2019-12-02 09:08:21 <_ikke_> llvm7 even
2019-12-02 09:08:52 <mps> we moved llvm7 to unmaintained, iirc
2019-12-02 09:08:55 <_ikke_> ah ok
2019-12-02 09:20:50 <_ikke_> ghc 8,6,5 with llvm6: http://tpaste.us/0Pwy
2019-12-02 09:23:49 <mps> oh, ghc is x86_64 only
2019-12-02 10:05:39 <north1> @ncopa can you take a look at #11001 ?
2019-12-02 10:06:57 <mps> north1: I'm against this request
2019-12-02 11:07:20 <ncopa> mps: can you please mention in the issue why you are against it?
2019-12-02 11:07:54 <ncopa> my first reaction was that im against it too, but it seems that we use gnu patch as abuild dep
2019-12-02 11:08:11 <_ikke_> ncopa: correct
2019-12-02 11:08:24 <_ikke_> so most of the time, we are not even using busybox patch
2019-12-02 11:08:37 <ncopa> i thikn that i have used it occationally
2019-12-02 11:08:44 <ncopa> but it is not often
2019-12-02 11:10:01 <clandmeter> why not move it to extras?
2019-12-02 11:10:32 <ncopa> thats also an option
2019-12-02 11:10:50 <ncopa> but if you need patch, you'd probably better off using gnu patch anyway
2019-12-02 11:11:05 <ncopa> rather than install busybox-extras
2019-12-02 11:11:10 <clandmeter> right
2019-12-02 11:11:17 <clandmeter> actually i never reall think what im using
2019-12-02 11:11:29 <_ikke_> clandmeter: if you have alpine-sdk installed, you use gnu patch
2019-12-02 11:11:31 <ncopa> we used to use busybox patch
2019-12-02 11:11:34 <ncopa> long time ago
2019-12-02 11:11:40 <ncopa> but abuild now uses gnu patch
2019-12-02 11:12:55 <ncopa> ae0e4a4e1f05cc2fe7dd371517f1f4d8d663dd4d
2019-12-02 11:13:01 <ncopa> 2015
2019-12-02 11:24:33 <mps> I already wrote about this few days ago here, bb patch is useful for simple patches, usually sysadmin tasks
2019-12-02 11:25:15 <_ikke_> adding it to the issue helps to have a centralized discussion
2019-12-02 11:25:25 <mps> gnu patch is installed by default by alpine-sdk so not issue for developers
2019-12-02 11:25:54 <mps> I have impression that small number of people read issues
2019-12-02 11:26:16 <mps> at least, small number participate in them
2019-12-02 11:26:44 <_ikke_> But at least the involved people
2019-12-02 11:27:12 <_ikke_> BUt the issue the requests is having is that they are detectingi n their project that patch is availale, but patching still failes due to lack of fuzzy matching
2019-12-02 11:29:17 <ncopa> mps: i have also used busybox patch for minor sysadmin tasks
2019-12-02 11:29:23 <ncopa> but i dont do that very often
2019-12-02 11:30:16 <ncopa> the question is if the price for avoiding that extra `apk add patch` is worth it
2019-12-02 11:31:01 <ncopa> the price is 10-20k that cannot be removed for *everyone*
2019-12-02 11:31:21 <_ikke_> For me, that is the weakest argument
2019-12-02 11:32:33 <_ikke_> The docker base image is 5MB, saving 20kb on that is imho not significant
2019-12-02 11:36:19 <mps> agree with _ikke_ here, following every inconvenience with bb applets we should remove bb and add coreutils then
2019-12-02 11:37:24 <mps> for example, first thing I do when install alpine is 'apk add iproute2' and I don't ask to remove bb iproute applets
2019-12-02 11:42:31 <ncopa> i think there are significantly more people who uses busybox ip route than people who use busybox patch
2019-12-02 11:43:10 <mps> probably
2019-12-02 11:44:06 <mps> I will not stop now about that (non) issue
2019-12-02 11:44:35 <ncopa> i appreciate if you post your POV in the issue
2019-12-02 11:44:49 <_ikke_> so for me: 1) removing it just to save space is not worth it, but 2) I don't see a lot of reason to keep it either
2019-12-02 11:45:20 <ncopa> mps: in case i reject the issue i need documentation on why it was rejected
2019-12-02 11:45:38 <_ikke_> ncopa: We might break a lot of things that assume patch is installed by default though
2019-12-02 11:45:49 <ncopa> in case i remove busybox patch, it still serves as documentation that the usecases of it was considered
2019-12-02 11:46:02 <ncopa> _ikke_: that is true
2019-12-02 11:46:32 <ncopa> there may be dockerfiles which uses it
2019-12-02 11:48:27 <mps> ncopa: ok, I will write my opinion there, (although told that I will stop about this :) )
2019-12-02 11:48:50 <mps> heh, that's life, never say never :)
2019-12-02 11:51:50 <mps> I would like to return postgresql-pglogical problem, to repeat, imo it should be disabled for now
2019-12-02 11:53:14 <_ikke_> Then create a patch to propose that :)
2019-12-02 11:53:15 <mps> when the upstream releases new version with postgresql 12 support reenable it for 3.11 stable
2019-12-02 11:53:49 <_ikke_> mps: not sure if that's possible for stable releases
2019-12-02 11:54:10 <_ikke_> if you need to significantly upgrade pglogical
2019-12-02 11:54:26 <mps> it is cumbersome, sure, but anyone have better idea
2019-12-02 11:59:39 <Cogitri> Does downgrading packages just work by decreasing the pkgver or is something additional required to downgrade users who have upgraded already?
2019-12-02 12:14:41 <ncopa> Cogitri: downgrades work by just decrease the pkgver. but you should also increase pkgrel to be whatever it was before upgrade +1
2019-12-02 12:15:20 <ncopa> keep in mind that `apk upgrade` will not downgrade the package so `apk upgrade -a` is needed
2019-12-02 12:15:29 <clandmeter> heh
2019-12-02 12:15:30 <Cogitri> Ah, okie
2019-12-02 12:15:31 <clandmeter> you beat me to it
2019-12-02 12:15:42 <clandmeter> -a i all i use these days
2019-12-02 12:15:44 <Cogitri> We don't have anything that downgrades it for all users?
2019-12-02 12:16:19 <Cogitri> E.g. gnome-session broke horribly in 3.34.2 and was downgraded to 3.34.1 subsequently but users which don't do -a end up with a broken version anyway
2019-12-02 12:16:47 <clandmeter> they dont release a newer version which is not broken?
2019-12-02 12:18:03 <Cogitri> Well, it's only broken on non-systemd versions, soooo :P
2019-12-02 12:18:19 <Cogitri> So upstream doesn't encounter the breakage
2019-12-02 12:18:22 <clandmeter> ah right, who cares about those fools... :)
2019-12-02 12:18:36 <Cogitri> I'll make a fix later but I was just curious if we can downgrade all users until I have smth
2019-12-02 12:18:47 <mps> ( rm -rf *gnome* ) :)
2019-12-02 12:19:10 <clandmeter> Cogitri: apk will always select the highest version
2019-12-02 12:19:10 <ncopa> Cogitri: downgrade the release to 3.34.1 and increase pkgrel is the best you got
2019-12-02 12:19:14 <clandmeter> execpt if you use -a
2019-12-02 12:19:32 <ncopa> it will prevent people who do new install to get the broker version
2019-12-02 12:19:40 <clandmeter> i think there was talk to make it default in new apk?
2019-12-02 12:19:56 <ncopa> possibly
2019-12-02 12:20:00 <Cogitri> That'd be nice
2019-12-02 12:20:11 <Cogitri> Not having any way to downgrade already upgraded users is kinda bad
2019-12-02 12:20:13 <ncopa> i think it makes sense
2019-12-02 12:20:46 <mps> Cogitri: I do by 'apk add pkgname=version'
2019-12-02 12:21:05 <Cogitri> Yes, but that's manual user action
2019-12-02 12:21:16 <Cogitri> Something that just works is nice :)
2019-12-02 12:21:40 <clandmeter> i think you can fix it by depending on exact version in ahtoher pkg?
2019-12-02 12:21:43 <mps> users should be educated
2019-12-02 12:22:04 <clandmeter> so whatever pulls in gnome-session
2019-12-02 12:22:45 <ncopa> ritght, that may work
2019-12-02 12:23:00 <clandmeter> but you need to remind yourself about it
2019-12-02 12:23:37 <ncopa> if there are anything that depends on  gnome-session, then you can do: depends="gnome-session<3.34.2"
2019-12-02 12:23:38 <Cogitri> mps: we don't have a news system built into apk so I don't see how we'd do that
2019-12-02 12:24:34 <mps> right, and I think sometimes we should add it
2019-12-02 12:24:40 <ncopa> but i wouldnt worry to much about it. if people gets bitten by it, we can probably simply tell them to `apk upgrade -a`
2019-12-02 12:24:50 <Cogitri> Alrighty.
2019-12-02 12:25:33 <mps> but again, I don't think that much uneducated users use alpine
2019-12-02 12:25:52 <mps> maybe I'm wrong
2019-12-02 12:26:21 <_ikke_> There are users of all sorts and ranks
2019-12-02 12:27:55 <mps> well, to achieve something where big distros are we need a lot more man power (hands)
2019-12-02 15:27:41 <Tartarus> Ah, here, this might be quicker kaniini
2019-12-02 15:38:41 <kpcyrd> 
ACTION waves from the reproducible builds summit

2019-12-02 15:38:59 <_ikke_> kpcyrd: o/
2019-12-02 15:40:06 <_ikke_> kpcyrd: did you gather ncopa managed to make a reproducable build a while ago? (but some of it had to be reverted because it broke abuild)
2019-12-02 15:40:18 <kpcyrd> we've got to the point that we can build two packages that are identical except the signature. I'm currently trying to strip it for testing purpose (which works), but the datahash is calculated before that and still includes the signature
2019-12-02 15:40:36 <kpcyrd> oh, let me check if there's something I missed
2019-12-02 15:41:22 <_ikke_> Just look at the recent activity in the abuild repo
2019-12-02 15:42:08 <kpcyrd> sonds really interesting, let me check it out real quick
2019-12-02 15:43:47 <_ikke_> https://twitter.com/n_copa/status/1192446676646187008
2019-12-02 15:44:41 <ncopa> hi kpcyrd!
2019-12-02 15:44:47 <ncopa> this is the revert commit https://gitlab.alpinelinux.org/alpine/abuild/commit/51d9e3bcb9fe99a67059e08d7b6fb6ca6a2b75c2
2019-12-02 15:44:58 <PureTryOut[m]> Oh that reminds me, is there a Mastodon account for Alpine Linux? Or does ncopa have a Mastodon account?
2019-12-02 15:45:40 <ncopa> i may have an account, but i dont remember.  and im not using it
2019-12-02 15:47:32 <kpcyrd> hmm, the timestamps are already normalized on in the `find . -exec touch` and `touch -h -d "@$SOURCE_DATE_EPOCH" "$dir"/.PKGINFO` lines, right?
2019-12-02 15:54:04 <PureTryOut[m]> ncopa: could you consider using it or setup a bot that bridges your tweets from Twitter? I'd be interested in following you but I don't use Twitter
2019-12-02 16:10:14 <kpcyrd> ncopa: did you do something about the signature when you got your package to be reproducible? I didn't find it referenced in a commit yet :)
2019-12-02 16:10:43 <_ikke_> kpcyrd: there were multiple commits involved
2019-12-02 16:11:18 <_ikke_> https://gitlab.alpinelinux.org/alpine/abuild/commit/672032a4be46b385da7ac631f688ffaea8ab29bd perhaps?
2019-12-02 16:13:06 <kpcyrd> that's the timestamp in the gzip header :) the file that's currently causing issues for me is .SIGN.RSA.build-5de527c8.rsa.pub
2019-12-02 16:14:04 <_ikke_> What is the issue with that?
2019-12-02 16:21:17 <kpcyrd> huh, I just tested using openssl directly and it seems signing the same file with the same key produces the same signature
2019-12-02 16:21:54 <kpcyrd> I thought that's what's causing a difference but it seems the data it's signing already differs
2019-12-02 16:47:55 <ncopa> kpcyrd: no, the reproducibilty assumes that you ahve the same signing key when you build it
2019-12-02 16:48:32 <ncopa> so, build apk, save the checksum of .apk
2019-12-02 16:48:34 <ncopa> rebuild it
2019-12-02 16:48:38 <ncopa> an compare the checksum
2019-12-02 16:49:29 <_ikke_> But that makes it hard for other to verify the official packages
2019-12-02 16:49:35 <_ikke_> (impossible)
2019-12-02 16:50:06 <_ikke_> You would need to verify the unsigned package
2019-12-02 16:51:32 <_ikke_> (which I guess you cannot avoid)
2019-12-02 17:12:37 <kpcyrd> ncopa: did your patch make the package uninstallable in specific cases or for every time? do you know the line apk fails duing install?
2019-12-02 17:15:05 <_ikke_> every time
2019-12-02 17:15:23 <_ikke_> apk would report the package corrupt
2019-12-02 17:15:50 <kpcyrd> apk does it's own tar parsing, right?
2019-12-02 17:16:24 <_ikke_> I guess so
2019-12-02 17:38:04 <kpcyrd> (1/1) Installing alpine-mirrors (3.5.10-r0)
2019-12-02 17:38:06 <kpcyrd> OK: 237 MiB in 67 packages
2019-12-02 17:38:14 <kpcyrd> I'm not sure but it _seems_ I have a working patch
2019-12-02 17:39:22 <_ikke_> cool
2019-12-02 17:43:59 <kpcyrd> ncopa: can you try this patch? https://gitlab.com/kpcyrd/abuild/commit/b514a4e56d4d17da53bbe5a2d203f616f9a9f371
2019-12-02 17:48:27 <kpcyrd> (_ikke_: also interested in feedback from you if you have time)
2019-12-02 17:48:52 <_ikke_> This is a bit out of my league :)
2019-12-02 18:32:14 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1746/diffs#3236bae76a57fcecdd57eef0a2b0f4ad1e25d6a0_0_13 We don't permit interactive post-install scripts, do we?
2019-12-02 18:32:35 <Cogitri> Heh, not quite, algitbot :P
2019-12-02 18:33:45 <_ikke_> Cogitri: no, we don't
2019-12-02 18:34:52 <Cogitri> Good
2019-12-02 18:42:43 <Cogitri> clandmeter: Wanna check out pr12092?
2019-12-02 20:43:16 <mps> why do we have 'UTF8_LOCALE="en_US.UTF-8"' in mdocml and not 'UTF8_LOCALE="C.UTF-8"'
2019-12-02 20:45:05 <Cogitri> I guess it might not expect the locale to start with C
2019-12-02 20:45:26 <Cogitri> Most stuff doesn't expect it since only musl (and a few distro's glibc) use C.UTF-8
2019-12-02 20:46:16 <mps> musl only use C.UTF-8, so en_US.UTF-8 looks strange
2019-12-02 20:46:35 <Cogitri> Musl itself does, but other programs may not
2019-12-02 20:47:17 <Cogitri> E.g. GNOME sets LANG for the user session differently depending on user configuration, so user programs (e.g. Evolution) show up in that lang
2019-12-02 20:47:58 <mps> yes, but I'm asking for default in mdocml
2019-12-02 20:48:32 <mps> Cogitri: btw, you are/were void developer?
2019-12-02 20:49:39 <Cogitri> I was a Void dev before I switched to Alpine, yes
2019-12-02 20:51:19 <mps> could you tell me what means 'vconf ${FILESDIR}/filename' in template files
2019-12-02 20:53:16 <Cogitri> The alpine equivalent would be `install -Dm644 "$srcdir"/filename "$pkgdir"/etc`
2019-12-02 20:53:51 <mps> thank you
2019-12-02 20:57:14 <Cogitri> :)
2019-12-02 21:04:47 <mps> _ikke_: !1821
2019-12-02 21:05:26 <mps> I took void patches because upstream didn't answered
2019-12-02 21:17:34 <mps> hmm, just received response from mdocml develepor. I have to be more patient
2019-12-03 05:21:59 <_ikke_> mps: :)
2019-12-03 07:20:23 <mps> _ikke_: \o
2019-12-03 07:30:02 <ncopa> morning
2019-12-03 07:30:10 <north1> morning
2019-12-03 07:42:21 <Cogitri> Morning
2019-12-03 07:56:16 <_ikke_> Morning
2019-12-03 09:05:17 <clandmeter> morning
2019-12-03 09:59:59 <clandmeter> ncopa: wasn't there some discussion to include ipv6 in the kernel instead of a module?
2019-12-03 10:02:27 <ncopa> possibly, i dont remember
2019-12-03 10:02:48 <ncopa> we should include ipv4 and unix sockets too in that case
2019-12-03 10:03:43 <clandmeter> i see ipv6 is added to modules file
2019-12-03 10:04:11 <ncopa> 0655da328034c0de4ba88ea54613347b906da77e
2019-12-03 10:09:50 <clandmeter> devs, nld5 is going to reboot
2019-12-03 10:09:54 <clandmeter> hold your horses
2019-12-03 10:10:15 <clandmeter> going to clean the stables
2019-12-03 10:30:27 <clandmeter> we have an issue on nld5
2019-12-03 10:30:37 <clandmeter> failed disk probably, so needs work to recover
2019-12-03 10:31:28 <clandmeter> ncopa: can you backport that EDAC DEBUG fix?
2019-12-03 10:31:38 <clandmeter> its filling up my ringbuffer
2019-12-03 10:35:14 <mps> clandmeter: maybe you can temporary disable module load, blacklist i3200_edac
2019-12-03 10:35:38 <mps> it is x86_64 box?
2019-12-03 10:37:12 <ncopa> ok
2019-12-03 10:37:52 <ncopa> hum, the machine is unavailable...
2019-12-03 10:38:03 <ncopa> my 3.10 machine
2019-12-03 10:38:13 <_ikke_> yes, because it's on nld5 :'(
2019-12-03 11:25:02 <mps> could this be related to xmltv build failures https://github.com/XMLTV/xmltv/issues/77
2019-12-03 11:26:27 <clandmeter> xmltv fails to build only on builders?
2019-12-03 11:29:48 <_ikke_> clandmeter: they are test failures
2019-12-03 11:30:14 <clandmeter> i know
2019-12-03 11:30:20 <clandmeter> i wonder if they alkso fail on ci
2019-12-03 11:30:48 <_ikke_> I'll test it
2019-12-03 11:31:01 <mps> clandmeter: it fails also locally on my box
2019-12-03 11:31:11 <_ikke_> ah ok
2019-12-03 11:31:16 <clandmeter> ok
2019-12-03 11:32:24 <mps> I read the cause is perl-xml-libxml changes in some number parameters, from 2 to 3, iirc, but don't have time to look deeply
2019-12-03 11:37:42 <clandmeter> 
ACTION slaps fcolista around a bit with a large trout

2019-12-03 11:38:07 <clandmeter> c007998b4cd24694f46393698fff4f20e36bf6ca
2019-12-03 11:38:21 <_ikke_> :D
2019-12-03 11:44:49 <ncopa> mps: i tried to downgrade perl-xml-parser to 2.45, but it still fails
2019-12-03 11:48:37 <ncopa> ok, i found a fix upstream for xmltv
2019-12-03 11:48:42 <_ikke_> nice
2019-12-03 11:48:52 <ncopa> https://github.com/XMLTV/xmltv/commit/5463cde27030237d79fedd200e49968edaa06f67
2019-12-03 11:48:57 <ncopa> im applying it
2019-12-03 11:49:02 <ncopa> and fixing the contributor line
2019-12-03 11:49:18 <_ikke_> How did you find it?
2019-12-03 11:49:46 <ncopa> i looked at the source url, to find where it was downloaded from, to see if there was any new release
2019-12-03 11:49:54 <ncopa> found it that it was from github
2019-12-03 11:50:16 <ncopa> i looked at github releases and it said that there were 55 commits since last release
2019-12-03 11:50:24 <ncopa> i had a look at the commits
2019-12-03 11:50:45 <mps> also I nowadays mostly look at source urls, 'url' for not small number of pkgs is wrong
2019-12-03 11:51:12 <mps> hmm, and I thought we can downgrade packages
2019-12-03 11:51:22 <mps> s/can/can't/
2019-12-03 11:51:22 <alpine-meetbot> mps meant to say: hmm, and I thought we can't downgrade packages
2019-12-03 11:51:24 <ncopa> and saw imdb something, which i think i saw in the error log, it also seems to be related to redirection
2019-12-03 11:51:35 <_ikke_> mps: we can downgrade them, apk is just not automatically installing it
2019-12-03 11:51:41 <ncopa> which the issue mps pointed to seemed to be related to
2019-12-03 11:51:57 <ncopa> so i just took a chance and tried to build it with the patch
2019-12-03 11:52:37 <_ikke_> for x86_64, there are not a lot of packages left to build
2019-12-03 11:54:06 <mps> and yes, I know it was related but as told don't have time now to look deeply
2019-12-03 11:54:51 <mps> ncopa: btw, could you look at upx MR
2019-12-03 11:54:53 <_ikke_> ncopa: did you have a fix for sshd being truncated already?
2019-12-03 11:54:57 <_ikke_> on the builders
2019-12-03 11:55:34 <clandmeter> i have a fix
2019-12-03 11:55:47 <_ikke_> ok
2019-12-03 11:55:53 <clandmeter> but you wont like it :)
2019-12-03 11:55:59 <_ikke_> oh
2019-12-03 11:56:06 <mps> !1795
2019-12-03 11:56:19 <clandmeter> use abuild rootbld
2019-12-03 11:56:31 <_ikke_> why wouldn't I like it?
2019-12-03 11:56:41 <clandmeter> i dont think you will mind it
2019-12-03 11:56:48 <clandmeter> i think the other person here will ;-)
2019-12-03 11:56:57 <_ikke_> It's just that we need some permissions on lxc to be able to do that
2019-12-03 11:57:16 <clandmeter> our buildsystem sucks
2019-12-03 11:57:24 <clandmeter> thats not to complain about it.
2019-12-03 11:57:29 <clandmeter> i this case it sucks
2019-12-03 11:57:41 <clandmeter> abuild should never overwrite system apps
2019-12-03 11:57:59 <_ikke_> It makes a lot of sense to have an isolated build environment
2019-12-03 11:58:09 <_ikke_> a lot of issues we need to regularly fix would be solved by that
2019-12-03 11:58:28 <clandmeter> i think abuild rootbld could fix it
2019-12-03 11:58:30 <Cogitri> Yes
2019-12-03 11:58:39 <clandmeter> a new build system for sure would
2019-12-03 11:58:46 <_ikke_> iirc, you'd need to add some permissions to lxc to be able to use bubblewrap
2019-12-03 11:58:56 <clandmeter> yes
2019-12-03 11:59:18 <Cogitri> clandmeter: new buildsystem aka abuildv$Next  ?
2019-12-03 11:59:52 <clandmeter> the one that ncopa wanted to talk about in fosdem :|
2019-12-03 12:00:57 <Cogitri> Oh, I wasn't at this years FOSDEM sadly
2019-12-03 12:01:06 <Cogitri> (Hopefully at the next one though)
2019-12-03 12:01:41 <clandmeter> the plan was 2020 afaik
2019-12-03 12:01:45 <clandmeter> but i think ncopa cant go
2019-12-03 12:02:03 <_ikke_> yes, he said he can't
2019-12-03 12:02:14 <clandmeter> maybe fabled wants to talk about new apk-tools
2019-12-03 12:02:19 <clandmeter> that would be cool :)
2019-12-03 12:02:39 <clandmeter> as long i dont have to talk, everyting is cool .
2019-12-03 12:09:01 <ncopa> mps: wouldnt it be better to try fix -static -no-pie?
2019-12-03 12:11:23 <Cogitri> clandmeter:+1 on that :P
2019-12-03 12:12:03 <clandmeter> ncopa: cant we introduce rootbld on builders?
2019-12-03 12:12:47 <ncopa> i think we could
2019-12-03 12:12:48 <ncopa> but
2019-12-03 12:12:59 <clandmeter> options=!rootbld in case it fails
2019-12-03 12:12:59 <mps> ncopa: this test is added in APKBUILD, it doesn't exist upstream
2019-12-03 12:13:10 <ncopa> its a major change
2019-12-03 12:13:31 <ncopa> im a bit worried to do that change so late
2019-12-03 12:13:35 <ncopa> before release
2019-12-03 12:13:40 <_ikke_> Yeah, would probably be best to do after 3.11
2019-12-03 12:13:42 <clandmeter> we dont need it now
2019-12-03 12:13:50 <ncopa> lets do it after 3.11
2019-12-03 12:13:53 <mps> not sure if this test is needed at all
2019-12-03 12:13:59 <clandmeter> ok but for sure then.
2019-12-03 12:14:05 <clandmeter> i think we discussed it before :)
2019-12-03 12:14:05 <_ikke_> Does it require option=net for packages that need an internet connection?
2019-12-03 12:14:14 <clandmeter> yes
2019-12-03 12:14:17 <ncopa> mps: it tests that upx works with a static binary without pie
2019-12-03 12:14:21 <ncopa> apparently it used to work
2019-12-03 12:14:52 <_ikke_> so all go / rust packages at least
2019-12-03 12:15:23 <mps> yes, but then we should contact maintainer and ask his reasoning for this, and fix
2019-12-03 12:15:27 <clandmeter> yes, its a very intrusive change
2019-12-03 12:15:46 <_ikke_> but that's something we can prepare in advance for I guess?
2019-12-03 12:15:48 <clandmeter> so devs  should be prepared
2019-12-03 12:15:54 <clandmeter> kappe nou
2019-12-03 12:15:57 <clandmeter> :p
2019-12-03 12:15:59 <ncopa> mps: the reasoning is that we want upx to work on different kinds of binaries
2019-12-03 12:16:05 <Cogitri> ikke: First step would be warn/error in CI
2019-12-03 12:16:11 <mps> aha, ok
2019-12-03 12:16:20 <ncopa> mps: the error is: upx.out: upxtest: EOFException: premature end of file
2019-12-03 12:16:20 <_ikke_> clandmeter: ;-)
2019-12-03 12:16:39 <ncopa> so apparently upx is not able to parse the -static -no-pie binary
2019-12-03 12:16:42 <_ikke_> Cogitri: how can CI detect it?
2019-12-03 12:16:43 <mps> not sure that I will have time in next few days to look at deeply
2019-12-03 12:16:56 <_ikke_> Cogitri: just based on language (ie, deps / makedeps)?
2019-12-03 12:17:17 <mps> I have to fix mdocml and maybe crystal, if we remove llvm5
2019-12-03 12:17:28 <ncopa> i think i fixed llvm5
2019-12-03 12:17:34 <ncopa> it was the mips target that failed
2019-12-03 12:17:40 <ncopa> so i simply removed mips target
2019-12-03 12:17:48 <mps> iirc, it fails on all
2019-12-03 12:17:58 <ncopa> oh?
2019-12-03 12:18:19 <mps> maybe _ikke_ have more infos
2019-12-03 12:18:36 <_ikke_> nope
2019-12-03 12:18:46 <Cogitri> _ikke_: Oh right, somehow I forgot we don't fetch lang deps in a seperate phase, oops :P
2019-12-03 12:18:47 <Cogitri> Maybe we can just have a rootbld pipeline?
2019-12-03 12:18:58 <mps> and firefox with rust 1.39 fails on all
2019-12-03 12:19:15 <Cogitri> Yes, but ff 71 will be released tomorrow with fixes for that
2019-12-03 12:19:29 <_ikke_> Cogitri: does rootbld work in docker?
2019-12-03 12:19:30 <mps> good news
2019-12-03 12:25:25 <Cogitri> ikke: In privileged containers probably, dunno if it works in unprivileged ones
2019-12-03 12:26:14 <_ikke_> And using privileged containers in CI does not sound like a good plan
2019-12-03 12:26:37 <_ikke_> But I think it might be possible to give just the specific capabilities it needs
2019-12-03 12:27:06 <Cogitri> Yup, using privileged containers with untrusted input isn't a good idea
2019-12-03 12:29:08 <_ikke_> clandmeter: do we know how to allow rootbld on lxc already?
2019-12-03 12:37:56 <_ikke_> hmm, xmltv still failing?
2019-12-03 12:38:00 <ncopa> mps: i applied your upx patch, i only added a FIXME comment
2019-12-03 12:38:16 <mps> that's fine, I think
2019-12-03 12:38:38 <mps> if we find solution later this can be reenabled
2019-12-03 12:39:08 <mps> iiuc, you want 3.11 release soon
2019-12-03 12:40:10 <ncopa> ugh... i think i have messed up the xmltv test
2019-12-03 12:41:09 <ncopa> phew... seems i was lucky
2019-12-03 12:42:12 <fcolista> clandmeter, ?
2019-12-03 12:42:24 <_ikke_> fcolista: you messed up an upgrade
2019-12-03 12:42:32 <fcolista> which one?
2019-12-03 12:43:07 <_ikke_> http://dup.pw/aports/c007998b
2019-12-03 12:43:24 <_ikke_> it's a silly issue :)
2019-12-03 12:43:37 <ncopa> the contributor line
2019-12-03 12:43:55 <ncopa> and i have fixed it already
2019-12-03 12:43:56 <fcolista> omg
2019-12-03 12:44:00 <ncopa> :)
2019-12-03 12:44:23 <fcolista> /0\
2019-12-03 12:44:37 <clandmeter> Hehe
2019-12-03 12:44:41 <fcolista> 
ACTION deserves being slapped with large trout :)

2019-12-03 12:45:38 <ncopa> looks like community repos are 99% or 100% on all arches
2019-12-03 12:45:55 <ncopa> which means we are close to make rc1
2019-12-03 12:46:00 <_ikke_> :)
2019-12-03 12:46:04 <Cogitri> Nice
2019-12-03 12:46:14 <ncopa> have you tested the linux-lts?
2019-12-03 12:46:40 <ncopa> i'd like to move linux-vanilla to community and linux-lts to main
2019-12-03 12:47:01 <ncopa> and use that as the default kernel for v3.11
2019-12-03 12:47:58 <Cogitri> Sounds good to me
2019-12-03 12:47:59 <Cogitri> I'm using linux-lts right now
2019-12-03 12:48:36 <Cogitri> For some reason my laptop doesn't boot with linux-vanilla anymore though
2019-12-03 12:48:49 <ncopa> heh
2019-12-03 12:49:35 <Cogitri> So yeah, +1 for linux-lts :P
2019-12-03 12:51:18 <mps> also I use -lts, no issues, or I didn't noticed
2019-12-03 12:52:49 <mps> only don't forget to apply EDAC_DEBUG patch for x86_64
2019-12-03 12:53:35 <ncopa> right, i'll do that with 5.4.2
2019-12-03 12:53:49 <mps> and I need to update linux-headers MR
2019-12-03 12:56:14 <kpcyrd> ncopa: did you have time to look at my patch or are there any concerns if I use an abuild with that patch applied on reproducible-builds CI? :) https://gitlab.com/kpcyrd/abuild/commit/b514a4e56d4d17da53bbe5a2d203f616f9a9f371
2019-12-03 13:22:25 <ncopa> kpcyrd: i had a quick look at it, but i think the checksum differed after built second time
2019-12-03 13:22:54 <ncopa> i am also slightly worried to modify the way the packages are built so close to a release
2019-12-03 13:23:04 <ncopa> almost all packages for v3.11 is built at this point
2019-12-03 13:23:19 <ncopa> so i think i'll have a closer look at it after the 3.11 release
2019-12-03 13:23:54 <ncopa> it does seem to fix the problem with package not being installable
2019-12-03 13:26:55 <ncopa> i moved doas to main
2019-12-03 13:27:07 <ncopa> i wonder about the default config though
2019-12-03 13:27:14 <ncopa> it currently has:
2019-12-03 13:27:25 <ncopa> # Uncomment to allow group "admin" to become root
2019-12-03 13:27:25 <ncopa> # permit :admin
2019-12-03 13:27:47 <ncopa> we had group "wheel" in default sudo config
2019-12-03 13:27:55 <ncopa> so i wonder if we should od:
2019-12-03 13:27:58 <ncopa> do:
2019-12-03 13:28:18 <ncopa> # permit persistent :wheel
2019-12-03 13:28:22 <ncopa> as the default
2019-12-03 13:28:55 <ncopa> or do we want change wheel -> admin?
2019-12-03 13:29:28 <_ikke_> wheel would probably be more in line with what other distros do?
2019-12-03 13:31:15 <_ikke_> sudo is also common, but would not make sense for doas
2019-12-03 13:31:57 <mps> _ikke_: I finished mdocml (for now at least) !1821
2019-12-03 13:32:21 <_ikke_> mps: I can look at it later
2019-12-03 13:32:28 <mps> please, push it or build locally and test if the segfault is fixed
2019-12-03 13:32:51 <mps> ok, np, just don't forget, I can't it is in main
2019-12-03 13:33:22 <mps> and sorry to annoy you too often
2019-12-03 13:33:31 <_ikke_> np
2019-12-03 15:33:28 <walbon> Hi folks, I'm newcomer on the alpine project and I would like to help with powerpc issues. Testing, build, etc.
2019-12-03 15:33:58 <ncopa> walbon: welcome!
2019-12-03 15:34:54 <mps> \o/
2019-12-03 15:45:50 <_ikke_> walbon: welcome from me as well :)
2019-12-03 15:46:10 <_ikke_> Feel free to ask questions
2019-12-03 15:55:45 <clandmeter> _ikke_: i think i have set some options on my container to allow bwrap
2019-12-03 15:55:53 <clandmeter> not sure which syscalls it needs
2019-12-03 15:56:03 <clandmeter> I probably didnt look too close
2019-12-03 15:56:18 <_ikke_> ok
2019-12-03 15:59:07 <mps> Cogitri: https://ftp.mozilla.org/pub/firefox/releases/71.0/source/firefox-71.0.source.tar.xz
2019-12-03 16:02:04 <ahmedbilal> How to get previous N messages? Some one mentioned me but I was offline
2019-12-03 16:02:37 <clandmeter> https://dev.alpinelinux.org/irclogs/
2019-12-03 16:02:49 <_ikke_> clandmeter: now you beat me :)
2019-12-03 16:03:20 <mps> and me :)
2019-12-03 16:03:25 <clandmeter> we should let algitbot metnion it on irc + logs
2019-12-03 16:03:54 <mps> some shorthand: 'algitbot: irclog'
2019-12-03 16:05:09 <ahmedbilal> algitbot: irclog
2019-12-03 16:05:20 <ahmedbilal> 'algitbot: irclog'
2019-12-03 16:05:32 <clandmeter> heh, it is a suggestion from mps
2019-12-03 16:05:38 <clandmeter> not a real feature
2019-12-03 16:05:50 <ahmedbilal> clandmeter: Thanks. I start trying that :+1:\
2019-12-03 16:06:28 <ahmedbilal> Ok. So, it is false positive from freenode. There was no new message for me. :]
2019-12-03 16:06:43 <ahmedbilal> fcolista: Hi, did you fix the issue?
2019-12-03 16:08:21 <ahmedbilal> fcolista: Currently, I am installing etcd as `apk add etcd' `curl https://raw.githubusercontent.com/etcd-io/etcd/release-3.4/etcd.conf.yml.sample -o /etc/etcd/conf.yml` and then `service etcd start`
2019-12-03 16:09:25 <ahmedbilal> fcolista: Correctly Formatted: `apk add etcd` `curl https://raw.githubusercontent.com/etcd-io/etcd/release-3.4/etcd.conf.yml.sample -o /etc/etcd/conf.yml` and `service etcd start`
2019-12-03 16:11:11 <clandmeter> wut
2019-12-03 16:13:24 <clandmeter> rnalrd: why is go in depends? b9e2e0c480ef3958c6dfac5191afb37a48cbec1a
2019-12-03 16:14:14 <clandmeter> _ikke_: could we warn CI on lines that are longer than 80 chars?
2019-12-03 16:15:20 <clandmeter> oh im getting tired, looking in gentoo repo...
2019-12-03 16:15:41 <walbon> ncopa, mps, _ikke_: thks
2019-12-03 16:17:18 <_ikke_> clandmeter: you mean APKBUILD lines?
2019-12-03 16:17:27 <clandmeter> yes
2019-12-03 16:17:28 <_ikke_> clandmeter: every hash would violate it
2019-12-03 16:17:44 <clandmeter> depends on rules i think?
2019-12-03 16:17:57 <clandmeter> src and checksum could be excluded?
2019-12-03 16:20:40 <_ikke_> I would set the warning threshold to 90 or so to give a little bit of leeway
2019-12-03 16:21:10 <_ikke_> 8-tab indent means you loose a lot of space already
2019-12-03 16:21:18 <_ikke_> 8-space tab I mean
2019-12-03 16:21:28 <_ikke_> but that's more visualy
2019-12-03 16:21:50 <clandmeter> ?
2019-12-03 16:21:53 <clandmeter> we use tabs right?
2019-12-03 16:22:15 <_ikke_> es
2019-12-03 16:22:17 <_ikke_> yes
2019-12-03 16:22:22 <_ikke_> ignore that part
2019-12-03 16:22:29 <clandmeter> :)
2019-12-03 16:25:52 <_ikke_> I use a column line in vim for the 80th column, but with tab characters that is not the same
2019-12-03 16:26:21 <clandmeter> understand
2019-12-03 16:26:29 <clandmeter> i was triggered by gentoo repo
2019-12-03 16:26:36 <clandmeter> it used some really long lines
2019-12-03 16:26:50 <clandmeter> but i think in genenral its not bad to check for it.
2019-12-03 16:27:11 <_ikke_> Still there would be lots of APKBUILD files violating it
2019-12-03 16:27:24 <clandmeter> but we can warn right?
2019-12-03 16:27:27 <_ikke_> yup
2019-12-03 16:37:38 <north1> clandmeter (IRC): Tried to warn on over 80 chars but that will catch all sha512sums=
2019-12-03 16:39:33 <north1> The builders are trying to build snapcast which is already up to date
2019-12-03 16:39:41 <north1> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/snapcast/snapcast-0.17.1-r0.log
2019-12-03 16:48:46 <_ikke_> north1: so we are going to exclude those lines
2019-12-03 17:32:14 <mps> north1: thanks, 'hawk eye' :)
2019-12-03 17:32:34 <north1> _ikke_ (IRC): alright
2019-12-03 17:32:48 <north1> mps (IRC): welcome
2019-12-03 17:35:17 <mps> hmm, for build problem with community/x2goserver there is for some time MR !685
2019-12-03 17:37:36 <_ikke_> north1: is the (IRC) part necessary btw :)
2019-12-03 17:38:22 <mps> to remind us where we are :)
2019-12-03 17:38:25 <north1> No but the matrix-irc bridge i'm using has people using IRC with the (IRC) suffix so it appears when i autocomplete people's names
2019-12-03 19:14:17 <_ikke_> Cogitri: let's continue here
2019-12-03 19:26:13 <kpcyrd> ncopa: sure, no hurry. :) I think I could reproduce the issue, the order of the files in the package may vary
2019-12-03 19:39:41 <Cogitri> Sure, ikke
2019-12-03 20:24:54 <kpcyrd> I think somewhere in the backlog it said something about alpine always using LANG=C.UTF-8, right?
2019-12-03 20:26:20 <mps> kpcyrd: it should
2019-12-03 20:28:29 <kpcyrd> do people care if my patch forces LC_ALL=C in abuild when calling sort?
2019-12-03 20:29:47 <mps> I don't know but still think it is better to use C.UTF-8
2019-12-03 20:40:23 <andypost[m]> ncopa: I can reproduce in chroot php7-pecl-gmagick logs looks like int32 overflow, imo better disable x86 for 3.11
2019-12-03 22:26:39 <kpcyrd> \o\ \o/ /o/ https://tests.reproducible-builds.org/alpine/main/py3-uritemplate/py3-uritemplate-3.0.0-r4.apk.html \o\ \o/ /o/
2019-12-03 22:28:14 <mps> \o/
2019-12-03 23:27:27 <Crusher4> is there an issue with the main alpine repo on rsync today?
2019-12-03 23:27:57 <Crusher4> ( rsync://rsync.alpinelinux.org/alpine/ )
2019-12-03 23:29:05 <Crusher4> or is that better asked in alpine-linux? you guys dont seem to have a mirror channel
2019-12-03 23:37:20 <PureTryOut[m]> #alpine-infra would probably be the right place
2019-12-04 01:13:27 <north1> builders keep trying to build snapcast which is up-to-date
2019-12-04 01:31:29 <andypost[m]> Confirm, seen that few times whole evening
2019-12-04 05:41:54 <Cogitri> Could someone with main bits look at pr12095?
2019-12-04 05:42:57 <_ikke_> Cogitri: you think it's good to go?
2019-12-04 05:43:40 <Cogitri> I think so, yes (you might want to add what he's written in the PR description to the commit msg though)
2019-12-04 05:43:57 <_ikke_> yeah, I noticed that
2019-12-04 05:44:22 <_ikke_> so sad that sites like github / gitlab dilute the value of proper commit messages
2019-12-04 05:44:34 <_ikke_> (by making them 2nd class)
2019-12-04 08:32:22 <mps> is the the llvm5 fixed
2019-12-04 08:32:59 <mps> ncopa: ^
2019-12-04 08:34:00 <mps> I made patch for crystal to fix failed check, and wait for llvm5 before pushing
2019-12-04 08:34:14 <_ikke_> mps: seems like it
2019-12-04 08:34:28 <_ikke_> But I don't see a fix for it
2019-12-04 08:35:23 <mps> ah good, then I will push crystal fix in a hour
2019-12-04 08:36:03 <mps> fix = workaround, actually :/
2019-12-04 08:36:03 <_ikke_> not sure why it suddenly just built
2019-12-04 08:36:41 <mps> white magic, what else :)
2019-12-04 09:01:21 <kaey> _ikke_: if you "squash merge" pr description is set as commit message
2019-12-04 09:01:42 <_ikke_> kaey: we don't typically squash merge
2019-12-04 09:02:09 <_ikke_> We assume each commit is usefull with a usefull commit message
2019-12-04 09:15:36 <_ikke_> 7 packages left for aarch64 :-)
2019-12-04 09:34:47 <mps> Am I blind or edge aarch64 builder is not working?
2019-12-04 09:36:15 <_ikke_> Looks like its stuck on xmrig
2019-12-04 09:37:45 <_ikke_> killed it
2019-12-04 09:37:52 <mps> I see
2019-12-04 09:38:57 <_ikke_> it needs to build 36 packages
2019-12-04 09:39:56 <mps> it builds main right now, good
2019-12-04 09:40:50 <_ikke_> 19 packages for main, 36 for community
2019-12-04 09:40:57 <_ikke_> so it has a bit of a backlog
2019-12-04 09:41:22 <mps> oh, crystal on x86_64 Invalid memory access (signal 11) at address 0x7ff00bb211d8
2019-12-04 09:41:52 <mps> that is, 3.11
2019-12-04 09:42:50 <mps> seriously thinking to disable check and build it with llvm8
2019-12-04 09:43:22 <mps> would be nice if maintainer comment this idea
2019-12-04 10:40:34 <fredrigu> does apk has weak dependencies? Like rpms Suggests or Recommends?
2019-12-04 10:41:02 <_ikke_> not atm
2019-12-04 10:41:17 <fredrigu> _ikke_: thanks
2019-12-04 10:42:16 <ncopa> mps: this "fixed" lllvm5: 8022bb4b09eeb11d7fe081b4dceafc0e7dfa7192
2019-12-04 10:46:15 <ncopa> looks like crystal supportes llvm8
2019-12-04 10:47:58 <Cogitri> They recently added support for LLVM8 or 9 I think
2019-12-04 10:48:18 <_ikke_> who are they?
2019-12-04 10:48:19 <ncopa> we should porbably try use llvm8 then
2019-12-04 10:48:51 <PureTryOut[m]> "Removed mips for now"? I didn't think Alpine supported the MIPS target?
2019-12-04 10:48:53 <PureTryOut[m]> *architecture
2019-12-04 10:49:05 <_ikke_> PureTryOut[m]: someone is working on adding that
2019-12-04 10:49:05 <ncopa> we dont
2019-12-04 10:49:58 <PureTryOut[m]> Interesting. I did see a lot of patches on the mailing list from "alpine-mips-patches"
2019-12-04 10:50:45 <mps> yes, crystal can be built with llvm8 for about 4-5 months, I tested it on both aarch64 and x86_64
2019-12-04 10:51:25 <mps> but when built with llvm8 test fails on aarch64
2019-12-04 10:52:14 <_ikke_> haskell supports llvm6/7 now, but I think we have issues getting it compiled
2019-12-04 10:53:19 <_ikke_> https://github.com/alpinelinux/aports/pull/6829
2019-12-04 11:06:42 <Cogitri> PureTryOut[m]: "remove mips" means "remove the mips target from LLVM" in this context, meaning LLVM5 can't target (e.g. when crosscompiling) it
2019-12-04 11:07:09 <PureTryOut[m]> I get that. But the commit message said "for now", suggesting MIPS is wanted
2019-12-04 11:07:26 <ncopa> we probably want mips support yes
2019-12-04 11:07:35 <ncopa> but its not clear if we need llvm5 with mips support
2019-12-04 11:07:49 <ncopa> at this point it means that we dont have crystal or ghc
2019-12-04 11:11:03 <mps> don't know for ghc, but looks like crystal upstream don't care much about crystal on aarch64 (except few devs)
2019-12-04 11:11:44 <mps> maybe we also should keep it only on x86_64
2019-12-04 11:12:17 <PureTryOut[m]> I wonder if ghc works with newer llvm's
2019-12-04 11:12:45 <mps> afaik, no
2019-12-04 11:16:17 <PureTryOut[m]> I wonder of our ghc maintainer is still active. It needs to be updated
2019-12-04 12:02:42 <_ikke_> PureTryOut[m]: they are
2019-12-04 12:02:49 <_ikke_> PureTryOut[m]: there is PR open for a couple of months already
2019-12-04 12:02:53 <_ikke_> but there are build issues
2019-12-04 12:02:56 <_ikke_> https://github.com/alpinelinux/aports/pull/6829
2019-12-04 12:04:51 <PureTryOut[m]> Ah damn 😕
2019-12-04 12:05:44 <_ikke_> Maybe I will ask about it in #haskell, maybe someone there knows what the issue is
2019-12-04 12:25:55 <tmhoang> wth ocaml failing?
2019-12-04 12:26:38 <tmhoang> it looks like it is pulling ocaml-ocamlbuild built with ocaml-4.09
2019-12-04 12:26:47 <tmhoang> it = builder
2019-12-04 12:43:09 <ncopa> yes
2019-12-04 12:43:26 <ncopa> seems like building ocamlbuild pulls in ocaml-4.09
2019-12-04 12:43:48 <tmhoang> maybe need a bump ?
2019-12-04 13:47:57 <_ikke_> now ghc is failing to build
2019-12-04 13:48:07 <_ikke_> ah, needs to be bootstrapped
2019-12-04 14:07:39 <ncopa> which machine?
2019-12-04 14:07:52 <_ikke_> x86_64, I was already on it
2019-12-04 14:07:59 <ncopa> i manually fixed the ocaml issue
2019-12-04 14:08:25 <ncopa> the problem was that ocaml-4.09 was not removed due to the repository was not completely built
2019-12-04 14:08:34 <ncopa> old packages are removed after finished build of repo
2019-12-04 14:08:48 <ncopa> so ocamlbuild pulled in latest ocaml, 4.09
2019-12-04 14:08:57 <ncopa> i manually removed the ocaml-4.09 package
2019-12-04 14:08:59 <_ikke_> did you restart the buider?
2019-12-04 14:09:03 <ncopa> yeah
2019-12-04 14:09:07 <_ikke_> noticed it :)
2019-12-04 14:09:13 <ncopa> where you in there?
2019-12-04 14:09:22 <_ikke_> yes, not actively though
2019-12-04 14:09:28 <ncopa> sorry
2019-12-04 14:09:29 <_ikke_> np
2019-12-04 14:09:36 <_ikke_> I just noticed my ssh session got dc'd
2019-12-04 14:10:27 <_ikke_> waiting for ghc to be build again
2019-12-04 14:27:34 <ncopa> the 32bit builders are done with 3.11
2019-12-04 14:27:47 <ncopa> im rebuilding crystal with llvm8
2019-12-04 14:28:54 <_ikke_> \o/
2019-12-04 14:29:19 <_ikke_> ugh, ghc fails now with the same linker issues :(
2019-12-04 14:42:52 <mps> ncopa: hope you will have more luck than I
2019-12-04 14:43:15 <mps> it builds on x86_64
2019-12-04 14:43:18 <fredrigu> _ikke_: what does apk install-if do?
2019-12-04 14:45:09 <_ikke_> ERROR: 'install-if' is not an apk command. See 'apk --help'.
2019-12-04 14:45:25 <_ikke_> fredrigu: are you referring to install_if in akbuild?
2019-12-04 14:45:31 <_ikke_> APKBUILD*
2019-12-04 14:45:55 <fredrigu> _ikke_: correct, it's package value just as depends and provides
2019-12-04 14:46:01 <fredrigu> yes, as in apkbuild
2019-12-04 14:46:22 <_ikke_> It allows you to specify that a package should be automaticall installed if another package is installed
2019-12-04 14:46:42 <_ikke_> We use it for example to automatically install the -openrc subpackages if openrc is installed
2019-12-04 14:46:55 <_ikke_> or all *-doc subpackages if docs is installed
2019-12-04 14:47:13 <_ikke_> (the relevant packages only)
2019-12-04 14:47:33 <fredrigu> oh, sounds like the same usage as "Recommends" in the rpm world, but still not quite
2019-12-04 14:47:45 <_ikke_> it's not recommends
2019-12-04 14:48:14 <fredrigu> I know, but the usage overlap. "Install this package if another package exists"
2019-12-04 14:48:27 <mps> more like dependent
2019-12-04 14:48:50 <fredrigu> yeah, it's a different way of solving the same problem
2019-12-04 14:49:19 <fredrigu> well, unfortunately I need Recommends, so I'll add it
2019-12-04 14:49:26 <_ikke_> In aports it's not necessarily used in a recommends kind of way
2019-12-04 14:49:42 <_ikke_> more like, only install these additional files if it makes sense
2019-12-04 14:50:24 <_ikke_> a lot of packages have autocompletion files for certain shells, but they will only be installed if you have that particular shell installed
2019-12-04 14:51:03 <_ikke_> fredrigu: there has been a mailing list topic about this btw
2019-12-04 14:51:08 <_ikke_> (recommends and optional)
2019-12-04 14:51:12 <fredrigu> _ikke_: that's the same way bitbake/yocto uses recommends. "Always try to install all these package but don't care if they fails and then a package will fail to install if not another package already is installed"
2019-12-04 14:51:38 <fredrigu> _ikke_: nice, thanks. On the alpine-devel? I'll read it
2019-12-04 14:51:44 <_ikke_> https://lists.alpinelinux.org/~alpine/devel/%3C883dca1a-b7f3-6137-059d-f561ef22c126%40cosmoborsky.com%3E
2019-12-04 14:54:50 <_ikke_> fredrigu: it's more that apk automatically installs packages as soon as another package is installed
2019-12-04 14:55:16 <_ikke_> maybe like a recommends with a dependency t
2019-12-04 14:55:18 <_ikke_> then
2019-12-04 14:55:45 <_ikke_> but in aports it's almost exclusively used for subpackages
2019-12-04 14:56:01 <_ikke_> so it's not used to install completely different packages automatically
2019-12-04 14:56:51 <fredrigu> _ikke_: thanks, I see
2019-12-04 14:57:20 <fredrigu> so it sounds like ncopa isn't too happy about a recommends feature. I understand him
2019-12-04 14:58:10 <_ikke_> more like there are a lot of caveats
2019-12-04 14:58:55 <fredrigu> My use case is that if a package is in recommends it should be installed but if it's not found (i.e. not in the APKINDEX.tar.gz) we should just silently ignore it and not quit with an error
2019-12-04 14:59:14 <fredrigu> to me it sounds like a bit of a stupid usecase, but that's how rpm handles it
2019-12-04 14:59:32 <fredrigu> perhaps I've to do a patch that won't be included upstream in apk
2019-12-04 15:02:09 <mps> if pkg can work without 'install-if' pkg then I don't think this dependent pkg should be automatically installed
2019-12-04 15:03:01 <mps> alpine trying to escape from so called 'dependency hell'
2019-12-04 15:08:08 <_ikke_> fredrigu: Is there some reason you need to duplicate what rpm does?
2019-12-04 15:13:38 <ddevault> is Konstantin Kulikov in this channel?
2019-12-04 15:13:54 <fredrigu> _ikke_: yes, I try to use apk in bitbake and its default package system is rpm (but it also supports deb and opkg). So I need to have functionality in apk that is up to the lowest common denominator for rpm, deb and ipkg
2019-12-04 15:14:26 <fredrigu> I'm not saying this is something that needs to be included in apk. But I need it
2019-12-04 15:15:16 <_ikke_> fredrigu: yes, was just curious to the usecase :)
2019-12-04 15:15:43 <_ikke_> ddevault: probably not
2019-12-04 15:16:45 <fredrigu> _ikke_: I think recommends is not really the same as install-if but sometimes they do overlap. It's also interesting that rpm, deb and ipkg have decided that they need a feature that apk lacks, and still alpine linux works well
2019-12-04 15:17:57 <_ikke_> fredrigu: I think because Alpine mostly caters to people who know what they want / need
2019-12-04 15:19:08 <kaey> ddevault: yes
2019-12-04 15:19:17 <ddevault> hey kaey
2019-12-04 15:19:24 <ddevault> looking at your prometheus feedback now
2019-12-04 15:19:30 <ddevault> can you tell me more about the output_log and error_log changes you're asking for?
2019-12-04 15:20:08 <ddevault> does that just involve putting output_log=/var/log/prom.log & error_log in the conf.d file, then updating the supervise_daemon_args?
2019-12-04 15:20:18 <ddevault> and checkpath
2019-12-04 15:20:53 <kaey> https://github.com/OpenRC/openrc/blob/master/sh/supervise-daemon.sh#L31
2019-12-04 15:21:09 <ddevault> oh cool
2019-12-04 15:21:11 <ddevault> easy peasy
2019-12-04 15:21:27 <ddevault> thanks for the feedback & assistance
2019-12-04 15:22:12 <kaey> as for checkpath you can [ -n "$error_log" ] && checkpath and same for output_log
2019-12-04 15:33:37 <kaey> ddevault: config file should be owned by root
2019-12-04 15:33:59 <ddevault> isn't it?
2019-12-04 15:34:05 <ddevault> it's mode 644
2019-12-04 15:34:15 <ddevault> which matches everything in my conf.d
2019-12-04 15:34:54 <north1> ghc-8.8.1 failed on 3.11-x86_64
2019-12-04 15:35:14 <north1> 8.4.4*
2019-12-04 15:36:01 <kaey> i mean this line: checkpath -f "$prometheus_config_file" -m 740 -o prometheus:prometheus
2019-12-04 15:36:35 <ddevault> ah
2019-12-04 15:37:28 <_ikke_> north1: yes, I got that linker issues with newer versions of ghc and llvm as well
2019-12-04 15:37:32 <ddevault> hm, this line is weird
2019-12-04 15:37:36 <ddevault> I wonder why I put it here in the first place
2019-12-04 15:37:40 <_ikke_> I have no idea where those flags come form
2019-12-04 15:37:42 <_ikke_> from
2019-12-04 15:43:57 <mps> ddevault: when you are here, do you plan to upgrade stellarium, or if you don't have time ...
2019-12-04 15:44:07 <ddevault> hm, I guess I wasn't subscribed to its releases
2019-12-04 15:44:09 <ddevault> lemme get on top of that
2019-12-04 15:44:28 <ddevault> also, when my packages get marked outdated on pkgs.a.o, the email I get stays in my todo list and eventually gets done
2019-12-04 15:44:36 <mps> minor upgrade but looks interesting
2019-12-04 15:45:29 <ncopa> fredrigu: i think that recommends creates more problems than it solves
2019-12-04 15:45:44 <ncopa> mps: seems like crystal fails on aarch64 yes
2019-12-04 15:45:57 <fredrigu> ncopa: you might be right. What problems are you worried about?
2019-12-04 15:46:31 <mps> yes, it can be built but result is useles, crashes on nearly every invocation
2019-12-04 15:46:46 <mps> on x86_64 it works
2019-12-04 15:47:12 <ddevault> the lack of recommends in apk/alpine initially surprised me
2019-12-04 15:47:17 <ddevault> but now I don't really care, it's not that useful imo
2019-12-04 15:49:54 <mps> reason I use alpine is this, i.e. minimal dependecies (and no systemd)
2019-12-04 15:56:21 <north1> @ncopa can you take a look at this ? https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/11
2019-12-04 15:56:58 <north1> it just moves /usr/share/glade and /usr/lib/glade to -dev by default, i'd like it on 3.11
2019-12-04 16:04:22 <ncopa> which are the affected packages?
2019-12-04 16:04:33 <ncopa> do we need to rebuild some packages if we merge it?
2019-12-04 16:04:46 <north1> yes, libhandy, webkit2gtk
2019-12-04 16:04:54 <north1> any package that has /usr/lib/glade on the mainpkg
2019-12-04 16:05:25 <north1> strongly necessary to rebuild no, but while those glade libraries live in /usr/lib/glade the mainpkg will bring in libglade as a dependency unnecessarily
2019-12-04 16:05:45 <north1> https://gitlab.alpinelinux.org/alpine/aports/issues/11010
2019-12-04 16:05:56 <mps> ddevault: sorry for nitpicking again, but commit msg for new pkg should be 'new aport' and not 'new APKBUILD'
2019-12-04 16:06:22 <ncopa> what about glade itself?
2019-12-04 16:06:30 <ddevault> asdf
2019-12-04 16:06:34 <ddevault> just --amend it before you push?
2019-12-04 16:07:25 <north1> ncopa (IRC): libglade doesn't need it
2019-12-04 16:07:42 <ncopa> and what about /usr/lib/glade3?
2019-12-04 16:07:43 <north1> actually yes
2019-12-04 16:07:54 <north1> libglade won't but the package glade yes
2019-12-04 16:08:03 <mps> ddevault: ok
2019-12-04 16:08:07 <ncopa> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/11
2019-12-04 16:08:10 <north1> very confusing that there are 2 different but very similar packages
2019-12-04 16:08:23 <ncopa> sorry, wrong link
2019-12-04 16:08:27 <ncopa> https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fglade*&name=&branch=edge
2019-12-04 16:08:34 <ddevault> thanks mps
2019-12-04 16:09:00 <mps> ddevault: np :)
2019-12-04 16:10:39 <ncopa> looks like there are a significant about of packages that are affected by /usr/share/glade https://pkgs.alpinelinux.org/contents?path=%2Fusr%2Fshare%2Fglade%2A&page=2&branch=edge
2019-12-04 16:10:44 <north1> @ncopa Fedora keeps those in libgladeui
2019-12-04 16:11:32 <ncopa> im hesitant to do this right be fore this release. seems like there are significant number of packages that will be built differently if rebuilt (when applying security fixes)
2019-12-04 16:12:28 <north1> after page 3 until page 30 it is only glade and libxfce4ui-dev
2019-12-04 16:13:39 <north1> I restricted to /usr/share/glade/catalogs and usr/lib/glade/modules
2019-12-04 16:13:45 <north1> seems like what Debian does
2019-12-04 16:14:36 <north1> That leaves: libhandy, evolution, glade and libxfce4ui-dev for usr/lib/glade/modules
2019-12-04 16:14:58 <ncopa> can you include link to what debian and fedora does does in the issue?
2019-12-04 16:15:19 <north1> and adds: gitg, libpeas, libgweather and gtksourceview4 for usr/share/glade/catalogs
2019-12-04 16:15:22 <north1> ncopa (IRC): Sure
2019-12-04 16:17:24 <north1> done
2019-12-04 16:18:01 <mps> ddevault: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1870
2019-12-04 16:18:24 <mps> to test build on CI first
2019-12-04 16:19:18 <ddevault> aside: still working on CI support for lists.sr.ht
2019-12-04 16:19:27 <ddevault> https://github.com/libgit2/pygit2/pull/948 current step
2019-12-04 16:20:01 <mps> nice, when you finish this will save us some work and time
2019-12-04 16:20:42 <mps> heh, passed cleanly
2019-12-04 16:20:48 <_ikke_> ddevault: wondering, do you have multi-arch support?
2019-12-04 16:21:30 <ddevault> somewhat, but it's not production ready
2019-12-04 16:21:46 <ddevault> debian builds on aarch64+qemu are available
2019-12-04 16:21:46 <_ikke_> ok
2019-12-04 16:21:53 <ddevault> ppc64 hardware has been provisioned
2019-12-04 16:22:26 <mps> _ikke_: it is ok to push prometheus straight to community?
2019-12-04 16:23:12 <mps> it is useful pkg I know, but ask again because I'm not sure is that ok
2019-12-04 16:23:24 <mps> s/it is/is it/
2019-12-04 16:23:24 <alpine-meetbot> mps meant to say: is it useful pkg I know, but ask again because I'm not sure is that ok
2019-12-04 16:23:31 <mps> uhm
2019-12-04 16:23:54 <mps> algitbot: ignore me
2019-12-04 16:24:30 <mps> I meant to ask: is it ok to push prometheus straight to community?
2019-12-04 16:24:41 <_ikke_> if ddevault is confident enough that the package itself is working properly
2019-12-04 16:25:03 <mps> ddevault: ^
2019-12-04 16:25:53 <_ikke_> Perhaps test the package from CI (you can download it from there)
2019-12-04 16:26:04 <ddevault> said as much in the v1 patchset
2019-12-04 16:26:10 <ddevault> these packages are imported from my third-party repo
2019-12-04 16:26:14 <ddevault> they've been running in production for a while now
2019-12-04 16:26:19 <mps> _ikke_: already passed on out CI
2019-12-04 16:26:36 <mps> s/out/our/
2019-12-04 16:26:36 <alpine-meetbot> mps meant to say: _ikke_: already passed on our CI
2019-12-04 16:26:44 <ddevault> I've been meaning to upstream my packages but at my current pace of 0<n<1 per year it may take some time :P
2019-12-04 16:26:56 <mps> 
ACTION need coffee, obviously

2019-12-04 16:27:38 <mps> ok, will risk to be slapped by someone ;)
2019-12-04 16:28:43 <_ikke_> mps: yes, but I mean you can actually download the packages, install it on a system, and see that they are actually working
2019-12-04 16:29:01 <mps> from CI?
2019-12-04 16:29:04 <_ikke_> yes
2019-12-04 16:29:15 <mps> didn't know for this option
2019-12-04 16:30:03 <_ikke_> https://gitlab.alpinelinux.org/mps/aports/-/jobs/19951
2019-12-04 16:30:08 <_ikke_> there is a download button there
2019-12-04 16:30:45 <ddevault> thanks all
2019-12-04 16:31:45 <mps> ah, artifacts/download
2019-12-04 16:31:50 <_ikke_> yes, exactly
2019-12-04 16:32:06 <mps> good to remember
2019-12-04 16:35:24 <_ikke_> The reason we add packages to testing is that comitters can be less worried about submitting a new aport and give the submitted the chance to test it before it goes to a stable branch
2019-12-04 16:35:50 <_ikke_> s/submitted/submitter
2019-12-04 16:35:50 <alpine-meetbot> _ikke_ meant to say: The reason we add packages to testing is that comitters can be less worried about submitting a new aport and give the submitter the chance to test it before it goes to a stable branch
2019-12-04 16:36:42 <ddevault> mps: stellarium patches out
2019-12-04 16:38:12 <mps> ddevault: will look after coffee (and one brandy maybe :) )
2019-12-04 16:41:45 <ddevault> I should put on a pot too
2019-12-04 16:44:02 <north1> @ddevault !1871
2019-12-04 16:57:08 <north1> @ddevault stellarium is merged
2019-12-04 16:57:20 <north1> apparently it didn't went into the patches tab of sr.ht
2019-12-04 16:58:20 <ddevault> north1: thanks, made a note
2019-12-04 17:00:33 <mps> ah, north1 was faster than me
2019-12-04 17:04:49 <north1> :)
2019-12-04 17:05:14 <mps> he is robot :P
2019-12-04 17:05:31 <mps> north1: sorry for joke
2019-12-04 17:05:49 <north1> isok
2019-12-04 17:06:14 <mps> sometimes I think you never sleep
2019-12-04 17:06:44 <north1> Sometimes i don't
2019-12-04 17:06:46 <north1> sometimes == once a month
2019-12-04 17:07:29 <mps> ah :)
2019-12-04 17:08:10 <mps> no, joke aside, you probably have good tools
2019-12-04 17:08:36 <_ikke_> and time :)
2019-12-04 17:09:04 <mps> yes, time is something which I have less and less
2019-12-04 17:35:34 <mps> this !1814 is superseded by ea20a7ddaef1a04c17784a9986ad00d815231f37 I think
2019-12-04 17:36:35 <mps> prspkt is not here?
2019-12-04 18:02:17 <mps> to late to upgrade gnutls for 3.11?
2019-12-04 22:14:57 <Cogitri> I guess we can't upgrade to FF 71 just yet: https://www.reddit.com/r/voidlinux/comments/e5x5s3/comment/f9mgai1?context=3
2019-12-04 22:14:58 <alpine-meetbot> [REDDIT] firefox 71 crash (self.voidlinux) | 4 points (75.0%) | 4 comments | Posted by kodifies | Created at 2019-12-04 - 10:12:56UTC
2019-12-04 22:15:16 <Cogitri> They even locked the bug report so I guess it's something serious
2019-12-04 22:20:04 <mps> void managed to build 71.0 on musl?
2019-12-04 22:24:39 <Cogitri> I suppose so
2019-12-04 22:25:55 <mps> would be interesting how, I tried on aarch64 but failed
2019-12-04 22:37:28 <mps> kernel 5.4.2 is out
2019-12-04 22:40:14 <mps> hope ncopa will not forget disable EDAC_DEBUG and enable CONFIG_DM_INTEGRITY as module :)
2019-12-04 23:33:56 <mps> heh, firefox 71.0 building on aarch64, passed point of the previous fail, but can't wait to finish, time for bed
2019-12-04 23:34:13 <mps> hope tomorrow it will be ready
2019-12-05 00:39:17 <kpcyrd> in case somebody is following along, the graphs show the first few green packages https://tests.reproducible-builds.org/alpine/alpine.htmlhttps://tests.reproducible-builds.org/alpine/alpine.html
2019-12-05 00:41:13 <kpcyrd> we're at 13.1% reproducible right now and rapidly growing as the outdated results are being replaced
2019-12-05 05:20:47 <_ikke_> kpcyrd: that page returns a 404 for me
2019-12-05 07:03:04 <ncopa> morning
2019-12-05 07:03:11 <ncopa> its a doublepaste
2019-12-05 07:03:29 <Cogitri> Morning
2019-12-05 07:11:41 <mps> \o
2019-12-05 07:17:00 <north1> ncopa: morning, tagged you on a few old issues about enabling kernel config
2019-12-05 07:19:16 <mps> yes, I wrote here last night for 5.4.2 (released) about EDAC_DEBUG and CONFIG_DM_INTEGRITY
2019-12-05 07:19:47 <mps> Cogitri: firefox-71.0 running on my aarch64 :)
2019-12-05 07:20:39 <mps> !1885
2019-12-05 07:21:31 <mps> failed on x86_64 CI, but pass on lxc aarch64
2019-12-05 07:26:09 <Cogitri> Nice
2019-12-05 07:26:27 <Cogitri> But I'm wondering whether void did something odd or if we're just not enabling stack smashing protection
2019-12-05 07:27:30 <Cogitri> (Would take a look but Laptop is kind of dead.... again. Doesn't like to charge via usb-c anymore so I'll have to fetch an original charger somewhere)
2019-12-05 07:28:00 <ncopa> ghc-bootastrap is broken
2019-12-05 07:28:31 <ncopa> this commit broke it c40d12ef290bf0c25b033d179a34e32462cd1274
2019-12-05 07:28:44 <ncopa> i think we should not split out the -static, as its needed for bootstrap
2019-12-05 07:32:56 <mps> Cogitri: oh, again :(
2019-12-05 07:34:24 <mps> on my chromebook usb-c charging is only, no separate charging connector/adapter
2019-12-05 07:38:17 <north1> @ncopa anything blocking the glade changes on abuild ?
2019-12-05 08:25:23 <_ikke_> north1: the upcoming 3.11 release
2019-12-05 08:27:28 <ncopa> yeah, i dont want rebuild all packages with glade files before 3.11 release
2019-12-05 08:27:31 <ncopa> dont think its worth it
2019-12-05 08:27:48 <ncopa> i better spend time on fixing ghc and kernel
2019-12-05 08:28:39 <ncopa> re kernel config issues, can you please add label C-kernel to those
2019-12-05 08:28:53 <ncopa> so i dont miss them when looking at kernel config
2019-12-05 09:33:18 <nmeum> did 2f801fed8842d7a863feeac19b4f14066de1bb19 break unbound for anyone else as well? because my control socket is /var/run/unbound.sock and the start_pre changes introduced in the commit attempt to change the owner of /var/run (dirname of my control socket) to unbound:unbound then
2019-12-05 09:39:19 <ncopa> rnalrd, the logic when installing init.d/conf.d here is broken: 653c61b661708b8b92f1d38a3d90cffde6c7eda1
2019-12-05 09:40:32 <ncopa> $ doas rc-update --update 2>&1 | tpaste
2019-12-05 09:40:32 <ncopa> http://tpaste.us/gkZb
2019-12-05 09:42:15 <north1> ncopa: ill do when I sweep old issues again
2019-12-05 09:42:47 <ncopa> it installs the iscsi.conf into /etc/conf.d/
2019-12-05 10:04:32 <ncopa> thanks
2019-12-05 10:31:43 <_ikke_> ncopa: nice find re ghc
2019-12-05 11:18:28 <ncopa> _ikke_: im fixing the build-3-11-x86_64 now
2019-12-05 11:18:31 <ncopa> with ghc
2019-12-05 11:22:09 <nmeum> is there any timetable regarding the 3.11 release?
2019-12-05 11:22:23 <nmeum> i.e. any critical issues that need help / should be addressed before the release?
2019-12-05 11:24:42 <_ikke_> ncopa: thanks
2019-12-05 11:25:09 <_ikke_> ncopa: fyi: there is a PR on github open to upgrade ghc. I think they were stuck on the same issue
2019-12-05 11:25:50 <_ikke_> nmeum: all packages need to be built for 3-11. There are just a few left that are stuck. Once that's done, rc1 can be released
2019-12-05 11:28:24 <ncopa> i need move linux-lts to main
2019-12-05 11:28:28 <ncopa> fix ghc build
2019-12-05 11:28:41 <ncopa> fix rpi4 support
2019-12-05 11:28:55 <_ikke_> ncopa: I guess crystal still depends on llvm5?
2019-12-05 11:29:02 <ncopa> nmeum: jirutka posted a patch, which i dont think solve your issue
2019-12-05 11:29:09 <ncopa> pushed a patch*
2019-12-05 11:29:26 <_ikke_> ncopa: otherwise, if we would upgrade ghc, then llvm5 could be removed
2019-12-05 11:30:01 <ncopa> im interested in that
2019-12-05 11:30:12 <ncopa> there is a PR for ghc upgrade, but it is missint a patch for fixing testsuite
2019-12-05 11:30:30 <ncopa> we also need to fix crystal with llvm8 on aarch64
2019-12-05 11:30:31 <_ikke_> that patch is in master already?
2019-12-05 11:31:06 <nmeum> ncopa: yeah, saw that patch. I don't think it fixes it either because the socket doesn't exist in start_pre but didn't manage to test it yet
2019-12-05 11:31:08 <ncopa> no, it is a patch which is referenced in the APKBUILD but J0WI forgot to `git add fix-testsuite.patch` when commiting
2019-12-05 11:31:21 <_ikke_> ncopa: ah, ok, thanks. I'll update the PR
2019-12-05 11:31:35 <ncopa> _ikke_: i think i mentioned it in the PR
2019-12-05 11:31:46 <_ikke_> ok
2019-12-05 11:31:49 <_ikke_> yes
2019-12-05 11:31:49 <ncopa> nmeum: yeah, i can reproduce it
2019-12-05 11:31:56 <nmeum> speaking of J0WI: do we want to merge https://github.com/alpinelinux/aports/pull/12170 before 3.11? should likely make the busybox build reproducible
2019-12-05 11:32:02 <nmeum> or at least "more reproducible"
2019-12-05 11:32:09 <ncopa> i dont know why he needs to make unbound the owner of the socket dir
2019-12-05 11:32:17 <nmeum> I don't get it either
2019-12-05 11:32:41 <nmeum> he is making the startup logic unessecarly more complicated than it needs to be
2019-12-05 11:34:31 <ncopa> nmeum: feel free to reopen the issue
2019-12-05 11:34:51 <nmeum> will test it first and repoen it then
2019-12-05 11:34:52 <nmeum> )
2019-12-05 11:35:09 <nmeum> gimme a sec
2019-12-05 11:40:29 <nmeum> yep, doesn't work because /var/run is cleared on reboot and the sock file doesn't exist then and checkpath is invoked again
2019-12-05 11:40:34 <nmeum> I will repoen the issue
2019-12-05 11:41:09 <_ikke_> nmeum: I'm testing J0WI's PR right now
2019-12-05 11:41:12 <_ikke_> ncopa: *
2019-12-05 11:42:33 <north1> When can i push to master without getting into the path of 3.11?
2019-12-05 11:43:09 <_ikke_> north1: Only after 3.11 is released
2019-12-05 11:43:22 <_ikke_> then 3.11 is branched off
2019-12-05 11:43:26 <north1> bummer
2019-12-05 11:44:52 <nmeum> I use a local staging branch with changes I want to push after the release
2019-12-05 11:46:39 <ncopa> hehe
2019-12-05 11:46:42 <ncopa> that is intentional
2019-12-05 11:46:53 <ncopa> so we all focus on getting the release out
2019-12-05 11:47:18 <ncopa> nmeum: looks like also nsd may suffer from same problem
2019-12-05 11:47:30 <nmeum> yes it does
2019-12-05 11:48:17 <nmeum> should probably be fixed before 3.11 is released
2019-12-05 12:03:13 <mps> _ikke_: ncopa: crystal built with llvm8 on aarch64 is useles, it doesn't work
2019-12-05 12:04:04 <nmeum> upstream actually recommends using llvm8 though https://crystal-lang.org/install/from_sources/
2019-12-05 12:04:09 <nmeum> >
2019-12-05 12:04:09 <nmeum> Make sure a supported LLVM version is present in the path. When possible, use the latest supported version: 8.0.
2019-12-05 12:04:33 <mps> can compile simple programs but anything longer than 10 lines fail, I tested just few and not too much, but that is enough
2019-12-05 12:05:00 <mps> nmeum: it builds with llvm8 and works on x86_64
2019-12-05 12:05:09 <nmeum> ah
2019-12-05 12:05:21 <mps> it builds on aarch64 with llvm8 but doesn't work
2019-12-05 12:06:38 <mps> nmeum: !508
2019-12-05 12:08:45 <mps> I talked with _ikke_ few days ago about crystal, maybe we should disable aarch64 and build only x86_64, but I wouldn't decide about that. left to maintainer (jirutka) or ncopa
2019-12-05 12:09:43 <mps> but must add, crystal on aarch64 built with llvm5 works fine
2019-12-05 12:09:59 <nmeum> ghc and crystal are the only packages still using llvm5, if only enabling crystal on x86_64 would allow us to remove llvm5 with 3.11 that would certianly be worth it imho
2019-12-05 12:10:06 <nmeum> *only
2019-12-05 12:10:13 <ncopa> +1
2019-12-05 12:10:22 <ncopa> i think we have ghc fixed
2019-12-05 12:10:28 <ncopa> so its only crystal left
2019-12-05 12:10:45 <ncopa> crystal builds with llvm8 on x86_64 but not aarch64
2019-12-05 12:10:48 <mps> ball is in your hands
2019-12-05 12:11:31 <ncopa> i sent the ball to the maintainer: https://gitlab.alpinelinux.org/alpine/aports/issues/11017
2019-12-05 12:13:04 <mps> also we will have to remove shards, ameba and oq, pkgs depends on crystal
2019-12-05 12:13:43 <mps> s/remove/disable on aarch64/
2019-12-05 12:13:43 <alpine-meetbot> mps meant to say: also we will have to disable on aarch64 shards, ameba and oq, pkgs depends on crystal
2019-12-05 12:13:50 <ncopa> yeah
2019-12-05 12:14:18 <ncopa> i think it may we worth it
2019-12-05 12:14:31 <ncopa> lets do ghc first and see how that goes
2019-12-05 12:14:45 <mps> (I tend to agree, but psshhh ...)
2019-12-05 12:14:54 <_ikke_> ghc is still building for me
2019-12-05 12:15:12 <ncopa> with j0wi's patch?
2019-12-05 12:15:23 <_ikke_> not yet
2019-12-05 12:15:36 <ncopa> im building it with j0wi's patches
2019-12-05 12:15:42 <_ikke_> ok
2019-12-05 12:15:53 <ncopa> im hopeful
2019-12-05 12:17:25 <mps> oh to not forget, dovecot 2.8.9 release looks like 'security' fix although it is not announced as such, would be good to upgrade it for 3.11, imo
2019-12-05 12:20:21 <_ikke_> ncopa: for me it failed
2019-12-05 12:20:45 <_ikke_> test failures, but quite a few
2019-12-05 12:31:52 <nmeum> I have a fix for ocaml-lablgtk, should allow us to build unison again
2019-12-05 12:36:58 <nmeum> now unison itself fails, nice
2019-12-05 12:38:54 <_ikke_> hah
2019-12-05 12:39:09 <nmeum> seems to be a known upstream issue this time https://github.com/bcpierce00/unison/issues/277
2019-12-05 12:39:44 <_ikke_> hopefully with a fix? :P
2019-12-05 12:40:16 <_ikke_> seems to be fixed in master
2019-12-05 12:40:36 <nmeum> yes
2019-12-05 12:40:45 <nmeum> not sure how easy it will be to backport the neccessary changes though
2019-12-05 12:47:08 <nmeum> backported the compatibility commit linked in the github issue above
2019-12-05 12:47:27 <nmeum> fails with `Error: /usr/lib/ocaml/lablgtk2/pango.cmi: is not a compiled interface for this version of OCaml.` now, maybe ocaml-lablgtk2 needs a rebuild?
2019-12-05 12:47:31 <nmeum> (i don't speak ocaml)
2019-12-05 12:54:48 <ncopa> i think lablgtk2 needs to be rebuilt with ocaml 4.08
2019-12-05 12:54:53 <mps> ncopa: are you working on linux-lts or if you busy I can prepare some things from issue reports
2019-12-05 12:55:12 <ncopa> i was about to tart with the linux-lts now
2019-12-05 12:55:12 <nmeum> ncopa: looks like it, with the rebuild unison builds fine https://gitlab.alpinelinux.org/nmeum/aports/pipelines/3219
2019-12-05 12:55:24 <nmeum> will merge my unison fix in a sec
2019-12-05 12:55:46 <north1> ocaml likes all packages compiled against the same compiler
2019-12-05 12:55:58 <nmeum> well, that's annoying
2019-12-05 12:56:56 <ncopa> mps: looks like im gonna be busy with some other things for another hour or so
2019-12-05 12:58:37 <mps> ok, I will prepare upgrade and post it somewhere, will not push
2019-12-05 13:03:44 <_ikke_> ncopa: how is your ghc build doing?
2019-12-05 13:14:15 <nmeum> shouldn't it be possible to extend abuild with a check where it doesn't build a package if the dependency are not available on the current architecture? would make it unnecessary to add explicit !$arch statements to the arch variable everytime
2019-12-05 13:19:11 <north1> I prefer that it fails instead of silently succeeding
2019-12-05 13:23:07 <nmeum> the downside is that it creates unnecessary work load (i.e. during a new release) and that the !$arch statements are not automatically updated if the dependency becomes available on $arch
2019-12-05 13:24:57 <north1> Yes but the side effect is that we silently introduce new packages or make packages unavailable on a whim without proper feedback
2019-12-05 13:25:22 <Cogitri> nmeum: How would we enable a package once a dep becomes available then though?
2019-12-05 13:25:26 <Cogitri> Should abuild scan the entire tree on every build to check that?
2019-12-05 13:27:30 <Cogitri> If we had to manually revbump the package at that point it wouldn't really be easier for devs (and easier to forget) and users on other arches would have to download the package again for no reason
2019-12-05 13:48:24 <ncopa> _ikke_: lots of test failures
2019-12-05 13:49:35 <ncopa> i agree with north1, but we should have better tools to detect and deal with it
2019-12-05 13:51:12 <north1> Can probably be added to atools
2019-12-05 13:51:54 <walbon> ncopa: well, I saw a commit from Soren into ocaml-labgtk and the build using edge repositories worked well on powerpc.
2019-12-05 13:52:23 <nmeum> *sören
2019-12-05 13:54:01 <walbon> nmeum: sorry, I have to learn to use ö in mey keyboard
2019-12-05 13:54:18 <nmeum> (: np
2019-12-05 14:00:26 <north1> mesa 19.2.7 is gonna be lit
2019-12-05 14:01:14 <north1> ncopa (IRC): I can add a 1-depth check on *depends of an APKBUILD that checks if a package depends on another package that is not available  in that arch
2019-12-05 14:02:06 <_ikke_> north1: maybe use lua-aports
2019-12-05 14:02:35 <_ikke_> north1: it's very fast in reading aports
2019-12-05 14:02:46 <north1> i have no clue how to use lua-aports
2019-12-05 14:02:53 <north1> :D you know atools and lua-aports
2019-12-05 14:02:58 <_ikke_> yup
2019-12-05 14:03:08 <clandmeter> _ikke_: knows all
2019-12-05 14:03:15 <clandmeter> he even knows what im about to type
2019-12-05 14:05:34 <_ikke_> gmta
2019-12-05 14:13:37 <mps> there is no config-lts.armhf in testing/linux-lts. I this sign that we will not release armhf
2019-12-05 14:13:58 <clandmeter> isnt that discussed already?
2019-12-05 14:14:17 <clandmeter> lts would not ship armhf, only with rpi images/kernels
2019-12-05 14:15:47 <mps> ok
2019-12-05 14:16:38 <clandmeter> users that have armv6 hardware with hard float will probably build the kernel themselves.
2019-12-05 14:17:31 <_ikke_> how?
2019-12-05 14:17:32 <mps> or, didn't tested but maybe armv7 kernel could work for them
2019-12-05 14:18:08 <clandmeter> _ikke_: probably build it cross
2019-12-05 14:18:28 <clandmeter> or else on armv6 hw :)
2019-12-05 14:18:44 <clandmeter> or like we do on faster
2019-12-05 14:19:27 <clandmeter> armv6 are mostly small devices, you probably dont want our large multipurpose kernel.
2019-12-05 14:47:53 <telmich> if I want to create a ticket for tracking IPv6 support in the install media - against which repo should I create an issue?
2019-12-05 15:23:11 <mps> (uhm, my x86_64/x86 builder is fast like a snail)
2019-12-05 15:37:30 <clandmeter> telmich: install media?
2019-12-05 15:38:16 <clandmeter> if you are usure, create an issue in aports tracker.
2019-12-05 15:38:22 <clandmeter> we can move it later if needed.
2019-12-05 16:12:27 <ncopa> mps: do you have patch for kernel upgrade?
2019-12-05 16:12:45 <ncopa> otherwise I'll update it myself, and move it to main
2019-12-05 16:12:59 <ncopa> and apply the other changes
2019-12-05 16:16:15 <mps> I have diff but not yet finished with -virt.x86_64, building I mean to if it works
2019-12-05 16:17:03 <mps> tested on armv7 and aarch64, looks ok
2019-12-05 16:17:44 <ncopa> git diff | tpaste
2019-12-05 16:18:18 <ncopa> or: git commit && git format-patch -1 | tpaste
2019-12-05 16:19:12 <mps> http://tpaste.us/8XbK
2019-12-05 16:19:23 <mps> format-patch
2019-12-05 16:20:17 <mps> look at CMA addition, I set default values, if you think this is not ok, remove or change
2019-12-05 16:21:28 <mps> anyway you will probably have to tweak some things according your preferences
2019-12-05 17:04:45 <mps> ncopa: I forgot 'git rm x86-fpu-Dont-cache-access-to-fpu_fpregs_owner_ctx.patch' for kernel patch
2019-12-05 17:05:05 <telmich> good evening
2019-12-05 17:05:47 <telmich> it seems the ENABLE_FEATURE_PREFER_IPV4_ADDRESS in busybox is causing non-working IPv6 environments. Is there any opinion on whether to keep it or would it be ok to create an MR removing it?
2019-12-05 17:05:54 <telmich> Context: https://gitlab.alpinelinux.org/alpine/aports/issues/10937
2019-12-05 17:06:09 <mps> finally finished building both x86_64 linux-lts and linux-virt, time to clean dust from my i7 notebook
2019-12-05 17:06:58 <telmich> mps: I find it quite funny that over all those years, kernel compile time never decreased, even though the hardware is getting much faster...
2019-12-05 17:07:59 <mps> telmich: heh, remember time when built it on 4MB (MB, really) and put it to work overnight :)
2019-12-05 17:11:14 <telmich> mps: I've to confess I only started building around the early 2.x series, afair the computer already had 32-128MB RAM at that time
2019-12-05 17:15:20 <mps> I forgot exact version with which started to built it, but remember it was 1.x where x was low number
2019-12-05 17:23:55 <telmich> ...reminds me of the really bad 2.5 times
2019-12-05 17:24:00 <telmich> every 2nd kernel was roughly broken
2019-12-05 17:26:47 <mps> and now is much difference ? :)
2019-12-05 17:28:32 <telmich> maybe every 10th to 15th now :-)
2019-12-05 17:32:52 <mps> well, -rc's kernel can make a real mess
2019-12-05 18:07:55 <telmich> one thing I've seen on multiple notebooks now is that syslinux with efi hangs at boot
2019-12-05 18:08:07 <telmich> replacing it with grub-efi works w/o any problems though
2019-12-05 18:09:17 <telmich> I guess syslinux was chosen for a good reason to be the default, but maybe I should add a pointer in the wiki to that problem, because it bit me at least three times so far
2019-12-05 18:11:09 <mps> telmich: if you boot install media on efi enabled machine it will by default install grub-efi
2019-12-05 18:11:42 <telmich> mps: I cannot confirm that; I am 95% sure that some hours ago the installer did not install grub-efi
2019-12-05 18:12:08 <telmich> Because I did apk add it later and it was not installed; neither was efibootmgr
2019-12-05 18:12:16 <mps> maybe not fully functional efi on machine
2019-12-05 18:12:34 <telmich> it did have efivars and efibootmgr did show the regular output
2019-12-05 18:12:54 <telmich> mps: if you want to, I can give you access to the machine, it's the mpd player of the hacking hotel
2019-12-05 18:13:02 <mps> in a last few installation I always got grub-efi
2019-12-05 18:14:04 <mps> even in qemu if efi.fd file is given as -bios parameter
2019-12-05 18:14:10 <telmich> it's quite an ancient machine from asus (~7-9 years old), but already with efi, so an early version or incomplete might be a good guess
2019-12-05 18:14:59 <mps> I have one such, has efi in bios but didn't worked, 5 or more years old notebook
2019-12-05 18:16:03 <mps> but another one bought at the same time efi works 'out of the box'
2019-12-05 18:16:58 <mps> also one old macbook (about 2012/2014) efi worked, alpine install
2019-12-05 19:26:52 <clandmeter> If you boot with EFI installer will use grub efi
2019-12-05 19:29:21 <mps> clandmeter: yes, that is my experience
2019-12-05 19:32:38 <clandmeter> I added it so I'm kind of sure it works like that ;)
2019-12-05 19:33:28 <mps> I remember :)
2019-12-05 19:50:44 <mps> when we are talking about installer, for some time thinking to ask someone with shell scripting knowledge to extend it with options to select size of swap and root fs
2019-12-05 20:28:37 <_ikke_> https://seclists.org/oss-sec/2019/q4/122
2019-12-05 20:31:36 <fassl> got some makefile/shell thing, but it uses lvm, i can link it to you if you want mps
2019-12-05 20:32:30 <mps> rp_filter is in kernel for reason
2019-12-05 20:33:56 <mps> fassl: thanks, I would prefer it to be in default installer on alpine
2019-12-05 20:35:03 <fassl> the installer being setup-alpine?
2019-12-05 20:35:10 <mps> yes
2019-12-05 20:36:19 <mps> we can do manually do this tweaks of setting disk layout and size of FS, but would be nice to have this as default option in setup-alpine
2019-12-05 20:36:39 <fassl> yep, i would prefer that as well
2019-12-05 21:44:15 <ncopa> mps: I think you can set swap size for installer
2019-12-05 21:44:28 <ncopa> export SWAP_SIZE=....
2019-12-05 21:44:30 <ncopa> or similar
2019-12-05 21:46:35 <clandmeter> ncopa: reminds me, there is no way to set the size of root fs on lvm?
2019-12-05 21:52:05 <ncopa> seems so yes
2019-12-05 21:52:24 <ncopa> 100%FREE is hardcoded
2019-12-05 21:52:30 <ncopa> but thats esy to fix
2019-12-05 21:52:38 <clandmeter> i guess a custom setup-disk is needed for now.
2019-12-05 21:53:04 <ncopa> I can change it to ${ROOTFS_SIZE:-100%FREE}
2019-12-05 21:53:37 <clandmeter> ok, i guess thats used for normal partitions?
2019-12-05 21:56:06 <ncopa> http://tpaste.us/6VEB
2019-12-05 21:56:14 <ncopa> for lvcreate
2019-12-05 21:56:24 <clandmeter> yes i know the hardcoded part
2019-12-05 21:56:38 <clandmeter> i bumped into it :)
2019-12-05 21:58:43 <mps> export SWAP_SIZE=... before starting setup-alpine?
2019-12-05 21:59:06 <ncopa> yes
2019-12-05 21:59:12 <ncopa> looks like its MB
2019-12-05 21:59:29 <mps> export SWAP_SIZE=0 ? no swap?
2019-12-05 21:59:35 <ncopa> correct
2019-12-05 22:00:35 <mps> aha, waiting for ${ROOTFS_SIZE:xxG} :)
2019-12-05 22:01:26 <mps> btw, I finally got '5.4.2-0-lts #1-Alpine SMP Thu, 05 Dec 2019 13:22:25 UTC x86_64 GNU/Linux'
2019-12-05 22:01:33 <ncopa> nice
2019-12-05 22:01:40 <ncopa> i didnt have tim to look at you patch
2019-12-05 22:01:49 <ncopa> will do it tomorrow morning
2019-12-05 22:01:50 <ncopa> sorry
2019-12-05 22:02:26 <mps> my current workstation is so slow, in meantime I clean my i7 box and making build machine from it
2019-12-05 22:02:40 <ncopa> on the other had, my contract with Docker was terminated today
2019-12-05 22:02:49 <ncopa> and I signed a contract with Mirantis
2019-12-05 22:02:55 <mps> no need to sorry, better to have it in good shape than fast
2019-12-05 22:03:07 <clandmeter> congrats
2019-12-05 22:03:15 <ncopa> thanks!
2019-12-05 22:03:24 <clandmeter> when do i receive cake?
2019-12-05 22:03:26 <mps> Mirantis? first time hear for this
2019-12-05 22:03:44 <clandmeter>  i have the wine already from mps :)
2019-12-05 22:05:27 <mps> https://www.mirantis.com/ ?
2019-12-05 22:05:30 <clandmeter> mps: its the company that bought the commercial side of docker
2019-12-05 22:05:58 <mps> oh, so alpine goes commercial :D
2019-12-05 22:06:20 <clandmeter> docker was already commerial
2019-12-05 22:06:34 <clandmeter> nothing changes regading that part.
2019-12-05 22:07:46 <mps> clandmeter: did you notice ':D' in my msg
2019-12-05 22:08:38 <mps> joke aside, congrats ncopa :)
2019-12-05 22:23:24 <ncopa> thanks
2019-12-05 22:23:28 <ncopa> and good night!
2019-12-05 22:31:00 <mps> \o
2019-12-05 22:59:32 <andypost[m]> Filed security upgrade for putty !1911 maybe move it to community?
2019-12-05 23:00:51 <mps> there are more candidates to move from main to community, imo
2019-12-05 23:01:13 <mps> but maybe after 3.11 release
2019-12-06 04:40:40 <kaniini> does swish-e even build
2019-12-06 04:41:00 <kaniini> it is making entirely bogus call to zlib uncompress2()
2019-12-06 04:41:09 <kaniini> perhaps this is a shadowing issue
2019-12-06 04:42:03 <kaniini> yes, it is
2019-12-06 04:49:47 <kaniini> ...this package needs some love
2019-12-06 04:49:56 <kaniini> it does not build with system expat library
2019-12-06 04:56:31 <kaniini> http://tpaste.us/9Nb0
2019-12-06 04:56:34 <kaniini> somebody apply this
2019-12-06 05:11:48 <north1> Is it urgent?
2019-12-06 05:17:40 <kaniini> i mean, right now the package fails to build
2019-12-06 05:19:34 <north1> Blocking the builders?
2019-12-06 05:20:10 <maldridge> greetings all, I'd like to know if there's opposition to moving nscd to community/ and re-linking samba against it.  Right now samba uses some internal headers which don't actually work and  as such needs to be re-built by any downstream consumer wanting to use its winbind services.
2019-12-06 05:21:12 <kaniini> north1: no, because the package has not been rebuilt in years
2019-12-06 05:21:24 <kaniini> north1: it does block anyone trying to rebuild alpine from scratch
2019-12-06 05:21:51 <north1> kaniini: I'll take a look in a few hours
2019-12-06 05:22:11 <kaniini> okay
2019-12-06 05:22:13 <kaniini> that is cool
2019-12-06 05:23:35 <kaniini> north1: however, it is probably urgent that swish-e get rebuilt anyway, the package is likely not working anyway
2019-12-06 05:23:42 <kaniini> alternatively we could just drop swish-e
2019-12-06 05:23:46 <kaniini> i really do not care what we do
2019-12-06 05:29:54 <kaniini> there is no rush i guess, considering  my builder options are shit, shit, and qemu-user (which apparently needs some signal-handling fixes for go applications)
2019-12-06 05:41:08 <kaniini> i am half tempted to just start rebuilding the entirety of alpine from scratch every 6 hours until all FTBFS issues are fixed permanently
2019-12-06 05:41:26 <kaniini> for x86 and ppc64 it is no problem for me to do this
2019-12-06 05:54:56 <maldridge> kaniini: I do something like that once a month for void
2019-12-06 05:55:08 <maldridge> though I don't often have the time/energy to follow up on ftbfs
2019-12-06 05:57:09 <_ikke_> what is ftbfs?
2019-12-06 05:57:24 <maldridge> Fails To Build From Source
2019-12-06 06:00:09 <kaniini> finally i am fixing an FTBFS that has to do with mips64 again.
2019-12-06 07:16:44 <north1> aight i'm back
2019-12-06 07:17:40 <north1> Need testers for the new stuff and the removed stuff on mesa !1898
2019-12-06 07:52:17 <ncopa> north1: removal of gles1 sounds scary at this point
2019-12-06 07:52:22 <ncopa> is there not anything that uses it?
2019-12-06 07:52:53 <north1> Both fedora and arch remove it and everything o saw including raspis use gles2
2019-12-06 07:56:22 <ncopa> $ apk search  --exact --quiet --origin --rdepend so:libGLESv1_CM.so.1 | sort -u | tpaste
2019-12-06 07:56:22 <ncopa> http://tpaste.us/Xg0l
2019-12-06 07:56:28 <ncopa> those needs to be rebuilt
2019-12-06 08:00:31 <north1> Need to remove those that match so:libGLESv2
2019-12-06 08:00:45 <north1> wlroots only links to libGLESv2
2019-12-06 08:02:03 <ncopa> i may have some old index or old packages locally
2019-12-06 08:02:25 <north1> wlc , weston, wayfire and mutter as well
2019-12-06 08:02:36 <ncopa> i also think that if we are sure main and community is ok, then I think you can push
2019-12-06 08:02:43 <ncopa> and we can clean up testing afterwards
2019-12-06 08:02:56 <ncopa> testing repo has lower prio til 3.11 is out
2019-12-06 08:06:28 <north1> ok, i did apk info --depends on each one of them and none showed libGLESv1_CM.so.1
2019-12-06 08:06:32 <north1> only libGLESv2.so.1
2019-12-06 08:07:39 <north1> http://ix.io/23FA
2019-12-06 08:16:03 <ncopa> ok, i gues you can push it then
2019-12-06 08:16:54 <north1> It also has other minor changes
2019-12-06 08:20:13 <ncopa> mps: i'm building the 5.4.2 kernel now
2019-12-06 08:20:43 <ncopa> i need to be afk most of today, but i'll try to push it later today
2019-12-06 08:20:55 <ncopa> just need to make sure it builds and boots (in qemu)
2019-12-06 08:21:53 <mps> I tested x86_64, aarch64, and one armv7. boots ok and work
2019-12-06 08:22:36 <mps> armv7 will need other tweaks, but not urgent now
2019-12-06 08:52:07 <ncopa> Didn’t reach to do it before I went out. Will have to wait til I’m back home 😔
2019-12-06 09:06:20 <mps> if I finish setting my old/new building box I will check more options
2019-12-06 09:07:42 <mps> (need AI OS which will read my minds and work all I think, so I can go to skiing)
2019-12-06 10:19:44 <mps> hmm, linux-vanilla and linux-lts for armv7 'conflicts' on /boot/dtbs files
2019-12-06 10:21:36 <mps> we need separate dirs for them, or versioned dtbs-'uname -r'
2019-12-06 11:12:44 <Cogitri> Hey, can I still move some GNOME stuff from testing to community? 😅
2019-12-06 11:31:26 <_ikke_> Cogitri: Should be
2019-12-06 11:33:25 <Cogitri> Alrighty, thanks
2019-12-06 12:13:12 <mps> Cogitri: iio-sensor-proxy depends on gtk?
2019-12-06 12:13:32 <mps> i.e. could it be built without gtk
2019-12-06 12:14:40 <Cogitri> It only needs gtk for its tests, it doesn't depend on it during runtime
2019-12-06 12:14:56 <Cogitri> But I can't add it to checkdepends because it's always checking for it :)
2019-12-06 12:15:10 <mps> aha, thanks. np
2019-12-06 12:16:08 <mps> just ask because I have in memory (maybe fading) there was/is iio-sensor-proxy without glib/gtk deps
2019-12-06 12:16:10 <Cogitri> Uhh...is `arch=noarch !s390x` valid?
2019-12-06 12:16:29 <Cogitri> (don't mind the missing quotes)
2019-12-06 12:17:05 <Cogitri> Somehow I had thought I'd need to do `arch="all !s390"` if I want to disable one arch even if the package doesn't contain any arch dependant binaries
2019-12-06 12:17:37 <mps> there are packages with such arch var
2019-12-06 12:18:10 <mps> though, I'm not sure
2019-12-06 12:19:41 <ncopa> I think it’s valid
2019-12-06 12:20:29 <Cogitri> Hm, good to know, I always changed `noarch` to `all !$failingArch` because I thought it's invalid
2019-12-06 12:21:25 <mps> makes sense if arch is 'noarch' but pkg don't need to be in '!arch'
2019-12-06 12:22:09 <ncopa> Some of the reps may be arch dependent
2019-12-06 12:22:18 <ncopa> deps
2019-12-06 12:23:07 <mps> ncopa: quick question, when you move linux-lts to main, name will be linux-lts, i.e. not changed?
2019-12-06 12:25:15 <Cogitri> How long do we keep buildlogs? I want to link to a build log to reason why I disabled s390x for py3-argon2-cffi but that's not useful if the URL is only valid for a little
2019-12-06 12:27:46 <_ikke_> There is no scheduled removal
2019-12-06 12:27:55 <_ikke_> so only when the drive is full logs get purged
2019-12-06 12:28:06 <_ikke_> logs for failed builds will get overwritten on each build
2019-12-06 12:28:39 <Cogitri> Okie. Thanks for the info
2019-12-06 12:30:58 <mps> Cogitri: yes, rust failed on CI for firefox but worked on lxc
2019-12-06 12:31:13 <Cogitri> SIGSEGV?
2019-12-06 12:31:55 <mps> I forgot, there is log on gitlab.a.o for firefox-71.0
2019-12-06 12:32:05 <mps> not now at workstation
2019-12-06 12:33:22 <Cogitri> Okie, will take a look later
2019-12-06 12:34:18 <mps> I'm preparing x86_64 builder locally, need some eth cables and set another switch
2019-12-06 12:35:43 <Cogitri> Nice, gtk4 fails to build on x86 because it runs out of VMEM
2019-12-06 12:36:12 <mps> heh, and it is not written in rust
2019-12-06 12:36:33 <Cogitri> I think we've mostly hit that limitation with big CPP stuff as of now :P
2019-12-06 12:37:11 <mps> C++ :(
2019-12-06 13:12:45 <ncopa> mps: correct
2019-12-06 13:19:16 <mps> ncopa: iiuc, linux-vanilla will be moved to testing or community with different name, or it will stay -vanilla
2019-12-06 13:19:57 <mps> I'm asking to fix /boot/dtbs if the user wants to install different kernels
2019-12-06 13:25:07 <ncopa> im not sure we want keep linux-vanilla
2019-12-06 13:26:03 <_ikke_> Wasn't there a plan to have a more up-to-date kernel in community?
2019-12-06 13:26:51 <ncopa> it is an option, yes, but im not sure we (I) have resources to maintain another kernel
2019-12-06 13:26:57 <_ikke_> ok
2019-12-06 13:27:04 <mps> ok, it is not important now how it will be called
2019-12-06 13:28:19 <ncopa> i guess the question is if we want support multiple kernels installed at the same time for arm*/aarch64
2019-12-06 13:28:26 <mps> just want to fix 'conflict' for /boot/dtbs if we have two different kernels installable at the same time
2019-12-06 13:29:20 <mps> then we cannot have /boot/dtbs in both
2019-12-06 13:30:03 <Cogitri> I'd personally love to have a linux-lts and a linux-current (or similiar) and if it's in community I could maintain that - unsure what arches we'd want to target tho
2019-12-06 13:30:23 <mps> maybe /boot/dtbs-lts and /boot/dtbs-xyz, xyz is the name of the other kernel
2019-12-06 13:30:53 <mps> kernel flavour, I mean
2019-12-06 13:31:25 <ncopa> im also thinking we may want be able to have different  configs, like -virt and -lts
2019-12-06 13:31:41 <ncopa> and maybe -server and -desktop or similar
2019-12-06 13:31:53 <Cogitri> I don't see much of a point in that tbh
2019-12-06 13:32:19 <ncopa> or -debug
2019-12-06 13:32:20 <odc> -lowlatency ;)
2019-12-06 13:32:29 <Cogitri> Sounds like a lot of maintenance effort only to save a few MB on a server
2019-12-06 13:32:35 <mps> we don't have resources (for now at least) for many kernels
2019-12-06 13:32:42 <ncopa> yes and yes
2019-12-06 13:32:48 <Cogitri> And if you need to debug a kernel you're most likely better of building it yourself anyway
2019-12-06 13:32:58 <mps> Cogitri: +1
2019-12-06 13:33:03 <ncopa> but i think it would be useful to be able to install different kernels at the same time
2019-12-06 13:33:10 <mps> and for rest of pkgs :)
2019-12-06 13:33:13 <Cogitri> Yes. Very much so
2019-12-06 13:33:29 <Cogitri> If only so that you have something to boot from in case one kernel goes bad on an update
2019-12-06 13:33:37 <ncopa> so i think it makes sense to fix the /boot/dtbs problem
2019-12-06 13:33:41 <mps> meant for Cogitri 'for rest of pkgs :)'
2019-12-06 13:33:44 <Cogitri> Yup
2019-12-06 13:34:01 <mps> now we can have vanilla and lts
2019-12-06 13:34:07 <mps> works fine
2019-12-06 13:34:36 <mps> both installed at same time and selectable at boot time
2019-12-06 13:35:18 <Cogitri> Yup, just that I'd like to have -vanilla be -current
2019-12-06 13:35:38 <ncopa> could maybe even be in testing repo
2019-12-06 13:35:57 <Cogitri> Hm, I'd like to use it in 3.12 actually on my NAS
2019-12-06 13:36:05 <mps> testing sounds better for evolving kernels
2019-12-06 13:36:11 <Cogitri> (Which currently still runs edge for a dew pkgs)
2019-12-06 13:36:27 <Cogitri> Hm, I wouldn't call linux-current evolving
2019-12-06 13:37:00 <ncopa> if we have it in community we´ll have to backport sec fixes
2019-12-06 13:37:01 <mps> well, current is not good name, imo
2019-12-06 13:37:18 <mps> yes
2019-12-06 13:37:29 <Cogitri> ncopa: Oh right, didn't consider that
2019-12-06 13:37:33 <Cogitri> Testing sounds good to me then :P
2019-12-06 13:37:35 <mps> testing looks better place
2019-12-06 13:38:08 <mps> we will have -lts in main and 'whatever' in testing
2019-12-06 13:38:19 <Cogitri> Yup
2019-12-06 13:38:29 <mps> for now this looks best we can do for now
2019-12-06 13:38:33 <Cogitri> What kernel modules are we going to build for it? Wireguard & ZFS?
2019-12-06 13:38:45 <mps> 2 times 'for now' :)
2019-12-06 13:38:46 <_ikke_> gtk4.0 is current failing
2019-12-06 13:39:01 <Cogitri> Yes, looking into it
2019-12-06 13:39:11 <Cogitri> <Cogitri "Nice, gtk4 fails to build on x86"> ^
2019-12-06 13:39:13 <mps> Cogitri: yes, and sdfat, dahdi ...
2019-12-06 13:39:24 <_ikke_> ah, missed that
2019-12-06 13:39:29 <mps> something called 'jool...'
2019-12-06 13:39:46 <ncopa> i´d prefer note have any 3rd party modules if possible
2019-12-06 13:40:29 <mps> but you wouldn't drop them without thinking, I think
2019-12-06 13:40:31 <ncopa> but then we´d probably need dkms or similar
2019-12-06 13:40:47 <Cogitri> Yup, then we'd need dkms which is kind of a pain too
2019-12-06 13:40:57 <Cogitri> And without zfs the kernel would be kind of useless to me at least
2019-12-06 13:41:40 <ncopa> so i dont think dropping all 3rd party modules is possible
2019-12-06 13:41:49 <Cogitri> Yup
2019-12-06 13:42:05 <mps> personally, I try to use only 'in upstream' modules but there are some which is must, WG for example
2019-12-06 13:42:32 <ncopa> i think wireguard will be upstreamed soonish
2019-12-06 13:43:08 <Cogitri> Nice
2019-12-06 13:43:10 <mps> WG will be in 5.6 probably, and sdfat in 5.5 or 5.6 didn't looked yet
2019-12-06 13:43:39 <mps> zinc is already in 5.5, iirc
2019-12-06 13:43:43 <Cogitri> Another unrelated thing: What CFLAGS do we use on the builders?
2019-12-06 13:44:10 <ncopa> -Os
2019-12-06 13:44:18 <Cogitri> Just -Os?
2019-12-06 13:44:24 <ncopa> possible some also has -fomit-frame-pointer
2019-12-06 13:44:29 <mps> to go to original question, should we keep '/boot/dtbs' for -lts?
2019-12-06 13:44:41 <mps> or /boot/dtbs-lts
2019-12-06 13:44:47 <Cogitri> No stack protection/clash protection/FORTIFY_SOURCE ?
2019-12-06 13:45:05 <ncopa> mps: i think the latter makes sense
2019-12-06 13:45:16 <mps> agree
2019-12-06 13:45:20 <ncopa> Cogitri: that is handled by kernel config
2019-12-06 13:45:32 <mps> it is clear from the name what is there
2019-12-06 13:45:33 <Cogitri> I mean for all packages not just the kernel
2019-12-06 13:45:45 <ncopa> at least  ssp and FORTIFY_SOURCE is a libc thing
2019-12-06 13:45:51 <ncopa> and kernel does not link to libc
2019-12-06 13:46:27 <ncopa> i think there is some sort of SSP in kernel, but that is enabled/disabled with kernel config
2019-12-06 13:46:33 <ncopa> same with fortify source
2019-12-06 13:46:51 <ncopa> clash protection i dont know
2019-12-06 13:47:16 <mps> 'always enable Stack Smashing Protector'
2019-12-06 13:47:29 <Cogitri> Yes, but I was talking about all packages, not just the kernel
2019-12-06 13:47:37 <ncopa> ah
2019-12-06 13:48:01 <Cogitri> So we're building all packages with stack- protection, SSP and stack clashing protection?
2019-12-06 13:48:01 <ncopa> yes, we have SSP and fortify enabled by default
2019-12-06 13:48:08 <ncopa> yes
2019-12-06 13:48:13 <Cogitri> Good
2019-12-06 13:48:15 <ncopa> stack-protector-strong
2019-12-06 13:48:23 <ncopa> not stack-protector-all
2019-12-06 13:48:37 <Cogitri> Yes, -all is too expensive
2019-12-06 13:48:41 <Cogitri> Also stack-clash-protection ?
2019-12-06 13:48:48 <ncopa> which enables SSP in places where its useless
2019-12-06 13:49:21 <Cogitri> Since Void is triggering a Segfault on FF 71 (due to stack clashing) that we don't have, so I suspect we don't have stack-clash-protection enabled
2019-12-06 13:49:32 <ncopa> i dont think we have it
2019-12-06 13:49:38 <ncopa> first time i hear about it
2019-12-06 13:50:08 <ncopa> ssp, fortify and PIE are enabled by default in our toolchain
2019-12-06 13:50:14 <ncopa> and not via CFLAGS
2019-12-06 13:50:49 <ncopa> you need to explicitly disable it if you dont want it
2019-12-06 13:50:57 <Cogitri> Alrighty, great
2019-12-06 13:51:06 <Cogitri> We should really consider stack-clash-protection though
2019-12-06 13:51:24 <ncopa> sounds like we should, yes
2019-12-06 13:51:32 <Cogitri> E.g. systemd-journald had some major CVEs that just didn't apply if you compiled it with that flag (https://www.qualys.com/2019/01/09/system-down/system-down.txt)
2019-12-06 13:51:53 <Cogitri> (And yes, although that's systemd it's still super useful for other packages :P)
2019-12-06 13:52:15 <mps> Cogitri: please, don't
2019-12-06 13:52:41 <Cogitri> And I guess FF is going to issue a CVE for FF 71 that was surfaced due to stack-clash-protection
2019-12-06 13:55:53 <ncopa> ERROR: unsatisfiable constraints:
2019-12-06 13:55:53 <ncopa>   so:libvirglrenderer.so.0 (missing):
2019-12-06 13:55:53 <ncopa>     required by: qemu-4.1.1-r1[so:libvirglrenderer.so.0] qemu-system-x86_64-4.1.1-r1[so:libvirglrenderer.so.0]
2019-12-06 13:58:39 <ncopa> looks like it was introduced with bc7ca99b460459d57124a56d8fa82ccafd5969a3
2019-12-06 14:00:38 <ncopa> and it seems that it is only qemu that needs rebuild
2019-12-06 14:11:17 <ncopa> kaniini: you got your push access back. welcome back!
2019-12-06 14:18:51 <mps> nice :)
2019-12-06 14:20:55 <ncopa> i pushed linux-lts update and move to main
2019-12-06 14:22:06 <mps> ok, now is time again for testing
2019-12-06 14:22:07 <Cogitri> Nice
2019-12-06 14:41:41 <clandmeter> ncopa: can we include wireguard in the rpi modloop?
2019-12-06 14:48:26 <clandmeter> ncopa: it would also be nice to have an aarch64 iso included.
2019-12-06 15:32:08 <ncopa> i think we need move wireguard to main in that case
2019-12-06 15:33:56 <ncopa> wow! 3.11 builders are done!
2019-12-06 15:34:30 <_ikke_> \o/\o/\o/
2019-12-06 15:37:42 <mps> looks like dl-cdn.alpinelinux.org is not synced for some time
2019-12-06 15:38:21 <clandmeter> last-updated                                       06-Dec-2019 15:00                  11
2019-12-06 15:39:09 <_ikke_> 40 minutes ago?
2019-12-06 15:39:28 <mps> hmm, I don't see pkgs built last night on my aarch64
2019-12-06 15:41:53 <clandmeter> i think the last updated only gets updated on the hour
2019-12-06 15:42:09 <clandmeter> and t1 mirror is synced every 15min
2019-12-06 15:44:53 <mps> ok, will check in hour and see
2019-12-06 16:04:33 <ncopa> do we still need dahdi-linux kernel module?
2019-12-06 16:05:07 <clandmeter> dunno, maybe fabled uses it?
2019-12-06 16:05:13 <clandmeter> thats asterisk right?
2019-12-06 16:05:34 <ncopa> its a driver for an ISDN card that asterisk uses, yes
2019-12-06 16:41:43 <kaniini> it would be nice to keep
2019-12-06 16:42:11 <kaniini> however in practice I don't think many use digium isdn cards anymore
2019-12-06 17:15:39 <mps> nice, linux-lts is now default
2019-12-06 17:16:34 <mps> and we got ROOT_SIZE
2019-12-06 17:27:18 <mps> after 3.11 rc1 will the main and community be rebuilt again before 3.11 final release?
2019-12-06 17:28:39 <ncopa> no
2019-12-06 17:28:57 <ncopa> we just fix the things that needs to be fixed and ship the release
2019-12-06 17:29:15 <mps> ah, then upgrade linux-headers to 5.4 doesn't make sense
2019-12-06 17:29:29 <ncopa> correct
2019-12-06 17:29:35 <mps> thanks
2019-12-06 17:34:51 <ncopa> clandmeter: what do you think about an aarch64 virt iso image?
2019-12-06 17:35:19 <ncopa> or were you thinking standard
2019-12-06 17:43:55 <ncopa> what do we need for making a release with rpi4?
2019-12-06 18:32:45 <mps> hah, I think I have one sangoma card in garage :)
2019-12-06 18:33:21 <mps> and, no, I don't use it for years
2019-12-06 18:33:50 <ncopa> ok
2019-12-06 18:33:55 <ncopa> i think im ready for an rc1
2019-12-06 18:34:38 <mps> ok, I'm too tired to fix reboot and poweroff for some armv7 boards
2019-12-06 18:34:52 <mps> maybe tomorrow
2019-12-06 18:36:08 <ncopa> ok here we go....
2019-12-06 19:00:06 <walbon> ncopa: I am trying to add the bcc/libbpf to powerpc, but I have problem to build it because the luajit has an issue in it too. So, how can I apply patches for both and use it to try a build of bcc?
2019-12-06 20:52:30 <kpcyrd> we finished building main and it's currently at 91.9% reproducible, 5.8% unreproducible and 0.7% has build issues in our test environment
2019-12-06 20:53:13 <kpcyrd> community is still in progress and hovering around 82%
2019-12-06 20:55:28 <mps> nice
2019-12-06 21:43:18 <north1> @maldridge I have made an MR and tagged you, it includes fixes to your previous MR
2019-12-06 21:46:50 <clandmeter> _ikke_: what does this do? https://git.alpinelinux.org/aports/tree/community/chezmoi/APKBUILD?id=87e52be140741344ea24ae0e70f9a221330de2da#n41
2019-12-06 21:47:27 <_ikke_> chezmoi?
2019-12-06 21:47:39 <clandmeter> check my link
2019-12-06 21:47:56 <_ikke_> right
2019-12-06 21:48:05 <_ikke_> it tells where to find the documentation
2019-12-06 21:48:23 <_ikke_> And it also tells it to not bundle it in the binary
2019-12-06 21:48:38 <_ikke_> oh, no, thats --tags noembeddocs
2019-12-06 21:48:50 <clandmeter> i mean line 41
2019-12-06 21:49:10 <_ikke_> ugh, debug statement I mistakenly left :-/
2019-12-06 21:49:16 <clandmeter> :p
2019-12-06 21:49:52 <_ikke_> clandmeter: cgit has weird anchoring. It shows line 27 on top, so that's why I thought you were talking about that
2019-12-06 21:50:45 <clandmeter> because it cant scroll any further down?
2019-12-06 21:51:19 <_ikke_> hmm, good point
2019-12-06 21:52:52 <clandmeter> no worries, its weekend :)
2019-12-06 21:53:05 <_ikke_> :)
2019-12-06 21:53:08 <telmich> hihi, I was fooled by that before, too
2019-12-06 21:53:47 <clandmeter> by the weekend?
2019-12-06 22:26:05 <ncopa> 3.11 rc1 is out
2019-12-06 22:26:56 <north1> nice
2019-12-06 22:29:19 <north1> 3.11-stable is not branched out yet, yeah ?
2019-12-06 22:49:26 <telmich> clandmeter: never! but often by holidays - they are really tricky, when one works independently of them
2019-12-06 22:52:25 <maldridge> north1: a link would be nice
2019-12-06 22:52:38 <north1> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1965
2019-12-06 22:53:33 <north1> ddevault (IRC): opinion on https://lists.alpinelinux.org/~alpine/aports/patches/3159 ?
2019-12-06 22:53:56 <ddevault> +1
2019-12-06 22:54:36 <north1> aight, gonna merge
2019-12-06 22:57:20 <north1> @ddevault using https://lists.alpinelinux.org/~alpine/aports/patches/3159/mbox always return the first patch, any way to get the last one (via commandline) ?
2019-12-06 23:04:14 <ddevault> oh, they sent v2 to the same thread
2019-12-06 23:04:19 <ddevault> that's discouraged, and it doesn't handle it well
2019-12-06 23:04:24 <north1> So user mistake ?
2019-12-06 23:04:24 <ddevault> try this: https://lists.alpinelinux.org/~alpine/aports/%3C20191206225118.19415-1-galen%40galenabell.com%3E/raw
2019-12-06 23:04:30 <ddevault> well, the software ought to handle it better
2019-12-06 23:04:34 <north1> Yes i did that but it required me to leave the commandline
2019-12-06 23:04:36 <ddevault> but yeah, that's not how v2's should be sent
2019-12-06 23:04:39 <north1> ^ i don't like that
2019-12-06 23:04:58 <ddevault> ack, neither do I
2019-12-06 23:05:02 <ddevault> I've hit this before too
2019-12-06 23:32:23 <Guest9> v3.11 rc1/etc/update-extlinux.conf:# default# default kernel to bootdefault=vanilla
2019-12-06 23:32:31 <Guest9> should be lts, right?
2019-12-06 23:56:26 <mps> right, need fix
2019-12-07 00:16:20 <north1> @maldridge it is in main
2019-12-07 00:19:52 <maldridge> north1: cool thnx
2019-12-07 11:59:14 <_ikke_> xmrig is stuck again on aarch64
2019-12-07 13:20:38 <PureTryOut[m]> So I'd like pinentry to also have the Qt UI enabled. However, it's in main where Qt is in community. Would it be ok to move pinentry to community?
2019-12-07 13:23:55 <_ikke_> Is there something else in main depending on pinentry?
2019-12-07 13:27:19 <qa3Txu0iak0F> gnupg?
2019-12-07 13:27:37 <qa3Txu0iak0F> or does that come with it's own impl of pinentry? unsure
2019-12-07 13:28:18 <qa3Txu0iak0F> yeah, it does depend on it.
2019-12-07 13:32:15 <PureTryOut[m]> Seems `gnupg`, `gcr` and `gnupg1`
2019-12-07 13:32:47 <PureTryOut[m]> Seeing GTK+3.0 is in `main/`, I wouldn't mind moving Qt to `main/` at some point too, but just Pinentry would do for me right now
2019-12-07 13:35:16 <Cogitri> Fine by me to move gcr
2019-12-07 13:35:53 <_ikke_> I think we wanted to move gtk to community
2019-12-07 13:40:06 <PureTryOut[m]> I'll just make a MR then and people can comment on there
2019-12-07 13:57:43 <qa3Txu0iak0F> i don't think you can move gnupg from main to community
2019-12-07 13:59:11 <PureTryOut[m]> Hmm there are several packages that depend on gnupg in main...
2019-12-07 14:11:15 <mps> yes, gtk should go to community, if possible
2019-12-07 14:12:07 <mps> PureTryOut[m]: you can create separate pinentry-qt pkg
2019-12-07 14:12:59 <PureTryOut[m]> That's ugly though... It would also mean regular pinentry is still pulled in while you might only need the Qt bindings
2019-12-07 14:13:10 <PureTryOut[m]> (when installing e.g. gnupg)
2019-12-07 14:16:01 <mps> gnupg should stay in main and qt (and gtk) should be in community
2019-12-07 14:18:54 <PureTryOut[m]> Yeah that sounds logical. But then you have the issue of packages in main having (optional) UI's which depend on toolkits in community
2019-12-07 14:19:41 <mps> yes, it is ugly I agree, but doubt that we have better solution
2019-12-07 14:58:52 <PureTryOut[m]> What about this then? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1982
2019-12-07 14:58:55 <PureTryOut[m]> Basically what you said
2019-12-07 15:04:45 <PureTryOut[m]> Btw the aarch64 Gitlab CI runner is down
2019-12-07 15:05:43 <_ikke_> let me check
2019-12-07 15:18:17 <mps> PureTryOut[m]: disabling gtk/gnome for pinentry in main sound reasonable, imo
2019-12-07 15:19:35 <mps> yes, aarch64 CI is busy or doesn't work, at least when I pushed linux-lts update
2019-12-07 15:33:39 <_ikke_> The runner is running again
2019-12-07 15:39:13 <north1> Nice
2019-12-07 15:39:34 <Cogitri> Let's please not disable gtk/gnome for pinentry
2019-12-07 15:39:47 <Cogitri> Unless you move that out to a seperate package in community
2019-12-07 15:40:00 <Cogitri> This change would break GPG on GNOME
2019-12-07 15:41:15 <_ikke_> Cogitri: that's exactly what PureTryOut[m] is doing
2019-12-07 15:41:21 <_ikke_> look at the MR
2019-12-07 15:41:58 <_ikke_> community/pinentry-ui
2019-12-07 15:42:05 <Cogitri> Alrighty, good
2019-12-07 15:56:26 <mps> hm, isn't text mode also 'ui'
2019-12-07 15:57:19 <PureTryOut[m]> I guess, but then the regular pinentry package would be empty 😛 Idk what else to call it
2019-12-07 15:57:49 <mps> just 'pinentry'
2019-12-07 15:58:30 <PureTryOut[m]> Wouldn't it then conflict with pinentry in main?
2019-12-07 15:58:55 <mps> yes, I thought you are talking about pkg in main
2019-12-07 16:00:06 <mps> can community flavour be pinentry-{gtk,gnome,qt} pkgs
2019-12-07 16:02:58 <_ikke_> then you would need to create 3 packages instead of one
2019-12-07 16:03:29 <mps> can this be done by subpackages
2019-12-07 16:03:31 <_ikke_> or an empty main package with 3 subpkackages
2019-12-07 16:03:57 <mps> that's what I think, if possible
2019-12-07 16:25:18 <PureTryOut[m]> Well I'm trying to move the subpackages to community. But to prevent having to create 3 separate packages, they need a "main" package, in this case pinentry-ui
2019-12-07 16:51:55 <mps> how to know who is aports/scripts maintainer, or scripts doesn't have it
2019-12-07 16:52:20 <_ikke_> indeed
2019-12-07 16:52:45 <mps> no maintainer?
2019-12-07 16:52:55 <_ikke_> You can look who is making changes to these scripts
2019-12-07 16:53:09 <mps> I looked in git log
2019-12-07 16:53:39 <mps> most changes is done by BFDL
2019-12-07 16:53:47 <_ikke_> :)
2019-12-07 16:53:52 <mps> BDFL*
2019-12-07 16:54:36 <mps> ok, will wait till monday to ask to make some changes for arm images
2019-12-07 17:19:07 <ddevault> how would we feel about dropping ninja in favor of samurai, which is compatible with ninja, by adding a symlink
2019-12-07 17:19:22 <ddevault> samu is simpler, written in C instead of C++, and has maintainership which is not hostile to distros
2019-12-07 17:19:30 <ddevault> (ninja refuses to add an environment variable for -j, samu already has one)
2019-12-07 17:19:59 <mps> (I'm more for samu/rai folklore :) )
2019-12-07 17:20:34 <mps> (hagakure)
2019-12-07 17:32:25 <north1> ddevault (IRC): I packaged samurai for Exherbo and Void Linux and yes
2019-12-07 17:32:33 <north1> i planned on pushing for replacing it eventually
2019-12-07 17:32:58 <ddevault> sent email to the ml
2019-12-07 17:33:19 <ddevault> shit, bunged it up
2019-12-07 17:38:06 <ddevault> https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E
2019-12-07 19:12:17 <mps> ddevault: just read your mail, +1 for samu (you know why I dislike to reply to ML ;) )
2019-12-07 20:19:34 <kaniini> ddevault: i assume by "not bug for bug compatible with ninja" it is the same as how pkgconf is not bug-compatible with freedesktop.org pkg-config, right?
2019-12-07 20:19:42 <ddevault> aye
2019-12-07 20:19:59 <ddevault> the readme points out that samurai implements a behavior specified in ninja's docs that ninja's implementation does not conform to
2019-12-07 20:20:25 <ddevault> and samu uses a different job scheduler, which might cause build issues with projects whose dependencies are not fully specified
2019-12-07 20:20:39 <kaniini> (the latter being that pkgconf very loudly refuses to proceed with processing certain .pc files that are wrong but freedesktop version accepts anyway)
2019-12-07 20:21:28 <kaniini> ddevault: i think it is a good idea
2019-12-07 20:21:37 <kaniini> i wish somebody would write an alternative to meson, as well
2019-12-07 20:21:39 <tehcloud> I also think it is a good idea
2019-12-07 20:21:43 <ddevault> agreed wrt meson
2019-12-07 20:21:49 <kaniini> mostly because, well
2019-12-07 20:21:57 <ddevault> but I don't think it'll need reimplementing, but just serve as inspiration for the next generation
2019-12-07 20:22:01 <kaniini> while meson is better than autotools, ummmmmmmmm
2019-12-07 20:22:12 <kaniini> meson's maintainers are well :)
2019-12-07 20:22:43 <tehcloud> you have to consider dependencies as well, in that sense is meson still better than autotools?
2019-12-07 20:22:49 <kaniini> i wish that there were some tool that could just take meson build files and handle everything transparently
2019-12-07 20:22:50 <ddevault> I also spoke with mcf a few weeks ago (samu guy) and suggested that he work towards standardizing ninja's behavior
2019-12-07 20:22:52 <kaniini> tehcloud: yes
2019-12-07 20:23:14 <kaniini> tehcloud: i have been doing autotools since 2000, but i know more about ninja
2019-12-07 20:23:16 <kaniini> erf
2019-12-07 20:23:17 <kaniini> meson
2019-12-07 20:23:30 <ddevault> don't get me started on cmake
2019-12-07 20:23:36 <kaniini> meson is far, far, far more transparent than autotools
2019-12-07 20:24:02 <kaniini> the downside is that it is maintained by people who have their own vision and don't really listen to what devs need
2019-12-07 20:24:11 <tehcloud> I hate Python
2019-12-07 20:24:17 <kaniini> and it's written in python so i can't just switch pkgconf over to it
2019-12-07 20:24:22 <ddevault> I don't hate Python but I agree that it's completely wrong for a build system
2019-12-07 20:24:27 <kaniini> because you need pkgconf far earlier than you need python
2019-12-07 20:24:35 <kaniini> and you need pkgconf to build python
2019-12-07 20:24:40 <ddevault> can't pkgconf just use make?
2019-12-07 20:24:44 <kaniini> yes
2019-12-07 20:24:56 <kaniini> i am thinking about
2019-12-07 20:25:00 <kaniini> just using make
2019-12-07 20:25:11 <kaniini> and letting the microsoft people have a visual studio solution
2019-12-07 20:25:14 <ddevault> you might also take a look at the POSIX 'build system' I wrote for mrsh
2019-12-07 20:25:17 <kaniini> which is what was originally how it went
2019-12-07 20:25:21 <ddevault> which just involved POSIX shell scripts which spit out some Makefiles
2019-12-07 20:25:34 <ddevault> https://git.sr.ht/~emersion/mrsh
2019-12-07 20:25:41 <ddevault> see configure script
2019-12-07 20:25:53 <kaniini> but for audacious, meson has been great
2019-12-07 20:26:08 <kaniini> we can build windows and mac binaries that are correctly bundled
2019-12-07 20:26:20 <kaniini> and on posix it is same as using autotools
2019-12-07 20:26:32 <ddevault> wlroots uses meson, and I overhauled monado (OpenXR) to use it too
2019-12-07 20:26:44 <ddevault> it's a clear winner over cmake or autotools
2019-12-07 20:26:54 <ddevault> despite living far too high in the stack
2019-12-07 20:26:55 <kaniini> well
2019-12-07 20:27:18 <kaniini> cmake was originally created by a US government contractor
2019-12-07 20:27:26 <kaniini> and it shows in the whole mentality of how the tool is designed
2019-12-07 20:27:44 <ddevault> cmake was originally created by a dead goat with a keyboard positioned under weights tied to its decaying body
2019-12-07 20:28:30 <ddevault> cmake may be the actual antichrist
2019-12-07 20:28:39 <tehcloud> glad to see nobody saying anything good about cmake
2019-12-07 20:29:39 <kaniini> incidentally
2019-12-07 20:29:48 <kaniini> ddevault: are you still interested in riscv64 alpine
2019-12-07 20:29:56 <ddevault> yes, but it's blocked by u-Boot quality issues
2019-12-07 20:30:13 <kaniini> huh?
2019-12-07 20:30:16 <ddevault> I plan on resuming it when I have a good solution for booting with a kernel/initrd on the filesystem rather than baked into some crazy shit at build time
2019-12-07 20:30:27 <kaniini> there is no bootm?
2019-12-07 20:30:44 <ddevault> the issue is that the uboot port doesn't have an mmc driver
2019-12-07 20:30:51 <ddevault> I could netboot but I don't want to
2019-12-07 20:30:55 <kaniini> humm
2019-12-07 20:31:05 <kaniini> on octeon, they just do not support bootm at all
2019-12-07 20:31:09 <ddevault> an mmc driver exists for the kernel
2019-12-07 20:31:11 <kaniini> instead there is bootoctlinux
2019-12-07 20:31:13 <ddevault> in theory a marriage is possible
2019-12-07 20:31:19 <ddevault> but it's not a priority for me atm
2019-12-07 20:31:35 <kaniini> on octeon, we have named memory blocks, and there's a 10 line kernel patch that makes it possible to boot an initramfs
2019-12-07 20:32:03 <kaniini> so you just create a memory region named linux.initrd
2019-12-07 20:32:08 <kaniini> and load the initramfs blob into it
2019-12-07 20:32:16 <kaniini> and then boot with rd_name=linux.initrd
2019-12-07 20:32:21 <ddevault> but you're still whangjangling your kernels manually or with hacks
2019-12-07 20:32:29 <ddevault> I'd really rather pull it from the filesystem, the leap isn't far
2019-12-07 20:32:40 <ddevault> let's not immortalize shitty boot hacks in this arch, too
2019-12-07 20:32:49 <kaniini> yes, we use fatload
2019-12-07 20:33:02 <kaniini> to read from mmc or usb
2019-12-07 20:33:24 <kaniini> namedblock linux.initrd 0x4000000
2019-12-07 20:33:40 <kaniini> fatload usb 0 initramfs-octeon $named_block_addr
2019-12-07 20:33:52 <ddevault> fedora uses hardcoded kernels and root filesystem over nbd
2019-12-07 20:33:53 <kaniini> bootoctlinux [...] rd_name=linux.initrd
2019-12-07 20:34:07 <ddevault> hifive doesn't have usb, only avenues are mmc or network
2019-12-07 20:34:13 <ddevault> or serial I guess
2019-12-07 20:34:28 <ddevault> smoke signals
2019-12-07 20:34:29 <kaniini> so the real problem is the hw is not really usable
2019-12-07 20:34:40 <ddevault> well, usable for what?
2019-12-07 20:34:50 <kaniini> booting off a hard disk :)
2019-12-07 20:34:52 <ddevault> it can be useful once you get it booted and on the network
2019-12-07 20:35:14 <ddevault> no, there's no SATA without the expansion board, which is hard (read: impossible) to get, and pretty shit anyway (FPGA based)
2019-12-07 20:35:37 <kaniini> well that certainly kills the viability of that port :/
2019-12-07 20:35:43 <ddevault> the boot story is really my only concern with this hardware
2019-12-07 20:36:00 <ddevault> why? you can't use HDDs on a raspberry pi, either, but they still serve a purpose
2019-12-07 20:36:07 <ddevault> I rather like the hifive, it's a pretty nice machine
2019-12-07 20:36:15 <kaniini> you can, via USB
2019-12-07 20:36:35 <ddevault> well, I've never plugged a hard drive into an rpi, and I still have had use-cases for them
2019-12-07 20:36:46 <kaniini> sure, but for building
2019-12-07 20:36:50 <kaniini> it is kind of a pain
2019-12-07 20:36:58 <ddevault> depends, really
2019-12-07 20:37:01 <kaniini> to have to boot off NBD or whatever
2019-12-07 20:37:04 <ddevault> not really
2019-12-07 20:37:18 <ddevault> I bootstrapped a significant chunk of main off of a 128G SD card
2019-12-07 20:37:28 <ddevault> 8G of RAM makes for a pretty decent disk cache
2019-12-07 20:37:33 <kaniini> when did the SD card die ;)
2019-12-07 20:37:37 <ddevault> so it's not thrashing it much
2019-12-07 20:37:42 <ddevault> ¯\_(ツ)_/¯
2019-12-07 20:37:45 <ddevault> if it dies, put a new one in
2019-12-07 20:37:53 <ddevault> idk, it's enough for me
2019-12-07 20:38:03 <ddevault> my board has an uptime of >100 days right now
2019-12-07 20:38:28 <kaniini> people always see "works on raspberry pi" on pleroma's site and then install it to some shit tier SD card they bought for $4.95 at walmart
2019-12-07 20:38:36 <kaniini> and then the SD card dies like a week later
2019-12-07 20:38:40 <kaniini> so :P
2019-12-07 20:38:40 <ddevault> well, this board costs over a grand
2019-12-07 20:38:45 <ddevault> no one is going to buy it without having a plan for it
2019-12-07 20:39:37 <ddevault> anyway, any time someone emails me about riscv64 on alpine, I try to convince them to go work on u-boot
2019-12-07 20:39:41 <ddevault> so far I have been unsuccessful in this endeavour
2019-12-07 20:39:56 <kaniini> u-boot is horrible, that is why
2019-12-07 20:40:05 <ddevault> aye
2019-12-07 20:40:25 <ddevault> there's another bootloader around for this board, but it suffers from similar dumb shit (like writing the kernel directly to a GPT partition with a magic UUID)
2019-12-07 20:40:29 <kaniini> i tried to update the cavium fork of u-boot and chainload it
2019-12-07 20:40:46 <kaniini> oh
2019-12-07 20:40:51 <kaniini> that is the chromeos way
2019-12-07 20:41:12 <kaniini> i have alpine running on an aarch64 chromebook actually
2019-12-07 20:41:15 <kaniini> it is quite speedy
2019-12-07 20:41:27 <ddevault> I am very fucking unenthusiastic about a post-upgrade hook for the kernel which dd's it onto a magic disk partition
2019-12-07 20:41:29 <kaniini> 8 cores at 2.5ghz with 3.1ghz turbo
2019-12-07 20:41:37 <ddevault> plus, the modules and initrd have to be baked in
2019-12-07 20:42:02 <ddevault> which would involve magic ELF fiddling at best, and zero customizability and a weird build at worst
2019-12-07 20:42:20 <kaniini> yeah i looked into
2019-12-07 20:42:30 <kaniini> slipstreaming an initramfs into an already built kernel
2019-12-07 20:42:35 <kaniini> due to octeon fuckery
2019-12-07 20:42:42 <ddevault> it's the worst thing ever, right
2019-12-07 20:43:02 <kaniini> i did get petitboot working, but that's too much of a hack tbh
2019-12-07 20:43:24 <kaniini> i don''t want to have to build a linux distro just to boot another linux distro
2019-12-07 20:43:27 <kaniini> lol
2019-12-07 20:43:35 <ddevault> lol yeah, that shit be dumb
2019-12-07 20:43:45 <ddevault> did you hear about my petitboot horror story on ppc64
2019-12-07 20:44:02 <ddevault> at some point the petitboot ncurses TUI was being piped into /bin/sh and shitting logs out of serial
2019-12-07 20:45:15 <kaniini> no but it seems about right
2019-12-07 20:45:17 <kaniini> i just use grub
2019-12-07 20:45:21 <kaniini> on ppc64
2019-12-07 20:45:38 <kaniini> you can boot directly to it from the system management console thing
2019-12-07 20:55:08 <mps> kaniini: also I have alpine on chromebook
2019-12-07 20:55:37 <mps> aarch64
2019-12-07 20:57:20 <kaniini> how do you boot yours
2019-12-07 20:57:34 <kaniini> i use some arch kernel but it is broken and doesnt turn my trackpad on
2019-12-07 20:58:42 <mps> I created vboot-utils for alpine, build kernel and sign, then 'dd' kernel partition
2019-12-07 20:58:52 <kaniini> yeah but what kernel do you use
2019-12-07 20:58:58 <kaniini> like a custom one?
2019-12-07 20:59:37 <mps> yes, I build custom because alpine aarch64 kernel (as it is now) doesn't work
2019-12-07 21:02:07 <mps> for old exynos (arm32) chomebook I found non verified u-boot and on it 'normal' kernel+initramfs can boot
2019-12-07 21:02:33 <mps> and 'numeric' menu in u-boot to select kernels
2019-12-07 21:03:01 <mps> but didn't found anything which work on aarch64
2019-12-07 21:03:41 <mps> tried to build from upstream but display is blank, doesn't work
2019-12-07 21:04:43 <kaniini> ah so you use the google-provided sources
2019-12-07 21:05:08 <mps> no, upstream kernel.org
2019-12-07 21:05:48 <mps> in previous msg by 'upstream' I meant u-boot
2019-12-07 21:06:10 <kaniini> do you use upstream sources with the google-provided DTB or what
2019-12-07 21:07:32 <mps> I took kernel.its from Arch, everything else is in upstream kernel
2019-12-07 21:07:46 <mps> rk3399
2019-12-07 21:08:45 <mps> actually, I could write kernel.its but lazy
2019-12-07 21:10:23 <kaniini> what kernel are you using
2019-12-07 21:10:26 <kaniini> like just 5.4?
2019-12-07 21:10:27 <kaniini> or what
2019-12-07 21:11:13 <mps> 5.4.2-1-gru #1 SMP PREEMPT Fri Dec 6 22:39:46 CET 2019 aarch64 GNU/Linux
2019-12-07 21:11:49 <mps> but started with 5.0 iirc
2019-12-07 21:12:49 <mps> maybe 4.2x, forgot TBH
2019-12-07 21:14:00 <kaniini> interesting
2019-12-07 21:14:10 <kaniini> have you packaged vboot-utils yet
2019-12-07 21:14:28 <mps> apk search vboot-utils :)
2019-12-07 21:14:33 <mps> testing repo
2019-12-07 21:15:51 <mps> and cgpt subpkg
2019-12-07 21:24:28 <kaniini> could probably move to community :)
2019-12-07 21:26:23 <mps> you are first who asked
2019-12-07 21:27:37 <mps> and I don't move pkgs till someone ask :)
2019-12-07 21:27:44 <kaniini> so i think ultimately
2019-12-07 21:27:51 <kaniini> i just need to get upstream kernel source
2019-12-07 21:28:06 <kaniini> and the DTB from the google sources (since it's not in upstream), and write an its file
2019-12-07 21:28:12 <kaniini> and then my trackpad will work
2019-12-07 21:28:25 <mps> what is your chipset
2019-12-07 21:28:28 <kaniini> since i think the DTB being used in the arch kernel is for a previous revision
2019-12-07 21:28:32 <kaniini> umm
2019-12-07 21:28:36 <kaniini> the mediatek one
2019-12-07 21:28:51 <kaniini> 'oak' baseboard
2019-12-07 21:28:52 <mps> ah, my son have mediatek chromebook
2019-12-07 21:29:00 <mps> yes, oak
2019-12-07 21:29:17 <kaniini> it boots fine with the arch kernel just the trackpad is wired up to wrong GPIO pins i think
2019-12-07 21:29:23 <kaniini> in the DTB
2019-12-07 21:29:26 <mps> but I can't experiment with his chromebook
2019-12-07 21:29:55 <mps> on his machine kernel is 3.18 I think
2019-12-07 21:30:20 <kaniini> yes
2019-12-07 21:30:34 <kaniini> i think it is possible to run upstream 5.4
2019-12-07 21:30:40 <kaniini> just need to get the right DTB
2019-12-07 21:30:45 <mps> but trackpad works on his machine
2019-12-07 21:30:55 <kaniini> yeah
2019-12-07 21:31:05 <kaniini> everything but trackpad works
2019-12-07 21:31:26 <clandmeter> why do ppl use chromebook with linux? battery life?
2019-12-07 21:31:37 <kaniini> aarch64
2019-12-07 21:32:01 <mps> 970 gr, weight :)
2019-12-07 21:32:23 <clandmeter> what is special about aarch64 that you want it on your notebook?
2019-12-07 21:32:26 <kaniini> the fact that it deadnames me when i log in
2019-12-07 21:33:08 <clandmeter> mps: you can get that weight also on x86 notebooks
2019-12-07 21:33:37 <kaniini> clandmeter: lack of bullshit like spectre/meltdown
2019-12-07 21:33:56 <kaniini> also it is nice to be able to test my code on aarch64
2019-12-07 21:33:58 <mps> xrandr says '2400x1600'
2019-12-07 21:34:24 <mps> plus tablet mode
2019-12-07 21:34:36 <mps> touchscreen
2019-12-07 21:34:43 <kaniini> mine doesnt have touchscreen
2019-12-07 21:34:47 <kaniini> but oak boards usually do
2019-12-07 21:34:55 <kaniini> that's why i think i need a different DTB :P
2019-12-07 21:35:06 <mps> ah, could be
2019-12-07 21:35:38 <mps> I will look deeply on my son machine in aa few days, when he come here
2019-12-07 21:36:06 <kaniini> also need to figure out video acceleration i guess
2019-12-07 21:36:33 <mps> yes, that is unknown for me on mediatek
2019-12-07 21:36:34 <kaniini> probably linking gcompat against the proprietary blob for now :/
2019-12-07 21:37:25 <kaniini> clandmeter: also chromebooks are like $160 US with otherwise decent spec
2019-12-07 21:37:55 <clandmeter> decent for the price maybe
2019-12-07 21:38:02 <mps> about spectre: lscpu => Vulnerability Spectre v2:        Vulnerable
2019-12-07 21:38:07 <mps> meh
2019-12-07 21:41:45 <mps> clandmeter: if I buy it now I would probably go with rock64
2019-12-07 21:41:51 <clandmeter> i have one which is a bit older and runs linux, but if you are used to X1 and macbooks (not the 2017/8) hardware its hard to switch.
2019-12-08 07:27:45 <Cogitri> kaniini: Somehow I was under the impression that AArch64 is vulnerable to Spectre too (unless you buy the latest revision or ARMv8 that has a hardware mitigation for it)
2019-12-08 07:28:17 <kaniini> look, it's not x86 is the main point
2019-12-08 07:28:30 <kaniini> i do not think you understand my dislike of x86
2019-12-08 07:28:36 <kaniini> it is pretty extreme
2019-12-08 07:36:55 <mps> also, I dislike x86 maybe not extreme but sure dislike them strongly
2019-12-08 07:37:32 <mps> not that I like arm ltd much
2019-12-08 07:55:53 <kaniini> well
2019-12-08 07:55:55 <kaniini> i should clarify
2019-12-08 07:55:59 <kaniini> i dislike intel extremely
2019-12-08 07:56:04 <kaniini> AMD are mostly okay
2019-12-08 07:56:12 <kaniini> but
2019-12-08 08:00:00 <Cogitri> I don't like x86, but right now it's just the best bang for the buck, sooo
2019-12-08 08:00:15 <Cogitri> I'm team AMD too though
2019-12-08 08:00:36 <mps> I don't know if ADM have IME (Intel Management Engine)
2019-12-08 08:02:17 <russkel> computers eh
2019-12-08 08:03:56 <mps> worked with 8086 (yes, that one) and with 6502 (predecessor of ARM) maybe I like arm because of their simplest architecture
2019-12-08 08:06:14 <Cogitri> AMD has PSP which kind of is like the IME
2019-12-08 08:38:02 <russkel> soo my patch to clang hasn't been looked at, is github not the preferred repo for patches to main?
2019-12-08 08:44:27 <Cogitri> We're transitioning to Gitlab, yes. But maybe _ikke_/ncopa can take a look at it
2019-12-08 08:57:23 <russkel> https://github.com/alpinelinux/aports/pull/12044
2019-12-08 08:57:33 <russkel> that'll be my last patch via github
2019-12-08 08:58:38 <russkel> I got opencv compiling and need to create a PR for it
2019-12-08 09:08:21 <Cogitri> Nice, feel free to ask if need help w/ Gitlab
2019-12-08 09:39:36 <russkel> =)
2019-12-08 11:16:20 <artok> alpine and ROS .. mmm
2019-12-08 11:59:31 <russkel> oh he knew what I was working on
2019-12-08 12:12:36 <mps> Robot OS?
2019-12-08 12:13:30 <_ikke_> realtime I guess
2019-12-08 12:13:56 <_ikke_> although that's usually rtos
2019-12-08 12:15:02 <mps> https://wiki.ros.org/
2019-12-08 12:15:22 <mps> ROS (Robot Operating System)
2019-12-08 12:16:30 <mps> I wondered why they call it OS when it runs on OS actually
2019-12-08 12:16:30 <_ikke_> ah ok
2019-12-08 12:21:07 <mps> opencv (openCV - CV Computer Vision) triggered my memory about ROS
2019-12-08 13:16:13 <russkel> yeah I'm trying to get all the dependencies into aports
2019-12-08 13:16:30 <russkel> dependency hell when you run with it on debian
2019-12-08 13:16:36 <russkel> or ubuntu
2019-12-08 13:22:21 <mps> russkel: oh no, I escaped to alpine from debian deps hell after being there for more than two decades and looks like I'm going back :D
2019-12-08 13:23:16 <russkel> mps I don't think it's anywhere near as bad haha
2019-12-08 13:23:55 <russkel> an example I give is installing some simple package like proj on ubuntu ends up installing a full mariadb setup
2019-12-08 13:35:30 <mps> russkel: you noticed ':D' at the end of my msg :)
2019-12-08 13:35:51 <russkel> yep =)
2019-12-08 13:36:23 <mps> and I understand that some pkgs are 'dependency hell'
2019-12-08 13:40:01 <russkel> haha yeah not a secret at all
2019-12-08 13:43:07 <russkel> hmm I wish someone would port nanomsg-ng to an embedded platform
2019-12-08 14:59:14 <mps> north1: git commit -v  'community/vboot-utils: move from community'
2019-12-08 14:59:29 <mps> should be from testing
2019-12-08 14:59:46 <mps> I mean your git hook which I use
2019-12-08 15:02:56 <mps> north1: sorry, looking at it I'm not sure is this issue with your git hook
2019-12-08 16:11:52 <artok> heyaaa
2019-12-08 16:11:56 <artok> how is rc1 going on?
2019-12-08 16:13:13 <_ikke_> it has been released..
2019-12-08 16:13:24 <_ikke_> so we're waiting for people testing things
2019-12-08 16:16:39 <mps> and fixing known bugs
2019-12-08 16:43:06 <artok> sadly I haven't had time for rpi4 stuff, might not make it to release
2019-12-08 16:51:52 <artok> not that it would be difficult to do quick patch tonight
2019-12-08 16:58:09 <artok> it will be 5.4 kernel on the release, then?
2019-12-08 17:20:35 <dmy> Hi, what is the proper way to add a self-hosting compiler to aports?
2019-12-08 17:21:04 <dmy> I would like to work on adding again ghc form arm, but the previous version has been removed for a while.
2019-12-08 17:21:43 <dmy> So I'm not sure how bootstrapping is supposed to be done in these cases.
2019-12-08 17:34:15 <Cogitri> Fetch a tarball to bootstrap from
2019-12-08 17:37:44 <dmy> Ok, and bootstrapping using itself would then be added only in the following release?
2019-12-08 17:44:26 <Cogitri> Yes
2019-12-08 17:44:33 <Cogitri> See Rust for how this was done
2019-12-08 17:45:22 <dmy> I will give it a look. Thank you.
2019-12-08 20:10:29 <kmmndr> Hi all :-)
2019-12-08 20:13:39 <kmmndr> I've created a tiny build environment to package for arm32v7 on amd64 host, using docker and qemu
2019-12-08 20:13:48 <kmmndr> https://github.com/kmmndr/alpine-build-env
2019-12-08 20:14:52 <kmmndr> It may be usefull for someone else than me :-)
2019-12-09 02:21:13 <kaniini> kmmndr: that approach will not work for go-based applications due to how go does signalling
2019-12-09 02:21:53 <kaniini> kmmndr: i am looking into fixing it, but have not yet found a good solution -- i suspect qemu-user's signal management will need significant rework
2019-12-09 07:06:50 <north1> apk-tools is flagged for outdated, but has the same version
2019-12-09 07:06:51 <north1> sway is flagged outdated for being 1.2-r1 (-r1 is the pkgrel= from Alpine), the suggestion of the newer version is 1.2 :D
2019-12-09 07:06:51 <north1> the flagged packages from pkgs.a.o is so wonky
2019-12-09 08:14:45 <javashin> hey anybody have compiled citra 3ds emulator ?
2019-12-09 08:16:02 <Cogitri> Doesn't ring a bell here
2019-12-09 08:18:12 <javashin> i see
2019-12-09 08:24:42 <kmmndr> kaniini: That's very good to know, did you start a similar tool ?
2019-12-09 09:06:11 <clandmeter> north1: those are manually flagged.
2019-12-09 09:06:38 <clandmeter> Automatic flagging has not been enabled yet
2019-12-09 09:06:55 <clandmeter> Keep forgetting to turn it back on
2019-12-09 09:17:46 <_ikke_> clandmeter: you're supposed to be in spain, enjoying the sun :P
2019-12-09 09:42:02 <kaniini> kmmndr: yeah I used that to accelerate bootstrapping mips64 port
2019-12-09 10:01:03 <tmhoang> ncopa: I may have to upgrade s390-tools for kernel 5.3
2019-12-09 10:03:12 <tmhoang> it's failing to boot
2019-12-09 10:03:29 <tmhoang> *reboot, after installation.
2019-12-09 10:06:57 <tmhoang> do you prefer me to upgrade s390-tools or backport patches to current version? The latter might be more work.
2019-12-09 10:07:32 <tmhoang> but since s390-tools has no dependencies, I think upgrading is fine. s390-tools releases quite matches kernel release.
2019-12-09 10:08:08 <clandmeter> _ikke_: :)
2019-12-09 10:08:10 <clandmeter> I am
2019-12-09 10:08:21 <clandmeter> But still lurking ;-)
2019-12-09 10:08:52 <tmhoang> clandmeter: have you tried netboot-ing 3.11 artifacts ?
2019-12-09 10:09:18 <tmhoang> I'm seeing busybox spitting bunch of warnings, currently checking on x86_64
2019-12-09 10:15:15 <tmhoang> ok confirmed on x86_64 busybox spitting some warning
2019-12-09 10:15:20 <tmhoang> getting them ... brb
2019-12-09 10:15:47 <clandmeter> Which kind?
2019-12-09 11:25:19 <tmhoang> clandmeter: 3.11 netboot images vmlinuz-lts, initramfs-lts, modloop-lts
2019-12-09 11:25:50 <clandmeter> the error i mean
2019-12-09 11:31:02 <tmhoang> clandmeter : http://tpaste.us/BjJo
2019-12-09 11:32:01 <tmhoang> happening inside initramfs
2019-12-09 11:32:19 <tmhoang> probably does bb does not run its hook to populate the symlinks
2019-12-09 11:32:49 <artok> mkimg script has some bugs, that happened to me last night when I created rpi package
2019-12-09 11:32:55 <_ikke_> '
2019-12-09 11:32:58 <_ikke_> Executing busybox-1.31.1-r2.post-install'
2019-12-09 11:33:04 <_ikke_> isn't that the hook to do exactly that?
2019-12-09 11:33:12 <tmhoang> yeah seems right
2019-12-09 11:34:00 <tmhoang> exec /bin/busybox --install -s
2019-12-09 11:34:20 <tmhoang> should be that one (in the past I had to run manully when porting stuffs ...)
2019-12-09 11:34:58 <tmhoang> brb
2019-12-09 11:35:45 <clandmeter> sounds like /usr/bin doesnt exist?
2019-12-09 11:46:50 <artok> what package should create it?
2019-12-09 12:12:15 <clandmeter> initramfs i guess
2019-12-09 12:25:44 <mps> #11020
2019-12-09 12:25:54 <artok> hmm is there something now wrong when mkinitfs searches modules for running kernel rather than target, when running mkimage script
2019-12-09 12:27:05 <mps> I run latest mkinitfs (edge) on armv7 and it works without problem, or I didn't noticed something
2019-12-09 12:33:17 <artok> I put my rpi4 to build linux kernel for rpi4 + rpi3 : http://pasteall.org/pic/show.php?id=823d7e8a9323b17d3a6fdfcb71786484
2019-12-09 12:34:14 <artok> at least cooling works...
2019-12-09 12:43:01 <artok> mps care to try building linux-rpi package on armv7 using https://github.com/djazo/aports/tree/rpi4-542 ? and linux-firmware from that same branch
2019-12-09 12:44:12 <artok> oh forget the linux-firmware, doesn't work now =)
2019-12-09 12:44:28 <artok> (or it might, but irrelevant)
2019-12-09 12:59:20 <mps> artok: what I should do? do you have PR there which I can apply to current aports
2019-12-09 13:00:16 <mps> oh, you mean to clone this repo?
2019-12-09 13:00:51 <mps> and, build RPI4 on armv7 or aarch64?
2019-12-09 13:06:11 <artok> build rpi4 on armv7, aarch64 machine I have from scaleway building
2019-12-09 13:09:21 <mps> by cloning repo?
2019-12-09 13:09:36 <north1> :D see everyone later, installing SSD on my notebook
2019-12-09 13:09:37 <artok> yah
2019-12-09 13:10:33 <mps> ok, see you later
2019-12-09 13:10:51 <artok> I created that big patch last night since I don't have scp access to alpinelinux.org files =)
2019-12-09 13:11:34 <mps> you can create MR on gitlab.a.o
2019-12-09 13:12:13 <artok> going to, I just need to read some docs =)
2019-12-09 13:12:23 <mps> artok: I should build main/linux-rpi
2019-12-09 13:15:20 <artok> yeah
2019-12-09 13:15:44 <artok> and should get rpi, rpi2, rpi4 packages
2019-12-09 13:16:29 <mps> ok
2019-12-09 13:16:43 <mps> this is 4.19.x not 5.4
2019-12-09 13:16:59 <artok> 5.4.2 is on the rpi4-542 branch
2019-12-09 13:17:21 <mps> ah, I have to checkout branch
2019-12-09 13:17:30 <artok> yeah sorry forgot to mention
2019-12-09 13:18:04 <mps> but there is no branches, only master
2019-12-09 13:18:44 <artok> https://github.com/djazo/aports.git should have that branch
2019-12-09 13:19:13 <mps> git clone https://github.com/djazo/aports.git
2019-12-09 13:19:23 <mps> git branch => master
2019-12-09 13:19:26 <mps> no other
2019-12-09 13:20:13 <artok> and if you go https://github.com/djazo/aports and check from web ui, you'll see rpi4-542 branch there ?
2019-12-09 13:21:02 <mps> yes
2019-12-09 13:21:24 <mps> but not after clone in local repo
2019-12-09 13:23:56 <mps> git pull origin rpi4-542
2019-12-09 13:24:06 <mps> looks solved
2019-12-09 13:24:19 <mps> hackish way :)
2019-12-09 13:25:32 <mps> artok: building, see you later ....
2019-12-09 13:30:53 <artok> thanks! laters!
2019-12-09 13:39:36 <oliv3r[m]> Hey, a curiosity, can I very easily determine if all files in a directory are part of the APKINDEX file? I know if I try to do apk add and it's not in the index (or vice versa) it complains, but I'm looking for something more trivial
2019-12-09 13:41:45 <oliv3r[m]> I guess i can do for _file in "${dir}/*"; do apk verify "${_file}" APKINDEX.tar.gz; done to check all apk files against the index, but what about the other way around?
2019-12-09 14:25:47 <clandmeter> Files are not part of the index at all
2019-12-09 14:33:30 <oliv3r[m]> of course not, but the package name is listed, which points to a file in the end. The error apk gives is 'missing file' :)
2019-12-09 14:34:03 <oliv3r[m]> basically, what I'm after is, is file bla.apk, listed properly in APKINDEX.tar.gz
2019-12-09 14:43:22 <artok> oh my.. that poor rpi4 has been working soon around the clock
2019-12-09 14:44:09 <artok> ssd on usb port might have been one to speed up things =)
2019-12-09 14:46:36 <mps> artok: I use ssd on usb-c also when building bigger pkgs
2019-12-09 14:47:03 <artok> I have "fast" usb stick
2019-12-09 14:47:09 <mps> it is much faster than emmc or (OMG) mmc
2019-12-09 14:47:21 <artok> yeah oh god people using mmc as their root
2019-12-09 14:49:54 <mps> mmc as root fs is not big issue, but fs where have write a lot is (hmm) not acceptable although even this can be used
2019-12-09 14:50:01 <mps> but need time
2019-12-09 14:50:23 <mps> anyway, building linux-rpi is finished
2019-12-09 14:52:04 <artok> and proper packages there?
2019-12-09 14:52:28 <artok> great!
2019-12-09 14:52:49 <mps> yes
2019-12-09 14:53:02 <mps> but I don't have boards to test
2019-12-09 14:53:09 <artok> now only to create tar installation package and we might test
2019-12-09 14:53:24 <artok> before that, linux-firmware should be build also
2019-12-09 14:53:42 <mps> from the same repo and branch?
2019-12-09 14:54:11 <artok> yes, and the scripts are also modified to work on that branch
2019-12-09 14:54:30 <mps> ok, lets try
2019-12-09 14:57:12 <mps> it was fast, finished
2019-12-09 15:03:06 <artok> it creates fakeroot, installs packages and runs initramfs and modloop.. and boom
2019-12-09 15:06:04 <artok> I need to now get some coffee and drive 1,5hrs
2019-12-09 15:06:26 <artok> if you have the tar.gz available for me to download, share it now. =)
2019-12-09 15:07:01 <artok> I'll test when I'm done with driving, I'm having my rpi's with me
2019-12-09 15:14:40 <clandmeter> oliv3r[m]: apk search gives you all packages available
2019-12-09 15:16:15 <artok> mps, laters, 2hrs might go and I'll be back, I'm packing now all my sd cards
2019-12-09 15:16:18 <oliv3r[m]> from a specific index file? I want to check in a script, if an index file contains all apk files in a dir
2019-12-09 15:16:43 <clandmeter> you can specifiy which index you want to use
2019-12-09 15:17:18 <clandmeter> but i htink you need to exclude the default ones with something like /dev/null
2019-12-09 15:18:20 <clandmeter> something like repository-file /dev/null extra-repo whatever.
2019-12-09 15:18:27 <clandmeter> im not suer what the correct syntax is
2019-12-09 15:19:59 <clandmeter> im currently on windows on a macbook pro with a partition that is too small to run any updates. its kind of frustrating...
2019-12-09 15:20:09 <clandmeter> macos does not want to connect to the wifi...
2019-12-09 15:41:36 <oliv3r[m]> ouch :( why would you run windows on your macbook working on alpine? :)
2019-12-09 15:47:19 <clandmeter> because it doesnt run linux properly, and without wifi its kind of useless.
2019-12-09 15:47:32 <oliv3r[m]> i can pass --repositories-file /dev/null, but it then it just cryptographically checks the signature, it doesn't run it against the APKINDEX
2019-12-09 15:47:54 <oliv3r[m]> ah a new macbook pro :( I have an older 2015-late model; runs linux pretty great
2019-12-09 15:48:18 <oliv3r[m]> suspend/resume isn't not perfect, especially with regards to wifi
2019-12-09 15:49:54 <clandmeter> did you specify -X?
2019-12-09 15:51:11 <oliv3r[m]> --repository . yes, also --repository $(readlink -f . )
2019-12-09 15:52:40 <oliv3r[m]> i think it's because by default, it will look in the current directory?
2019-12-09 15:53:10 <oliv3r[m]> nope that's not it either
2019-12-09 15:53:34 <oliv3r[m]> I just removed the APKINDEX.tar.gz file, but it just happily says 'untrusted' (which is true) but doesn't let me know it's missing fomr the index al toghether
2019-12-09 15:53:44 <clandmeter> by default it will getrepos from /etc/apk/repositories
2019-12-09 15:53:59 <clandmeter> thts why you need to disable it
2019-12-09 15:54:32 <oliv3r[m]> yeah hence the --repositories-file /dev/null
2019-12-09 15:55:49 <oliv3r[m]> what I don't want to do, is tar xvf APKINDEX.tar.gz | grep <pkg>
2019-12-09 15:55:53 <oliv3r[m]> rather I'd use some built in tool to properly do this
2019-12-09 15:58:07 <clandmeter> apk --no-cache --repositories-file /dev/null -X http://dl-cdn.alpinelinux.org/alpine/latest-stable/main search
2019-12-09 15:59:11 <clandmeter> apk --quiet --no-cache --repositories-file /dev/null -X http://dl-cdn.alpinelinux.org/alpine/latest-stable/main search
2019-12-09 15:59:17 <clandmeter> if you dojnt want pkgver
2019-12-09 16:15:49 <ddevault> https://lists.alpinelinux.org/~alpine/aports/patches/3164
2019-12-09 16:16:24 <_ikke_> ddevault: Cogitri had objections to completely removing ninja
2019-12-09 16:16:39 <ddevault> aye, I responded on the mailing list
2019-12-09 16:16:45 <ddevault> I don't expect this patch to be merged right away
2019-12-09 16:19:10 <oliv3r[m]> gotta figure out if i can send an argument to search; but I do get a list of files in the APKINDEX, so that's already really nice
2019-12-09 16:19:25 <oliv3r[m]> ah, i can use --exact to pass a search argument, but it ignores package version; so Either print all, and grep the file in the result, or use --exact, but don't get a package version :S
2019-12-09 16:19:45 <Cogitri> ddevault: Odd, didn't get the email
2019-12-09 16:20:46 <oliv3r[m]> well i can do search --exact pkgname | grep -q ${file%%.apk} or something;
2019-12-09 16:21:23 <oliv3r[m]> hmm, nope because pkgname of course would be only the name, not the full filename, i'd have to parse away the version fields, at which point its easy to just grep against -a
2019-12-09 16:22:00 <ddevault> Cogitri: https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E#%3CBZ10HOAT7Z8A.1DMTQFIGETY9K@homura%3E
2019-12-09 16:22:03 <ddevault> greylisting, maybe?
2019-12-09 16:22:05 <ddevault> dunno
2019-12-09 16:22:23 <ddevault> lists.a.o doesn't forward emails that you're already copied on, it leaves that up to the sender's MTA so you don't get it twice
2019-12-09 16:23:30 <ddevault> on the subject of these samu bug-for-bug issues being rare, I've never heard of it happening. Maybe tridactyla can comment?
2019-12-09 16:40:28 <Cogitri> Same, but some upstreams just refuse to accept bug reports with different tooling
2019-12-09 16:40:44 <Cogitri> And it's way easier to install ninja instead of arguing with upstream :)
2019-12-09 16:40:54 <ddevault> upstream doesn't have to know ;)
2019-12-09 16:41:08 <Cogitri> So big - from me for moving it to unmaintained, just moving to community seems like more than enough to me
2019-12-09 16:41:41 <Cogitri> Ninja isn't a high maintenance package, having it in community doesn't seem like a problem to me
2019-12-09 16:42:04 <ddevault> so you would rather go through all alpine packages and add a make dependency on samurai instead of ninja?
2019-12-09 16:42:12 <ddevault> it doesn't seem like a robust approach
2019-12-09 16:42:21 <ddevault> we're replacing it or we're not, I don't want to half ass it
2019-12-09 16:43:40 <Cogitri> Well, doing one -e `s/ninja -C/samu -C/g` -e `s/ninja/samurai/g` should catch about all occurrences of this
2019-12-09 16:43:54 <ddevault> I understand, but I still dislike it
2019-12-09 16:44:07 <ddevault> people complain about our use of busybox tools causing build problems, for example
2019-12-09 16:44:09 <ddevault> alpine is no stranger to this
2019-12-09 16:44:18 <Cogitri> Well, camouflaging samu as ninja just seems a bit hacky to me
2019-12-09 16:44:23 <ddevault> samu is a drop-in replacement, I say drop it in
2019-12-09 16:44:48 <ddevault> let's not hold up doing the right thing in expectation of an unlikely future
2019-12-09 16:44:55 <Cogitri> I was like that for pkgconf too on Alpine but when we did the switch from pkg-config to pkgconf more stuff than expected broke
2019-12-09 16:45:04 <Cogitri> s/on Alpine/on Void/
2019-12-09 16:45:04 <alpine-meetbot> Cogitri meant to say: I was like that for pkgconf too on Void but when we did the switch from pkg-config to pkgconf more stuff than expected broke
2019-12-09 16:45:28 <ddevault> that makes sense, because pkg-config is a complicated beast with lots of ways people (ab)use it
2019-12-09 16:45:36 <ddevault> ninja doesn't really have the same problems
2019-12-09 16:45:40 <Cogitri> Because we relied on some "bugs" which were features for cross compiling that pkgconf upstream didn't want to implement it
2019-12-09 16:46:15 <Cogitri> Well, possibly, but after that switch I'm sceptical of just camouflaging tools
2019-12-09 16:46:42 <Cogitri> I'm all for that with busybox since that does have a very good purpose - making the core image smaller
2019-12-09 16:47:01 <ddevault> similar benefits come from samu in that respect
2019-12-09 16:47:05 <Cogitri> But with ninja vs samu I don't think the advantages are great enough
2019-12-09 16:47:15 <ddevault> it's much simpler and smaller, reduces the C++ footprint in our build dependency tree, etc
2019-12-09 16:47:28 <Cogitri> Yes, but that is only installed on a very limited amount of machines
2019-12-09 16:47:35 <Cogitri> (Only dev machines)
2019-12-09 16:47:45 <ddevault> I don't like giving dev machines a second-class experience
2019-12-09 16:47:54 <ddevault> anyone could build packages for any reason at any time
2019-12-09 16:47:58 <ddevault> it's not limited to the members of this channel
2019-12-09 16:48:48 <ddevault> anyway, I see where you're coming from with the risk-averse approach to this idea
2019-12-09 16:48:58 <ddevault> but the risks with samurai are exceptionally small, much smaller than with e.g. pkgconf
2019-12-09 16:49:06 <ddevault> and I think the benefits are compelling
2019-12-09 16:49:57 <ddevault> and I'll remind you that despite those difficulties, alpine uses pkgconf to this day :)
2019-12-09 16:50:15 <ddevault> it's always been the alpine way to use the best software, in spite of the possibility of bad upstreams causing compatibility problems
2019-12-09 16:50:19 <ddevault> musl, busybox, pkgconf...
2019-12-09 16:52:34 <Cogitri> Hm, fair enough
2019-12-09 16:52:57 <tehcloud> Alpine forces people like me to make sure their sources are actually portable, and those kinds of choices are why I'm using it for that purpose
2019-12-09 16:53:02 <Cogitri> Can we maybe do something like with coreutils/busybox where if you install those they replace the symlinks to the busybox applet?
2019-12-09 16:53:19 <Cogitri> So samu symlinks to ninja unless you have ninja installed?
2019-12-09 16:53:23 <ddevault> I'd rather do that once we know that it'll be necessary, not before
2019-12-09 16:53:31 <ddevault> we don't have a pkg-config package
2019-12-09 16:53:53 <ddevault> honestly I am pretty confident that we will have exactly zero compatibility problems between ninja and samurai
2019-12-09 16:54:19 <_ikke_> ninja is easily recoverable in case we really need it
2019-12-09 16:55:39 <Cogitri> Hm, true that
2019-12-09 16:56:26 <Cogitri> Well, I guess when you're confident that it won't break stuff I don't mind the replacement, but I'm not looking forward to arguing with upstreams
2019-12-09 16:56:30 <ddevault> we can schedule rebuilds for everything which depends on ninja to be sure before the next release
2019-12-09 16:56:43 <ddevault> ~600 pkgs
2019-12-09 18:11:42 <kaey> you can also make samurai-ninja subpackage with single symlink
2019-12-09 18:13:11 <ddevault> what is py3-pygments doing in main
2019-12-09 18:24:30 <ddevault> what is ceph doing in main
2019-12-09 18:36:16 <ddevault> pygments -> because gtk+2.0
2019-12-09 18:36:19 <ddevault> what is gtk+2.0 doing in main
2019-12-09 18:41:21 <mps> ceph is moved because of qemu, iirc
2019-12-09 18:54:49 <artok> what ceph has to do with qemu?
2019-12-09 18:55:36 <mps> rbd deps, iirc
2019-12-09 18:57:30 <artok> oh yeah it supports now that
2019-12-09 19:00:10 <ddevault> qemu should be in community too imo
2019-12-09 19:00:10 <_ikke_> ddevault: probably still there from before community existed and nobody bothered to move it yet
2019-12-09 19:00:34 <_ikke_> I recall clandmeter and ncopa discussing moving qemu
2019-12-09 19:01:56 <mps> (what will stay in main at the end)
2019-12-09 19:02:10 <ddevault> self-hosting base system
2019-12-09 19:02:32 <mps> weechat and irsii in main?
2019-12-09 19:02:34 <ddevault> apk, linux, and everything necessary to build, install, and maintain the system
2019-12-09 19:02:43 <ddevault> I'd vote against weechat and irssi in main
2019-12-09 19:02:50 <ddevault> for vim and nano, though
2019-12-09 19:03:04 <_ikke_> A lot of it is just history
2019-12-09 19:03:46 <mps> I'd vote for more repos/subdirs
2019-12-09 19:04:17 <ddevault> I don't want it to be overcomplex, I just want main to be small
2019-12-09 19:04:31 <ddevault> I don't want FreeBSD style separation
2019-12-09 19:04:36 <ddevault> s/FreeBSD/ports/
2019-12-09 19:04:36 <alpine-meetbot> ddevault meant to say: I don't want ports style separation
2019-12-09 19:04:57 <_ikke_> mps: what would that help?
2019-12-09 19:05:54 <mps> I'm for system where we can keep system programs/servers and similar
2019-12-09 19:06:40 <mps> and maybe DE
2019-12-09 19:06:49 <mps> DE subdir*
2019-12-09 19:07:06 <_ikke_> I don't see how that helps things rather than complicate things more
2019-12-09 19:07:07 <ddevault> yeah, the last thing I want is a de subdir
2019-12-09 19:07:42 <ddevault> imo main is defined as the minimum practical self-hosting base system, testing is defined as an incubation room for new packages, and community is defined as everything else
2019-12-09 19:07:58 <_ikke_> ddevault: main is also for things we want to give long term support for
2019-12-09 19:08:07 <_ikke_> which is more then just a bare minimum system
2019-12-09 19:08:13 <ddevault> maybe base/main/community/testing would be better
2019-12-09 19:08:19 <artok> mps, having packages somewhere to download?
2019-12-09 19:08:34 <mps> I'm out of home now
2019-12-09 19:08:48 <artok> ok
2019-12-09 19:09:18 <mps> ask _ikke_ to copy from my armv7 lxc somewhere
2019-12-09 19:09:27 <_ikke_> I can do that
2019-12-09 19:09:32 <_ikke_> What should I copy?
2019-12-09 19:09:44 <mps>  /home/mps/packages/main/arvm7
2019-12-09 19:09:51 <_ikke_> everything?
2019-12-09 19:10:08 <mps> linux-rpi* and linux-firmware*
2019-12-09 19:10:18 <_ikke_> ok
2019-12-09 19:10:21 <artok> did you do the installer packages?
2019-12-09 19:10:55 <mps> _ikke_: mps-edge-armv7 usa4
2019-12-09 19:11:00 <_ikke_> yes, found it already :)
2019-12-09 19:11:03 <mps> artok: no
2019-12-09 19:11:18 <mps> just what you asked for
2019-12-09 19:13:40 <artok> didn't I ask for those installers?
2019-12-09 19:13:50 <artok> might be =)
2019-12-09 19:14:26 <mps> could be but don't remember, sorry
2019-12-09 19:14:40 <artok> but no worries, that runs on cross platform =)
2019-12-09 19:22:03 <artok> I'm still in middle of provisioning my scaleway aarch64 machine
2019-12-09 20:05:37 <Cogitri> Can someone merge !1997 for me? My laptop is still MIA so I can't merge it
2019-12-09 20:07:18 <_ikke_> done
2019-12-09 20:07:29 <Cogitri> Thank you :)
2019-12-09 20:07:59 <Cogitri> Also, since the ProtonMail android app apparently allows HTML email so I can't send this to the mailing list:
2019-12-09 20:08:00 <Cogitri> How about adding a issue template to Gitlab?
2019-12-09 20:08:21 <Cogitri> Where users have to check some stuff before submitting bugs ala:
2019-12-09 20:08:38 <Cogitri> - [ ] I have made sure that my system is fully upgraded, if not why:
2019-12-09 20:08:56 <Cogitri> - [ ] I have included logs, if necessary
2019-12-09 20:08:58 <Cogitri> etc.
2019-12-09 20:09:16 <_ikke_> I hate those :|
2019-12-09 20:09:19 <Cogitri> (I have noticed a lot of issues which could've been caught by the first one already)
2019-12-09 20:09:52 <_ikke_> Add a lot of cruft (I'd like it better if it was just commentary that is not visible in the actual report)
2019-12-09 20:10:10 <Cogitri> I think that works if we just put HTML style comments around it
2019-12-09 20:10:21 <Cogitri> At least that works on GitHub, not quite sure if it does with GitLab too
2019-12-09 20:11:03 <_ikke_> The issue with a lot of those templates is that they only work for a very specific sort of issue
2019-12-09 20:13:58 <Cogitri> Yes, they're often ignored when they don't match the problem well, but I feel like some basic checkmarks would improve the quality of the issues
2019-12-09 20:14:15 <_ikke_> The problem is when they are not ignored if they don't match the problem :)
2019-12-09 20:14:23 <_ikke_> then you get these very broken reports
2019-12-09 20:14:45 <Cogitri> Hm, I haven't seen that yet, but fair enough
2019-12-09 20:14:54 <_ikke_> I see that all the time
2019-12-09 20:21:24 <tridactyla> ddevault: regarding samurai-ninja compatibility, i think the only thing that might matter is differing build execution order causing failures due to insufficiently specified dependencies in the package
2019-12-09 20:21:49 <ddevault> tridactyla: have you ever seen this happen in practice?
2019-12-09 20:21:56 <tridactyla> this is always a bug in the package though, not ninja or samurai
2019-12-09 20:23:04 <Cogitri> I have seen it happen lots with ninja, not sure if samurai would show different behaviour though
2019-12-09 20:23:28 <Cogitri> (For some reason this happens especially often with ppc64le, not sure if that builder simply has the most builders though)
2019-12-09 20:23:39 <Cogitri> s/builders/build jobs/
2019-12-09 20:23:39 <alpine-meetbot> Cogitri meant to say: (For some reason this happens especially often with ppc64le, not sure if that builder simply has the most build jobs though)
2019-12-09 20:23:50 <ddevault> that's surprising, in more ways than one
2019-12-09 20:23:54 <ddevault> do you have a build log somewhere?
2019-12-09 20:25:47 <tridactyla> ddevault: yeah, i have seen it occasionally
2019-12-09 20:26:06 <ddevault> bugs in e.g. meson or something closer upstream?
2019-12-09 20:26:36 <tridactyla> the package itself in the meson/cmake files
2019-12-09 20:29:36 <Cogitri> NetworkManager still has the bug I think
2019-12-09 20:30:36 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/blob/master/community/networkmanager/APKBUILD#L83
2019-12-09 20:30:55 <tridactyla> the only other compatibility issue i'm aware of is https://github.com/ninja-build/ninja/issues/1516, which i've never run into in practice
2019-12-09 20:31:16 <Cogitri> I think greping for `ninja -C output .*` might yield more cases of this, but can't check
2019-12-09 20:41:26 <clandmeter> mps: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e7096c131e5161fa3b8e52a650d7719d2857adfd
2019-12-09 21:25:44 <mps> clandmeter: thanks, hope it will be backported to 5.4
2019-12-09 21:26:07 <_ikke_> why would it?
2019-12-09 21:26:44 <mps> although is look like simple cherry-pick will work
2019-12-09 21:27:07 <mps> _ikke_: have it in linux-lts and not separate pkg
2019-12-09 21:27:24 <_ikke_> mps: you mean backported by alpine?
2019-12-09 21:27:40 <mps> no, to 5.4.x LTS upstream
2019-12-09 21:28:04 <_ikke_> But why would upstream backport new features?
2019-12-09 21:28:10 <mps> but also doesn't look complicated to alpine linux-lts directrly
2019-12-09 21:28:40 <mps> this is one of important and asked for few years
2019-12-09 21:29:01 <_ikke_> sure, but that does not mean they have to backport it
2019-12-09 21:29:09 <mps> I build my kernels always by creating patch from WG git tree
2019-12-09 21:29:33 <_ikke_> I mean, it would be nice, but I don't expect upstream to backport it
2019-12-09 21:30:08 <mps> it is so simple: /home/WireGuard/contrib/kernel-tree/create-patch.sh > wg-gru.patch
2019-12-09 21:30:17 <_ikke_> it's not about how hard it is
2019-12-09 21:30:18 <mps> patch -p1 < wg-gru.patch
2019-12-09 21:31:55 <mps> no, but maintain separate pkg is burden anyway
2019-12-09 21:33:43 <clandmeter> I think we can use vanilla to have not let's kernels
2019-12-09 21:34:14 <Cogitri> I'd just keep using the external wg module until it's in the kernel we use, that way we don't have to deal with odd breakages
2019-12-09 21:42:59 <mps> hm, we patch a lot of things anyway
2019-12-09 22:43:20 <clandmeter> features dont get backported.
2019-12-09 22:43:47 <clandmeter> i think we could have vanilla follow latest kernel
2019-12-09 22:45:51 <mps> clandmeter: iiuc, that is a plan
2019-12-09 22:46:39 <mps> although name sounds 'strange' to me, but I don't know fine points of english
2019-12-09 23:17:16 <tmhoang> _ikke_, ncopa: when you have a minute, please help me https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2021. This is needed for new kernel change, older version of s390-tools would not boot with newer kernels.
2019-12-10 01:18:10 <kaniini> mps: i wonder if we should try to organize an irc channel and mailing list for discussing running alpine on x86 and aarch64 chromebooks
2019-12-10 01:18:26 <kaniini> i suspect the combination of alpine + chromebooks to be a useful computing platform
2019-12-10 01:55:07 <artok> when booting rpi, I'm getting those busybox missing links
2019-12-10 02:26:43 <artok> and seems that rpi people are still in 5.4.1
2019-12-10 03:06:10 <artok> in meantime, if anyone interested, aarch64 install boots on rpi3 and rpi4 nicely
2019-12-10 03:06:50 <artok> other than that busybox thingie
2019-12-10 07:39:22 <telmich> when browsing aports via web on gitlab, I see the message " Too many items to show. To preserve performance only 1,000 of 1,990 items are displayed. " at the top
2019-12-10 07:40:00 <telmich> While I am being warned, not showing all items/packages, prevents me from ctrl-f searching in the lists
2019-12-10 07:40:15 <telmich> I was wondering if anyone could checkout if that limit can be raised to maybe 10k?
2019-12-10 07:50:14 <Cogitri> That'll make gitlab rather slow, it already takes some 10 seconds to load community/
2019-12-10 07:50:23 <Cogitri> I'd suggest you clone the repo and do find instead
2019-12-10 08:25:48 <_ikke_> or use git.a.o
2019-12-10 08:26:02 <_ikke_> https://git.alpinelinux.org/aports/tree/main
2019-12-10 08:26:14 <_ikke_> https://git.alpinelinux.org/aports/tree/community/
2019-12-10 08:28:14 <Cogitri> Or that, yes
2019-12-10 08:53:00 <north1> Installed new alpine system on ZFS and i'm getting permission denied errors on the src/ directory of abuild when using dabuild
2019-12-10 08:53:16 <north1> any idea of what is wrong ? i have set up abuild group and permissions on /var/cache/distfiles
2019-12-10 08:54:02 <north1> it works without docker-abuild
2019-12-10 08:54:46 <_ikke_> different uids?
2019-12-10 08:54:54 <north1> oh
2019-12-10 08:55:12 <north1> can make sense, my UUID on the new system is 1001 instead of 1000
2019-12-10 09:06:19 <north1> Yep
2019-12-10 09:06:23 <north1> all work now, thanks @ikke
2019-12-10 09:06:56 <_ikke_> :)
2019-12-10 09:07:14 <_ikke_> how did you end up with uid 1001 btw?
2019-12-10 09:07:24 <north1> created another account before
2019-12-10 09:07:40 <_ikke_> sounds kind of logical :)
2019-12-10 09:16:26 <mps> kaniini: I'm not against you idea, but maybe we can continue here and #alpine-linux to have broader audience and attract more interested people (developers and testers)
2019-12-10 09:16:42 <alpine-meetbot> mps meant to say: kaniini: I'm not against your idea, but maybe we can continue here and #alpine-linux to have broader audience and attract more interested people (developers and testers)
2019-12-10 09:16:42 <mps> s/you/your/
2019-12-10 09:18:44 <mps> about mailing list, I'm for it but if we can use something better than current Alpine ML system (I stopped to post to current ML because I don't like how it works)
2019-12-10 09:19:49 <mps> and, maybe we can consider more broader 'theme' than only chromebooks, something like 'Alpine on ARM'
2019-12-10 09:21:31 <mps> (my interest to x86 is faded few years ago, although I still use it because this arch is everywhere and cannot ignore it)
2019-12-10 10:30:24 <russkel> how much exposure to the underlying arch do you get these days?
2019-12-10 10:30:46 <_ikke_> russkel: bugs like spectre/smeltdown?
2019-12-10 10:30:47 <russkel> or is that just your thing to pick on :D?
2019-12-10 10:30:56 <russkel> fair
2019-12-10 10:31:23 <russkel> I haven't heard much fall out over that, any attacks used out in the wild?
2019-12-10 10:31:30 <russkel> APTs using them yet?
2019-12-10 10:31:45 <PureTryOut[m]> mps: why not Alpine on laptops/desktop in general?
2019-12-10 10:31:47 <_ikke_> russkel: I think the bigger impact is the performance drop all the mitigations are causing
2019-12-10 10:32:18 <PureTryOut[m]> uh, kaniini rather
2019-12-10 10:32:54 <mps> PureTryOut[m]: imo, desktop is separate topic
2019-12-10 10:33:12 <PureTryOut[m]> Separate from Chromebooks? How so?
2019-12-10 10:33:35 <mps> with 'Alpine on ARM' I mean base system, boot loaders, kernels and tools for that
2019-12-10 10:33:45 <russkel> on second thought is that necessarily an x86 specific thing? I thought it was a side effect of branch prediction/other optimisations on intel chips
2019-12-10 10:34:44 <mps> PureTryOut[m]: think of these as layers in onion
2019-12-10 10:35:25 <_ikke_> russkel: right, not necessarily an ISA issue
2019-12-10 10:35:43 <mps> PureTryOut[m]: when I got base (boot loader, kernel and tools) I don't have much issues with userspace
2019-12-10 10:36:59 <mps> there are some things in userspace (lima, panfrost for example) but without base system these are not important
2019-12-10 10:38:04 <mps> and, btw I don't see big issue with 'Alpine on Desktop', it is quite fine, imo
2019-12-10 10:40:13 <russkel> I'm more of an Alpine on a robot
2019-12-10 10:40:15 <russkel> kind of guy
2019-12-10 10:40:28 <russkel> :D
2019-12-10 10:40:51 <mps> russkel: hi ROS :)
2019-12-10 10:41:39 <russkel> I had another framework already working on it haha
2019-12-10 10:41:58 <russkel> but yes ROS is the next step
2019-12-10 10:45:01 <mps> ncopa: I half finished linux-lts armv7 changes. Tested on one real board and it works quite fine, things which I tested
2019-12-10 10:45:32 <mps> later (at night, I thinl) will test on two more boards
2019-12-10 10:46:12 <russkel> ooh which board mps?
2019-12-10 10:46:28 <mps> only have issues on exynos, but we didn't had kernel which worked on exynos afaik
2019-12-10 10:46:45 <russkel> is that the processor the odroids use?
2019-12-10 10:46:57 <mps> russkel: leemaker bananapi and one cubie board
2019-12-10 10:47:24 <mps> russkel: some versions of odroid use exynos
2019-12-10 10:47:44 <russkel> 
ACTION nods

2019-12-10 10:47:58 <russkel> I have an orange pi zero plus 2
2019-12-10 10:48:06 <russkel> that has been troubles since day one
2019-12-10 10:48:24 <mps> I can't remember right now which odroid use which exynos version
2019-12-10 10:48:49 <mps> orange uses Allwinner SOC's, mostly
2019-12-10 10:49:06 <mps> oranges*
2019-12-10 10:49:16 <russkel> XU4 uses Exynos5 Octa apparently
2019-12-10 10:49:41 <mps> I think so
2019-12-10 10:50:12 <mps> I have exynos5 octa but in chromebook (samsung)
2019-12-10 10:52:01 <mps> ncopa: when you find time please ping me so I can post changes in config-lts.armv7, a lot of changes :)
2019-12-10 10:52:34 <mps> (and we need more testers with arm)
2019-12-10 10:52:40 <mps> and devs, ofc
2019-12-10 10:53:43 <russkel> does alpine-arm closely track mainline linux kernel?
2019-12-10 10:54:54 <mps> currently all alpine kernels are built from mainline
2019-12-10 10:55:36 <mps> RPI kernels are little different but not much
2019-12-10 10:56:32 <russkel> just did a search on pkgs.a.o for linux, bit confusing
2019-12-10 10:56:38 <mps> small patches and different config
2019-12-10 10:56:44 <russkel> linux-vanilla is behind linux-lts
2019-12-10 10:57:10 <mps> till now linux-vanilla was only kernel
2019-12-10 10:58:02 <mps> now it will be linux-lts, and what will be done with -vanilla I'm not sure. Depends on BDFL :)
2019-12-10 10:58:37 <russkel> lots of stuff added to the kernel in the SoC space
2019-12-10 10:59:24 <mps> yes, and lot things now works and lot works better
2019-12-10 11:00:02 <mps> 5.5-rc1 have a lot more fine things for ARM
2019-12-10 11:00:51 <kaniini> PureTryOut[m]: there are specialized concerns involving chromebooks
2019-12-10 11:01:12 <kaniini> PureTryOut[m]: it is kind of a hellish mashup between the work you are doing in pmOS and normal desktop packaging
2019-12-10 11:02:07 <russkel> mps, any tools for customising the device trees etc?
2019-12-10 11:04:16 <mps> russkel: not much that I know (except 'vim' :) )
2019-12-10 11:04:37 <russkel> some distros like to help out with that kind of thing
2019-12-10 11:04:41 <russkel> I think armbian being one
2019-12-10 11:05:15 <russkel> I quite like armbian I have to say
2019-12-10 11:05:17 <mps> imo, best is alarm, Arch linux ARM
2019-12-10 11:05:41 <russkel> I've tried to install that once and didn't get anywhere
2019-12-10 11:06:00 <russkel> is a shame because I like arch. my desktop is manjaro
2019-12-10 11:06:06 <mps> I used armbian for some time but it is not good, slow at first
2019-12-10 11:06:35 <russkel> slow why?
2019-12-10 11:07:06 <mps> try to install alpine on same board and you will understand what I say :)
2019-12-10 11:07:23 <russkel> :D
2019-12-10 11:07:40 <russkel> I'm not disagreeing, just curious as to why it is slower
2019-12-10 11:08:10 <mps> systemd, glibc and probably some other crufts
2019-12-10 11:08:51 <russkel> fair points
2019-12-10 11:09:21 <russkel> I should try get alpine rolling on it, although I'm dreading setting up drivers for wifi etc
2019-12-10 11:09:29 <mps> when I switched my mail server from armbian to alpine I first thought alpine fakes me (because difference in speed)  and will trash my mails
2019-12-10 11:09:52 <mps> my mail server is on arm board
2019-12-10 11:10:52 <mps> (dns, dhcp, web server, wifi router, adsl etc, all on one old SBC)
2019-12-10 11:11:06 <russkel> what mail server?
2019-12-10 11:11:29 <mps> postfix, if you ask which software
2019-12-10 11:11:39 <mps> and dovecot
2019-12-10 11:11:55 <mps> plus postgrey
2019-12-10 11:12:17 <russkel> I use[d] dovecot and that other one
2019-12-10 11:12:29 <russkel> damn forgot the name
2019-12-10 11:12:58 <russkel> exim
2019-12-10 11:13:17 <russkel> They use so much RAM!! For what?!?
2019-12-10 11:13:17 <mps> debian inheritance :)
2019-12-10 11:13:44 <russkel> I kind of want to write a lightweight one in Rust as an experiment
2019-12-10 11:14:01 <mps> heritage? (self taught in english, sorry)
2019-12-10 11:14:17 <russkel> heritage works
2019-12-10 11:14:24 <mps> lightweight in Rust? :D
2019-12-10 11:15:06 <russkel> I simply don't understand why I can't run a mailserver setup in less than 512mb of RAM
2019-12-10 11:15:23 <mps> (hipsters never made anything good)
2019-12-10 11:15:42 <russkel> you don't like Rust?
2019-12-10 11:16:03 <mps> it depends on how much mail server have to handle
2019-12-10 11:16:37 <mps> Rust is one of the worst langs after python
2019-12-10 11:27:24 <Cogitri> Rust's amazing other than static linking the mircrodeps in - but that's not much different compared to about every other modern lang
2019-12-10 11:27:24 <Cogitri> <mps "Rust is one of the worst langs a"> -1 on that :P
2019-12-10 11:29:41 <mps> Cogitri: -1 :)
2019-12-10 11:31:32 <Cogitri> I do write some stuff in D now though to get that sweet, sweet dynamic linking
2019-12-10 11:34:28 <russkel> -l ?
2019-12-10 11:35:19 <russkel> I haven't used Rust much but I really enjoyed using it
2019-12-10 11:35:46 <russkel> python is great what are you talking about!? :D
2019-12-10 11:36:40 <russkel> a straightforward, clean and easy to use language with a competent stdlib and an amazing ecosystem of libs
2019-12-10 11:38:15 <mps> we should move this discussion to #alpine-offtopic, really
2019-12-10 16:51:45 <andypost[m]> Is this a right way to provide BC for sub-packages? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2030/diffs#22c872dc3fc831e19e6e8160c8d206064ce1b84d_48_50
2019-12-10 18:22:50 <_ikke_> nmeum: ctags broke on a few arches
2019-12-10 18:23:14 <north1> That is annoying, it passes on CI and fails on Builders.
2019-12-10 18:32:54 <_ikke_> stderr                                                      mfailed (diff: /home/buildozer/aports/main/ctags/src/ctags-2ebf5b1bed1f8ce2f2cccec66e613cd33bcee571/Tmain/enable-kind-prefix-with-wildcard.d/stderr-diff.txt)
2019-12-10 22:19:23 <mps> Arch linux ARM (alarm) kernel use patch for wireguard, and take this patch from debian
2019-12-10 23:08:22 <clandmeter> https://git.alpinelinux.org/abuild/commit/abuild.in?id=b8b8a651fc147669e3e811f55198305b97c1001c
2019-12-10 23:08:45 <clandmeter> tmhoang: thats that one that causes the busybox errors
2019-12-11 01:13:29 <kaniini> I think we should have a talk about procmail
2019-12-11 01:14:02 <kaniini> it presently FTBFS (for me) on mips64 and also on x86_64
2019-12-11 01:14:16 <kaniini> procmail is a giant security hole
2019-12-11 01:14:33 <kaniini> it's upstream maintainer literally advises users to use anything else
2019-12-11 01:14:47 <kaniini> I propose we remove it before 3.11 release on QA grounds
2019-12-11 02:07:28 <north1> Oh, git just got a lot of windows/NTFS-specific CVEs
2019-12-11 05:33:03 <_ikke_> north1: yeah, I've upgraded git already
2019-12-11 05:36:46 <north1> Ah then please close the MRs jowi made please
2019-12-11 05:52:08 <_ikke_> done
2019-12-11 06:01:57 <north1> Ty
2019-12-11 06:12:37 <tmhoang> @clandmeter> tmhoang: thats that one that causes the busybox errors : ---> waiting for clandmeter's fix :D
2019-12-11 06:13:59 <tmhoang> I should start using snapshot edge's netboot images more frequently
2019-12-11 06:14:48 <tmhoang> so if that commit is the cause,  then it could be detected sooner
2019-12-11 06:18:39 <tmhoang> ah north1 is JOWI
2019-12-11 06:19:53 <north1> I know but I couldn't give myself the effort
2019-12-11 06:20:08 <tmhoang> give more :P
2019-12-11 06:22:34 <north1> Not while I'm laying in bed
2019-12-11 06:52:04 <tmhoang> clandmeter: maybe https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2033
2019-12-11 06:56:58 <ncopa> morning
2019-12-11 07:09:29 <north1> oh sweet
2019-12-11 07:09:35 <north1> it wasn't only my system having lockups with kernel 5.4+
2019-12-11 07:09:45 <north1> ^ sounds very bad btw
2019-12-11 07:11:02 <north1> https://gitlab.freedesktop.org/drm/intel/issues/674 https://cgit.freedesktop.org/drm-tip
2019-12-11 08:09:47 <clandmeter> tmhoang: i already pushed a fix
2019-12-11 08:10:43 <tmhoang> ah https://git.alpinelinux.org/aports/log/?qt=author&q=meter
2019-12-11 08:11:16 <tmhoang> it's interesting lastname : Landmeter
2019-12-11 08:12:40 <clandmeter> Many ncopa want to fix it in another place
2019-12-11 08:13:01 <clandmeter> This just fixes the current issue
2019-12-11 08:15:32 <tmhoang> clandmeter: acked. also the warning is gone in x86's bb-1.31.1-r3.
2019-12-11 08:16:13 <tmhoang> ouch ctags fail on s390x
2019-12-11 08:20:38 <_ikke_> tmhoang: literally translated: "land measurer"
2019-12-11 08:23:39 <north1> /bin/busybox mkdir -p "/bin"
2019-12-11 08:23:54 <north1> ^ that's a good one
2019-12-11 08:28:07 <clandmeter> north1: ?
2019-12-11 08:29:26 <_ikke_> I guess directly calling busybox because mkdir does not exist yet without the syminks?
2019-12-11 08:29:46 <north1> calling /bin/busybox to create /bin
2019-12-11 08:29:54 <clandmeter>  /bin is not the right dir
2019-12-11 08:29:56 <north1> if you are calling /bin/busybox then obviously /bin exists
2019-12-11 08:30:00 <_ikke_> nod
2019-12-11 08:30:09 <north1> otherwise /bin/busybox will fail in the first place
2019-12-11 08:30:13 <clandmeter> busybox uses /usr/bin
2019-12-11 08:30:17 <clandmeter> by default
2019-12-11 08:31:03 <_ikke_> clandmeter: the script calls /bin/busybox to create /bin
2019-12-11 08:31:38 <artok> or /usr/bin ?
2019-12-11 08:31:47 <_ikke_> that's not the point
2019-12-11 08:32:07 <_ikke_> creating /bin by calling a binary in that directory
2019-12-11 08:32:22 <artok> yeah but where is that script you're talking about? =)
2019-12-11 08:32:41 <_ikke_> https://git.alpinelinux.org/aports/commit/?id=883eee9a
2019-12-11 08:33:00 <_ikke_> it's just redundant
2019-12-11 08:33:03 <artok> aah another commit there
2019-12-11 08:33:23 <clandmeter> somebody commited over my commit
2019-12-11 08:33:35 <clandmeter> i have no clue why its changed
2019-12-11 08:34:02 <_ikke_> I guess ncopa merged the MR from oliv3r[m] and fixed the conflicts?
2019-12-11 08:34:33 <clandmeter> now it creates more dirs which are not actually involved
2019-12-11 08:35:17 <_ikke_> clandmeter: according to oliv3r[m] they are
2019-12-11 08:35:51 <clandmeter> ah maybe so
2019-12-11 08:36:01 <clandmeter> they were already exiting, i didnt verify that.
2019-12-11 08:36:18 <clandmeter> ncopa didnt clean those empty dirs
2019-12-11 08:36:23 <_ikke_> http://tpaste.us/vJNo
2019-12-11 08:42:07 <ncopa> $ busybox --list-applets | tpaste
2019-12-11 08:42:07 <ncopa> http://tpaste.us/QnR0
2019-12-11 08:42:44 <ncopa> i merged the MR
2019-12-11 08:43:02 <ncopa> yeah, /bin was not needed
2019-12-11 08:43:04 <clandmeter> i didnt notice there was one :)
2019-12-11 08:43:24 <clandmeter> i tracked it back to the cleanup change
2019-12-11 08:43:40 <clandmeter> i guess the noempty option sounds sane for baselayout
2019-12-11 08:43:51 <clandmeter> err keepempty or whatever
2019-12-11 08:43:51 <ncopa> we need an options="keepdirs" or similar
2019-12-11 08:44:09 <ncopa> yeah
2019-12-11 08:44:14 <Cogitri> ncopa: Can't reply on ML, but +1 to your re: samurai vs ninja, having both available would be nice and I'm not so sure if upstreams support builds with samu (I'd certainly ask the build to be done with ninja too before a bug report)
2019-12-11 08:44:43 <ncopa> Cogitri: why cannot you reply on ML?
2019-12-11 08:48:02 <tmhoang> yay we decided to upgrade and change upstream for ctags
2019-12-11 08:48:32 <north1> ncopa (IRC): I talked about the emptydirs option that is found on archlinux's pkgbuild
2019-12-11 08:48:44 <ncopa> yeah, i think that makes sense
2019-12-11 08:50:56 <ncopa> i need to go out for a while
2019-12-11 08:50:57 <ncopa> bblm
2019-12-11 08:51:28 <ncopa> s/bblm/bbl/
2019-12-11 08:51:28 <alpine-meetbot> ncopa meant to say: bbl
2019-12-11 08:54:04 <Cogitri> ncopa: I don't have my laptop right now (in repair again) and the ProtonMail android app can only do HTML email
2019-12-11 09:17:37 <nmeum> _ikke_: re ctags, just waking up but if it's still an issue could you give me access to stderr-diff.txt?
2019-12-11 09:18:39 <_ikke_> nmeum: yes, still an issue
2019-12-11 09:18:41 <_ikke_> nmeum: let me see
2019-12-11 09:19:18 <_ikke_> it's s390x, I have no access there
2019-12-11 09:43:02 <tmhoang> nmeum: 1 sec
2019-12-11 09:43:33 <tmhoang> brb
2019-12-11 10:12:52 <nmeum> gotta get to work, will try to look into it asap
2019-12-11 11:04:43 <nmeum> hm, I can actually reproduce the test failure on s390x
2019-12-11 11:04:49 <nmeum> how did this pass on the ci? Oo
2019-12-11 11:09:39 <nmeum> most failures seem to be related to some regex warning `regexp missing name pattern` which causes the stderr output to not match
2019-12-11 11:10:15 <nmeum> I guess the quick fix for this would be disabling the ctags tests on s390x and reporting this upstream?
2019-12-11 11:17:08 <_ikke_> nmeum: did the job even run on s390x? A lot of jobs are timing out atm
2019-12-11 11:23:59 <nmeum> _ikke_: it timed out indeed
2019-12-11 11:24:42 <_ikke_> tmhoang: would be nice if we could schedule a moment to find out why this is happening
2019-12-11 12:18:45 <nmeum> disabled the ctags testsuite for now to unblock the builder and reported this upstream. If I get around to it I may investigate this further, just wanted to unblock the builder for now
2019-12-11 12:19:27 <_ikke_> (y)
2019-12-11 12:24:38 <_ikke_> now someone should look at kea
2019-12-11 12:24:44 <_ikke_> still failing to build on aarch64
2019-12-11 12:25:07 <andypost[m]> I'd like to get one more eye on !2030 for BC before merging
2019-12-11 12:25:27 <_ikke_> BC?
2019-12-11 12:25:58 <Cogitri> lgtm I guess
2019-12-11 12:26:11 <Cogitri> (Forgot to approve on Gitlab when taking a look at it earlier)
2019-12-11 12:26:12 <mps> kea, DCTL_CONFIG_FILE_LOAD_FAIL Control-agent reason: unable to setup TCP acceptor for listening to the incoming HTTP requests: bind: Address in use
2019-12-11 12:26:25 <mps> _ikke_: ^
2019-12-11 12:26:43 <_ikke_> Yes, I've seen that in the logs, just wondering why it happens
2019-12-11 12:26:53 <mps> is the aarch64 builder in 'clean' state
2019-12-11 12:28:32 <_ikke_> Looks like an stunnel process is still running
2019-12-11 12:29:08 <mps> I'll resync aarch64 lxc now, and try to build kea
2019-12-11 12:50:08 <tmhoang> _ikke_ nmeum: just found the 1989 MR. I'm also looking into the test suites.
2019-12-11 12:50:18 <tmhoang> _ikke_ : you mean the time out issue ? I have time now.
2019-12-11 12:50:27 <north1> @tmhoang !1989 can be used to refer to it with algitbot support
2019-12-11 12:51:09 <tmhoang> it looks to me from the 1989 (yeah don't want to put ! for spamming :D ) that it times out waiting for the gitlab runner container
2019-12-11 12:51:18 <_ikke_> tmhoang: Somehow cloning aports on that builder seems to hang
2019-12-11 12:51:24 <ncopa> kea builds in my aarch64 dev env
2019-12-11 12:51:43 <_ikke_> ncopa: yes, it built now on the builder as well
2019-12-11 12:51:49 <ncopa> ok
2019-12-11 12:51:50 <_ikke_> there was a stray stunnel process left behind
2019-12-11 12:52:40 <mps> ah, you saved me some time :)
2019-12-11 12:53:14 <_ikke_> mps: you pointed me in the right direction :)
2019-12-11 12:53:45 <tmhoang> _ikke_: do you mind if I login s390x-ci.a.o and run a cron job  or a script or so to see how frequently git clone keeps timing out, so that I will have evidence to tell admins that their infra has problem. Make sense ?
2019-12-11 12:53:55 <tmhoang> _ikke_ : there was a stray stunnel process left behind >> this is for the s390-ci ?
2019-12-11 12:53:56 <_ikke_> tmhoang: sure, np
2019-12-11 12:54:03 <_ikke_> tmhoang: no, that was about kea
2019-12-11 12:54:09 <tmhoang> ok
2019-12-11 12:54:30 <_ikke_> afaik it's always git index-pack that is having issues
2019-12-11 12:54:40 <tmhoang> do we git clone --depth 1 ?
2019-12-11 12:54:43 <_ikke_> no
2019-12-11 12:54:57 <tmhoang> aports is huge  you know
2019-12-11 12:55:01 <_ikke_> yes, I know
2019-12-11 12:55:19 <_ikke_> But to calculate the correct diffs, we need at least some history
2019-12-11 12:55:38 <_ikke_> I did try with a highter depth, but even there we missed commits
2019-12-11 12:55:49 <tmhoang> yep, make sense
2019-12-11 12:56:39 <_ikke_> I have another solution in mind (basically incrementally increase depth until we have everything we need), but I need to test / implement that
2019-12-11 12:57:08 <tmhoang> nah would cost more time for you, I would just run git with debug mode to see and collect debug message and report to admins
2019-12-11 12:57:41 <tmhoang> we have some other servers over there and also see this hanging issue ...
2019-12-11 12:57:52 <_ikke_> And gitlab should also cache the repo, so it should not have to completely clone the entire aports
2019-12-11 12:57:53 <tmhoang> time to report
2019-12-11 12:58:05 <_ikke_> At least, once for every user
2019-12-11 14:52:09 <mps> is Michael Pirogov here?
2019-12-11 14:52:51 <mps> I want to push !2055 and later for perl-redis
2019-12-11 15:55:48 <oliv3r[m]> clandmeter well /bin isn't strictly needed if it exists and your busybox lives there, but busybox install will install to /bin, /usr/bin /sbin and /usr/sbin. For example, I can imagine that you' dwant to do bbb="$(mktemp -p "${chrootpath}/${TMPDIR:-/tmp}")" cp "${BBB}" bbb; chroot "${chrootpath}" "${bbb#${chrootpath}}" --install -s
2019-12-11 15:56:04 <oliv3r[m]> but I think we can close !2033 as ncopa did indeed merge and resolve the conflict :)
2019-12-11 15:58:05 <_ikke_> oliv3r[m]: the fact that you can call /bin/busybox means that /bin must already exist :)
2019-12-11 15:58:37 <oliv3r[m]> in this exact example, of course :) that's why I gave you the 'copy/chroot' example :)
2019-12-11 15:58:46 <_ikke_> yup
2019-12-11 15:58:59 <oliv3r[m]> I just wanted to state, busybox requires those 4 paths; so lets be proper, and create all 4 :)
2019-12-11 16:00:17 <oliv3r[m]> but you are right, technically, you can _assume_ quit safetly it exists, but lets not do assumptions (how obvious they are)
2019-12-11 16:00:18 <oliv3r[m]> still would be far better for busybox to create it's own files; so maybe during xmas i'll play with that
2019-12-11 16:01:03 <mps> aren't these paths in alpine-base?
2019-12-11 16:01:49 <_ikke_> no
2019-12-11 16:02:11 <_ikke_> abuild now actively removes those if they are empty
2019-12-11 16:02:40 <mps> it should not
2019-12-11 16:03:16 <north1> there are plans to add !emptydirs or keepdirs to options=""
2019-12-11 16:22:14 <artok> btw "if they are empty" is not what happens
2019-12-11 16:23:40 <artok> oh wait
2019-12-11 16:25:03 <artok> forgot rmdir command usage
2019-12-11 16:25:09 <artok> as you were...
2019-12-11 16:32:53 <ncopa> seems like we currently only delete /usr/lib /usr/bin /usr/share /usr or /etc if empty
2019-12-11 16:32:55 <ncopa> and thats it
2019-12-11 16:33:19 <ncopa> so nothing was actually deleted in alpine-baselayout
2019-12-11 17:07:50 <_ikke_> Yes, but there was a proposal to add those dirs to that package, which would then not work
2019-12-11 17:50:19 <Cogitri> Hooray, Laptop arrived (again :P)
2019-12-11 17:50:19 <Cogitri> mps: What's the status on FF 71?
2019-12-11 17:59:27 <mps> Cogitri: build on aarch64 but fail on x86_64
2019-12-11 17:59:47 <mps> Cogitri: hooray for laptop :)
2019-12-11 17:59:48 <Cogitri> Okie, gonna test later today
2019-12-11 17:59:55 <Cogitri> :)
2019-12-11 18:00:25 <_ikke_> Cogitri: nice
2019-12-11 18:00:30 <mps> I can post you patch which worked on aarch64
2019-12-11 18:00:47 <Cogitri> Ah, isn't that the one on Gitlab?
2019-12-11 18:01:16 <mps> hm, yes
2019-12-11 18:01:23 <mps> I forgot it
2019-12-11 18:01:26 <mps> :)
2019-12-11 18:02:14 <mps> I wasted time on kernel and didn't looked at it in a week
2019-12-11 18:07:06 <Cogitri> Okie, looks like I'll have to dump some time into tracker-miners too
2019-12-11 18:07:19 <Cogitri> It's failing due to secoomp so this is going to be a really "fun" one :^)
2019-12-11 18:09:13 <mps> programming is hard discipline, but we like hard tasks :)
2019-12-11 19:15:48 <oliv3r[m]> mps whether they are in alpine base is irrelevant. Packages should be idempotent where they can, depending on alpine-base(layout) implicitly is bad imo. Having everything depend on alpine-base is also a weakness rather then a strength
2019-12-11 19:16:38 <oliv3r[m]> also, deleting empty dirs makes sense, if they are to be kept, they should have a .keep placeholder imo
2019-12-11 19:17:00 <oliv3r[m]> and they need a strong reason to be kept (/run or /var/lock are decent candidates)
2019-12-11 19:29:25 <mps> oliv3r[m]: I meant to say alpine-baselayout, sorry for confusion
2019-12-11 19:29:59 <oliv3r[m]> either/or :)
2019-12-11 19:30:03 <oliv3r[m]> it's a requirement for BB, so it should be fixed within bb :)
2019-12-11 19:30:35 <mps> agree, and don't understand why these dirs are deleted
2019-12-11 19:31:08 <mps> TBH, didn't looked deeply at the issue
2019-12-11 20:35:41 <z3ntu> Is Nathan Angelacos in this channel?
2019-12-11 20:36:03 <_ikke_> not at the moment
2019-12-11 20:38:40 <z3ntu> okay thanks
2019-12-11 20:56:49 <Cogitri> Ugh, seems like FF 71 fails on x86_64 for me too, looking into it now that tracker-miners is fixed at least :)
2019-12-11 20:57:18 <Cogitri> WIll be quite the nice improvement to battery life, it just SIGSYSed every other second and restarted which amounted in some good amount of CPU usage
2019-12-11 21:32:08 <clandmeter> z3ntu: he almost never is
2019-12-11 21:32:28 <z3ntu> I'll just submit a MR with my changes then
2019-12-11 21:32:38 <z3ntu> He's the maintainer of the gpsd package
2019-12-11 22:46:19 <clandmeter> Or use email
2019-12-12 06:13:12 <brlin_> Hello all,  I encountered a problem where running `abuild -rF` as root under the `/root/aports-3.10.3/main/openssh` directory will fail with `/usr/bin/abuild: cd: line 1652: can't cd to /root/packages//main/unknown: No such file or directory` error message after purging dependencies.  Anyone know how to solve it?
2019-12-12 06:13:41 <brlin_> Screenshot: https://usercontent.irccloud-cdn.com/file/fIyAsYbs/Screenshot_20191212_141253.png
2019-12-12 06:17:07 <Cogitri> Do you have permission to write to that djr?
2019-12-12 06:57:24 <hrio[m]> Small heads up of a problem with the Ansible user module when managing Alpine  https://github.com/ansible/ansible/issues/65711 problem introduced in Ansible 2.8
2019-12-12 08:15:01 <brlin_> Cogitri: Yes, the running user is root (hence the `-F` switch)
2019-12-12 08:15:46 <Cogitri> Ah sorry, replied when I just woke up :P
2019-12-12 08:32:57 <brlin_> hrio[m]: Thanks for the heads-up, appreciated.
2019-12-12 10:22:56 <_ikke_> Local privilege escalation in OpenBSD: https://www.openwall.com/lists/oss-security/2019/12/11/9
2019-12-12 13:11:25 <north1> @ncopa gpsd bumped soname, some packages need to be rebuilt
2019-12-12 13:11:57 <ncopa> oh
2019-12-12 13:15:04 <ncopa> I'm on it
2019-12-12 13:16:54 <north1> alright
2019-12-12 13:18:21 <ncopa> what is needed to make alpine 3.11 to work on rpi4 out of the box?
2019-12-12 13:18:58 <_ikke_> artok has been working on the RPI 4
2019-12-12 13:26:26 <ncopa> i merged the kernel related things i think
2019-12-12 13:30:34 <mps> !1981
2019-12-12 13:30:46 <mps> ncopa: ^
2019-12-12 13:32:42 <mps> #11020
2019-12-12 13:33:14 <mps> oh, sorry, looks like this is closed few minutes ago
2019-12-12 13:35:11 <mps>  and, what is policy about MR which can't work and didn't fixed for some weeks?
2019-12-12 14:21:19 <north1> I wait for stale bot to close it
2019-12-12 14:22:01 <mps> ah, we have stale bot, nice
2019-12-12 14:22:46 <mps> do you know after how much time it 'work'
2019-12-12 14:22:55 <north1> 60 days i think
2019-12-12 14:23:14 <mps> thanks for info
2019-12-12 15:58:03 <mps> ncopa: I see you pushed change for dtbs-lts, this should be also changed in in aports/scripts
2019-12-12 15:58:51 <mps> I'm not sure how to make patch for scripts, like normal patch?
2019-12-12 16:00:18 <mps> and what is rationale for using DEVICETREEDIR instead of FDTDIR in mkimg.base.sh
2019-12-12 16:00:31 <mps> mkimg.base.sh:                          DEVICETREEDIR /boot/dtbs
2019-12-12 16:02:00 <mps> sorry, missing line number. mkimg.base.sh:107:                              DEVICETREEDIR /boot/dtbs
2019-12-12 16:11:30 <ncopa> normal patch yes
2019-12-12 16:11:34 <ncopa> not sure
2019-12-12 16:12:53 <mps> other distros use FDTDIR
2019-12-12 16:13:47 <mps> DEVICETREEDIR is just defined once in u-boot tree, in pxe.c iirc
2019-12-12 16:14:47 <mps> will look later in source when come back to home
2019-12-12 17:34:26 <_ikke_> anything against updating vim to 8.2?
2019-12-12 17:40:21 <mps> not that I know, and will be good imo
2019-12-12 17:41:31 <mps> you remind me of my forgotten work on splitting vim to more subpackages. hope will remember it after 3.11 release
2019-12-12 17:42:56 <_ikke_> Make an issue for yourself :)
2019-12-12 17:43:04 <mps> hehe
2019-12-12 17:43:36 <mps> I have dir with notes, but don't look there often
2019-12-12 17:45:01 <mps> btw, this reminds me that we cannot move gtk from main because vim depends in it
2019-12-12 17:45:03 <_ikke_> booh, ghc failed to build again
2019-12-12 17:46:46 <mps> hah, build logs now have ansi colors
2019-12-12 17:47:26 <_ikke_> where?
2019-12-12 17:47:35 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/ghc/ghc-8.6.5-r3.log is just plain text fo me
2019-12-12 17:48:39 <mps> ah, curl download. '^M  0'
2019-12-12 17:49:23 <mps> but I'm sure yesterday I saw in one log
2019-12-12 17:51:00 <mps> or maybe not, and doesn't matter
2019-12-12 17:51:43 <mps> ghc fails on some tests
2019-12-12 17:52:47 <_ikke_> yes, they have been working on fixing those, but apparently there are still some left
2019-12-12 18:17:28 <mps> _ikke_: can I delete RPI kernels and firmware which I built for artok? you copied them for him?
2019-12-12 19:27:30 <_ikke_> mps: yes, it's on dev.a.o
2019-12-12 19:28:00 <mps> ok, thanks, I'm cleaning lxc's
2019-12-13 04:11:54 <north1> upstream fixed an error and released 1.5.1.corrected, not 1.5.2
2019-12-13 04:11:57 <north1> or 1.5.1.1 :D
2019-12-13 07:23:21 <ncopa> ugh, so the checksum is different?
2019-12-13 07:23:25 <ncopa> morning
2019-12-13 07:23:54 <mps> \o
2019-12-13 07:24:07 <ncopa> ghc built in my dev env :-/
2019-12-13 07:29:07 <mps> crystal 0.32.0 is released and still fail tests on aarc64 :-\
2019-12-13 07:42:55 <mps> qemu 4.2.0 is released
2019-12-13 08:05:13 <Cogitri> mps: Seems like the build failure on x86_64 for FF 71.0 is due to cbindgen
2019-12-13 08:05:32 <Cogitri> (Or at least downgrading to cbindgen 0.9.1 gives me a different error afterwards :P)
2019-12-13 08:10:35 <Cogitri> Ugh, it manually checks for custom Rust triplets
2019-12-13 08:12:37 <Cogitri> Great, you can only export a target JSON (that's required for building FF) on nightly Rustc
2019-12-13 08:12:58 <mps> TBH I didn't had time to look deeply at the build issue
2019-12-13 08:13:24 <mps> nice that you found it
2019-12-13 08:19:39 <Cogitri> Trying another build, let's see if this thing works :)
2019-12-13 08:23:36 <mps> my hope is up
2019-12-13 08:41:14 <north1> @ncopa no, they literally released a version called '1.5.1.corrected'
2019-12-13 08:53:49 <clandmeter> lol
2019-12-13 08:54:13 <clandmeter> makes you wonder what the next correction will be named
2019-12-13 08:54:24 <clandmeter> correctlycorrected
2019-12-13 09:45:16 <mps> x86_64 is 'blocked' by ghc
2019-12-13 09:45:23 <mps> builder*
2019-12-13 11:08:54 <Cogitri> ncopa: What's the status on a new mkinitfs release?
2019-12-13 11:10:24 <nmeum> Cogitri: regarding firefox 71.0 did you try https://git.alpinelinux.org/aports/tree/community/firefox-esr/fix-build-with-rust-1.39.patch ?
2019-12-13 11:10:47 <nmeum> this patch fixes a bindgen error I discovered while uprading firefox-esr, maybe the same thing still applies to firefox 71.0?
2019-12-13 11:11:35 <Cogitri> Hm, possibly
2019-12-13 11:12:11 <nmeum> what's the error message you are getting?
2019-12-13 11:14:06 <Cogitri> See my comment here: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1885
2019-12-13 11:14:19 <Cogitri> That's fixed with older cbindgen
2019-12-13 11:16:43 <nmeum> hm, might not be related if it builds on aarch64
2019-12-13 11:19:15 <mps> nmeum: it fails in CI aarch64, but build fine in lxc
2019-12-13 11:19:32 <nmeum> ah
2019-12-13 11:19:35 <mps> also, it fail in x86_64 lxc
2019-12-13 11:20:06 <mps> not sure what could be reason that if fail in aarc64 CI
2019-12-13 11:20:17 <mps> s/if/it/
2019-12-13 11:20:17 <alpine-meetbot> mps meant to say: not sure what could be reason that it fail in aarc64 CI
2019-12-13 11:21:24 <nmeum> did you use the same rust version for both builds because the patch I linked above is only needed with rust >= 1.39
2019-12-13 11:22:29 <mps> yes, 1.39
2019-12-13 11:23:48 <mps> patch which pass on aarc64 lxc I posted without any change as !1885
2019-12-13 11:26:23 <Cogitri> I doubt the Rust 1.39 is the breakage that occurs in FF 71
2019-12-13 11:27:45 <mps> if it build fine on aarch64 also I doubt that the rust is issue, (but who knows of subtle bugs everywere)
2019-12-13 11:29:20 <Cogitri> It's just cbindgen and after that it fails because we use a custom triplet on x86_64. I'm working on that though, FF is compiling right now
2019-12-13 11:31:13 <mps> good, I don't have much time these days for it, mostly testing armv7 kernel on some boards
2019-12-13 11:32:20 <mps> although, if no one upgrade thunderbird in a day or two I will look :)
2019-12-13 11:33:40 <mps> and, although crystal 0.32.0 is released I think we should keep current version in current (not optimal) shape for 3.11
2019-12-13 11:33:48 <mps> ncopa: ^
2019-12-13 11:36:36 <mps> btw, do we want to use haproxy LTS (2.0.x) in 3.11 or 2.1.x which is not LTS. LTS would be easier to maintain I think
2019-12-13 11:37:08 <_ikke_> lts sounds better I guess
2019-12-13 11:37:15 <_ikke_> any downsides / mayor breakage?
2019-12-13 11:39:26 <mps> currently, 2.0.x (LTS) and 2.1.x are nearly same
2019-12-13 11:39:53 <mps> ofc, 2.1.x have some small 'add-ons'
2019-12-13 11:40:08 <mps> but nothing big and important, imo
2019-12-13 11:41:06 <_ikke_> Then I think LTS would be the better choice
2019-12-13 11:41:10 <mps> _ikke_: and, I'm also for lts
2019-12-13 11:41:23 <_ikke_> Especially because we want to support it for 2 years
2019-12-13 11:41:41 <mps> that's the reason I asked
2019-12-13 11:43:06 <north1> _ikke_ (IRC): Can the timeout limit be bumped for the boost MR ?
2019-12-13 11:43:15 <_ikke_> north1: sure
2019-12-13 11:43:16 <north1> :D i want to not subject my notebook to building a truckload of packages
2019-12-13 11:43:56 <_ikke_> How long do you expect this to take?
2019-12-13 11:44:17 <north1> no clue but there is a list of packages that will be rebuilt in the MR itself
2019-12-13 11:44:24 <north1> it includes libreoffice so a lot
2019-12-13 11:44:39 <_ikke_> I set 4h for now
2019-12-13 11:45:11 <north1> thanks, rebased and pushed
2019-12-13 11:45:26 <_ikke_> ah, I restarted the pipeline
2019-12-13 11:45:39 <_ikke_> You don't need to rebase+push to restart it
2019-12-13 11:45:42 <north1> oh
2019-12-13 11:45:58 <_ikke_> You can just go to the pipeline and there is a restart button
2019-12-13 11:46:29 <north1> Yeah but that means i need to leave the comfort of my commandline
2019-12-13 11:46:45 <north1> i might have to make a gitlab-ci-pipeline-restarter with GitLab V4 API
2019-12-13 12:04:20 <clandmeter> ncopa, Qemu 4.2 is out
2019-12-13 12:06:35 <mps> clandmeter: '08:42 ............. mps| qemu 4.2.0 is released' :)
2019-12-13 12:07:35 <ncopa> clandmeter: ef2829899620c5becb13826891a52a1b1e1af95e
2019-12-13 12:07:40 <mps> and #alpine-commits says it is upraded and moved to community
2019-12-13 12:07:55 <mps> ehm
2019-12-13 12:08:00 <_ikke_> armhf: failed to build qemu
2019-12-13 12:08:31 <clandmeter> :)
2019-12-13 12:08:54 <mps> _ikke_: sha512sum: WARNING: 1 of 1 computed checksums did NOT match
2019-12-13 12:10:41 <clandmeter> ncopa: please keep that response time ;)
2019-12-13 13:35:33 <north1> kernel 5.4.3 is out
2019-12-13 13:42:48 <ncopa> i'm on it
2019-12-13 13:43:09 <ncopa> artok: what is needed to make rpi4 work?
2019-12-13 13:49:05 <Cogitri> Hooray, FF builds
2019-12-13 13:53:30 <mps> Cogitri: hooray :)
2019-12-13 13:53:49 <Cogitri> mps: FF works with these two patches: https://dist.cogitri.dev/0001-community-cbindgen-downgrade-to-0.9.1.patch https://dist.cogitri.dev/00
2019-12-13 13:53:50 <Cogitri> 02-testing-firefox-fix-on-x86_64.patch
2019-12-13 13:54:29 <Cogitri> (oops, had a newline in the 2nd link, but you get the point :)
2019-12-13 13:55:14 <mps> ofc
2019-12-13 14:25:18 <mps> waiting for 5.4.3 for a week in hope it will fix boot on exynos :)
2019-12-13 14:30:52 <mps> Cogitri: would you consider to take/fix !1885
2019-12-13 14:33:44 <Cogitri> Just apply my two patches and it should work :)
2019-12-13 14:35:11 <mps> ok, np
2019-12-13 15:00:26 <mps> Cogitri: pushed to CI
2019-12-13 15:01:59 <mps> ohm, cbindgen should be first downgraded
2019-12-13 15:02:52 <mps> (actually, first should go for coffee)
2019-12-13 15:04:12 <Cogitri> Hm, if you put the cbindgen commit in front of the FF bump it should work
2019-12-13 15:05:46 <mps> to late, I pushed FF commit
2019-12-13 16:03:49 <north1> @ikke boost still timed-out but it is very close so i can do the rest manually
2019-12-13 16:04:03 <north1> most importantly it passed on libreoffice
2019-12-13 16:19:12 <_ikke_> ok
2019-12-13 17:26:35 <_ikke_> I wonder if it still makes sense to have isofs as default image format
2019-12-13 17:38:40 <mps> what else?
2019-12-13 17:39:49 <_ikke_> ext* perhaps, or at least something that is writable
2019-12-13 17:40:18 <mps> you mean read made image for installation
2019-12-13 17:40:34 <mps> ready*
2019-12-13 17:41:07 <mps> which can be 'dd'-ed to boot media
2019-12-13 17:41:18 <_ikke_> yes, and then used to persist changes with lbu
2019-12-13 17:41:36 <_ikke_> I mean, the current image can already be dd'd, but then it's read-only
2019-12-13 17:42:07 <mps> yes
2019-12-13 17:42:22 <mps> and your proposal makes sense
2019-12-13 17:42:39 <_ikke_> for sys install it doesn't matter of course
2019-12-13 17:42:42 <mps> I thought to create this for armv7
2019-12-13 18:04:14 <_ikke_> ok, there should be more than enough space again on that builder :)
2019-12-13 18:05:56 <mps> thanks
2019-12-13 18:21:26 <ncopa> _ikke_: i wonder how to create a disk image with an ext partition without being root
2019-12-13 18:21:39 <ncopa> we may need a fat partition for uefi
2019-12-13 18:22:31 <_ikke_> fat would work too
2019-12-13 18:36:11 <ncopa> the downside with fat is that it is not resizeable
2019-12-13 18:36:31 <ncopa> it would be nice to know how other distros do it
2019-12-13 18:37:24 <ncopa> i guess we can create a diskimage with a single fat partition and mcopy the files over
2019-12-13 18:38:59 <mps> diskimage could have more partitions, boot and root at least
2019-12-13 18:39:26 <_ikke_> https://wiki.syslinux.org/wiki/index.php?title=Isohybrid
2019-12-13 18:39:56 <mps> armbian have diskimage with boot and small root partition
2019-12-13 18:40:14 <ncopa> isohybrid is what we do now
2019-12-13 18:40:19 <mps> on first boot root partition can resized (extended)
2019-12-13 18:40:35 <_ikke_> ncopa: right
2019-12-13 18:41:13 <mps> install process is 'dd' to sd card, boot, and resize when it boots
2019-12-13 18:41:39 <ncopa> hum
2019-12-13 18:42:34 <ncopa> we run our root on tmpfs
2019-12-13 18:43:09 <ncopa> we could have a /boot partition and an apks partition
2019-12-13 18:43:21 <ncopa> where apks is ext2 or ext4
2019-12-13 18:43:38 <mps> I didn't intended to say that we should do what armbian does
2019-12-13 18:44:20 <ncopa> that way it would be possible to extend the data partition
2019-12-13 18:44:39 <ncopa> but then we need to rewrite setup-bootable
2019-12-13 19:15:38 <ncopa> can you please hold your commits for a sec? I'm about to push 3.11.0_rc2
2019-12-13 19:22:38 <ncopa> ok, here comes rc2
2019-12-13 19:22:45 <_ikke_> :)
2019-12-13 19:23:11 <ncopa> i added rpi4 support
2019-12-13 19:23:29 <ncopa> would also be nice to test aarch64 on rpi3
2019-12-13 19:24:28 <_ikke_> I only have a v1 and v2
2019-12-13 19:38:49 <ncopa> i have v3
2019-12-13 19:38:54 <ncopa> and i have ordered a v4
2019-12-13 19:38:58 <ncopa> will test on monday
2019-12-13 20:01:39 <_ikke_> ncopa: you ask about testing with ipv6 only. One challens is that a lot of our infrastructure is not reachable natively via IPv6 yet
2019-12-13 20:02:48 <joneskoo> ncopa: any chance for armhf rpi build :/
2019-12-13 20:54:08 <clandmeter> Cogitri: does gnome take much memory to compile?
2019-12-13 21:09:41 <Cogitri> Hm, not that much
2019-12-13 21:09:57 <Cogitri> Wait, are you talking about memory == disk space or memory == RAM?
2019-12-13 21:11:38 <clandmeter> RAM
2019-12-13 21:12:32 <_ikke_> since when is memory diskspace?
2019-12-13 21:34:47 <Cogitri> I guess memory does usually refer to RAM but it can refer to disk space, doesn't it? Maybe I just think that because the German word for memory (Speicher) is more oriented towards disk space
2019-12-13 21:34:59 <Cogitri> Anyway, the think that needs the most RAM is webkit2gtk
2019-12-13 21:35:15 <_ikke_> Isn't Speicher more related to storage?
2019-12-13 21:35:34 <_ikke_> memory almost always refers to volatile working memory, not persistent storage
2019-12-13 21:35:49 <_ikke_> Speichern is to safe, right?
2019-12-13 21:35:54 <Cogitri> Speicher can be translated as both storage or memory
2019-12-13 21:35:58 <Cogitri> Speichern is to safe, yes
2019-12-13 21:36:56 <Cogitri> The other stuff doesn't need *that* much RAM. I guess gtk3 or mutter would be the heaviest ones to compile but I guess they're not that bad for how much functionality they offer
2019-12-13 21:43:18 <clandmeter> Cogitri: we have our 128G aarch64 box oom
2019-12-13 21:43:34 <clandmeter> we cant really pin point it now
2019-12-13 21:43:53 <clandmeter> it killed our qemu runner
2019-12-13 21:43:54 <Cogitri> Phew
2019-12-13 21:44:15 <clandmeter> not sure how the linux oom killer works.
2019-12-13 21:44:18 <Cogitri> How many build jobs does that AArch64 set?
2019-12-13 21:44:37 <Cogitri> I think it just kills whatever takes up the most RAM
2019-12-13 21:44:38 <clandmeter> ci is not the issue
2019-12-13 21:44:42 <clandmeter> its run inside qemu
2019-12-13 21:44:48 <clandmeter> qemu itself has been killed
2019-12-13 21:45:00 <clandmeter> we use 32G for CI
2019-12-13 21:45:13 <clandmeter> so we have 98 left for system
2019-12-13 21:45:26 <Cogitri> It's interesting that it kills Qemu instead of Qemu killing whatever process is being run inside of it though
2019-12-13 21:45:44 <clandmeter> as i mention, its not happening due to CI
2019-12-13 21:45:52 <clandmeter> the builders run on it
2019-12-13 21:45:58 <_ikke_> abuild.conf for the builders has JOBS=90
2019-12-13 21:45:58 <clandmeter> they consume the rest of it
2019-12-13 21:46:22 <Cogitri> So memory is being overprovisioned?
2019-12-13 21:46:59 <Cogitri> Anyway, the only thing I have recently pushed that could consume that much RAM is mutter since that's the only thing having enough compilation units to even feed 90 build jobs
2019-12-13 21:47:11 <clandmeter> my guess is that some package spawns processes that use a lot of memory
2019-12-13 21:47:33 <clandmeter> so the builders use all the memory that is left
2019-12-13 21:47:43 <clandmeter> linux kills the processes that uses that most
2019-12-13 21:47:48 <_ikke_> mutter was pushed after the OOM
2019-12-13 21:48:21 <clandmeter> s/that most/the most
2019-12-13 21:48:21 <alpine-meetbot> clandmeter meant to say: linux kills the processes that uses the most
2019-12-13 21:56:45 <clandmeter> going to upgrade gitlab. will take some time.
2019-12-13 22:07:56 <Cogitri> ikke: Oh, okay
2019-12-13 22:08:12 <Cogitri> Hm, I don't know what could've consumed that much RAM then, sorry
2019-12-13 22:08:44 <Cogitri> I think I only pushed gnome before that and that's a meta package
2019-12-13 22:12:17 <andypost[m]> I'm working on pr12184 and it passed on travis, but looks it killing dron runners - any way to stop this jobs?
2019-12-13 22:18:06 <clandmeter> andypost[m]: gitlab is back
2019-12-13 22:19:37 <andypost[m]> clandmeter: thank you, looks runners are without ptrace caps so no way to run tests(
2019-12-13 23:18:53 <kaey> 5.4.3 aarch64 boots fine on rpi3, no obvious errors in dmesg
2019-12-13 23:22:56 <kreios> I did a quick test of aarch64 on rpi4.  Ethernet works fine. No wifi, bluetooth, or display. Still need to test USB.
2019-12-13 23:30:05 <PureTryOut[m]> I want to see if I can boot straight Alpine Linux 3.11 on the Pine64 A64LTS this time, 3.10 was using too old of a kernel but I did get the required u-boot changes in
2019-12-13 23:33:25 <mps> PureTryOut[m]: I have no luck with 5.4 on samsung chomebook (peach pi) with exynos5 although Arch linux (alarm) kernel 5.4.2 works fine
2019-12-13 23:34:19 <mps> on rk3399 5.4.x works fine (ok, some quirks with video driver)
2019-12-13 23:34:51 <mps> rk3399 based samsung cromebook, I mean
2019-12-14 07:01:14 <north1> Oof
2019-12-14 07:01:25 <north1> 5.4.3 still missing Intel fixes
2019-12-14 07:01:29 <north1> Just got the hangup
2019-12-14 08:59:55 <mps> north1: for me it happens only when 'working' with firefox, once it is killed by OOM
2019-12-14 09:00:56 <mps> now I added swap (beside 4GB of ram) to see what will happen
2019-12-14 09:19:36 <clandmeter> north1: still have issues with gitlab api?
2019-12-14 09:21:03 <north1> Yes, some rare timeouts due to ssh blocking
2019-12-14 09:21:20 <north1> They mostly stopped after I made effort into using https wherever possible
2019-12-14 09:21:27 <clandmeter> On gitlab?
2019-12-14 09:22:25 <north1> Ah, no issues with gitlab API except it being annoying to use, but I got used to it
2019-12-14 09:23:45 <clandmeter> Ok
2019-12-14 09:23:52 <clandmeter> That I can't change
2019-12-14 12:34:55 <mps> default kernel for 3.11 will be linux-lts ? think so but confirmation would be appreciated
2019-12-14 15:20:22 <clandmeter> yes
2019-12-14 15:20:30 <clandmeter> that is what i read before
2019-12-14 15:20:40 <clandmeter> its in main
2019-12-14 15:20:48 <clandmeter> vanilla is in community
2019-12-14 15:23:22 <mps> clandmeter: thanks for confirm
2019-12-14 15:23:46 <clandmeter> no problem
2019-12-14 15:23:48 <mps> I missed move vanilla to community
2019-12-14 15:23:50 <clandmeter> your wish is my command
2019-12-14 15:23:59 <mps> :)
2019-12-14 15:24:04 <north1> Will vanilla still be an option?
2019-12-14 15:24:18 <north1> Or rather, before 5.x, 5.x breaks my system
2019-12-14 15:24:50 <clandmeter> i think so
2019-12-14 15:25:01 <clandmeter> not sure whats on the iso
2019-12-14 15:25:02 <mps> I think intention with vanilla is to follow upstream development
2019-12-14 15:25:25 <clandmeter> you can always install vanilla from repo
2019-12-14 15:25:34 <clandmeter> the downside is out of tree modules
2019-12-14 15:25:45 <clandmeter> i dont think ncopa will maintain them for vanilla
2019-12-14 15:25:55 <clandmeter> like zfs
2019-12-14 15:26:22 <clandmeter> north1: do you know what causes your issue?
2019-12-14 15:26:31 <north1> Yes I have an issue on aports
2019-12-14 15:26:38 <north1> It should be on top
2019-12-14 15:27:27 <clandmeter> !11026 ?
2019-12-14 15:27:35 <mps> #11026
2019-12-14 15:27:36 <clandmeter> uhm
2019-12-14 15:27:42 <clandmeter> ah thats the one :)
2019-12-14 15:27:48 <Cogitri> #11026 ?
2019-12-14 15:27:53 <Cogitri> Oops :P
2019-12-14 15:28:02 <north1> Exclamation Mark is for MRs
2019-12-14 15:28:34 <mps> we need some time to 'ingrain' this in brain
2019-12-14 15:29:23 <clandmeter> i have not been in -devel much lately due to infra stuff
2019-12-14 15:29:44 <clandmeter> i hope to stabilize infra to a level it takes less time
2019-12-14 15:32:09 <mps> north1: I'm not sure if your issue related to one which I had few times with -lts, but in my case adding swap looks like as a solution
2019-12-14 15:32:23 <north1> I have 12 GB swap
2019-12-14 15:32:28 <north1> That shouldn't be a problem
2019-12-14 15:32:36 <mps> huh, then no :)
2019-12-14 15:32:51 <north1> Plus my ram usage when I get the hang varies a lot
2019-12-14 15:33:12 <north1> Last time I had only chromium open, 1.7 GB being used on the whole system out of 8
2019-12-14 15:33:14 <mps> also I see increase in RAM usage with -lts
2019-12-14 15:34:00 <mps> I mean, on x86_64, not on ARM's
2019-12-14 15:35:48 <mps> and there are other issues with -lts, lot changed from 4.19
2019-12-14 15:47:09 <Cogitri> Hm, I doubt a new kernel would introduce higher ram usage
2019-12-14 15:48:23 <mps> tell me after 25 years :)
2019-12-14 15:52:18 <mps> Mosaic, web gui browser worked fine in 4MB of RAM
2019-12-14 15:53:11 <mps> Mosaic is from what firefox evolved
2019-12-14 16:10:56 <Cogitri> And here I sit with 32GB which barely do the trick :P
2019-12-14 16:11:21 <Cogitri> Do we have /var/lib/dbus/machine-id in the builders? libhandy needs it for testing
2019-12-14 16:54:09 <mps> hmm, linux-vanilla is still in main aports
2019-12-14 17:20:03 <_ikke_> Cogitri: apparently yes (based on a sample of 1)
2019-12-14 17:20:31 <Cogitri> Okay, because we don't have it on CI
2019-12-14 17:21:33 <_ikke_> Probably because the CI containers never run dbus (or whatever creates it)
2019-12-14 17:28:18 <Cogitri> Yes, wasn't sure if the runners do though
2019-12-14 17:28:30 <Cogitri> I guess I'll push it and go have a look, libhandy isn't terribly expensive to build
2019-12-14 22:32:14 <PureTryOut[m]> Why is consolekit2 a runtime dependency of bluez?
2019-12-15 14:07:19 <mps> in armv7 3.11 rc2 tarball /boot/dtbs files are missing
2019-12-15 14:08:23 <mps> probably need !2141 to be applied
2019-12-15 15:14:44 <andypost[m]> Used to try upgrade certbot (py) to 1.0 and found no setup.py... pep517 is there example how to build now?
2019-12-15 15:16:28 <north1> inside the certbot directory
2019-12-15 15:54:12 <hjaekel> north1, do you think that !1581 can be merged
2019-12-15 15:55:19 <north1> no clue, i'll take a look later
2019-12-15 16:00:59 <hjaekel> thanks
2019-12-15 19:34:38 <mksully22> hmm, trying to install 3.11 rc2 on ppc64le natively and no disks are present. Looking at modules.dep it doesn't look like any of the scsi modules are present. maybe they were omitted during the modloop creation?
2019-12-15 19:43:05 <mksully22> nevermind. my error :P
2019-12-15 19:43:49 <_ikke_> mksully22: do you know why we have some bad network performance to the ppc64 builder lately (from time to time)
2019-12-15 21:11:38 <_ikke_> mksully22: latency is all over the place :)
2019-12-15 22:37:21 <Cogitri> Does someone happen to know gyp foe pr12162 ?
2019-12-15 22:38:31 <_ikke_> The only experience I have with gyp is when it's causing trouble
2019-12-15 22:40:31 <Cogitri> The only experience I have with gyp is that I try to stay as far away from projects using it as possible :P