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
2019-12-16 05:53:40 <joneskoo> https://gitlab.alpinelinux.org/alpine/aports/issues/11031 seems to be non-fatal but "can't create /proc/sys/kernel/hotplug: nonexistent directory" on 3.11.0_rc2 on aarch64 Rasberry Pi 3B+
2019-12-16 05:54:30 <_ikke_> joneskoo: thanks for the report
2019-12-16 13:06:34 <ncopa> im working on a couple of fixes for #11031
2019-12-16 13:06:36 <mksully22> _ikke_: I'm not sure. I'll send a message to one of the administrators at unicamp and see if they've been experiancing some known problems
2019-12-16 13:07:00 <_ikke_> mksully22: alright, thanks
2019-12-16 14:46:39 <mps> #11031
2019-12-16 14:47:33 <mps> yes, everything work fine without fixing this issue, although I did on my local  build just to remove this annoying message
2019-12-16 14:48:41 <mps> and not only on aarch64 but also on armv7
2019-12-16 14:50:20 <mps> did I read yesterday in kernel git log (upstream or Arch linux) that the rpi3/4 kernel is 'unified' now
2019-12-16 14:52:05 <mps> ncopa: 3.11-rc2 armv7 tarball is missing /boot/dtbs dir and dtb files
2019-12-16 15:01:59 <ncopa> mps: ok, I'll have a look at that
2019-12-16 15:02:20 <ncopa> so rpi3/4 kernel config is unified?
2019-12-16 15:02:25 <ncopa> do you have url?
2019-12-16 15:02:42 <ncopa> that is sort of significant
2019-12-16 15:05:08 <mps> will look again in a half hour
2019-12-16 15:07:38 <mps> this dtbs dir issue could be solved by patch I made for mkimg.sh, but have to fix _f (flavor) var
2019-12-16 15:08:19 <ncopa> will test it in a bit
2019-12-16 15:08:27 <ncopa> i tested boot rpi3
2019-12-16 15:13:13 <mps> sorry for rpi3/4 merging, it was on u-boot not kernel
2019-12-16 15:13:39 <mps> (brain wearing)
2019-12-16 15:24:27 <joneskoo> re: rpi, is it possible to add armhf release for zero/older rpi? (why not)
2019-12-16 15:26:00 <mps> joneskoo: armhf will be released http://dl-cdn.alpinelinux.org/alpine/v3.11/main/armhf/
2019-12-16 15:26:49 <joneskoo> I mean rpi tarball http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/
2019-12-16 15:26:55 <joneskoo> it's non-trivial to build myself
2019-12-16 15:28:08 <mps> ah, yes
2019-12-16 15:28:32 <mps> that is because we do not have kernels for armhf now
2019-12-16 15:29:09 <mps> as of 3.10 release, I mean
2019-12-16 15:30:12 <clandmeter> ncopa: we are not going to ship armhf kernel for rpi?
2019-12-16 15:34:43 <ncopa> um
2019-12-16 15:34:58 <ncopa> i think we need armhf rpi kernel
2019-12-16 15:35:48 <ncopa> i think we have linux-rpi for armhf?
2019-12-16 15:36:07 <joneskoo> I think there is one for rpi armhf yes
2019-12-16 15:36:24 <clandmeter> ah right, i was looking in the wrong pkg
2019-12-16 15:36:34 <_ikke_> ncopa: bats and busybox fail to build
2019-12-16 15:41:34 <HRio> "ERROR: bats: builddeps failed" but there are no build deps
2019-12-16 15:42:24 <_ikke_> might mean there is an issue on the builders
2019-12-16 15:42:24 <HRio> passed CI tests https://gitlab.alpinelinux.org/HRio/aports/pipelines/3672
2019-12-16 15:43:39 <_ikke_> "(1/1) Reinstalling busybox (1.31.1-r5)"
2019-12-16 15:44:24 <HRio> https://git.alpinelinux.org/aports/commit/?id=d8d56f3702cefbfb5433283d1a5ac53e0884198c ?
2019-12-16 15:47:10 <ncopa> yeah, i broke it
2019-12-16 15:47:14 <ncopa> with a missing replaces
2019-12-16 15:48:23 <ncopa> i'm on it
2019-12-16 15:48:36 <_ikke_> alright
2019-12-16 15:49:08 <_ikke_> I ran apk fix on x86(_64)
2019-12-16 16:00:47 <ncopa> i have done the rest
2019-12-16 16:00:50 <ncopa> and rebooted them
2019-12-16 16:00:57 <_ikke_> ok
2019-12-16 16:01:08 <ncopa> i wonder if it would make sense to reboot the builder after every successful build
2019-12-16 16:11:09 <mps> btw, will linux-vanilla stay in main for 3.11
2019-12-16 16:13:58 <mps> and to not forget, _ikke_ and I talked few days ago to downgrade haproxy for 3.11 to LTS version
2019-12-16 16:14:05 <mps> any objection?
2019-12-16 17:21:16 <ncopa> sounds good to me
2019-12-16 17:21:25 <ncopa> i managed to boot wandboard
2019-12-16 17:24:59 <ncopa> but i have no framebuffer
2019-12-16 17:26:02 <mps> I tested 3.11 armv7 on 3 boards and in qemu
2019-12-16 17:26:11 <ncopa> very nice
2019-12-16 17:26:20 <ncopa> what boards was it?
2019-12-16 17:26:21 <mps> works fine but kernel needs some fixes
2019-12-16 17:26:30 <ncopa> ok?
2019-12-16 17:26:36 <ncopa> what fixes are needed?
2019-12-16 17:27:00 <ncopa> i will test a framebuffer driver for wantboard
2019-12-16 17:27:21 <mps> all 32bit ARM one cubie board, and bananapi and leemaker's lamobo R1 board
2019-12-16 17:28:08 <mps> I will ask for one raspbery PI zero and I hope I will get it in a day or two
2019-12-16 17:28:21 <mps> but not sure yet
2019-12-16 17:28:39 <ncopa> i ordered a rpi4
2019-12-16 17:28:44 <ncopa> will probably get it tomorrow to
2019-12-16 17:28:46 <ncopa> too*
2019-12-16 17:28:56 <mps> aha, good
2019-12-16 17:29:20 <ncopa> what kernel changes are needed?
2019-12-16 17:29:41 <mps> needs RESET and REBOOT enable in kernels
2019-12-16 17:29:47 <mps> and USB drivers
2019-12-16 17:30:11 <ncopa> can you find the exact kernel config options for it?
2019-12-16 17:30:13 <mps> have to look for exact config options
2019-12-16 17:30:17 <ncopa> ok
2019-12-16 17:30:22 <mps> eh :)
2019-12-16 17:32:32 <mps> tested also on exynos5 (arm32 also), everything works fine except kernel. but on this chromebook kernels stopped to work with 5.4 upgrade I think this is not related to Alpine
2019-12-16 17:33:00 <mps> 3.11 userpsace works quite fine with kernel 5.3
2019-12-16 17:34:08 <mps> and, aarch64 userspace works quite fine on one rk3399 chromebook
2019-12-16 17:34:19 <mps> 3.11 userspace I mean
2019-12-16 17:34:24 <north1> fak
2019-12-16 17:34:49 <mps> only need to tweak kernel for specific things on it
2019-12-16 17:35:44 <ncopa> nice
2019-12-16 17:36:00 <mps> and I think something is not good with 5.4 kernel on my x86_64 box, looks like eats to much memory
2019-12-16 17:36:14 <mps> too*
2019-12-16 17:37:50 <mps> (git is becoming slow on my local aport clone)
2019-12-16 17:40:36 <mps> and I saw this git commit in kernel upstream for 5.5-rc2 f26a9e959a7b1588c59f7a919b41b67175b211d8
2019-12-16 17:40:50 <mps> drm/i915/gt: Detect if we miss WaIdleLiteRestore
2019-12-16 17:41:07 <mps> maybe could be backported to 5.4
2019-12-16 17:42:43 <mps> uhmmm, 5d045c47f3501b7254fe112a2ae9b335d7ffce89
2019-12-16 17:43:17 <mps> could we reword such git msg before push or ask submitter to fix
2019-12-16 17:43:22 <ncopa> i commented it in the issu
2019-12-16 17:43:44 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/issues/11026#note_57716
2019-12-16 17:45:16 <mps> I see, looks complicated for patch
2019-12-16 17:45:58 <ncopa> i could give it a try though
2019-12-16 17:46:29 <ncopa> what worries me is this change:
2019-12-16 17:46:33 <ncopa> -	ce->lrc_reg_state[CTX_RING_TAIL + 1] =
2019-12-16 17:46:33 <ncopa> +	ce->lrc_reg_state[CTX_RING_TAIL] =
2019-12-16 17:48:04 <mps> uh, yes. 4 out of 5 hunks FAILED
2019-12-16 17:50:14 <mps> hm, not sure why they had 'CTX_RING_TAIL + 1' at all
2019-12-16 17:50:51 <ncopa> the removal of +1 is what worries me
2019-12-16 17:55:29 <mps> aha, not sure because there are some more changes between 5.4 and current 5.5-rc
2019-12-16 17:56:17 <mps> maybe there will be new 5.4.x release in few days because bug is reported upstream
2019-12-16 17:57:33 <Cogitri> Can we have #11036 in 3.11 too?
2019-12-16 17:57:45 <mps> and to not forget, 3.11 userspace works fine for me on armv7, aarch64 and x86_64
2019-12-16 17:58:30 <Cogitri> I didn't test the RC but I've been using edge on 3 machines for some time without problems now, so I guess that's about the same :)
2019-12-16 17:58:48 <mps> It is config-lts.x86_64?
2019-12-16 17:59:22 <mps> Cogitri: nearly same, yes
2019-12-16 18:08:02 <joneskoo> ncopa: re: +1, drivers/gpu/drm/i915/gt/intel_lrc_reg.h has the + 1 added
2019-12-16 18:08:57 <joneskoo> -#define CTX_RING_TAIL			0x06
2019-12-16 18:09:00 <joneskoo> +#define CTX_RING_TAIL			(0x06 + 1)
2019-12-16 18:09:55 <_ikke_> north1: what's up?
2019-12-16 18:12:54 <north1> _ikke_ (IRC): Was tricked by gitlab title forgot to check actual commit title
2019-12-16 18:13:04 <_ikke_> north1: ah, that's anoying
2019-12-16 18:13:45 <north1> i'm honestly perplexed how can someone take the time to write the correct gitlab title ( which is auto deduced to be the title of the commit if there is only one )
2019-12-16 18:13:49 <north1> but get the commit title itself wrong
2019-12-16 18:14:13 <_ikke_> north1: the sad state is that people don't care about commits
2019-12-16 18:14:36 <_ikke_> apps like github and gitlab focus more on merge/pull requests than commits
2019-12-16 18:15:18 <_ikke_> leading to people pushing tons of fix commits and ending up in a policy where everything gets squashed
2019-12-16 18:15:57 <mps> north1: don't take it seriously, it's a life :)
2019-12-16 18:21:18 <joneskoo> Re: armhf, does someone have a builder handy to give me a release tarball to try out if it will need more work?
2019-12-16 18:21:31 <joneskoo> rpi-armhf 3.11 prerelease that is
2019-12-16 18:24:06 <ncopa> i have
2019-12-16 18:25:49 <ncopa> joneskoo: i tested the aarch64 on rpi3
2019-12-16 18:25:58 <ncopa> and it works
2019-12-16 18:26:43 <joneskoo> yeah, but I have two zero W that I use for collecting bluetooth temperature data, that's why I care about armhf :)  more than enough hardware for that
2019-12-16 18:26:45 <ncopa> commit message for 5d045c47f3501b7254fe112a2ae9b335d7ffce89 is not very useful
2019-12-16 18:27:05 <ncopa> aha
2019-12-16 18:27:08 <_ikke_> ncopa: yes, that was what north1 was talking about
2019-12-16 18:28:03 <ncopa> joneskoo: have you tried the rc2?
2019-12-16 18:28:07 <joneskoo> Hm looks like #5629 doesn't have any comments, would be pretty cool to get usb serial via gadget mode on rpi zero.
2019-12-16 18:28:15 <mps> also I commented this msg above
2019-12-16 18:28:46 <joneskoo> ncopa: yes, #11031 :)
2019-12-16 18:29:14 <mps> aarch64 have this option enabled
2019-12-16 18:29:21 <joneskoo> Otherwise no issues initially on rpi3. I always forget to add wpa_supplicant to boot and networking to default but seems to work fine with that
2019-12-16 18:29:34 <mps> armv7 doesn't, and maybe RPI kernels
2019-12-16 18:29:42 <ncopa> oh, i didnt push the fix
2019-12-16 18:29:57 <mps> I looked at issue but didn't had time to make patch
2019-12-16 18:31:01 <ncopa> whatta
2019-12-16 18:31:10 <joneskoo> I'd love to test armhf and gadget with 3.11 if there's an attempt at either.
2019-12-16 18:31:10 <ncopa> im pretty sure i fixed it
2019-12-16 18:31:19 <ncopa> but where did the commit go?
2019-12-16 18:32:08 <joneskoo> 94f4c564ddbe0dd3098f4c786aef52f1aac6e417 has CONFIG_UEVENT_HELPER if you mean that?
2019-12-16 18:32:36 <ncopa> ok, that one got in
2019-12-16 18:32:50 <ncopa> but im pretty sure i tested the [rpi3] -> [pi3] change to
2019-12-16 18:32:56 <ncopa> but apparently i never ocmmitted that fix
2019-12-16 18:33:05 <ncopa> must have gotten distracted
2019-12-16 18:34:05 <joneskoo> as you have pi3 yourself I guess you won't need help there, but I get that armhf is less popular :)   of course it should work on pi3 too, but is required for zero and older
2019-12-16 18:34:43 <_ikke_> I still have a rpi1
2019-12-16 18:35:49 <mps> btw, this hotplug is not big issue, just annoying message on boot
2019-12-16 18:36:43 <ncopa> ok, i think I'll do rc3
2019-12-16 18:37:05 <ncopa> not sure if i should do the AMD kernel thing first though
2019-12-16 18:37:11 <ncopa> will probably take an hour or so
2019-12-16 18:37:23 <mps> we don't have /sbin/hotplug file
2019-12-16 18:37:41 <joneskoo> So did I get you right that rpi3 should have USB Gadget somehow? Is there a wiki page or something how to enable it?
2019-12-16 18:38:00 <ncopa> oh, gadget to
2019-12-16 18:38:57 <ncopa> joneskoo: do you know the exact config option?
2019-12-16 18:39:23 <ncopa> CONFIG_USB_DWC2
2019-12-16 18:39:35 <joneskoo> I don't. I see dwc2.dtbo on aarch64 so perhaps that part is there? I never used it. I can try to see how it works on raspbian I guess, that should have it
2019-12-16 18:40:34 <joneskoo> modules-load=dwc2,g_serial and g_ether appear in quick googling
2019-12-16 18:41:47 <joneskoo> https://blog.gbaman.info/?p=791 says works with zero  but it being 2016 it might not be valid for pi3b+
2019-12-16 18:46:05 <ncopa> I'm gonna push this: http://tpaste.us/dE1L
2019-12-16 18:46:21 <joneskoo> do we have gadget serial and gadget ethernet
2019-12-16 18:46:31 <ncopa> and then i'll tag rc3
2019-12-16 18:46:39 <ncopa> and you can test the rc3
2019-12-16 18:47:16 <joneskoo> I don't think dwc2 without gadget serial would do much. I won't use ethernet I guess but would probably make sense to include that too.
2019-12-16 18:48:24 <joneskoo> possibly USB_G_SERIAL
2019-12-16 18:49:58 <joneskoo> I guess USB_ETH for g_ether :
2019-12-16 18:49:59 <joneskoo> 	  Say "y" to link the driver statically, or "m" to build a
2019-12-16 18:49:59 <joneskoo> 	  dynamically linked module called "g_ether".
2019-12-16 18:54:38 <joneskoo> rc3 will have armhf release if you're building it?
2019-12-16 18:58:59 <ncopa> yes
2019-12-16 18:59:07 <ncopa> im not sure why it does not have one already
2019-12-16 19:14:30 <andypost[m]> ncopa, please comment on issue #10933
2019-12-16 19:15:46 <joneskoo> aha, in pi zero there's a separate micro USB for power/data and no USB hub, vs. in the larger pi there's an USB hub so gadget won't work. not sure if the dwc2 will be useful for aarch64 because of this.
2019-12-16 19:29:14 <joneskoo> f7c1d7e3a6a02a71501dbb9f6c84161f5eba83ea - so USB_G_SERIAL was there already?
2019-12-16 19:30:24 <joneskoo> ok I see it in 4.19.58-0-rpi so I guess no reason it wouldn't be then.
2019-12-16 19:56:35 <mps> what is procedure to downgrade package for 3.11 ? downgrade it on edge?
2019-12-16 19:56:46 <_ikke_> yes
2019-12-16 19:56:50 <_ikke_> there is only the master branch atm
2019-12-16 19:57:03 <mps> ok, thanks
2019-12-16 19:57:08 <_ikke_> only at the time of release, 3.11-stable is branched off
2019-12-16 19:57:55 <mps> yes, know this but wasn't sure about downgrade. and when I'm not sure I usually ask
2019-12-16 19:58:13 <_ikke_> whether it's a downgrade or upgrade does not matter
2019-12-16 19:58:36 <mps> ofc, and thanks for confimation
2019-12-16 19:59:01 <mps> s/confimation/confirmation/
2019-12-16 19:59:01 <alpine-meetbot> mps meant to say: ofc, and thanks for confirmation
2019-12-16 19:59:02 <_ikke_> after 3.11 has been branched off, it can be upgraded again
2019-12-16 19:59:15 <_ikke_> Maybe add a comment as well
2019-12-16 19:59:42 <mps> that's idea which we discussed two or three days ago
2019-12-16 19:59:46 <_ikke_> yes
2019-12-16 20:00:23 <mps> and BDFL told that is ok to downgrade haproxy to LTS for 3.11 release
2019-12-16 20:00:52 <_ikke_> :)
2019-12-16 20:16:08 <mps> _ikke_: do you agree with commit message for !2199
2019-12-16 20:29:10 <_ikke_> mps: suggested to add the comment inline in the APKBUILD as well
2019-12-16 20:30:31 <mps> ah, didn't understood
2019-12-16 20:30:59 <_ikke_> np
2019-12-16 20:35:24 <ncopa> 3.11.0_rc3 was tagged
2019-12-16 20:35:32 <_ikke_> Yes, noticed, nice
2019-12-16 20:35:41 <ncopa> the armhf image generation was broke
2019-12-16 20:35:46 <ncopa> but i manually uploaded it
2019-12-16 20:36:04 <mps> heh, movie on #alpine-commits goes :)
2019-12-16 20:38:10 <_ikke_> ncopa: is that all managed by the scripts in aports/scripts?
2019-12-16 20:38:32 <ncopa> yeah
2019-12-16 20:38:44 <ncopa> aports-build and scripts/*
2019-12-16 20:42:20 <joneskoo> http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/armhf/ is empty?
2019-12-16 20:42:41 <_ikke_> joneskoo: maybe still synchronizing
2019-12-16 20:42:44 <joneskoo> ok
2019-12-16 20:43:10 <_ikke_> yes, it's still syncing
2019-12-16 20:59:35 <joneskoo> http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/armhf/ interesting, rc1 and rc2 for armhf appeared too
2019-12-16 20:59:50 <_ikke_> yes, apparently it was broken
2019-12-16 20:59:53 <_ikke_> so ncopa fixed it
2019-12-16 21:00:03 <joneskoo> the sync was, not the build? if the old releases appeared
2019-12-16 21:09:49 <joneskoo> There's something wrong with the network coming up. I did setup-interfaces, rc-update add wpa_supplicant boot, rc-update add networking, lbu commit, reboot. DHCP timed out, boot continued. After a few moments I signed in and after a few more moments the interface had an IP
2019-12-16 21:10:39 <joneskoo> I tested armhf on rpi3 now, but I have a feeling I got some similar effects earlier on aarch64 on 3.11.0rc2. But I can't say exactly where it gets stuck, but seems like wifi is coming up slower than 3.10 maybe.
2019-12-16 21:11:28 <joneskoo> I didn't do side-by-side comparison though or count how many % it has this failure mode so this is far from conclusive.
2019-12-16 21:11:59 <joneskoo> ncopa: the mdev fix seems good, no warning. armhf boots on rpi3 and no initial issues.
2019-12-16 21:27:06 <joneskoo> pi3 reboot: 40.8 seconds from stop pinging to responding again. after adding b43 to /etc/modules: 35 seconds.
2019-12-16 21:27:38 <joneskoo> That could explain the difference. Perhaps b43 should be added to modules by setup-interfaces for wlan0?
2019-12-16 21:29:08 <mps> uhmm, to upgrade ell+iwd before 3.11-stable, the question is
2019-12-16 21:29:19 <north1> the answer is yes
2019-12-16 21:29:38 <north1> @PureTryOut ping
2019-12-16 21:29:44 <mps> ell upgrade will probably require bluez rebuild, also
2019-12-16 21:30:42 <joneskoo> Adding b43 to modules was not sufficient, still times out on reboot, probably random.
2019-12-16 21:31:01 <mps> but, ell have buffer overflow fix
2019-12-16 21:31:11 <mps> ncopa: are you still here?
2019-12-16 21:31:53 <clandmeter> i am
2019-12-16 21:32:01 <mps> I think is good to update these, i.e. ell+iwd plus rebuild bluez
2019-12-16 21:32:26 <mps> clandmeter: sorry, didn't wanted to annoy you knowing how hard you work on infra
2019-12-16 21:32:55 <mps> but, when you here what is your advice about my dilemma?
2019-12-16 21:32:56 <clandmeter> ok ill crawl back to alpine-infra ;-)
2019-12-16 21:33:13 <mps> :)
2019-12-16 21:33:56 <clandmeter> what is your dilemma?
2019-12-16 21:34:34 <mps> upgrade ell and iwd, in this point in time, i.e. release is rc3
2019-12-16 21:34:55 <mps> not much time to test it
2019-12-16 21:35:23 <mps> but ell have buffer overflow fix in new release
2019-12-16 21:36:26 <PureTryOut[m]> north1: pong
2019-12-16 21:36:30 <mps> and north1 is already voiced for upgrade
2019-12-16 21:36:42 <PureTryOut[m]> Just a short pong though, I'm off in about ~5 minutes
2019-12-16 21:36:53 <north1> PureTryOut[m] (IRC): Merging your KDE stuff
2019-12-16 21:37:11 <PureTryOut[m]> Wait, you're maxice8?
2019-12-16 21:37:25 <mps> north1: ah this is those massive number of commits :)
2019-12-16 21:38:00 <north1> @PureTryOut yes, what is my irc name ?
2019-12-16 21:38:01 <_ikke_> PureTryOut[m]: north1 = maxice8 = leo
2019-12-16 21:38:18 <PureTryOut[m]> I only see an IRC account, not Matrix like normal
2019-12-16 21:38:25 <PureTryOut[m]> I realize maxice8 = Leo though 😉
2019-12-16 21:38:27 <north1> @mps Just 3 commits, PureTryOut does one big commit instead of lots small ones
2019-12-16 21:38:48 <mps> yes, I see
2019-12-16 21:38:51 <PureTryOut[m]> Uh yeah but only for big upgrades like the KDE stuff. Otherwise I do separate commit for every package I touch
2019-12-16 21:39:25 <mps> PureTryOut[m]: didn't wanted to say it is bad
2019-12-16 21:39:31 <clandmeter> north1: you are using north1 again instead of maxice8, not sure you noticed with the matrix integration.
2019-12-16 21:39:42 <PureTryOut[m]> mps: I know, I just wanted to clarify 😉
2019-12-16 21:39:48 <mps> just noticed it, nothing else. and good jod :)
2019-12-16 21:39:59 <PureTryOut[m]> So why are you using IRC again north1 rather than Matrix?
2019-12-16 21:40:01 <mps> s/jod/job/
2019-12-16 21:40:01 <alpine-meetbot> mps meant to say: just noticed it, nothing else. and good job :)
2019-12-16 21:40:23 <north1> @PureTryOut i'm not, i'm using a different IRC bridge, hosted by @Cogitri
2019-12-16 21:40:44 <PureTryOut[m]> Oh to avoid matrix.org
2019-12-16 21:41:13 <PureTryOut[m]> Makes sense then. Too bad we lose the direct Matrix-use  benefits 😭
2019-12-16 21:41:19 <PureTryOut[m]>  * Makes sense then. Too bad we lose the direct Matrix-use benefits 😭
2019-12-16 21:42:07 <PureTryOut[m]> Ah isn't it fun that CI passes but somehow the unit tests fail on the builder? Yay...
2019-12-16 21:42:19 <PureTryOut[m]> Probably a race condition which a simple retry will fix, happens a lot...
2019-12-16 21:42:38 <PureTryOut[m]> Anyways, I'm off. Good night 👋
2019-12-16 21:45:29 <joneskoo> ncopa: how can we get wireguard kernel module to rpi too? you can't install wireguard-rpi due to modloop I think
2019-12-16 21:46:12 <joneskoo> or do I need to wait for 5.6 in v3.12 :(
2019-12-16 21:46:58 <clandmeter> joneskoo: technically you can if oyou have enough memory
2019-12-16 21:47:10 <ncopa> problem is that we have wireguard in community. we dont give longterm support for it
2019-12-16 21:47:19 <joneskoo> ERROR: linux-firmware-brcm-20191022-r0: failed to rename lib/firmware/brcm/.apk.1e6e9cbc62580d70dca4539f0aaca5dab1eca01e3a52988e to lib/firmware/brcm/brcmfmac43236b.bin.
2019-12-16 21:48:17 <clandmeter> joneskoo: check modloop initd
2019-12-16 21:48:38 <clandmeter> it can be mounted with overlayfs so its kind of writeable
2019-12-16 21:49:15 <joneskoo> hm, wireguard-go might work since my app is very low bandwidth.
2019-12-16 21:49:18 <joneskoo> ERROR: (wg0) 2019/12/16 21:48:44 Failed to create TUN device: no such file or directory
2019-12-16 21:49:30 <joneskoo> modprobe tun, tada
2019-12-16 21:49:43 <joneskoo> ok so I skip the kernel implementation and community is fine, great!
2019-12-16 21:52:35 <clandmeter> joneskoo: another hack is to unpack the wireguard driver and just insmod it.
2019-12-16 21:53:07 <north1> @PureTryOut gonna play some HoI4 then merge plasma
2019-12-16 21:53:13 <joneskoo> oh. that might work, and given the kernel is anyway fixed to the release, I could just put it into apkovl even.
2019-12-16 21:54:25 <ncopa> hum, i wonder if you could create a modloop and kernel with update-kernel script
2019-12-16 21:54:34 <ncopa> maybe you can sneak in the wireguard module that way
2019-12-16 21:57:47 <joneskoo> insmod: ERROR: could not insert module lib/modules/5.4.3-2-rpi/extra/wireguard.ko: Invalid module format
2019-12-16 21:58:12 <joneskoo> hm, insmod: ERROR: could not insert module lib/modules/5.4.3-2-rpi2/extra/wireguard.ko: Unknown symbol in module
2019-12-16 21:58:20 <joneskoo> Linux ruuvi-prometheus 5.4.3-2-rpi2 #3-Alpine SMP Mon Dec 16 19:34:56 UTC 2019 armv7l Linux
2019-12-16 21:58:40 <mps> modinfo wireguard
2019-12-16 21:59:51 <joneskoo> I think I tried all variants, rpi, rpi2, armv7, armhf. This is the armhf release on raspberry 3b+
2019-12-16 22:00:32 <joneskoo> enough for one day though, I can live with the go version, just need to modprobe tun
2019-12-16 22:00:59 <mps> joneskoo: modinfo wireguard | grep vermagic
2019-12-16 22:01:10 <joneskoo> this one: vermagic:       5.4.3 SMP mod_unload modversions ARMv7 p2v8
2019-12-16 22:01:24 <mps> and compare with uname -a
2019-12-16 22:01:38 <mps> uname -r
2019-12-16 22:01:58 <mps> they must be same to use module
2019-12-16 22:02:25 <joneskoo> modinfo /lib/modules/5.4.3-2-rpi2/kernel/drivers/block/nbd.ko |grep ve
2019-12-16 22:02:29 <joneskoo> vermagic:       5.4.3-2-rpi2 SMP mod_unload modversions ARMv7 p2v8
2019-12-16 22:04:15 <joneskoo> http://dl-cdn.alpinelinux.org/alpine/v3.11/community/armhf/wir
2019-12-16 22:04:44 <joneskoo> interestingly http://dl-cdn.alpinelinux.org/alpine/v3.11/community/armhf/wireguard-rpi-5.4.3-r2.apk doesn't have -rpi2 or -rpi in the modinfo
2019-12-16 22:05:33 <mps> interesting, is the rpi kernel built with modversioning disabled
2019-12-16 22:06:12 <joneskoo> the modules on the actual rpi kernel have "5.4.3-2-rpi2 SMP mod_unload modversions ARMv7 p2v8" in the working modules
2019-12-16 22:07:28 <joneskoo> you'll let me know if I should be on the #alpine-linux instead, right? :)
2019-12-16 22:08:20 <mps> you can always, maybe someone there have more experience
2019-12-16 22:08:37 <mps> and I didn't looked how the rpi kernels are built
2019-12-16 22:08:48 <mps> and extra modules
2019-12-16 22:11:48 <_ikke_> north1: why did you add the changes-requested label on this issue? https://gitlab.alpinelinux.org/alpine/aports/issues/11027
2019-12-16 22:12:08 <north1> Mislabelled
2019-12-16 22:12:14 <north1> Meant to add package request
2019-12-16 22:12:19 <_ikke_> right
2019-12-16 22:12:41 <_ikke_> updated
2019-12-16 22:13:32 <_ikke_> is someone spamming for google now :D
2019-12-16 22:15:31 <mps> maybe with these upgrade !2191 testing/firefox can be built, anyone tried?
2019-12-16 22:29:24 <Cogitri> I'll try over night
2019-12-16 23:15:53 <shunter> For APKBUILD files, should `depends=` fit to one line, have one package per line, or have lines broken below 80 chars?
2019-12-16 23:16:46 <_ikke_> shunter: There are several styles, but I think the most accepted one is multiple lines wrapped at 80 columns and indented
2019-12-16 23:17:35 <shunter> Aight, thanks!
2019-12-16 23:57:28 <shunter> Last night, I sent a patch request to add testing/slop. When it was accepted, the line installing the COPYING file as explained on the wiki was removed. Should I hold off on doing that?
2019-12-17 04:54:10 <north1> I have good news and bad news :D
2019-12-17 05:27:24 <_ikke_> north1: enlighting us
2019-12-17 05:27:42 <north1> Read alpine-devel mailing list
2019-12-17 05:28:15 <_ikke_> alpine-devel or aports?
2019-12-17 05:28:22 <north1> devel
2019-12-17 05:28:26 <_ikke_> ah
2019-12-17 05:28:49 <_ikke_> Enjoy :-)
2019-12-17 05:28:55 <_ikke_> It's good to take a break sometimes
2019-12-17 05:40:38 <north1> Yes, someone will have to take care of kde-frameworks MR, also needs a timeout bump since it is quite huge
2019-12-17 05:41:13 <_ikke_> k
2019-12-17 06:06:56 <joneskoo> I mentioned about slow wifi earlier. I now think it's because I used a 5 GHz network. Probably country code needs to be set or otherwise wifi will wait to discover country from scanning
2019-12-17 06:15:36 <joneskoo> by the way armhf on pi zero works fine on 3.11.0_rc3. Many thanks ncopa!
2019-12-17 06:33:24 <joneskoo> Welcome to Alpine Linux 3.11
2019-12-17 06:33:25 <joneskoo> Kernel 5.4.3-2-rpi on an armv6l (/dev/ttyGS0)
2019-12-17 06:33:26 <joneskoo> <3
2019-12-17 06:35:39 <joneskoo> can't get gadget serial to work as kernel console - I think for some reason the kernel doesn't load the module dwc2 and g_serial early enough. works in /etc/modules and /etc/inittab but not console=ttyGS0
2019-12-17 06:44:05 <ncopa> do you get any /dev/ttyGS0?
2019-12-17 06:44:59 <ncopa> right, i think you need have the dwc2 and g_serial compiled into kernel to be able to use it as console=ttyGS0
2019-12-17 06:46:59 <ncopa> north1: you scared me :) enjoy your vacation!
2019-12-17 06:48:45 <north1> Ty
2019-12-17 06:49:13 <ncopa> i'm glad to see you take a well deserved vacation
2019-12-17 06:49:22 <ncopa> and im glad that you dont bring your laptop :)
2019-12-17 06:50:42 <north1> Funnily enough I'm going near the Alps
2019-12-17 06:50:59 <ncopa> ha!
2019-12-17 06:52:51 <joneskoo> ncopa: seems to work fine after boot. I was able to use g_serial to sign in to local console and g_ether brings up usb0 interface. Didn't attempt connecting it but don't see why it wouldn't work.
2019-12-17 06:54:15 <joneskoo> ncopa: the instructions for raspbian use commandline modules-load=dwc2,g_serial but I don't see console=ttyGS0 so probably they don't support boot console either
2019-12-17 06:55:13 <joneskoo> also, if you load g_serial I don't think you can switch to g_ether so there's benefits from having it as module so you can choose which one to use
2019-12-17 06:59:26 <joneskoo> I'm very happy with 3.11.0_rc3 <3 thanks again.
2019-12-17 07:29:03 <ncopa> great
2019-12-17 08:23:51 <mps> north1: enjoy :)
2019-12-17 08:37:05 <mps> joneskoo: nice that you tested on rpi zero, so I don't have to do that. thanks :)
2019-12-17 08:58:31 <Cogitri> Would be nice if a few people could test !2211 :)
2019-12-17 09:42:48 <tru_tru> https://twitter.com/fatherlinux/status/1206748837081239558?s=09 <- anyone to improve the alpine version ? 2 stage VS single and "no cache" for apk?
2019-12-17 09:51:52 <_ikke_> tru_tru: can you elaborate?
2019-12-17 10:03:48 <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-17 10:03:48 <brlin_> I later found that the missing `gcc` package causes this problem, I was attempting to rebuild OpenSSH without the alpine-sdk package installed which led to this issue
2019-12-17 10:31:07 <tru_tru> _ikke_: do you thingk there is a way to reduce the size of the alpine container?
2019-12-17 10:32:04 <tru_tru> https://github.com/fatherlinux/comparison-container-images/blob/master/build-files/Containerfile.java.alpine
2019-12-17 10:48:58 <_ikke_> apk add --no-cache might help a little, but I don't think it will improve a lot
2019-12-17 12:17:28 <clandmeter> ncopa: is it needed to run depmod twice on module installation?
2019-12-17 12:26:13 <north1> Officially in Switzerland
2019-12-17 12:26:29 <_ikke_> o/
2019-12-17 12:30:28 <clandmeter> don't eat too much chocolate :)
2019-12-17 12:30:57 <_ikke_> Is there such a thing? :P
2019-12-17 12:34:19 <clandmeter> yes there is, for sure after sinterklaas...
2019-12-17 12:34:53 <clandmeter> but thats not swiss chocolate :)
2019-12-17 12:39:43 <ncopa> clandmeter: in theory it is only needed once
2019-12-17 12:40:11 <clandmeter> why is it run on busybox trigger?
2019-12-17 12:41:59 <ncopa> because busybox provides a depmod too
2019-12-17 12:42:48 <ncopa> i guess we could check for a non-busybox depmod and skip that part
2019-12-17 12:43:21 <clandmeter> i think its a bit slow on slow cpu boxes
2019-12-17 12:48:17 <clandmeter> ncopa: in which cases do we use bb depmod?
2019-12-17 12:49:29 <Mikey95> hi guys, i try to build an apk with abuild, and would like to build an armhf package in an x86_64 env. But whatever i try it keeps genereating the package as x86_64. When i set arch=armhf and with options="!archcheck" it complains with: Package not available for the target architecture (x86_64). Aborting.. Do i miss something ?
2019-12-17 12:49:48 <clandmeter> you cannot do that
2019-12-17 12:49:54 <Mikey95> thats clear :)
2019-12-17 12:50:01 <clandmeter> use qemu
2019-12-17 12:50:04 <clandmeter> or real hw
2019-12-17 12:50:43 <Mikey95> why ?
2019-12-17 12:50:46 <clandmeter> we always build on native arch
2019-12-17 12:50:50 <Mikey95> ok
2019-12-17 12:51:13 <clandmeter> the only exception is when noarch is used
2019-12-17 12:51:21 <Mikey95> tried that too
2019-12-17 12:51:24 <Mikey95> not working
2019-12-17 12:51:31 <Mikey95> ends up in x86_64
2019-12-17 12:51:44 <clandmeter> does it ship arch depended binanries?
2019-12-17 12:51:46 <_ikke_> the package is still noarch
2019-12-17 12:51:47 <Mikey95> and when i check the APKINDEX its marked as x86_64
2019-12-17 12:51:57 <_ikke_> ^^
2019-12-17 12:52:29 <Mikey95> i am no trying with just empty apk to get a noarch
2019-12-17 12:52:32 <Mikey95> now
2019-12-17 12:52:50 <clandmeter> what package do you want to build?
2019-12-17 12:52:57 <Mikey95> new one
2019-12-17 12:53:13 <clandmeter> which is?
2019-12-17 12:53:22 <Mikey95> my own one
2019-12-17 12:53:29 <Mikey95> just some static files
2019-12-17 12:53:43 <Mikey95> lets say 3 txt files
2019-12-17 12:53:56 <clandmeter> set arch=noarch
2019-12-17 12:54:04 <Mikey95> not working
2019-12-17 12:54:29 <clandmeter> define not working
2019-12-17 12:54:36 <Mikey95> one second
2019-12-17 12:54:41 <Mikey95> will get result
2019-12-17 12:56:03 <Mikey95> >>> pod-program: Updating the mike/x86_64 repository index...
2019-12-17 12:56:11 <Mikey95> arch="noarch"
2019-12-17 12:56:30 <clandmeter> yes
2019-12-17 12:56:34 <clandmeter> thats correct
2019-12-17 12:56:42 <Mikey95> ok
2019-12-17 12:56:44 <clandmeter> what is your expected result?
2019-12-17 12:56:52 <_ikke_> There is no noarch folder
2019-12-17 12:56:57 <Mikey95> ok
2019-12-17 12:57:05 <_ikke_> so you just symlink or copy it to the correct arch folder
2019-12-17 12:57:07 <Mikey95> expected result is a noarch folder
2019-12-17 12:57:13 <Mikey95> allright
2019-12-17 12:57:23 <_ikke_> it always will look for packages in the specific arch folder
2019-12-17 12:57:28 <clandmeter> we do not have noarch folders, and if they exist its a bug.
2019-12-17 12:57:43 <clandmeter> each noarch pkg is duplicated over each arch
2019-12-17 12:57:55 <clandmeter> but can be exchanged to any arch
2019-12-17 12:58:02 <Mikey95> ok thats clear
2019-12-17 12:58:20 <Mikey95> but there is no simple command that create all archs with apkindex in it ?
2019-12-17 12:58:40 <clandmeter> no, because what you do is kind of a hack.
2019-12-17 12:58:44 <Mikey95> arch="all"
2019-12-17 12:58:51 <Mikey95> what should i expect there ?
2019-12-17 12:58:51 <clandmeter> that will not work
2019-12-17 12:58:57 <clandmeter> build it natively
2019-12-17 12:59:01 <clandmeter> on arm hw
2019-12-17 12:59:02 <Mikey95> ok
2019-12-17 12:59:08 <clandmeter> or in qemu
2019-12-17 12:59:19 <clandmeter> if its just text file, qemu will be ok
2019-12-17 12:59:37 <clandmeter> ones you start running gcc and similar it will be a pain due to translation.
2019-12-17 12:59:45 <Mikey95> that i understand
2019-12-17 12:59:57 <Mikey95> i thought abuild was bit more wise ;-)
2019-12-17 13:00:06 <Mikey95> or maybe expected to much
2019-12-17 13:00:34 <Mikey95> someone can recommended vps provider with arm hw ?
2019-12-17 13:00:57 <clandmeter> scaleway/packet
2019-12-17 13:01:00 <artok> scaleway is one
2019-12-17 13:01:21 <Mikey95> tried yesterday, could deploy one
2019-12-17 13:01:26 <Mikey95> but m,aybe out of stock
2019-12-17 13:01:55 <clandmeter> and it depends
2019-12-17 13:02:06 <clandmeter> if you need 32bit thats more complicated
2019-12-17 13:02:20 <Mikey95> no
2019-12-17 13:02:48 <Mikey95> no compiling, just generating git -> package
2019-12-17 13:02:57 <Mikey95> but will try qemy first
2019-12-17 13:03:08 <clandmeter> just use qemu, its a bit slow but should work.
2019-12-17 13:03:40 <Mikey95> ok
2019-12-17 13:03:46 <Mikey95> thank you for your time :)!
2019-12-17 13:03:55 <clandmeter> good luck
2019-12-17 13:04:41 <oliv3r[m]> how can I deal with the fact that I want to overwrite a file from a different package? (some package installs some 'example' file which is not really an example
2019-12-17 13:04:55 <clandmeter> replaces=
2019-12-17 13:05:35 <_ikke_> oliv3r[m]: is the original package still installed?
2019-12-17 13:07:06 <oliv3r[m]> yes, and it should :)
2019-12-17 13:07:27 <_ikke_> does that file live in /etc/*?
2019-12-17 13:07:31 <oliv3r[m]> yep
2019-12-17 13:07:44 <oliv3r[m]> https://pkgs.alpinelinux.org/contents?file=fw_env.config&path=&name=&branch=edge
2019-12-17 13:07:59 <_ikke_> oliv3r[m]: Then a kind of 'hacky' solution is a post-install / post-update hook that overwrites it
2019-12-17 13:08:18 <oliv3r[m]> ugh; that's ugly :)
2019-12-17 13:08:18 <_ikke_> but I don't think that will work for aports
2019-12-17 13:08:19 <_ikke_> yes
2019-12-17 13:10:52 <_ikke_> And most likely not acceptable for aports
2019-12-17 13:11:00 <_ikke_> but only one package can own a certain file
2019-12-17 13:16:05 <oliv3r[m]> !2214 should fix it then
2019-12-17 13:47:50 <mps> oliv3r[m]: are you sure we need separate apk for uboot-tools one file, although it is called example
2019-12-17 13:48:36 <oliv3r[m]> if you are suggesting to merge u-boot-tools into u-boot; yes we should; otherwise i'm not sure what you are recommending
2019-12-17 13:48:43 <oliv3r[m]> always install the example? That's not very alpine is it :)
2019-12-17 13:48:54 <oliv3r[m]> examples should be in example(s) subpackages from what I see in the tree
2019-12-17 13:49:02 <oliv3r[m]> we can put it into -doc, but then we'd have the same issue?
2019-12-17 13:49:18 <mps> agree, but in this case example file is usually needed
2019-12-17 13:49:55 <mps> maybe to ask maintainer what he thinks about this
2019-12-17 13:52:16 <mps> if someone install uboot-tools s/he expect to find /etc/fw_env.config
2019-12-17 13:54:44 <ncopa> clandmeter: we needd bb depomod when kmod is uninstalled
2019-12-17 13:55:29 <clandmeter> ncopa: you cannot uninstall it without removing the kernel?
2019-12-17 14:07:21 <ncopa> right
2019-12-17 14:07:27 <ncopa> seems that mkinitfs depends on it
2019-12-17 14:07:46 <ncopa> i guess we could disable it in busybox
2019-12-17 14:07:52 <ncopa> or move it to -extras
2019-12-17 14:07:59 <clandmeter> right
2019-12-17 14:08:08 <clandmeter> and remove the trigger
2019-12-17 14:11:14 <ncopa> do we need to add kmod as dependency to aports-build when generating boot images?
2019-12-17 14:11:22 <ncopa> and  maybe as builtime dep for kernels?
2019-12-17 14:12:12 <mps> does the bb depmod works, or it is not safe to use
2019-12-17 14:12:35 <ncopa> we want avoid call depmod twice from trigger
2019-12-17 14:12:54 <mps> iirc, it worked for me but last time I tested was more than a year ago
2019-12-17 14:13:05 <ncopa> but i think we can test if its busybox depmod or kmods
2019-12-17 14:13:33 <clandmeter> it runs kmods depmod twice
2019-12-17 14:13:58 <clandmeter> im ok with just removing the trigger in bb
2019-12-17 14:14:33 <clandmeter> maybe with some custom setup the bb depmod could be useful.
2019-12-17 14:15:21 <ncopa> it runs busybox depmod
2019-12-17 14:16:30 <clandmeter> ?
2019-12-17 14:16:47 <ncopa> @clandmeter> it runs kmods depmod twice
2019-12-17 14:16:54 <clandmeter> atleast ones
2019-12-17 14:17:04 <ncopa> that is not correct. it runs busybox depmod, not kmods
2019-12-17 14:17:10 <clandmeter>  /sbin/depmod ${i#/lib/modules/}
2019-12-17 14:17:12 <ncopa> but it does not need to :)
2019-12-17 14:17:21 <clandmeter>   /sbin/depmod -> ../bin/kmod
2019-12-17 14:17:28 <ncopa>   /bin/busybox depmod ${i#/lib/modules/}
2019-12-17 14:17:42 <clandmeter> not for kmod trigger
2019-12-17 14:18:10 <ncopa> oh? kmods trigger runs it twice?
2019-12-17 14:18:19 <ncopa> i was looking at the busybox trigger
2019-12-17 14:18:30 <clandmeter> i th ink both triggers run it
2019-12-17 14:18:37 <ncopa> yes
2019-12-17 14:18:39 <clandmeter> both check same path
2019-12-17 14:18:56 <ncopa> busybox depmod and kmod depmod
2019-12-17 14:21:07 <ncopa> clandmeter: how about this? http://tpaste.us/qlYK
2019-12-17 14:22:13 <ncopa> then we will run busybox depmod if mkinitfs would ever drop the dependency of kmod
2019-12-17 14:22:36 <clandmeter> ok.
2019-12-17 14:23:06 <clandmeter> another approach is to export that it already depmodded
2019-12-17 14:23:30 <clandmeter> not sure thats actualy possible between two triggers?
2019-12-17 14:24:04 <ncopa> they generate different output, so i dont think thats a good idea
2019-12-17 14:24:13 <ncopa> better buse busybox as fallback
2019-12-17 14:24:30 <clandmeter> i guess you need to adapt the kmod trigger to use the applet?
2019-12-17 14:25:07 <ncopa> no, i think kmod trigger can always run
2019-12-17 14:25:28 <ncopa> we just skip run busybox if depmod is kmod
2019-12-17 14:25:38 <clandmeter> i mean use kmods applet for depmod
2019-12-17 14:25:45 <clandmeter> now it uses /sbin/depmod
2019-12-17 14:25:49 <clandmeter> which could be busybox
2019-12-17 14:26:14 <clandmeter> busybox explicitly runs busybox depmod
2019-12-17 14:26:44 <ncopa> right. i that case it would run it twice
2019-12-17 14:26:56 <ncopa> but i dont think that will ever happen
2019-12-17 14:27:12 <ncopa> if you install kmod, it will overwrite busybox link
2019-12-17 14:27:23 <ncopa> if you uninstall kmod it will restore the busybox link
2019-12-17 14:29:13 <clandmeter> in the current setup it would not matter, but those core tools should they really depend on symlinks? sound a bit fragile.
2019-12-17 14:29:37 <mps> without installed kernel/mkinitfs: /sbin/depmod -> /bin/busybox
2019-12-17 14:29:55 <mps> else: /sbin/depmod -> ../bin/kmod
2019-12-17 14:30:33 <ncopa> worst thing that can happen is that it is run twice
2019-12-17 14:31:00 <ncopa> in base kmod is installed and someone manually deleted the /sbin/depmod and pointed it to /bin/busybox
2019-12-17 14:31:13 <mps> so, installed kmod shouldn't be reason it runs twice
2019-12-17 14:35:47 <clandmeter> ncopa: what gets passed to the trigger? all files and directory in the trigger location?
2019-12-17 14:36:41 <clandmeter> s/directory/directories
2019-12-17 14:36:41 <alpine-meetbot> clandmeter meant to say: ncopa: what gets passed to the trigger? all files and directories in the trigger location?
2019-12-17 14:37:29 <clandmeter> the busybox depmod trigger is much slow compared to kmods trigger
2019-12-17 14:49:34 <clandmeter> ncopa: anything against using -quick?
2019-12-17 14:50:38 <ncopa> the watched file or dir that triggered the trigger
2019-12-17 14:50:49 <ncopa> if there are multiple files/dirs they will all be passed
2019-12-17 14:50:56 <ncopa> use -quick for what?
2019-12-17 14:51:35 <clandmeter> This option scans to see if any modules are newer than the...
2019-12-17 14:51:42 <clandmeter> modules.dep file before any work is done
2019-12-17 14:52:11 <clandmeter> its only available in kmod
2019-12-17 14:53:16 <clandmeter> oh that makes no sense
2019-12-17 15:05:24 <ncopa> i have tested alpine-xen
2019-12-17 15:05:29 <ncopa> it works as expected
2019-12-17 15:05:48 <ncopa> i tested it in virtualbox and installed it to disk, and installed a domu
2019-12-17 15:28:32 <ncopa> # apk dot --errors | tpaste
2019-12-17 15:28:33 <ncopa> http://tpaste.us/xkD1
2019-12-17 15:28:40 <ncopa> i think i have fixed vlc
2019-12-17 15:34:29 <ncopa> Cogitri: there is a circular dep in libtracker -> tracker -> libtracker
2019-12-17 15:34:48 <ncopa> i think usr/lib/tracker-2.0/libtracker-data.so should move to libtracker
2019-12-17 15:35:03 <ncopa> possibly entire usr/lib/tracker-2.0
2019-12-17 15:35:05 <Cogitri> Oh
2019-12-17 15:35:12 <Cogitri> Doesn't that resolve itself since libtracker is a subpkg of tracker?
2019-12-17 15:35:12 <ncopa> not sure what trackertestutils is/does
2019-12-17 15:35:42 <ncopa> it does sort of, but it also means that splitting libtracker is meaningless
2019-12-17 15:36:03 <ncopa> and `apk dot --errors` reports it as circular
2019-12-17 15:37:21 <ncopa> i think we we should either fix the circular dep or remove libtracker subpackage
2019-12-17 15:38:06 <Cogitri> Yup
2019-12-17 15:49:03 <ncopa> anyone up for a challenge? how do we solve samba circular subpackages
2019-12-17 15:50:49 <ncopa> would be nice if we could install samba-client, samba-server, samba-winbind or samba-dc, with minimal amount of dependencies
2019-12-17 15:50:53 <ncopa> or a combination of those
2019-12-17 16:04:40 <oliv3r[m]> @mps: sure, but you need to supply your OWN fw_env.config, what's the purpose of having a miss-configured one? further more, what if you want to make a meta-package, that contains your own configurations and dependancies as your 'main install' package? you can't without some hackery :)
2019-12-17 16:18:44 <clandmeter> ncopa: seems to work nice now. much faster
2019-12-17 16:19:35 <clandmeter> i think it would be nice if apk would mention a package is kept due to install_if.
2019-12-17 16:43:34 <clandmeter> fabled: ^
2019-12-17 16:51:59 <mps> oliv3r[m]: there a lot of pkgs in alpine which install default (example) config files
2019-12-17 16:52:53 <Cogitri> mps: New cbindgen doesn't fix FF 71
2019-12-17 16:53:16 <mps> ah, bad
2019-12-17 16:53:46 <mps> it also doesn't build on CI with your downgrade of cbindgen
2019-12-17 16:56:17 <mps> but now, we should upgrade cbindgen and left firefox to fix after 3.11 release, I think
2019-12-17 16:57:36 <Cogitri> Uhh
2019-12-17 16:57:49 <Cogitri> Let's not do that please
2019-12-17 16:58:30 <Cogitri> I'm pretty sure Mozilla is going to announce CVEs for 71 or 71.1 soon
2019-12-17 16:58:32 <mps> firefox is in testing
2019-12-17 16:59:34 <mps> also I expected fix but more than 10 days passed and nothing yet
2019-12-17 17:00:00 <Cogitri> Even so I'd prefer to have a secure webbrowser on my machine running edge instead of bumping cbindgen and just waiting for something to happen
2019-12-17 17:00:11 <Cogitri> Also, ncopa: !2217 fixes tracker
2019-12-17 17:00:18 <mps> firefix-esr works
2019-12-17 17:00:35 <Cogitri> "works" as in it's somewhat secure while being super slow
2019-12-17 17:01:21 <PureTryOut[m]> Also "works" as in for a lot of people (on Musl/Alpine) the tab crashes when a password field is focused
2019-12-17 17:01:26 <Cogitri> And since Mozilla upstream hasn't bothered fixing FF with cbindgen >0.9 I somehow doubt that they're suddenly going to fix it for >=0.12
2019-12-17 17:01:35 <mps> I'm not against fix if they release upgrade
2019-12-17 17:02:16 <mps> PureTryOut[m]: I can't reproduce this bug on my boxes
2019-12-17 17:02:57 <PureTryOut[m]> Yeah I know, I'm not sure what exactly makes it happen on some machines and not on others
2019-12-17 17:03:08 <mps> it is somewhat slow, true, but works
2019-12-17 17:03:08 <PureTryOut[m]> But it's definitely related to Musl as it only happens on distros using it
2019-12-17 17:03:54 <mps> I would reword it as 'musl shows bug in FF'
2019-12-17 17:04:03 <_ikke_> It's definitely more secure, as your passwords cannot leak if you cannot even enter them :D
2019-12-17 17:04:17 <mps> :D
2019-12-17 17:11:08 <Cogitri> Anyway, unless there's someone actively working on making FF compatible with the new cbindgen let's just downgrade it and upgrade FF please
2019-12-17 17:14:17 <mps> Cogitri: I'm not against this if it works
2019-12-17 18:48:50 <okeuday> Hi, do you know what the builder VMs say with `cat /sys/devices/system/clocksource/clocksource0/current_clocksource`?
2019-12-17 18:49:31 <okeuday> just wondering for test execution, wanted to read up on the clocksource
2019-12-17 18:50:19 <_ikke_> cat: can't open '/sys/devices/system/clocksource/clocksource0/current_clocksource': No such file or directory
2019-12-17 18:50:26 <_ikke_> note that these are LXC containers
2019-12-17 18:51:06 <oliv3r[m]> @mps: just because a lot do it, doesn't mean it's right :) I call lazyness :)
2019-12-17 18:52:58 <okeuday> _ikke_: ok, thanks, that still gives me stuff to read about :-)
2019-12-17 18:57:09 <mps> oliv3r[m]: I would call it 'best practice' :)
2019-12-17 18:58:11 <mps> upstream made such files as 'hints' for end users and packagers should follow their idea
2019-12-17 18:58:59 <mps> if I install dnsmasq I expect example config file installed
2019-12-17 18:59:09 <mps> that is just one example
2019-12-17 20:08:16 <oliv3r[m]> @mps: I do expect examples, but I expect them to be either named .example or in /usr/share/doc; unless it is proper and working in a very useful way
2019-12-17 20:08:31 <oliv3r[m]> the really annoying thing with 'examples' that get installed, is that you make modifications, update it, and my changes may get wipe
2019-12-17 20:08:46 <oliv3r[m]> I prefer having 'default' config files, which include from a dir for example
2019-12-17 20:09:02 <oliv3r[m]> but having 'non-working' examples as real config files installed is just confusing imo
2019-12-17 20:09:10 <oliv3r[m]> and could even be dangerious in this case
2019-12-17 20:09:34 <oliv3r[m]> u-boot will happily say 'bad crc, writing default env' to whatever default was defined in the file, nuking whatever was really there :)
2019-12-17 20:26:27 <mps> then report bug upstream and if they don't fix it someone can make patch in aports to fix this problem
2019-12-17 20:28:14 <mps> actually I was tempted to add fixed fw_env.config to aports during last upgrade
2019-12-17 20:52:23 <oliv3r[m]> but how can you have a fixed fw_env.config? it is different for each and every board?
2019-12-17 20:53:05 <oliv3r[m]> I use mtd0, you use vfat, he uses eeprom, she uses mmcblk0, they use something else :)
2019-12-17 20:53:12 <oliv3r[m]> lets not even go over the permutations of addresses :)
2019-12-17 20:53:33 <mps> no actuall configs but commented examples
2019-12-17 20:54:35 <mps> look at Arch linux alarm for example
2019-12-17 20:54:48 <oliv3r[m]> if everything is commented, its just an example though, right?
2019-12-17 20:55:12 <mps> true, example and some kind of 'guide'
2019-12-17 20:55:44 <oliv3r[m]> that's fine, but in the alpine sense, it should then be in a subpackage :) (i don't mind the location, the example can install it into /etc of course)
2019-12-17 20:56:25 <oliv3r[m]> the thing with u-boot tools is, it should be a generic tool, the same for all distro's, not platform specific
2019-12-17 20:56:47 <mps> I don't think we need subpkg for file of about 1KB (probably less) size
2019-12-17 20:57:53 <mps> and I think we do not need subpkg for every possible config options
2019-12-17 20:58:06 <oliv3r[m]> pretty sure we have many other small packages :)
2019-12-17 20:58:22 <oliv3r[m]> exactly, this is not something you want to package! (except for some very common platforms)
2019-12-17 20:58:38 <oliv3r[m]> but that should be generated installed from the u-boot package, e.g. u-boot-olimex-lime2 or whatever
2019-12-17 20:58:44 <mps> ok, do whatever you want but first should ask maintainer
2019-12-17 20:59:28 <oliv3r[m]> I wonder how postmarket os does this ...
2019-12-17 20:59:42 <mps> i don't think we should build u-boot-olimex-lime2 for x86_64
2019-12-17 21:01:18 <oliv3r[m]> debian puts it under examples: https://source.puri.sm/Librem5/OS-issues/issues/32
2019-12-17 21:01:40 <oliv3r[m]> but how useful is u-boot-tools for x86_64 to begin with (of course there's a small few)
2019-12-17 21:03:08 <oliv3r[m]> openwrt generates it build time for the specific target
2019-12-17 21:03:36 <oliv3r[m]> so long term, the specific target u-boot package should install it; as for u-boot-tools package, it should really be just a subpackage of u-boot ...
2019-12-17 21:05:02 <mps> it is useful on x86_64, ofc. you can create image and flash it on sdcards, copy somewhere ...
2019-12-17 21:45:03 <shunter> I realized that I can set up an rpi4 model b. Is there still any need for testing, and if so, what should I test beyond installation?
2019-12-17 21:45:37 <mps> shunter: good news
2019-12-17 21:45:53 <mps> if it boots then it is fine I think
2019-12-17 21:46:34 <mps> userspace are same for other SBCs
2019-12-17 21:47:31 <shunter> I'll test with armhf, since that looks like the arch Raspbian distributes
2019-12-17 21:52:20 <artok> always good if it boots and if wifi works
2019-12-17 21:53:20 <shunter> I'm going through the rpi wiki article. What package do I need on my machine to mount FAT32 without an 'Invalid argument' error?
2019-12-17 21:54:11 <shunter> Ah, nvm, I needed to explicitly add '-t msdos' to mount it.
2019-12-17 21:54:17 <artok> yah
2019-12-17 21:54:46 <shunter> I'm too spoiled for it automatically detecting it.
2019-12-17 21:56:51 <mps> shunter: apk add util-linux
2019-12-17 21:57:20 <shunter> That works. Thanks!
2019-12-17 21:58:17 <mps> most basic tools are busybox applets and as such not fully functional like those from util-linux
2019-12-17 22:01:52 <Cogitri> By the way, does busybox' ls work for you? If I just type `ls` in my terminal as root it just says `Starting...` which kind of weirds me out
2019-12-17 22:03:42 <mps> Cogitri: it works fine, even colors
2019-12-17 22:04:30 <shunter> Works on this machine.
2019-12-17 22:06:24 <shunter> My rpi isn't booting. I'm checking to see if it's user error
2019-12-17 22:06:49 <Cogitri> Hm, alrighty
2019-12-17 22:07:32 <Cogitri> BTW, mps: !1885 passes CI on x86_64 and only fails on aarch64 because it runs out of RAM, so I think it's good to go.
2019-12-17 22:08:20 <mps> we should ask _ikke_ to increase RAM ;)
2019-12-17 22:09:22 <_ikke_> You say 32G is not enough?
2019-12-17 22:10:04 <Cogitri> I say that FF 's build says `virtual memory exhausted: Out of memory` :P
2019-12-17 22:13:23 <mps> will it pass on builders?
2019-12-17 22:13:42 <shunter> I see Raspbian boots, so it's not a monitor issue. Interestingly enough, their partition isn't marked as boot, just lba.
2019-12-17 22:13:45 <Cogitri> Would surprise me if it doesn't
2019-12-17 22:14:06 <Cogitri> If it really doesn't pass on the builders on first try we can just decrease the build jobs for FF
2019-12-17 22:16:15 <mps> I think it eats RAM during LTO and not sure if decreasing nr-jobs will help, but worth to try
2019-12-17 22:19:36 <Cogitri> I can assure you that lowering the number of (link) jobs will decrease the amount of RAM used
2019-12-17 22:19:43 <Cogitri> But let's give it a shot and see if it just werks
2019-12-17 22:20:43 <mps> ok, but right now I'm working with #iwd people to fix segfault
2019-12-17 22:26:18 <Cogitri> Okie
2019-12-17 22:48:09 <shunter> It looks like my rpi fails to boot with the image I made. I tried to have the fs like raspbian, seen here: https://paste.sr.ht/%7Eshunter/cec5b5fb5a2868fe1b8edf4ffb283b0803413aed
2019-12-17 22:49:15 <shunter> I'm still not sure how to better test if it's user error by making the image or other misstep.
2019-12-17 22:54:42 <shunter> For the record, I'm testing alpine rpi 3.10.3 armhf on an rpi 4 model B.
2019-12-17 23:16:08 <kreios> 3.10.3 does not work on rpi4.  The only image that I see released that boots is alpine-rpi-3.11.0_rc2-aarch64.tar.gz and that image doesn't fully work.  Ethernet works, wifi doesn't, bluetooth doesn't, and nothing outputs to either of the HDMI ports.
2019-12-18 00:11:01 <Guest3037> hello, one question, cherokee webserver has a wiki entry yet I don't find the apk, has it been pulled?
2019-12-18 00:21:50 <andypost[m]> Guest3037 it was removed before 3.5 release
2019-12-18 00:51:48 <Guest3037> oh ok thx
2019-12-18 08:27:53 <ncopa> have anyone with rpi1 tested alpine 3.11? #10407
2019-12-18 08:48:24 <mps> ncopa: did you applied !2205
2019-12-18 08:55:42 <ncopa> i thought that was done with a8089c68ce8dbec8ddf03c399ee680b695362678
2019-12-18 08:55:55 <ncopa> i think i commented it on the MR
2019-12-18 08:56:05 <ncopa> but didnt check if it actually was fixed
2019-12-18 08:56:06 <ncopa> sigh
2019-12-18 08:57:20 <mps> I created also 'same' MR !2201 for linux-vanilla
2019-12-18 08:58:18 <mps> i.e. use $_flavor variable for creating dtbd-$dir to follow change in mkimg.base.sh script
2019-12-18 08:58:35 <mps> s/dtbd/dtbs/
2019-12-18 08:58:35 <alpine-meetbot> mps meant to say: i.e. use $_flavor variable for creating dtbs-$dir to follow change in mkimg.base.sh script
2019-12-18 08:59:56 <mps> looked last night and in alpine-uboot-3.11.0_rc3-armv7.tar.gz and I see that /boot/dtbs-$_flavor is still missing
2019-12-18 09:00:57 <mps> but didn't had enough time to look deeply, chased bugs in iwd with upstream
2019-12-18 09:02:38 <ncopa> mps: so rc3 is broken?
2019-12-18 09:02:49 <ncopa> i was able to boot my wandboard
2019-12-18 09:02:53 <ncopa> and rpi
2019-12-18 09:03:52 <mps> does rpi use dtbs from /boot dir
2019-12-18 09:04:54 <ncopa> hum
2019-12-18 09:05:04 <ncopa> it is in update-kernel script
2019-12-18 09:05:06 <ncopa> this is tricky
2019-12-18 09:05:33 <ncopa> because now we need exact version of update-kernel with exact version of kernel
2019-12-18 09:05:47 <ncopa> you cannot use old update-kernel with new kernel
2019-12-18 09:05:47 <mps> thought so.
2019-12-18 09:06:12 <ncopa> why did we move around the dtbs dir in the firs place?
2019-12-18 09:06:29 <mps> in  alpine-uboot-3.10.3-armv7.tar.g (stable) there is /boot/dtbs dir
2019-12-18 09:06:53 <mps> and, for example './boot/dtbs/imx6qp-wandboard-revd1.dtb'
2019-12-18 09:08:01 <mps> we move it because users can install different kernels, if installed linux-lts then dtbs should be in /boot/dtbs-lts
2019-12-18 09:08:36 <mps> and if installed linux-vanilla then dtbs will be in /boot/dtbs-vanilla
2019-12-18 09:09:01 <mps> and users can have both kernels installed at the same time
2019-12-18 09:10:28 <ncopa> so, first it was /usr/lib/linux-${_abi_release} (commit c65edb14c5b7555b99bc38799c098f3fa3dd6414)
2019-12-18 09:10:41 <mps> this looks to me as 'best' option for now, till we get versioned kernels installation
2019-12-18 09:10:54 <ncopa> then it moved to /boot/dtbs/${_abi_release} (commit 081be4a965c0e6c99cc44fd75cc0ed8993cd8fa1)
2019-12-18 09:12:00 <ncopa> then it moved to /boot/dtbs (commit b34a70a62c5ef4eee9abc67deada57e7eac23e38)
2019-12-18 09:12:15 <mps> yes, some kind of mess, but I think with latest MR in mkimg.base.sh and linux-{lts,vanilla} it will be consolidated
2019-12-18 09:13:25 <ncopa> and now it moves to /boot/dtbs-$_flavor (commit 3c0a179097281150a64f6954a8e5c755a71d9e8d)
2019-12-18 09:13:36 <mps> yes
2019-12-18 09:13:46 <ncopa> so i think we should maybe stop up and think where we really want it?
2019-12-18 09:14:02 <ncopa> i dont think its a good idea to move this around every second week
2019-12-18 09:14:11 <ncopa> how does other distros do oit?
2019-12-18 09:14:57 <mps> I looked in Arch, they do it somewhat differently but similar
2019-12-18 09:15:25 <mps> and. iirc Armbian does similarly
2019-12-18 09:16:42 <mps> hmm, armbian 'boot/dtb -> dtb-4.19.68-sunxi'
2019-12-18 09:16:48 <mps> symlink
2019-12-18 09:18:19 <mps> I can't remember any distro which put dtbs anywhere else, i.e. all put them in /boot
2019-12-18 09:18:39 <mps> only alpine had them in /usr/lib/dtbs
2019-12-18 09:19:07 <ncopa> https://github.com/LeMaker/u-boot/blob/master/doc/README.distro#L109
2019-12-18 09:19:41 <ncopa> which means they need to regenerate the config file for every kernel update
2019-12-18 09:20:05 <mps> yes
2019-12-18 09:20:30 <mps> because that I think _flavor variable is better
2019-12-18 09:20:38 <ncopa> agree
2019-12-18 09:20:53 <ncopa> but this is for syslinux, right?
2019-12-18 09:21:02 <mps> u-boot
2019-12-18 09:21:31 <ncopa> where do we config u-boot?
2019-12-18 09:21:37 <mps> boot config file is placed in /boot/extlinux/extlinux.conf
2019-12-18 09:21:53 <ncopa> u-boot parses /boot/extlinux/extlinux.conf?
2019-12-18 09:22:11 <mps> or even, /extlinux/extlinux.conf
2019-12-18 09:22:49 <mps> yes, our u-boot's looks for extlinux.conf at these two dirs
2019-12-18 09:23:51 <mps> but we do not update these config extlinux.conf files automatically during kernel upgrade or install
2019-12-18 09:24:46 <mps> and I think this is ok, because it would be hard to make auto update extlinux.conf for a lot of different boards
2019-12-18 09:25:01 <mps> better left this for the end user/admin
2019-12-18 09:26:45 <ncopa> makes sense
2019-12-18 09:29:31 <mps> with mkimg.base.sh we create base extlinux.conf which can be used as base for further tweaking, usually adding needed modules in 'APPEND' line
2019-12-18 09:30:51 <mps> in our current 'state' we hardly can do much more, except to make tailored image for some boards and tweak them
2019-12-18 09:32:43 <ncopa> so it seems that it was the update-kernel that copied the dtbs to /boot
2019-12-18 09:32:46 <ncopa> from /usr/lib
2019-12-18 09:32:59 <ncopa> find -type f \( -name "*.dtb" -o -name "*.dtbo" \) | cpio -pudm "$_dtb" 2> /dev/null
2019-12-18 09:33:13 <ncopa> only *.dtb or *.dtbo files were copied
2019-12-18 09:33:18 <ncopa> maybe it was to save space?
2019-12-18 09:34:13 <ncopa> i guess it makes sense to have those in /boot
2019-12-18 09:35:33 <mps> ouh, yes, I forgot this, although looked at it few (5-6) months ago
2019-12-18 09:37:17 <mps> although, I'm not sure it works on arm's
2019-12-18 09:37:39 <ncopa> ncopa-edge-x86_64:~/alpine-conf$ git diff | tpaste
2019-12-18 09:37:39 <ncopa> http://tpaste.us/jx1v
2019-12-18 09:38:08 <ncopa> mps: i think you are right, i think the proper place to put those are in /boot/dtbs-$_flavor
2019-12-18 09:38:47 <ncopa> that also corresponds what we do with /boot/vmlinuz-$_flavor
2019-12-18 09:39:22 <mps> that was idea
2019-12-18 09:40:09 <mps> I will check patch you just posted above later
2019-12-18 09:40:52 <mps> also, we have /boot/initramfs_$_flavor
2019-12-18 09:41:01 <ncopa> yeah
2019-12-18 09:43:09 <mps> for example I have board on which 'ls -l /boot/*lts' shows /boot/System.map-lts  /boot/config-lts  /boot/initramfs-lts  /boot/vmlinuz-lts /boot/dtbs-lts
2019-12-18 09:43:17 <ncopa> ok, i pushed linux-vanilla update
2019-12-18 09:43:36 <ncopa> i will go and pick up my new rpi4
2019-12-18 09:43:41 <clandmeter> would it even work outside of boot?
2019-12-18 09:44:02 <ncopa> clandmeter: no, our update-kernel script copies it over
2019-12-18 09:44:11 <clandmeter> ah ok
2019-12-18 09:44:23 <ncopa> which means that dtbs is not updated after it is installed to disk and you update kernel
2019-12-18 09:44:26 <clandmeter> sorry i havent been following rpi recently
2019-12-18 09:44:31 <clandmeter> not have time nor hw
2019-12-18 09:44:35 <ncopa> this is uboot, not rpi
2019-12-18 09:44:41 <clandmeter> i know
2019-12-18 09:44:49 <clandmeter> but rpi is also discussed a lot recently
2019-12-18 09:44:55 <ncopa> no worries, we have other testers that has hlped us with rpi
2019-12-18 09:45:00 <ncopa> and im testing it myself
2019-12-18 09:45:06 <mps> ncopa: dtbs don't need update if they unpacked with from kernel apk
2019-12-18 09:45:26 <clandmeter> ive seen some ppl complain about wifi bt
2019-12-18 09:45:27 <ncopa> well if there is a new kernel release with dtbs fixes
2019-12-18 09:45:36 <mps> someone yesterday told that the RPI zero works fine
2019-12-18 09:45:42 <ncopa> clandmeter: ok? which rpi?
2019-12-18 09:45:50 <clandmeter> 4
2019-12-18 09:45:58 <ncopa> ok, i'll test it later
2019-12-18 09:46:08 <clandmeter> did we update fw?
2019-12-18 09:46:21 <ncopa> linux-firmware?
2019-12-18 09:46:28 <clandmeter> rpi fw
2019-12-18 09:46:50 <ncopa> no. how nad where do we do that?
2019-12-18 09:47:04 <ncopa> _rpi_bt=96eefffcccc725425fd83be5e0704a5c32b79e54
2019-12-18 09:47:12 <mps> ncopa: as of some time we ship dtbs with every kernel, updated possibly to fix things
2019-12-18 09:48:06 <clandmeter> raspberrypi-bootloader
2019-12-18 09:49:45 <mps> btw, can we force replace file /etc/ with apk upgrade
2019-12-18 09:50:17 <clandmeter> looks like its added in 4010d5bf052589c47228accdf1ffd83cff0816ca
2019-12-18 09:53:20 <ncopa> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=99a15a49acc592e674d035e562a2110268e5cd3c
2019-12-18 09:55:11 <ncopa> ok, im updateing linux-firmware
2019-12-18 09:55:14 <clandmeter> bit by bit rpi is going upsteam
2019-12-18 09:55:23 <ncopa> there are also a new rpi bt firmware
2019-12-18 09:55:38 <clandmeter> ncopa: https://downloads.raspberrypi.org/raspbian/release_notes.txt
2019-12-18 09:55:47 <clandmeter> a good resource for rpi
2019-12-18 09:56:16 <ncopa> they use 4.19 kernel still
2019-12-18 09:56:21 <clandmeter> yeah
2019-12-18 09:56:41 <ncopa> https://github.com/RPi-Distro/bluez-firmware
2019-12-18 09:56:49 <ncopa> i'll pick update from there
2019-12-18 10:06:29 <MY-R> hi! is it hard to change default initramfs-* file permissions? (to be readable by root ONLY)
2019-12-18 10:10:19 <clandmeter> MY-R: depends on the fs
2019-12-18 10:12:08 <MY-R> I mean I can do it manualy but it isnt the point, after every update of kernel that file is again world readable
2019-12-18 10:13:26 <MY-R> some people including me keep in that generated image some stuff like passwords for other partitions (keys) so would be cool if only root got access
2019-12-18 10:16:36 <MY-R> in Void Linux, Debian and probably few more distros permissions are 0640
2019-12-18 10:29:25 <agzotherm> I try to write me own .apk package that overrides a configuration file "owned" by another package. I specified the related package as "depend" and "replaces" in .PKGINFO. However, after installing my package, the configuration file remain the same, and the expected one is placed with the suffix ".apk-new". Is this an expected behavior?
2019-12-18 10:31:00 <xsteadfastx> i need to write a small openrc service file... what is the best way to set a environment variable for that service?
2019-12-18 10:31:12 <xsteadfastx> put it in the command?
2019-12-18 10:31:56 <clandmeter> conf.d will be sourced
2019-12-18 10:32:41 <MY-R> clandmeter, there is already multiple CVE based on that permission issue, better to not create another one for Alpine :\ here example discusion: https://github.com/calamares/calamares/issues/1191
2019-12-18 10:35:52 <agzotherm> Sorry, I was disconnected. I try to write me own .apk package that overrides a configuration file "owned" by another package. I specified the related package as "depend" and "replaces" in .PKGINFO. However, after installing my package, the configuration file remain the same, and the expected one is placed with the suffix ".apk-new". Is this an
2019-12-18 10:35:53 <agzotherm> expected behavior?
2019-12-18 10:36:16 <clandmeter> yes
2019-12-18 10:36:21 <clandmeter> etc is protected by default
2019-12-18 10:36:34 <agzotherm> ok, thanks!
2019-12-18 10:37:45 <clandmeter> MY-R: im not sure about that part, better ask ncopa and or add an issue to gitlab aports.
2019-12-18 10:47:08 <mps> ncopa: tested both latest linux-lts and linux-vanilla installed in parallel on Allwinner SBC with changes related to dtbs. both boots and work (except usb, but that is not related to dtbs)
2019-12-18 10:48:20 <mps> and to add note: in u-boot for alpine we can use boot menu where we can put different kernels or same kernel few times with different boot parameters
2019-12-18 11:15:18 <ncopa> MY-R: can you please create an issue on gitlab.alpinelinux.org/alpine/aports with the details? I'll have a look at it as soon i get a chance
2019-12-18 11:16:16 <MY-R> ncopa, yep just writing, should I select that issue as confidential?
2019-12-18 11:17:06 <mps> MY-R: you know proverb about closing doors when horses are already out :)
2019-12-18 11:17:27 <MY-R> whatever :D
2019-12-18 11:17:55 <MY-R> https://git.alpinelinux.org/mkinitfs/tree/mkinitfs.in#n156
2019-12-18 11:18:08 <MY-R> changing from 0022 to 0077 fixing it
2019-12-18 11:58:19 <clandmeter> ncopa: this is what a user reported last evening
2019-12-18 11:58:21 <clandmeter> <kreios> 3.10.3 does not work on rpi4. The only image that I see released that boots is alpine-rpi-3.11.0_rc2-aarch64.tar.gz and that image doesn't fully work. Ethernet works, wifi doesn't, bluetooth doesn't, and nothing outputs to either of the HDMI ports.
2019-12-18 12:43:03 <ncopa> clandmeter: thanks. I will test it now. i just got my rpi4
2019-12-18 12:48:05 <ncopa> so rc2 was broken, and the fixes was in rc3
2019-12-18 13:01:44 <ncopa> rc3 boots just fine on rpi4
2019-12-18 13:02:12 <ncopa> i think we may need an updated firwmare for wifi
2019-12-18 13:03:25 <artok> yah
2019-12-18 13:03:48 <artok> it's on my branch
2019-12-18 13:04:39 <ncopa> i already pushed an update
2019-12-18 13:04:45 <ncopa> so i just need to make new release tarball
2019-12-18 13:04:51 <artok> I've been at sea and haven't had time to really test out stuff (next time I'm next to my rpi's is year 2020...)
2019-12-18 13:05:13 <ncopa> im gonna test the armv7 on rpi4 next
2019-12-18 13:05:16 <ncopa> with updated firmware
2019-12-18 13:05:33 <artok> yeaa you have one also, great!
2019-12-18 13:05:41 <ncopa> just got one
2019-12-18 13:05:52 <ncopa> rpi4 is pretty nice
2019-12-18 13:06:20 <artok> heatsinks and fan ? =)
2019-12-18 13:06:33 <clandmeter> watercooling
2019-12-18 13:06:36 <ncopa> no? is it needed?
2019-12-18 13:07:00 <clandmeter> rpi4 gets more hot
2019-12-18 13:07:01 <ncopa> the case i bought was for rpi3 :-/
2019-12-18 13:07:29 <clandmeter> you can buy heatsink from ali for 1 euro
2019-12-18 13:07:42 <artok> It get's really hot yeah
2019-12-18 13:08:21 <clandmeter> it depends on the load right?
2019-12-18 13:08:49 <xsteadfastx> rc3 works really fine on my rpi4 aarch64... wifi too
2019-12-18 13:08:53 <artok> yeah, but throttling occurs then on "heavy" load
2019-12-18 13:09:58 <ncopa> xsteadfastx: you got wifi working? mine was not detected
2019-12-18 13:13:04 <artok> dmesg gaves info about "not found" for firmware file
2019-12-18 13:13:10 <artok> usually
2019-12-18 13:14:11 <xsteadfastx> sure.. i cloned the wifi firmware
2019-12-18 13:14:17 <xsteadfastx> like the wikipage said
2019-12-18 13:14:36 <ncopa> ah
2019-12-18 13:14:52 <xsteadfastx> didnt test bluetooth
2019-12-18 13:15:31 <ncopa> hum, armv7 does not boot
2019-12-18 13:18:04 <ncopa> seems like I forgot to add the pi4 kernel to config.txt
2019-12-18 13:20:47 <ncopa> i put the pi4 in wrong arch. i added it to armhf instead of armv7
2019-12-18 13:31:55 <PureTryOut[m]> So I'm trying to boot the Pine64 A64LTS on Alpine 3.11, but it seems the aarch64 version of linux-lts doesn't have any .dts installed
2019-12-18 13:33:23 <ncopa_> good news! rpi4 wifi works out of the box with the updated firmware
2019-12-18 13:33:33 <ncopa_> this is from rpi4 :)
2019-12-18 13:33:42 <ncopa_> armv7
2019-12-18 13:34:09 <ncopa_> im gonna create a new image with aarch64 and try that
2019-12-18 13:34:49 <PureTryOut[m]> Seems only the armv7 version has dtb files?
2019-12-18 13:35:27 <artok> yeii
2019-12-18 13:35:38 <ncopa> do we need the dtbs on aarch64 as well?
2019-12-18 13:35:45 <ncopa> i guess we do for uboot
2019-12-18 13:39:40 <ncopa> i think its pretty cool that i can remove the sdcard without powering it off :)
2019-12-18 13:39:41 <PureTryOut[m]> On any arm yes you do
2019-12-18 13:41:01 <PureTryOut[m]> Shouldn't https://git.alpinelinux.org/aports/tree/main/linux-lts/APKBUILD#n138 also apply to aarch64?
2019-12-18 13:42:19 <ncopa> PureTryOut[m]: i think so yes
2019-12-18 13:42:34 <PureTryOut[m]> Patch incoming lol
2019-12-18 13:42:39 <ncopa> i suppose the reason we dont have it (yet) is that our aarch64 machines uses uefi
2019-12-18 13:43:09 <ncopa> PureTryOut[m]: also, we removed armhf support for linux-lts
2019-12-18 13:43:25 <PureTryOut[m]> I don't care about armhf personally 😉
2019-12-18 13:43:39 <ncopa> the reasoning is that most 32 bit arm machines are armv7 nowdays
2019-12-18 13:43:55 <ncopa> and those that aren't will most likely need to build a custom kernel anyway
2019-12-18 13:44:28 <ncopa> this means that we only support rpi1 kernel for armhf
2019-12-18 13:44:36 <PureTryOut[m]> Oh yeah I agree
2019-12-18 13:44:55 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/AZhNoAPZexcBSYCzvnLdqtxO >

2019-12-18 13:45:03 <mps> hmm, https://git.alpinelinux.org/aports/tree/main/linux-lts/APKBUILD#n138
2019-12-18 13:45:39 <ncopa> mps: ok with you? https://matrix.org/_matrix/media/r0/download/matrix.org/AZhNoAPZexcBSYCzvnLdqtxO
2019-12-18 13:45:47 <ncopa> i think we may also need to fix update-kernel script
2019-12-18 13:45:54 <mps> should have arm* | aarch64
2019-12-18 13:46:10 <ncopa> thats what PureTryOut[m]'s patch does
2019-12-18 13:46:21 <mps> some arm64 boxes need dtbs
2019-12-18 13:46:34 <ncopa> makes sense
2019-12-18 13:47:01 <mps> ah, matrix long messages :P
2019-12-18 13:47:08 <mps> yes, look ok
2019-12-18 13:47:17 <mps> s/look/looks/
2019-12-18 13:47:17 <alpine-meetbot> mps meant to say: yes, looks ok
2019-12-18 13:49:27 <ncopa> make zinstall instaed of make install?
2019-12-18 13:52:55 <PureTryOut[m]> ncopa: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2221
2019-12-18 13:55:43 <mps> zinstall, install compressed kernel
2019-12-18 13:56:29 <mps> for some arch'es
2019-12-18 13:56:58 <mps> arm32/64 and risc-v iirc
2019-12-18 14:19:02 <mps> before release will some look to !2199
2019-12-18 14:33:18 <ncopa> mps: merged
2019-12-18 14:33:41 <mps> ncopa: I see, #alpine-commits movie goes :)
2019-12-18 14:34:45 <mps> for 3.11 I have two things to do, fix iwd and try to fix sunxi reboot, poweroff and usb
2019-12-18 14:35:54 <mps> iwd is actually works fine, but have to force upgrade /etc/iwd/main.conf on apk upgrade
2019-12-18 14:36:18 <ncopa> what is the problem with iwd?
2019-12-18 14:36:52 <mps> they changed config directives and it segfaults with old ones
2019-12-18 14:38:57 <ncopa> heh
2019-12-18 14:39:08 <ncopa> that is something we may want fix with a sed script in .post-upgrade?
2019-12-18 14:39:33 <ncopa> PureTryOut[m]: what do you think about my suggestion for !2199 ?
2019-12-18 14:39:41 <ncopa> sorry
2019-12-18 14:39:51 <ncopa> PureTryOut[m]: what do you think about my suggestion for !2221 ?
2019-12-18 14:41:54 <mps> if it is ok to use sed in .post-upgrade I will add it
2019-12-18 14:42:23 <ncopa> i think it is. just make it failsafe.
2019-12-18 14:42:34 <ncopa> like what happens if the file is missing or similar
2019-12-18 14:42:47 <ncopa> PureTryOut[m]: are you ok with this? http://tpaste.us/BjMn
2019-12-18 14:42:49 <mps> ok, and will try
2019-12-18 14:44:13 <ncopa> PureTryOut[m]: i mean this: http://tpaste.us/b4QD
2019-12-18 14:44:17 <ncopa> you will be author
2019-12-18 14:44:20 <ncopa> thats wy i ask
2019-12-18 14:44:37 <mps> ncopa: make for linux-{lts,vanilla} already put dtbs in proper place
2019-12-18 14:44:58 <mps> I think his original MR is ok
2019-12-18 14:45:05 <ncopa> its not
2019-12-18 14:45:23 <ncopa> path is wrong on aarch64
2019-12-18 14:45:27 <mps> if you want I can test when finish with building armv7 kernel
2019-12-18 14:45:31 <PureTryOut[m]> Hmm it seems ok to me
2019-12-18 14:45:40 <ncopa> arch/arm vs arch/arm64
2019-12-18 14:45:50 <mps> ah, true, ok
2019-12-18 14:46:01 <ncopa> and there are no arc/arm64/boot/dts/*.dtb on aarch64
2019-12-18 14:46:46 <mps> ok, will check all this little later
2019-12-18 14:47:26 <ncopa> ncopa-edge-aarch64:~/aports/main/linux-lts/src/build-lts.aarch64$ find arch/arm64/boot/dts/ -name '*.dtb' | tpaste
2019-12-18 14:47:26 <ncopa> http://tpaste.us/7KoL
2019-12-18 14:49:11 <ncopa> the question is if we should store those as /boot/dtbs-$_flavor/broadcom/bcm2837-rpi-3-b-plus.dtb or /boot/dtbs-$_flavor/bcm2837-rpi-3-b-plus.dtb (wihtout the .../boadcom/... subdir)
2019-12-18 14:52:14 <mps> last one, I think
2019-12-18 14:52:25 <ncopa> all files flat?
2019-12-18 14:53:09 <mps> u-boot in alpine looks for /boot/dtbs-$_flavor
2019-12-18 14:54:08 <mps> although it can be adjusted
2019-12-18 14:54:35 <mps> hmm
2019-12-18 14:55:39 <mps> u-boot search extlinux.conf and follow whatever is given as FDTDIR parameter
2019-12-18 14:57:12 <ncopa> it non-optimal that they are installed in different places on armv7 and aarch64
2019-12-18 14:57:36 <PureTryOut[m]> We can just install them to `/boot/dtbs-$_flavor` for aarch64 as well
2019-12-18 14:57:45 <ncopa> and i dont think its good that we move those around in the future as well
2019-12-18 14:57:53 <ncopa> since it will break peoples boot
2019-12-18 14:59:08 <mps> well, 'make INSTALL_DTBS_PATH="$pkgdir/boot/dtbs_$_flavor" dtbs_install' should do the all, but didn't tested so not 100% sure
2019-12-18 15:00:02 <ncopa> ah
2019-12-18 15:00:04 <ncopa> thats better
2019-12-18 15:00:07 <ncopa> much better
2019-12-18 15:01:20 <mps> as wrote above, will test later, now working on armv7 fixes
2019-12-18 15:02:01 <PureTryOut[m]> At postmarketOS we use `dtbs_install` already for our kernels
2019-12-18 15:02:25 <mps> so, it works?
2019-12-18 15:02:45 <PureTryOut[m]> At postmarketOS, yes
2019-12-18 15:03:22 <mps> good, then i think it will not be issue on alpine
2019-12-18 15:03:39 <mps> and just looked in Arch linux, they do the same
2019-12-18 15:03:52 <ncopa> yeah, thats the proper way to do it
2019-12-18 15:06:00 <ncopa> so I'll push this if its ok with PureTryOut[m] and if it builds on both armv7 and aarch64: http://tpaste.us/pKyw
2019-12-18 15:06:26 <ncopa> i love when we remove lines :)
2019-12-18 15:07:26 <mps> oh, I must be blind :) didn't noticed this when I made changes to /boot/dtbs
2019-12-18 15:07:30 <ncopa> it shouldnt be any backwards problems with aarch64, since the dtbs is completely missing there not
2019-12-18 15:09:58 <ncopa> hm, the rpi4 gets really hot weven without load
2019-12-18 15:11:04 <PureTryOut[m]> ncopa: ha yeah looks way better
2019-12-18 15:17:18 <ncopa> as i understand, there are virtualization support in rpi4?
2019-12-18 15:17:33 <ncopa> means we should be able to run xen on rpi4
2019-12-18 15:18:37 <mps> and qemu
2019-12-18 15:27:24 <PureTryOut[m]> ncopa: how do you normally edit the kconfig for linux-lts?
2019-12-18 15:29:42 <ncopa> depends a bit
2019-12-18 15:29:56 <ncopa> i normally edit the config-* file directly
2019-12-18 15:30:09 <ncopa> sometimes i run make menuconfig
2019-12-18 15:30:14 <ncopa> and copy the .config
2019-12-18 15:30:27 <ncopa> tricky part is that we have so many arches
2019-12-18 15:30:37 <ncopa> arches and config combinations
2019-12-18 15:31:22 <ncopa> i run CARCH=somearch abuild oldconfig
2019-12-18 15:31:26 <ncopa> to test each arch
2019-12-18 15:32:19 <mps> I do, abuild deps unpack prepare ; cd src/build-$ver ; make menuconfig ; cp .config ../../config-$file
2019-12-18 15:32:46 <mps> and also 'vi config-$file' for small changes
2019-12-18 15:32:58 <ncopa> $ tpaste < ~/update-kernel-configs
2019-12-18 15:32:58 <ncopa> http://tpaste.us/WR5M
2019-12-18 15:33:18 <ncopa> once the change is edited in each config
2019-12-18 15:33:30 <ncopa> to test that there are no unexpected questions
2019-12-18 15:35:26 <PureTryOut[m]> ncopa: ah ok, as I'm wondering how to edit the kconfig to enable the required parts for the Pine64 A64LTS
2019-12-18 15:44:42 <PureTryOut[m]> mps: that works nicely, even usable with docker-abuild (although I have to cd to src/linux-5.4 then). Is it documented somewhere?
2019-12-18 15:47:35 <mps> no, it is not, but good method to see dependencies when you change some config parameters, you see what else must be changed
2019-12-18 15:48:59 <mps> abuild create build-$kver dir where you can do a lot of tweaks
2019-12-18 15:49:13 <mps> src/build-$kver
2019-12-18 15:54:58 <mps> hm, 'apk add ncurses-dev ; cd src/build-lts.armv7 ; make menuconfig'
2019-12-18 15:59:38 <ncopa> are there any cheap(ish) arm64 boards that supports uefi?
2019-12-18 16:09:04 <PureTryOut[m]> I don't know tbh
2019-12-18 16:13:37 <ncopa> I suppose I should get an arm based chromebook or similar :)
2019-12-18 16:37:44 <mps> https://store.pine64.org/?product=14%e2%80%b3-pinebook-pro-linux-laptop-64gb-emmc-iso-keyboard-estimated-dispatch-in-october-2019
2019-12-18 16:38:28 <mps> if this can be ordered/bought I wouldn't look at chromebooks :)
2019-12-18 16:43:26 <ncopa> i think i'll tag rc4 now
2019-12-18 16:43:40 <ncopa> are there anything else that should be fixed before that?
2019-12-18 16:45:06 <mps> iwd, but not fix, upgrade
2019-12-18 16:45:54 <mps> don't wait for it if you want to create rc4
2019-12-18 17:05:42 <ncopa> ok, here comes rc4
2019-12-18 17:05:51 <_ikke_> ack
2019-12-18 17:47:57 <MY-R> nice spam in issues :D
2019-12-18 17:48:28 <MY-R> #11045
2019-12-18 17:51:44 <mps> ncopa: still no /boot/dtbs-lts in alpine-uboot-3.11.0_rc4-armv7.tar.gz
2019-12-18 17:52:13 <ncopa> huh
2019-12-18 18:14:33 <ncopa> i think we need to post announcements when there are security fixes: https://lists.alpinelinux.org/~alpine/users/%3C2013507513.1487922.1576682692429%40mail.yahoo.com%3E
2019-12-18 18:23:37 <PureTryOut[m]> ncopa, mps: so on aarch64 the dtb files are all separated into folder per manufacturer, I don't think the u-boot script account for that currently right? https://pkgs.alpinelinux.org/contents?file=*.dtb&path=&name=linux-lts&branch=edge&repo=main&arch=aarch64
2019-12-18 18:27:07 <ncopa> i don tknow
2019-12-18 18:27:18 <ncopa> ERROR: ca-certificates-20190108-r0: BAD archive
2019-12-18 18:29:04 <PureTryOut[m]> Where does the u-boot script come from actually? I can't find it
2019-12-18 18:29:42 <mps> u-boot script?
2019-12-18 18:30:38 <PureTryOut[m]> Yeah the one that tells u-boot at boot where to look for the kernel and dts and such
2019-12-18 18:31:11 <PureTryOut[m]> For example for the PinePhone we have the following on pmOS https://gitlab.com/postmarketOS/pmaports/blob/master/device/device-pine64-pinephone/uboot-script.cmd
2019-12-18 18:32:27 <mps> PureTryOut[m]: first about SBC dirs for arm64
2019-12-18 18:33:05 <mps> 'make INSTALL_DTBS_PATH="$pkgdir/boot/dtbs_$_flavor" dtbs_install' reflect kernel tree
2019-12-18 18:34:19 <mps> arch/arm64/boot/dts have subdirs for each SBC while arch/arm/boot/dts have all dts in one dir
2019-12-18 18:35:21 <mps> second, u-boot search for extlinux.conf file on boot partitions under /extlinux or /boot/extlinux
2019-12-18 18:36:21 <mps> replace 'SBC' with 'SOC' above
2019-12-18 18:36:35 <mps> actual SBCs are in SOC subdir
2019-12-18 18:39:50 <PureTryOut[m]> So it should "just" work then?
2019-12-18 18:41:32 <mps> yes, anyway if someone install any of our arm tarball s/he have to fix params in extlinux.conf, add needed modules to boot, set console etc...
2019-12-18 18:42:08 <mps> only some RPI's works 'out of the box' afaik
2019-12-18 18:42:33 <mps> not afaik (because I didn't tried) but iiuc
2019-12-18 18:43:04 <PureTryOut[m]> Ok. Well currently there doesn't seem to be any dts in the release images like you mentioned for armv7, so I'll try again once that's fixed
2019-12-18 18:43:13 <mps> we don't have ready made images like armbian (for example) for different boards
2019-12-18 18:43:48 <mps> yes, they are missing and I think ncopa fixed this for next tarballs
2019-12-18 19:03:02 <ncopa> i tagged rc5
2019-12-18 19:03:04 <ncopa> with the fixes
2019-12-18 19:17:36 <MY-R> something is wrong with that script: https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/grub/grub.post-upgrade
2019-12-18 19:18:11 <MY-R> even if I have in my /etc/default/grub line with GRUB_CMDLINE_LINUX_DEFAULT then script still after every grub upgrade add extra one
2019-12-18 19:21:33 <PureTryOut[m]> mps: I mean, I prefer the generic images 😉
2019-12-18 19:32:19 <MY-R> omg pfff somebody put wrong path in grub.post-upgrade :P
2019-12-18 19:33:08 <MY-R> s/path/paths
2019-12-18 19:33:08 <alpine-meetbot> MY-R meant to say: omg pfff somebody put wrong paths in grub.post-upgrade :P
2019-12-18 19:35:26 <mps> PureTryOut[m]: I didn't had enough time for aarch64 (not even for armv7) to make it in better shape for alpine, just small fixes and enhancements
2019-12-18 19:36:17 <mps> and I don't dare to create patch with big number and intrusive changes for alpine kernels
2019-12-18 19:36:57 <mps> at the end I think it will not be accepted (maybe I also would not accept my changes easy)
2019-12-18 19:43:04 <HRio> testing current edge (the rc5 tag), I see "Loading initial ramdisk..." and then "sh: zfs: unknown operand" during boot just before "OpenRC 0.42...."
2019-12-18 19:45:34 <MY-R> sorry for spamming this channel with my problems but when I wrote about it here then somehow after minute found solution for them :D GL issue of course created :)
2019-12-18 20:06:39 <PureTryOut[m]> mps: uh I'm not entirely sure what you're talking about? What will not be accepted?
2019-12-18 20:09:07 <ncopa> MY-R: im fixing grub. thanks!
2019-12-18 20:09:10 <PureTryOut[m]> ncopa: any chance you could create new tarballs for _rc5? Seems there is only an aports tarball atm
2019-12-18 20:09:28 <ncopa> PureTryOut[m]: what arch?
2019-12-18 20:09:36 <PureTryOut[m]> aarch64, the u-boot image
2019-12-18 20:09:48 <MY-R> ncopa, thank you! :)
2019-12-18 20:10:34 <ncopa> PureTryOut[m]: something muse have went wrong when making the release
2019-12-18 20:10:35 <PureTryOut[m]> Although it's only useful to me if it includes the dts files
2019-12-18 20:13:04 <ncopa> PureTryOut[m]: seems like it is still trying to upload files
2019-12-18 20:13:06 <mps> PureTryOut[m]: look at kernel source tree file arch/arm/configs/multi_v7_defconfig
2019-12-18 20:13:16 <mps> something like that
2019-12-18 20:13:50 <mps> or something like debian arm multi platform
2019-12-18 20:14:04 <mps> or Arch linux multi platform
2019-12-18 20:14:10 <PureTryOut[m]> Uh, what?
2019-12-18 20:14:40 <mps> simple, one kernel for multiple arm32 SOC's
2019-12-18 20:14:58 <mps> and similar for arm64 SOCs
2019-12-18 20:15:23 <PureTryOut[m]> Ah. Doesn't it already work like that with linux-lts?
2019-12-18 20:15:42 <mps> ofc, it is not possible to 'cover' or different variant's with one kernel but most can be
2019-12-18 20:15:53 <mps> no, not yet
2019-12-18 20:16:09 <mps> hope we will have more luck in next cyscle
2019-12-18 20:16:20 <PureTryOut[m]> Since the dts stuff is already built, I assume it's mainly a matter of enabling the required drivers no?
2019-12-18 20:16:21 <mps> cycle*
2019-12-18 20:16:34 <mps> true, mostly
2019-12-18 20:17:30 <mps> if you are interested I can post you patch from my linux-armv7-mp branch
2019-12-18 20:17:50 <PureTryOut[m]> Well I don't use armv7 so no not really haha sorry
2019-12-18 20:18:17 <mps> ok
2019-12-18 20:18:19 <mps> np
2019-12-18 20:18:44 <mps> I thought that pmOS people are more interested in armv7 than in aarch64
2019-12-18 20:19:49 <mps> ncopa: are you ok with 79c609001f5e74909e0b044edc7834ca0b5670be
2019-12-18 20:24:02 <mps> PureTryOut[m]: but ok, everything can't be perfect in always moving world as it is linux distro, we have to continue to work
2019-12-18 20:24:07 <ncopa> PureTryOut[m]: the rc5 was finally uploaded. alpine-uboot aarch64 is there now
2019-12-18 20:24:24 <mps> for now I think 3.11 stable is priority
2019-12-18 20:24:47 <ncopa> mps: are you not ok with moving the example config?
2019-12-18 20:25:20 <mps> alpine-uboot-3.11.0_rc5-armv7.tar.gz now looks fine :)
2019-12-18 20:26:14 <mps> I proposed to edit this file and keep it where it was earlier, but to me personally it is not important
2019-12-18 20:26:45 <mps> just think this will be unpleasant surprise for our users
2019-12-18 20:29:31 <PureTryOut[m]> mps: oh yeah from pmOS perspective we have most devices on armv7, but almost all of them use their own shitty downstream kernels anyway
2019-12-18 20:29:49 <PureTryOut[m]> and the few devices that do run on mainline still use our own pmOS kernels as they require lots of out of tree patches
2019-12-18 20:31:00 <mps> ah, so pmOS doesn't use alpine kernels?
2019-12-18 20:31:23 <mps> also, alpine-uboot-3.11.0_rc5-aarch64.tar.gz looks fine now :)
2019-12-18 20:35:24 <PureTryOut[m]> Atm we don't no, as basically all devices currently either require shitty downstream kernels or heavily patched mainline
2019-12-18 20:35:46 <PureTryOut[m]> Btw, got progress on booting the A64LTS with vanilla Alpine. Proper DTS is selected, but I'm getting `Bad Linux ARM64 Image magic!`
2019-12-18 20:57:54 <mps> 'apk add -u linux-firmware linux-firmware-intel' and it starts to install all linux-firmware
2019-12-18 20:59:25 <mps> sorry. my bad
2019-12-18 21:52:53 <ddevault> looks like libgit2 & git have a security flaw
2019-12-18 21:53:35 <ddevault> 3.10 main needs libgit2 0.28.4
2019-12-18 21:54:13 <ddevault> ditto for git 2.24.1
2019-12-18 21:58:03 <_ikke_> hmm
2019-12-18 21:58:40 <_ikke_> ddevault: what do you mean with git 2.24.1?
2019-12-18 21:59:12 <_ikke_> I updated all the stable released for git
2019-12-18 21:59:17 <_ikke_> releases
2019-12-18 21:59:29 <ddevault> maybe my mirror is outdated
2019-12-18 21:59:47 <_ikke_> 3.10 contains 2.22.2
2019-12-18 21:59:50 <_ikke_> which should be fixed
2019-12-18 22:00:01 <ddevault> is it? I thought it was fixed in 2.24.1
2019-12-18 22:00:10 <_ikke_> they backported it
2019-12-18 22:00:15 <ddevault> cool
2019-12-18 22:00:18 <ddevault> thanks
2019-12-18 22:01:14 <_ikke_> https://lore.kernel.org/git/xmqqr21cqcn9.fsf@gitster-ct.c.googlers.com/
2019-12-18 22:01:31 <_ikke_> I did not touch libgit2 though
2019-12-19 05:13:23 <okeuday> Hi, regarding the builders that are used for building packages and running their tests, they are using LXC containers without any special clocksource (like kvm-clock) so
2019-12-19 05:14:12 <okeuday> if clock_gettime CLOCK_MONOTONIC return values are used in tests, it is possible for the values to get significant delays as the builder machine switches between LXC containers, right?
2019-12-19 05:14:59 <okeuday> are there any guidelines for that, like not having tests enabled if they are relying on clock_gettime CLOCK_MONOTONIC return values, or timeouts should be a minimum value?
2019-12-19 05:31:35 <_ikke_> okeuday: lxc containers are not virtual machines
2019-12-19 05:31:56 <_ikke_> okeuday: they use the host kernel clock afaik
2019-12-19 05:35:41 <okeuday> _ikke_: that is what I mean, the lxc container execution will be slow while they see the clock jump at the points where they get cpu time
2019-12-19 05:36:18 <_ikke_> okeuday: how is that different for any other process running on the host?
2019-12-19 05:37:05 <_ikke_> there is no virtualization in play
2019-12-19 05:37:06 <okeuday> _ikke_: it isn't really, just when the host is running more, the lag is larger than would normally be expected
2019-12-19 05:37:29 <_ikke_> there is no host running vs lxc running
2019-12-19 05:37:59 <_ikke_> okeuday: the way you describe it sounds like you think lxc containers are vms
2019-12-19 05:38:50 <okeuday> _ikke_: that is not my intention, I may have just been observing times where the builder was overloaded, so that can lead to delays that cause tests to fail
2019-12-19 05:39:32 <_ikke_> okeuday: the host kernel uses tsc as clock source
2019-12-19 05:40:17 <okeuday> _ikke_: yeah, that makes sense, and it is similar to normal processes on a host, so increasing the timeout value seems like the simplest solution
2019-12-19 05:40:19 <_ikke_> at least, on one of the builders
2019-12-19 05:41:21 <okeuday> _ikke_: thanks for the info
2019-12-19 05:41:44 <_ikke_> np
2019-12-19 09:15:48 <north1> @ncopa does 5.4.5 have the fix for Intel GPU hanging?
2019-12-19 09:17:07 <ncopa> no, sorry
2019-12-19 09:17:39 <ncopa> north1: i was thinking of backport it myself, but i'm afraid of doing so before 3.11
2019-12-19 09:17:50 <ncopa> after 3.11 is out, i can try to backport it (to edge)
2019-12-19 09:17:57 <ncopa> and if it works we backport it 3.11
2019-12-19 09:34:10 <mps> 5.4.5 kernel upgrade is only net related
2019-12-19 11:24:29 <mps> overnight run again !1885 in lxc on aarch64, went ok and finished firefox 71.0
2019-12-19 11:30:14 <Cogitri> Good
2019-12-19 11:30:46 <mps> you told that it also pass on x86_64
2019-12-19 11:31:17 <Cogitri> Yup
2019-12-19 11:31:27 <mps> if so, it can be pushed
2019-12-19 11:31:33 <Cogitri> Sure
2019-12-19 11:31:41 <mps> do it! :)
2019-12-19 11:32:11 <mps> I'm on holiday
2019-12-19 11:33:52 <Cogitri> Oh, let's go then :P
2019-12-19 11:33:53 <Cogitri> Have nice holidays :)
2019-12-19 11:33:56 <Cogitri> I still have uni till Friday
2019-12-19 11:34:20 <mps> and add note that cbindgen should stay in downgrade status till all this is fixed
2019-12-19 11:36:29 <mps> note to !2191
2019-12-19 11:41:21 <Cogitri> Yup
2019-12-19 11:45:25 <mps> Cogitri: thanks for good wishes for holiday :)
2019-12-19 11:46:17 <mps> viele danke (trying to refresh my German)
2019-12-19 11:47:03 <PureTryOut[m]> So for ages QML has been completely broken on armhf due to the lack of a JIT compiler and running without it being broken. Wouldn't it be wise to disable the package completely for armhf?
2019-12-19 11:47:33 <PureTryOut[m]> Qt bug report https://bugreports.qt.io/browse/QTBUG-65246
2019-12-19 11:50:55 <PureTryOut[m]> Actually, I'll just make an MR and people can comment on it there
2019-12-19 11:52:14 <PureTryOut[m]> I guess I need to disable armhf for a lot of packages then
2019-12-19 12:05:16 <Cogitri> Yup, but disabling packages which are broken anyway sounds good :)
2019-12-19 12:35:15 <PureTryOut[m]> Hmm and how do you block a subpackage on a specific arch? For example now a subpackage has `$pkgname-sub::noarch`, but how would that be made to `noarch !armhf`?
2019-12-19 12:46:49 <Cogitri> Not quite sure about that, but I don't think that's possible
2019-12-19 12:47:33 <PureTryOut[m]> Hmm ok let's ignore those then
2019-12-19 12:47:59 <PureTryOut[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2230
2019-12-19 13:10:48 <Cogitri> That's quite a lot of pkgs indeed
2019-12-19 13:29:51 <PureTryOut[m]> Yup. I'm fixing a lot of shellcheck stuff in them while I'm at it too
2019-12-19 13:33:24 <ncopa> ok, i thimk im ready for 3.11 release
2019-12-19 13:33:32 <ncopa> may need help writing the release notes
2019-12-19 13:34:40 <mps> ncopa: north1 prepared wiki page somewhere about release notes for 3.11
2019-12-19 13:38:04 <_ikke_> ncopa: I have time this evening if that's early enough
2019-12-19 13:39:16 <_ikke_> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas)
2019-12-19 13:49:47 <ncopa> whaoo, that was much!
2019-12-19 13:49:52 <ncopa> we nee to shorten it a bit
2019-12-19 13:50:13 <ncopa> has anyone tested kde and gnome recently?
2019-12-19 13:50:14 <mps> yes, just looking at it
2019-12-19 13:50:15 <ncopa> is it useful?
2019-12-19 13:50:35 <mps> I mean, list not kde and gnome
2019-12-19 13:52:02 <Cogitri> ncopa: I've been running GNOME ever since and it works pretty well
2019-12-19 13:52:09 <ncopa> good
2019-12-19 13:52:16 <ncopa> then we can announce it
2019-12-19 13:52:54 <Cogitri> The one thing that doesn't work yet is that tracker-store likes to crash, so searching files by metadata doesn't work (e.g. text contained in text files(
2019-12-19 13:53:15 <Cogitri> I'm working on fixing that but the backtrace is some 2500 lines long, so that'll take a bit :P
2019-12-19 13:53:26 <ncopa> heh
2019-12-19 13:53:46 <ncopa> other things we should mention:
2019-12-19 13:53:49 <ncopa> gcc 9
2019-12-19 13:53:51 <ncopa> python 3.8
2019-12-19 13:54:00 <ncopa> support for rip4
2019-12-19 13:54:07 <Cogitri> Not quite on-topic, does gdb load debug symbols properly for you? It loads them rather sporadically for me :/
2019-12-19 13:54:10 <Cogitri> Maybe LLVM9?
2019-12-19 13:54:15 <ncopa> s/rip4/rpi4/
2019-12-19 13:54:15 <alpine-meetbot> ncopa meant to say: support for rpi4
2019-12-19 13:54:25 <ncopa> llvm9
2019-12-19 13:54:30 <ncopa> postgresql 12
2019-12-19 13:55:12 <ncopa> go 1.13
2019-12-19 13:55:50 <PureTryOut[m]> ncopa: I use KDE daily for several months already and works well
2019-12-19 13:56:02 <ncopa> PureTryOut[m]: very good
2019-12-19 13:56:32 <PureTryOut[m]> There are packages in testing that don't work properly, but everything that will be in 3.11 works good ime
2019-12-19 13:56:38 <mps> don't forget linux-lts
2019-12-19 13:56:47 <ncopa> ah, yes, linux-lts
2019-12-19 13:57:01 <Cogitri> Are we going to remove linux-vanilla for 3.11?
2019-12-19 13:57:09 <ncopa> thats a good question
2019-12-19 13:57:09 <PureTryOut[m]> I'm still trying to get Alpine 3.11 to boot on the Pine64 A64LTS, but it's failing so far. `Bad Linux ARM64 Image magic!`
2019-12-19 13:57:18 <ncopa> Cogitri: i think we maybe should
2019-12-19 13:57:46 <mps> I think so, no need to backport issues with -vanilla
2019-12-19 13:57:50 <PureTryOut[m]> mps: you're an ARM guy right? Any idea what `Bad Linux ARM64 Image magic!` means?
2019-12-19 13:57:52 <Cogitri> I think so too
2019-12-19 13:58:01 <ncopa> otherwise we need to maintain it
2019-12-19 13:58:04 <ncopa> which we dont want
2019-12-19 13:58:41 <mps> PureTryOut[m]: I noticed this last night but didn't had time to look how the vmlinuz-lts for aarch64 is built
2019-12-19 13:59:49 <mps> maybe I will find time this night to look what is wrong with kernel image
2019-12-19 13:59:57 <PureTryOut[m]> Hmm ok.
2019-12-19 14:00:35 <ncopa> https://forum.pine64.org/showthread.php?tid=4786&pid=30042#pid30042
2019-12-19 14:00:44 <ncopa> seems like you need to manually gunzip it
2019-12-19 14:01:21 <PureTryOut[m]> Ah good find, let me see how to do that
2019-12-19 14:01:45 <ncopa> I'd guess: gunzip vmlinuz-lts
2019-12-19 14:01:53 <mps> could be this, we gzip kernels
2019-12-19 14:02:18 <PureTryOut[m]> gunzip doesn't like it
2019-12-19 14:02:25 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/kDWvIZHyKGtubQGDOMtOPfpp >

2019-12-19 14:02:47 <mps> bzip?
2019-12-19 14:03:27 <mps> gunnzip -f
2019-12-19 14:03:32 <ncopa> https://stackoverflow.com/questions/8526622/how-to-decompress-compressed-kernel
2019-12-19 14:04:29 <PureTryOut[m]> Seems gunzip and gzip require an extension before decompressing...
2019-12-19 14:05:17 <mps> yes, normally you can't compress .gz file or decompress file without .gz
2019-12-19 14:05:29 <mps> but there are -f switch
2019-12-19 14:06:43 <PureTryOut[m]> That seems to be it! "Starting kernel ..."
2019-12-19 14:07:48 <mps> nice :)
2019-12-19 14:07:50 <PureTryOut[m]> Well, it boot loops now, but I guess it's an improvement lol
2019-12-19 14:08:26 <Cogitri> A different error, hooray! :P
2019-12-19 14:09:58 <PureTryOut[m]> mps: btw at least on gunzip the -f switch doesn't work
2019-12-19 14:10:30 <PureTryOut[m]> man says: `-f, --force       force overwrite of output file and compress links`
2019-12-19 14:10:39 <PureTryOut[m]> Although do note that this is GNU's gunzip
2019-12-19 14:12:41 <PureTryOut[m]> Actually that bootlooping is a lie, that's just the power connector not being entirely solid lol
2019-12-19 14:12:56 <PureTryOut[m]> Still, I get no output after "Starting kernel..."
2019-12-19 14:14:00 <mps> gunzip -c /boot/vmlinuz-lts > lts
2019-12-19 14:14:15 <mps> but you will get wrong result
2019-12-19 14:14:38 <mps> no gzip/bzip2/xz magic
2019-12-19 14:16:39 <ncopa> are there any significant removals?
2019-12-19 14:16:53 <PureTryOut[m]> Well the majority of Python 2 is quite significant
2019-12-19 14:17:42 <_ikke_> mention that python2 is officially deprecated?
2019-12-19 14:18:51 <ncopa> yeah
2019-12-19 14:19:16 <ncopa> this is what i have so far: http://tpaste.us/ObvY
2019-12-19 14:19:54 <ncopa> i think i will go ahead and just remove linux-vanilla kernel
2019-12-19 14:20:48 <Cogitri> Sounds good to me
2019-12-19 14:21:06 <Cogitri> But please replace&provides linux-lts so that users don't get stuck on linux-vanilla :)
2019-12-19 14:21:25 <ncopa> dont need replaces
2019-12-19 14:21:43 <ncopa> but provides
2019-12-19 14:21:52 <mps> should we say something about important changes for pkg upgrade, things which breaks something? clamav upgrade will require clamav-libunrar as separate
2019-12-19 14:22:28 <mps> separate add after clamav upgrade
2019-12-19 14:22:32 <ncopa> yeah
2019-12-19 14:22:39 <ncopa> we should add a section for upgrades
2019-12-19 14:23:03 <ncopa> users should manually apk add linux-lts
2019-12-19 14:23:14 <ncopa> i dont know if we want it to automatically replace linux-vanilla
2019-12-19 14:23:32 <ncopa> if we add provides=linux-vanilla it will uninstall linux-vanilla
2019-12-19 14:23:56 <PureTryOut[m]> ncopa: not sure if we need to specify KDE support better. KDE Plasma is entirely supported, everything there is in `community/`. However, the majority (except base packages) of KDE Applications is still in `testing/`
2019-12-19 14:23:57 <ncopa> so i think we better let it be there, so users can apk add linux-lts, reboot and apk del linux-vanilla
2019-12-19 14:24:29 <mps> did we had firefox for aarch64 in 3.10?
2019-12-19 14:24:31 <ncopa> "Initial GNOME and KDE support"
2019-12-19 14:24:53 <ncopa> i coudl change it to "Basic GNOME and KDE support"
2019-12-19 14:24:54 <ncopa> or similar
2019-12-19 14:25:16 <ncopa> i thought "initial" would indicate that we have the start but not everything yet
2019-12-19 14:25:17 <PureTryOut[m]> I guess there isn't much of a difference there.
2019-12-19 14:25:30 <PureTryOut[m]> Oh well it's fine, hopefully in 3.12 we can say "Full KDE support"
2019-12-19 14:25:57 <ncopa> mps: no
2019-12-19 14:26:03 <mps> we now have firefox-esr
2019-12-19 14:26:04 <PureTryOut[m]> Btw I noticed the git log contains 3 commits/changes under my nickname "PureTryOut" rather than my full name "Bart Ribbers". I guess we can't change that now?
2019-12-19 14:26:08 <ncopa> https://pkgs.alpinelinux.org/packages?name=firefox-esr&branch=v3.10
2019-12-19 14:26:21 <_ikke_> PureTryOut[m]: mailmap
2019-12-19 14:26:26 <ncopa> PureTryOut[m]: we cannot change the commits now
2019-12-19 14:26:38 <PureTryOut[m]> _ikke_: mailmap?
2019-12-19 14:26:43 <PureTryOut[m]> ncopa: yeah was afraid of that. Np
2019-12-19 14:26:50 <_ikke_> https://git.alpinelinux.org/aports/tree/.mailmap
2019-12-19 14:27:13 <PureTryOut[m]> Ah but I'm not sure which commits are under my nickname
2019-12-19 14:27:18 <ncopa> https://blog.developer.atlassian.com/aliasing-authors-in-git/
2019-12-19 14:27:20 <PureTryOut[m]> Just that there are some lol, according to the release notes by ncopa
2019-12-19 14:27:41 <_ikke_> PureTryOut[m]: you can use mailmap to dynamically rewrite
2019-12-19 14:27:45 <mps> ah, we have firefox-esr it in 3.10, then no need to add it in release notes
2019-12-19 14:28:02 <ncopa> we dont have it for aarch64 though
2019-12-19 14:28:12 <ncopa> dont think its important enough to mention in release notes
2019-12-19 14:28:20 <PureTryOut[m]> Ah nvm found it
2019-12-19 14:28:23 <ncopa> i'd like to keep it as short as possible
2019-12-19 14:29:08 <mps> we have firefox-esr now for aarch64
2019-12-19 14:29:38 <mps> this was one of most asked question in two previous releases, iirc
2019-12-19 14:31:11 <PureTryOut[m]> ncopa: could you merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2233 and remake the git shortlog with the result?
2019-12-19 14:31:42 <Cogitri> fwiw almost everything of GNOME is in community/ so initial support sounds good to me
2019-12-19 14:34:25 <PureTryOut[m]> Thanks!
2019-12-19 14:39:12 <PureTryOut[m]> Hmm the release notes you just committed don't have a regenerated shortlog
2019-12-19 14:39:22 <ncopa> yeah
2019-12-19 14:39:26 <ncopa> i just noticed it
2019-12-19 14:42:23 <PureTryOut[m]> 👍️
2019-12-19 14:46:16 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.11.0-released.html
2019-12-19 14:46:32 <ncopa> i will fill in the git shortlog after it is tagged
2019-12-19 14:52:29 <Cogitri> Nextcloud 17.0.2 has been pushed a few minutes ago
2019-12-19 14:52:35 <ncopa> ha!
2019-12-19 14:53:30 <ncopa> otherwise good?
2019-12-19 14:54:54 <Cogitri> Maaaybe initial D support, but maybe we want to save that up for 3.12 when we're going to have gdc and dmd
2019-12-19 15:11:01 <ncopa> did we push D support?
2019-12-19 15:16:41 <ncopa> ok, i'm tagging 3.11.0
2019-12-19 15:17:07 <ncopa> please hold your commits til I have branched 3.11-stable
2019-12-19 15:17:18 <ncopa> and updated the builders
2019-12-19 15:26:35 <north1> Landed in Berlin
2019-12-19 15:26:50 <north1> @ncopa the list is supposed to be big, it is just that we don't forget anything important
2019-12-19 15:26:59 <north1> We can scrap the nonimportant ones
2019-12-19 15:27:50 <Cogitri> ncopa: We've only pushed ldc as of now, so only D support for x86_64
2019-12-19 15:29:14 <ncopa> north1: it was very helpful
2019-12-19 15:30:08 <ncopa> thanks!
2019-12-19 15:45:57 <PureTryOut[m]> Hmm, I can't rebuild qt5-qtwebkit due to the patch making it compatible with Qt 5.12. `Could not find any sync.profile for your module!`, whatever that means
2019-12-19 15:47:15 <ncopa> so this is good to go? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.0-released.html
2019-12-19 15:47:18 <ncopa> for production
2019-12-19 15:47:28 <ncopa> and as email announcement
2019-12-19 15:48:57 <PureTryOut[m]> Wow my commit statistics increased a lot now lol
2019-12-19 15:48:59 <PureTryOut[m]> Yeah seems good to me
2019-12-19 15:49:53 <ncopa> north1 has 4k commits :)
2019-12-19 15:51:50 <PureTryOut[m]> Yeah he does a lot
2019-12-19 15:52:04 <PureTryOut[m]> Also merges my MR's damned quick which I'm really thankful for
2019-12-19 15:55:50 <ncopa> im also thankful for that
2019-12-19 15:56:33 <ncopa> has been incredibly good to be able to work in peace while he has merged MRs
2019-12-19 15:57:22 <fcolista> ncopa, tweet it!
2019-12-19 15:58:03 <ncopa> need push the release notes to web site
2019-12-19 15:58:33 <ncopa> which i just did
2019-12-19 16:00:47 <north1> https://alpinelinux.org/posts/Alpine-3.11.0-released.html
2019-12-19 16:01:11 <fcolista> \0/
2019-12-19 16:01:34 <north1> https://redd.it/ecv4st
2019-12-19 16:04:03 <north1> On clamav needs to be instead of need to be
2019-12-19 16:06:18 <ddevault> gz
2019-12-19 16:06:56 <ncopa> ddevault: xz
2019-12-19 16:07:18 <ddevault> gz is short for congratulations
2019-12-19 16:07:21 <ddevault> on the release
2019-12-19 16:07:45 <ncopa> and xz is short for thanxz :-)
2019-12-19 16:07:51 <ddevault> lol
2019-12-19 16:08:42 <north1> And I tought runescape congratulations was short enough
2019-12-19 16:08:56 <north1> gratz!
2019-12-19 16:09:25 <ncopa> gratz to everyone
2019-12-19 16:09:37 <Cogitri> :)
2019-12-19 16:10:07 <ncopa> it couldn't be done without all the contribs
2019-12-19 16:18:55 <andypost[m]> Hi, how to find why linter complains about https://gitlab.alpinelinux.org/andypost/aports/-/jobs/24206
2019-12-19 16:19:10 <andypost[m]> The backtick is from source https://gitlab.alpinelinux.org/alpine/aports/blob/ec6128f184f70046b94523d3290f3e7298acafbe/community/php7-pecl-mailparse/APKBUILD#L26
2019-12-19 16:21:54 <ncopa> andypost[m]: its a bug in shellcheck apparently
2019-12-19 16:24:40 <ncopa> but ideally, i think it should have been a patch instead of a sed line
2019-12-19 16:26:27 <andypost[m]> ncopa sadly no way to pactch because this Makefile is autogenerated in build()
2019-12-19 16:27:01 <ncopa> no *easy* way i suppose
2019-12-19 16:27:18 <ncopa> you could always patch the generator that generates the makefile
2019-12-19 16:30:34 <andypost[m]> I used to try do this, but it means to patch php7 itself for every package that using "bundled" extensions (they are shared in Alpine)
2019-12-19 16:31:38 <_ikke_> andypost[m]: ah, that's atools lint instead of shellcheck
2019-12-19 16:31:53 <andypost[m]> And looks my MRs for php7 security killing CI
2019-12-19 17:01:03 <north1> @ncopa majority of Python 2 packages 'were' removed
2019-12-19 17:17:38 <kreios> Tested 3.11.0 armv7 on RPI4 and didn't look like it booted. Display stuck at color box. Looking at the contents of the tarfile all the *.dtb files are missing. Adding them back and the system boot message are displayed.
2019-12-19 17:18:19 <kreios> Is this a bug or intentional?
2019-12-19 17:19:07 <_ikke_> sounds like a bug
2019-12-19 17:21:28 <clandmeter> mps: did dtb get removed from rpi images?
2019-12-19 17:31:54 <clandmeter> kreios: could you add an issue to gitlab aports repo?
2019-12-19 17:52:42 <kreios> clandmeter: https://gitlab.alpinelinux.org/alpine/aports/issues/11056
2019-12-19 17:58:37 <mps> I'm mentioned two times in release announce :)
2019-12-19 17:59:25 <mps> clandmeter: didn't touched rpi kernels, will look later what happened with dtbs there
2019-12-19 18:05:56 <Mikey12> Hi Guys, anyone that can point me out to the script that generates the armhf-rpi images like on the download section
2019-12-19 18:08:16 <_ikke_> https://git.alpinelinux.org/aports/tree/scripts
2019-12-19 18:08:37 <Mikey12> mkimg.arm.sh
2019-12-19 18:08:42 <Mikey12> that one ?
2019-12-19 18:09:10 <_ikke_> I think so
2019-12-19 18:09:26 <Mikey12> oke
2019-12-19 18:09:33 <_ikke_> Note that that's just a profile
2019-12-19 18:09:49 <_ikke_> https://git.alpinelinux.org/aports/tree/scripts/mkimage.sh this is the actual script you invoke
2019-12-19 18:10:22 <Mikey12> was just looking at it
2019-12-19 18:10:30 <Mikey12> thank you for pointing me out
2019-12-19 18:11:02 <Mikey12> pointing in the right direction
2019-12-19 18:11:08 <Mikey12> think that is better :-)
2019-12-19 18:11:27 <_ikke_> :)
2019-12-19 18:30:52 <Cogitri> So Rust 1.40 was just released, pushing that into 3.11 once it works on edge should be fine, right?
2019-12-19 18:32:02 <_ikke_> hmm
2019-12-19 18:32:46 <_ikke_> offically 3.11 would only receive bug/sec fixes
2019-12-19 18:33:25 <Cogitri> They haven't changed that much, so not pushing Rust 1.40 into 3.11 wouldn't be that problematic
2019-12-19 18:33:46 <_ikke_> ncopa: should 3.7 be eol now?
2019-12-19 18:33:49 <_ikke_> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2019-12-19 18:34:11 <Cogitri> But since Rust doesn't do longterm releases I'm generally curious how we should handle this best
2019-12-19 18:34:23 <_ikke_> It
2019-12-19 18:34:23 <Cogitri> Rust just being dead in the water for stable releases is rather unfortunate
2019-12-19 18:34:36 <_ikke_> it's in community anyway
2019-12-19 18:34:44 <Cogitri> Yup
2019-12-19 18:34:54 <_ikke_> So alpine is also not comitted to supporting it long time
2019-12-19 18:36:24 <_ikke_> ncopa: I've updated the wiki to mark 3.7 as 'on request only' now
2019-12-19 18:36:27 <Cogitri> Yup, but we don't really support it at all for anything but stable as of now
2019-12-19 18:42:19 <Cogitri> Do changes in the maintainer name (typo fix) need a pkgrel bump?
2019-12-19 18:42:34 <_ikke_> yes, to update the metadata
2019-12-19 18:42:47 <_ikke_> in pkgs.a.o for example
2019-12-19 18:45:47 <Cogitri> Alrighty, wasn't quite sure if it didn't notice that without the pkgrel bump already
2019-12-19 18:47:05 <_ikke_> without a pkgrel bump, nothing is being done
2019-12-19 18:47:15 <_ikke_> You just commit it, but no builder is taking action
2019-12-19 18:47:31 <Cogitri> Okie
2019-12-19 18:47:46 <Cogitri> Yup, but thought that we might pull the metadata from the website from the git repo
2019-12-19 18:48:07 <Cogitri> Another thing: Does someone happen to know why CI doesn't run for !2229?
2019-12-19 18:49:10 <_ikke_> because they disabled CI/CD on their fork
2019-12-19 18:49:28 <Cogitri> Oh, didn't know you could do that
2019-12-19 18:49:32 <_ikke_> enabled it now
2019-12-19 18:49:53 <_ikke_> Not sure how to trigger it now
2019-12-19 18:50:45 <Cogitri> I guess they'll have to force push again
2019-12-19 18:51:23 <_ikke_> close/open does not help
2019-12-19 18:52:34 <Cogitri> Yup, I think it's only triggered on push
2019-12-19 19:00:56 <_ikke_> ok, force pushed now :)
2019-12-19 19:01:13 <_ikke_> the pipeline is running
2019-12-19 19:01:37 <Cogitri> Oh, that works too :P
2019-12-19 19:01:38 <Cogitri> Nice
2019-12-19 19:02:16 <_ikke_> I even made sure to keep the committer the same :)
2019-12-19 19:06:24 <Cogitri> Neat
2019-12-19 20:20:48 <ncopa> _ikke_: thanks for fixing the wiki
2019-12-19 20:21:06 <ncopa> we also need to move all the issues with milestone 3.11.0 to 3.12.0
2019-12-19 20:21:10 <ncopa> or close them
2019-12-19 20:21:19 <ncopa> i closed a few with "due to inactivity"
2019-12-19 20:22:23 <mps> how to 'checkout' 3.11-stable branch in my local repo?
2019-12-19 20:25:35 <mps> on https://alpinelinux.org/downloads/ are still 3.10.3 files
2019-12-19 20:25:54 <ncopa> git checkout -b 3.11-stable -t origin/3.11-stable
2019-12-19 20:26:57 <_ikke_> (after git fetch)
2019-12-19 20:27:07 <mps> thanks, done
2019-12-19 20:34:43 <mps> looking to fix
2019-12-19 20:34:43 <mps> #11056
2019-12-19 20:36:31 <mps> anyone know why dtbs files from broadcom is put in separate dir i.e. "$INSTALL_DTBS_PATH"/broadcom/
2019-12-19 20:36:52 <_ikke_> hmm, anything todo with rpi4?
2019-12-19 20:38:57 <mps> _ikke_: for armv7 rpi dtbs are missing in release tarball
2019-12-19 20:39:16 <mps> think it is same for aarc64
2019-12-19 20:40:20 <mps> I'm working on fix but first for armv7
2019-12-19 20:47:59 <ncopa> i will take tomorrow off
2019-12-19 20:48:17 <ncopa> i have worked more than its healthy the last week(s)
2019-12-19 20:48:20 <ncopa> and i need a break
2019-12-19 20:48:25 <ncopa> will be back on monday
2019-12-19 20:48:31 <_ikke_> ncopa: enjoy your time off!
2019-12-19 20:48:39 <_ikke_> more then deserved :)
2019-12-19 20:48:40 <mps> I always work more than is healthy :)
2019-12-19 20:49:02 <ncopa> _ikke_ and clandmeter can reach me on my phone if necessary
2019-12-19 20:49:15 <_ikke_> mps: downloads should be fixed now
2019-12-19 20:49:23 <mps> ok
2019-12-19 20:49:33 <mps> I follow infra
2019-12-19 20:49:34 <ncopa> mps: thanks for reporting that
2019-12-19 20:49:57 <mps> np
2019-12-19 20:50:37 <mps> a lot of fixes wait for this weekend
2019-12-19 20:51:04 <mps> ncopa: enjoy your time :)
2019-12-19 20:51:48 <ncopa> thanks!
2019-12-19 20:57:52 <nmeum> anyone else getting a 'sh: zfs not found' warning in mkinitfs?
2019-12-19 20:58:10 <kreios> mps: FYI, overlays directory and its files are also missing from the rpi armv7 and aarch64 release tarballs.
2019-12-19 21:03:09 <Cogitri> nmeum: No, but I use ZFS, I guess you don't?
2019-12-19 21:03:14 <Cogitri> What's your cmdline?
2019-12-19 21:03:57 <nmeum> will investigate it in a sec, it's just a warning so it's not critical at all
2019-12-19 21:04:25 <nmeum> was just wondering if this is a known issue
2019-12-19 21:05:39 <mps> kreios: yes, I see
2019-12-19 21:06:19 <HRio> nmeum: I get it at boot. Not using zfs
2019-12-19 21:06:31 <mps> I'm building linux-rpi with changed path to dtbs to test will it work
2019-12-19 21:06:36 <nmeum> HRio: yeah, dito
2019-12-19 21:07:19 <HRio> my zfs boxes are still on v3.10
2019-12-19 21:07:26 <mps> kreios: at glance it seems that overlays (dtbo) and dtb files are put in same dir
2019-12-19 21:10:39 <kreios> mps: Interesting. That is different than how they are laid out on the boot partition.   *.dtb files are at root.  *.dtbo are in the overlays directoory.
2019-12-19 21:14:37 <mps> kreios: true
2019-12-19 21:15:03 <mps> looks like I'm also tired and not only n_copa :)
2019-12-19 21:15:46 <mps> I'm thinking to move dtb files to /boot/dtbs-rpi
2019-12-19 21:16:31 <mps> what do you think where should go overlay files, in /boot/dtbs-rpi/overlays ?
2019-12-19 21:17:45 <clandmeter> looks like setup-apkrepos is slightly broken
2019-12-19 21:19:33 <mpmc> clandmeter: That also describes everyone of the human race.
2019-12-19 21:20:33 <clandmeter> some are broken much more
2019-12-19 21:23:03 <kreios> mps: Raspberry Pi boot layout is here: https://github.com/raspberrypi/firmware/tree/master/boot
2019-12-19 21:24:51 <clandmeter> Cogitri: i just tried to follow the wiki to get gnome running (in qemu)
2019-12-19 21:25:01 <artok> well /boot/overlays
2019-12-19 21:26:00 <kreios> That is how previous Alpine images laid things out as well. *.dtb are at the root, *.dtbo go in an overlays directory in the root. I did that on my system here and it is working without issue.
2019-12-19 21:26:04 <mps> kreios: artok: does it must be '/boot/dtbs' or could be something like '/boot/dtbs-$FLAVOR'
2019-12-19 21:26:07 <clandmeter> after i run apk add gnome-apps i get a lot of output on console.
2019-12-19 21:26:36 <artok> without any settings, it will be /boot/overlays
2019-12-19 21:27:07 <mps> artok: but can be changed in config.txt?
2019-12-19 21:28:04 <artok> https://www.raspberrypi.org/documentation/configuration/device-tree.md
2019-12-19 21:29:35 <artok> afaik no, let's check
2019-12-19 21:29:49 <artok> ah yeah
2019-12-19 21:29:50 <artok> it has
2019-12-19 21:30:02 <artok> overlay_prefix  setting
2019-12-19 21:30:18 <artok> Specifies a subdirectory/prefix from which to load overlays - defaults to "overlays/". Note the trailing "/". If desired you can add something after the final "/" to add a prefix to each file, although this is not likely to be needed.
2019-12-19 21:30:47 <kreios> I should clarify, root of the tarfile.  There is a boot directory at the root of.the tarfile that holds the kernels. I will have. to check to see where /boot from linux perspective is linked.
2019-12-19 21:31:00 <artok> so if you add overlay_prefix=dtbs-$FLAVOR/
2019-12-19 21:32:28 <artok> what modifications I did on mkimg.arm.sh was: if there is raspberry pi, /boot/boot of the fakeroot (install dir) was symlinked into /boot/.
2019-12-19 21:32:47 <artok> that will put kernel into sd card root
2019-12-19 21:32:51 <mps> artok: I meant to say generic $FLAVOR, on creating tarball it will be replaced by linux-$_flavor
2019-12-19 21:33:27 <artok> sure, it needs to be added into config.txt and parsed =)
2019-12-19 21:33:37 <mps> so dtbs can be in  /boot/dtbs-rpi2
2019-12-19 21:33:51 <artok> can, if you add overlay_prefix=dtbs-rpi2/
2019-12-19 21:34:03 <mps> and OVL in /boot/dtbs-rpi2/overlays/
2019-12-19 21:34:03 <artok> into config.txt
2019-12-19 21:35:08 <artok> oh no
2019-12-19 21:35:11 <mps> ok, will look how it is done in Arch linux alarm
2019-12-19 21:35:13 <artok> sorry
2019-12-19 21:35:24 <artok> overlays can be on their won
2019-12-19 21:35:24 <artok> own
2019-12-19 21:35:32 <kreios> My understanding, rpi does separate out the overlays for each platform.
2019-12-19 21:35:39 <mps> this makes sense
2019-12-19 21:35:43 <artok> but dtbs need to be in the root
2019-12-19 21:35:48 <kreios> s/does/doesn't/
2019-12-19 21:35:48 <alpine-meetbot> kreios meant to say: My understanding, rpi doesn't separate out the overlays for each platform.
2019-12-19 21:36:43 <artok> indeed they are all the same tree
2019-12-19 21:36:45 <mps> hmm, it's time to get one RPI for testing
2019-12-19 21:37:16 <artok> but: dtbs needs to be in root, overlays in overlays/ or set the overlay_prefix setting in config.txt
2019-12-19 21:38:28 <mps> artok: are you sure that dtbs must be in root? or you mean /dtbs dir?
2019-12-19 21:39:38 <artok> in root
2019-12-19 21:39:41 <artok> https://hastebin.com/ipocenihic.bash
2019-12-19 21:40:36 <artok> there is whole function of mkimg.base.sh to get rpi initramfs into root
2019-12-19 21:40:44 <artok> and kernel and...
2019-12-19 21:42:12 <mps> which line?
2019-12-19 21:42:37 <artok> 8-10
2019-12-19 21:42:50 <mps> last changes about dtbs dir are mine
2019-12-19 21:43:19 <artok> I took that from my aports repo that hasn't been merged with upsteram...
2019-12-19 21:43:41 <nmeum> HRio: found the cause of the zfs warning https://tpaste.us/re5Q
2019-12-19 21:43:46 <mps> aha
2019-12-19 21:44:27 <artok> and whole rpi_gen_config() function: https://hastebin.com/uzowutacaw.cs
2019-12-19 21:44:39 <hrio[m]> <nmeum "HRio: found the cause of the zfs"> Thanks!
2019-12-19 21:44:48 <mps> artok: this is also your
2019-12-19 21:44:52 <artok> yah
2019-12-19 21:45:33 <artok> when I generated rpi image with those modifications, rpi3 and rpi4 booted from same card
2019-12-19 21:45:34 <mps> what keeps these changes in your local repo?
2019-12-19 21:46:13 <artok> oh no btw... needs to be [pi3], not [rpi3+] on aarch64
2019-12-19 21:46:25 <artok> what keeps ? I do
2019-12-19 21:46:36 <mps> :)
2019-12-19 21:47:35 <artok> when I've been around, I've done upstream merging once in a day
2019-12-19 21:50:16 <mps> arch linux alarm have /boot dir where dtbs files are put and /boot/overlays/ where dtbo (OVL) files are put
2019-12-19 21:50:34 <mps> not in '/'
2019-12-19 21:51:42 <nmeum> Cogitri: https://git.alpinelinux.org/mkinitfs/commit/?id=6e5b1852be0247803ea070a6708010a0d3c2bc3e just FYI
2019-12-19 21:51:45 <mps> looks like this issue will take some time to fix
2019-12-19 21:51:57 <mps> nmeum: not ^
2019-12-19 21:52:27 <nmeum> hm?
2019-12-19 21:53:25 <artok> arch linux has u-boot doing the stuff?
2019-12-19 21:53:26 <mps> nmeum: not this you just posted above my message
2019-12-19 21:53:34 <nmeum> ah
2019-12-19 21:53:40 <Cogitri> Oh, thanks for fixing that, nmeum
2019-12-19 21:54:14 <nmeum> np
2019-12-19 21:54:22 <nmeum> will also backport it to aports in a sec
2019-12-19 21:54:28 <Cogitri> clandmeter: Hm?
2019-12-19 21:54:52 <mps> artok: http://tpaste.us/PMQD content of the /boot dir
2019-12-19 21:55:11 <mps> arch alarm for rpi2
2019-12-19 21:55:18 <clandmeter> Cogitri: not sure which pkg it is, looks like fonts or related.
2019-12-19 21:55:24 <clandmeter> its like watching the matrix
2019-12-19 21:55:36 <artok> mps: that seems correct
2019-12-19 21:55:59 <artok> all .dtb in root and overlays under overlays/ dir
2019-12-19 21:56:12 <Cogitri> clandmeter: I think I'm missing a message or something, I'm a bit confused as to what you're talking about
2019-12-19 21:56:41 <clandmeter> Cogitri: <@clandmeter> after i run apk add gnome-apps i get a lot of output on console.
2019-12-19 21:57:08 <Cogitri> Ah, that's most likely texlive being installed
2019-12-19 21:57:25 <clandmeter> it needs to be that verbose?
2019-12-19 21:57:36 <Cogitri> Dunno, I haven't looked into texlive yet
2019-12-19 21:58:04 <Cogitri> Probably not though
2019-12-19 21:58:31 <Cogitri> But texlive is a complex beast so I was happy that I didn't have to mess with it as of now :P
2019-12-19 21:59:31 <clandmeter> looks like the trigger doesnt do any redirection
2019-12-19 22:00:20 <mps> artok: thanks, now I understand better
2019-12-19 22:02:05 <Cogitri> Also, if you're going to use/test GNOME: could you maybe run `tracker status` in your terminal after a bit and check if `tracker-store` is running (or if your dmesg is spammed by it SIGSEGVing)?
2019-12-19 22:02:39 <Cogitri> I'm unsure if it's crashing due to some incompatibility with our libs or if it's just overwhelmed by the amount of data in my $HOME
2019-12-19 22:02:43 <_ikke_> nmeum: CI failed for mkinitfs
2019-12-19 22:04:00 <nmeum> would be suprised if that's related to my change
2019-12-19 22:04:03 <nmeum> > /bin/sh: git: not found
2019-12-19 22:05:00 <ncopa> i think testsuite for mkinitfs is broken
2019-12-19 22:05:05 <ncopa> may need root access
2019-12-19 22:05:15 <_ikke_> ncopa: you should go to bed ;-)
2019-12-19 22:05:22 <ncopa> i know...
2019-12-19 22:05:23 <nmeum> was thinking the same thing :)
2019-12-19 22:05:26 <mps> artok: I've got linux-rpi4-5.4.5-r0.apk with (for example) 'boot/dtbs-/bcm2835-rpi-a.dtb' and 'boot/dtbs-/overlays/uart3.dtbo'
2019-12-19 22:05:42 <_ikke_> same counts for me though
2019-12-19 22:05:48 <ncopa> ok. im off for real. will power of the machine before somethine else blows up....
2019-12-19 22:05:50 <mps> so, need to remove 'dtbs-/'
2019-12-19 22:05:53 <_ikke_> o/
2019-12-19 22:05:58 <ncopa> thanks for taking care of stuff!
2019-12-19 22:06:09 <nmeum> _ikke_: is there any indication that the mkinitfs testsuite worked before?
2019-12-19 22:06:13 <nmeum> i.e. for the last commit?
2019-12-19 22:06:20 <_ikke_> I have no clue, sorry
2019-12-19 22:06:34 <_ikke_> I just noticed the message in #alpine-commits
2019-12-19 22:06:44 <nmeum> > 1576690841 (travis-ci) mkinitfs:master [failed] |Natanael Copa| ==== release 3.4.4 ==== | https://travis-ci.org/alpinelinux/mkinitfs/builds/626814605
2019-12-19 22:06:50 <nmeum> looks like it failed before
2019-12-19 22:07:02 <nmeum> will ignore this then
2019-12-19 22:08:27 <_ikke_> ok
2019-12-19 22:08:35 <artok> mps why on earth? overlay installation is then messed up
2019-12-19 22:09:17 <artok> mps that dtbs- needs to be removed, then it would be good
2019-12-19 22:09:50 <nmeum> _ikke_: while you are here, are you ok with the following changes to fzf? https://tpaste.us/6VKr
2019-12-19 22:09:54 <nmeum> new version works fine for me
2019-12-19 22:11:21 <mps> artok: I wrote this above
2019-12-19 22:11:26 <mps> so, need to remove 'dtbs-/'
2019-12-19 22:11:36 <artok> yah
2019-12-19 22:12:07 <mps> that is, and on kernel upgrade install all files will be put in proper place
2019-12-19 22:12:11 <_ikke_> nmeum: yes, fine with me
2019-12-19 22:12:30 <artok> then it will boot.. and check config.txt that kernel and initramfs are read from root dir of the sd card, not from boot/ dir
2019-12-19 22:12:56 <artok> rpi4 internal bootloader doesn't allow subdirectories for kernel
2019-12-19 22:13:12 <artok> no-one says that, but that's what I found out
2019-12-19 22:14:08 <mps> not sure for rpi4 but arch alarm rpi2 have kernel and initram in /boot
2019-12-19 22:14:15 <HRio> brlin: https://github.com/ansible/ansible/issues/65711#issuecomment-567692509
2019-12-19 22:14:21 <artok> I'm just saying =)
2019-12-19 22:14:40 <artok> there is no need for /boot/boot type of stuff
2019-12-19 22:14:50 <mps> ok, will look on rpi4 image
2019-12-19 22:15:23 <artok> and since kernel is packaged under boot/ , we need to make that ln -s thingie into mkimg.base.sh
2019-12-19 22:15:25 <mps> doesn't /boot/boot is symlink
2019-12-19 22:15:50 <artok> it isn't when doing the installer package
2019-12-19 22:15:59 <artok> without my addition, that is
2019-12-19 22:16:11 <artok> not in arm at least
2019-12-19 22:17:42 <mps> (broadcom is 'mess' and I'm now more assured that I'm right in avoiding their 'stuff')
2019-12-19 22:18:44 <_ikke_> That's something I agree with
2019-12-20 02:33:10 <brlin> HRio: Thanks for the info, will check it out.
2019-12-20 08:28:46 <mps> we are there https://lwn.net/
2019-12-20 08:31:11 <mps> and https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.11-Released
2019-12-20 08:36:42 <Cogitri> Nice :)
2019-12-20 08:38:03 <mps> comments on phoronix is worth read
2019-12-20 08:54:51 <north1> Never in phoronix comments are worth reading
2019-12-20 08:55:09 <north1> They are worse than reddit
2019-12-20 08:55:26 <north1> BTW reddit alpine Linux thread is currently talking about OpenBSD and how arch is bloated
2019-12-20 08:56:58 <_ikke_> north1: they say that it's incorrect to call 5.4 an LTS?
2019-12-20 08:57:13 <_ikke_> incorrectly :)
2019-12-20 08:59:40 <mps> I mean, it is worth to 'hear' different opinions, whatever they are
2019-12-20 09:00:18 <north1> Well I read the phoronix comments
2019-12-20 09:00:47 <north1> 1/3rd incorrect info, 1/3rd jokes (lol mega libc)
2019-12-20 09:03:52 <mps> imo, this tell us we need to have better (OMG) marketing page
2019-12-20 09:07:33 <north1> Guys
2019-12-20 09:07:38 <north1> Dxvk support is not in
2019-12-20 09:07:43 <north1> Dxvk is in testing/
2019-12-20 10:03:50 <Cogitri> Oops :P
2019-12-20 10:18:26 <mps> can someone post reddit link about 3.11 release
2019-12-20 10:20:01 <_ikke_> https://www.reddit.com/r/linux/comments/ecv4st/alpine_3110_released/
2019-12-20 10:20:02 <alpine-meetbot> [REDDIT] Alpine 3.11.0 released (https://alpinelinux.org/posts/Alpine-3.11.0-released.html) to r/linux | 123 points (93.0%) | 27 comments | Posted by maxice8_ | Created at 2019-12-19 - 16:00:25UTC
2019-12-20 10:20:40 <mps> thanks
2019-12-20 13:28:32 <mps> is the author of this here https://lists.alpinelinux.org/~alpine/aports/patches/3175
2019-12-20 13:28:37 <mps> dino-git
2019-12-20 13:29:01 <mps> why it is named with -git suffix
2019-12-20 13:29:36 <_ikke_> mps: some distros have that as standard for packages which are derived from the latest git version (rather than a release)
2019-12-20 13:31:03 <mps> _ikke_: yes, but I don't see reason for this, we usually keep one version of pkg, as I'm aware
2019-12-20 13:31:50 <mps> and there is no dino pkg in aports
2019-12-20 13:32:32 <mps> upstream named pkg just 'dino'
2019-12-20 13:51:29 <MY-R> mps, he probably used Arch AUR file because it is only place where using -git for this package :P isnt possible to write comment under patch on ML? :/
2019-12-20 13:54:12 <mps> MY-R: yes it is possible (write comment) but I dislike to use our ML, so if you have time .... :)
2019-12-20 14:20:57 <MY-R> mps, you can always send to him email! :D Im not using ML either :P
2019-12-20 14:25:07 <mps> np, maybe someone else will ask author about this
2019-12-20 14:26:47 <clandmeter> i dont think we prefer the -git suffix, better to use it in the version.
2019-12-20 14:30:24 <mps> right
2019-12-20 14:30:58 <clandmeter> but it looks like upstream doesnt like versioning.
2019-12-20 14:31:30 <clandmeter> i would not add it to aports if upstream doesnt care.
2019-12-20 14:32:03 <mps> I created wiringx (locally, not yet pushed) which also doesn't have release
2019-12-20 14:32:43 <mps> named it wiringx and version 0_git$rev
2019-12-20 14:46:57 <kaniini> hi
2019-12-20 14:47:14 <kaniini> is the maintainer of testing/frr present?
2019-12-20 15:03:46 <ahmedbilal> What does alpine don't like? 1. glibc 2. systemd  any more?
2019-12-20 15:04:12 <kaniini> alpine is not against either of those things
2019-12-20 15:04:20 <kaniini> we just do not use them
2019-12-20 15:04:27 <ahmedbilal> nope just need comic ideas :)
2019-12-20 15:06:01 <kaniini> > linux-vanilla has been removed. Install linux-lts when upgrading.
2019-12-20 15:06:18 <kaniini> ???? why not provides=linux-vanilla=${pkgver}-r${pkgrel} ?
2019-12-20 15:06:33 <_ikke_> kaniini: there was a reason for that
2019-12-20 15:06:43 <kaniini> i'm sure there was, but what is it
2019-12-20 15:08:32 <mps> kaniini: maintainer time
2019-12-20 15:08:34 <_ikke_> http://tpaste.us/RzoY
2019-12-20 15:09:05 <mps> ah, you asked something else
2019-12-20 15:09:34 <kaniini> yes, it will uninstall it, but as linux-lts is sucessor to linux-vanilla wouldn't that be desired ?
2019-12-20 15:10:05 <kaniini> (note i'm not terribly happy with the way we build kernels anyway, it's quite messy)
2019-12-20 15:11:00 <_ikke_> kaniini: I guess ncopa wanted to prevent linux-vanilla to be removed while it's still being used (and preventing new modules from being loaded for example)
2019-12-20 15:11:36 <kaniini> i wonder if what we should actually do is have a package for each individual branch
2019-12-20 15:11:42 <kaniini> which provides linux and linux-lts
2019-12-20 15:11:54 <kaniini> that way, it won't be automatically uninstalled
2019-12-20 15:12:01 <kaniini> unless you use --available
2019-12-20 15:12:14 <kaniini> in which case the highest ranked provider will replace the current selection
2019-12-20 15:13:46 <kaniini> maybe i should write a mail about this
2019-12-20 15:16:53 <mps> afaik, n_copa plan to make separate kernel which will follow upstream more closely and keep -lts for for those who want LTS kernels
2019-12-20 15:17:51 <kaniini> sure, but it can be done that way
2019-12-20 15:17:56 <kaniini> still :)
2019-12-20 15:24:24 <mps> kaniini: what do you mean by 'have a package for each individual branch'
2019-12-20 15:24:42 <mps> kernel branch or alpine branch (stable)
2019-12-20 15:50:10 <kaniini> kernel branch
2019-12-20 16:02:16 <mps> this sounds fine to me
2019-12-20 16:02:37 <Cogitri> Sounds like a lot of work
2019-12-20 16:05:29 <mps> well, should add 'if we have enouhg maintainers sounds fine ...'
2019-12-20 16:08:33 <north1> ikke can you fix the 3.11 changelog?
2019-12-20 16:08:38 <north1> Dxvk is in testing
2019-12-20 20:12:09 <ddevault> seems pkgs.alpinelinux.org does not have 3.11
2019-12-20 20:34:44 <_ikke_> ddevault: ah, we still need to add that
2019-12-20 20:38:29 <_ikke_> ddevault: it should appear soon
2019-12-20 20:38:44 <ddevault> thx _ikke_
2019-12-21 09:05:29 <clandmeter> https://www.phoronix.com/scan.php?page=article&item=alpine-linux-311&num=1
2019-12-21 11:52:51 <russkel> interesting
2019-12-21 11:53:08 <russkel> well I'm wiping ubuntu off our workstations and putting clear linux on them
2019-12-21 11:54:54 <mps> so, I can abuse CI to build kernel for me, and download artefacts (apk) to test kernels
2019-12-21 13:03:44 <nmeum> anybody with builder access around? bmake builds fine locally and on CI but fails (only on x86* strangely?) during check() with a usage error, would like to know what invocation causes that usage error (invoke src/bmake/boot-strap with set -x)
2019-12-21 13:04:00 <nmeum> not super important but I have no other means of debugging this further (except pushing debugging commits which I would prefer not to)
2019-12-21 13:04:48 <mps> nmeum: you mean lxc builder
2019-12-21 13:06:54 <nmeum> yeah, build.alpinelinux.org
2019-12-21 13:06:58 <mps> ah, official alpine builders
2019-12-21 13:07:05 <nmeum> yep
2019-12-21 13:07:25 <mps> afaik, only _ikke_
2019-12-21 13:07:42 <mps> over the weekend, I mean
2019-12-21 13:29:08 <mps> nmeum: 'NOTE: default prefix=/usr/local', could this be reason for bmake fail
2019-12-21 13:29:45 <nmeum> nope, that's just a note because I didn't set the prefix for the check operation since there should be no need to as it doesn't install any files
2019-12-21 13:30:03 <nmeum> and if that would be the case it should also fail locally and on the builders
2019-12-21 13:30:07 <nmeum> s/builders/CI/
2019-12-21 13:30:07 <alpine-meetbot> nmeum meant to say: and if that would be the case it should also fail locally and on the CI
2019-12-21 13:30:46 <mps> ok, asked before try to build on my local lxc
2019-12-21 13:31:51 <nmeum> my best guess is that the following shell function from the bmake build script doesn't work on the ci https://tpaste.us/XgvD
2019-12-21 13:32:01 <nmeum> though I am very suprised that it passes on arm* but not on x86* then
2019-12-21 13:34:15 <mps> when rsync aport finished I will try in local lxc
2019-12-21 13:50:34 <nmeum> ok, thanks
2019-12-21 13:53:58 <mps> nmeum: it pass without problem on local x86_64 lxc
2019-12-21 13:55:41 <nmeum> hm, strange. but thanks for checking
2019-12-21 14:28:51 <Cogitri> Does someone happen to want to upgrade LLVM9 to 9.0.1? Otherwise I'll try to look into it soon-ish and backport to 3.11
2019-12-21 14:37:59 <wsinatra> anyone have any idea why the lua5.3 package wouldn't provide /usr/bin/lua?
2019-12-21 14:40:15 <wsinatra> the apkbuild doesn't indicate that it shouldn't.. maybe it's fennels makefile
2019-12-21 14:43:52 <wsinatra> it's just peculiar. If I apk add lua or lua5.2/5.3 which lua returns nothing, but lua5.1 always produces /usr/bin/lua
2019-12-21 14:48:25 <_ikke_> nmeum: how can I help?
2019-12-21 14:57:58 <nmeum> _ikke_: can you edit src/bmake/boot-strap and add set -x to it (somewhere in the beginning) and rerun the build? would that be possible?
2019-12-21 14:58:40 <nmeum> this should help figuring out which bmake invocation causes the usage message to be printed and the build to be aborted
2019-12-21 15:00:32 <nmeum> wsinatra: I am not too familiar with the lua aports, but if you found an unconsistency between the different lua aports, just open an issue for it. otherwise it just gets lost in the irc backlog
2019-12-21 15:00:38 <nmeum> *inconsistency
2019-12-21 15:16:30 <wsinatra> nmeum: a good point there, I'll go that route since it's saner
2019-12-21 15:23:01 <_ikke_> nmeum: strange, no usage
2019-12-21 15:23:58 <nmeum> so if you invoke the build manually it passes?
2019-12-21 15:24:23 <_ikke_> with abuild build
2019-12-21 15:24:25 <_ikke_> yes
2019-12-21 15:24:41 <nmeum> hm, that sucks
2019-12-21 15:25:09 <nmeum> should I just push a patch which adds set -x to the boot-strap script to aports? or just disable the testsuite?
2019-12-21 15:38:21 <_ikke_> nmeum: ah, `abuild check` gives usage
2019-12-21 15:38:36 <_ikke_> but boot-strap is not invoked then
2019-12-21 15:39:04 <_ikke_> Ok
2019-12-21 15:39:06 <_ikke_> I have output
2019-12-21 15:39:31 <_ikke_> http://tpaste.us/LYyK
2019-12-21 15:39:51 <nmeum> ahh
2019-12-21 15:49:15 <nmeum> the invocation looks correct though and is (except for the linux version the same as on my system)
2019-12-21 16:00:53 <nmeum> _ikke_: if you have enough time on your hands could you rebuild with this patch https://tpaste.us/Z0Kl ? otherwise I would just push it
2019-12-21 16:31:34 <_ikke_> nmeum: I'll test it
2019-12-21 16:33:23 <nmeum> scrolling through the source that's the only usage() invocation without any additional debug messages, by enabling the debug message we should manage to figure out why this invocation is considered invalid
2019-12-21 16:37:45 <_ikke_> nmeum: https://tpaste.us/lYb6
2019-12-21 16:40:16 <_ikke_> the getopt flags do include -f
2019-12-21 16:40:16 <nmeum> that's fucked up, there is no l flag in the invocation
2019-12-21 16:40:24 <nmeum> > getopt(BC:D:I:J:NST:V:WXd:ef:ij:km:nqrstv:w) -> 108 (l)
2019-12-21 16:40:37 <nmeum> this means that the flag parser encountered the flag 'l' which is unknown
2019-12-21 16:40:41 <_ikke_> ah ok
2019-12-21 16:40:49 <nmeum> but I don't see an l flag in the invocation
2019-12-21 16:40:57 <_ikke_> me neither
2019-12-21 16:41:07 <_ikke_> and why only on the builder
2019-12-21 16:41:25 <nmeum> I am clueless, the only proper way to debug this further is with gdb I guess
2019-12-21 16:41:37 <_ikke_> ok, let's see if I can find something
2019-12-21 16:41:59 <nmeum> probably also need to rebuild the entire thing with debugging symbols then
2019-12-21 16:42:20 <nmeum> is there any way I could get access to an environment where I can debug this further as well?
2019-12-21 16:43:26 <_ikke_> mps said that it didn't fail in a generic lxc container, correctA
2019-12-21 16:43:28 <_ikke_> ?
2019-12-21 16:43:33 <nmeum> yep
2019-12-21 16:44:17 <mps> right, it pass
2019-12-21 16:45:17 <nmeum> _ikke_: can you reproduce this independed of the boot-strap script? e.g. by copying the bmake invocation causing this issue to the shell?
2019-12-21 16:46:50 <_ikke_> let me check
2019-12-21 16:49:26 <_ikke_> nmeum: then it works
2019-12-21 16:49:32 <nmeum> Oo
2019-12-21 16:49:51 <nmeum> so maybe some shell related word splitting issue then?
2019-12-21 16:50:01 <_ikke_> might be
2019-12-21 16:55:12 <nmeum> would really like to fix this but without being able to reproduce it, it's really hard
2019-12-21 16:55:50 <nmeum> unless you want to debug this further or I get access to some environment where I can reproduce this, I would just suggest disabling the test suite
2019-12-21 16:55:57 <_ikke_> understood, trying to figure out what the difference is between the builder on other lxc containers
2019-12-21 16:56:32 <_ikke_> I might try one stab at debugging it
2019-12-21 16:56:44 <nmeum> that would be good to know in general, isn't the first time I've seen something fail only on the builders
2019-12-21 16:57:24 <nmeum> if you take another stab at it take a look at the BMake function from boot-strap that might be the root cause, e.g. try removing the sub shell et cetera https://tpaste.us/dEoL
2019-12-21 16:58:55 <nmeum> also: you could try running the boot-strap script with a different shell implementation, e.g. add bash to makedepends and substitute sh for bash in the APKBUILD to rule out the possibility that this is a bug in busybox ash
2019-12-21 16:59:40 <_ikke_> removing the subshell still fails
2019-12-21 17:03:18 <_ikke_> no change with bash
2019-12-21 17:03:57 <nmeum> strange
2019-12-21 17:04:00 <nmeum> I am running out of ideas
2019-12-21 17:05:02 <_ikke_> adding a dbg subpackage should automatically flags to build with symbols, right?
2019-12-21 17:05:09 <_ikke_> s/flags/add flags/
2019-12-21 17:05:09 <alpine-meetbot> _ikke_ meant to say: adding a dbg subpackage should automatically add flags to build with symbols, right?
2019-12-21 17:05:53 <nmeum> https://git.alpinelinux.org/abuild/tree/abuild.in#n2600 yes
2019-12-21 17:07:15 <_ikke_> don't see a -g flag added
2019-12-21 17:09:35 <_ikke_> even when I manually add -g to CFLAGS
2019-12-21 17:10:47 <_ikke_> I'm now in a gdb session invoked through boot-strap
2019-12-21 17:11:13 <_ikke_> If I run it, I get the usage, so we can start debugging
2019-12-21 17:11:18 <nmeum> so the -g flag doesn't show up in the bmake gcc output? because if I compile with `DEBUG=1 abuild -r` it does
2019-12-21 17:11:28 <_ikke_> nmeum: it doesn't
2019-12-21 17:11:36 <_ikke_> let me try DEBUG=1
2019-12-21 17:11:52 <_ikke_> note that I don't use abuild -r
2019-12-21 17:12:24 <_ikke_> gcc -c -Os -fomit-frame-pointer -I. -I/home/buildozer/aports/testing/bmake/src/bmake -DHAVE_CONFIG_H -Os -fomit-frame-pointer -I/home/buildozer/aports/testing/bmake/src/bmake/missing -DMAKE_NATIVE -DUSE_META -DBMAKE_PATH_MAX=1024 -o stresep.o /home/buildozer/aports/testing/bmake/src/bmake/stresep.c
2019-12-21 17:12:30 <_ikke_> I don't see a -g in there
2019-12-21 17:12:45 <nmeum> strange, https://tpaste.us/4EvX here is my build log
2019-12-21 17:13:10 <PureTryOut[m]> Is it possible for anyone to recompile qt5-qtwebkit? An MR of mine tries too but fails while patching, but I didn't modify the package except for disabling an arch
2019-12-21 17:13:57 <_ikke_> PureTryOut[m]: you mean pkgrel bump?
2019-12-21 17:14:10 <nmeum> without debugging symbols debugging will be hard but if you set a breakpoint in main take a look at `argv` and maybe step through the parsing loop in the MainParseArgs function
2019-12-21 17:14:22 <_ikke_> ok
2019-12-21 17:14:24 <nmeum> (you will need debugging symbols for that though)
2019-12-21 17:14:38 <_ikke_> yup
2019-12-21 17:14:56 <PureTryOut[m]> _ikke_: basically yes
2019-12-21 17:15:05 <PureTryOut[m]> Just try rebuilding it in anyway
2019-12-21 17:16:18 <_ikke_> nmeum: did you explicitly echo CFLAGS?
2019-12-21 17:17:18 <_ikke_> nmeum: I do see -g in cflags
2019-12-21 17:18:14 <nmeum> I did echo echo $cflags in build()
2019-12-21 17:18:47 <nmeum> if you don't see it just add in manually by adding `export CFLAGS = $CFLAGS -g` to build() if that doesn't work (which it should) you could modify the makefile directly as a last resort
2019-12-21 17:20:02 <_ikke_> nmeum: I did echo $CFLAGS in build, and I did see -g present there
2019-12-21 17:20:12 <_ikke_> but even adding it manually to CFLAGS did not work
2019-12-21 17:20:23 <_ikke_> So was indeed already looking at the Makefile
2019-12-21 17:21:46 <_ikke_> Even adding CFLAGS += -g in the Makefile does not add them :-/
2019-12-21 17:22:22 <nmeum> Oo
2019-12-21 17:22:28 <_ikke_> Like if something is removing it
2019-12-21 17:22:49 <nmeum> can you add something else?
2019-12-21 17:22:56 <nmeum> as in: another flag or is that removed as well
2019-12-21 17:23:03 <nmeum> e.g. try -O0
2019-12-21 17:23:19 <_ikke_> ok
2019-12-21 17:24:30 <_ikke_> neither
2019-12-21 17:28:27 <_ikke_> not sure what changed, but now the -g flag is there :-/
2019-12-21 17:28:38 <nmeum> magic
2019-12-21 17:30:38 <_ikke_> argv is as we expect it
2019-12-21 17:31:20 <nmeum> so it's a bug in the option parser then
2019-12-21 17:32:15 <nmeum> but why would it only happen when invoked from boot-strap then? hm …
2019-12-21 17:32:24 <nmeum> either way probably best to debug the MainParseArgs then
2019-12-21 17:35:30 <_ikke_> http://tpaste.us/MbYP
2019-12-21 17:35:39 <_ikke_> in MainParseArgs
2019-12-21 17:35:49 <nmeum> where is that coming from?
2019-12-21 17:35:54 <_ikke_> good question
2019-12-21 17:35:57 <nmeum> ah
2019-12-21 17:36:08 <nmeum> what's MAKEFLAGS set to in /etc/abuild.conf ?
2019-12-21 17:36:30 <nmeum> wow that's really the explanation
2019-12-21 17:36:33 <_ikke_> yup
2019-12-21 17:36:35 <_ikke_> indeed
2019-12-21 17:36:38 <nmeum> wow
2019-12-21 17:36:58 <nmeum> that's so painfully obvious
2019-12-21 17:37:32 <_ikke_> so probably unset MAKEFLAGS in check?
2019-12-21 17:37:55 <nmeum> yes
2019-12-21 17:38:37 <nmeum> _ikke_: https://tpaste.us/EO46 can you test this real quick before I push it?
2019-12-21 17:39:34 <nmeum> also lessons learned: would probably be need to add the output of env(1) to the build log produced by build.alpinelinux.org?
2019-12-21 17:39:36 <_ikke_> bingop
2019-12-21 17:39:38 <_ikke_> bingo
2019-12-21 17:39:38 <nmeum> s/need/neat/
2019-12-21 17:39:38 <alpine-meetbot> nmeum meant to say: also lessons learned: would probably be neat to add the output of env(1) to the build log produced by build.alpinelinux.org?
2019-12-21 17:40:00 <nmeum> _ikke_: ok, great. will push it in a sec
2019-12-21 17:40:06 <nmeum> _ikke_: thanks a lot for debugging this :)
2019-12-21 17:40:08 <_ikke_> nmeum: np
2019-12-21 17:40:22 <_ikke_> nmeum: probably something to add to abuild?
2019-12-21 17:41:51 <nmeum> maybe, I guess I will just open an issue for this so we can discuss how it can be implemented later?
2019-12-21 17:41:56 <_ikke_> yes
2019-12-21 17:41:58 <_ikke_> sounds good
2019-12-21 17:45:07 <_ikke_> ..
2019-12-21 17:46:19 <nmeum> probably just build an old version
2019-12-21 17:46:43 <_ikke_> yup
2019-12-21 17:46:54 <_ikke_> nop
2019-12-21 17:46:56 <nmeum> ah
2019-12-21 17:47:01 <nmeum> gotta set it for the install() too
2019-12-21 17:47:05 <_ikke_> ok
2019-12-21 17:47:26 <nmeum> I guess I will just unset it globally
2019-12-21 17:54:03 <nmeum> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10665
2019-12-21 17:54:09 <nmeum> build also passed on x86 now \o/
2019-12-21 17:58:59 <_ikke_> \o/
2019-12-21 18:37:14 <north1> Nice work guys
2019-12-21 18:37:20 <nmeum> _ikke_: is there any reason why bmake wasn't build on x86 yet? did you pause it manually?
2019-12-21 18:37:51 <SpaceToast> https://gitlab.alpinelinux.org/SpaceToast/aports/-/jobs/24767 - is there something up with armv7 / aarch64 builders?
2019-12-21 18:38:01 <SpaceToast> gcc can't find ld in builds for whatever reason
2019-12-21 18:40:24 <nmeum> SpaceToast: on arm* go is using gold ld in some scenarios
2019-12-21 18:40:37 <nmeum> try adding binutils-gold to depends
2019-12-21 18:40:56 <SpaceToast> nmeum: thanks :)
2019-12-21 18:41:34 <nmeum> you're welcome
2019-12-21 18:49:14 <_ikke_> nmeum: no, I did not pause anythingA
2019-12-21 18:50:02 <nmeum> just wondering because according to the web frontend it has been in the "pulling git" state for quite a while
2019-12-21 18:51:04 <_ikke_> probably stale message
2019-12-21 21:34:34 <alexeymin> Hi! Is there something like libapk, some library that would allow to use apk functionality programmatically without invoking CLI tool?
2019-12-21 21:37:23 <_ikke_> alexeymin: I don't think so
2019-12-21 21:37:59 <_ikke_> alexeymin: but there is going to be a big upgrade of apktools, so might be good time to add that
2019-12-21 21:39:14 <alexeymin> I did some digging and found only this https://pkgs.alpinelinux.org/contents?branch=edge&name=lua5.2-apk&arch=x86_64&repo=main
2019-12-21 21:39:36 <alexeymin> which contains something that looks like a shared library, but i's for lua
2019-12-21 21:39:43 <_ikke_> right, some kind of lua module
2019-12-21 21:41:32 <alexeymin> and Makefile of apk contains some mentions of libapk https://gitlab.alpinelinux.org/alpine/apk-tools/blob/master/src/Makefile#L15
2019-12-21 21:42:06 <alexeymin> looks like there were some plans on that?
2019-12-21 21:42:51 <_ikke_> I guess so, I don't know all the details
2019-12-21 21:43:23 <alexeymin> _ikke_: any more information about that "big apktools upgrade"?
2019-12-21 21:43:56 <_ikke_> https://lists.alpinelinux.org/~alpine/devel/%3C20191203180717.0016af8a%40vostro%3E
2019-12-21 21:46:11 <alexeymin> oh right, mailing lists.. I probably should subscribe to those, thanks
2019-12-22 09:09:59 <nmeum> _ikke_: if you have a minute, could you make sure that the x86_64 builder is really not stuck? because there haven't been any messages from it in #alpine-commits, according to build.alpinelinux.org it is still pulling git and according to pkgs.alpinelinux.org it hasn't build bmake and other packages yet
2019-12-22 09:43:16 <HRio> somebody here with push to main permission? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2279 fixes code that does not work on all POSIX shells.
2019-12-22 10:08:18 <Cogitri> Uuggh
2019-12-22 10:08:34 <Cogitri> Apparently the Rust build on the builders went wrong
2019-12-22 10:09:24 <Cogitri> So the rpath is messed up and rustc can't find its libs unless you pass LD_LIBRARY_PATH="/usr/lib/rustlib/$target"
2019-12-22 10:10:11 <Cogitri> Sorry for the breakage, all these downstream patches get a bit annoying
2019-12-22 10:22:44 <mps> 'uname -a' => 5.4.6-0-lts #1-Alpine SMP Sat, 21 Dec 2019 12:58:54 UTC x86_64 GNU/Linux
2019-12-22 10:23:52 <mps> after one day of usage it looks little better than previous but still have relatively (for Alpine) high RAM usage
2019-12-22 10:24:32 <mps> probably firefox is RAM eater
2019-12-22 10:34:44 <north1> Firefox was hungrier with ram than chromium was, for me
2019-12-22 10:42:29 <Cogitri> Uhhh...seems like CI and builders didn't generate one of required libs for rustc, how did that work on my local rig ><
2019-12-22 10:43:27 <Cogitri> Can we maybe import Rust 1.39.0 back into the repo for edge (maybe from 3.11)? I don't think I can bootstrap another rustc from that, sorry...
2019-12-22 10:44:08 <Cogitri> Huh, apparently abuild even warned about this on CI: `>>> ERROR: rust*: librustc_driver-98c004e8e9c9040f.so: path not found`, but abuild kept going so CI went green
2019-12-22 11:29:28 <_ikke_> nmeum: hmm, alright. I did already check some things and restarted the service
2019-12-22 12:10:37 <north1> Going back home
2019-12-22 13:41:38 <wsinatra_>  
2019-12-22 13:45:14 <wsinatra_> if anyone has a minute could they look at MR #2261 and let me know if anything else seems amiss?
2019-12-22 13:46:31 <_ikke_> !2261
2019-12-22 13:48:06 <mps> 'lua lisp implementation', what that means
2019-12-22 13:49:27 <wsinatra_> it's a bit odd, but it's a tiny lisp written in lua that can compile to lua script
2019-12-22 13:50:16 <wsinatra_> kid of like ecl compiles to C vs sbcl compilation to straight machine code. it's lisp in syntax mostly
2019-12-22 13:50:19 <mps> it looks odd, looking at syntax
2019-12-22 13:51:34 <wsinatra_> it kind of feels like scheme or clojure/clojurescript to me. It's not a true lisp, but I would prefer to write lua in a lisp fashion than learn lua :)
2019-12-22 13:52:24 <mps> isn't it better and easier to write in lua directly
2019-12-22 13:53:10 <_ikke_> better is subjective :)
2019-12-22 13:53:20 <mps> 
ACTION dislike layers everywhere

2019-12-22 13:53:51 <wsinatra_> Probably better for most, but I'm all in on lisp
2019-12-22 13:54:36 <wsinatra_> so in my mind this removes nuances I would need to remember specifically about lua, while backing up my knowledge of lisp
2019-12-22 13:55:19 <wsinatra_> My logic is probably bad, but I'm gungho about my lisp stuff!
2019-12-22 13:56:55 <mps> 
ACTION dislike logic, also :)

2019-12-22 13:58:29 <wsinatra_> hahaha, I use lisp in production, so how much logic do we really need?
2019-12-22 13:58:31 <joneskoo> alpine-conf#10451 - is there some end-to-end tests for alpine as cross-package functionality test would probably otherwise not be possible?
2019-12-22 13:58:38 <joneskoo> https://gitlab.alpinelinux.org/alpine/alpine-conf/issues/10451
2019-12-22 14:01:07 <mps> wsinatra_: I never tried lisp (except some simple play) so cannot tell much about it, but please don't take my words about fennel seriously
2019-12-22 14:04:09 <wsinatra_> You're good mps! No offense taken at all. I have a good sense of humor :)
2019-12-22 14:04:41 <mps> anyone with RPI knowledge here to look at tarball I made and tell does it look ok, http://tpaste.us/xka1
2019-12-22 14:05:21 <joneskoo> mps: what do you mean ok? what I'd do is compare to the release tarball. what was changed?
2019-12-22 14:05:33 <mps> wsinatra_: nice to hear :) we had nice conversations some time ago, iirc
2019-12-22 14:06:12 <mps> joneskoo: look at url I posted, there are dtbs and overlays dir with dtbos
2019-12-22 14:06:30 <mps> does it looks ok
2019-12-22 14:07:15 <mps> (although I would prefer if we put these files under /boot )
2019-12-22 14:09:38 <wsinatra_> mps: you're quiet right we have! (though now we've wandered well away from devel I think)
2019-12-22 14:11:20 <joneskoo> mps: I mean visually it looks similar to aarch64 or armhf structure, has config.txt and a bunch of overlays and stuff. Looks what I'd expect?
2019-12-22 14:12:15 <mps> joneskoo: thanks, I will prepare MR for linux-rpi then, and post
2019-12-22 14:12:48 <joneskoo> I'm not clear about the difference between -rpi, -rpi2 and -rpi4 kernels. I assume rpi is for 32bit, rpi2 is for 64bit and rpi4 for specifically the new rpi4 hardware?
2019-12-22 14:12:56 <wsinatra> quut
2019-12-22 14:13:51 <joneskoo> at least I saw my Raspberry Pi 3B+ boot on armhf rpi2 kernel earlier and from the same release Zero boots -rpi kernel so I assume the difference is armhf vs. armv7 kernel.
2019-12-22 14:16:44 <mps> joneskoo: it is not about will kernel boot or not, it is to check are needed files in release tarballs there and in proper place (dirs)
2019-12-22 14:33:25 <joneskoo> mps: https://tpaste.us/yZgp
2019-12-22 14:38:32 <joneskoo> so were 3.11.0 releases broken then, missing overlays? https://tpaste.us/Ypdr is the diff to rc3-armhf which I'm running and works fine for me
2019-12-22 15:42:30 <nmeum> _ikke_: do not mean to annoy you but the x86_64 builder does still not seem to function correctly. maybe the checkout of the aports repository is in a dirty state?
2019-12-22 15:47:14 <_ikke_> I'll check in a moment
2019-12-22 15:49:27 <_ikke_> nmeum: that was it indeed
2019-12-22 15:49:29 <_ikke_> thanks
2019-12-22 15:50:55 <nmeum> np
2019-12-22 16:12:43 <nmeum> mps: are you still planning on testing !2113? i don't mind if you do or don't but if you don't I would just push it as is
2019-12-22 16:17:32 <mps> nmeum: I will but didn't had time trying to fix kernel and tarballs for rpi, although I put your patch on my local build box
2019-12-22 16:18:46 <mps> and I don't think my test is something which should hold you to not push it
2019-12-22 17:24:34 <mps> north1: does this in kernel 5.4.6 sounds promising for your issue drm/i915/gvt: Fix cmd length check for MI_ATOMIC
2019-12-22 17:24:48 <north1> Oh nice
2019-12-22 17:25:22 <north1> I'm in a flixbus from Berlin to Stuttgart, will arrive around 21:30, then a few more mins until Ludwigsburg
2019-12-22 17:25:35 <mps> you can download from gitlab artefacts from my MR to upgrade kernel
2019-12-22 17:26:03 <north1> Ok
2019-12-22 17:26:18 <mps> I installed it yesterday and testing, looks fine, didn't had lock (yet)
2019-12-22 17:28:16 <north1> Also don't know how long until gitlab CI deletes the artefact
2019-12-22 17:28:48 <mps> ask _ikke_ , I think about week
2019-12-22 17:35:25 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/blob/master/.gitlab-ci.yml#L40
2019-12-22 17:36:55 <mps> ah, so it expired
2019-12-22 18:31:14 <mps> hmm, could be interesting for CI monitoring https://github.com/nbedos/citop
2019-12-22 18:32:42 <_ikke_> gitlab ci is not mentioned
2019-12-22 18:38:05 <mps> it is
2019-12-22 18:39:21 <mps> List pipelines associated to a commit of a GitHub or GitLab repository
2019-12-22 18:39:34 <mps> Features
2019-12-22 19:24:07 <mps> nmeum: I built gdb-multiarch locally.
2019-12-22 19:29:01 <mps> looks fine
2019-12-22 19:29:13 <nmeum> great
2019-12-22 19:29:53 <nmeum> thanks for testing it. I guess I will just push it then or do you want to do any further tests?
2019-12-22 19:31:01 <mps> I don't have idea now for some complicated tests so just push it
2019-12-22 19:31:26 <mps> if issue appears we will fix them :) as usual
2019-12-22 19:31:39 <mps> issues*
2019-12-22 19:32:55 <mps> it works with few tests as 'normal' gdb, so good enough
2019-12-22 20:57:25 <nmeum> mps: I am always a bit more cautious with changes to "essential" / important packages, but pushed it now. thanks for testing
2019-12-22 20:58:17 <_ikke_> nmeum: not a bad attitude :)
2019-12-22 21:07:33 <mps> nmeum: during testing it helped me to spot bug in one of my simple program :)
2019-12-22 21:13:50 <nmeum> great :)
2019-12-22 21:15:04 <north1> back!
2019-12-22 21:16:56 <_ikke_> o/
2019-12-22 21:17:03 <_ikke_> enjoyed it?
2019-12-22 21:17:39 <north1> Yes, walked a bit too much for my current condition but it was a lot of fun
2019-12-22 21:18:40 <nmeum> I hope you didn't walk from stuttgart to berlin because that would take a while :)
2019-12-22 21:20:58 <north1> no, took FlixTrain
2019-12-22 22:15:40 <north1> oof
2019-12-22 22:16:00 <north1> @mps artifacts were removed 8 hours ago (2019-12-22T23:15:54+0100)
2019-12-22 22:16:41 <_ikke_> we lost the x86_64 ci builder, it's gone awol
2019-12-22 22:18:59 <mps> so, I can't even abuse CI buy force push to rebuild it?
2019-12-22 22:19:15 <_ikke_> mps: You don't even need to force push
2019-12-22 22:19:24 <_ikke_> There is an actual restart button :)
2019-12-22 22:19:38 <_ikke_> but the x86_64 builds are not running atm
2019-12-22 22:19:54 <mps> not builder, but CI
2019-12-22 22:19:59 <_ikke_> yes, that's what I meant
2019-12-22 22:20:05 <mps> ah, ok
2019-12-22 22:20:07 <_ikke_> the builder is working fine
2019-12-22 22:21:33 <mps> I have apk downloaded but don't know where can put it, my link to upload to internet is slow, 1Mb/s
2019-12-22 22:21:42 <north1> oof
2019-12-22 22:21:58 <_ikke_> mps: you should have an account on dev.a.o
2019-12-22 22:22:09 <mps> and apk is 61M
2019-12-22 22:22:31 <mps> afaik I don't have it
2019-12-22 22:22:41 <_ikke_> no, I don't see it, indeed
2019-12-22 22:25:04 <mps> _ikke_: I'm copying it to my lxc, mps-edge-aarch64 usa4
2019-12-22 22:25:27 <mps> maybe it finish in 10-15 minutes
2019-12-22 22:25:38 <_ikke_> ok
2019-12-22 22:25:39 <mps> so, you copy it for north1
2019-12-22 22:25:56 <mps> I'll inform you when it is done
2019-12-22 22:26:18 <north1> Where will it be?
2019-12-22 22:26:27 <_ikke_> I will put it on dev.a.o
2019-12-22 22:26:38 <north1> Ok
2019-12-22 22:35:52 <mps> _ikke_: usa4.a.o  mps-edge-aarch64 /home/mps/linux-lts-5.4.6-r0.apk
2019-12-22 22:36:02 <_ikke_> ok
2019-12-22 22:40:14 <_ikke_> north1: https://dev.alpinelinux.org/archive/linux-lts-5.4.6-r0.apk
2019-12-22 23:01:34 <Cogitri> ncopa: Is there a reason why you haven't upgraded Wireguard-tools?
2019-12-22 23:01:35 <Cogitri> !2273
2019-12-23 01:59:21 <ddevault> ncopa: can you bump python to 3.8.1 when you have the chance? bonus points if we can ship that to alpine 3.11
2019-12-23 08:34:48 <north1> @mps still happens, just happened just as i resumed from sleep
2019-12-23 08:35:35 <mps> ohm, bad news in the morning
2019-12-23 08:35:54 <north1> on the bright side it is just graphical
2019-12-23 08:36:02 <north1> when i pressed the power button it worked again
2019-12-23 08:36:19 <north1> but it worked just enough to show my notebook shutting down :D
2019-12-23 08:36:30 <mps> so, small step on right path
2019-12-23 08:38:15 <mps> I didn't had issue from saturday when i installed 5.4.6 (same apk posted to you)
2019-12-23 08:39:37 <north1> @PureTryOut !2186 is failing due to CI timeouts, can i yolomerge ?
2019-12-23 08:48:42 <Cogitri> (Or increase the CI timeout on your fork)
2019-12-23 08:49:16 <Cogitri> maxice8: fwiw that has always worked for me, when my laptop froze shutting it down by pressing the power button once did the trick
2019-12-23 08:49:48 <north1> yeah but i'd rather it not shut down and it just unhang itself
2019-12-23 08:51:00 <mps> oh, that is something I experience on aarch64 chromebook also
2019-12-23 08:52:15 <mps> when it froze I press power button which do 'suspend-to-ram' and pressing any key brings it from suspend and it works fine again
2019-12-23 08:53:39 <mps> that behavior started with 5.x kernels
2019-12-23 08:53:52 <mps> can't remember exact version
2019-12-23 09:00:34 <Cogitri> maxice8: Same here, just wanted to mention that that most likely isn't an "improvement" 5.4.6 brought along
2019-12-23 09:25:47 <Cogitri> ikke: Can you test !2310 ?
2019-12-23 09:26:13 <_ikke_> I can later today
2019-12-23 09:26:53 <Cogitri> Thanks :)
2019-12-23 09:43:58 <MY-R> maybe #11071 is related with commit 27b8dc5b but I have no idea how netboot files are generated
2019-12-23 09:44:24 <MY-R> https://gitlab.alpinelinux.org/alpine/aports/commit/27b8dc5bd034f91683012dcb5ad680e64c72c712
2019-12-23 09:52:21 <mps> MY-R: generic arm tarballs are correct, so I think something else is the problem
2019-12-23 10:00:24 <MY-R> mps, tarballs can be fine but those initramfs-* files got only read permission by root so maybe were copied with same permissions to web server
2019-12-23 10:06:15 <mps> aha, now understand what is the issue
2019-12-23 10:06:21 <MY-R> :)
2019-12-23 10:59:57 <Cogitri> _Ikke_: About the change to py3-pycryptodome: Does it install under the Cryptodome namespace without the `seperate namespaces` file too?
2019-12-23 11:00:11 <Cogitri> So can I upstream changes to import Cryptodome instead of Crypto?
2019-12-23 11:00:40 <_ikke_> Cogitri: No, without that file it would install it under the Crypto namespace
2019-12-23 11:03:37 <Cogitri> So we have to keep patches downstream?
2019-12-23 11:03:37 <Cogitri> That's unfortunate
2019-12-23 11:07:38 <nmeum> testing/tau currently fails to build an armhf with a segfault in rustc, wow
2019-12-23 11:09:03 <Cogitri> Yes
2019-12-23 11:09:10 <Cogitri> Rust on musl likes to SIGSEGV at random times
2019-12-23 11:09:21 <Cogitri> And Gtk-rs being a complex project is especially good at triggering it apparently
2019-12-23 11:26:15 <_ikke_> Cogitri: where patches mean creating a file?
2019-12-23 11:26:41 <_ikke_> cryptodome has 2 ways of use. 1 as replacement of crypto, and one as standalone
2019-12-23 11:31:18 <Cogitri> Patches mean change import Crypto to import Cryptodome
2019-12-23 11:31:32 <Cogitri> !2330
2019-12-23 11:32:00 <_ikke_> Cogitri: shouldn't it depend on crypto then instead of cryptodome?
2019-12-23 11:32:48 <_ikke_> crypto and cryptodome cannot coexist if they use the same namespace
2019-12-23 11:33:10 <_ikke_> so we either need to drop crypto and use pycryptodome, or packages should depend on crypto
2019-12-23 11:34:16 <Cogitri> Yes, they import Crypto but actually need Cryptodome (for ChaCha20)
2019-12-23 11:34:28 <Cogitri> They just assume that Crypto is Cryptodome under the hood
2019-12-23 11:34:31 <_ikke_> so upstream is broken then :)
2019-12-23 11:34:35 <_ikke_> yeah
2019-12-23 11:34:42 <Cogitri> Yes, so my question is how we can fix that upstream :)
2019-12-23 11:34:59 <Cogitri> Can we upstream changes like in the MR I did?
2019-12-23 11:35:03 <_ikke_> I guess what you said: s/import crypto/import cryptodome
2019-12-23 11:35:36 <Cogitri> Alrighty, good. Wasn't sure if it only installs to the Crypto namespace by default (so an import for Cryptodome would fail on systems that aren't Alpine)
2019-12-23 11:35:46 <_ikke_> hmm
2019-12-23 11:36:00 <_ikke_> I guess it's either / or
2019-12-23 11:36:07 <_ikke_> let me check
2019-12-23 11:37:45 <_ikke_> Cogitri: yeah, it's either only crypto or cryptodome
2019-12-23 11:37:47 <Cogitri> Thanks, my Python is pretty limited :)
2019-12-23 11:38:03 <Cogitri> So we can't really upstream these changes, can we?
2019-12-23 11:38:51 <_ikke_> I wonder in how far it's legitemate that pycryptodome assumes the crypto namespace
2019-12-23 11:39:02 <Cogitri> Seems odd to me too, yes
2019-12-23 11:39:23 <Cogitri> But I guess this is something Pycryptodome has to deal with then and not projects which depend on it
2019-12-23 11:40:18 <_ikke_> https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html
2019-12-23 11:41:47 <_ikke_> seems like pycrypto is unmaintained
2019-12-23 11:41:50 <_ikke_> https://pypi.org/project/pycrypto/
2019-12-23 11:41:53 <_ikke_> last released 2013
2019-12-23 11:42:15 <_ikke_> So we might consider replacing it with pycryptodome then
2019-12-23 11:43:27 <_ikke_> Cogitri: does that seem reasonable?
2019-12-23 11:44:37 <Cogitri> Sounds good, yes
2019-12-23 11:44:43 <_ikke_> https://github.com/dlitz/pycrypto/issues/292#issuecomment-548376073
2019-12-23 11:45:00 <Cogitri> And probably is what other distros did too
2019-12-23 11:45:16 <_ikke_> yup
2019-12-23 11:45:50 <_ikke_> ncopa: mind if we drop py3-crypto (dead / unmaintained) in favor of pycryptodome (mostly backwards compattible)?
2019-12-23 11:46:15 <_ikke_> py3-crypto is in main, so we might need to move py3-pycryptodome to main as well
2019-12-23 11:47:22 <_ikke_> ansible depends on it
2019-12-23 11:53:28 <ncopa> sounds good to me _ikke_
2019-12-23 11:53:48 <ncopa> we should also upgrade py3-django
2019-12-23 11:53:56 <_ikke_> ncopa: alright
2019-12-23 12:04:44 <ncopa> any idea how to deal with https://gitlab.alpinelinux.org/alpine/aports/issues/11076
2019-12-23 12:04:57 <ncopa> i guess its technically an #alpine-infra question
2019-12-23 12:05:48 <Cogitri> Would be nice if we could get more eyes on !2313
2019-12-23 12:05:48 <ncopa> the problem is that latest-stable is a symlink, it now points to v3.11 but old (v3.10) version is cached
2019-12-23 12:06:07 <Cogitri> And ncopa please take a look at !1139 :)
2019-12-23 12:06:36 <_ikke_> ncopa: a script that invalidates everything after release?
2019-12-23 12:06:53 <ncopa> Cogitri: if rust works, then i think we can push it to edge at least
2019-12-23 12:07:04 <mps> Cogitri: I would but I'm trying to understand why rpi tarballs missing dtbs in proper place
2019-12-23 12:07:26 <ncopa> _ikke_: i think i started a script last release, 3.10
2019-12-23 12:07:50 <ncopa> which would only invalidate the cache for the packages that existed in both v3.10 and v3.9
2019-12-23 12:07:54 <ncopa> that was the idea at least
2019-12-23 12:08:09 <ncopa> we technically dont need to invalidate everything
2019-12-23 12:08:48 <_ikke_> rit
2019-12-23 12:08:50 <_ikke_> right
2019-12-23 12:08:58 <ncopa> and we should do it for every arch...
2019-12-23 12:09:10 <Cogitri> Okie, gonna push it when CI goes green then
2019-12-23 12:38:50 <_ikke_> ncopa: do you still have that script somewhere?
2019-12-23 12:42:39 <clandmeter> i never understood latest stable. without using --available its kind of dangerous to use.
2019-12-23 12:44:13 <clandmeter> it would be nice if apk had some mechanism to detect branch update and notifies the user.
2019-12-23 12:51:00 <nmeum> does anybody except me use wireshark regulary? if so: any thoughts on !2248? currently, the package doesn't ship with any mechanism allowing unprivileged users to sniff packetes
2019-12-23 12:53:54 <nmeum> ncopa: would you be ok with making the private key size as generated by abuild-keygen configurable? currently, a key size of 2048 bits is hardcoded. I would also consider bumping the default to 4096 tbh
2019-12-23 12:56:32 <ncopa> nmeum: sounds good to me
2019-12-23 13:03:05 <ddevault> so I'm reading through the apk code with the intention of splitting the download step from the installation step
2019-12-23 13:03:23 <ddevault> I'm thinking that this would only be useful/desirable if the cache is enabled
2019-12-23 13:03:32 <ddevault> so that we have somewhere to stage the packages on the filesystem
2019-12-23 13:03:41 <ddevault> does anyone have some thoughts on this?
2019-12-23 13:04:31 <ncopa> talked with fabled about this last week
2019-12-23 13:05:36 <PureTryOut[m]> north1: yeah you can (regarding !2186), I compiled it all locally fine so hopefully it won't cause to much troubles
2019-12-23 13:05:40 <ncopa> i think it makes sense to do when cache is enabled yes
2019-12-23 13:06:11 <ddevault> for the approach I'm thinking about adding an operation bitmask, where op can be DOWNLOAD or EXTRACT, and passing it along to apk_db_unpack_pkg
2019-12-23 13:06:19 <ddevault> then running through everything twice from a higher level
2019-12-23 13:06:42 <ddevault> if cache isn't enabled the operation is 1|2
2019-12-23 13:07:25 <ncopa> what would be the purpose of fetching it first?
2019-12-23 13:07:34 <ddevault> I want to fetch everything, then install everything
2019-12-23 13:07:38 <z3ntu> <ddevault "so I'm reading through the apk c"> yes please!
2019-12-23 13:07:45 <ddevault> this reduces the risk of leaving the system in a half-installed state in case of network issues
2019-12-23 13:07:51 <ncopa> ok
2019-12-23 13:07:51 <z3ntu> <3
2019-12-23 13:07:52 <ddevault> and makes it safe to interrupt the installation during the download step
2019-12-23 13:08:05 <ncopa> makes sense
2019-12-23 13:09:12 <ncopa> i wonder if it possible to do it already with apk cache sync
2019-12-23 13:09:54 <ncopa> seems not
2019-12-23 13:10:17 <nmeum> ncopa: ok, I will merge https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/12 then
2019-12-23 13:49:33 <ddevault> nice https://paste.sr.ht/~sircmpwn/99128635103ca1c4e70a42e26c01b71e5e9a30f1
2019-12-23 13:55:09 <ddevault> do I send the patch to ~alpine/devel?
2019-12-23 14:01:42 <PureTryOut[m]> north1: might want to merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2341
2019-12-23 14:05:36 <Cogitri> ddevault: Nice :)
2019-12-23 14:06:45 <PureTryOut[m]> ddevault: hell yes to splitting up download and install phases
2019-12-23 14:08:22 <ddevault> here's the WIP patch https://paste.sr.ht/~sircmpwn/a00a872e951dd0028354f5ad1c800ae57294a764
2019-12-23 14:12:39 <ddevault> https://lists.alpinelinux.org/~alpine/devel/patches/3186
2019-12-23 14:12:59 <ncopa> ddevault: create MR here: https://gitlab.alpinelinux.org/alpine/apk-tools
2019-12-23 14:13:04 <ddevault> bleh
2019-12-23 14:13:49 <ddevault> bleh x2, forgot my gitlab password
2019-12-23 14:21:03 <PureTryOut[m]> Interesting how I managed to build stuff locally fine (in clean docker containers) and they still fail on the builders lol
2019-12-23 14:23:07 <PureTryOut[m]> north1: might want to merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2342
2019-12-23 14:23:26 <PureTryOut[m]> That was quick, nice
2019-12-23 14:23:32 <north1> yes, saw your message notification as i pressed enter on mgmr 2342
2019-12-23 14:23:57 <Cogitri> How come the dbus tests don't work? 🤔
2019-12-23 14:24:10 <Cogitri> Lots of GNOME stuff has tests that needs dbus
2019-12-23 14:24:44 <PureTryOut[m]> Lol nice
2019-12-23 14:24:45 <_ikke_> because the builders are not running the dbus service?
2019-12-23 14:24:50 <PureTryOut[m]> Idk, it happens for more packages
2019-12-23 14:28:50 <PureTryOut[m]> north1: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2343
2019-12-23 14:30:17 <Cogitri> I just need to add `dbus` to checkdepends and it works
2019-12-23 14:30:53 <kpcyrd> is the rust package broken on x86_64 in edge? https://paste.debian.net/plain/1122340
2019-12-23 14:30:57 <PureTryOut[m]> Oh it gets autorun?
2019-12-23 14:31:01 <Cogitri> I think so
2019-12-23 14:31:22 <Cogitri> kpcyrd: Please upgrade
2019-12-23 14:31:35 <PureTryOut[m]> Cogitri: ah nice, will re-enable those tests than when the builders are done
2019-12-23 14:32:36 <Cogitri> Dunno, either xvfb-run launches it or its autolaunched
2019-12-23 14:32:44 <Cogitri> But yes, it should work :)
2019-12-23 14:33:29 <Cogitri> kpcyrd: I broke it on the upgrade to 1.40.0-r0 but I pushed the fix yesterday with Rust 1.40.0-r1
2019-12-23 14:33:59 <kpcyrd> ah, my mirror was just stale
2019-12-23 14:34:22 <PureTryOut[m]> north1: I wonder what you do to the commit to make it appear with a different hash and not have Gitlab realize the MR has been merged?
2019-12-23 14:34:41 <north1> rebase against master
2019-12-23 14:35:16 <PureTryOut[m]> Ah. Too bad that gets rid of any signing of the commit as well
2019-12-23 14:35:28 <PureTryOut[m]> Could the script you use not check if rebasing is even necessary?
2019-12-23 14:35:52 <north1> it always rebases
2019-12-23 14:42:10 <PureTryOut[m]> I realize that but it's too bad it does that when it's not necessary as it gets rid of the signature on the commit
2019-12-23 14:43:18 <_ikke_> PureTryOut[m]: our workflow requires linear history, which means in almost any case that we need to rebase
2019-12-23 14:43:44 <_ikke_> PureTryOut[m]: commits are almost always applied as patches
2019-12-23 14:44:39 <_ikke_> (might change in the future, but right now this is the case)
2019-12-23 14:48:31 <PureTryOut[m]> Damn. Still would be nice to make Gitlab somehow realize itself the MR got merged. Now it still thinks every MR I make is my first contribution lol
2019-12-23 14:49:04 <_ikke_> yup
2019-12-23 14:52:54 <PureTryOut[m]> north1: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2344
2019-12-23 14:54:12 <Cogitri> Aren't we going to adapt Gitlab as main git repo soon so we can FF merge via the webUI?
2019-12-23 14:56:11 <_ikke_> Cogitri: that would still mean signatures are gone
2019-12-23 14:56:24 <_ikke_> the only way to keep signatures is by merging
2019-12-23 14:57:49 <Cogitri> Ah, but why's that necessary? I thought the point is that the MR is displayed as merged
2019-12-23 14:58:07 <_ikke_> Cogitri: that was the reason why PureTryOut[m] started about it
2019-12-23 15:09:47 <mps> ncopa: regarding b4fe4890e9141961590f3f4c05f872008a9ea999
2019-12-23 15:10:45 <mps> I looked at it over weekend and thought that could (one of considered) cause
2019-12-23 15:11:49 <MY-R> xorg is broken
2019-12-23 15:12:08 <MY-R> jesus, thanks for outdated mirrors so can still use my desktop...
2019-12-23 15:12:23 <mps> changed linux-rpi and build it locally to follow this change but couldn't manage to build 'release' tarball, no matter what tried mkimage.sh don't use local repo kernel apk
2019-12-23 15:15:55 <mps> clandmeter: !2254 security fix and you are maintainer, pass local build and CI. and sorry I know you are busy
2019-12-23 15:47:32 <PureTryOut[m]> north1: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2345
2019-12-23 15:58:20 <north1> Merged
2019-12-23 17:31:58 <andypost[m]> is it ok to use direct path in places like that https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2277/diffs#9cb10c78aec8242adc36ffcb93a06b985013f687_37_30
2019-12-23 18:10:39 <_ikke_> I think we lost all matrix users
2019-12-23 18:10:41 <_ikke_> RIP
2019-12-23 18:11:50 <MY-R> !2355
2019-12-23 18:12:05 <MY-R> north1, looks like it working fine with radeon :)
2019-12-23 18:12:19 <MY-R> above mesa MR
2019-12-23 18:15:24 <Cogitri> _ikke_: Maybe matrix.org's IRC bridge is broke once again
2019-12-23 18:15:57 <_ikke_> Cogitri: most likely
2019-12-23 18:16:55 <Cogitri> Yeah, it's really annoying how often its down
2019-12-23 18:17:29 <Cogitri> (Which is why I've hosted my own, it's just too annoying to use matrix.org's bridge and using plain IRC isn't that nice either)
2019-12-23 18:22:13 <_ikke_> Someone able to review https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2354?
2019-12-23 18:22:55 <_ikke_> Cogitri: ^ that's about pycryptodome
2019-12-23 18:40:21 <andypost[m]> I see discussions from matrix, it hangs sometimes but mostly works
2019-12-23 18:40:43 <_ikke_> andypost[m]: We just saw a mass exodus here :)
2019-12-23 18:41:06 <_ikke_> andypost[m]: were you referring to this? `-d extension=/usr/lib/php7/modules/session.so`
2019-12-23 18:41:45 <andypost> _ikke_, yes, exactly
2019-12-23 18:41:52 <_ikke_> What would be the alternative?
2019-12-23 18:42:36 <andypost> probably some local variable for example
2019-12-23 18:43:13 <_ikke_> So it's mostly about the 'repetition'
2019-12-23 18:44:02 <andypost> yes, cos it used in few aports and ncopa said that better to get rid of sed
2019-12-23 18:46:08 <_ikke_> to me that seems fine
2019-12-23 18:47:49 <andypost> _ikke_, thank you, I will keep it like fullpath now
2019-12-23 19:23:02 <andypost> is there a way to get details from builders about failed tests, I can't reproduce it locally in chroot
2019-12-23 19:26:43 <_ikke_> andypost: I can take a look
2019-12-23 19:27:35 <andypost> _ikke_, please, failed tests could be found in tests in source
2019-12-23 19:28:40 <_ikke_> lots of files
2019-12-23 19:28:52 <_ikke_> What do you need?
2019-12-23 19:29:01 <_ikke_> http://tpaste.us/jxOl
2019-12-23 19:32:14 <andypost> _ikke_, mostly diff files
2019-12-23 19:34:42 <_ikke_> https://dev.alpinelinux.org/archive/php7-pecl-zstd-tests.tar
2019-12-23 19:34:49 <_ikke_> entire tests dir
2019-12-23 19:35:17 <andypost> _ikke_, that you a lot
2019-12-23 20:18:03 <andypost> so the issue in zstd itself https://gitlab.alpinelinux.org/alpine/aports/blob/master/main%2Fzstd%2FAPKBUILD#L29
2019-12-23 20:18:43 <_ikke_> but isn't the package broken on armv7 then?
2019-12-23 20:19:11 <_ikke_> It would make more sense to disable the package than to disable tests
2019-12-23 20:28:31 <andypost> the problem is that I can't reproduce it locally(
2019-12-23 20:28:50 <andypost> and armv7 works fine
2019-12-23 21:32:48 <mps> hmm, mkimage.sh when building uboot profile on armv7 says: grub-mkimage: error: cannot open `/usr/lib/grub/arm-efi/moddep.lst': No such file or directory.
2019-12-23 21:33:21 <mps> why it tries grub when building u-boot tarball
2019-12-23 23:54:46 <PureTryOut[m]> Cogitri: I'm not sure how you make dbus stuff work. Just adding dbus to checkdepends worked for one package, but doesn't for another
2019-12-23 23:57:43 <Cogitri> Hm, odd. Does that other package happen to not use xvfb-run?
2019-12-23 23:57:56 <Cogitri> Because I think xvfb-run also starts a dbus instance if it's not available
2019-12-24 00:03:33 <PureTryOut[m]> It does use xvfb-run
2019-12-24 00:03:59 <PureTryOut[m]> (I'm testing with `community/kdelibs4support`)
2019-12-24 02:57:19 <wsinatra> Can anyone point me towards references on using mercurial inside of an apkbuild? An existing package that uses mercurial would work well if anyone knows one
2019-12-24 03:07:31 <ddevault> do you not have access to a tarball, wsinatra?
2019-12-24 03:07:40 <ddevault> many code hosting platforms can generate a tarball for an arbitrary commit
2019-12-24 03:08:20 <ddevault> if not, just use hg clone in the prepare()
2019-12-24 03:08:32 <ddevault> and file a complaint with upstream about the lack of tarballs
2019-12-24 03:09:21 <wsinatra> The project I was looking at provided tarballs with precompiled glibc binaries, so it wasn't very helpful
2019-12-24 03:09:30 <ddevault> source tarballs, rather
2019-12-24 03:09:34 <ddevault> what's the project?
2019-12-24 03:09:40 <wsinatra> But if it's as easy as calling hg clone in prepare then that's not too bad.
2019-12-24 03:10:21 <wsinatra> I was looking at love
2019-12-24 03:10:37 <ddevault> the game engine?
2019-12-24 03:10:49 <wsinatra> but I actually see a linux-src tarball in there that I over looked, so might be a none issue
2019-12-24 03:10:57 <wsinatra> Yeah the lua 2d engine
2019-12-24 03:12:17 <ddevault> https://bitbucket.org/rude/love/get/11.3.tar.gz
2019-12-24 03:12:24 <ddevault> swap 11.3 with $pkgver
2019-12-24 03:13:13 <wsinatra> thank you!
2019-12-24 03:13:18 <ddevault> np
2019-12-24 03:14:13 <wsinatra> One less thing to over thing while I figure out how many dependencies I need to port :)
2019-12-24 07:58:21 <_ikke_> mps: fyi: 0_git$rev is not going to work if $rev is refering to a git revision (hash)
2019-12-24 07:58:33 <_ikke_> if you have a hash which is considered older, it will never upgrade
2019-12-24 08:30:55 <mps> _ikke_: this is what I thought after i wrote message, i.e. hash is not safe and thought about something which can be safely incremented and to have meaning
2019-12-24 08:32:42 <mps> I thought about just increment pkgver but reading your response in aports ML to someone this morning I got nice solution. thanks :)
2019-12-24 09:10:03 <joneskoo> mps: git describe --tags style counts commits from last tags before hash and that would be safe for version if I'm not mistaken.. not sure if it's a format you prefer
2019-12-24 09:11:57 <mps> iiuc, this is ok if there are tags in git commits?
2019-12-24 09:30:43 <_ikke_> mps: common is to use the commit date or something like that
2019-12-24 09:38:42 <mps> _ikke_: yes, this make most sense to me
2019-12-24 09:40:02 <_ikke_> mps: I replied to the dino patch btw
2019-12-24 09:42:35 <mps> yes, I read your reply already, and your reply is just what I would say + about pkgver
2019-12-24 09:48:08 <mps> anyone would comment #11056 about my additions, and related !2378
2019-12-24 11:52:55 <ncopa> mps: i think i already pushed fix for it
2019-12-24 11:53:06 <ncopa> 83c48ef4787f5c5c61f561e3332195853dc7e30d
2019-12-24 12:08:55 <mps> ncopa: hm, can't see it
2019-12-24 12:09:20 <mps> ah
2019-12-24 12:09:50 <mps> I looked my name in commits :)
2019-12-24 12:10:04 <mps> but looks ok
2019-12-24 12:10:52 <mps> will wait for mirrors, and try to build tarball to see will it fix rpis issue
2019-12-24 12:37:19 <mps> now we have kernel 5.4 in edge, should we upgrade linux-headers also !1632
2019-12-24 12:44:29 <clandmeter> ncopa: will you create a new release?
2019-12-24 12:50:17 <wsinatra> would anyone mind checking !2291 it should be ready to push
2019-12-24 12:51:07 <wsinatra> once that's pushed I have a new aport for the lua love2d game engine to push. Fairly excited to get that in!
2019-12-24 12:55:55 <ncopa> clandmeter: yes thats the idea
2019-12-24 12:58:47 <ncopa> trying to fix as many of the bugs as possible
2019-12-24 13:01:13 <mps> if you speak about 3.10 then !2254 should be pushed, it is secfix
2019-12-24 13:03:12 <ncopa> im speaking about 3.11.1
2019-12-24 13:04:08 <mps> aha
2019-12-24 13:04:51 <mps> I'm testing rpi tarballs, first test (content of tar.gz) looks ok
2019-12-24 13:05:37 <ncopa> i can upload test releases
2019-12-24 13:05:40 <ncopa> if you are interested
2019-12-24 13:05:44 <ncopa> i tested armv7 already
2019-12-24 13:06:18 <mps> I have only rpi zero, so probably need armhf tarball
2019-12-24 13:06:38 <mps> and looks like I can't create it armv7
2019-12-24 13:08:24 <mps> so if you can put armhf tarball somewhere I will test it
2019-12-24 13:09:12 <mps> I destroyed my armhf development lxc about 20 days ago :(
2019-12-24 13:10:59 <ncopa> ok, im making an armhf release
2019-12-24 13:14:21 <ncopa> mps: try this: https://dev.alpinelinux.org/~ncopa/armhf/
2019-12-24 13:14:58 <mps> https://dev.alpinelinux.org/~ncopa/armhf/alpine-rpi-20191224-armhf.tar.gz
2019-12-24 13:15:03 <danieli> https://prnt.sc/qf6k6y damn it, still no booting
2019-12-24 13:15:11 <danieli> how would i go about debugging that?
2019-12-24 13:15:22 <mps> thanks
2019-12-24 13:16:45 <ncopa> vmware?
2019-12-24 13:16:49 <danieli> yes
2019-12-24 13:16:56 <ncopa> does the -lts kernel boot?
2019-12-24 13:17:11 <danieli> i just booted the -virt x86_64 3.11 ISO
2019-12-24 13:17:18 <danieli> do we have any ISOs with the LTS kernel in them?
2019-12-24 13:17:33 <_ikke_> 3.11 standard
2019-12-24 13:17:47 <danieli> i thought virt was pretty much just a stripped down standard
2019-12-24 13:17:47 <danieli> let's test
2019-12-24 13:18:20 <_ikke_> danieli: yes, that's my understanding as well
2019-12-24 13:19:10 <ncopa> danieli: virt is supposed to work in vmware
2019-12-24 13:19:33 <danieli> i'm pretty sure it has in the past
2019-12-24 13:19:53 <ncopa> me too
2019-12-24 13:20:12 <ncopa> i wonder if it is 5.4 kernel or our -virt kernel config
2019-12-24 13:20:30 <danieli> neither grub (efi) or syslinux (bios) is able to boot 3.11 standard x86_64
2019-12-24 13:20:45 <danieli> "Mounting boot media failed." and then initramfs emergency shell
2019-12-24 13:20:46 <ncopa> ok
2019-12-24 13:20:55 <ncopa> huh
2019-12-24 13:21:23 <ncopa> where is the cdrom connected? via virtio? scsi?
2019-12-24 13:21:30 <ncopa> try connect it via IDE
2019-12-24 13:21:35 <ncopa> or SATA
2019-12-24 13:22:21 <ncopa> looks like i have vmware fusion 8 on my macbook
2019-12-24 13:22:27 <ncopa> what version of vmware is it?
2019-12-24 13:22:41 <danieli> 15.5.1 build-15018445 on windows 10 pro
2019-12-24 13:22:48 <danieli> workstation pro
2019-12-24 13:23:02 <ncopa> smells like bug in 5.4 kernel
2019-12-24 13:23:10 <danieli> cool, 3.11 x86 standard booted
2019-12-24 13:23:46 <danieli> both bios and efi
2019-12-24 13:24:03 <_ikke_> is it running -lts or -vanilla?
2019-12-24 13:24:22 <danieli> probably vanilla, let me check
2019-12-24 13:24:40 <ncopa> there are no -vanilla for 3.11
2019-12-24 13:24:42 <ncopa> i removed it
2019-12-24 13:24:48 <mps> ncopa: OpenRC 0.42.1.034fce6328 is starting up Linux 5.4.6-0-rpi (armv6l)
2019-12-24 13:24:54 <_ikke_> right, so not a 5.4 issue then
2019-12-24 13:24:56 <danieli> -lts
2019-12-24 13:24:57 <mps> from your tarball
2019-12-24 13:25:02 <ncopa> mps: awesome
2019-12-24 13:25:05 <danieli> 5.4.5-0-lts
2019-12-24 13:25:15 <danieli> i have other 64 bit operating systems running in the same vmware workstation installation fwiw
2019-12-24 13:25:39 <ncopa> the "Mounting boot media failed." is because it fails to find the cdrom
2019-12-24 13:25:45 <ncopa> the driver for it is missing in initramfs
2019-12-24 13:25:56 <danieli> it boots the x86_64 iso in x86 config for the VM
2019-12-24 13:26:03 <danieli> i.e. not "64-bit" in the VM settings
2019-12-24 13:26:22 <ncopa> what does that 64-bit setting do?
2019-12-24 13:26:28 <mps> just untarr-ed it to partition, and changed boot parameters to use serial console, added usercfg.txt to enable uart, that's all
2019-12-24 13:26:30 <danieli> i don't remember
2019-12-24 13:28:12 <danieli> google doesn't seem to be able to tell me what it does
2019-12-24 13:29:25 <ncopa> ok my vmware fusion is defunct in macos catalina
2019-12-24 13:30:39 <danieli> fusion 11.5 pro is still a thing as far as i know
2019-12-24 13:30:54 <danieli> fusion 11.5 too
2019-12-24 13:31:56 <ncopa> 274 EUR for 15.5 Pro
2019-12-24 13:32:01 <danieli> ouch
2019-12-24 13:32:05 <danieli> i use volume license from my employer
2019-12-24 13:32:31 <ncopa> i got vmware fusion 8 from docker
2019-12-24 13:32:40 <danieli> that's quite old by now
2019-12-24 13:32:41 <ncopa> but i no longer work for docker so...
2019-12-24 13:32:43 <ncopa> yeah
2019-12-24 13:32:47 <ncopa> and it does not work
2019-12-24 13:32:54 <danieli> i'd ask what happened, but perhaps PM or -offtopic is better
2019-12-24 13:34:52 <mps> ncopa: sorry for breaking you two, but would you mind to scp two files to dev.a.o from my lxc on usa4
2019-12-24 13:35:06 <ncopa> sure, which files?
2019-12-24 13:35:20 <mps> crystal static tarballs for new crystal
2019-12-24 13:35:38 <mps> mps-edge-aarch64:~/crystal dir
2019-12-24 13:35:54 <ncopa> i guess that if vmware is interested in alpine working on their platform they could give me a free license
2019-12-24 13:36:00 <mps> crystal-0.31.1-aarch64-alpine-linux-musl.tar.gz and crystal-0.31.1-x86_64-alpine-linux-musl.tar.gz
2019-12-24 13:36:12 <ncopa> mps: great
2019-12-24 13:36:37 <mps> if someone wants to play with crystal upgrade to 0.32.1 :)
2019-12-24 13:36:55 <ncopa> i wonder if i should push this first though: http://tpaste.us/wng5
2019-12-24 13:37:33 <danieli> i'll poke vmware wherever i can and ask
2019-12-24 13:38:19 <ncopa> thanks!
2019-12-24 13:38:44 <mps> ncopa: if you are not sure about this fix, I can try later and see does it works
2019-12-24 13:39:46 <ncopa> i tested it
2019-12-24 13:39:53 <ncopa> but didnt solve crystal issue
2019-12-24 13:39:55 <ncopa> not sure why
2019-12-24 13:40:05 <mps> ah
2019-12-24 13:40:18 <ncopa> in any case, its an upstream bug so i think we can merge it
2019-12-24 13:40:48 <mps> true, bugs should be fixed
2019-12-24 13:41:43 <mps> again, what you think about linux-headers upgrade, simple yes/no is enough
2019-12-24 13:41:48 <ncopa> yes
2019-12-24 13:42:04 <ncopa> we should upgrade headers but only for edge
2019-12-24 13:42:13 <ncopa> actually
2019-12-24 13:42:19 <ncopa> it may make sense wait another week
2019-12-24 13:42:25 <mps> !1632
2019-12-24 13:42:35 <ncopa> its convenient that edge and 3.11 is similar right now
2019-12-24 13:42:36 <mps> yes, only for edge, I agree
2019-12-24 13:42:52 <ncopa> til we have flushed out the worst 3.11 bugs
2019-12-24 13:43:25 <mps> not sure if linux-headers need to be backported to 3.11
2019-12-24 13:43:36 <ncopa> no, i dont think it needs
2019-12-24 13:43:46 <mps> nice, we agree
2019-12-24 13:44:45 <mps> I'm waiting for linux-headers upgrade to clean iwd aports somewhat
2019-12-24 13:46:37 <wsinatra> ncopa: thanks for the commit!
2019-12-24 13:46:55 <ncopa> wsinatra: yw
2019-12-24 13:48:54 <ncopa> mps: crystal is updated
2019-12-24 13:49:01 <ncopa> i mean uploaded
2019-12-24 13:49:20 <mps> ok, thanks
2019-12-24 13:52:08 <ncopa> wsinatra: i cleaned up the commit message a bit though
2019-12-24 13:55:59 <wsinatra> yeah that might have been a bit messy.. sorry about that
2019-12-24 13:57:21 <MY-R> ncopa, thank you! python hexchat support working great again :) "community/hexchat: build with python3-embed"
2019-12-24 13:58:05 <ncopa> yw, thanks for a good bug report
2019-12-24 13:58:43 <MY-R> :)
2019-12-24 14:01:37 <MY-R> ps ncopa I'm kind of sure that #11071 is related with last changes to initramfs-* files permissions, for web server those files should have be readable for group and maybe others too (depends on web server configuration)
2019-12-24 14:02:54 <MY-R> I have got 403 Forbidden on dl-master.a.o too
2019-12-24 14:03:54 <_ikke_> seems to work here..
2019-12-24 14:05:19 <MY-R> _ikke_, can you download it? http://dl-master.alpinelinux.org/alpine/v3.11/releases/x86_64/netboot/initramfs-lts
2019-12-24 14:05:31 <ncopa> MY-R: makes sense
2019-12-24 14:05:32 <danieli> i get 403
2019-12-24 14:05:38 <_ikke_> ah, yes, that one returns a 403 indeed
2019-12-24 14:05:45 <MY-R> yeeep
2019-12-24 14:05:47 <danieli> it's not behind fastly so no cache
2019-12-24 14:09:36 <ncopa> MY-R: can you please comment to #11071?
2019-12-24 14:13:02 <MY-R> ncopa, comment about? :P
2019-12-24 14:13:29 <MY-R> it is probably easy to fix by script which generating those files for netboot?
2019-12-24 14:14:24 <ncopa> yeah
2019-12-24 14:14:27 <ncopa> im on it
2019-12-24 14:14:37 <ncopa> you dont need comment, i added a reference to the issue
2019-12-24 14:15:29 <MY-R> ye I was already checking which commit it was and then you done it :)
2019-12-24 14:29:45 <ncopa> hum. my workstation just hanged
2019-12-24 14:30:04 <ncopa> GPU hang
2019-12-24 14:30:13 <ncopa> i wonder if it is the i915 problem
2019-12-24 14:33:02 <mps> uname -a => 5.4.6-0-lts #1-Alpine SMP Sat, 21 Dec 2019 12:58:54 UTC x86_64 GNU/Linux
2019-12-24 14:33:32 <mps> uptime => 15:30:50 up 3 days, 24 min
2019-12-24 14:34:01 <MY-R> ye, that is the only hang type which I ever had but was long time ago with "radeon" stuff
2019-12-24 14:34:13 <mps> lspci => VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
2019-12-24 14:34:39 <ncopa> https://tpaste.us/8Xey
2019-12-24 14:35:15 <mps> aiee, I see
2019-12-24 14:35:59 <mps> read something about rcs0 in git log for 5.5-rc3 yesterday
2019-12-24 14:36:11 <ncopa> maybe its #11026
2019-12-24 14:36:37 <MY-R> for intel gpu's people recomend using modesetting xorg driver
2019-12-24 14:39:00 <ncopa> ok. im tagging 3.11.1 now
2019-12-24 14:39:15 <ncopa> or is there something else we need to include?
2019-12-24 14:39:22 <ncopa> i think we got the most critical stuff
2019-12-24 14:39:35 <ncopa> like netboot fix and rpi's dtbs
2019-12-24 14:40:17 <mps> I can't remember anything, but users will tell us what we forgetting now :)
2019-12-24 14:40:24 <ncopa> tagged
2019-12-24 14:40:30 <ncopa> 3.11.1 is in the oven
2019-12-24 14:47:08 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.1-released.html
2019-12-24 14:49:10 <mps> fine with me
2019-12-24 14:53:27 <ncopa> drats
2019-12-24 14:53:30 <ncopa> i messed up
2019-12-24 14:53:50 <_ikke_> with the tag?
2019-12-24 14:53:55 <ncopa> yeah
2019-12-24 14:54:06 <_ikke_> I was already looking for the tag commit
2019-12-24 14:54:16 <_ikke_> saw that you tagged the last commit on 3.11
2019-12-24 14:55:38 <ncopa> ok
2019-12-24 14:55:40 <ncopa> what do i do
2019-12-24 14:55:56 <ncopa> i guess i need to tag 3.11.2 instead
2019-12-24 14:55:57 <_ikke_> Changing tags is not feasible I guess?
2019-12-24 14:56:02 <_ikke_> ahuh
2019-12-24 14:56:07 <MY-R> or maybe 3.11.02 ? :D
2019-12-24 14:56:26 <ncopa> or i just ship it as is
2019-12-24 14:56:37 <_ikke_> ncopa: What difference does it make?
2019-12-24 14:56:39 <ncopa> the only thing is that /etc/alpine-release will report 3.11.0
2019-12-24 14:56:56 <_ikke_> right, because you did not bump alpine-base, right?
2019-12-24 14:57:11 <ncopa> yeah
2019-12-24 14:57:16 <ncopa> i forgot to commit it
2019-12-24 14:57:32 <ncopa> im stressing because i should not work anymore...
2019-12-24 14:57:56 <_ikke_> :( We don't want you to be stressed out
2019-12-24 14:58:00 <mps> uh, don't take it so
2019-12-24 14:58:51 <mps> by making mistakes we learn, it is hard school but best one
2019-12-24 14:59:30 <MY-R> ye ncopa calm down and chill or you will end up like few people around here... with heart problems visited today hospital :\
2019-12-24 15:00:11 <ncopa> yeah, you are right....
2019-12-24 15:00:38 <mps> alpine 3.11 is quite good and we have to be proud of that, especially you
2019-12-24 15:05:57 <ncopa> is this ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.2-released.html
2019-12-24 15:06:08 <ncopa> note that the milestone in gitlab is still 3.11.1
2019-12-24 15:07:17 <mps> yes, snow on Alps is really exciting :)
2019-12-24 15:07:49 <mps> sorry for kidding, looks fine
2019-12-24 15:09:01 <mps> only milestone need change, as I see
2019-12-24 15:09:04 <ncopa> ha! https://alpinelinux.org/downloads/ shows 3.11.1
2019-12-24 15:10:09 <mps> aren't this always changed after announce?
2019-12-24 15:11:01 <mps> but yes, could be changed now
2019-12-24 15:12:29 <ncopa> its updated
2019-12-24 15:12:32 <ncopa> to 3.11.2
2019-12-24 15:12:33 <ncopa> good
2019-12-24 15:12:52 <mps> I see
2019-12-24 15:13:21 <mps> only milestone is left 3.11.1
2019-12-24 15:13:42 <ncopa> i think i dont want change ~20 issues by hand
2019-12-24 15:13:47 <ncopa> i'll just leave it
2019-12-24 15:13:58 <_ikke_> You can do bulk update now
2019-12-24 15:14:08 <ncopa> or..
2019-12-24 15:14:11 <ncopa> i can rename it
2019-12-24 15:14:18 <_ikke_> yes
2019-12-24 15:26:46 <mps> even minor releases are good excuses for opening bottle of wine, today we have excuse to open two bottles :)
2019-12-24 15:28:50 <ncopa> ha!
2019-12-24 15:28:55 <ncopa> indeed
2019-12-24 15:29:27 <ncopa> i was supposed to cook here today
2019-12-24 15:30:00 <mps> :)
2019-12-24 15:31:00 <ncopa> and thanks for being supportive
2019-12-24 15:31:16 <ncopa> im tired and hungry now
2019-12-24 15:31:19 <danieli> i have some nice whiskey and cuban cigars around here somewhere
2019-12-24 15:31:49 <mps> also I'm going to lunch, cheers!
2019-12-24 15:33:12 <mps> cuban cigars, uhm. have to be content with good dutch tobacco
2019-12-24 15:33:33 <ncopa> im gonna pop a wine
2019-12-24 15:33:46 <ncopa> i think its gonna be a pinot noir
2019-12-24 15:37:40 <MY-R> let's get this party started! ;)
2019-12-24 18:08:51 <Mikey67> Hi guys, i am succesfully building images with the mkimage script with a custom profile. What is the best way to add a custom rc.local to the project ? I can make a apk for it, but like to have it without
2019-12-24 18:10:10 <dsmster> thanks for early christmas present in 3.11.2 :-)
2019-12-24 18:14:27 <_ikke_> PureTryOut[m]: your last change to elisa seems to have broken the build on s390x
2019-12-24 18:37:27 <Mikey67> think i found some in the scripts
2019-12-24 18:37:32 <Mikey67> apkovl=
2019-12-24 18:47:16 <mps> Mikey67: /etc/local.d/README
2019-12-24 18:54:27 <Mikey67> just read
2019-12-24 18:54:43 <Mikey67> no mention how to add it in the mkimage proces ;-)
2019-12-24 18:56:10 <mps> you need to have it one of runlevels, default probably
2019-12-24 18:56:43 <Mikey67> that part is absolute not the problem
2019-12-24 18:56:49 <Mikey67> its when buidling the iso / image
2019-12-24 18:57:00 <Mikey67> want some beefy stuff added at that point
2019-12-24 18:57:07 <Mikey67> so i can sysprep the whole thing
2019-12-24 18:57:49 <Mikey67> and dont want to clone just some storage
2019-12-24 18:58:02 <mps> probably add one funtion somewhere in script
2019-12-24 18:58:56 <mps> last night I hacked mkimage.sh with 'cp some file_file somewhere'
2019-12-24 18:59:16 <Mikey67> and they end up in rootfs ?
2019-12-24 18:59:32 <Mikey67> here the end up at the root of the sd card
2019-12-24 19:00:09 <mps> well, it was in workdir for some other script to extract it, but you have idea
2019-12-24 19:00:44 <Mikey67> what was the workdir ?
2019-12-24 19:00:50 <Mikey67> and can you share me your cp line ?
2019-12-24 19:01:12 <mps> parameter for --workdir for mkimage.sh
2019-12-24 19:02:01 <Mikey67> i see isee
2019-12-24 19:02:18 <mps> I deleted it, it was temporary hack to when working on fix for missing dtbs for RPIs
2019-12-24 19:03:57 <Mikey67> now trying with modified genapkovl-dhcp.sh
2019-12-24 19:04:03 <Mikey67> think that is what i am looking for
2019-12-24 20:13:06 <Mikey67> if i add extra package to the apks line like: apks="${apks} python3"
2019-12-24 20:13:35 <Mikey67> its added on the local storage, but not added after boot
2019-12-24 20:13:49 <Mikey67> simple trick to force that ?
2019-12-24 20:13:58 <Mikey67> i can apk add python3 and commit
2019-12-24 20:15:28 <Mikey67> ^mkimage script
2019-12-24 21:06:04 <PureTryOut[m]> _ikke_: yeah as vlc isn't on s390x, I saw it
2019-12-24 21:06:16 <PureTryOut[m]> it's a requirement for full program functionality though, otherwise you have on-screen buttons not working
2019-12-24 21:08:15 <_ikke_> And I don't think someone will be using that on an s390x, would they?
2019-12-24 22:01:57 <Cogitri> PureTryOut[m]: FYI I just disabled elisa on s390x due to missing vlc-dev
2019-12-24 22:02:16 <Cogitri> (Also, nitty but maybe add a linebreak to the makedepends :)
2019-12-24 22:20:21 <wsinatra> anyone mind checking !2406 to see if there's anything left, and if not push it?
2019-12-24 22:25:02 <Cogitri> wsinatra: I can give it another look, but especially on Christmas Eve reviews can be a bit sparse :P
2019-12-24 22:26:18 <wsinatra> fair point, hopefully I'm not asking too much! I'm stuck in the office for the remainder of the evening just trying to be a little productive :)
2019-12-24 22:26:48 <_ikke_> I can take a look
2019-12-24 22:27:50 <Cogitri> Took a look :)
2019-12-24 22:28:16 <wsinatra> thank you! I appreciate the suggestion too, I hadn't thought to link the depends
2019-12-24 22:28:18 <_ikke_> heh
2019-12-24 22:29:11 <_ikke_> Was that issue with lua not being provided for lua5.3 solved?
2019-12-24 22:29:59 <wsinatra> Yep that's the one. I didn't realize the lua5.2 apk provided it as lua5.3 and not just lua
2019-12-24 22:31:47 <wsinatra> in the end I changed the package for fennel so that it called lua5.3 instead of just looking for lua, since everything else seemed to function
2019-12-24 22:32:18 <wsinatra> purely semantic issues
2019-12-25 12:15:19 <AinNero> PureTryOut[m]: did you recognize me?
2019-12-25 12:16:44 <AinNero> FYI i bought Alpine Linux to top of r/unixporn
2019-12-25 12:17:45 <PureTryOut[m]> I did not
2019-12-25 12:19:31 <AinNero> the ncurses database shipped with alpine has a bug tho that makes the status bar on a VT520 unusable
2019-12-25 12:19:45 <AinNero> its also in upstream, but im not sure who even maintains the terminfo db
2019-12-25 14:47:08 <mps> AinNero: terminfo db are built from ncurses source with each upgrade
2019-12-25 14:47:41 <mps> if you found bug you can report it to ncurses ML
2019-12-25 18:29:38 <Cogitri> ncopa: ping
2019-12-25 21:12:12 <_ikke_> Someone knows why it gives this warning? "error: missing sentinel in function call" here "gtk_container_child_set(GTK_CONTAINER(notebook), gtk_notebook_get_nth_page(notebook, i), "tab-expand", TRUE, "tab-fill", TRUE, NULL);"
2019-12-25 21:14:20 <_ikke_> ok, apparently that NULL must be a char*
2019-12-26 07:02:21 <ncopa> Cogitri: pong
2019-12-26 08:45:46 <Danct12-IRC> knock knock
2019-12-26 09:04:09 <ncopa> who's there?
2019-12-26 09:04:53 <mps> come in :)
2019-12-26 09:06:44 <mps> ncopa: !1632
2019-12-26 09:13:30 <mps> thanks
2019-12-26 09:15:52 <mps> now I have to create iwd.post-install which rewrite /etc/iwd/main.conf, which is not easy for someone uneducated in shell scripting as I am
2019-12-26 09:21:44 <Cogitri> ncopa: Can you maybe take another look at !1139? :)
2019-12-26 09:36:00 <ncopa> Cogitri: ok, after I fix the chromium armv7 build and openjdk12
2019-12-26 09:41:23 <Cogitri> Alrighty, thank you :)
2019-12-26 10:40:38 <mps> do we have 3.11.x milestones on gitlab.a.o or I'm blind
2019-12-26 10:54:07 <Cogitri> Thanks for merging, ncopa :)
2019-12-26 10:56:12 <ncopa> mps: i created 3.11.3 milestone
2019-12-26 10:59:27 <mps> ncopa: I see, you added it to !2481
2019-12-26 11:00:07 <mps> thanks
2019-12-26 11:02:01 <mps> ncopa: this was for 3.10.4 f8c1d041503312cdf93078ee694087c0ea6d81e6
2019-12-26 11:02:45 <mps> did I made something wrong in MR
2019-12-26 11:04:03 <mps> !2483 is for edge
2019-12-26 11:04:45 <ncopa> the one for 3.11 worked on edge too so i added it there too while at it :)
2019-12-26 11:04:56 <ncopa> oh
2019-12-26 11:05:01 <ncopa> you wanted 2.1.2
2019-12-26 11:05:30 <mps> yes, I think we talked to upgrade after 3.11 release
2019-12-26 11:06:04 <mps> if you think to keep LTS for 3.12 than don't apply 2.1.2 upgrade
2019-12-26 11:07:25 <mps> to late, I see :)
2019-12-26 11:11:05 <north1> ncopa: got a MR for updating elfutils :D
2019-12-26 11:27:09 <_ikke_> Someone able to build https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2287? In my lxc container, I get errors during testing
2019-12-26 11:27:27 <_ikke_> but on gitlab CI it succeeds
2019-12-26 11:27:44 <mps> !2287
2019-12-26 11:28:44 <mps> _ikke_: what arch
2019-12-26 11:28:50 <_ikke_> x86_64
2019-12-26 11:29:43 <mps> does it make sense to test on aarch64, my x86_64 now is somewhat messed
2019-12-26 11:30:02 <_ikke_> just try
2019-12-26 11:30:08 <mps> ok
2019-12-26 11:42:42 <mps> _ikke_: ls -l (filtered): -rw-r--r--    1 mps      mps        1795981 Dec 26 11:39 netdata-1.19.0-r0.apk
2019-12-26 11:42:52 <mps> aarch64, lxc
2019-12-26 11:43:00 <_ikke_> ok, thanks
2019-12-26 11:43:13 <_ikke_> I'll just push it and see
2019-12-26 11:45:37 <_ikke_> ok, built just fine, strange
2019-12-26 12:41:58 <mps> hehe, ghosts are everywhere around us :)
2019-12-26 13:34:52 <north1> @ncopa am updating python3 to 3.8.1 (was 3.8.0), ok ?
2019-12-26 13:37:07 <ncopa> i think so
2019-12-26 13:37:16 <ncopa> are there any CVE?
2019-12-26 13:37:25 <ncopa> we may want upgrade it for 3.11 too
2019-12-26 13:37:38 <ncopa> lets upgrade edge only first and test it a few days there
2019-12-26 13:42:02 <north1> https://docs.python.org/3.8/whatsnew/changelog.html#security no CVEs but some  bpo
2019-12-26 13:43:21 <north1> Another thing to note is that 3.8.1 brings py3-typed-ast back into python3 so we might need to remove py3-typed-ast
2019-12-26 13:58:05 <ncopa> hum
2019-12-26 14:01:30 <north1> no changes to py3-typed-ast
2019-12-26 15:58:17 <north1> https://gitlab.alpinelinux.org/Leo/aports/-/jobs/27251 can someone help with this ? mariadb on x86 is failing
2019-12-26 18:33:31 <okeuday> When building an ISO image with the aports/scripts, is debug_init=yes suppose to be in kernel_cmdline or initfs_cmdline ?
2019-12-27 11:41:34 <mps> CI didn't tried to really build !2519  is that because pkgrel is not bumped or some other reason?
2019-12-27 11:42:58 <mps> hmm, forgot checksum
2019-12-27 13:28:42 <_ikke_> CI doesn't care about pkgrel, it only looks at changed APKBUILD files
2019-12-27 13:47:42 <mps> _ikke_: noticed that when I fixed checksums
2019-12-27 13:49:40 <mps> anyone would push !2519 it is simple change, just enabled one module in armv7, aarch64, x86 and x86_64
2019-12-27 13:51:23 <mps> it doesn't build new kernels (pkgrel is not bumped) just update aports
2019-12-27 13:51:36 <mps> I'm preparing fix for #11058 and need this first in aports
2019-12-27 14:07:43 <ncopa> mps: i was planning to do that together when 5.4.7 is out
2019-12-27 14:08:35 <ncopa> but I can push it today if its important for you
2019-12-27 14:12:37 <north1> @PureTryOut https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/27576 armv7 of your MR is failing
2019-12-27 14:12:54 <PureTryOut[m]>  Yeah I know, got the email
2019-12-27 14:13:00 <mps> I make mistake and sent this to gitlab, and now it is complicated to me to add patch for #11058
2019-12-27 14:13:14 <mps> s/make/made/
2019-12-27 14:13:14 <alpine-meetbot> mps meant to say: I made mistake and sent this to gitlab, and now it is complicated to me to add patch for #11058
2019-12-27 14:14:07 <mps> would be easiser for me if !2519 is in aports
2019-12-27 14:16:08 <mps> I want to enable AX.25 networking and some drivers in x86, x86_64, armv7 and aarch64
2019-12-27 14:16:23 <mps> any comment or objections
2019-12-27 14:32:29 <mps> 
ACTION wonder do we really still need -virt kernels

2019-12-27 14:35:35 <PureTryOut[m]> north1: it was some kind of race condition, it went through fine now
2019-12-27 14:35:54 <north1> i see
2019-12-27 16:13:34 <ddevault> ncopa: this keyutils package looks pretty messed up
2019-12-27 16:13:42 <ddevault> ncopa: is some of this deliberate? it's installed to / instead of /usr
2019-12-27 17:07:49 <ddevault> ncopa: sent patch
2019-12-27 17:31:43 <mjohn> Is it possible to have an APKBUILD file to use 'git clone' to fetch a release rather than download a tarball?
2019-12-27 17:31:58 <north1> Yes but not officially
2019-12-27 17:32:27 <mjohn> okay, thanks
2019-12-27 17:33:50 <ddevault> mjohn: for what package is this desirable to you?
2019-12-27 17:35:18 <mjohn> I've written an APKBUILD for azure-iot-sdk-c, and their github release do not include the submodule dependencies
2019-12-27 17:35:32 <north1> mjohn (IRC): oof
2019-12-27 17:35:42 <north1> that is a constant pain, see telegram-desktop APKBUILD and ppsspp
2019-12-27 17:35:50 <north1> :D lots of git submodules being fetched separately
2019-12-27 17:36:11 <mjohn> I'll give those a look, thanks
2019-12-27 17:36:18 <ddevault> how many submodules?
2019-12-27 17:36:23 <ddevault> you can have multiple source tarballs in the APKBUILD
2019-12-27 17:36:28 <north1> the best case is upstream actually doing packaging right  and including a tarball with the submodules, just like Rust package should include tarballs with the fetched dependencies
2019-12-27 17:36:30 <ddevault> one for each submodule, if appropriate
2019-12-27 17:36:44 <ddevault> and yeah, you should file a bug with upstream asking for a better release process
2019-12-27 17:36:49 <mjohn> 11 submodules
2019-12-27 17:37:03 <ddevault> that seems like a managable number
2019-12-27 17:39:12 <mjohn> yeah, I've reached out to them seeing if they could include the submodules in their release, the reply was a no.
2019-12-27 19:54:43 <PureTryOut[m]> Cogitri: I've been packaging some games and I found GNOME 2048. Would you be fine with me packaging it but setting you as the maintainer?
2019-12-27 20:00:11 <Cogitri> Oh sure, that'd be fine by me :)
2019-12-27 20:00:16 <Cogitri> I wanted to package those for some time but somehow didn't get around to it
2019-12-27 20:01:33 <PureTryOut[m]> Awesome, I'll tag you in the MR's
2019-12-27 20:05:33 <PureTryOut[m]> Can a package depend on it's subpackage?
2019-12-27 20:06:03 <PureTryOut[m]> I'm trying to split out data files to a noarch subpackage to save space as the CI complains about it for a package, but the application won't run without those files
2019-12-27 20:09:11 <mps> I think it can, vim depends on xxd
2019-12-27 20:10:39 <mps> but be careful about circular deps
2019-12-27 22:03:15 <PureTryOut[m]> Well that data subpackage doesn't have deps so should be fine
2019-12-27 22:03:28 <PureTryOut[m]> Still complains about being too large though, not sure what to do
2019-12-27 22:55:39 <_ikke_> What being too large?
2019-12-27 22:55:57 <north1> The created package to update as artifact on the MR I assume
2019-12-27 22:57:55 <_ikke_> Right, but splitting into subpackages doesn't fix that. And if that's the only issue, we can just ignore it, or increase the max size of uploads in Gitlab
2019-12-27 23:30:55 <kpcyrd> are there any docs on how to build a custom alpine iso that automatically executes `setup-alpine -f answerfile` with a file I provide?
2019-12-27 23:32:15 <kpcyrd> my usecase is having an iso I can drop into a VM, boot it, wait until it's done and then have a very basic server I can ssh into
2019-12-28 08:52:47 <clandmeter> kpcyrd: you can start the iso with ssh with firstboot
2019-12-28 10:50:28 <clandmeter> mort___: ping
2019-12-28 11:16:29 <PureTryOut[m]> Huh, not sure why the builders fail over the checksum now but it went through CI fine there
2019-12-28 11:19:39 <minecrell> PureTryOut[m]: I think the line endings changed in no-sysctl.patch, now it has a different sha512sum
2019-12-28 11:20:02 <PureTryOut[m]> But CI should've picked that up no?
2019-12-28 11:20:16 <minecrell> I guess it changed when it was merged
2019-12-28 11:20:25 <PureTryOut[m]> How strange...
2019-12-28 11:20:26 <minecrell> your MR is fine, it's different in master only
2019-12-28 11:22:29 <minecrell> PureTryOut[m]: Your patch has CRLF line endings (possibly because the source file had them?), and it was changed to LF when it was applied
2019-12-28 11:22:58 <PureTryOut[m]> How strange...
2019-12-28 11:40:29 <Cogitri> Oh, I suppose my `git am` automatically changed that
2019-12-28 11:40:33 <Cogitri> Sorry about that
2019-12-28 11:40:47 <Cogitri> Was wondering how the builders fail if CI didn't too
2019-12-28 11:52:51 <Cogitri> Should be fixed now.
2019-12-28 17:11:37 <clandmeter> _ikke_: ping
2019-12-28 17:36:59 <_ikke_> clandmeter: pong
2019-12-28 18:00:49 <clandmeter> _ikke_: do you know if there are differences in docker install types?
2019-12-28 18:09:15 <_ikke_> Hmm, no I'm not really aware of any difference except perhaps storage deivers
2019-12-28 18:18:01 <dsmster> is there an official go-lang pkg for rpi / aarch64 ?  I see that the official go-lang binaries for arm8 expect glibc and not musl
2019-12-28 18:18:31 <Cogitri> We offer a package for it
2019-12-28 18:18:46 <Cogitri> If you want a tarball from Go upstream you'll have to ask them I suppose
2019-12-28 18:19:08 <dsmster> ahh okay, i didn't try very hard, just tried apk add go and go-lang - thanks
2019-12-28 18:20:16 <Cogitri> https://pkgs.alpinelinux.org/packages?name=go&branch=v3.11&repo=community&arch=aarch64
2019-12-28 18:20:33 <Cogitri> There you go :)
2019-12-28 18:20:38 <dsmster> Cogitri : thank you
2019-12-28 18:25:36 <clandmeter> _ikke_: i think im not very clear
2019-12-28 18:25:44 <clandmeter> im looking at https://docs.docker.com/docker-for-mac/multi-arch/
2019-12-28 18:25:59 <clandmeter> it looks like only docker for mac supports this out of the box
2019-12-28 18:26:00 <_ikke_> clandmeter: obviously :-P
2019-12-28 18:26:30 <clandmeter> it has qemu bundelled
2019-12-28 18:26:52 <clandmeter> so it will use binfmt_misc
2019-12-28 18:27:49 <clandmeter> this allows me to run arm code on my mac x86 directly via docker
2019-12-28 18:28:12 <clandmeter> but it wont work on linux in the same way
2019-12-28 18:29:09 <clandmeter> maybe im missing something on linux to make this work or its  just not supported
2019-12-28 18:29:36 <clandmeter> i remember we had somebody here with some docker internal knowledge, dont remember who it was.
2019-12-28 18:50:29 <kaniini> some thoughts on the samurai thing
2019-12-28 18:50:45 <kaniini> actually, i will write to devel about it.
2019-12-29 14:07:52 <mort___> clandmeter: sorry was afk (at 36c3)
2019-12-29 14:08:05 <_ikke_> mort___: o/
2019-12-29 14:09:39 <mort___> 
ACTION back to read through for presentation

2019-12-29 15:55:38 <mort___> clandmeter: with the multi-arch image stuff -- I'll add a note to the README. does it require any packages installed on the host first, or is it enough just to run that privileged container?
2019-12-29 15:56:06 <clandmeter> olla
2019-12-29 15:56:14 <clandmeter> the container is all you need
2019-12-29 15:56:35 <clandmeter> atleast it works on my workstation
2019-12-29 15:56:44 <mort___> great
2019-12-29 15:56:53 <mort___> (wasn't sure if qemu had to be installed already)
2019-12-29 15:56:54 <clandmeter> i wasnt even aware this was possible
2019-12-29 15:57:15 <clandmeter> my multi arch support was for other purpouses
2019-12-29 15:57:28 <clandmeter> but this is an interesting addition
2019-12-29 15:57:40 <clandmeter> we get many requests for ppl who want to build arm on x86
2019-12-29 15:58:57 <clandmeter> mort___: i pushed some changes to the repo on github but they got overwritten :|
2019-12-29 15:59:08 <clandmeter> i need to push to git.a.o :)
2019-12-29 15:59:29 <clandmeter> there is also an PR open (now closed) with some fixes
2019-12-29 15:59:50 <clandmeter> i have some ideas on how to further improve it.
2019-12-29 16:00:08 <clandmeter> i dont think we currently support a config file right?
2019-12-29 16:00:37 <mort___> correct, there's no config file for dabuild -- all done via environment variables
2019-12-29 16:00:49 <mort___> happy to see PRs though :) (or MRs if we move it to gitlab.a.o :)
2019-12-29 16:01:57 <clandmeter> it would also be nice to follow alpine style guidelines if thats ok with you.
2019-12-29 16:02:22 <mort___> sure -- is there an easy way to set them up for the repo in emacs?
2019-12-29 16:02:49 <mort___> (my default config hates actual tab characters after too long working with python and collaborators with inconsistent treatment of tabs... :)
2019-12-29 16:03:13 <clandmeter> i think its a mix of tabs and spaces which was kind of confusing
2019-12-29 16:03:29 <mort___> dabuild.in is spaces only
2019-12-29 16:03:48 <clandmeter> are you sure? i think i found some lines which had taba and spaces.
2019-12-29 16:04:14 <clandmeter> we use tabs in aports
2019-12-29 16:04:31 <mort___> pretty sure; i untabify and also have whitespace mode setup to highlight them
2019-12-29 16:04:50 <mort___> yes, noticed that in alpine style guides - if there's some way i can auotmatically apply styling like that in a post-commit hook, happy to do so
2019-12-29 16:06:12 <clandmeter> maybe my vim acted weird (or i did myself)
2019-12-29 16:06:43 <mort___> (if there's a standard emacs config for working on alpine formatted shell scripts, happy to set it up so i get it right in future too...?)
2019-12-29 16:06:47 <mort___> anyway, gtg give my talk now
2019-12-29 16:06:54 <mort___> probably back online later
2019-12-29 16:07:03 <clandmeter> good luck
2019-12-29 16:07:06 <mort___> ta!
2019-12-29 18:03:39 <Cogitri> Ugh, `LLVM ERROR: out of memory` while compiling FF on x86, 4GB of RAM per process starts to become limiting...
2019-12-29 18:32:28 <mort___> clandmeter: applied your fixes to README, pushed and closed #51 again
2019-12-29 18:32:48 <clandmeter> thx
2019-12-29 18:33:12 <clandmeter> I added a pr, ill add more stuff later.
2019-12-29 18:46:16 <mort___> clandmeter: cool, you want me to review them now or wait for more stuff?
2019-12-29 18:47:02 <clandmeter> Go ahead
2019-12-29 18:47:09 <clandmeter> It's minor
2019-12-29 18:56:21 <mort___> cool, reviewed
2019-12-29 19:36:05 <manj-gnome> hey guys
2019-12-29 19:36:57 <manj-gnome> I am pretty desperate, I am trying to setup Pyarrow on an Alpine image and I am petty stuck, anybody feels like giving advice?
2019-12-29 19:37:51 <_ikke_> manj-gnome: Can you give a bit more context?
2019-12-29 19:38:08 <_ikke_> talking about images, I assume you use docker
2019-12-29 20:11:45 <clandmeter> and this is probably not the correct channel for those type of questions.
2019-12-29 20:18:31 <mps> Cogitri: 4GB RAM limit on 32bit is not enough to build firefox, even when disabling LTO (which shouldn't be done)
2019-12-29 20:19:46 <mps> maybe to try with adelie rust, (don't know though is it worth but I plan to do that after 2019 :) )
2019-12-29 20:25:01 <Cogitri> I very much doubt their rustc magically consumes less RAM
2019-12-29 20:25:15 <Cogitri> I'm currently testing it without debug info on CI, hopefully that'll do
2019-12-29 20:25:55 <mps> iirc I tried without debug about month ago
2019-12-29 20:28:26 <Cogitri> If that doesn't work I'll try decreasing the optlevel
2019-12-29 20:31:01 <mps> I forgot all options I tried, but didn't had success whatever I tried. I hope you will find solution
2019-12-29 20:33:12 <PureTryOut[m]> Guess Firefox on 32-bit needs to be cross compiled
2019-12-29 20:34:15 <Cogitri> Well, let's see how the native build goes
2019-12-29 20:34:40 <Cogitri> If we can't compile it natively we'll have to keep it disabled I suppose, not feeling like messing with crosscompiling to be honest
2019-12-29 20:34:44 <mps> or build in armv7/x86 container with 64bit (aarch64/x86_64) personality
2019-12-29 20:35:17 <mps> if that is possible, ofc
2019-12-29 20:39:25 <Cogitri> Well, it's currently compiling the rust parts which failed previously so we should know if it works soon :)
2019-12-29 20:40:09 <mps> fingers crossed :)
2019-12-29 20:42:03 <mps> (if it succeed beware of memory manufacturers)
2019-12-29 20:43:13 <Cogitri> This sure takes long :P
2019-12-29 20:43:19 <Cogitri> I thought my FF froze for a second
2019-12-29 20:47:35 <Cogitri> Hooray, seems to work
2019-12-29 20:48:49 <mps> :)
2019-12-29 20:49:15 <mps> armv7 or x86 ?
2019-12-29 20:51:25 <Cogitri> x86 worked so I'd suprise me if armv7 didn't
2019-12-29 20:51:44 <Cogitri> The armv7 CI runner is currently busy so I decided to just give it a go
2019-12-29 20:52:04 <mps> yes, i think so, and hope I'm not wrong
2019-12-29 20:52:10 <Cogitri> Err...I mean we don't have an armhf runner, armv7 is disabled anyway
2019-12-29 20:52:15 <mps> hat off :)
2019-12-29 20:52:27 <Cogitri> Although that might work now, can you maybe test that on your lxc? :)
2019-12-29 20:52:42 <mps> ofc, and with pleasure
2019-12-29 20:53:22 <mps> give me few minutes to clean and archive it somewhat
2019-12-29 20:54:10 <mps> last FF commit?
2019-12-29 20:56:36 <Cogitri> Yup, with the latest commit, just enable armv7 in arch and it might work already
2019-12-29 20:58:35 <mps> ok
2019-12-29 20:59:12 <mps> it's a pity my lxc is now shared with builders so I limit JOBS to 8
2019-12-29 21:12:33 <Cogitri> Not that Rust would use much more than that :^)
2019-12-29 21:14:35 <mps> it's working, now have to wait
2019-12-29 21:37:31 <Cogitri> I think you can cancel that build
2019-12-29 21:37:39 <Cogitri> Can you try again with !2606 ?
2019-12-29 22:13:07 <mps> Cogitri: this from aports failed
2019-12-29 22:13:59 <Cogitri> Yes, I suppose something about `user_vfp` not being defined?
2019-12-29 22:14:03 <mps> do you mean to apply !2606 to aports and try to build
2019-12-29 22:14:14 <Cogitri> Yup, please try that again :)
2019-12-29 22:15:30 <mps> somewhere after 'Compiling gkrust v0.1.0 (/home/mps/aports/testing/firefox/src/firefox-71.0/toolkit/library/rust'
2019-12-29 22:18:55 <mps> ok, waiting to finish ......
2019-12-29 22:24:38 <Cogitri> Thanks
2019-12-29 22:45:45 <mps> thank you for hard part of work! my part is easy, git am and abuild -r
2019-12-29 23:28:54 <mps> Cogitri: ls -l => -rw-r--r--    1 mps      mps       57760620 Dec 29 23:20 firefox-71.0-r1.apk
2019-12-29 23:29:00 <mps> armv7 lxc
2019-12-29 23:29:07 <mps> aieee :)
2019-12-29 23:29:38 <mps> congratulations :)
2019-12-29 23:29:38 <Cogitri> Nice :)
2019-12-29 23:30:45 <Cogitri> Thanks for testing :)
2019-12-29 23:30:50 <mps> all credits are yours
2019-12-30 09:21:20 <Cogitri> Hm, sadly it appears that it only works on armv7 and not armhf, but oh well, I guess running FF on armhf isn't fun anyway :)
2019-12-30 09:25:43 <mps> agree
2019-12-30 09:26:12 <_ikke_> ARMv7 and x86 CI should now work properly with the correct arch/images
2019-12-30 09:26:14 <mps> later today I will test how good it is on armv7
2019-12-30 09:26:50 <mps> FF on armv7, I mean
2019-12-30 09:41:56 <ncopa> morning
2019-12-30 09:42:04 <ncopa> i'm working on !2077
2019-12-30 09:42:08 <Cogitri> Morning
2019-12-30 10:35:03 <ncopa> clandmeter: ae1f4c098467a4071d568bb0268eef3b4a617f88
2019-12-30 10:35:50 <clandmeter> ah so it was me :)
2019-12-30 10:36:12 <clandmeter> i guess we need abuild to check for correct arch.
2019-12-30 10:36:21 <clandmeter> or atleast CI
2019-12-30 10:36:34 <ncopa> yeah
2019-12-30 10:36:34 <clandmeter> but then we need to pass everything via CI first.
2019-12-30 10:36:49 <clandmeter> which not all of us does
2019-12-30 10:37:30 <clandmeter> oh its not me
2019-12-30 10:37:35 <clandmeter> this commit is confusing
2019-12-30 10:37:49 <clandmeter> ah no its not confusing
2019-12-30 10:38:00 <Cogitri> heh
2019-12-30 10:38:50 <ncopa> should be removed from all builders now
2019-12-30 10:39:03 <Cogitri> Well, if we could merge via the Gitlab WebUI/API  using Gitlab CI would certainly be a tag nicer
2019-12-30 10:39:33 <Cogitri> Right now it can be a bit annoying when we need to checkout the mr/pull/push and then manually close the MR
2019-12-30 10:59:47 <Danct12-IRC> HEEEEEEEEEEEY
2019-12-30 10:59:50 <Danct12-IRC> whats up
2019-12-30 11:04:47 <ncopa> hi
2019-12-30 11:04:57 <Danct12-IRC> whats up ncopa?
2019-12-30 11:05:34 <ncopa> im working on !2077
2019-12-30 11:06:05 <Danct12-IRC> iirc i was the one who pushed that to alpine
2019-12-30 11:06:13 <Danct12-IRC> initial** or so
2019-12-30 11:06:15 <Danct12-IRC> not remember
2019-12-30 11:06:52 <Danct12-IRC> i think false memory haha
2019-12-30 11:07:56 <Danct12-IRC> oh it was called bullet
2019-12-30 12:08:17 <mps> ncopa: if you have time !2519
2019-12-30 12:08:59 <mps> there are two commits, one is to fix #11058
2019-12-30 12:09:41 <mps> but you can see in commit msg that I 'skipped' s390x and ppc64le
2019-12-30 13:57:53 <mps> Cogitri: with firefox 71 my old arm32 (exynos) chromebook is again fully usable as lightweight box
2019-12-30 13:58:19 <Cogitri> Nice :)
2019-12-30 13:58:54 <mps> FF is really responsive
2019-12-30 13:59:05 <mps> thank you for fixing it
2019-12-30 14:02:04 <ddevault> ncopa: bumping python upgrade request
2019-12-30 14:02:33 <ddevault> ncopa: and bumping request for it to make it to the stable branch
2019-12-30 14:12:26 <ncopa> ddevault: i think puython 3.8.1 was pushed to edge
2019-12-30 14:12:41 <ddevault> ncopa: can you push it to 3.11?
2019-12-30 14:13:14 <ncopa> yes
2019-12-30 14:13:18 <ddevault> thanks
2019-12-30 14:13:25 <ncopa> after lunch
2019-12-30 14:14:09 <mort___> clandmeter: there?
2019-12-30 14:15:00 <mort___> I'm afraid I can't follow what you're saying on your last comment to docker-abuild#52 (I am currently coffee-deprived though so it may just be that!)
2019-12-30 14:16:11 <mort___> (am also on fairly flaky deutschebahn wifi currently so apologies if I drop out)
2019-12-30 15:35:50 <clandmeter> mort___: which part is unclear?
2019-12-30 15:42:49 <mps> looking through kernel 5.5-rc4 log, there could be fix for i915 issue some have: drm/i915/pmu: Ensure monotonic rc6
2019-12-30 15:44:28 <mps> not sure if this need to be backported
2019-12-30 15:53:02 <mps> 5.4.7 is preparing, probably will be soon released
2019-12-30 15:54:08 <Cogitri> Well, hopefully the linux upstream backported it if it indeed is the fix for those problems
2019-12-30 15:56:22 <mps> not sure, patch looks complicated to me, it 'plays' with some registers I don't know about their usage
2019-12-30 15:57:26 <mps> but this new Threadripper CPUs will have fixed
2019-12-30 16:08:54 <Cogitri> Neat, the mce stuff being fixed is kind of important
2019-12-30 16:09:13 <Cogitri> (Too bad there are not MiniITX boards for TRX40, otherwise I'd have gone with that)
2019-12-30 16:11:02 <mps> looks like mce is not fixed but something else done till the mce fixed
2019-12-30 16:11:35 <ddevault> jirutka: would you consider moving py3-pygithub into community?
2019-12-30 16:12:43 <mps> ah, yes mce fix
2019-12-30 16:13:06 <Cogitri> Ah
2019-12-30 16:13:47 <mps> https://www.phoronix.com/scan.php?page=news_item&px=Threadripper-3000-MCE-5.5-Fix
2019-12-30 16:20:31 <mort___> clandmeter: there? (was changing trains...)
2019-12-30 16:21:51 <mort___> first two sentences I don't get: you say for packages bind mounts make sense as want to access built pacakges easily (i think I agree with this); but you then say something about fewer security concerns than with abuild keys so volumes would make sense
2019-12-30 16:22:32 <mort___> not sure i understand either the security concerns (all the containers are local to developer machine aren't they?) or why/when volumes woudl make sense...
2019-12-30 16:24:19 <clandmeter> mort___: i mean .abuild can be a volume instead of a bind
2019-12-30 16:24:53 <clandmeter> using incorrect permissions on .abuild would be a security issue.
2019-12-30 16:25:02 <mort___> ah, ok, i see
2019-12-30 16:25:12 <clandmeter> it houses your abuild keys
2019-12-30 16:25:20 <clandmeter> but it also houses your abuild.conf
2019-12-30 16:25:26 <mort___> so perms on ~/.abuild should usually by 700 then?
2019-12-30 16:25:46 <mort___> *be
2019-12-30 16:25:48 <clandmeter> so you would need to enter the container to access it.
2019-12-30 16:26:16 <clandmeter> yes 700 should be ok
2019-12-30 16:27:22 <clandmeter> its more the concern for user/group whcih we need to share between host and container.
2019-12-30 16:27:27 <mort___> ok - reason to bind mount ~/.abuild was to share abuild.conf and keys between native host and docker container build environments, so as to produce packages for different archs (i think)
2019-12-30 16:27:33 <clandmeter> which would not be needed on a volume
2019-12-30 16:28:09 <mort___> i guess if the script can setup to copy current ~/.abuild contents into the volume every time, then that would work just as well
2019-12-30 16:28:19 <clandmeter> right, so to fix that we could add a applet
2019-12-30 16:29:14 <mort___> the (well, a) particular case where teh bind mount is needed is where the user doens't have ~/.abuild to start with (eg me, when ttrying to build packages on a mac)
2019-12-30 16:29:33 <mort___> so there's no "master" to copy from into the arch-specific volumes
2019-12-30 16:30:13 <mort___> D4M handles the file ownership correclty though, so it doesn't matter so much on mac i think
2019-12-30 16:30:15 <clandmeter> alternative you could do bind mounts in /srv/...
2019-12-30 16:30:18 <clandmeter> this how we do infra
2019-12-30 16:30:28 <mort___> ?
2019-12-30 16:31:15 <clandmeter> to work around the permissions issue
2019-12-30 16:31:29 <clandmeter> to not have a .abuild in $HOME owned by a different user.
2019-12-30 16:32:18 <clandmeter> not sure we talk about similar issues here :)
2019-12-30 16:32:25 <mort___> agree :)
2019-12-30 16:33:16 <mort___> My understanding:
2019-12-30 16:33:17 <clandmeter> how do you want to fix user/group differences?
2019-12-30 16:34:57 <mort___> dabuild is intended to solve two problems: make it easy to build packages for non-native architectures; and make it possible to build packages when not on an alpine host (whether non-alpine linux, or OSX/Windows)
2019-12-30 16:35:12 <clandmeter> nod
2019-12-30 16:35:27 <mort___> i think the challenge we have is the latter case
2019-12-30 16:36:04 <clandmeter> i didnt check on windows
2019-12-30 16:36:08 <mort___> once a valid ~/.abuild exists, containing abuild.conf and signing keys then the former case is easy: create a named volume and copy ~/.abuild in on invocation
2019-12-30 16:36:10 <clandmeter> i do have a mac
2019-12-30 16:36:46 <mort___> (...unless we would need to have differences per-architecture between abuild.conf and/or signing keys? i hope not...)
2019-12-30 16:36:49 <clandmeter> why does it need to exist?
2019-12-30 16:37:03 <clandmeter> initial run will generate them?
2019-12-30 16:37:22 <mort___> is it ok for one developer to have different signing keys per architecture?
2019-12-30 16:37:41 <Cogitri> Maybe it'd make sense to have a dabuild specific abuild.conf anyway? Right now dabuild assumed that REPODEST is $HOME/packages or else the package won't end up in the bindmount (and as such can't be accessed)
2019-12-30 16:37:48 <clandmeter> why would that be different keys?
2019-12-30 16:38:34 <mort___> clandmeter: doh sorry. yes, can have a single arch-independent volume for ~/.abuild.
2019-12-30 16:38:42 <clandmeter> :)
2019-12-30 16:39:11 <clandmeter> but abuild.conf could be an issue
2019-12-30 16:39:14 <clandmeter> i need to check that
2019-12-30 16:39:33 <clandmeter> i dont think so
2019-12-30 16:40:00 <clandmeter> im confused with /etc/abuild.conf
2019-12-30 16:40:05 <mort___> Cogitri: dabuild lets you set target dir via DABUILD_PACKAGES which is always bind-mounted to /home/builder/packages
2019-12-30 16:40:18 <clandmeter> its not
2019-12-30 16:40:21 <clandmeter> ;-)
2019-12-30 16:40:25 <clandmeter> its relative to aports
2019-12-30 16:41:04 <clandmeter> but configurable ofc
2019-12-30 16:41:07 <Cogitri> mort___: Even so you have to be careful to keep those two in sync
2019-12-30 16:41:36 <Cogitri> It'd make more sense to just set REPODEST in abuild.conf according to DABUILD_PACKAGES or the other way around
2019-12-30 16:42:04 <Cogitri> Took me some time to get that dabuild didn't generate packages due to those two values being out of sync which is very annoying
2019-12-30 16:42:28 <mort___> pnig
2019-12-30 16:42:32 <mort___> *ping
2019-12-30 16:42:36 <Cogitri> And I think it actually still doesn't work properly, dabuild doesn't find the packages I built recently, haven't looked into why that happens yet
2019-12-30 16:42:38 <mort___> (sorry, was offline for a bit, flaky wifi still)
2019-12-30 16:42:51 <mort___> too many threads :)
2019-12-30 16:42:59 <clandmeter> Cogitri: please add an issue so we can look into it.
2019-12-30 16:43:05 <Cogitri> Will do
2019-12-30 16:43:38 <clandmeter> mort___: so making .abuild a named volume is probably a better solution
2019-12-30 16:43:54 <clandmeter> and add some interface to access it.
2019-12-30 16:45:42 <mort___> trying to take them in turn:
2019-12-30 16:45:43 <mort___> - /etc/abuild.conf is bind mounted in if it exists (to cover the case where dabuild is used on an alpine host
2019-12-30 16:45:43 <mort___> - ~/.abuild/ could indeed be created in a volume and shared between all dabuild invocations and I should probably do this (what control might a user wish to exercise over it's contents? i've only ever done the simple thing of use the autogenerated signing keys)
2019-12-30 16:45:43 <mort___> - DABUILD_PACKAGES defaults to something relative to your aports/ tree but can be set arbitrarily; it should always be bind mounted into though so the built packages should always become visible on the host (if they don't then i think that's a bug)
2019-12-30 16:46:44 <clandmeter> i dont think we need to touch /etc/abuild.conf
2019-12-30 16:47:55 <clandmeter> you can set most of it in users abuild.conf?
2019-12-30 16:48:30 <clandmeter> i think you can even do case $CARCH if you want to apply arch based settings.
2019-12-30 16:48:42 <mort___> i'm not sure what it contains but i think someone said it would be useful to have it there cf docker-abuild#6
2019-12-30 16:48:59 <clandmeter> user abuild.conf is sources after global one
2019-12-30 16:49:05 <mort___> i don't think it's a problem to bind-mount it in anyway
2019-12-30 16:49:06 <clandmeter> so you can overide it and add things.
2019-12-30 16:49:11 <clandmeter> i dont see the need.
2019-12-30 16:49:46 <mort___> i don't know all the developer workflows -- there may be people using dabuild who rely on content of their /etc/abuild.conf for all i know :)
2019-12-30 16:50:03 <clandmeter> we curerntly dont mount it do we?
2019-12-30 16:50:07 <mort___> dont think it causes any harm to mount it through (given it's already implemented like that)
2019-12-30 16:50:08 <mort___> yes
2019-12-30 16:50:22 <clandmeter> i dont have one on mac anyway
2019-12-30 16:50:25 <mort___> ~lines 77-79
2019-12-30 16:50:50 <mort___> https://github.com/alpinelinux/docker-abuild/blob/master/dabuild.in#L76-L78 in fact
2019-12-30 16:51:01 <clandmeter> i have no strong opinion. i just dont think its smart to do.
2019-12-30 16:51:28 <mort___> i think it's already done, it might reduce surprise in some cases, and it doesn't cause any other problems, so would leave that as-is
2019-12-30 16:52:10 <mort___> putting ~/.abuild into a named volume seems something worth adding, with the dabuild script copying into the named volume from ~/.abuild on the host if it exists, otherwise just creating from scratch
2019-12-30 16:52:36 <mort___> (happy to be told otherwise about that last point though)
2019-12-30 16:52:54 <mort___> issues with DABUILD_PACAKGES not working as expected are just bugs and would be useful if filed as issues :)
2019-12-30 16:53:58 <clandmeter> btw, ccache is currently not individually configurable.
2019-12-30 16:54:16 <clandmeter> i dont like the idea of having named mounts for all those / directories
2019-12-30 16:54:25 <clandmeter> so i prefer to keep that disabled
2019-12-30 16:54:37 <clandmeter> (for me personally)
2019-12-30 16:54:42 <mort___> what do you mean, "not individually configurable"?
2019-12-30 16:55:00 <clandmeter> ccache gets mounted only when CACHE is enabled right?
2019-12-30 16:55:32 <mort___> ccache isn't mounted at all
2019-12-30 16:55:44 <mort___> ccache is a package that gets installed for abulid to use (AIUI, i've not looked at the details)
2019-12-30 16:55:55 <clandmeter> .ccache is a directory
2019-12-30 16:56:16 <mort___> yes - not mounted anywhere, exists only inside container
2019-12-30 16:56:51 <mort___> DABUILD_CACHE controls whether the named volumes are mounted as subdriectories of / so that changes are persisted between successive invocations of dabuild  (eg if doing a build requires installing lots of packages first)
2019-12-30 16:57:09 <clandmeter> i think you made ccache part of it?
2019-12-30 16:57:29 <clandmeter> https://github.com/alpinelinux/docker-abuild/blob/master/Makefile#L8
2019-12-30 16:57:31 <mort___> the named volumes effectively act as copy-on-write layers overlaid on the origianal image
2019-12-30 16:57:42 <mort___> ah! doh, yes i did
2019-12-30 16:58:14 <mort___> cf https://github.com/alpinelinux/docker-abuild/issues/48
2019-12-30 16:58:22 <mort___> :)
2019-12-30 16:58:33 <clandmeter> yes
2019-12-30 16:58:38 <clandmeter> i have more ideas but no time
2019-12-30 16:58:47 <clandmeter> lets talk later
2019-12-30 16:58:55 <mort___> ah right - so you want .ccache mounted regardless of wheter DABUILD_CACHE is set?
2019-12-30 16:58:56 <clandmeter> thx for the chat :)
2019-12-30 16:59:05 <clandmeter> yes
2019-12-30 16:59:12 <mort___> i can do that easy enough - sorry for being dense :)
2019-12-30 16:59:23 <mort___> will put a PR in now
2019-12-30 16:59:24 <clandmeter> i think it could even be a single named volume
2019-12-30 16:59:31 <mort___> yes
2019-12-30 16:59:32 <clandmeter> but with subdirs per arch
2019-12-30 16:59:43 <clandmeter> ok i need to run :)
2019-12-30 16:59:45 <clandmeter> laters
2019-12-30 16:59:49 <mort___> ttfn!
2019-12-30 17:14:21 <_ikke_> mort___: re moving docker-abuild to gitlab, is there anything special to it?
2019-12-30 17:17:08 <Cogitri> As noted in the issue, please use the import function of Gitlab to retain issues and stuff :)
2019-12-30 17:18:58 <_ikke_> Right
2019-12-30 17:24:02 <mort___> _ikke_: no don't think there's anything special - what sort of special thing might there be?
2019-12-30 17:24:35 <_ikke_> What would you expect to happen for CI?
2019-12-30 17:25:04 <mort___> ah - right now, there's no CI other than the drone stuff, which i didn't setup :)
2019-12-30 17:25:20 <_ikke_> Currently it builds images for each of the arches we support, upload them to docker, and create a manifest
2019-12-30 17:25:21 <mort___> which is supposed to build the base images that dabuild uses
2019-12-30 17:26:05 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/gitlab-ci-templates/blob/master/docker-image.yml
2019-12-30 17:30:09 <mort___> (sorry was offline for a while) the correct moment to build those images is whenever the appropriate aports branch (vX.X or master) is updated i think
2019-12-30 17:35:26 <mort___> will import the repo to gitlab when i'm back on a stable connection
2019-12-30 17:38:01 <_ikke_> mort___: yes, it would upload the images only for master
2019-12-30 17:38:22 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/gitlab-ci-templates/blob/master/docker-image.yml#L99
2019-12-30 17:38:36 <kaniini> hi all
2019-12-30 17:39:02 <_ikke_> hey
2019-12-30 17:40:49 <Cogitri> Hello
2019-12-30 18:28:08 <SpaceToast> ping - is podman and co. up for adoption? I've been looking at it lately and might be interested in getting it functional
2019-12-30 18:28:40 <_ikke_> apparently it is, there is no maintainer recorded
2019-12-30 18:29:18 <Cogitri> I think maxice8 just forgot to fill that out
2019-12-30 18:29:19 <SpaceToast> that doesn't necessarily mean it's up for adoption :) someone's clearly been keeping it up to date
2019-12-30 18:30:00 <SpaceToast> there's a lot of broken aspects to it though, so I basically want to know whether to work with whoever's keeping it updated (without being the official maintainer) or actually adopt, basically
2019-12-30 18:30:17 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2560
2019-12-30 18:30:42 <Cogitri> Oh nevermind, I think the MR was accidental
2019-12-30 18:31:02 <Cogitri> https://gitlab.alpinelinux.org/kohnish introduced it and yes, it's kinda broken
2019-12-30 18:31:28 <SpaceToast> ah, I see
2019-12-30 18:31:36 <SpaceToast> thanks Cogitri :)
2019-12-30 18:32:03 <SpaceToast> I've still to figure out if I really wanna take it up, but if I do I'll just adopt it and see if someone complains
2019-12-30 18:36:42 <Cogitri> Sounds good
2019-12-30 19:56:16 <kaniini> hey what if we do something fun and exciting and switch to uClibc again
2019-12-30 19:56:21 <kaniini> ok i'll show myself out
2019-12-30 23:40:10 <shrizza> Hm, anyone recognize errors like this?
2019-12-30 23:40:12 <shrizza> Error relocating /usr/bin/../lib/libclang-cpp.so.9: Error relocating /usr/bin/../lib/libclang-cpp.so.9: _ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEC1Ev_ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEC1Ev: symbol not found: symbol not found
2019-12-30 23:40:31 <shrizza> This package used to successfully build a few months ago but I'm now getting errors.
2019-12-30 23:41:56 <north1> Sounds like an ABI mismatch
2019-12-30 23:42:10 <north1> usually find that when people mix 3.X with edge and everything blows up :D
2019-12-30 23:42:20 <north1> https://github.com/lovell/sharp/issues/1979 like this
2019-12-31 02:12:45 <kaniini> north1: perhaps we should declare dependency on libstdcxx abi version for c++ packages
2019-12-31 02:13:10 <kaniini> I'll write something up about it
2019-12-31 11:44:38 <mps> someone on debian-arm posted msg that RPi4 can be built from upstream 5.5-rc3 and boot , https://lists.debian.org/debian-arm/2019/12/msg00029.html
2019-12-31 11:45:38 <mps> also mentioned that custom kernel from upstream for RPi3 works
2019-12-31 12:36:37 <clandmeter> SpaceToast: did you do some podman work already?
2019-12-31 12:38:24 <clandmeter> hmm if a src tree has the directory "hack" doesnt give you a warm and fuzzy feeling...
2019-12-31 13:01:09 <shrizza> north1: I don't use edge I think?
2019-12-31 13:03:10 <Cogitri> Well, do you use a 3.x release but install clang from the edge repos?
2019-12-31 13:11:36 <SpaceToast> clandmeter: no, I'm going to be busy for a while, just looking/talking-to upstream right now
2019-12-31 13:13:55 <MY-R> I see on irc already 2 "symbol not found" / "relocating" errors in different applications, that from shrizza, another from xfz on #alpine-linux and mine issue which was fixed (python 3.8 related) #11066 isnt weird? :P
2019-12-31 13:18:25 <shrizza> Hm... OK, actually I checked and actually I did have edge repos uncommented.
2019-12-31 13:18:38 <shrizza> Once I commented them and tried abuild -r again, it seems to be moving along.
2019-12-31 13:19:46 <mps> usual report and usual solution :)
2019-12-31 13:19:46 <shrizza> So is there a good way to fix my package here?
2019-12-31 13:20:02 <shrizza> It's just failing by default now.
2019-12-31 13:20:21 <MY-R> and now all issues fixed by using apk upgrade and not mixing edge with stable :D
2019-12-31 13:28:47 <mps> MY-R: if I'm channel OP I would be tempted to put these words in topic, especially on #alpine-linux
2019-12-31 13:29:47 <MY-R> mps, could you create issue on gitlab about it? :D
2019-12-31 13:30:01 <mps> :D
2019-12-31 13:30:50 <MY-R> or everytime when somebody write "symbol not found" then alpinebot will paste smart hint :>
2019-12-31 13:31:43 <mps> this sound better idea
2019-12-31 13:36:53 <Cogitri> Well, the best thing would be if we depended on a specific ABI version of a lib instead of depending on a specific soversion, I suppose
2019-12-31 13:37:04 <Cogitri> But that'd be rather tedious work, I suppose :)
2019-12-31 13:38:37 <mps> or be conservative in upgrades
2019-12-31 13:44:31 <Cogitri> Meh, being careful because everything could break with every upgrade isn't really a path forward imho
2019-12-31 13:47:05 <mps> going forward for the sake of going forward is not good path to going forward, imo
2019-12-31 13:50:24 <Cogitri> Going forward for the sake of more features, better performance and security fixes certainly is though :)
2019-12-31 13:51:35 <mps> +1, but you forgot to add stable and working system I presume :)
2019-12-31 13:52:04 <mps> which is not easy task, I know
2019-12-31 13:54:16 <mps> but ok, there is no 'thing' mankind made which is not fragile
2019-12-31 13:56:04 <Cogitri> Yup, but I don't think I had any of my systems break once on Alpine edge as of yet
2019-12-31 13:56:31 <AinNero> agree, im sitting on edge as well waiting for stuff to break
2019-12-31 13:56:31 <Cogitri> If you don't mix and match repos (read: do unsupported things) everything is fine usually :)
2019-12-31 13:57:14 <nmeum> does anybody have an opinion on !2248? Otherwise I would probably just merge it as is, not sure if the armhf failure is also reproducible on the builders...
2019-12-31 13:57:16 <mps> ofc, also on my some boxes edge works quite fine
2019-12-31 13:58:25 <mps> nmeum: to me this is ok
2019-12-31 14:00:17 <Cogitri> nmeum: Seems good to me, but I don't use Wireshark
2019-12-31 14:00:52 <nmeum> I do and I am personally very annoyed by the fact that we don't offer any easy way to let unprivileged users use it (:
2019-12-31 14:03:58 <mps> I use tshark and tcpdump mostly, but also wirehark to analyze dumps
2019-12-31 14:04:33 <nmeum> that was also my previous workflow, running tcpdump or tshark as root and then analyzing the dumps using wireshark as non-root
2019-12-31 14:15:58 <zfoo> Is it possible to cross-compile with abuild? I set 'CROSS_COMPILE' in the env and it built successfully but failed on 'prepare_package' for 'Unable to recognize the format of input file'
2019-12-31 14:16:45 <zfoo> host is x86_64 and the target was armv7
2019-12-31 14:18:03 <Cogitri> No, it's not possible
2019-12-31 14:18:14 <Cogitri> We only support native compilation for now
2019-12-31 14:18:23 <Cogitri> We only use cross to bootstrap new targets
2019-12-31 14:51:31 <ddevault> ncopa: python bump
2019-12-31 16:28:32 <PureTryOut[m]> I wonder, why are a package `$depends` installed when building the package (`abuild -r`)?
2019-12-31 16:29:56 <AinNero> for C programs i could only come up with an explanation for -dev packages
2019-12-31 16:30:38 <ncopa> ddevault: aad4175d78e4f745f84d460279b9b75c27eb80cd
2019-12-31 16:30:48 <ddevault> thanks ncopa!
2019-12-31 16:31:21 <Cogitri> PureTryOut[m]: They're installed onto the system, same as makedepends
2019-12-31 16:31:36 <Cogitri> (So specifying something in both depends and makedepends is redundant)
2019-12-31 16:31:41 <PureTryOut[m]> Yeah but why
2019-12-31 16:31:52 <PureTryOut[m]> Everything that is required for compiling it should already be in makedepends
2019-12-31 16:32:06 <north1> Problably for running the package or you would need to replicate depends on makedepends
2019-12-31 16:32:25 <PureTryOut[m]> Now I have packages installing stuff that isn't required for building it and it just takes a lot of bandwidth and time
2019-12-31 16:32:45 <Cogitri> depends usually are also required for check()
2019-12-31 16:32:48 <AinNero> which aport?
2019-12-31 16:33:32 <mps> PureTryOut[m]: is $depends put in makedepends or checkdepends
2019-12-31 16:34:00 <PureTryOut[m]> That's why there is checkdepends though lol. Is it such a problem to duplicate some entries over the different depends?
2019-12-31 16:39:38 <Cogitri> That's what checkdepends is for, but in like 95% of cases where tests are enabled you need $depends on checkdepends
2019-12-31 16:40:34 <PureTryOut[m]> I guess... A bit annoying though when some stuff is actually only required at runtime but is still installed
2019-12-31 16:41:02 <Cogitri> Yes, I see your point but changing that behaviour now doesn't exactly seem nice either
2019-12-31 16:41:18 <Cogitri> And I suppose on the builders it doesn't matter much
2019-12-31 16:42:44 <PureTryOut[m]> No but it does matter when developing locally and having a bit of a slow network 😛
2019-12-31 17:22:20 <mps> new year gift, kernel 5.4.7 :)
2019-12-31 17:23:12 <mps> I have something to work this night
2019-12-31 17:23:28 <north1> beer ?
2019-12-31 17:26:05 <mps> cheers ! though I prefer wine
2019-12-31 17:26:30 <north1> beer is placeholder for alcohol for me really
2019-12-31 17:26:37 <north1> I don't drink so it is all the same
2019-12-31 17:27:24 <AinNero> oh, its last night of the year
2019-12-31 17:27:28 <AinNero> that explains the noise
2019-12-31 17:27:32 <AinNero> 
ACTION closes curtains

2019-12-31 17:27:46 <mps> north1: you miss good part of life :)
2019-12-31 17:28:02 <AinNero> mps: i dont like booze as well
2019-12-31 17:28:11 <mps> :)
2019-12-31 17:28:11 <AinNero> not that i never tried, it just makes me feel worse
2019-12-31 17:34:43 <north1> mps (IRC): No need for alcohol when you have apple juice
2019-12-31 17:37:03 <mps> enjoy :) (whatever you like)
2019-12-31 17:51:41 <Cogitri> Heh, cheers mps :)
2019-12-31 18:06:44 <mps> Hey Cogitri, cheers !
2019-12-31 18:07:45 <north1> got a big nice christmas gift from Telegram Desktop team
2019-12-31 18:07:54 <north1> they made a tarball that includes all the git submodules checked out
2019-12-31 18:08:02 <north1> take note everyone that uses git submodules, and rust people
2019-12-31 18:15:38 <Cogitri> Neat
2019-12-31 18:32:40 <MY-R> yes!
2019-12-31 18:42:10 <mps> north1: https://gitlab.alpinelinux.org/mps/aports/-/jobs/29324/artifacts/raw/packages/main/x86_64/linux-lts-5.4.7-r0.apk
2019-12-31 18:42:39 <mps> there are two i915 fixes, maybe this can help you
2019-12-31 18:42:49 <north1> downloading
2019-12-31 18:43:27 <mps> and there is MCE/AMD fix for those who had issues in booting new AMD boxes
2019-12-31 18:44:09 <mps> for now it boots on my box at least: 5.4.7-0-lts #1-Alpine SMP Tue, 31 Dec 2019 18:04:43 UTC x86_64 GNU/Linux
2019-12-31 18:44:21 <north1> re: telegram-desktop
2019-12-31 18:44:32 <north1> on the bad side they switched to CMake and apparently don't make it easy to use system components
2019-12-31 18:44:51 <north1> which is very annoying because i don't want to build external_qt external_ffmpeg external_whatever
2019-12-31 18:45:26 <Cogitri> Not using GYP is neato though
2019-12-31 18:45:28 <mps> uhm, cmake :\
2019-12-31 18:45:46 <north1> it is neato but it worked before, barely
2019-12-31 23:06:02 <AinNero> man wtf is going on with my neighbours
2019-12-31 23:07:13 <mps> hmm, are you in my neighborhood :)
2019-12-31 23:12:56 <north1> AinNero (IRC): fireworks ?
2019-12-31 23:13:11 <AinNero> yes
2019-12-31 23:13:14 <AinNero> and party noises
2019-12-31 23:13:46 <north1> lots of fun really
2019-12-31 23:14:10 <AinNero> i do enjoy it as most cats and dogs enjoy it
2019-12-31 23:16:41 <north1> Used to enjoy like that as well
2019-12-31 23:18:57 <mps> as retired artillerist I don't care, but sorry for dogs and cats