2019-12-01 00:01:16 woot 2019-12-01 00:31:59 _ikke_: any problem with https://tpaste.us/XgKl and moving it to community? 2019-12-01 02:11:22 can someone fix the greedy permission gitlab app want from gitlab oauth users ? 2019-12-01 02:11:48 the app owner seems to be https://gitlab.com/kdaudt 2019-12-01 02:19:07 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 ACTION prod 2019-12-01 04:06:26 can I get a final review on this please https://github.com/alpinelinux/aports/pull/12044 ? 2019-12-01 08:55:56 russkel: Ah yes, someone with access to main/ gotta merge that 2019-12-01 08:56:36 =) 2019-12-01 08:59:24 <_ikke_> Cogitri: a review is still helpful :-) 2019-12-01 08:59:53 Yup, I already approved it :P 2019-12-01 09:10:50 <_ikke_> clandmeter: fine with me 2019-12-01 09:11:09 :) 2019-12-01 09:56:58 sh4rm4^bnc: oauth, price for commodity :) 2019-12-01 10:56:26 north1: when you already looking for my MR's :), would you mind to look !1784 2019-12-01 10:56:41 simple removal of stale patch 2019-12-01 10:58:25 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 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 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 ok, will make MR and see 2019-12-01 12:13:50 <_ikke_> heh 2019-12-01 12:13:57 heh ;- 2019-12-01 12:14:05 ) 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 _ikke_: I found solution for upx by disabling '-no-pie' test but not sure should I do that 2019-12-01 12:19:03 i.e. disable this test 2019-12-01 12:19:21 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 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 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 Cogitri: upx is not built with -no-pie, just test something together with static, '-static -no-pie' 2019-12-01 12:51:31 Ah 2019-12-01 13:45:00 _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 _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 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 so, it segfaults in docker and not in lxc 2019-12-01 14:00:25 _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 _ikke_: I run ./upxtest in lxc and got '1,0x1000200030004001' 2019-12-01 14:06:56 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 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 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 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-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 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 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 agree 2019-12-01 14:39:48 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 s/but/but I/ 2019-12-01 14:40:13 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 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 didn't looked, hope someone who worked with it will know 2019-12-01 16:40:40 _ikke_, yeah that looks much better 2019-12-01 16:40:42 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 hm, postgresql-pglogical is move to GH and is buggy much too 2019-12-01 17:29:52 oh, this one https://github.com/2ndQuadrant/pglogical/issues/223 2019-12-01 17:30:18 it is not yet ready for postgresql-12 2019-12-01 17:31:00 should be disabled for now? 2019-12-01 17:56:50 perl-xml-libxslt fails only on 32bit, in one test file 2019-12-01 19:47:27 kernel 4.19.87 is out 2019-12-01 20:09:26 _ikke_, seems to work. i filed issue 11001 as requested. 2019-12-01 20:10:16 wow, that bot is so smart it certainly has a HUGE AI built-in! (j/k) 2019-12-02 08:14:52 morning 2019-12-02 08:16:44 \o 2019-12-02 08:17:49 ncopa: you will probably upgrade kernel? 4.19.87? 2019-12-02 08:18:09 looks like it is xmltv, patchwork, llvm5 and postgresql-pglogical that are the current blockers 2019-12-02 08:18:24 yeah, im upgrading the vanilla kernel 4.19.87 2019-12-02 08:18:25 please look at the !1790 when you do upgrade 2019-12-02 08:19:58 well, _ikke_ and I discussed some of these blockers, backlog of this channel has our discusssion 2019-12-02 08:20:47 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 and only ghc and crystal deps on llvm5 2019-12-02 08:25:36 and upx fails, i made !1795 to fix it 2019-12-02 08:27:06 but _ikke_ and I ask why is the custom check is added in APKBUILD there 2019-12-02 08:28:50 _ikke_: could you look !1784 2019-12-02 08:29:21 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 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 I see, thanks. (will not have to go through rebasing my messed branches :) ) 2019-12-02 08:33:45 and, I think we should disable postgresql-pglogical till upstream releases version which supports postgresql 12 2019-12-02 09:07:41 _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 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 oh, ghc is x86_64 only 2019-12-02 10:05:39 @ncopa can you take a look at #11001 ? 2019-12-02 10:06:57 north1: I'm against this request 2019-12-02 11:07:20 mps: can you please mention in the issue why you are against it? 2019-12-02 11:07:54 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 i thikn that i have used it occationally 2019-12-02 11:08:44 but it is not often 2019-12-02 11:10:01 why not move it to extras? 2019-12-02 11:10:32 thats also an option 2019-12-02 11:10:50 but if you need patch, you'd probably better off using gnu patch anyway 2019-12-02 11:11:05 rather than install busybox-extras 2019-12-02 11:11:10 right 2019-12-02 11:11:17 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 we used to use busybox patch 2019-12-02 11:11:34 long time ago 2019-12-02 11:11:40 but abuild now uses gnu patch 2019-12-02 11:12:55 ae0e4a4e1f05cc2fe7dd371517f1f4d8d663dd4d 2019-12-02 11:13:01 2015 2019-12-02 11:24:33 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 gnu patch is installed by default by alpine-sdk so not issue for developers 2019-12-02 11:25:54 I have impression that small number of people read issues 2019-12-02 11:26:16 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 mps: i have also used busybox patch for minor sysadmin tasks 2019-12-02 11:29:23 but i dont do that very often 2019-12-02 11:30:16 the question is if the price for avoiding that extra `apk add patch` is worth it 2019-12-02 11:31:01 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 agree with _ikke_ here, following every inconvenience with bb applets we should remove bb and add coreutils then 2019-12-02 11:37:24 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 i think there are significantly more people who uses busybox ip route than people who use busybox patch 2019-12-02 11:43:10 probably 2019-12-02 11:44:06 I will not stop now about that (non) issue 2019-12-02 11:44:35 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 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 in case i remove busybox patch, it still serves as documentation that the usecases of it was considered 2019-12-02 11:46:02 _ikke_: that is true 2019-12-02 11:46:32 there may be dockerfiles which uses it 2019-12-02 11:48:27 ncopa: ok, I will write my opinion there, (although told that I will stop about this :) ) 2019-12-02 11:48:50 heh, that's life, never say never :) 2019-12-02 11:51:50 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 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 it is cumbersome, sure, but anyone have better idea 2019-12-02 11:59:39 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 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 keep in mind that `apk upgrade` will not downgrade the package so `apk upgrade -a` is needed 2019-12-02 12:15:29 heh 2019-12-02 12:15:30 Ah, okie 2019-12-02 12:15:31 you beat me to it 2019-12-02 12:15:42 -a i all i use these days 2019-12-02 12:15:44 We don't have anything that downgrades it for all users? 2019-12-02 12:16:19 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 they dont release a newer version which is not broken? 2019-12-02 12:18:03 Well, it's only broken on non-systemd versions, soooo :P 2019-12-02 12:18:19 So upstream doesn't encounter the breakage 2019-12-02 12:18:22 ah right, who cares about those fools... :) 2019-12-02 12:18:36 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 ( rm -rf *gnome* ) :) 2019-12-02 12:19:10 Cogitri: apk will always select the highest version 2019-12-02 12:19:10 Cogitri: downgrade the release to 3.34.1 and increase pkgrel is the best you got 2019-12-02 12:19:14 execpt if you use -a 2019-12-02 12:19:32 it will prevent people who do new install to get the broker version 2019-12-02 12:19:40 i think there was talk to make it default in new apk? 2019-12-02 12:19:56 possibly 2019-12-02 12:20:00 That'd be nice 2019-12-02 12:20:11 Not having any way to downgrade already upgraded users is kinda bad 2019-12-02 12:20:13 i think it makes sense 2019-12-02 12:20:46 Cogitri: I do by 'apk add pkgname=version' 2019-12-02 12:21:05 Yes, but that's manual user action 2019-12-02 12:21:16 Something that just works is nice :) 2019-12-02 12:21:40 i think you can fix it by depending on exact version in ahtoher pkg? 2019-12-02 12:21:43 users should be educated 2019-12-02 12:22:04 so whatever pulls in gnome-session 2019-12-02 12:22:45 ritght, that may work 2019-12-02 12:23:00 but you need to remind yourself about it 2019-12-02 12:23:37 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 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 right, and I think sometimes we should add it 2019-12-02 12:24:40 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 Alrighty. 2019-12-02 12:25:33 but again, I don't think that much uneducated users use alpine 2019-12-02 12:25:52 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 well, to achieve something where big distros are we need a lot more man power (hands) 2019-12-02 15:27:41 Ah, here, this might be quicker kaniini 2019-12-02 15:38:41 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 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 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 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 hi kpcyrd! 2019-12-02 15:44:47 this is the revert commit https://gitlab.alpinelinux.org/alpine/abuild/commit/51d9e3bcb9fe99a67059e08d7b6fb6ca6a2b75c2 2019-12-02 15:44:58 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 i may have an account, but i dont remember. and im not using it 2019-12-02 15:47:32 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 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 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 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 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 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 kpcyrd: no, the reproducibilty assumes that you ahve the same signing key when you build it 2019-12-02 16:48:32 so, build apk, save the checksum of .apk 2019-12-02 16:48:34 rebuild it 2019-12-02 16:48:38 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 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 apk does it's own tar parsing, right? 2019-12-02 17:16:24 <_ikke_> I guess so 2019-12-02 17:38:04 (1/1) Installing alpine-mirrors (3.5.10-r0) 2019-12-02 17:38:06 OK: 237 MiB in 67 packages 2019-12-02 17:38:14 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 ncopa: can you try this patch? https://gitlab.com/kpcyrd/abuild/commit/b514a4e56d4d17da53bbe5a2d203f616f9a9f371 2019-12-02 17:48:27 (_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 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 Heh, not quite, algitbot :P 2019-12-02 18:33:45 <_ikke_> Cogitri: no, we don't 2019-12-02 18:34:52 Good 2019-12-02 18:42:43 clandmeter: Wanna check out pr12092? 2019-12-02 20:43:16 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 I guess it might not expect the locale to start with C 2019-12-02 20:45:26 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 musl only use C.UTF-8, so en_US.UTF-8 looks strange 2019-12-02 20:46:35 Musl itself does, but other programs may not 2019-12-02 20:47:17 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 yes, but I'm asking for default in mdocml 2019-12-02 20:48:32 Cogitri: btw, you are/were void developer? 2019-12-02 20:49:39 I was a Void dev before I switched to Alpine, yes 2019-12-02 20:51:19 could you tell me what means 'vconf ${FILESDIR}/filename' in template files 2019-12-02 20:53:16 The alpine equivalent would be `install -Dm644 "$srcdir"/filename "$pkgdir"/etc` 2019-12-02 20:53:51 thank you 2019-12-02 20:57:14 :) 2019-12-02 21:04:47 _ikke_: !1821 2019-12-02 21:05:26 I took void patches because upstream didn't answered 2019-12-02 21:17:34 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 _ikke_: \o 2019-12-03 07:30:02 morning 2019-12-03 07:30:10 morning 2019-12-03 07:42:21 Morning 2019-12-03 07:56:16 <_ikke_> Morning 2019-12-03 09:05:17 morning 2019-12-03 09:59:59 ncopa: wasn't there some discussion to include ipv6 in the kernel instead of a module? 2019-12-03 10:02:27 possibly, i dont remember 2019-12-03 10:02:48 we should include ipv4 and unix sockets too in that case 2019-12-03 10:03:43 i see ipv6 is added to modules file 2019-12-03 10:04:11 0655da328034c0de4ba88ea54613347b906da77e 2019-12-03 10:09:50 devs, nld5 is going to reboot 2019-12-03 10:09:54 hold your horses 2019-12-03 10:10:15 going to clean the stables 2019-12-03 10:30:27 we have an issue on nld5 2019-12-03 10:30:37 failed disk probably, so needs work to recover 2019-12-03 10:31:28 ncopa: can you backport that EDAC DEBUG fix? 2019-12-03 10:31:38 its filling up my ringbuffer 2019-12-03 10:35:14 clandmeter: maybe you can temporary disable module load, blacklist i3200_edac 2019-12-03 10:35:38 it is x86_64 box? 2019-12-03 10:37:12 ok 2019-12-03 10:37:52 hum, the machine is unavailable... 2019-12-03 10:38:03 my 3.10 machine 2019-12-03 10:38:13 <_ikke_> yes, because it's on nld5 :'( 2019-12-03 11:25:02 could this be related to xmltv build failures https://github.com/XMLTV/xmltv/issues/77 2019-12-03 11:26:27 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 i know 2019-12-03 11:30:20 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 clandmeter: it fails also locally on my box 2019-12-03 11:31:11 <_ikke_> ah ok 2019-12-03 11:31:16 ok 2019-12-03 11:32:24 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 ACTION slaps fcolista around a bit with a large trout 2019-12-03 11:38:07 c007998b4cd24694f46393698fff4f20e36bf6ca 2019-12-03 11:38:21 <_ikke_> :D 2019-12-03 11:44:49 mps: i tried to downgrade perl-xml-parser to 2.45, but it still fails 2019-12-03 11:48:37 ok, i found a fix upstream for xmltv 2019-12-03 11:48:42 <_ikke_> nice 2019-12-03 11:48:52 https://github.com/XMLTV/xmltv/commit/5463cde27030237d79fedd200e49968edaa06f67 2019-12-03 11:48:57 im applying it 2019-12-03 11:49:02 and fixing the contributor line 2019-12-03 11:49:18 <_ikke_> How did you find it? 2019-12-03 11:49:46 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 found it that it was from github 2019-12-03 11:50:16 i looked at github releases and it said that there were 55 commits since last release 2019-12-03 11:50:24 i had a look at the commits 2019-12-03 11:50:45 also I nowadays mostly look at source urls, 'url' for not small number of pkgs is wrong 2019-12-03 11:51:12 hmm, and I thought we can downgrade packages 2019-12-03 11:51:22 s/can/can't/ 2019-12-03 11:51:22 mps meant to say: hmm, and I thought we can't downgrade packages 2019-12-03 11:51:24 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 which the issue mps pointed to seemed to be related to 2019-12-03 11:51:57 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 and yes, I know it was related but as told don't have time now to look deeply 2019-12-03 11:54:51 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 i have a fix 2019-12-03 11:55:47 <_ikke_> ok 2019-12-03 11:55:53 but you wont like it :) 2019-12-03 11:55:59 <_ikke_> oh 2019-12-03 11:56:06 !1795 2019-12-03 11:56:19 use abuild rootbld 2019-12-03 11:56:31 <_ikke_> why wouldn't I like it? 2019-12-03 11:56:41 i dont think you will mind it 2019-12-03 11:56:48 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 our buildsystem sucks 2019-12-03 11:57:24 thats not to complain about it. 2019-12-03 11:57:29 i this case it sucks 2019-12-03 11:57:41 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 i think abuild rootbld could fix it 2019-12-03 11:58:30 Yes 2019-12-03 11:58:39 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 yes 2019-12-03 11:59:18 clandmeter: new buildsystem aka abuildv$Next ? 2019-12-03 11:59:52 the one that ncopa wanted to talk about in fosdem :| 2019-12-03 12:00:57 Oh, I wasn't at this years FOSDEM sadly 2019-12-03 12:01:06 (Hopefully at the next one though) 2019-12-03 12:01:41 the plan was 2020 afaik 2019-12-03 12:01:45 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 maybe fabled wants to talk about new apk-tools 2019-12-03 12:02:19 that would be cool :) 2019-12-03 12:02:39 as long i dont have to talk, everyting is cool . 2019-12-03 12:09:01 mps: wouldnt it be better to try fix -static -no-pie? 2019-12-03 12:11:23 clandmeter:+1 on that :P 2019-12-03 12:12:03 ncopa: cant we introduce rootbld on builders? 2019-12-03 12:12:47 i think we could 2019-12-03 12:12:48 but 2019-12-03 12:12:59 options=!rootbld in case it fails 2019-12-03 12:12:59 ncopa: this test is added in APKBUILD, it doesn't exist upstream 2019-12-03 12:13:10 its a major change 2019-12-03 12:13:31 im a bit worried to do that change so late 2019-12-03 12:13:35 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 we dont need it now 2019-12-03 12:13:50 lets do it after 3.11 2019-12-03 12:13:53 not sure if this test is needed at all 2019-12-03 12:13:59 ok but for sure then. 2019-12-03 12:14:05 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 yes 2019-12-03 12:14:17 mps: it tests that upx works with a static binary without pie 2019-12-03 12:14:21 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 yes, but then we should contact maintainer and ask his reasoning for this, and fix 2019-12-03 12:15:27 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 so devs should be prepared 2019-12-03 12:15:54 kappe nou 2019-12-03 12:15:57 :p 2019-12-03 12:15:59 mps: the reasoning is that we want upx to work on different kinds of binaries 2019-12-03 12:16:05 ikke: First step would be warn/error in CI 2019-12-03 12:16:11 aha, ok 2019-12-03 12:16:20 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 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 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 I have to fix mdocml and maybe crystal, if we remove llvm5 2019-12-03 12:17:28 i think i fixed llvm5 2019-12-03 12:17:34 it was the mips target that failed 2019-12-03 12:17:40 so i simply removed mips target 2019-12-03 12:17:48 iirc, it fails on all 2019-12-03 12:17:58 oh? 2019-12-03 12:18:19 maybe _ikke_ have more infos 2019-12-03 12:18:36 <_ikke_> nope 2019-12-03 12:18:46 _ikke_: Oh right, somehow I forgot we don't fetch lang deps in a seperate phase, oops :P 2019-12-03 12:18:47 Maybe we can just have a rootbld pipeline? 2019-12-03 12:18:58 and firefox with rust 1.39 fails on all 2019-12-03 12:19:15 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 good news 2019-12-03 12:25:25 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 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 mps: i applied your upx patch, i only added a FIXME comment 2019-12-03 12:38:16 that's fine, I think 2019-12-03 12:38:38 if we find solution later this can be reenabled 2019-12-03 12:39:08 iiuc, you want 3.11 release soon 2019-12-03 12:40:10 ugh... i think i have messed up the xmltv test 2019-12-03 12:41:09 phew... seems i was lucky 2019-12-03 12:42:12 clandmeter, ? 2019-12-03 12:42:24 <_ikke_> fcolista: you messed up an upgrade 2019-12-03 12:42:32 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 the contributor line 2019-12-03 12:43:55 and i have fixed it already 2019-12-03 12:43:56 omg 2019-12-03 12:44:00 :) 2019-12-03 12:44:23 /0\ 2019-12-03 12:44:37 Hehe 2019-12-03 12:44:41 ACTION deserves being slapped with large trout :) 2019-12-03 12:45:38 looks like community repos are 99% or 100% on all arches 2019-12-03 12:45:55 which means we are close to make rc1 2019-12-03 12:46:00 <_ikke_> :) 2019-12-03 12:46:04 Nice 2019-12-03 12:46:14 have you tested the linux-lts? 2019-12-03 12:46:40 i'd like to move linux-vanilla to community and linux-lts to main 2019-12-03 12:47:01 and use that as the default kernel for v3.11 2019-12-03 12:47:58 Sounds good to me 2019-12-03 12:47:59 I'm using linux-lts right now 2019-12-03 12:48:36 For some reason my laptop doesn't boot with linux-vanilla anymore though 2019-12-03 12:48:49 heh 2019-12-03 12:49:35 So yeah, +1 for linux-lts :P 2019-12-03 12:51:18 also I use -lts, no issues, or I didn't noticed 2019-12-03 12:52:49 only don't forget to apply EDAC_DEBUG patch for x86_64 2019-12-03 12:53:35 right, i'll do that with 5.4.2 2019-12-03 12:53:49 and I need to update linux-headers MR 2019-12-03 12:56:14 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 kpcyrd: i had a quick look at it, but i think the checksum differed after built second time 2019-12-03 13:22:54 i am also slightly worried to modify the way the packages are built so close to a release 2019-12-03 13:23:04 almost all packages for v3.11 is built at this point 2019-12-03 13:23:19 so i think i'll have a closer look at it after the 3.11 release 2019-12-03 13:23:54 it does seem to fix the problem with package not being installable 2019-12-03 13:26:55 i moved doas to main 2019-12-03 13:27:07 i wonder about the default config though 2019-12-03 13:27:14 it currently has: 2019-12-03 13:27:25 # Uncomment to allow group "admin" to become root 2019-12-03 13:27:25 # permit :admin 2019-12-03 13:27:47 we had group "wheel" in default sudo config 2019-12-03 13:27:55 so i wonder if we should od: 2019-12-03 13:27:58 do: 2019-12-03 13:28:18 # permit persistent :wheel 2019-12-03 13:28:22 as the default 2019-12-03 13:28:55 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 _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 please, push it or build locally and test if the segfault is fixed 2019-12-03 13:32:51 ok, np, just don't forget, I can't it is in main 2019-12-03 13:33:22 and sorry to annoy you too often 2019-12-03 13:33:31 <_ikke_> np 2019-12-03 15:33:28 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 walbon: welcome! 2019-12-03 15:34:54 \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 _ikke_: i think i have set some options on my container to allow bwrap 2019-12-03 15:55:53 not sure which syscalls it needs 2019-12-03 15:56:03 I probably didnt look too close 2019-12-03 15:56:18 <_ikke_> ok 2019-12-03 15:59:07 Cogitri: https://ftp.mozilla.org/pub/firefox/releases/71.0/source/firefox-71.0.source.tar.xz 2019-12-03 16:02:04 How to get previous N messages? Some one mentioned me but I was offline 2019-12-03 16:02:37 https://dev.alpinelinux.org/irclogs/ 2019-12-03 16:02:49 <_ikke_> clandmeter: now you beat me :) 2019-12-03 16:03:20 and me :) 2019-12-03 16:03:25 we should let algitbot metnion it on irc + logs 2019-12-03 16:03:54 some shorthand: 'algitbot: irclog' 2019-12-03 16:05:09 algitbot: irclog 2019-12-03 16:05:20 'algitbot: irclog' 2019-12-03 16:05:32 heh, it is a suggestion from mps 2019-12-03 16:05:38 not a real feature 2019-12-03 16:05:50 clandmeter: Thanks. I start trying that :+1:\ 2019-12-03 16:06:28 Ok. So, it is false positive from freenode. There was no new message for me. :] 2019-12-03 16:06:43 fcolista: Hi, did you fix the issue? 2019-12-03 16:08:21 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 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 wut 2019-12-03 16:13:24 rnalrd: why is go in depends? b9e2e0c480ef3958c6dfac5191afb37a48cbec1a 2019-12-03 16:14:14 _ikke_: could we warn CI on lines that are longer than 80 chars? 2019-12-03 16:15:20 oh im getting tired, looking in gentoo repo... 2019-12-03 16:15:41 ncopa, mps, _ikke_: thks 2019-12-03 16:17:18 <_ikke_> clandmeter: you mean APKBUILD lines? 2019-12-03 16:17:27 yes 2019-12-03 16:17:28 <_ikke_> clandmeter: every hash would violate it 2019-12-03 16:17:44 depends on rules i think? 2019-12-03 16:17:57 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 ? 2019-12-03 16:21:53 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 :) 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 understand 2019-12-03 16:26:29 i was triggered by gentoo repo 2019-12-03 16:26:36 it used some really long lines 2019-12-03 16:26:50 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 but we can warn right? 2019-12-03 16:27:27 <_ikke_> yup 2019-12-03 16:37:38 clandmeter (IRC): Tried to warn on over 80 chars but that will catch all sha512sums= 2019-12-03 16:39:33 The builders are trying to build snapcast which is already up to date 2019-12-03 16:39:41 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 north1: thanks, 'hawk eye' :) 2019-12-03 17:32:34 _ikke_ (IRC): alright 2019-12-03 17:32:48 mps (IRC): welcome 2019-12-03 17:35:17 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 to remind us where we are :) 2019-12-03 17:38:25 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 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 Sure, ikke 2019-12-03 20:24:54 I think somewhere in the backlog it said something about alpine always using LANG=C.UTF-8, right? 2019-12-03 20:26:20 kpcyrd: it should 2019-12-03 20:28:29 do people care if my patch forces LC_ALL=C in abuild when calling sort? 2019-12-03 20:29:47 I don't know but still think it is better to use C.UTF-8 2019-12-03 20:40:23 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 \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 \o/ 2019-12-03 23:27:27 is there an issue with the main alpine repo on rsync today? 2019-12-03 23:27:57 ( rsync://rsync.alpinelinux.org/alpine/ ) 2019-12-03 23:29:05 or is that better asked in alpine-linux? you guys dont seem to have a mirror channel 2019-12-03 23:37:20 #alpine-infra would probably be the right place 2019-12-04 01:13:27 builders keep trying to build snapcast which is up-to-date 2019-12-04 01:31:29 Confirm, seen that few times whole evening 2019-12-04 05:41:54 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 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 is the the llvm5 fixed 2019-12-04 08:32:59 ncopa: ^ 2019-12-04 08:34:00 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 ah good, then I will push crystal fix in a hour 2019-12-04 08:36:03 fix = workaround, actually :/ 2019-12-04 08:36:03 <_ikke_> not sure why it suddenly just built 2019-12-04 08:36:41 white magic, what else :) 2019-12-04 09:01:21 _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 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 I see 2019-12-04 09:38:57 <_ikke_> it needs to build 36 packages 2019-12-04 09:39:56 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 oh, crystal on x86_64 Invalid memory access (signal 11) at address 0x7ff00bb211d8 2019-12-04 09:41:52 that is, 3.11 2019-12-04 09:42:50 seriously thinking to disable check and build it with llvm8 2019-12-04 09:43:22 would be nice if maintainer comment this idea 2019-12-04 10:40:34 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 _ikke_: thanks 2019-12-04 10:42:16 mps: this "fixed" lllvm5: 8022bb4b09eeb11d7fe081b4dceafc0e7dfa7192 2019-12-04 10:46:15 looks like crystal supportes llvm8 2019-12-04 10:47:58 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 we should porbably try use llvm8 then 2019-12-04 10:48:51 "Removed mips for now"? I didn't think Alpine supported the MIPS target? 2019-12-04 10:48:53 *architecture 2019-12-04 10:49:05 <_ikke_> PureTryOut[m]: someone is working on adding that 2019-12-04 10:49:05 we dont 2019-12-04 10:49:58 Interesting. I did see a lot of patches on the mailing list from "alpine-mips-patches" 2019-12-04 10:50:45 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 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 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 I get that. But the commit message said "for now", suggesting MIPS is wanted 2019-12-04 11:07:26 we probably want mips support yes 2019-12-04 11:07:35 but its not clear if we need llvm5 with mips support 2019-12-04 11:07:49 at this point it means that we dont have crystal or ghc 2019-12-04 11:11:03 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 maybe we also should keep it only on x86_64 2019-12-04 11:12:17 I wonder if ghc works with newer llvm's 2019-12-04 11:12:45 afaik, no 2019-12-04 11:16:17 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 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 wth ocaml failing? 2019-12-04 12:26:38 it looks like it is pulling ocaml-ocamlbuild built with ocaml-4.09 2019-12-04 12:26:47 it = builder 2019-12-04 12:43:09 yes 2019-12-04 12:43:26 seems like building ocamlbuild pulls in ocaml-4.09 2019-12-04 12:43:48 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 which machine? 2019-12-04 14:07:52 <_ikke_> x86_64, I was already on it 2019-12-04 14:07:59 i manually fixed the ocaml issue 2019-12-04 14:08:25 the problem was that ocaml-4.09 was not removed due to the repository was not completely built 2019-12-04 14:08:34 old packages are removed after finished build of repo 2019-12-04 14:08:48 so ocamlbuild pulled in latest ocaml, 4.09 2019-12-04 14:08:57 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 yeah 2019-12-04 14:09:07 <_ikke_> noticed it :) 2019-12-04 14:09:13 where you in there? 2019-12-04 14:09:22 <_ikke_> yes, not actively though 2019-12-04 14:09:28 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 the 32bit builders are done with 3.11 2019-12-04 14:27:47 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 ncopa: hope you will have more luck than I 2019-12-04 14:43:15 it builds on x86_64 2019-12-04 14:43:18 _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 _ikke_: correct, it's package value just as depends and provides 2019-12-04 14:46:01 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 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 I know, but the usage overlap. "Install this package if another package exists" 2019-12-04 14:48:27 more like dependent 2019-12-04 14:48:50 yeah, it's a different way of solving the same problem 2019-12-04 14:49:19 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 _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 _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 _ikke_: thanks, I see 2019-12-04 14:57:20 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 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 to me it sounds like a bit of a stupid usecase, but that's how rpm handles it 2019-12-04 14:59:32 perhaps I've to do a patch that won't be included upstream in apk 2019-12-04 15:02:09 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 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 is Konstantin Kulikov in this channel? 2019-12-04 15:13:54 _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 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 _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 ddevault: yes 2019-12-04 15:19:17 hey kaey 2019-12-04 15:19:24 looking at your prometheus feedback now 2019-12-04 15:19:30 can you tell me more about the output_log and error_log changes you're asking for? 2019-12-04 15:20:08 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 and checkpath 2019-12-04 15:20:53 https://github.com/OpenRC/openrc/blob/master/sh/supervise-daemon.sh#L31 2019-12-04 15:21:09 oh cool 2019-12-04 15:21:11 easy peasy 2019-12-04 15:21:27 thanks for the feedback & assistance 2019-12-04 15:22:12 as for checkpath you can [ -n "$error_log" ] && checkpath and same for output_log 2019-12-04 15:33:37 ddevault: config file should be owned by root 2019-12-04 15:33:59 isn't it? 2019-12-04 15:34:05 it's mode 644 2019-12-04 15:34:15 which matches everything in my conf.d 2019-12-04 15:34:54 ghc-8.8.1 failed on 3.11-x86_64 2019-12-04 15:35:14 8.4.4* 2019-12-04 15:36:01 i mean this line: checkpath -f "$prometheus_config_file" -m 740 -o prometheus:prometheus 2019-12-04 15:36:35 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 hm, this line is weird 2019-12-04 15:37:36 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 ddevault: when you are here, do you plan to upgrade stellarium, or if you don't have time ... 2019-12-04 15:44:07 hm, I guess I wasn't subscribed to its releases 2019-12-04 15:44:09 lemme get on top of that 2019-12-04 15:44:28 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 minor upgrade but looks interesting 2019-12-04 15:45:29 fredrigu: i think that recommends creates more problems than it solves 2019-12-04 15:45:44 mps: seems like crystal fails on aarch64 yes 2019-12-04 15:45:57 ncopa: you might be right. What problems are you worried about? 2019-12-04 15:46:31 yes, it can be built but result is useles, crashes on nearly every invocation 2019-12-04 15:46:46 on x86_64 it works 2019-12-04 15:47:12 the lack of recommends in apk/alpine initially surprised me 2019-12-04 15:47:17 but now I don't really care, it's not that useful imo 2019-12-04 15:49:54 reason I use alpine is this, i.e. minimal dependecies (and no systemd) 2019-12-04 15:56:21 @ncopa can you take a look at this ? https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/11 2019-12-04 15:56:58 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 which are the affected packages? 2019-12-04 16:04:33 do we need to rebuild some packages if we merge it? 2019-12-04 16:04:46 yes, libhandy, webkit2gtk 2019-12-04 16:04:54 any package that has /usr/lib/glade on the mainpkg 2019-12-04 16:05:25 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 https://gitlab.alpinelinux.org/alpine/aports/issues/11010 2019-12-04 16:05:56 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 what about glade itself? 2019-12-04 16:06:30 asdf 2019-12-04 16:06:34 just --amend it before you push? 2019-12-04 16:07:25 ncopa (IRC): libglade doesn't need it 2019-12-04 16:07:42 and what about /usr/lib/glade3? 2019-12-04 16:07:43 actually yes 2019-12-04 16:07:54 libglade won't but the package glade yes 2019-12-04 16:08:03 ddevault: ok 2019-12-04 16:08:07 https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/11 2019-12-04 16:08:10 very confusing that there are 2 different but very similar packages 2019-12-04 16:08:23 sorry, wrong link 2019-12-04 16:08:27 https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fglade*&name=&branch=edge 2019-12-04 16:08:34 thanks mps 2019-12-04 16:09:00 ddevault: np :) 2019-12-04 16:10:39 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 @ncopa Fedora keeps those in libgladeui 2019-12-04 16:11:32 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 after page 3 until page 30 it is only glade and libxfce4ui-dev 2019-12-04 16:13:39 I restricted to /usr/share/glade/catalogs and usr/lib/glade/modules 2019-12-04 16:13:45 seems like what Debian does 2019-12-04 16:14:36 That leaves: libhandy, evolution, glade and libxfce4ui-dev for usr/lib/glade/modules 2019-12-04 16:14:58 can you include link to what debian and fedora does does in the issue? 2019-12-04 16:15:19 and adds: gitg, libpeas, libgweather and gtksourceview4 for usr/share/glade/catalogs 2019-12-04 16:15:22 ncopa (IRC): Sure 2019-12-04 16:17:24 done 2019-12-04 16:18:01 ddevault: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1870 2019-12-04 16:18:24 to test build on CI first 2019-12-04 16:19:18 aside: still working on CI support for lists.sr.ht 2019-12-04 16:19:27 https://github.com/libgit2/pygit2/pull/948 current step 2019-12-04 16:20:01 nice, when you finish this will save us some work and time 2019-12-04 16:20:42 heh, passed cleanly 2019-12-04 16:20:48 <_ikke_> ddevault: wondering, do you have multi-arch support? 2019-12-04 16:21:30 somewhat, but it's not production ready 2019-12-04 16:21:46 debian builds on aarch64+qemu are available 2019-12-04 16:21:46 <_ikke_> ok 2019-12-04 16:21:53 ppc64 hardware has been provisioned 2019-12-04 16:22:26 _ikke_: it is ok to push prometheus straight to community? 2019-12-04 16:23:12 it is useful pkg I know, but ask again because I'm not sure is that ok 2019-12-04 16:23:24 s/it is/is it/ 2019-12-04 16:23:24 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 uhm 2019-12-04 16:23:54 algitbot: ignore me 2019-12-04 16:24:30 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 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 said as much in the v1 patchset 2019-12-04 16:26:10 these packages are imported from my third-party repo 2019-12-04 16:26:14 they've been running in production for a while now 2019-12-04 16:26:19 _ikke_: already passed on out CI 2019-12-04 16:26:36 s/out/our/ 2019-12-04 16:26:36 mps meant to say: _ikke_: already passed on our CI 2019-12-04 16:26:44 I've been meaning to upstream my packages but at my current pace of 0 ACTION need coffee, obviously 2019-12-04 16:27:38 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 from CI? 2019-12-04 16:29:04 <_ikke_> yes 2019-12-04 16:29:15 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 thanks all 2019-12-04 16:31:45 ah, artifacts/download 2019-12-04 16:31:50 <_ikke_> yes, exactly 2019-12-04 16:32:06 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 _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 mps: stellarium patches out 2019-12-04 16:38:12 ddevault: will look after coffee (and one brandy maybe :) ) 2019-12-04 16:41:45 I should put on a pot too 2019-12-04 16:44:02 @ddevault !1871 2019-12-04 16:57:08 @ddevault stellarium is merged 2019-12-04 16:57:20 apparently it didn't went into the patches tab of sr.ht 2019-12-04 16:58:20 north1: thanks, made a note 2019-12-04 17:00:33 ah, north1 was faster than me 2019-12-04 17:04:49 :) 2019-12-04 17:05:14 he is robot :P 2019-12-04 17:05:31 north1: sorry for joke 2019-12-04 17:05:49 isok 2019-12-04 17:06:14 sometimes I think you never sleep 2019-12-04 17:06:44 Sometimes i don't 2019-12-04 17:06:46 sometimes == once a month 2019-12-04 17:07:29 ah :) 2019-12-04 17:08:10 no, joke aside, you probably have good tools 2019-12-04 17:08:36 <_ikke_> and time :) 2019-12-04 17:09:04 yes, time is something which I have less and less 2019-12-04 17:35:34 this !1814 is superseded by ea20a7ddaef1a04c17784a9986ad00d815231f37 I think 2019-12-04 17:36:35 prspkt is not here? 2019-12-04 18:02:17 to late to upgrade gnutls for 3.11? 2019-12-04 22:14:57 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 [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 They even locked the bug report so I guess it's something serious 2019-12-04 22:20:04 void managed to build 71.0 on musl? 2019-12-04 22:24:39 I suppose so 2019-12-04 22:25:55 would be interesting how, I tried on aarch64 but failed 2019-12-04 22:37:28 kernel 5.4.2 is out 2019-12-04 22:40:14 hope ncopa will not forget disable EDAC_DEBUG and enable CONFIG_DM_INTEGRITY as module :) 2019-12-04 23:33:56 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 hope tomorrow it will be ready 2019-12-05 00:39:17 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 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 morning 2019-12-05 07:03:11 its a doublepaste 2019-12-05 07:03:29 Morning 2019-12-05 07:11:41 \o 2019-12-05 07:17:00 ncopa: morning, tagged you on a few old issues about enabling kernel config 2019-12-05 07:19:16 yes, I wrote here last night for 5.4.2 (released) about EDAC_DEBUG and CONFIG_DM_INTEGRITY 2019-12-05 07:19:47 Cogitri: firefox-71.0 running on my aarch64 :) 2019-12-05 07:20:39 !1885 2019-12-05 07:21:31 failed on x86_64 CI, but pass on lxc aarch64 2019-12-05 07:26:09 Nice 2019-12-05 07:26:27 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 (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 ghc-bootastrap is broken 2019-12-05 07:28:31 this commit broke it c40d12ef290bf0c25b033d179a34e32462cd1274 2019-12-05 07:28:44 i think we should not split out the -static, as its needed for bootstrap 2019-12-05 07:32:56 Cogitri: oh, again :( 2019-12-05 07:34:24 on my chromebook usb-c charging is only, no separate charging connector/adapter 2019-12-05 07:38:17 @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 yeah, i dont want rebuild all packages with glade files before 3.11 release 2019-12-05 08:27:31 dont think its worth it 2019-12-05 08:27:48 i better spend time on fixing ghc and kernel 2019-12-05 08:28:39 re kernel config issues, can you please add label C-kernel to those 2019-12-05 08:28:53 so i dont miss them when looking at kernel config 2019-12-05 09:33:18 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 rnalrd, the logic when installing init.d/conf.d here is broken: 653c61b661708b8b92f1d38a3d90cffde6c7eda1 2019-12-05 09:40:32 $ doas rc-update --update 2>&1 | tpaste 2019-12-05 09:40:32 http://tpaste.us/gkZb 2019-12-05 09:42:15 ncopa: ill do when I sweep old issues again 2019-12-05 09:42:47 it installs the iscsi.conf into /etc/conf.d/ 2019-12-05 10:04:32 thanks 2019-12-05 10:31:43 <_ikke_> ncopa: nice find re ghc 2019-12-05 11:18:28 _ikke_: im fixing the build-3-11-x86_64 now 2019-12-05 11:18:31 with ghc 2019-12-05 11:22:09 is there any timetable regarding the 3.11 release? 2019-12-05 11:22:23 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 i need move linux-lts to main 2019-12-05 11:28:28 fix ghc build 2019-12-05 11:28:41 fix rpi4 support 2019-12-05 11:28:55 <_ikke_> ncopa: I guess crystal still depends on llvm5? 2019-12-05 11:29:02 nmeum: jirutka posted a patch, which i dont think solve your issue 2019-12-05 11:29:09 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 im interested in that 2019-12-05 11:30:12 there is a PR for ghc upgrade, but it is missint a patch for fixing testsuite 2019-12-05 11:30:30 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 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 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 _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 nmeum: yeah, i can reproduce it 2019-12-05 11:31:56 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 or at least "more reproducible" 2019-12-05 11:32:09 i dont know why he needs to make unbound the owner of the socket dir 2019-12-05 11:32:17 I don't get it either 2019-12-05 11:32:41 he is making the startup logic unessecarly more complicated than it needs to be 2019-12-05 11:34:31 nmeum: feel free to reopen the issue 2019-12-05 11:34:51 will test it first and repoen it then 2019-12-05 11:34:52 ) 2019-12-05 11:35:09 gimme a sec 2019-12-05 11:40:29 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 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 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 bummer 2019-12-05 11:44:52 I use a local staging branch with changes I want to push after the release 2019-12-05 11:46:39 hehe 2019-12-05 11:46:42 that is intentional 2019-12-05 11:46:53 so we all focus on getting the release out 2019-12-05 11:47:18 nmeum: looks like also nsd may suffer from same problem 2019-12-05 11:47:30 yes it does 2019-12-05 11:48:17 should probably be fixed before 3.11 is released 2019-12-05 12:03:13 _ikke_: ncopa: crystal built with llvm8 on aarch64 is useles, it doesn't work 2019-12-05 12:04:04 upstream actually recommends using llvm8 though https://crystal-lang.org/install/from_sources/ 2019-12-05 12:04:09 > 2019-12-05 12:04:09 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 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 nmeum: it builds with llvm8 and works on x86_64 2019-12-05 12:05:09 ah 2019-12-05 12:05:21 it builds on aarch64 with llvm8 but doesn't work 2019-12-05 12:06:38 nmeum: !508 2019-12-05 12:08:45 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 but must add, crystal on aarch64 built with llvm5 works fine 2019-12-05 12:09:59 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 *only 2019-12-05 12:10:13 +1 2019-12-05 12:10:22 i think we have ghc fixed 2019-12-05 12:10:28 so its only crystal left 2019-12-05 12:10:45 crystal builds with llvm8 on x86_64 but not aarch64 2019-12-05 12:10:48 ball is in your hands 2019-12-05 12:11:31 i sent the ball to the maintainer: https://gitlab.alpinelinux.org/alpine/aports/issues/11017 2019-12-05 12:13:04 also we will have to remove shards, ameba and oq, pkgs depends on crystal 2019-12-05 12:13:43 s/remove/disable on aarch64/ 2019-12-05 12:13:43 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 yeah 2019-12-05 12:14:18 i think it may we worth it 2019-12-05 12:14:31 lets do ghc first and see how that goes 2019-12-05 12:14:45 (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 with j0wi's patch? 2019-12-05 12:15:23 <_ikke_> not yet 2019-12-05 12:15:36 im building it with j0wi's patches 2019-12-05 12:15:42 <_ikke_> ok 2019-12-05 12:15:53 im hopeful 2019-12-05 12:17:25 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 I have a fix for ocaml-lablgtk, should allow us to build unison again 2019-12-05 12:36:58 now unison itself fails, nice 2019-12-05 12:38:54 <_ikke_> hah 2019-12-05 12:39:09 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 yes 2019-12-05 12:40:45 not sure how easy it will be to backport the neccessary changes though 2019-12-05 12:47:08 backported the compatibility commit linked in the github issue above 2019-12-05 12:47:27 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 (i don't speak ocaml) 2019-12-05 12:54:48 i think lablgtk2 needs to be rebuilt with ocaml 4.08 2019-12-05 12:54:53 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 i was about to tart with the linux-lts now 2019-12-05 12:55:12 ncopa: looks like it, with the rebuild unison builds fine https://gitlab.alpinelinux.org/nmeum/aports/pipelines/3219 2019-12-05 12:55:24 will merge my unison fix in a sec 2019-12-05 12:55:46 ocaml likes all packages compiled against the same compiler 2019-12-05 12:55:58 well, that's annoying 2019-12-05 12:56:56 mps: looks like im gonna be busy with some other things for another hour or so 2019-12-05 12:58:37 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 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 I prefer that it fails instead of silently succeeding 2019-12-05 13:23:07 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 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 nmeum: How would we enable a package once a dep becomes available then though? 2019-12-05 13:25:26 Should abuild scan the entire tree on every build to check that? 2019-12-05 13:27:30 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 _ikke_: lots of test failures 2019-12-05 13:49:35 i agree with north1, but we should have better tools to detect and deal with it 2019-12-05 13:51:12 Can probably be added to atools 2019-12-05 13:51:54 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 *sören 2019-12-05 13:54:01 nmeum: sorry, I have to learn to use ö in mey keyboard 2019-12-05 13:54:18 (: np 2019-12-05 14:00:26 mesa 19.2.7 is gonna be lit 2019-12-05 14:01:14 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 i have no clue how to use lua-aports 2019-12-05 14:02:53 :D you know atools and lua-aports 2019-12-05 14:02:58 <_ikke_> yup 2019-12-05 14:03:08 _ikke_: knows all 2019-12-05 14:03:15 he even knows what im about to type 2019-12-05 14:05:34 <_ikke_> gmta 2019-12-05 14:13:37 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 isnt that discussed already? 2019-12-05 14:14:17 lts would not ship armhf, only with rpi images/kernels 2019-12-05 14:15:47 ok 2019-12-05 14:16:38 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 or, didn't tested but maybe armv7 kernel could work for them 2019-12-05 14:18:08 _ikke_: probably build it cross 2019-12-05 14:18:28 or else on armv6 hw :) 2019-12-05 14:18:44 or like we do on faster 2019-12-05 14:19:27 armv6 are mostly small devices, you probably dont want our large multipurpose kernel. 2019-12-05 14:47:53 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 (uhm, my x86_64/x86 builder is fast like a snail) 2019-12-05 15:37:30 telmich: install media? 2019-12-05 15:38:16 if you are usure, create an issue in aports tracker. 2019-12-05 15:38:22 we can move it later if needed. 2019-12-05 16:12:27 mps: do you have patch for kernel upgrade? 2019-12-05 16:12:45 otherwise I'll update it myself, and move it to main 2019-12-05 16:12:59 and apply the other changes 2019-12-05 16:16:15 I have diff but not yet finished with -virt.x86_64, building I mean to if it works 2019-12-05 16:17:03 tested on armv7 and aarch64, looks ok 2019-12-05 16:17:44 git diff | tpaste 2019-12-05 16:18:18 or: git commit && git format-patch -1 | tpaste 2019-12-05 16:19:12 http://tpaste.us/8XbK 2019-12-05 16:19:23 format-patch 2019-12-05 16:20:17 look at CMA addition, I set default values, if you think this is not ok, remove or change 2019-12-05 16:21:28 anyway you will probably have to tweak some things according your preferences 2019-12-05 17:04:45 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 good evening 2019-12-05 17:05:47 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 Context: https://gitlab.alpinelinux.org/alpine/aports/issues/10937 2019-12-05 17:06:09 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 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 telmich: heh, remember time when built it on 4MB (MB, really) and put it to work overnight :) 2019-12-05 17:11:14 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 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 ...reminds me of the really bad 2.5 times 2019-12-05 17:24:00 every 2nd kernel was roughly broken 2019-12-05 17:26:47 and now is much difference ? :) 2019-12-05 17:28:32 maybe every 10th to 15th now :-) 2019-12-05 17:32:52 well, -rc's kernel can make a real mess 2019-12-05 18:07:55 one thing I've seen on multiple notebooks now is that syslinux with efi hangs at boot 2019-12-05 18:08:07 replacing it with grub-efi works w/o any problems though 2019-12-05 18:09:17 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 telmich: if you boot install media on efi enabled machine it will by default install grub-efi 2019-12-05 18:11:42 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 Because I did apk add it later and it was not installed; neither was efibootmgr 2019-12-05 18:12:16 maybe not fully functional efi on machine 2019-12-05 18:12:34 it did have efivars and efibootmgr did show the regular output 2019-12-05 18:12:54 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 in a last few installation I always got grub-efi 2019-12-05 18:14:04 even in qemu if efi.fd file is given as -bios parameter 2019-12-05 18:14:10 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 I have one such, has efi in bios but didn't worked, 5 or more years old notebook 2019-12-05 18:16:03 but another one bought at the same time efi works 'out of the box' 2019-12-05 18:16:58 also one old macbook (about 2012/2014) efi worked, alpine install 2019-12-05 19:26:52 If you boot with EFI installer will use grub efi 2019-12-05 19:29:21 clandmeter: yes, that is my experience 2019-12-05 19:32:38 I added it so I'm kind of sure it works like that ;) 2019-12-05 19:33:28 I remember :) 2019-12-05 19:50:44 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 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 rp_filter is in kernel for reason 2019-12-05 20:33:56 fassl: thanks, I would prefer it to be in default installer on alpine 2019-12-05 20:35:03 the installer being setup-alpine? 2019-12-05 20:35:10 yes 2019-12-05 20:36:19 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 yep, i would prefer that as well 2019-12-05 21:44:15 mps: I think you can set swap size for installer 2019-12-05 21:44:28 export SWAP_SIZE=.... 2019-12-05 21:44:30 or similar 2019-12-05 21:46:35 ncopa: reminds me, there is no way to set the size of root fs on lvm? 2019-12-05 21:52:05 seems so yes 2019-12-05 21:52:24 100%FREE is hardcoded 2019-12-05 21:52:30 but thats esy to fix 2019-12-05 21:52:38 i guess a custom setup-disk is needed for now. 2019-12-05 21:53:04 I can change it to ${ROOTFS_SIZE:-100%FREE} 2019-12-05 21:53:37 ok, i guess thats used for normal partitions? 2019-12-05 21:56:06 http://tpaste.us/6VEB 2019-12-05 21:56:14 for lvcreate 2019-12-05 21:56:24 yes i know the hardcoded part 2019-12-05 21:56:38 i bumped into it :) 2019-12-05 21:58:43 export SWAP_SIZE=... before starting setup-alpine? 2019-12-05 21:59:06 yes 2019-12-05 21:59:12 looks like its MB 2019-12-05 21:59:29 export SWAP_SIZE=0 ? no swap? 2019-12-05 21:59:35 correct 2019-12-05 22:00:35 aha, waiting for ${ROOTFS_SIZE:xxG} :) 2019-12-05 22:01:26 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 nice 2019-12-05 22:01:40 i didnt have tim to look at you patch 2019-12-05 22:01:49 will do it tomorrow morning 2019-12-05 22:01:50 sorry 2019-12-05 22:02:26 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 on the other had, my contract with Docker was terminated today 2019-12-05 22:02:49 and I signed a contract with Mirantis 2019-12-05 22:02:55 no need to sorry, better to have it in good shape than fast 2019-12-05 22:03:07 congrats 2019-12-05 22:03:15 thanks! 2019-12-05 22:03:24 when do i receive cake? 2019-12-05 22:03:26 Mirantis? first time hear for this 2019-12-05 22:03:44 i have the wine already from mps :) 2019-12-05 22:05:27 https://www.mirantis.com/ ? 2019-12-05 22:05:30 mps: its the company that bought the commercial side of docker 2019-12-05 22:05:58 oh, so alpine goes commercial :D 2019-12-05 22:06:20 docker was already commerial 2019-12-05 22:06:34 nothing changes regading that part. 2019-12-05 22:07:46 clandmeter: did you notice ':D' in my msg 2019-12-05 22:08:38 joke aside, congrats ncopa :) 2019-12-05 22:23:24 thanks 2019-12-05 22:23:28 and good night! 2019-12-05 22:31:00 \o 2019-12-05 22:59:32 Filed security upgrade for putty !1911 maybe move it to community? 2019-12-05 23:00:51 there are more candidates to move from main to community, imo 2019-12-05 23:01:13 but maybe after 3.11 release 2019-12-06 04:40:40 does swish-e even build 2019-12-06 04:41:00 it is making entirely bogus call to zlib uncompress2() 2019-12-06 04:41:09 perhaps this is a shadowing issue 2019-12-06 04:42:03 yes, it is 2019-12-06 04:49:47 ...this package needs some love 2019-12-06 04:49:56 it does not build with system expat library 2019-12-06 04:56:31 http://tpaste.us/9Nb0 2019-12-06 04:56:34 somebody apply this 2019-12-06 05:11:48 Is it urgent? 2019-12-06 05:17:40 i mean, right now the package fails to build 2019-12-06 05:19:34 Blocking the builders? 2019-12-06 05:20:10 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 north1: no, because the package has not been rebuilt in years 2019-12-06 05:21:24 north1: it does block anyone trying to rebuild alpine from scratch 2019-12-06 05:21:51 kaniini: I'll take a look in a few hours 2019-12-06 05:22:11 okay 2019-12-06 05:22:13 that is cool 2019-12-06 05:23:35 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 alternatively we could just drop swish-e 2019-12-06 05:23:46 i really do not care what we do 2019-12-06 05:29:54 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 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 for x86 and ppc64 it is no problem for me to do this 2019-12-06 05:54:56 kaniini: I do something like that once a month for void 2019-12-06 05:55:08 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 Fails To Build From Source 2019-12-06 06:00:09 finally i am fixing an FTBFS that has to do with mips64 again. 2019-12-06 07:16:44 aight i'm back 2019-12-06 07:17:40 Need testers for the new stuff and the removed stuff on mesa !1898 2019-12-06 07:52:17 north1: removal of gles1 sounds scary at this point 2019-12-06 07:52:22 is there not anything that uses it? 2019-12-06 07:52:53 Both fedora and arch remove it and everything o saw including raspis use gles2 2019-12-06 07:56:22 $ apk search --exact --quiet --origin --rdepend so:libGLESv1_CM.so.1 | sort -u | tpaste 2019-12-06 07:56:22 http://tpaste.us/Xg0l 2019-12-06 07:56:28 those needs to be rebuilt 2019-12-06 08:00:31 Need to remove those that match so:libGLESv2 2019-12-06 08:00:45 wlroots only links to libGLESv2 2019-12-06 08:02:03 i may have some old index or old packages locally 2019-12-06 08:02:25 wlc , weston, wayfire and mutter as well 2019-12-06 08:02:36 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 and we can clean up testing afterwards 2019-12-06 08:02:56 testing repo has lower prio til 3.11 is out 2019-12-06 08:06:28 ok, i did apk info --depends on each one of them and none showed libGLESv1_CM.so.1 2019-12-06 08:06:32 only libGLESv2.so.1 2019-12-06 08:07:39 http://ix.io/23FA 2019-12-06 08:16:03 ok, i gues you can push it then 2019-12-06 08:16:54 It also has other minor changes 2019-12-06 08:20:13 mps: i'm building the 5.4.2 kernel now 2019-12-06 08:20:43 i need to be afk most of today, but i'll try to push it later today 2019-12-06 08:20:55 just need to make sure it builds and boots (in qemu) 2019-12-06 08:21:53 I tested x86_64, aarch64, and one armv7. boots ok and work 2019-12-06 08:22:36 armv7 will need other tweaks, but not urgent now 2019-12-06 08:52:07 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 if I finish setting my old/new building box I will check more options 2019-12-06 09:07:42 (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 hmm, linux-vanilla and linux-lts for armv7 'conflicts' on /boot/dtbs files 2019-12-06 10:21:36 we need separate dirs for them, or versioned dtbs-'uname -r' 2019-12-06 11:12:44 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 Alrighty, thanks 2019-12-06 12:13:12 Cogitri: iio-sensor-proxy depends on gtk? 2019-12-06 12:13:32 i.e. could it be built without gtk 2019-12-06 12:14:40 It only needs gtk for its tests, it doesn't depend on it during runtime 2019-12-06 12:14:56 But I can't add it to checkdepends because it's always checking for it :) 2019-12-06 12:15:10 aha, thanks. np 2019-12-06 12:16:08 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 Uhh...is `arch=noarch !s390x` valid? 2019-12-06 12:16:29 (don't mind the missing quotes) 2019-12-06 12:17:05 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 there are packages with such arch var 2019-12-06 12:18:10 though, I'm not sure 2019-12-06 12:19:41 I think it’s valid 2019-12-06 12:20:29 Hm, good to know, I always changed `noarch` to `all !$failingArch` because I thought it's invalid 2019-12-06 12:21:25 makes sense if arch is 'noarch' but pkg don't need to be in '!arch' 2019-12-06 12:22:09 Some of the reps may be arch dependent 2019-12-06 12:22:18 deps 2019-12-06 12:23:07 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 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 Okie. Thanks for the info 2019-12-06 12:30:58 Cogitri: yes, rust failed on CI for firefox but worked on lxc 2019-12-06 12:31:13 SIGSEGV? 2019-12-06 12:31:55 I forgot, there is log on gitlab.a.o for firefox-71.0 2019-12-06 12:32:05 not now at workstation 2019-12-06 12:33:22 Okie, will take a look later 2019-12-06 12:34:18 I'm preparing x86_64 builder locally, need some eth cables and set another switch 2019-12-06 12:35:43 Nice, gtk4 fails to build on x86 because it runs out of VMEM 2019-12-06 12:36:12 heh, and it is not written in rust 2019-12-06 12:36:33 I think we've mostly hit that limitation with big CPP stuff as of now :P 2019-12-06 12:37:11 C++ :( 2019-12-06 13:12:45 mps: correct 2019-12-06 13:19:16 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 I'm asking to fix /boot/dtbs if the user wants to install different kernels 2019-12-06 13:25:07 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 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 ok, it is not important now how it will be called 2019-12-06 13:28:19 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 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 then we cannot have /boot/dtbs in both 2019-12-06 13:30:03 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 maybe /boot/dtbs-lts and /boot/dtbs-xyz, xyz is the name of the other kernel 2019-12-06 13:30:53 kernel flavour, I mean 2019-12-06 13:31:25 im also thinking we may want be able to have different configs, like -virt and -lts 2019-12-06 13:31:41 and maybe -server and -desktop or similar 2019-12-06 13:31:53 I don't see much of a point in that tbh 2019-12-06 13:32:19 or -debug 2019-12-06 13:32:20 -lowlatency ;) 2019-12-06 13:32:29 Sounds like a lot of maintenance effort only to save a few MB on a server 2019-12-06 13:32:35 we don't have resources (for now at least) for many kernels 2019-12-06 13:32:42 yes and yes 2019-12-06 13:32:48 And if you need to debug a kernel you're most likely better of building it yourself anyway 2019-12-06 13:32:58 Cogitri: +1 2019-12-06 13:33:03 but i think it would be useful to be able to install different kernels at the same time 2019-12-06 13:33:10 and for rest of pkgs :) 2019-12-06 13:33:13 Yes. Very much so 2019-12-06 13:33:29 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 so i think it makes sense to fix the /boot/dtbs problem 2019-12-06 13:33:41 meant for Cogitri 'for rest of pkgs :)' 2019-12-06 13:33:44 Yup 2019-12-06 13:34:01 now we can have vanilla and lts 2019-12-06 13:34:07 works fine 2019-12-06 13:34:36 both installed at same time and selectable at boot time 2019-12-06 13:35:18 Yup, just that I'd like to have -vanilla be -current 2019-12-06 13:35:38 could maybe even be in testing repo 2019-12-06 13:35:57 Hm, I'd like to use it in 3.12 actually on my NAS 2019-12-06 13:36:05 testing sounds better for evolving kernels 2019-12-06 13:36:11 (Which currently still runs edge for a dew pkgs) 2019-12-06 13:36:27 Hm, I wouldn't call linux-current evolving 2019-12-06 13:37:00 if we have it in community we´ll have to backport sec fixes 2019-12-06 13:37:01 well, current is not good name, imo 2019-12-06 13:37:18 yes 2019-12-06 13:37:29 ncopa: Oh right, didn't consider that 2019-12-06 13:37:33 Testing sounds good to me then :P 2019-12-06 13:37:35 testing looks better place 2019-12-06 13:38:08 we will have -lts in main and 'whatever' in testing 2019-12-06 13:38:19 Yup 2019-12-06 13:38:29 for now this looks best we can do for now 2019-12-06 13:38:33 What kernel modules are we going to build for it? Wireguard & ZFS? 2019-12-06 13:38:45 2 times 'for now' :) 2019-12-06 13:38:46 <_ikke_> gtk4.0 is current failing 2019-12-06 13:39:01 Yes, looking into it 2019-12-06 13:39:11 ^ 2019-12-06 13:39:13 Cogitri: yes, and sdfat, dahdi ... 2019-12-06 13:39:24 <_ikke_> ah, missed that 2019-12-06 13:39:29 something called 'jool...' 2019-12-06 13:39:46 i´d prefer note have any 3rd party modules if possible 2019-12-06 13:40:29 but you wouldn't drop them without thinking, I think 2019-12-06 13:40:31 but then we´d probably need dkms or similar 2019-12-06 13:40:47 Yup, then we'd need dkms which is kind of a pain too 2019-12-06 13:40:57 And without zfs the kernel would be kind of useless to me at least 2019-12-06 13:41:40 so i dont think dropping all 3rd party modules is possible 2019-12-06 13:41:49 Yup 2019-12-06 13:42:05 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 i think wireguard will be upstreamed soonish 2019-12-06 13:43:08 Nice 2019-12-06 13:43:10 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 zinc is already in 5.5, iirc 2019-12-06 13:43:43 Another unrelated thing: What CFLAGS do we use on the builders? 2019-12-06 13:44:10 -Os 2019-12-06 13:44:18 Just -Os? 2019-12-06 13:44:24 possible some also has -fomit-frame-pointer 2019-12-06 13:44:29 to go to original question, should we keep '/boot/dtbs' for -lts? 2019-12-06 13:44:41 or /boot/dtbs-lts 2019-12-06 13:44:47 No stack protection/clash protection/FORTIFY_SOURCE ? 2019-12-06 13:45:05 mps: i think the latter makes sense 2019-12-06 13:45:16 agree 2019-12-06 13:45:20 Cogitri: that is handled by kernel config 2019-12-06 13:45:32 it is clear from the name what is there 2019-12-06 13:45:33 I mean for all packages not just the kernel 2019-12-06 13:45:45 at least ssp and FORTIFY_SOURCE is a libc thing 2019-12-06 13:45:51 and kernel does not link to libc 2019-12-06 13:46:27 i think there is some sort of SSP in kernel, but that is enabled/disabled with kernel config 2019-12-06 13:46:33 same with fortify source 2019-12-06 13:46:51 clash protection i dont know 2019-12-06 13:47:16 'always enable Stack Smashing Protector' 2019-12-06 13:47:29 Yes, but I was talking about all packages, not just the kernel 2019-12-06 13:47:37 ah 2019-12-06 13:48:01 So we're building all packages with stack- protection, SSP and stack clashing protection? 2019-12-06 13:48:01 yes, we have SSP and fortify enabled by default 2019-12-06 13:48:08 yes 2019-12-06 13:48:13 Good 2019-12-06 13:48:15 stack-protector-strong 2019-12-06 13:48:23 not stack-protector-all 2019-12-06 13:48:37 Yes, -all is too expensive 2019-12-06 13:48:41 Also stack-clash-protection ? 2019-12-06 13:48:48 which enables SSP in places where its useless 2019-12-06 13:49:21 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 i dont think we have it 2019-12-06 13:49:38 first time i hear about it 2019-12-06 13:50:08 ssp, fortify and PIE are enabled by default in our toolchain 2019-12-06 13:50:14 and not via CFLAGS 2019-12-06 13:50:49 you need to explicitly disable it if you dont want it 2019-12-06 13:50:57 Alrighty, great 2019-12-06 13:51:06 We should really consider stack-clash-protection though 2019-12-06 13:51:24 sounds like we should, yes 2019-12-06 13:51:32 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 (And yes, although that's systemd it's still super useful for other packages :P) 2019-12-06 13:52:15 Cogitri: please, don't 2019-12-06 13:52:41 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 ERROR: unsatisfiable constraints: 2019-12-06 13:55:53 so:libvirglrenderer.so.0 (missing): 2019-12-06 13:55:53 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 looks like it was introduced with bc7ca99b460459d57124a56d8fa82ccafd5969a3 2019-12-06 14:00:38 and it seems that it is only qemu that needs rebuild 2019-12-06 14:11:17 kaniini: you got your push access back. welcome back! 2019-12-06 14:18:51 nice :) 2019-12-06 14:20:55 i pushed linux-lts update and move to main 2019-12-06 14:22:06 ok, now is time again for testing 2019-12-06 14:22:07 Nice 2019-12-06 14:41:41 ncopa: can we include wireguard in the rpi modloop? 2019-12-06 14:48:26 ncopa: it would also be nice to have an aarch64 iso included. 2019-12-06 15:32:08 i think we need move wireguard to main in that case 2019-12-06 15:33:56 wow! 3.11 builders are done! 2019-12-06 15:34:30 <_ikke_> \o/\o/\o/ 2019-12-06 15:37:42 looks like dl-cdn.alpinelinux.org is not synced for some time 2019-12-06 15:38:21 last-updated 06-Dec-2019 15:00 11 2019-12-06 15:39:09 <_ikke_> 40 minutes ago? 2019-12-06 15:39:28 hmm, I don't see pkgs built last night on my aarch64 2019-12-06 15:41:53 i think the last updated only gets updated on the hour 2019-12-06 15:42:09 and t1 mirror is synced every 15min 2019-12-06 15:44:53 ok, will check in hour and see 2019-12-06 16:04:33 do we still need dahdi-linux kernel module? 2019-12-06 16:05:07 dunno, maybe fabled uses it? 2019-12-06 16:05:13 thats asterisk right? 2019-12-06 16:05:34 its a driver for an ISDN card that asterisk uses, yes 2019-12-06 16:41:43 it would be nice to keep 2019-12-06 16:42:11 however in practice I don't think many use digium isdn cards anymore 2019-12-06 17:15:39 nice, linux-lts is now default 2019-12-06 17:16:34 and we got ROOT_SIZE 2019-12-06 17:27:18 after 3.11 rc1 will the main and community be rebuilt again before 3.11 final release? 2019-12-06 17:28:39 no 2019-12-06 17:28:57 we just fix the things that needs to be fixed and ship the release 2019-12-06 17:29:15 ah, then upgrade linux-headers to 5.4 doesn't make sense 2019-12-06 17:29:29 correct 2019-12-06 17:29:35 thanks 2019-12-06 17:34:51 clandmeter: what do you think about an aarch64 virt iso image? 2019-12-06 17:35:19 or were you thinking standard 2019-12-06 17:43:55 what do we need for making a release with rpi4? 2019-12-06 18:32:45 hah, I think I have one sangoma card in garage :) 2019-12-06 18:33:21 and, no, I don't use it for years 2019-12-06 18:33:50 ok 2019-12-06 18:33:55 i think im ready for an rc1 2019-12-06 18:34:38 ok, I'm too tired to fix reboot and poweroff for some armv7 boards 2019-12-06 18:34:52 maybe tomorrow 2019-12-06 18:36:08 ok here we go.... 2019-12-06 19:00:06 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 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 community is still in progress and hovering around 82% 2019-12-06 20:55:28 nice 2019-12-06 21:43:18 @maldridge I have made an MR and tagged you, it includes fixes to your previous MR 2019-12-06 21:46:50 _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 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 i mean line 41 2019-12-06 21:49:10 <_ikke_> ugh, debug statement I mistakenly left :-/ 2019-12-06 21:49:16 :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 because it cant scroll any further down? 2019-12-06 21:51:19 <_ikke_> hmm, good point 2019-12-06 21:52:52 no worries, its weekend :) 2019-12-06 21:53:05 <_ikke_> :) 2019-12-06 21:53:08 hihi, I was fooled by that before, too 2019-12-06 21:53:47 by the weekend? 2019-12-06 22:26:05 3.11 rc1 is out 2019-12-06 22:26:56 nice 2019-12-06 22:29:19 3.11-stable is not branched out yet, yeah ? 2019-12-06 22:49:26 clandmeter: never! but often by holidays - they are really tricky, when one works independently of them 2019-12-06 22:52:25 north1: a link would be nice 2019-12-06 22:52:38 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1965 2019-12-06 22:53:33 ddevault (IRC): opinion on https://lists.alpinelinux.org/~alpine/aports/patches/3159 ? 2019-12-06 22:53:56 +1 2019-12-06 22:54:36 aight, gonna merge 2019-12-06 22:57:20 @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 oh, they sent v2 to the same thread 2019-12-06 23:04:19 that's discouraged, and it doesn't handle it well 2019-12-06 23:04:24 So user mistake ? 2019-12-06 23:04:24 try this: https://lists.alpinelinux.org/~alpine/aports/%3C20191206225118.19415-1-galen%40galenabell.com%3E/raw 2019-12-06 23:04:30 well, the software ought to handle it better 2019-12-06 23:04:34 Yes i did that but it required me to leave the commandline 2019-12-06 23:04:36 but yeah, that's not how v2's should be sent 2019-12-06 23:04:39 ^ i don't like that 2019-12-06 23:04:58 ack, neither do I 2019-12-06 23:05:02 I've hit this before too 2019-12-06 23:32:23 v3.11 rc1/etc/update-extlinux.conf:# default# default kernel to bootdefault=vanilla 2019-12-06 23:32:31 should be lts, right? 2019-12-06 23:56:26 right, need fix 2019-12-07 00:16:20 @maldridge it is in main 2019-12-07 00:19:52 north1: cool thnx 2019-12-07 11:59:14 <_ikke_> xmrig is stuck again on aarch64 2019-12-07 13:20:38 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 gnupg? 2019-12-07 13:27:37 or does that come with it's own impl of pinentry? unsure 2019-12-07 13:28:18 yeah, it does depend on it. 2019-12-07 13:32:15 Seems `gnupg`, `gcr` and `gnupg1` 2019-12-07 13:32:47 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 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 I'll just make a MR then and people can comment on there 2019-12-07 13:57:43 i don't think you can move gnupg from main to community 2019-12-07 13:59:11 Hmm there are several packages that depend on gnupg in main... 2019-12-07 14:11:15 yes, gtk should go to community, if possible 2019-12-07 14:12:07 PureTryOut[m]: you can create separate pinentry-qt pkg 2019-12-07 14:12:59 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 (when installing e.g. gnupg) 2019-12-07 14:16:01 gnupg should stay in main and qt (and gtk) should be in community 2019-12-07 14:18:54 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 yes, it is ugly I agree, but doubt that we have better solution 2019-12-07 14:58:52 What about this then? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1982 2019-12-07 14:58:55 Basically what you said 2019-12-07 15:04:45 Btw the aarch64 Gitlab CI runner is down 2019-12-07 15:05:43 <_ikke_> let me check 2019-12-07 15:18:17 PureTryOut[m]: disabling gtk/gnome for pinentry in main sound reasonable, imo 2019-12-07 15:19:35 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 Nice 2019-12-07 15:39:34 Let's please not disable gtk/gnome for pinentry 2019-12-07 15:39:47 Unless you move that out to a seperate package in community 2019-12-07 15:40:00 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 Alrighty, good 2019-12-07 15:56:26 hm, isn't text mode also 'ui' 2019-12-07 15:57:19 I guess, but then the regular pinentry package would be empty 😛 Idk what else to call it 2019-12-07 15:57:49 just 'pinentry' 2019-12-07 15:58:30 Wouldn't it then conflict with pinentry in main? 2019-12-07 15:58:55 yes, I thought you are talking about pkg in main 2019-12-07 16:00:06 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 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 that's what I think, if possible 2019-12-07 16:25:18 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 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 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 I looked in git log 2019-12-07 16:53:39 most changes is done by BFDL 2019-12-07 16:53:47 <_ikke_> :) 2019-12-07 16:53:52 BDFL* 2019-12-07 16:54:36 ok, will wait till monday to ask to make some changes for arm images 2019-12-07 17:19:07 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 samu is simpler, written in C instead of C++, and has maintainership which is not hostile to distros 2019-12-07 17:19:30 (ninja refuses to add an environment variable for -j, samu already has one) 2019-12-07 17:19:59 (I'm more for samu/rai folklore :) ) 2019-12-07 17:20:34 (hagakure) 2019-12-07 17:32:25 ddevault (IRC): I packaged samurai for Exherbo and Void Linux and yes 2019-12-07 17:32:33 i planned on pushing for replacing it eventually 2019-12-07 17:32:58 sent email to the ml 2019-12-07 17:33:19 shit, bunged it up 2019-12-07 17:38:06 https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E 2019-12-07 19:12:17 ddevault: just read your mail, +1 for samu (you know why I dislike to reply to ML ;) ) 2019-12-07 20:19:34 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 aye 2019-12-07 20:19:59 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 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 (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 ddevault: i think it is a good idea 2019-12-07 20:21:37 i wish somebody would write an alternative to meson, as well 2019-12-07 20:21:39 I also think it is a good idea 2019-12-07 20:21:43 agreed wrt meson 2019-12-07 20:21:49 mostly because, well 2019-12-07 20:21:57 but I don't think it'll need reimplementing, but just serve as inspiration for the next generation 2019-12-07 20:22:01 while meson is better than autotools, ummmmmmmmm 2019-12-07 20:22:12 meson's maintainers are well :) 2019-12-07 20:22:43 you have to consider dependencies as well, in that sense is meson still better than autotools? 2019-12-07 20:22:49 i wish that there were some tool that could just take meson build files and handle everything transparently 2019-12-07 20:22:50 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 tehcloud: yes 2019-12-07 20:23:14 tehcloud: i have been doing autotools since 2000, but i know more about ninja 2019-12-07 20:23:16 erf 2019-12-07 20:23:17 meson 2019-12-07 20:23:30 don't get me started on cmake 2019-12-07 20:23:36 meson is far, far, far more transparent than autotools 2019-12-07 20:24:02 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 I hate Python 2019-12-07 20:24:17 and it's written in python so i can't just switch pkgconf over to it 2019-12-07 20:24:22 I don't hate Python but I agree that it's completely wrong for a build system 2019-12-07 20:24:27 because you need pkgconf far earlier than you need python 2019-12-07 20:24:35 and you need pkgconf to build python 2019-12-07 20:24:40 can't pkgconf just use make? 2019-12-07 20:24:44 yes 2019-12-07 20:24:56 i am thinking about 2019-12-07 20:25:00 just using make 2019-12-07 20:25:11 and letting the microsoft people have a visual studio solution 2019-12-07 20:25:14 you might also take a look at the POSIX 'build system' I wrote for mrsh 2019-12-07 20:25:17 which is what was originally how it went 2019-12-07 20:25:21 which just involved POSIX shell scripts which spit out some Makefiles 2019-12-07 20:25:34 https://git.sr.ht/~emersion/mrsh 2019-12-07 20:25:41 see configure script 2019-12-07 20:25:53 but for audacious, meson has been great 2019-12-07 20:26:08 we can build windows and mac binaries that are correctly bundled 2019-12-07 20:26:20 and on posix it is same as using autotools 2019-12-07 20:26:32 wlroots uses meson, and I overhauled monado (OpenXR) to use it too 2019-12-07 20:26:44 it's a clear winner over cmake or autotools 2019-12-07 20:26:54 despite living far too high in the stack 2019-12-07 20:26:55 well 2019-12-07 20:27:18 cmake was originally created by a US government contractor 2019-12-07 20:27:26 and it shows in the whole mentality of how the tool is designed 2019-12-07 20:27:44 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 cmake may be the actual antichrist 2019-12-07 20:28:39 glad to see nobody saying anything good about cmake 2019-12-07 20:29:39 incidentally 2019-12-07 20:29:48 ddevault: are you still interested in riscv64 alpine 2019-12-07 20:29:56 yes, but it's blocked by u-Boot quality issues 2019-12-07 20:30:13 huh? 2019-12-07 20:30:16 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 there is no bootm? 2019-12-07 20:30:44 the issue is that the uboot port doesn't have an mmc driver 2019-12-07 20:30:51 I could netboot but I don't want to 2019-12-07 20:30:55 humm 2019-12-07 20:31:05 on octeon, they just do not support bootm at all 2019-12-07 20:31:09 an mmc driver exists for the kernel 2019-12-07 20:31:11 instead there is bootoctlinux 2019-12-07 20:31:13 in theory a marriage is possible 2019-12-07 20:31:19 but it's not a priority for me atm 2019-12-07 20:31:35 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 so you just create a memory region named linux.initrd 2019-12-07 20:32:08 and load the initramfs blob into it 2019-12-07 20:32:16 and then boot with rd_name=linux.initrd 2019-12-07 20:32:21 but you're still whangjangling your kernels manually or with hacks 2019-12-07 20:32:29 I'd really rather pull it from the filesystem, the leap isn't far 2019-12-07 20:32:40 let's not immortalize shitty boot hacks in this arch, too 2019-12-07 20:32:49 yes, we use fatload 2019-12-07 20:33:02 to read from mmc or usb 2019-12-07 20:33:24 namedblock linux.initrd 0x4000000 2019-12-07 20:33:40 fatload usb 0 initramfs-octeon $named_block_addr 2019-12-07 20:33:52 fedora uses hardcoded kernels and root filesystem over nbd 2019-12-07 20:33:53 bootoctlinux [...] rd_name=linux.initrd 2019-12-07 20:34:07 hifive doesn't have usb, only avenues are mmc or network 2019-12-07 20:34:13 or serial I guess 2019-12-07 20:34:28 smoke signals 2019-12-07 20:34:29 so the real problem is the hw is not really usable 2019-12-07 20:34:40 well, usable for what? 2019-12-07 20:34:50 booting off a hard disk :) 2019-12-07 20:34:52 it can be useful once you get it booted and on the network 2019-12-07 20:35:14 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 well that certainly kills the viability of that port :/ 2019-12-07 20:35:43 the boot story is really my only concern with this hardware 2019-12-07 20:36:00 why? you can't use HDDs on a raspberry pi, either, but they still serve a purpose 2019-12-07 20:36:07 I rather like the hifive, it's a pretty nice machine 2019-12-07 20:36:15 you can, via USB 2019-12-07 20:36:35 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 sure, but for building 2019-12-07 20:36:50 it is kind of a pain 2019-12-07 20:36:58 depends, really 2019-12-07 20:37:01 to have to boot off NBD or whatever 2019-12-07 20:37:04 not really 2019-12-07 20:37:18 I bootstrapped a significant chunk of main off of a 128G SD card 2019-12-07 20:37:28 8G of RAM makes for a pretty decent disk cache 2019-12-07 20:37:33 when did the SD card die ;) 2019-12-07 20:37:37 so it's not thrashing it much 2019-12-07 20:37:42 ¯\_(ツ)_/¯ 2019-12-07 20:37:45 if it dies, put a new one in 2019-12-07 20:37:53 idk, it's enough for me 2019-12-07 20:38:03 my board has an uptime of >100 days right now 2019-12-07 20:38:28 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 and then the SD card dies like a week later 2019-12-07 20:38:40 so :P 2019-12-07 20:38:40 well, this board costs over a grand 2019-12-07 20:38:45 no one is going to buy it without having a plan for it 2019-12-07 20:39:37 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 so far I have been unsuccessful in this endeavour 2019-12-07 20:39:56 u-boot is horrible, that is why 2019-12-07 20:40:05 aye 2019-12-07 20:40:25 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 i tried to update the cavium fork of u-boot and chainload it 2019-12-07 20:40:46 oh 2019-12-07 20:40:51 that is the chromeos way 2019-12-07 20:41:12 i have alpine running on an aarch64 chromebook actually 2019-12-07 20:41:15 it is quite speedy 2019-12-07 20:41:27 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 8 cores at 2.5ghz with 3.1ghz turbo 2019-12-07 20:41:37 plus, the modules and initrd have to be baked in 2019-12-07 20:42:02 which would involve magic ELF fiddling at best, and zero customizability and a weird build at worst 2019-12-07 20:42:20 yeah i looked into 2019-12-07 20:42:30 slipstreaming an initramfs into an already built kernel 2019-12-07 20:42:35 due to octeon fuckery 2019-12-07 20:42:42 it's the worst thing ever, right 2019-12-07 20:43:02 i did get petitboot working, but that's too much of a hack tbh 2019-12-07 20:43:24 i don''t want to have to build a linux distro just to boot another linux distro 2019-12-07 20:43:27 lol 2019-12-07 20:43:35 lol yeah, that shit be dumb 2019-12-07 20:43:45 did you hear about my petitboot horror story on ppc64 2019-12-07 20:44:02 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 no but it seems about right 2019-12-07 20:45:17 i just use grub 2019-12-07 20:45:21 on ppc64 2019-12-07 20:45:38 you can boot directly to it from the system management console thing 2019-12-07 20:55:08 kaniini: also I have alpine on chromebook 2019-12-07 20:55:37 aarch64 2019-12-07 20:57:20 how do you boot yours 2019-12-07 20:57:34 i use some arch kernel but it is broken and doesnt turn my trackpad on 2019-12-07 20:58:42 I created vboot-utils for alpine, build kernel and sign, then 'dd' kernel partition 2019-12-07 20:58:52 yeah but what kernel do you use 2019-12-07 20:58:58 like a custom one? 2019-12-07 20:59:37 yes, I build custom because alpine aarch64 kernel (as it is now) doesn't work 2019-12-07 21:02:07 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 and 'numeric' menu in u-boot to select kernels 2019-12-07 21:03:01 but didn't found anything which work on aarch64 2019-12-07 21:03:41 tried to build from upstream but display is blank, doesn't work 2019-12-07 21:04:43 ah so you use the google-provided sources 2019-12-07 21:05:08 no, upstream kernel.org 2019-12-07 21:05:48 in previous msg by 'upstream' I meant u-boot 2019-12-07 21:06:10 do you use upstream sources with the google-provided DTB or what 2019-12-07 21:07:32 I took kernel.its from Arch, everything else is in upstream kernel 2019-12-07 21:07:46 rk3399 2019-12-07 21:08:45 actually, I could write kernel.its but lazy 2019-12-07 21:10:23 what kernel are you using 2019-12-07 21:10:26 like just 5.4? 2019-12-07 21:10:27 or what 2019-12-07 21:11:13 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 but started with 5.0 iirc 2019-12-07 21:12:49 maybe 4.2x, forgot TBH 2019-12-07 21:14:00 interesting 2019-12-07 21:14:10 have you packaged vboot-utils yet 2019-12-07 21:14:28 apk search vboot-utils :) 2019-12-07 21:14:33 testing repo 2019-12-07 21:15:51 and cgpt subpkg 2019-12-07 21:24:28 could probably move to community :) 2019-12-07 21:26:23 you are first who asked 2019-12-07 21:27:37 and I don't move pkgs till someone ask :) 2019-12-07 21:27:44 so i think ultimately 2019-12-07 21:27:51 i just need to get upstream kernel source 2019-12-07 21:28:06 and the DTB from the google sources (since it's not in upstream), and write an its file 2019-12-07 21:28:12 and then my trackpad will work 2019-12-07 21:28:25 what is your chipset 2019-12-07 21:28:28 since i think the DTB being used in the arch kernel is for a previous revision 2019-12-07 21:28:32 umm 2019-12-07 21:28:36 the mediatek one 2019-12-07 21:28:51 'oak' baseboard 2019-12-07 21:28:52 ah, my son have mediatek chromebook 2019-12-07 21:29:00 yes, oak 2019-12-07 21:29:17 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 in the DTB 2019-12-07 21:29:26 but I can't experiment with his chromebook 2019-12-07 21:29:55 on his machine kernel is 3.18 I think 2019-12-07 21:30:20 yes 2019-12-07 21:30:34 i think it is possible to run upstream 5.4 2019-12-07 21:30:40 just need to get the right DTB 2019-12-07 21:30:45 but trackpad works on his machine 2019-12-07 21:30:55 yeah 2019-12-07 21:31:05 everything but trackpad works 2019-12-07 21:31:26 why do ppl use chromebook with linux? battery life? 2019-12-07 21:31:37 aarch64 2019-12-07 21:32:01 970 gr, weight :) 2019-12-07 21:32:23 what is special about aarch64 that you want it on your notebook? 2019-12-07 21:32:26 the fact that it deadnames me when i log in 2019-12-07 21:33:08 mps: you can get that weight also on x86 notebooks 2019-12-07 21:33:37 clandmeter: lack of bullshit like spectre/meltdown 2019-12-07 21:33:56 also it is nice to be able to test my code on aarch64 2019-12-07 21:33:58 xrandr says '2400x1600' 2019-12-07 21:34:24 plus tablet mode 2019-12-07 21:34:36 touchscreen 2019-12-07 21:34:43 mine doesnt have touchscreen 2019-12-07 21:34:47 but oak boards usually do 2019-12-07 21:34:55 that's why i think i need a different DTB :P 2019-12-07 21:35:06 ah, could be 2019-12-07 21:35:38 I will look deeply on my son machine in aa few days, when he come here 2019-12-07 21:36:06 also need to figure out video acceleration i guess 2019-12-07 21:36:33 yes, that is unknown for me on mediatek 2019-12-07 21:36:34 probably linking gcompat against the proprietary blob for now :/ 2019-12-07 21:37:25 clandmeter: also chromebooks are like $160 US with otherwise decent spec 2019-12-07 21:37:55 decent for the price maybe 2019-12-07 21:38:02 about spectre: lscpu => Vulnerability Spectre v2: Vulnerable 2019-12-07 21:38:07 meh 2019-12-07 21:41:45 clandmeter: if I buy it now I would probably go with rock64 2019-12-07 21:41:51 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 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 look, it's not x86 is the main point 2019-12-08 07:28:30 i do not think you understand my dislike of x86 2019-12-08 07:28:36 it is pretty extreme 2019-12-08 07:36:55 also, I dislike x86 maybe not extreme but sure dislike them strongly 2019-12-08 07:37:32 not that I like arm ltd much 2019-12-08 07:55:53 well 2019-12-08 07:55:55 i should clarify 2019-12-08 07:55:59 i dislike intel extremely 2019-12-08 07:56:04 AMD are mostly okay 2019-12-08 07:56:12 but 2019-12-08 08:00:00 I don't like x86, but right now it's just the best bang for the buck, sooo 2019-12-08 08:00:15 I'm team AMD too though 2019-12-08 08:00:36 I don't know if ADM have IME (Intel Management Engine) 2019-12-08 08:02:17 computers eh 2019-12-08 08:03:56 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 AMD has PSP which kind of is like the IME 2019-12-08 08:38:02 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 We're transitioning to Gitlab, yes. But maybe _ikke_/ncopa can take a look at it 2019-12-08 08:57:23 https://github.com/alpinelinux/aports/pull/12044 2019-12-08 08:57:33 that'll be my last patch via github 2019-12-08 08:58:38 I got opencv compiling and need to create a PR for it 2019-12-08 09:08:21 Nice, feel free to ask if need help w/ Gitlab 2019-12-08 09:39:36 =) 2019-12-08 11:16:20 alpine and ROS .. mmm 2019-12-08 11:59:31 oh he knew what I was working on 2019-12-08 12:12:36 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 https://wiki.ros.org/ 2019-12-08 12:15:22 ROS (Robot Operating System) 2019-12-08 12:16:30 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 opencv (openCV - CV Computer Vision) triggered my memory about ROS 2019-12-08 13:16:13 yeah I'm trying to get all the dependencies into aports 2019-12-08 13:16:30 dependency hell when you run with it on debian 2019-12-08 13:16:36 or ubuntu 2019-12-08 13:22:21 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 mps I don't think it's anywhere near as bad haha 2019-12-08 13:23:55 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 russkel: you noticed ':D' at the end of my msg :) 2019-12-08 13:35:51 yep =) 2019-12-08 13:36:23 and I understand that some pkgs are 'dependency hell' 2019-12-08 13:40:01 haha yeah not a secret at all 2019-12-08 13:43:07 hmm I wish someone would port nanomsg-ng to an embedded platform 2019-12-08 14:59:14 north1: git commit -v 'community/vboot-utils: move from community' 2019-12-08 14:59:29 should be from testing 2019-12-08 14:59:46 I mean your git hook which I use 2019-12-08 15:02:56 north1: sorry, looking at it I'm not sure is this issue with your git hook 2019-12-08 16:11:52 heyaaa 2019-12-08 16:11:56 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 and fixing known bugs 2019-12-08 16:43:06 sadly I haven't had time for rpi4 stuff, might not make it to release 2019-12-08 16:51:52 not that it would be difficult to do quick patch tonight 2019-12-08 16:58:09 it will be 5.4 kernel on the release, then? 2019-12-08 17:20:35 Hi, what is the proper way to add a self-hosting compiler to aports? 2019-12-08 17:21:04 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 So I'm not sure how bootstrapping is supposed to be done in these cases. 2019-12-08 17:34:15 Fetch a tarball to bootstrap from 2019-12-08 17:37:44 Ok, and bootstrapping using itself would then be added only in the following release? 2019-12-08 17:44:26 Yes 2019-12-08 17:44:33 See Rust for how this was done 2019-12-08 17:45:22 I will give it a look. Thank you. 2019-12-08 20:10:29 Hi all :-) 2019-12-08 20:13:39 I've created a tiny build environment to package for arm32v7 on amd64 host, using docker and qemu 2019-12-08 20:13:48 https://github.com/kmmndr/alpine-build-env 2019-12-08 20:14:52 It may be usefull for someone else than me :-) 2019-12-09 02:21:13 kmmndr: that approach will not work for go-based applications due to how go does signalling 2019-12-09 02:21:53 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 apk-tools is flagged for outdated, but has the same version 2019-12-09 07:06:51 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 the flagged packages from pkgs.a.o is so wonky 2019-12-09 08:14:45 hey anybody have compiled citra 3ds emulator ? 2019-12-09 08:16:02 Doesn't ring a bell here 2019-12-09 08:18:12 i see 2019-12-09 08:24:42 kaniini: That's very good to know, did you start a similar tool ? 2019-12-09 09:06:11 north1: those are manually flagged. 2019-12-09 09:06:38 Automatic flagging has not been enabled yet 2019-12-09 09:06:55 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 kmmndr: yeah I used that to accelerate bootstrapping mips64 port 2019-12-09 10:01:03 ncopa: I may have to upgrade s390-tools for kernel 5.3 2019-12-09 10:03:12 it's failing to boot 2019-12-09 10:03:29 *reboot, after installation. 2019-12-09 10:06:57 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 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 _ikke_: :) 2019-12-09 10:08:10 I am 2019-12-09 10:08:21 But still lurking ;-) 2019-12-09 10:08:52 clandmeter: have you tried netboot-ing 3.11 artifacts ? 2019-12-09 10:09:18 I'm seeing busybox spitting bunch of warnings, currently checking on x86_64 2019-12-09 10:15:15 ok confirmed on x86_64 busybox spitting some warning 2019-12-09 10:15:20 getting them ... brb 2019-12-09 10:15:47 Which kind? 2019-12-09 11:25:19 clandmeter: 3.11 netboot images vmlinuz-lts, initramfs-lts, modloop-lts 2019-12-09 11:25:50 the error i mean 2019-12-09 11:31:02 clandmeter : http://tpaste.us/BjJo 2019-12-09 11:32:01 happening inside initramfs 2019-12-09 11:32:19 probably does bb does not run its hook to populate the symlinks 2019-12-09 11:32:49 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 yeah seems right 2019-12-09 11:34:00 exec /bin/busybox --install -s 2019-12-09 11:34:20 should be that one (in the past I had to run manully when porting stuffs ...) 2019-12-09 11:34:58 brb 2019-12-09 11:35:45 sounds like /usr/bin doesnt exist? 2019-12-09 11:46:50 what package should create it? 2019-12-09 12:12:15 initramfs i guess 2019-12-09 12:25:44 #11020 2019-12-09 12:25:54 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 I run latest mkinitfs (edge) on armv7 and it works without problem, or I didn't noticed something 2019-12-09 12:33:17 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 at least cooling works... 2019-12-09 12:43:01 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 oh forget the linux-firmware, doesn't work now =) 2019-12-09 12:44:28 (or it might, but irrelevant) 2019-12-09 12:59:20 artok: what I should do? do you have PR there which I can apply to current aports 2019-12-09 13:00:16 oh, you mean to clone this repo? 2019-12-09 13:00:51 and, build RPI4 on armv7 or aarch64? 2019-12-09 13:06:11 build rpi4 on armv7, aarch64 machine I have from scaleway building 2019-12-09 13:09:21 by cloning repo? 2019-12-09 13:09:36 :D see everyone later, installing SSD on my notebook 2019-12-09 13:09:37 yah 2019-12-09 13:10:33 ok, see you later 2019-12-09 13:10:51 I created that big patch last night since I don't have scp access to alpinelinux.org files =) 2019-12-09 13:11:34 you can create MR on gitlab.a.o 2019-12-09 13:12:13 going to, I just need to read some docs =) 2019-12-09 13:12:23 artok: I should build main/linux-rpi 2019-12-09 13:15:20 yeah 2019-12-09 13:15:44 and should get rpi, rpi2, rpi4 packages 2019-12-09 13:16:29 ok 2019-12-09 13:16:43 this is 4.19.x not 5.4 2019-12-09 13:16:59 5.4.2 is on the rpi4-542 branch 2019-12-09 13:17:21 ah, I have to checkout branch 2019-12-09 13:17:30 yeah sorry forgot to mention 2019-12-09 13:18:04 but there is no branches, only master 2019-12-09 13:18:44 https://github.com/djazo/aports.git should have that branch 2019-12-09 13:19:13 git clone https://github.com/djazo/aports.git 2019-12-09 13:19:23 git branch => master 2019-12-09 13:19:26 no other 2019-12-09 13:20:13 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 yes 2019-12-09 13:21:24 but not after clone in local repo 2019-12-09 13:23:56 git pull origin rpi4-542 2019-12-09 13:24:06 looks solved 2019-12-09 13:24:19 hackish way :) 2019-12-09 13:25:32 artok: building, see you later .... 2019-12-09 13:30:53 thanks! laters! 2019-12-09 13:39:36 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 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 Files are not part of the index at all 2019-12-09 14:33:30 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 basically, what I'm after is, is file bla.apk, listed properly in APKINDEX.tar.gz 2019-12-09 14:43:22 oh my.. that poor rpi4 has been working soon around the clock 2019-12-09 14:44:09 ssd on usb port might have been one to speed up things =) 2019-12-09 14:46:36 artok: I use ssd on usb-c also when building bigger pkgs 2019-12-09 14:47:03 I have "fast" usb stick 2019-12-09 14:47:09 it is much faster than emmc or (OMG) mmc 2019-12-09 14:47:21 yeah oh god people using mmc as their root 2019-12-09 14:49:54 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 but need time 2019-12-09 14:50:23 anyway, building linux-rpi is finished 2019-12-09 14:52:04 and proper packages there? 2019-12-09 14:52:28 great! 2019-12-09 14:52:49 yes 2019-12-09 14:53:02 but I don't have boards to test 2019-12-09 14:53:09 now only to create tar installation package and we might test 2019-12-09 14:53:24 before that, linux-firmware should be build also 2019-12-09 14:53:42 from the same repo and branch? 2019-12-09 14:54:11 yes, and the scripts are also modified to work on that branch 2019-12-09 14:54:30 ok, lets try 2019-12-09 14:57:12 it was fast, finished 2019-12-09 15:03:06 it creates fakeroot, installs packages and runs initramfs and modloop.. and boom 2019-12-09 15:06:04 I need to now get some coffee and drive 1,5hrs 2019-12-09 15:06:26 if you have the tar.gz available for me to download, share it now. =) 2019-12-09 15:07:01 I'll test when I'm done with driving, I'm having my rpi's with me 2019-12-09 15:14:40 oliv3r[m]: apk search gives you all packages available 2019-12-09 15:16:15 mps, laters, 2hrs might go and I'll be back, I'm packing now all my sd cards 2019-12-09 15:16:18 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 you can specifiy which index you want to use 2019-12-09 15:17:18 but i htink you need to exclude the default ones with something like /dev/null 2019-12-09 15:18:20 something like repository-file /dev/null extra-repo whatever. 2019-12-09 15:18:27 im not suer what the correct syntax is 2019-12-09 15:19:59 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 macos does not want to connect to the wifi... 2019-12-09 15:41:36 ouch :( why would you run windows on your macbook working on alpine? :) 2019-12-09 15:47:19 because it doesnt run linux properly, and without wifi its kind of useless. 2019-12-09 15:47:32 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 ah a new macbook pro :( I have an older 2015-late model; runs linux pretty great 2019-12-09 15:48:18 suspend/resume isn't not perfect, especially with regards to wifi 2019-12-09 15:49:54 did you specify -X? 2019-12-09 15:51:11 --repository . yes, also --repository $(readlink -f . ) 2019-12-09 15:52:40 i think it's because by default, it will look in the current directory? 2019-12-09 15:53:10 nope that's not it either 2019-12-09 15:53:34 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 by default it will getrepos from /etc/apk/repositories 2019-12-09 15:53:59 thts why you need to disable it 2019-12-09 15:54:32 yeah hence the --repositories-file /dev/null 2019-12-09 15:55:49 what I don't want to do, is tar xvf APKINDEX.tar.gz | grep 2019-12-09 15:55:53 rather I'd use some built in tool to properly do this 2019-12-09 15:58:07 apk --no-cache --repositories-file /dev/null -X http://dl-cdn.alpinelinux.org/alpine/latest-stable/main search 2019-12-09 15:59:11 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 if you dojnt want pkgver 2019-12-09 16:15:49 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 aye, I responded on the mailing list 2019-12-09 16:16:45 I don't expect this patch to be merged right away 2019-12-09 16:19:10 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 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 ddevault: Odd, didn't get the email 2019-12-09 16:20:46 well i can do search --exact pkgname | grep -q ${file%%.apk} or something; 2019-12-09 16:21:23 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 Cogitri: https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E#%3CBZ10HOAT7Z8A.1DMTQFIGETY9K@homura%3E 2019-12-09 16:22:03 greylisting, maybe? 2019-12-09 16:22:05 dunno 2019-12-09 16:22:23 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 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 Same, but some upstreams just refuse to accept bug reports with different tooling 2019-12-09 16:40:44 And it's way easier to install ninja instead of arguing with upstream :) 2019-12-09 16:40:54 upstream doesn't have to know ;) 2019-12-09 16:41:08 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 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 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 it doesn't seem like a robust approach 2019-12-09 16:42:21 we're replacing it or we're not, I don't want to half ass it 2019-12-09 16:43:40 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 I understand, but I still dislike it 2019-12-09 16:44:07 people complain about our use of busybox tools causing build problems, for example 2019-12-09 16:44:09 alpine is no stranger to this 2019-12-09 16:44:18 Well, camouflaging samu as ninja just seems a bit hacky to me 2019-12-09 16:44:23 samu is a drop-in replacement, I say drop it in 2019-12-09 16:44:48 let's not hold up doing the right thing in expectation of an unlikely future 2019-12-09 16:44:55 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 s/on Alpine/on Void/ 2019-12-09 16:45:04 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 that makes sense, because pkg-config is a complicated beast with lots of ways people (ab)use it 2019-12-09 16:45:36 ninja doesn't really have the same problems 2019-12-09 16:45:40 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 Well, possibly, but after that switch I'm sceptical of just camouflaging tools 2019-12-09 16:46:42 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 similar benefits come from samu in that respect 2019-12-09 16:47:05 But with ninja vs samu I don't think the advantages are great enough 2019-12-09 16:47:15 it's much simpler and smaller, reduces the C++ footprint in our build dependency tree, etc 2019-12-09 16:47:28 Yes, but that is only installed on a very limited amount of machines 2019-12-09 16:47:35 (Only dev machines) 2019-12-09 16:47:45 I don't like giving dev machines a second-class experience 2019-12-09 16:47:54 anyone could build packages for any reason at any time 2019-12-09 16:47:58 it's not limited to the members of this channel 2019-12-09 16:48:48 anyway, I see where you're coming from with the risk-averse approach to this idea 2019-12-09 16:48:58 but the risks with samurai are exceptionally small, much smaller than with e.g. pkgconf 2019-12-09 16:49:06 and I think the benefits are compelling 2019-12-09 16:49:57 and I'll remind you that despite those difficulties, alpine uses pkgconf to this day :) 2019-12-09 16:50:15 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 musl, busybox, pkgconf... 2019-12-09 16:52:34 Hm, fair enough 2019-12-09 16:52:57 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 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 So samu symlinks to ninja unless you have ninja installed? 2019-12-09 16:53:23 I'd rather do that once we know that it'll be necessary, not before 2019-12-09 16:53:31 we don't have a pkg-config package 2019-12-09 16:53:53 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 Hm, true that 2019-12-09 16:56:26 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 we can schedule rebuilds for everything which depends on ninja to be sure before the next release 2019-12-09 16:56:43 ~600 pkgs 2019-12-09 18:11:42 you can also make samurai-ninja subpackage with single symlink 2019-12-09 18:13:11 what is py3-pygments doing in main 2019-12-09 18:24:30 what is ceph doing in main 2019-12-09 18:36:16 pygments -> because gtk+2.0 2019-12-09 18:36:19 what is gtk+2.0 doing in main 2019-12-09 18:41:21 ceph is moved because of qemu, iirc 2019-12-09 18:54:49 what ceph has to do with qemu? 2019-12-09 18:55:36 rbd deps, iirc 2019-12-09 18:57:30 oh yeah it supports now that 2019-12-09 19:00:10 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 (what will stay in main at the end) 2019-12-09 19:02:10 self-hosting base system 2019-12-09 19:02:32 weechat and irsii in main? 2019-12-09 19:02:34 apk, linux, and everything necessary to build, install, and maintain the system 2019-12-09 19:02:43 I'd vote against weechat and irssi in main 2019-12-09 19:02:50 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 I'd vote for more repos/subdirs 2019-12-09 19:04:17 I don't want it to be overcomplex, I just want main to be small 2019-12-09 19:04:31 I don't want FreeBSD style separation 2019-12-09 19:04:36 s/FreeBSD/ports/ 2019-12-09 19:04:36 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 I'm for system where we can keep system programs/servers and similar 2019-12-09 19:06:40 and maybe DE 2019-12-09 19:06:49 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 yeah, the last thing I want is a de subdir 2019-12-09 19:07:42 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 maybe base/main/community/testing would be better 2019-12-09 19:08:19 mps, having packages somewhere to download? 2019-12-09 19:08:34 I'm out of home now 2019-12-09 19:08:48 ok 2019-12-09 19:09:18 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 /home/mps/packages/main/arvm7 2019-12-09 19:09:51 <_ikke_> everything? 2019-12-09 19:10:08 linux-rpi* and linux-firmware* 2019-12-09 19:10:18 <_ikke_> ok 2019-12-09 19:10:21 did you do the installer packages? 2019-12-09 19:10:55 _ikke_: mps-edge-armv7 usa4 2019-12-09 19:11:00 <_ikke_> yes, found it already :) 2019-12-09 19:11:03 artok: no 2019-12-09 19:11:18 just what you asked for 2019-12-09 19:13:40 didn't I ask for those installers? 2019-12-09 19:13:50 might be =) 2019-12-09 19:14:26 could be but don't remember, sorry 2019-12-09 19:14:40 but no worries, that runs on cross platform =) 2019-12-09 19:22:03 I'm still in middle of provisioning my scaleway aarch64 machine 2019-12-09 20:05:37 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 Thank you :) 2019-12-09 20:07:59 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 How about adding a issue template to Gitlab? 2019-12-09 20:08:21 Where users have to check some stuff before submitting bugs ala: 2019-12-09 20:08:38 - [ ] I have made sure that my system is fully upgraded, if not why: 2019-12-09 20:08:56 - [ ] I have included logs, if necessary 2019-12-09 20:08:58 etc. 2019-12-09 20:09:16 <_ikke_> I hate those :| 2019-12-09 20:09:19 (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 I think that works if we just put HTML style comments around it 2019-12-09 20:10:21 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 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 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 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 tridactyla: have you ever seen this happen in practice? 2019-12-09 20:21:56 this is always a bug in the package though, not ninja or samurai 2019-12-09 20:23:04 I have seen it happen lots with ninja, not sure if samurai would show different behaviour though 2019-12-09 20:23:28 (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 s/builders/build jobs/ 2019-12-09 20:23:39 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 that's surprising, in more ways than one 2019-12-09 20:23:54 do you have a build log somewhere? 2019-12-09 20:25:47 ddevault: yeah, i have seen it occasionally 2019-12-09 20:26:06 bugs in e.g. meson or something closer upstream? 2019-12-09 20:26:36 the package itself in the meson/cmake files 2019-12-09 20:29:36 NetworkManager still has the bug I think 2019-12-09 20:30:36 https://gitlab.alpinelinux.org/alpine/aports/blob/master/community/networkmanager/APKBUILD#L83 2019-12-09 20:30:55 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 I think greping for `ninja -C output .*` might yield more cases of this, but can't check 2019-12-09 20:41:26 mps: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e7096c131e5161fa3b8e52a650d7719d2857adfd 2019-12-09 21:25:44 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 although is look like simple cherry-pick will work 2019-12-09 21:27:07 _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 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 but also doesn't look complicated to alpine linux-lts directrly 2019-12-09 21:28:40 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 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 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 patch -p1 < wg-gru.patch 2019-12-09 21:31:55 no, but maintain separate pkg is burden anyway 2019-12-09 21:33:43 I think we can use vanilla to have not let's kernels 2019-12-09 21:34:14 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 hm, we patch a lot of things anyway 2019-12-09 22:43:20 features dont get backported. 2019-12-09 22:43:47 i think we could have vanilla follow latest kernel 2019-12-09 22:45:51 clandmeter: iiuc, that is a plan 2019-12-09 22:46:39 although name sounds 'strange' to me, but I don't know fine points of english 2019-12-09 23:17:16 _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 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 i suspect the combination of alpine + chromebooks to be a useful computing platform 2019-12-10 01:55:07 when booting rpi, I'm getting those busybox missing links 2019-12-10 02:26:43 and seems that rpi people are still in 5.4.1 2019-12-10 03:06:10 in meantime, if anyone interested, aarch64 install boots on rpi3 and rpi4 nicely 2019-12-10 03:06:50 other than that busybox thingie 2019-12-10 07:39:22 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 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 I was wondering if anyone could checkout if that limit can be raised to maybe 10k? 2019-12-10 07:50:14 That'll make gitlab rather slow, it already takes some 10 seconds to load community/ 2019-12-10 07:50:23 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 Or that, yes 2019-12-10 08:53:00 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 any idea of what is wrong ? i have set up abuild group and permissions on /var/cache/distfiles 2019-12-10 08:54:02 it works without docker-abuild 2019-12-10 08:54:46 <_ikke_> different uids? 2019-12-10 08:54:54 oh 2019-12-10 08:55:12 can make sense, my UUID on the new system is 1001 instead of 1000 2019-12-10 09:06:19 Yep 2019-12-10 09:06:23 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 created another account before 2019-12-10 09:07:40 <_ikke_> sounds kind of logical :) 2019-12-10 09:16:26 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 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 s/you/your/ 2019-12-10 09:18:44 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 and, maybe we can consider more broader 'theme' than only chromebooks, something like 'Alpine on ARM' 2019-12-10 09:21:31 (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 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 or is that just your thing to pick on :D? 2019-12-10 10:30:56 fair 2019-12-10 10:31:23 I haven't heard much fall out over that, any attacks used out in the wild? 2019-12-10 10:31:30 APTs using them yet? 2019-12-10 10:31:45 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 uh, kaniini rather 2019-12-10 10:32:54 PureTryOut[m]: imo, desktop is separate topic 2019-12-10 10:33:12 Separate from Chromebooks? How so? 2019-12-10 10:33:35 with 'Alpine on ARM' I mean base system, boot loaders, kernels and tools for that 2019-12-10 10:33:45 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 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 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 there are some things in userspace (lima, panfrost for example) but without base system these are not important 2019-12-10 10:38:04 and, btw I don't see big issue with 'Alpine on Desktop', it is quite fine, imo 2019-12-10 10:40:13 I'm more of an Alpine on a robot 2019-12-10 10:40:15 kind of guy 2019-12-10 10:40:28 :D 2019-12-10 10:40:51 russkel: hi ROS :) 2019-12-10 10:41:39 I had another framework already working on it haha 2019-12-10 10:41:58 but yes ROS is the next step 2019-12-10 10:45:01 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 later (at night, I thinl) will test on two more boards 2019-12-10 10:46:12 ooh which board mps? 2019-12-10 10:46:28 only have issues on exynos, but we didn't had kernel which worked on exynos afaik 2019-12-10 10:46:45 is that the processor the odroids use? 2019-12-10 10:46:57 russkel: leemaker bananapi and one cubie board 2019-12-10 10:47:24 russkel: some versions of odroid use exynos 2019-12-10 10:47:44 ACTION nods 2019-12-10 10:47:58 I have an orange pi zero plus 2 2019-12-10 10:48:06 that has been troubles since day one 2019-12-10 10:48:24 I can't remember right now which odroid use which exynos version 2019-12-10 10:48:49 orange uses Allwinner SOC's, mostly 2019-12-10 10:49:06 oranges* 2019-12-10 10:49:16 XU4 uses Exynos5 Octa apparently 2019-12-10 10:49:41 I think so 2019-12-10 10:50:12 I have exynos5 octa but in chromebook (samsung) 2019-12-10 10:52:01 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 (and we need more testers with arm) 2019-12-10 10:52:40 and devs, ofc 2019-12-10 10:53:43 does alpine-arm closely track mainline linux kernel? 2019-12-10 10:54:54 currently all alpine kernels are built from mainline 2019-12-10 10:55:36 RPI kernels are little different but not much 2019-12-10 10:56:32 just did a search on pkgs.a.o for linux, bit confusing 2019-12-10 10:56:38 small patches and different config 2019-12-10 10:56:44 linux-vanilla is behind linux-lts 2019-12-10 10:57:10 till now linux-vanilla was only kernel 2019-12-10 10:58:02 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 lots of stuff added to the kernel in the SoC space 2019-12-10 10:59:24 yes, and lot things now works and lot works better 2019-12-10 11:00:02 5.5-rc1 have a lot more fine things for ARM 2019-12-10 11:00:51 PureTryOut[m]: there are specialized concerns involving chromebooks 2019-12-10 11:01:12 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 mps, any tools for customising the device trees etc? 2019-12-10 11:04:16 russkel: not much that I know (except 'vim' :) ) 2019-12-10 11:04:37 some distros like to help out with that kind of thing 2019-12-10 11:04:41 I think armbian being one 2019-12-10 11:05:15 I quite like armbian I have to say 2019-12-10 11:05:17 imo, best is alarm, Arch linux ARM 2019-12-10 11:05:41 I've tried to install that once and didn't get anywhere 2019-12-10 11:06:00 is a shame because I like arch. my desktop is manjaro 2019-12-10 11:06:06 I used armbian for some time but it is not good, slow at first 2019-12-10 11:06:35 slow why? 2019-12-10 11:07:06 try to install alpine on same board and you will understand what I say :) 2019-12-10 11:07:23 :D 2019-12-10 11:07:40 I'm not disagreeing, just curious as to why it is slower 2019-12-10 11:08:10 systemd, glibc and probably some other crufts 2019-12-10 11:08:51 fair points 2019-12-10 11:09:21 I should try get alpine rolling on it, although I'm dreading setting up drivers for wifi etc 2019-12-10 11:09:29 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 my mail server is on arm board 2019-12-10 11:10:52 (dns, dhcp, web server, wifi router, adsl etc, all on one old SBC) 2019-12-10 11:11:06 what mail server? 2019-12-10 11:11:29 postfix, if you ask which software 2019-12-10 11:11:39 and dovecot 2019-12-10 11:11:55 plus postgrey 2019-12-10 11:12:17 I use[d] dovecot and that other one 2019-12-10 11:12:29 damn forgot the name 2019-12-10 11:12:58 exim 2019-12-10 11:13:17 They use so much RAM!! For what?!? 2019-12-10 11:13:17 debian inheritance :) 2019-12-10 11:13:44 I kind of want to write a lightweight one in Rust as an experiment 2019-12-10 11:14:01 heritage? (self taught in english, sorry) 2019-12-10 11:14:17 heritage works 2019-12-10 11:14:24 lightweight in Rust? :D 2019-12-10 11:15:06 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 (hipsters never made anything good) 2019-12-10 11:15:42 you don't like Rust? 2019-12-10 11:16:03 it depends on how much mail server have to handle 2019-12-10 11:16:37 Rust is one of the worst langs after python 2019-12-10 11:27:24 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 -1 on that :P 2019-12-10 11:29:41 Cogitri: -1 :) 2019-12-10 11:31:32 I do write some stuff in D now though to get that sweet, sweet dynamic linking 2019-12-10 11:34:28 -l ? 2019-12-10 11:35:19 I haven't used Rust much but I really enjoyed using it 2019-12-10 11:35:46 python is great what are you talking about!? :D 2019-12-10 11:36:40 a straightforward, clean and easy to use language with a competent stdlib and an amazing ecosystem of libs 2019-12-10 11:38:15 we should move this discussion to #alpine-offtopic, really 2019-12-10 16:51:45 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 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 Arch linux ARM (alarm) kernel use patch for wireguard, and take this patch from debian 2019-12-10 23:08:22 https://git.alpinelinux.org/abuild/commit/abuild.in?id=b8b8a651fc147669e3e811f55198305b97c1001c 2019-12-10 23:08:45 tmhoang: thats that one that causes the busybox errors 2019-12-11 01:13:29 I think we should have a talk about procmail 2019-12-11 01:14:02 it presently FTBFS (for me) on mips64 and also on x86_64 2019-12-11 01:14:16 procmail is a giant security hole 2019-12-11 01:14:33 it's upstream maintainer literally advises users to use anything else 2019-12-11 01:14:47 I propose we remove it before 3.11 release on QA grounds 2019-12-11 02:07:28 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 Ah then please close the MRs jowi made please 2019-12-11 05:52:08 <_ikke_> done 2019-12-11 06:01:57 Ty 2019-12-11 06:12:37 @clandmeter> tmhoang: thats that one that causes the busybox errors : ---> waiting for clandmeter's fix :D 2019-12-11 06:13:59 I should start using snapshot edge's netboot images more frequently 2019-12-11 06:14:48 so if that commit is the cause, then it could be detected sooner 2019-12-11 06:18:39 ah north1 is JOWI 2019-12-11 06:19:53 I know but I couldn't give myself the effort 2019-12-11 06:20:08 give more :P 2019-12-11 06:22:34 Not while I'm laying in bed 2019-12-11 06:52:04 clandmeter: maybe https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2033 2019-12-11 06:56:58 morning 2019-12-11 07:09:29 oh sweet 2019-12-11 07:09:35 it wasn't only my system having lockups with kernel 5.4+ 2019-12-11 07:09:45 ^ sounds very bad btw 2019-12-11 07:11:02 https://gitlab.freedesktop.org/drm/intel/issues/674 https://cgit.freedesktop.org/drm-tip 2019-12-11 08:09:47 tmhoang: i already pushed a fix 2019-12-11 08:10:43 ah https://git.alpinelinux.org/aports/log/?qt=author&q=meter 2019-12-11 08:11:16 it's interesting lastname : Landmeter 2019-12-11 08:12:40 Many ncopa want to fix it in another place 2019-12-11 08:13:01 This just fixes the current issue 2019-12-11 08:15:32 clandmeter: acked. also the warning is gone in x86's bb-1.31.1-r3. 2019-12-11 08:16:13 ouch ctags fail on s390x 2019-12-11 08:20:38 <_ikke_> tmhoang: literally translated: "land measurer" 2019-12-11 08:23:39 /bin/busybox mkdir -p "/bin" 2019-12-11 08:23:54 ^ that's a good one 2019-12-11 08:28:07 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 calling /bin/busybox to create /bin 2019-12-11 08:29:54 /bin is not the right dir 2019-12-11 08:29:56 if you are calling /bin/busybox then obviously /bin exists 2019-12-11 08:30:00 <_ikke_> nod 2019-12-11 08:30:09 otherwise /bin/busybox will fail in the first place 2019-12-11 08:30:13 busybox uses /usr/bin 2019-12-11 08:30:17 by default 2019-12-11 08:31:03 <_ikke_> clandmeter: the script calls /bin/busybox to create /bin 2019-12-11 08:31:38 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 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 aah another commit there 2019-12-11 08:33:23 somebody commited over my commit 2019-12-11 08:33:35 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 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 ah maybe so 2019-12-11 08:36:01 they were already exiting, i didnt verify that. 2019-12-11 08:36:18 ncopa didnt clean those empty dirs 2019-12-11 08:36:23 <_ikke_> http://tpaste.us/vJNo 2019-12-11 08:42:07 $ busybox --list-applets | tpaste 2019-12-11 08:42:07 http://tpaste.us/QnR0 2019-12-11 08:42:44 i merged the MR 2019-12-11 08:43:02 yeah, /bin was not needed 2019-12-11 08:43:04 i didnt notice there was one :) 2019-12-11 08:43:24 i tracked it back to the cleanup change 2019-12-11 08:43:40 i guess the noempty option sounds sane for baselayout 2019-12-11 08:43:51 err keepempty or whatever 2019-12-11 08:43:51 we need an options="keepdirs" or similar 2019-12-11 08:44:09 yeah 2019-12-11 08:44:14 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 Cogitri: why cannot you reply on ML? 2019-12-11 08:48:02 yay we decided to upgrade and change upstream for ctags 2019-12-11 08:48:32 ncopa (IRC): I talked about the emptydirs option that is found on archlinux's pkgbuild 2019-12-11 08:48:44 yeah, i think that makes sense 2019-12-11 08:50:56 i need to go out for a while 2019-12-11 08:50:57 bblm 2019-12-11 08:51:28 s/bblm/bbl/ 2019-12-11 08:51:28 ncopa meant to say: bbl 2019-12-11 08:54:04 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 _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 nmeum: 1 sec 2019-12-11 09:43:33 brb 2019-12-11 10:12:52 gotta get to work, will try to look into it asap 2019-12-11 11:04:43 hm, I can actually reproduce the test failure on s390x 2019-12-11 11:04:49 how did this pass on the ci? Oo 2019-12-11 11:09:39 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 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 _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 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 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 lgtm I guess 2019-12-11 12:26:11 (Forgot to approve on Gitlab when taking a look at it earlier) 2019-12-11 12:26:12 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 _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 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 I'll resync aarch64 lxc now, and try to build kea 2019-12-11 12:50:08 _ikke_ nmeum: just found the 1989 MR. I'm also looking into the test suites. 2019-12-11 12:50:18 _ikke_ : you mean the time out issue ? I have time now. 2019-12-11 12:50:27 @tmhoang !1989 can be used to refer to it with algitbot support 2019-12-11 12:51:09 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 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 ok 2019-12-11 12:51:50 <_ikke_> there was a stray stunnel process left behind 2019-12-11 12:52:40 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 _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 _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 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 do we git clone --depth 1 ? 2019-12-11 12:54:43 <_ikke_> no 2019-12-11 12:54:57 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 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 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 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 time to report 2019-12-11 12:58:05 <_ikke_> At least, once for every user 2019-12-11 14:52:09 is Michael Pirogov here? 2019-12-11 14:52:51 I want to push !2055 and later for perl-redis 2019-12-11 15:55:48 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 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 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 I just wanted to state, busybox requires those 4 paths; so lets be proper, and create all 4 :) 2019-12-11 16:00:17 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 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 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 it should not 2019-12-11 16:03:16 there are plans to add !emptydirs or keepdirs to options="" 2019-12-11 16:22:14 btw "if they are empty" is not what happens 2019-12-11 16:23:40 oh wait 2019-12-11 16:25:03 forgot rmdir command usage 2019-12-11 16:25:09 as you were... 2019-12-11 16:32:53 seems like we currently only delete /usr/lib /usr/bin /usr/share /usr or /etc if empty 2019-12-11 16:32:55 and thats it 2019-12-11 16:33:19 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 Hooray, Laptop arrived (again :P) 2019-12-11 17:50:19 mps: What's the status on FF 71? 2019-12-11 17:59:27 Cogitri: build on aarch64 but fail on x86_64 2019-12-11 17:59:47 Cogitri: hooray for laptop :) 2019-12-11 17:59:48 Okie, gonna test later today 2019-12-11 17:59:55 :) 2019-12-11 18:00:25 <_ikke_> Cogitri: nice 2019-12-11 18:00:30 I can post you patch which worked on aarch64 2019-12-11 18:00:47 Ah, isn't that the one on Gitlab? 2019-12-11 18:01:16 hm, yes 2019-12-11 18:01:23 I forgot it 2019-12-11 18:01:26 :) 2019-12-11 18:02:14 I wasted time on kernel and didn't looked at it in a week 2019-12-11 18:07:06 Okie, looks like I'll have to dump some time into tracker-miners too 2019-12-11 18:07:19 It's failing due to secoomp so this is going to be a really "fun" one :^) 2019-12-11 18:09:13 programming is hard discipline, but we like hard tasks :) 2019-12-11 19:15:48 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 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 and they need a strong reason to be kept (/run or /var/lock are decent candidates) 2019-12-11 19:29:25 oliv3r[m]: I meant to say alpine-baselayout, sorry for confusion 2019-12-11 19:29:59 either/or :) 2019-12-11 19:30:03 it's a requirement for BB, so it should be fixed within bb :) 2019-12-11 19:30:35 agree, and don't understand why these dirs are deleted 2019-12-11 19:31:08 TBH, didn't looked deeply at the issue 2019-12-11 20:35:41 Is Nathan Angelacos in this channel? 2019-12-11 20:36:03 <_ikke_> not at the moment 2019-12-11 20:38:40 okay thanks 2019-12-11 20:56:49 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 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 z3ntu: he almost never is 2019-12-11 21:32:28 I'll just submit a MR with my changes then 2019-12-11 21:32:38 He's the maintainer of the gpsd package 2019-12-11 22:46:19 Or use email 2019-12-12 06:13:12 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 Screenshot: https://usercontent.irccloud-cdn.com/file/fIyAsYbs/Screenshot_20191212_141253.png 2019-12-12 06:17:07 Do you have permission to write to that djr? 2019-12-12 06:57:24 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 Cogitri: Yes, the running user is root (hence the `-F` switch) 2019-12-12 08:15:46 Ah sorry, replied when I just woke up :P 2019-12-12 08:32:57 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 @ncopa gpsd bumped soname, some packages need to be rebuilt 2019-12-12 13:11:57 oh 2019-12-12 13:15:04 I'm on it 2019-12-12 13:16:54 alright 2019-12-12 13:18:21 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 i merged the kernel related things i think 2019-12-12 13:30:34 !1981 2019-12-12 13:30:46 ncopa: ^ 2019-12-12 13:32:42 #11020 2019-12-12 13:33:14 oh, sorry, looks like this is closed few minutes ago 2019-12-12 13:35:11 and, what is policy about MR which can't work and didn't fixed for some weeks? 2019-12-12 14:21:19 I wait for stale bot to close it 2019-12-12 14:22:01 ah, we have stale bot, nice 2019-12-12 14:22:46 do you know after how much time it 'work' 2019-12-12 14:22:55 60 days i think 2019-12-12 14:23:14 thanks for info 2019-12-12 15:58:03 ncopa: I see you pushed change for dtbs-lts, this should be also changed in in aports/scripts 2019-12-12 15:58:51 I'm not sure how to make patch for scripts, like normal patch? 2019-12-12 16:00:18 and what is rationale for using DEVICETREEDIR instead of FDTDIR in mkimg.base.sh 2019-12-12 16:00:31 mkimg.base.sh: DEVICETREEDIR /boot/dtbs 2019-12-12 16:02:00 sorry, missing line number. mkimg.base.sh:107: DEVICETREEDIR /boot/dtbs 2019-12-12 16:11:30 normal patch yes 2019-12-12 16:11:34 not sure 2019-12-12 16:12:53 other distros use FDTDIR 2019-12-12 16:13:47 DEVICETREEDIR is just defined once in u-boot tree, in pxe.c iirc 2019-12-12 16:14:47 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 not that I know, and will be good imo 2019-12-12 17:41:31 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 hehe 2019-12-12 17:43:36 I have dir with notes, but don't look there often 2019-12-12 17:45:01 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 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 ah, curl download. '^M 0' 2019-12-12 17:49:23 but I'm sure yesterday I saw in one log 2019-12-12 17:51:00 or maybe not, and doesn't matter 2019-12-12 17:51:43 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 _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 ok, thanks, I'm cleaning lxc's 2019-12-13 04:11:54 upstream fixed an error and released 1.5.1.corrected, not 1.5.2 2019-12-13 04:11:57 or 1.5.1.1 :D 2019-12-13 07:23:21 ugh, so the checksum is different? 2019-12-13 07:23:25 morning 2019-12-13 07:23:54 \o 2019-12-13 07:24:07 ghc built in my dev env :-/ 2019-12-13 07:29:07 crystal 0.32.0 is released and still fail tests on aarc64 :-\ 2019-12-13 07:42:55 qemu 4.2.0 is released 2019-12-13 08:05:13 mps: Seems like the build failure on x86_64 for FF 71.0 is due to cbindgen 2019-12-13 08:05:32 (Or at least downgrading to cbindgen 0.9.1 gives me a different error afterwards :P) 2019-12-13 08:10:35 Ugh, it manually checks for custom Rust triplets 2019-12-13 08:12:37 Great, you can only export a target JSON (that's required for building FF) on nightly Rustc 2019-12-13 08:12:58 TBH I didn't had time to look deeply at the build issue 2019-12-13 08:13:24 nice that you found it 2019-12-13 08:19:39 Trying another build, let's see if this thing works :) 2019-12-13 08:23:36 my hope is up 2019-12-13 08:41:14 @ncopa no, they literally released a version called '1.5.1.corrected' 2019-12-13 08:53:49 lol 2019-12-13 08:54:13 makes you wonder what the next correction will be named 2019-12-13 08:54:24 correctlycorrected 2019-12-13 09:45:16 x86_64 is 'blocked' by ghc 2019-12-13 09:45:23 builder* 2019-12-13 11:08:54 ncopa: What's the status on a new mkinitfs release? 2019-12-13 11:10:24 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 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 Hm, possibly 2019-12-13 11:12:11 what's the error message you are getting? 2019-12-13 11:14:06 See my comment here: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1885 2019-12-13 11:14:19 That's fixed with older cbindgen 2019-12-13 11:16:43 hm, might not be related if it builds on aarch64 2019-12-13 11:19:15 nmeum: it fails in CI aarch64, but build fine in lxc 2019-12-13 11:19:32 ah 2019-12-13 11:19:35 also, it fail in x86_64 lxc 2019-12-13 11:20:06 not sure what could be reason that if fail in aarc64 CI 2019-12-13 11:20:17 s/if/it/ 2019-12-13 11:20:17 mps meant to say: not sure what could be reason that it fail in aarc64 CI 2019-12-13 11:21:24 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 yes, 1.39 2019-12-13 11:23:48 patch which pass on aarc64 lxc I posted without any change as !1885 2019-12-13 11:26:23 I doubt the Rust 1.39 is the breakage that occurs in FF 71 2019-12-13 11:27:45 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 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 good, I don't have much time these days for it, mostly testing armv7 kernel on some boards 2019-12-13 11:32:20 although, if no one upgrade thunderbird in a day or two I will look :) 2019-12-13 11:33:40 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 ncopa: ^ 2019-12-13 11:36:36 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 currently, 2.0.x (LTS) and 2.1.x are nearly same 2019-12-13 11:39:53 ofc, 2.1.x have some small 'add-ons' 2019-12-13 11:40:08 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 _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 that's the reason I asked 2019-12-13 11:43:06 _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 :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 no clue but there is a list of packages that will be rebuilt in the MR itself 2019-12-13 11:44:24 it includes libreoffice so a lot 2019-12-13 11:44:39 <_ikke_> I set 4h for now 2019-12-13 11:45:11 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 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 Yeah but that means i need to leave the comfort of my commandline 2019-12-13 11:46:45 i might have to make a gitlab-ci-pipeline-restarter with GitLab V4 API 2019-12-13 12:04:20 ncopa, Qemu 4.2 is out 2019-12-13 12:06:35 clandmeter: '08:42 ............. mps| qemu 4.2.0 is released' :) 2019-12-13 12:07:35 clandmeter: ef2829899620c5becb13826891a52a1b1e1af95e 2019-12-13 12:07:40 and #alpine-commits says it is upraded and moved to community 2019-12-13 12:07:55 ehm 2019-12-13 12:08:00 <_ikke_> armhf: failed to build qemu 2019-12-13 12:08:31 :) 2019-12-13 12:08:54 _ikke_: sha512sum: WARNING: 1 of 1 computed checksums did NOT match 2019-12-13 12:10:41 ncopa: please keep that response time ;) 2019-12-13 13:35:33 kernel 5.4.3 is out 2019-12-13 13:42:48 i'm on it 2019-12-13 13:43:09 artok: what is needed to make rpi4 work? 2019-12-13 13:49:05 Hooray, FF builds 2019-12-13 13:53:30 Cogitri: hooray :) 2019-12-13 13:53:49 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 02-testing-firefox-fix-on-x86_64.patch 2019-12-13 13:54:29 (oops, had a newline in the 2nd link, but you get the point :) 2019-12-13 13:55:14 ofc 2019-12-13 14:25:18 waiting for 5.4.3 for a week in hope it will fix boot on exynos :) 2019-12-13 14:30:52 Cogitri: would you consider to take/fix !1885 2019-12-13 14:33:44 Just apply my two patches and it should work :) 2019-12-13 14:35:11 ok, np 2019-12-13 15:00:26 Cogitri: pushed to CI 2019-12-13 15:01:59 ohm, cbindgen should be first downgraded 2019-12-13 15:02:52 (actually, first should go for coffee) 2019-12-13 15:04:12 Hm, if you put the cbindgen commit in front of the FF bump it should work 2019-12-13 15:05:46 to late, I pushed FF commit 2019-12-13 16:03:49 @ikke boost still timed-out but it is very close so i can do the rest manually 2019-12-13 16:04:03 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 what else? 2019-12-13 17:39:49 <_ikke_> ext* perhaps, or at least something that is writable 2019-12-13 17:40:18 you mean read made image for installation 2019-12-13 17:40:34 ready* 2019-12-13 17:41:07 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 yes 2019-12-13 17:42:22 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 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 thanks 2019-12-13 18:21:26 _ikke_: i wonder how to create a disk image with an ext partition without being root 2019-12-13 18:21:39 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 the downside with fat is that it is not resizeable 2019-12-13 18:36:31 it would be nice to know how other distros do it 2019-12-13 18:37:24 i guess we can create a diskimage with a single fat partition and mcopy the files over 2019-12-13 18:38:59 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 armbian have diskimage with boot and small root partition 2019-12-13 18:40:14 isohybrid is what we do now 2019-12-13 18:40:19 on first boot root partition can resized (extended) 2019-12-13 18:40:35 <_ikke_> ncopa: right 2019-12-13 18:41:13 install process is 'dd' to sd card, boot, and resize when it boots 2019-12-13 18:41:39 hum 2019-12-13 18:42:34 we run our root on tmpfs 2019-12-13 18:43:09 we could have a /boot partition and an apks partition 2019-12-13 18:43:21 where apks is ext2 or ext4 2019-12-13 18:43:38 I didn't intended to say that we should do what armbian does 2019-12-13 18:44:20 that way it would be possible to extend the data partition 2019-12-13 18:44:39 but then we need to rewrite setup-bootable 2019-12-13 19:15:38 can you please hold your commits for a sec? I'm about to push 3.11.0_rc2 2019-12-13 19:22:38 ok, here comes rc2 2019-12-13 19:22:45 <_ikke_> :) 2019-12-13 19:23:11 i added rpi4 support 2019-12-13 19:23:29 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 i have v3 2019-12-13 19:38:54 and i have ordered a v4 2019-12-13 19:38:58 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 ncopa: any chance for armhf rpi build :/ 2019-12-13 20:54:08 Cogitri: does gnome take much memory to compile? 2019-12-13 21:09:41 Hm, not that much 2019-12-13 21:09:57 Wait, are you talking about memory == disk space or memory == RAM? 2019-12-13 21:11:38 RAM 2019-12-13 21:12:32 <_ikke_> since when is memory diskspace? 2019-12-13 21:34:47 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 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 Speicher can be translated as both storage or memory 2019-12-13 21:35:58 Speichern is to safe, yes 2019-12-13 21:36:56 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 Cogitri: we have our 128G aarch64 box oom 2019-12-13 21:43:34 we cant really pin point it now 2019-12-13 21:43:53 it killed our qemu runner 2019-12-13 21:43:54 Phew 2019-12-13 21:44:15 not sure how the linux oom killer works. 2019-12-13 21:44:18 How many build jobs does that AArch64 set? 2019-12-13 21:44:37 I think it just kills whatever takes up the most RAM 2019-12-13 21:44:38 ci is not the issue 2019-12-13 21:44:42 its run inside qemu 2019-12-13 21:44:48 qemu itself has been killed 2019-12-13 21:45:00 we use 32G for CI 2019-12-13 21:45:13 so we have 98 left for system 2019-12-13 21:45:26 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 as i mention, its not happening due to CI 2019-12-13 21:45:52 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 they consume the rest of it 2019-12-13 21:46:22 So memory is being overprovisioned? 2019-12-13 21:46:59 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 my guess is that some package spawns processes that use a lot of memory 2019-12-13 21:47:33 so the builders use all the memory that is left 2019-12-13 21:47:43 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 s/that most/the most 2019-12-13 21:48:21 clandmeter meant to say: linux kills the processes that uses the most 2019-12-13 21:56:45 going to upgrade gitlab. will take some time. 2019-12-13 22:07:56 ikke: Oh, okay 2019-12-13 22:08:12 Hm, I don't know what could've consumed that much RAM then, sorry 2019-12-13 22:08:44 I think I only pushed gnome before that and that's a meta package 2019-12-13 22:12:17 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 andypost[m]: gitlab is back 2019-12-13 22:19:37 clandmeter: thank you, looks runners are without ptrace caps so no way to run tests( 2019-12-13 23:18:53 5.4.3 aarch64 boots fine on rpi3, no obvious errors in dmesg 2019-12-13 23:22:56 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 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 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 on rk3399 5.4.x works fine (ok, some quirks with video driver) 2019-12-13 23:34:51 rk3399 based samsung cromebook, I mean 2019-12-14 07:01:14 Oof 2019-12-14 07:01:25 5.4.3 still missing Intel fixes 2019-12-14 07:01:29 Just got the hangup 2019-12-14 08:59:55 north1: for me it happens only when 'working' with firefox, once it is killed by OOM 2019-12-14 09:00:56 now I added swap (beside 4GB of ram) to see what will happen 2019-12-14 09:19:36 north1: still have issues with gitlab api? 2019-12-14 09:21:03 Yes, some rare timeouts due to ssh blocking 2019-12-14 09:21:20 They mostly stopped after I made effort into using https wherever possible 2019-12-14 09:21:27 On gitlab? 2019-12-14 09:22:25 Ah, no issues with gitlab API except it being annoying to use, but I got used to it 2019-12-14 09:23:45 Ok 2019-12-14 09:23:52 That I can't change 2019-12-14 12:34:55 default kernel for 3.11 will be linux-lts ? think so but confirmation would be appreciated 2019-12-14 15:20:22 yes 2019-12-14 15:20:30 that is what i read before 2019-12-14 15:20:40 its in main 2019-12-14 15:20:48 vanilla is in community 2019-12-14 15:23:22 clandmeter: thanks for confirm 2019-12-14 15:23:46 no problem 2019-12-14 15:23:48 I missed move vanilla to community 2019-12-14 15:23:50 your wish is my command 2019-12-14 15:23:59 :) 2019-12-14 15:24:04 Will vanilla still be an option? 2019-12-14 15:24:18 Or rather, before 5.x, 5.x breaks my system 2019-12-14 15:24:50 i think so 2019-12-14 15:25:01 not sure whats on the iso 2019-12-14 15:25:02 I think intention with vanilla is to follow upstream development 2019-12-14 15:25:25 you can always install vanilla from repo 2019-12-14 15:25:34 the downside is out of tree modules 2019-12-14 15:25:45 i dont think ncopa will maintain them for vanilla 2019-12-14 15:25:55 like zfs 2019-12-14 15:26:22 north1: do you know what causes your issue? 2019-12-14 15:26:31 Yes I have an issue on aports 2019-12-14 15:26:38 It should be on top 2019-12-14 15:27:27 !11026 ? 2019-12-14 15:27:35 #11026 2019-12-14 15:27:36 uhm 2019-12-14 15:27:42 ah thats the one :) 2019-12-14 15:27:48 #11026 ? 2019-12-14 15:27:53 Oops :P 2019-12-14 15:28:02 Exclamation Mark is for MRs 2019-12-14 15:28:34 we need some time to 'ingrain' this in brain 2019-12-14 15:29:23 i have not been in -devel much lately due to infra stuff 2019-12-14 15:29:44 i hope to stabilize infra to a level it takes less time 2019-12-14 15:32:09 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 I have 12 GB swap 2019-12-14 15:32:28 That shouldn't be a problem 2019-12-14 15:32:36 huh, then no :) 2019-12-14 15:32:51 Plus my ram usage when I get the hang varies a lot 2019-12-14 15:33:12 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 also I see increase in RAM usage with -lts 2019-12-14 15:34:00 I mean, on x86_64, not on ARM's 2019-12-14 15:35:48 and there are other issues with -lts, lot changed from 4.19 2019-12-14 15:47:09 Hm, I doubt a new kernel would introduce higher ram usage 2019-12-14 15:48:23 tell me after 25 years :) 2019-12-14 15:52:18 Mosaic, web gui browser worked fine in 4MB of RAM 2019-12-14 15:53:11 Mosaic is from what firefox evolved 2019-12-14 16:10:56 And here I sit with 32GB which barely do the trick :P 2019-12-14 16:11:21 Do we have /var/lib/dbus/machine-id in the builders? libhandy needs it for testing 2019-12-14 16:54:09 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 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 Yes, wasn't sure if the runners do though 2019-12-14 17:28:30 I guess I'll push it and go have a look, libhandy isn't terribly expensive to build 2019-12-14 22:32:14 Why is consolekit2 a runtime dependency of bluez? 2019-12-15 14:07:19 in armv7 3.11 rc2 tarball /boot/dtbs files are missing 2019-12-15 14:08:23 probably need !2141 to be applied 2019-12-15 15:14:44 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 inside the certbot directory 2019-12-15 15:54:12 north1, do you think that !1581 can be merged 2019-12-15 15:55:19 no clue, i'll take a look later 2019-12-15 16:00:59 thanks 2019-12-15 19:34:38 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 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 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 The only experience I have with gyp is that I try to stay as far away from projects using it as possible :P