2019-10-01 04:44:35 mps, Cogitri: https://github.com/alpinelinux/aports/pull/11738 2019-10-01 06:33:48 colona: thanks, will look and try to build after finishing $day_job 2019-10-01 06:36:13 looks fine, similar with my changes to firefox-esr 68 for aarch64 and armv7 2019-10-01 06:40:12 actually I posted my fixes few weeks ago here but didn't received any feedback 2019-10-01 06:43:03 ncopa: did you looked at abuild issue with firefox-esr on aarch64 https://gitlab.alpinelinux.org/alpine/aports/issues/10783 2019-10-01 08:09:01 morning 2019-10-01 08:09:16 mps: i think i had a short look at it, but the build faild before that 2019-10-01 08:22:52 ncopa: I just tried to build testing/firefox on aarch64 and it worked 2019-10-01 08:23:04 and, good morning 2019-10-01 08:23:28 will try again firefox-esr with new rust 2019-10-01 08:24:05 maybe new rust will fix issue, I hope 2019-10-01 08:31:25 mps: did you try the PR 11738? 2019-10-01 08:33:35 yes, I think this, but right now I'm afk so can't look to be 100% sure about NR 2019-10-01 08:34:03 this one colona posted this morning 2019-10-01 08:35:03 it will need some minor tweaks, but it works 2019-10-01 08:36:35 mps: can you follow up that PR then? and push whenever it is ready 2019-10-01 08:37:59 ofc, but give me some time to test it, actually it works on my moving computer right now 2019-10-01 12:21:29 If a PR changes a package in multiple commits, do you have to increase the pkgrel by 1 for each commit, or just once for the entire PR? 2019-10-01 12:21:52 <_ikke_> PureTryOut[m]: Just the latter, the builders just rebuild the package once 2019-10-01 12:25:46 But that'll incorrectly increase/decrease the pkgrel when doing reverts and bisects and such 2019-10-01 12:26:29 bisecting doesn't work anyways when you go back in history 2019-10-01 12:27:02 <_ikke_> PureTryOut[m]: when reverting the pkgrel should be increased anyway 2019-10-01 12:30:18 Yeah makes sense. This question came up from a postmarketOS developer and I was wondering 2019-10-01 12:32:30 Can anyone please help me out with this PR? 2019-10-01 12:32:31 https://github.com/alpinelinux/aports/pull/11638 2019-10-01 12:35:25 (CI just needs a retrigger for that one) 2019-10-01 12:36:36 I am not seeing any button to do that 2019-10-01 12:36:40 <_ikke_> Restarted 2019-10-01 12:38:04 rahmanshaber: you can't, the Alpine devs have to do that 2019-10-01 12:38:37 <_ikke_ "Restarted"> thanks. 2019-10-01 12:40:58 rahmanshaber: do note that the IRC bridge does not translate multiline messages and replies well. In majority IRC channels, try to not use Matrix's extended features 2019-10-01 15:39:14 SpaceToast: the amove test suite was very useful. I think we should add a testsuite for abuild 2019-10-01 15:39:23 <_ikke_> +1 2019-10-01 15:39:50 and a `make check` target 2019-10-01 15:39:58 ncopa: glad you found it useful :) 2019-10-01 15:40:37 <_ikke_> and a CI pipeline :-) 2019-10-01 15:41:03 SpaceToast: sorry that i went with another way to implement it though 2019-10-01 15:41:18 that's fine Β―\_(ツ)_/Β― 2019-10-01 18:25:10 >try to not use Matrix's extended features 2019-10-01 18:25:21 even on matrix theyre usually annoying 2019-10-01 18:50:09 Hm, most of them are kinda useful IMHO, but Matrix only dumping a link to long messages on IRC really is pretty bad 2019-10-01 19:33:17 colona: did you tried to build firefox on x86_64 with your changes for aarch64 2019-10-01 19:36:59 I tried it on x86_64 in lxc and it failed 2019-10-01 20:04:03 mps: I don't have anything to test it at the moment, but I think it was working for Cogitri 2019-10-01 20:07:55 I see 3 PR on GH, but none looks consistent 2019-10-01 20:08:40 I think first should be done upgrade to 69 for current arch'es and then add fixes for aarch64 2019-10-01 20:13:25 yeah, feel free to move forward with some other PR or split mine, I can only test on arm64 and it takes 9h for every rebuild, so it's pretty painful to make and test new revisions 2019-10-01 20:14:43 colona: your PR builds fine on aarch64 and resulting firefox works fine 2019-10-01 20:14:52 but not on x86_64 2019-10-02 12:42:57 Please backport pr11717 - it si actually security release 2019-10-02 14:21:29 Anyone care to take a brief look at PR #11731 and tell me if there's anything amiss? 2019-10-02 14:39:18 wsinatra: why you have some -dev pkg's in depends 2019-10-02 14:43:42 I couldn't get the package to actually run without the -dev depends. libdirectfb.so is required, and the webkit2gtk failed to run for me without the -dev 2019-10-02 14:44:09 Open to suggestions to work around that though, it's possible I just ran into a wall and went around it instead of addressing it properly 2019-10-02 14:57:22 interesting. this should be resolved somehow 2019-10-02 14:58:20 Insofar as libfixposix is concerned, it calls the .so directly, and the -dev package produces that file. The normal one produces a .so.3 and a .so.3.2.0. I could just symlink .so.3.2.0 -> .so in /usr/lib, but that seems like a hack 2019-10-02 14:59:17 besides this, does it work well for you, looks interesting and I will probably try it in a few days 2019-10-02 14:59:36 I like it's keyboard interface 2019-10-02 14:59:43 looks promising 2019-10-02 14:59:46 Yeah aside from the weird dependencies it works flawlessly 2019-10-02 15:00:14 is it cpu/ram/disk hungry 2019-10-02 15:00:14 I've been using it for the past few days after I got the package setup, runs better than firefox in my experience 2019-10-02 15:01:09 It doesn't appear to be ram/cpu/disk hungry, though it does tend to use more CPU than any of the others in that list 2019-10-02 15:01:27 if I don't work on fixing firefox right now, and testing linux 5.4-rc I would jump right there to try it 2019-10-02 15:01:40 But I've been using it on a netbook running Alpine edge on a celeron n3050 with 2GB of ram, and nothing but snappy performance all around 2019-10-02 15:02:08 ahm, you bribe me to try right now ;-) 2019-10-02 15:05:18 It's yours! If the package gets merged in haha 2019-10-02 15:05:42 Obviously, part of my eagerness there is sharing it with others. Plus it's common lisp, and I'm all over anything common lisp 2019-10-02 15:08:25 right now you enabled it only on x86_64. this is because sbcl is only this arch I think 2019-10-02 15:12:18 That's correct, it's only x86_64 for that reason 2019-10-02 15:12:38 I plan to expand sbcl's coverage in the future though, so that'll be addressed in the future 2019-10-02 15:12:48 redundant sentence, is redundant 2019-10-02 15:20:32 I don't know much about sbcl, but if no one pushes next in a few days I will try fix it, with your help I hope, and to push it to aports 2019-10-02 15:22:13 hmm, pushes 'next' (it should have less ambiguous name) 2019-10-02 15:26:16 Yeah it is a little ambiguous when you look at it against all of the other packages. next-browser maybe? 2019-10-02 15:27:03 Insofar as SBCL goes my issue is that it requires CLISP currently, which is only available on x86_64. I had started working on getting it ported, but ran into issues with missing dependencies 2019-10-02 15:27:24 Fixed those up, then ran directly into compilation errors, and had to swap over to a more pressing project. Life is hectic 2019-10-02 15:27:58 yes, same here 2019-10-02 15:29:41 It likely won't stop haha, but I can imagine that everyone here who helps with the maintenance/creation of Alpine has it especially hectic 2019-10-02 15:30:01 time to give a chance to 5.4 kernel on this arm chromebook. crossing fingers 2019-10-02 15:33:50 no luck, black screen, will wait for rc3 to try again 2019-10-02 15:34:06 That's sad, was typing good luck as soon as you said it didn't work 2019-10-02 15:34:22 Eventually there'll be parity 2019-10-02 15:35:20 yes, it will work, I'm not in hurry. just wanted to try if it works 2019-10-02 15:35:50 but, that is normal for early rc's, ime 2019-10-02 15:37:21 regarding hectic alpinists, sometimes I work much but sometimes I slow down 2019-10-02 15:39:33 there are a lot of pkgs in my private repo but I didn't pushed them yet, I will when and if someone ask or I'm sure they are useful for other 2019-10-02 15:39:57 What kind of packages do you have in there out of curiosity? 2019-10-02 15:40:01 I prefer to fix bugs and issues in important pkgs 2019-10-02 15:40:37 That's how I initially got started, just building things for the project I'm working on, but then SBCL became unmaintained and I started just pushing what I could 2019-10-02 15:40:55 Honestly, I can appreciate that. The bug fixes and important packages keep the distro stable 2019-10-02 15:41:07 some perl modules, xsettingsd, kbbd switcher, set color temperature are just some of them 2019-10-02 15:42:09 yes, I remember when we talked about your taking of sbcl, few weeks ago iirc 2019-10-02 15:42:21 Definitely stuff that could be useful, but I see the priority 2019-10-02 15:43:11 I can't keep up with what I had for lunch yesterday if I'm being honest, between building my stats timer and trying to get my RHCSA/CE 2019-10-02 15:43:27 I focus way too much on technical projects and just drop all of the other information 2019-10-02 15:45:48 also, my $day_job don't allow me to devote more time for alpine 2019-10-02 15:46:49 I understand that frustration. I trying to juggle a small business and a $day_job. A lot of the time I'm on here is late at night. Or when I'm being coy 2019-10-02 15:50:08 we have also #alpine-offtopic channel for chats not much related to develepment of alpine 2019-10-02 15:51:37 I might have to switch there, everone here is a pleasure to talk to :) 2019-10-02 15:52:48 yes, but channel is for development talk and I don't like to use it much for other chats 2019-10-02 15:53:23 Absolutely agreed 2019-10-02 17:16:30 ping fcolista - re: LXD stabilization, I know they do LTS releases; how does it sound to take the nodejs route? (lxd-lts in community/ is the LTS release, lxd in testing/ is the current release, so that bugs can be fixed ahead of time with the help of weird people that run edge like me) 2019-10-03 06:06:52 SpaceToast, sounds lika a good idea 2019-10-03 09:25:21 Cogitri: I see I just made a duplicate of your vte3 PR.... 2019-10-03 09:25:35 it looks like the python2-dev dependency isn't required anymore 2019-10-03 09:56:40 Is it just me or did the aarch64-edge builder get stuck on the first failure of FF? 2019-10-03 10:00:17 <_ikke_> I see a rust process that's taking 100% cpu 2019-10-03 10:02:04 <_ikke_> No process in the buildlog as far as I can see 2019-10-03 10:02:45 <_ikke_> Cogitri: I killed it 2019-10-03 10:09:42 Thank you 2019-10-03 13:26:44 ncopa: would you mind to post patch you made for main/ell to their ML, they will probably it there 2019-10-03 13:45:59 mps: i suppose i should. 2019-10-03 13:46:09 i need figure out how and where to send it 2019-10-03 13:46:27 mps: i dont mind if you send it 2019-10-03 13:46:33 their ML, with git send-email 2019-10-03 13:47:55 however you want, I can, but I will put you as author, so blames and credits will go to proper address ;) 2019-10-03 13:52:20 what is the email address? 2019-10-03 13:52:49 ELL@LISTS.01.ORG? 2019-10-03 13:53:24 I'm on moving computer right now, will look when I come back home 2019-10-03 13:54:28 hum. apparently i need to join the list to be able to post to it 2019-10-03 13:54:36 but you will have to subscribe there first, iirc 2019-10-03 13:54:37 and there are no instructions on website how to join 2019-10-03 13:54:48 right 2019-10-03 13:58:07 their channel is quiet usually, I didn't noticed that I'm not there 2019-10-03 14:07:57 anyone here using wireguard on Alpine and has very low throughput ? 2019-10-03 14:08:58 alpinenoob: some of us (if not lot of us) but most of us have good throughput 2019-10-03 14:09:10 server is Alpine + openvpn, client is Debian, throughput around 30-50mpbs, with wireguard it's like 1-2mbps 2019-10-03 14:09:30 mps: both client server are alpine or mixed like mine ? 2019-10-03 14:10:09 iiuc, you use wireguard over openvpn? 2019-10-03 14:10:23 my setup is nothing fancy. udp high port, mtu 1420-1460 (same like openvpn) 2019-10-03 14:10:24 no no 2019-10-03 14:10:25 lol 2019-10-03 14:11:01 I'm comparing througput in wireguard vs openvpn 2019-10-03 14:11:20 aha, my ' mtu 1420' 2019-10-03 14:11:33 but I tried both 2019-10-03 14:12:00 mps: do you mind if pasting me your wg config on both ends ? 2019-10-03 14:12:41 I used some time WG between alpine and debian but it worked fine, also 2019-10-03 14:12:49 but, it's dead simple. I believe I can't screw that up. Once used wg.conf, but now I change all to cmdline 2019-10-03 14:13:19 # ip link add dev wg0 type wireguard 2019-10-03 14:13:24 np, tpaste.us is best paste service 2019-10-03 14:13:35 # ip addr add 10.0.0.1/24 dev wg0 2019-10-03 14:14:25 # wg set wg0 listen-port 12345 private-key /path/to/pri-key peer allowed-ips 0.0.0.0/0 endpoint remote:12345 2019-10-03 14:14:26 you can look here https://wiki.alpinelinux.org/wiki/Configure_a_Wireguard_interface_(wg) 2019-10-03 14:14:37 if you didn't already 2019-10-03 14:15:37 mps: thanks man, gotta off vpn now 2019-10-03 14:16:13 that is how I setup it nowadays, earlier I also used 'ip' 2019-10-03 14:16:38 but anyway, from the beginning it worked fine for me 2019-10-03 14:17:43 iirc, I'm using it about two years 2019-10-03 15:12:06 mps: https://wiki.alpinelinux.org/wiki/Configure_a_Wireguard_interface_(wg) 2019-10-03 15:21:31 clandmeter: I think I posted above this link too 2019-10-03 16:37:29 I updated it 2019-10-03 16:38:46 ah, so, didn't noted that. just posted it to alpinenoob 2019-10-03 21:29:40 will some push !279 2019-10-03 21:29:57 need it for tcpdump upgrade 2019-10-04 09:31:49 Hi rnalrd, any plan to move ntop to ntopng ? 2019-10-04 09:40:34 clandmeter: could you check real quick what is mtu you are using for your wireguard setup ? 2019-10-04 09:40:57 still can't figure out why my wireguard is damn slow 2019-10-04 09:44:26 i have no more wg running atm 2019-10-04 09:52:47 mps: if you have a moment, https://tpaste.us/nMY6. thanks 2019-10-04 10:11:40 tmhoang: sorry, long phone call 2019-10-04 10:13:54 holly, if i let wget running for like 5 min, it max out my local connection 2019-10-04 10:15:34 I could try later to find my debian config of wg in archive, if i didn't deleted it 2019-10-04 10:20:22 tmhoang: did you tried config which clandmeter described on alpine wiki 2019-10-04 10:21:24 I did 2019-10-04 10:22:25 and? same? 2019-10-04 10:23:26 yes, same. if I let wget running for like 5 min, it max out my connection to 160mbps (server has more bandwidth than my line). So I think the config is ok, something either on the vps side or in Alpine side. 2019-10-04 10:24:48 did you tried to speed with iperf 2019-10-04 10:25:04 test speed* 2019-10-04 10:25:15 iperf test sucks, both openvpn + wg shows 8-10mpbs 2019-10-04 10:27:10 have no idea, it always worked very good for me 2019-10-04 10:28:45 <_ikke_> Sounds like tcp window ramping up very slowly 2019-10-04 10:29:26 maxice8: are you still alive? 😱 2019-10-04 10:29:54 <_ikke_> PureTryOut[m]: He is away 2019-10-04 10:30:02 His laptop is in repair right now 2019-10-04 10:30:14 <_ikke_> ah, that's anoying 2019-10-04 10:30:41 Yup :/ 2019-10-04 10:31:46 Gotta send my laptop to repair too soon since bright pictures burn into my screen, let's see if I can borrow a laptop somewhere for the time it's in repair 2019-10-04 10:31:48 Note to self: Don't buy HP :P 2019-10-04 10:33:07 after my years at HP... no need to worry about that 2019-10-04 10:34:00 Ah damn. Basically maxice8 being away means my patches just aren't merged anymore... 2019-10-04 10:34:15 <_ikke_> PureTryOut[m]: I can take a look 2019-10-04 10:35:32 https://lists.alpinelinux.org/~alpine/aports/patches/3087, https://lists.alpinelinux.org/~alpine/aports/patches/3085, https://lists.alpinelinux.org/~alpine/aports/patches/3082 and https://lists.alpinelinux.org/~alpine/aports/patches/3081 2019-10-04 10:35:58 <_ikke_> It's hard to see there what patches have been merged already and which haven't 2019-10-04 10:37:45 Yeah ddevault is still working on that 2019-10-04 10:37:52 PureTryOut: Well, if you do PRs/MRs I'll look at them 2019-10-04 10:37:57 But the 4 I linked are the only ones from me that haven't been merged yet afaik 2019-10-04 10:38:04 But I don't want to use the ML without CU to be frank 2019-10-04 10:38:10 s/CU/CI/ 2019-10-04 10:38:10 Cogitri meant to say: But I don't want to use the ML without CI to be frank 2019-10-04 10:38:41 Understandable, but I prefer the ML currently 2019-10-04 10:39:22 <_ikke_> I prefer GL, which is where I'm mostly active atm 2019-10-04 10:40:02 +1 for GL 2019-10-04 10:40:41 will someone push !279 2019-10-04 10:40:53 _ikke_: ^ 2019-10-04 10:41:12 <_ikke_> Probably someone will ;-) 2019-10-04 10:41:28 need it built to post tcpdump upgrade 2019-10-04 10:41:48 to test and post, I mean 2019-10-04 10:41:50 <_ikke_> I'll look at it after I'm finished with the ones from PureTryOut[m] 2019-10-04 10:42:35 <_ikke_> PureTryOut[m]: https://lists.alpinelinux.org/~alpine/aports/patches/3081 does not apply 2019-10-04 10:43:17 <_ikke_> Not sure why 2019-10-04 10:43:42 <_ikke_> error: patch failed: community/plymouth/APKBUILD:1 2019-10-04 10:44:08 Huh. I'll rebase it, maybe that helps 2019-10-04 10:45:31 <_ikke_> PureTryOut[m]: the others have been merged 2019-10-04 10:45:48 hey guys, I have sent 4 patches for a new gnunet package to the aport mlist. Could somebody tell my please what comes next? How long have I to wait for feedback? 2019-10-04 10:46:21 (missing word: have) 2019-10-04 10:46:24 <_ikke_> xrs: not a lot of devs actively look at the aports mailing list to be honest 2019-10-04 10:46:43 ok, how does this work, then? 2019-10-04 10:47:12 <_ikke_> xrs: If you paste the links to the patches (from https://lists.alpinelinux.org/~alpine/aports), I'll try to look at them 2019-10-04 10:47:20 Uhm, `git send-email` fails currently. I'll make a MR instead for now _ikke_ 2019-10-04 10:47:28 <_ikke_> PureTryOut[m]: alright 2019-10-04 10:47:29 cool! just a moment 2019-10-04 10:47:52 <_ikke_> mps: abuild complains about static files without a -static subpackage 2019-10-04 10:48:18 _ikke_: https://lists.alpinelinux.org/~alpine/aports/patches/3080 2019-10-04 10:49:17 the main packages are gnunet and gnunet-gtk, the need additional ones, libidn2 and gnurl, which I have packaged, too 2019-10-04 10:50:29 <_ikke_> xrs: libidn2 is already present in main 2019-10-04 10:50:36 <_ikke_> https://pkgs.alpinelinux.org/packages?name=libidn2&branch=edge 2019-10-04 10:50:59 <_ikke_> I can just drop the patch 2019-10-04 10:51:15 ok, fine :) 2019-10-04 10:53:02 _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/281 2019-10-04 10:53:32 <_ikke_> PureTryOut[m]: thanks 2019-10-04 10:53:45 <_ikke_> I have to go back to work now, I'll continue after that 2019-10-04 10:56:44 _ikke_: libpcap, but it builds on CI 2019-10-04 10:57:07 ok, see you later 2019-10-04 10:57:52 Would be great to commit pr11525 and related backports 2019-10-04 11:00:54 PureTryOut: don't worry, my computer repairshop is taking quite long so I'll most likely bust out my old laptop 2019-10-04 11:02:33 maxice8: good day :) 2019-10-04 11:03:31 maxice8: haha it's fine. It's just that you are the one merging everything quite quickly so I have to get used to the slower pace now πŸ˜‰ 2019-10-04 11:04:52 mps: hopefully 2019-10-04 11:06:00 oh, maybe it is language semantic difference. I wish to you good day 2019-10-04 11:06:24 mps: I know I'm just frustrated atm 2019-10-04 11:06:26 Good day to you as well 2019-10-04 11:07:06 ah, ok. 2019-10-04 11:07:29 maybe it is sometimes good to be without computer 2019-10-04 11:08:02 this morning I damned day when I decided to by my first computer :D 2019-10-04 12:07:00 _ikke_: do we need -static subpackage for libpcap? 2019-10-04 12:07:20 <_ikke_> mps: The alternative is to disable the static build 2019-10-04 12:08:02 I'd prefer to put static libs in -dev :P 2019-10-04 12:11:42 <_ikke_> Well, apparently the choice was made to split them out 2019-10-04 12:12:49 we should fix this, imo 2019-10-04 12:13:38 ofc, we should discuss this before making changes 2019-10-04 12:13:47 <_ikke_> What is there to fix? It's a subjective opinion whether they belong in -dev or be separated out 2019-10-04 12:14:11 <_ikke_> And that change was fairly recently made to split them out 2019-10-04 12:14:30 <_ikke_> Ofcourse you can start a new discussion whether that was a good choice or not 2019-10-04 12:14:42 yes, every opinion (which is not imposed to us) is subjective 2019-10-04 12:15:11 afaik, all other distros put static libs in -dev 2019-10-04 12:15:37 <_ikke_> mps: in alpine it's a lot more common to split things out compared to other distros 2019-10-04 12:16:45 ok, I don't mind about this to much, but -static naming is missleading to some degree 2019-10-04 12:17:25 you know 'curl-dev' and 'curl-static' 2019-10-04 12:17:38 <_ikke_> yes, there is now a confusion between static libs and statically built programs 2019-10-04 12:18:16 what about 'curl-dev-static' 2019-10-04 12:18:41 'static-curl-dev' sound bad 2019-10-04 12:18:59 and 'curl-static-dev' also 2019-10-04 12:26:55 could someone try the current virt-iso in qemu? 2019-10-04 12:27:09 not sure if broken or just slow 2019-10-04 12:29:14 mh, just slow because i dont have kvm 2019-10-04 13:16:19 ncopa: how do you want to handle the recent go security update? i.e. go packages are still vulnerable to CVE-2019-16276 until they are recompiled 2019-10-04 13:18:12 <_ikke_> nmeum: A new one? 2019-10-04 13:18:25 <_ikke_> I recall someone recompiling almost any go package due to a CVE 2019-10-04 13:18:29 <_ikke_> a couple of weeks ago 2019-10-04 13:18:31 yeah, that was me 2019-10-04 13:18:36 <_ikke_> right 2019-10-04 13:18:40 <_ikke_> I guess the same way? 2019-10-04 13:19:02 yes, that's go 2019-10-04 13:19:10 <_ikke_> that's static compiling for you 2019-10-04 13:19:13 rebuilding all of them was pretty annoying last time 2019-10-04 13:19:34 some heuristic to figure out which packages are effected would be neat 2019-10-04 13:20:03 if the problem in std go libs then all 2019-10-04 13:20:52 if in some third party libs/package then only those which depeneds on it 2019-10-04 13:21:14 well, it seems to be an issue with the net/http package from the standard library 2019-10-04 13:21:33 but only the aport which actually import the net/http package (directly or indirectly) should be affected 2019-10-04 13:21:36 *aports 2019-10-04 13:21:55 I wonder how other distributions handle go security updates 2019-10-04 13:21:57 could it be somehow checked which packages uses it (net/http) 2019-10-04 13:22:36 afaik, usually by rebuild 2019-10-04 13:23:08 https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/docker&id=17a8e30165cf6909d064d95a254fd29525935baa 2019-10-04 13:23:10 looks like it 2019-10-04 13:24:33 https://www.archlinux.org/todo/golang-staticlibs-security-rebuild/ 2019-10-04 13:25:13 yes 2019-10-04 13:29:38 here's a PR rebuild all go packages https://github.com/alpinelinux/aports/pull/11773 2019-10-04 13:29:51 quite a lot to be honest 2019-10-04 14:16:15 nmeum: thats why we dont do static complie, and thats why i dont like go 2019-10-04 14:17:36 <_ikke_> We don't track dependencies for go packages, so you would need to unpack all these projects and find the dependencies it uses 2019-10-04 14:18:12 well…the CVE is a package which is part of the standard library 2019-10-04 14:18:16 *is in 2019-10-04 14:18:41 β†’ it is not a dependency that would normally be tracked by abuild anyways 2019-10-04 14:18:45 <_ikke_> Right 2019-10-04 14:18:54 <_ikke_> But you could see whether they import it, right? 2019-10-04 14:19:08 <_ikke_> or is that just always available? 2019-10-04 14:19:41 from a go language perspective you need to import it, yes. e.g. with `import "net/http"` 2019-10-04 14:19:45 Let's hope LLVM9 doesn't blow up the builders 2019-10-04 14:19:54 <_ikke_> nmeum: right, that's what I meant 2019-10-04 14:20:20 _ikke_ I think it's better to be on the safe side and just rebuild everything instead of greping all sources 2019-10-04 14:20:58 we could check if there is tooling to figure out if given source code imports a given package 2019-10-04 14:21:01 that should be possible after all 2019-10-04 14:21:01 <_ikke_> Was just trying to see if it was possible to find the minimal set of packages where it would be necessary 2019-10-04 14:21:47 what makes it more difficult is that a given package might indirectly import "net/http" e.g. through a library it depends on 2019-10-04 14:22:06 but there might be tooling which also handles this edge case 2019-10-04 14:23:56 i think the information is in the compiled binary 2019-10-04 14:24:04 so in theory it should be possible to track it 2019-10-04 14:24:58 it should be possible to strings | grep the binary 2019-10-04 14:25:03 binaries 2019-10-04 14:25:27 Cogitri: i built the llvm9 on my machine first 2019-10-04 14:25:33 foudn a couple of breakages 2019-10-04 14:25:45 Oh? :o 2019-10-04 14:27:22 ncopa: we strip go binaries nowadays, they shouldn't contain any debug symbols anymore 2019-10-04 14:27:39 What breakage? 2019-10-04 14:27:39 It worked for me on my laptop for a few days now 2019-10-04 14:28:10 bcc and rust 2019-10-04 14:28:23 Huh, weird, both compiled fine for me 2019-10-04 14:28:28 i think bcc broke due to abuild git master 2019-10-04 14:28:56 and runst broke due to llvm-libunwind-static has been splitted out 2019-10-04 14:29:04 libunwind.a was missing 2019-10-04 14:29:29 in any case, it was trivial fixes 2019-10-04 14:31:04 Oh, yeah, I think I only bumped llvm-libunwind after rebuilding rust, my bad 2019-10-04 14:31:05 PureTryOut: dusting out old notebook 2019-10-04 14:31:09 Thanks for taking a look! 2019-10-04 14:31:18 Intel Atom 2GB RAM 2019-10-04 14:31:30 Oh damn lol 2019-10-04 14:31:46 Cogitri: thanks for doing the work with llvm9. i just did a test build 2019-10-04 14:32:00 nmeum: cockroach fails to build 2019-10-04 14:34:36 It isn't turning on 2019-10-04 14:35:51 ncopa: hm, indeed. will investigate 2019-10-04 14:36:23 cc1plus: all warnings being treated as errors 2019-10-04 14:36:34 smells like gcc9 has some new warnings 2019-10-04 14:37:36 yeah 2019-10-04 14:37:44 just passing -Wno-error would work 2019-10-04 14:39:27 testing if it builds with that … 2019-10-04 15:48:07 go-ipfs fails too 2019-10-04 16:07:37 ncopa: ok, will look into that as well thanks 2019-10-04 17:46:15 I'm preparing main/tcpdump upgrade which have a lot of CVE's fixes. Should all they be added to APKBUILD? here is changelog http://www.tcpdump.org/tcpdump-changes.txt 2019-10-04 17:47:33 Sure, why shouldn't they be added? 2019-10-04 17:48:06 I noticed that CVE notes are not added for 4.9.2 2019-10-04 17:49:12 <_ikke_> You can retroactively add them 2019-10-04 17:49:32 rewrite git history? 2019-10-04 17:50:01 <_ikke_> no 2019-10-04 17:50:09 <_ikke_> just add them in the APKBUILD 2019-10-04 17:50:17 ah 2019-10-04 17:51:14 really? then we will have to do this for not small number of packages, I think 2019-10-04 17:51:36 but, ok, I will follow your advice this time 2019-10-04 17:52:05 <_ikke_> mps: This is often done oportunistically, rather then comprehensive 2019-10-04 17:52:49 yes, I know, just grumble a little 2019-10-04 17:53:27 although I think we should not keep CVE's in APKBUILD 2019-10-04 17:54:18 <_ikke_> Do you have a better idea? 2019-10-04 17:54:18 another question about this, CVE's is 'space indented' not tabs 2019-10-04 17:54:30 <_ikke_> probably because the format is yml 2019-10-04 17:54:51 yes, looks like yaml 2019-10-04 17:55:24 better idea, not sure. maybe some external DB for this 2019-10-04 17:56:57 <_ikke_> Something like this? https://git.alpinelinux.org/alpine-secdb/tree/ 2019-10-04 17:59:51 aha, didn't know for it. thanks 2019-10-04 18:01:43 skimming over it, it scans APKBUILD's and build yaml files with CVE's? 2019-10-04 18:02:04 <_ikke_> yes 2019-10-04 18:02:10 nice 2019-10-04 18:02:34 now I understand why we need to put CVE's to APKBUILD 2019-10-04 18:04:25 _ikke_: I just made upgraded APKBUILD for tcpdump, would you mind to look at it and review because I keep description of CVE's from upstream changelog 2019-10-04 18:04:57 <_ikke_> Yes, I'm currently reviewing another patch series, will look at it later 2019-10-04 18:05:07 http://tpaste.us/lZqo 2019-10-04 18:05:25 <_ikke_> quite a lot of CVEs 2019-10-04 18:05:39 don't know if these extra data needed 2019-10-04 18:05:51 <_ikke_> me neither 2019-10-04 18:06:33 do we have someone from 'security team' here? 2019-10-04 18:10:04 <_ikke_> apparently not atm :) 2019-10-04 18:11:24 so, I will create MR as it is now, and see if someone have objection to this change 2019-10-04 18:11:54 extra fields after CVE numbers, I mean 2019-10-04 18:12:17 and 'make check' works now, have to test it on armv7 2019-10-04 18:13:53 ncopa: go-ipfs seems to have some issues with the new module system introduced in go 1.13 would probably just include it from the rebuild for now. did anything else fail to build? 2019-10-04 18:13:58 cockroach was fixed 2019-10-04 18:23:48 uhm, tcpdump check failed on ppc64le 2019-10-04 18:25:28 anyone have ppc64le box to test one failed test 2019-10-04 18:25:44 why it failed 2019-10-04 18:33:46 <_ikke_> texlive seems broken by the recent poppler upgrade 2019-10-04 18:35:38 there is patch on ML for texlive, iirc 2019-10-04 18:35:48 didn't had time to review it 2019-10-04 18:36:48 <_ikke_> I see, thanks 2019-10-04 18:36:53 <_ikke_> so many places to look :-) 2019-10-04 18:37:13 (and a lot of things are broken now, by my perception) 2019-10-04 18:37:51 yes, hope that all move to one place ;-) 2019-10-04 18:38:21 <_ikke_> Seems like that patch was already applied 2019-10-04 18:38:24 your CI is fantastic 2019-10-04 18:38:45 <_ikke_> oh, no, sorry 2019-10-04 18:38:54 <_ikke_> mps: thanks 2019-10-04 18:38:56 yes! 2019-10-04 18:39:50 I think to use it for packages which I can push directly to aports but not sure is this ok, i.e. to not overuse resources 2019-10-04 18:39:52 <_ikke_> I'll just create merge requests myself for patch from the mailing list 2019-10-04 18:40:42 oh, and that is about I contemplated yesterday, take patch from ML and create MR 2019-10-04 18:41:57 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/283 2019-10-04 18:43:11 how you add these two source: url's 2019-10-04 18:43:18 <_ikke_> Just copy paste 2019-10-04 18:43:48 aha 2019-10-04 18:44:24 KISS 2019-10-04 18:44:50 uhm, KISS principle 2019-10-04 18:45:20 <_ikke_> indeed 2019-10-04 18:45:57 best principle 2019-10-04 18:55:12 oh, just learned how to update MR, 'git push --force mps' 2019-10-04 18:55:26 <_ikke_> :-) 2019-10-04 18:55:52 and CI pass now, with disabled check though 2019-10-04 18:57:23 should these fixes for tcpdump (and libpcap) need to be backported to stable? 2019-10-04 18:58:38 <_ikke_> If they are security fixes, they should 2019-10-04 18:58:51 <_ikke_> and even bugfixes can be backported to 3.10 2019-10-04 18:58:53 you saw a long list 2019-10-04 18:58:56 <_ikke_> Yup 2019-10-04 18:59:49 ok, will prepare libpcap first for 3.10 and after it is pushed will prepare tcpdump 2019-10-04 19:00:19 <_ikke_> and 3.10 should have CI now as well 2019-10-04 19:00:28 but have to work on new clamav and crystal 2019-10-04 19:21:13 hi, so I did a PR towards aports, and the travis CI job got a timeout while trying to download the source from github, should I do something about it? 2019-10-04 19:22:27 <_ikke_> xerireu: What PR? 2019-10-04 19:22:52 _ikke_: https://github.com/alpinelinux/aports/pull/11779 2019-10-04 19:23:56 <_ikke_> I restarted it 2019-10-04 19:24:43 thanks 2019-10-04 19:35:01 <_ikke_> ok, done with the review 2019-10-04 21:35:11 I build new clamav 0.102.0 with some added fixes, but it have some other issues. for example slowdown in loading signatures 2019-10-04 21:36:15 so, not sure should I make MR for it as it is now, or we should wait 2-3 weeks to be fixed on next update, as clamav devs told me 2019-10-04 21:36:33 or to make MR with WIP tag? 2019-10-04 21:39:32 <_ikke_> the latter you can always do 2019-10-04 21:40:14 I don't like it to be pushed to aports in current state 2019-10-04 21:41:14 it needs some bug fixes and improvements, because that I ask what to do 2019-10-04 21:42:07 and it would be bad if someone with 'push without check' attitude make PR/MR and push blindly 2019-10-04 21:42:39 although it will go to edge, it is not always good to 'break' things 2019-10-04 21:44:51 <_ikke_> agreed 2019-10-04 21:45:04 <_ikke_> a WIP MR should be indication enough that it should not be pushed yet 2019-10-04 21:45:53 ok, I know who give best advises :) 2019-10-04 21:45:58 thanks 2019-10-04 21:46:31 but it is to late, going to bed, good night all 2019-10-04 21:46:45 <_ikke_> o/ 2019-10-05 08:19:15 Hi, I'm new to making APKBUILDs and I'm wondering if there's a common issue where a manual "make" on source works, but "abuild build" seems to have a problem finding local header files. This is built with clang++ BTW. 2019-10-05 08:22:58 You'll need `clang-dev` installed for that 2019-10-05 11:04:40 ncopa _ikke_: regarding go rebuilds, what does seem to be possible is using `go list -f '{{.Imports}}' ./... | grep "net/http"` to figure out which packages are affected by the CVE 2019-10-05 11:04:58 however, that requires GOPATH to be setup correctly and depending on the buildsystem used by the package that might not be the case 2019-10-05 12:36:49 Cogitri: I do have clang-dev installed. It's also in my APKBUILD's makedepends. 2019-10-05 12:46:04 Huh, mind spinning me a log? 2019-10-05 12:53:29 Cogitri: https://pastebin.com/Yma2YLgL 2019-10-05 12:54:48 I guess it's missing a `-I src/util` to include the header file 2019-10-05 12:55:25 Hm, but the manual make progresses through it fine. Does abuild need extra args for that? 2019-10-05 12:57:18 That shouldn't be the case, maybe it doesn't like the env variables abuild sets? (e.g. CFLAGS) 2019-10-05 12:57:37 My build() is just: cd "$builddir" && make 2019-10-05 13:21:38 Yes, abuild sets those flags automatically 2019-10-05 13:21:40 Also, no need to cd builddir anymore 2019-10-05 13:24:26 Hm, so I need to tell abuild to not set the various environment variables? 2019-10-05 13:24:46 Also, thank you for the builddir tip. 2019-10-05 13:28:52 No, you need to fix that package's build system :) 2019-10-05 13:29:23 abuild only sets pretty standard variables which about every other package builder sets too 2019-10-05 13:30:08 Hm, I wonder if the Makefile is being problematic for abuild. 2019-10-05 13:31:04 This is the Makefile I'm dealing with: https://github.com/avaraline/Avara/blob/master/Makefile 2019-10-05 13:52:17 Hm, not a Makefile wizard, but I'm pretty sure that using the CPPFLAGS and INCFLAGS setup is wrong 2019-10-05 13:53:22 They should make those read only (as in put them in a seperate variable), as one doesn't want to override those with env variables 2019-10-05 13:54:19 Ah, will look into that. Thanks. 2019-10-05 13:55:59 Wow, just changing those did it. Thanks! 2019-10-05 13:56:59 Be sure to tell upstream about it (and maybe make a PR) 2019-10-05 13:58:20 Yeah, I'm trying to understand the best practice so I can actually communicate it to them. 2019-10-05 13:58:36 Please can anyone merge it 2019-10-05 13:58:37 https://github.com/alpinelinux/aports/pull/11638 2019-10-05 14:00:30 what is this core* suite 2019-10-05 14:03:25 Related to this it seems? https://gitlab.com/cubocore 2019-10-05 14:06:16 shrizza: yes. 2019-10-05 14:06:26 ah, yet another UI 2019-10-05 14:06:54 but diffrent. 2019-10-05 14:07:44 agree, I noticed it in aports and thought to look at it but never found enough time 2019-10-05 14:08:22 shrizza: rahmanshaber[m]: thanks for info 2019-10-05 14:09:05 mps: 2019-10-05 14:09:15 ACTION uploaded an image: pic3.png (787KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/SnGbhLySCPmYuantQdhghZdN > 2019-10-05 14:09:20 does it work well under awesome WM 2019-10-05 14:11:36 mps: yes. no relation with anything. works on everything. from 3.5'' to 32'' display, touch is also we focused on. 2019-10-05 14:11:48 * mps: yes. no relation with anything. works on everything. from 3.5'' to 32'' display, touchDisplay is also we focused on. 2019-10-05 14:13:47 just reading about it on site. looks like it is good for small touch screen devices 2019-10-05 14:16:24 yes. We wanted to fill the gaps that linux dose not have that much app for touch based devices. it is not only ment for touch, desktop is also our focuse. light and takes less ram. less that lxde apps i think. 2019-10-05 14:18:27 thanks, probably will try on my touchscreen chromebook 2019-10-05 14:18:45 I think it would be useful in tablet mode 2019-10-05 14:23:14 mps: We are here if you need us 2019-10-05 14:23:15 https://matrix.to/#/!FjawFZWMgoJDdxZBXY:matrix.org?via=matrix.org&via=disroot.org&via=t2bot.io 2019-10-05 14:24:31 yes, I see on your site that you use matrix for chat 2019-10-05 14:53:38 Cool 2019-10-05 14:54:09 OK, I think I got a handle on this Makefile thing. Thanks a lot Cogitri. 2019-10-05 14:54:13 Might take a look this evening if I'm a bit better until then 2019-10-05 14:54:54 Nice :) 2019-10-05 14:55:36 rahmanshaber: Dunno if it's just me but that link doesn't work for me 2019-10-05 14:56:14 the room link? 2019-10-05 14:56:17 Cogitri: 2019-10-05 14:56:43 You probably need a matrix client. 2019-10-05 14:56:43 Yup, but maybe that's just on Riot mobile 2019-10-05 14:57:40 Cogitri: Try 2019-10-05 14:57:41 https://riot.im/app/#/room/#cubocore:matrix.org 2019-10-05 14:58:49 Manually joining worked, I guess clicking the link doesn't cut it for Riot mobile 2019-10-05 14:58:56 Thanks 2019-10-05 15:06:45 Cogitri: I used official way to do it. I guess that did not worked 2019-10-05 15:39:30 Cogitri: could you upgrade `gnome-terminal` and enable it for all arm architectures (if it works there)? 2019-10-05 15:39:53 I'm currently waiting for someone with the magic bits to merge the vte3 upgrade 2019-10-05 15:40:02 Once that's through I'll push gnome-terminal, sorry for the hold up 2019-10-05 15:40:23 Ah no problem thanks! 2019-10-05 15:40:37 And https://github.com/alpinelinux/aports/pull/11234 does enable more arches :) 2019-10-05 15:41:18 Ah awesome! 2019-10-05 16:46:06 which is now default llvm on edge, llvm9 or llvm8 2019-10-05 16:49:51 or, what I need to linker to solve this 'zig_clang_cc1as_main.cpp:(.text+0x2a98): undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()' 2019-10-05 16:51:55 llvm9 2019-10-05 16:52:12 And I guess you'll have to rebuild zig 2019-10-05 16:52:59 you have it? 2019-10-05 16:52:59 Weird that apk didn't show it when I searched for stuff that linked against clang though :o 2019-10-05 16:53:37 I mean, you have zig built on alpine? 2019-10-05 16:55:04 I think I have to pass -lstdc++ somehow to cmake but don't know how 2019-10-05 17:17:16 Oh no, I thought it's in the repos 2019-10-05 17:17:21 Well, I guess that explains it then :) 2019-10-05 17:17:35 I guess zig doesn't build against clang9 yet 2019-10-05 17:17:46 no, I trying to build it 2019-10-05 17:17:57 And you can't mix llvm8 w/ clang9 in case you're doing that 2019-10-05 17:18:06 it build but have issue in linking 2019-10-05 17:18:23 no, I'm using clean lxc 2019-10-05 17:19:09 zig 0.5.0 builds with llvm9 according to upstream 2019-10-05 17:19:55 but I don't know much about cmake, how to set it's build options 2019-10-05 17:21:01 Ah, I don't know CMake that well either, but that issue definitely is about not finding some symbol from CLang 2019-10-05 17:21:20 Maybe it'd be best to ask upstream about it 2019-10-05 17:22:00 yes, that is in link phase, but wait a moment 2019-10-05 17:22:38 first error is '-- Could NOT find CLANG (missing: CLANG_LIBRARIES)' 2019-10-05 17:23:00 although clang-libs are installed 2019-10-05 17:24:06 and also '-- Could NOT find LLD (missing: LLD_LIBRARIES)' and it installed 2019-10-05 17:24:37 so, I presume I need to tell cmake somehow where to find all these 2019-10-05 17:25:24 Hm, it should find clang.cmake automatically 2019-10-05 17:27:28 'clang.cmake', apk-file didn't found it 2019-10-05 17:29:10 Ah, it's ClangConfig.cmake 2019-10-05 17:29:21 aha 2019-10-05 17:32:42 ok, they have channel on freenode, will ask there 2019-10-05 17:33:18 btw, anyone working on packaging dart language 2019-10-05 17:33:32 <_ikke_> nope 2019-10-05 17:33:36 <_ikke_> not me ;-) 2019-10-05 17:34:15 I need it for alpine for android development 2019-10-05 17:35:19 hm, on alpine for android development* 2019-10-05 17:43:21 anyone knows why this is happening? 2019-10-05 17:43:32 ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/ukwDJjQVrUUifmVoSuOylyzk > 2019-10-05 17:43:44 mesa-git-dev provides these 2019-10-05 17:45:37 I guess you've pinned mesa-dev? 2019-10-05 17:45:39 maybe `apk upgrade -a` does the trick 2019-10-05 17:46:48 boom, got the main package installed, still cant get the dev package to install because of the same error 2019-10-05 17:47:06 ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/AVqWhqHwtOWuwDHBnPbmXUGQ > 2019-10-05 17:51:49 Ah, mesa-git is another package, got it 2019-10-05 17:51:50 and yes, mesa-git-dev provides mesa-dev, so i assume it should know that and let it install 2019-10-05 17:51:57 Thought that was just the version somehow :P 2019-10-05 17:52:34 yep 2019-10-05 17:52:51 Yup 2019-10-05 17:53:28 the thing here is that the package is that it conflicts with mesa-dev 2019-10-05 17:53:51 which i already have the dev package of the git version installed, and that one provides mesa-dev 2019-10-05 21:11:01 zig language developer told me that they use alpine docker to build it with every ci commit 2019-10-05 21:25:10 Neat, but doesn't bring us closer to the solution unless they use edge 2019-10-05 21:25:25 I'd guess it's on them not being compatible with CLang 9 2019-10-05 21:26:17 does anyone know a good APKBUILD example where makedepends is arch dependent? 2019-10-05 21:29:31 Cogitri: here is their docker file https://github.com/ziglang/docker-zig 2019-10-05 21:38:35 qa3Txu0iak0F: Just do a `case "$CARCH"` and do `makedepends="$makedepends moredeps"` for that arch 2019-10-05 21:39:22 mps: Huh, so they do use llvm9 and clang9 but compile it themselves 2019-10-05 21:39:37 thanks! that's exactly what i did. 2019-10-05 21:39:39 ;) 2019-10-05 21:44:31 Cogitri: yes, they started this before you pushed llvm9 2019-10-05 21:45:42 btw, how can I add '-fPIC' to cmake options 2019-10-05 21:46:15 I have this ' `.rodata.cst16' can not be used when making a PIE object; recompile with -fPIC' 2019-10-05 21:49:08 CFLAGS="-fPIC", as usual 2019-10-05 21:49:18 Or if it's a C++ project CXXFLAGS 2019-10-05 21:50:06 I did this '-DCMAKE_CXX_FLAGS="$CXXFLAGS -fPIC"' but without luck 2019-10-05 21:54:48 btw, I built zig executable, but need to finish with rest 2019-10-05 21:56:53 './zig0 targets' is interesting => riscv64-linux-musl 2019-10-06 08:51:27 ncopa: Mind taking a look at pr11743 ? 2019-10-06 10:14:43 is git packages accepted to packages? 2019-10-06 10:25:10 Danct12: did you mean git url? 2019-10-06 10:25:47 yeah like git packages 2019-10-06 10:25:54 such as linux-git 2019-10-06 10:26:34 what is that? 2019-10-06 10:26:40 file or url 2019-10-06 10:26:57 a package that builds the linux kernel from git sources 2019-10-06 10:27:00 instead from a tarball 2019-10-06 10:27:19 yup, that ^ 2019-10-06 10:27:32 so, git url? 2019-10-06 10:27:41 yeah i guess 2019-10-06 10:27:55 but when we get the tarball for a certain commit 2019-10-06 10:28:07 so technically file 2019-10-06 10:28:13 not sure but I think git://.... will not work 2019-10-06 10:29:03 mps: He means that we allow packages with `_git` as pkgver I think 2019-10-06 10:29:12 even 'git https://....' will not work 2019-10-06 10:29:36 Danct12_: We usually only do that if there's no released version of the respective package available yet 2019-10-06 10:29:39 mps: what do you mean? http://w1r3.net/paste/cvCUdo.txt 2019-10-06 10:30:23 AinNero: no, i mean somthhing like 'git clone https://....' 2019-10-06 10:30:33 but git can clone via https? 2019-10-06 10:30:58 also afaik it can invoke git-archive via https 2019-10-06 10:31:12 git can, ofc, but source in APKBUILD will not work 2019-10-06 10:32:40 who wanted to do that? 2019-10-06 10:32:58 OP question wasn't clear 2019-10-06 10:33:09 man, look, its clear what he want - fetch sources via git instead of via http archive 2019-10-06 10:33:17 and there are some packages that successfully do that 2019-10-06 10:33:28 even if its not considered nice 2019-10-06 10:34:36 which one 2019-10-06 10:34:57 want to see it as example 2019-10-06 10:36:41 do a recursive grep on 'git clone' 2019-10-06 10:37:25 there are some main/yajl for example but these 'tricks' 2019-10-06 10:37:42 its what OP is looking for 2019-10-06 10:39:13 but that could be done as Cogitri says, with _gitcommit or _gitdate in source field 2019-10-06 10:42:42 that _gitcommit is a convention how to declare the commit id inside of an APKBUILD 2019-10-06 10:42:56 actually not even that, it is how it was done for two packages 2019-10-06 10:43:35 community/docker and main/kamailio 2019-10-06 10:44:18 if you check them, you see they use the snapshot functionality like the other packages building from git 2019-10-06 10:44:50 I know how it works, I made and updated some packages using _gitcommit 2019-10-06 10:48:23 Danct12: back to your question, alpine use LTS linux kernel and I think linux from git will not be accepted 2019-10-06 10:53:25 Hi, can https://github.com/alpinelinux/aports/pull/11780 get some attention please? It's really needed for postmarketOS because ssh is broken otherwise 2019-10-06 10:55:00 Someone will access to main/ will have to take a look at that, so ncopa/ikke ^ 2019-10-06 10:58:40 <_ikke_> let me see 2019-10-06 11:38:34 Cogitri: can you say why the emacs build is failing at your host? both ci fails are due to bad configuration for building emacs 2019-10-06 11:39:03 one is an ftp passive problem, the other is a security measure that makes it impossible for emacs to dump itself 2019-10-06 11:39:16 It fails with the dame error as on Drone CI 2019-10-06 11:39:18 Cogitri meant to say: It fails with the same error as on Drone CI 2019-10-06 11:39:18 s/dame/same/ 2019-10-06 11:39:39 The security measure thing 2019-10-06 11:39:56 what kind of setup do you have that makes it have a gap between bss and heap? what security measure do you have? maybe disable aslr? 2019-10-06 11:40:48 it's completely normal. emacs tries to dump itself to disk 2019-10-06 11:43:59 anyone willing to help me with zig lang build problem, PIE and PIC for cmake settings 2019-10-06 11:44:21 <_ikke_> Out of my expertise 2019-10-06 11:47:10 Cogitri: what does cat /proc/sys/kernel/randomize_va_space output? 2019-10-06 11:47:58 are you building under docker? 2019-10-06 11:48:21 you can temporarily disable the feature while building Emacs by echo 0 > /proc/sys/kernel/randomize_va_space 2019-10-06 11:48:41 I'm building under Docker, yes 2019-10-06 11:49:04 aha 2019-10-06 11:49:20 then you must change your docker setup to enable the personality call 2019-10-06 11:49:49 Docker container with a security profile that allows 'personality' by using Docker's --security-opt option with an appropriate profile https://docs.docker.com/engine/security/seccomp/ 2019-10-06 11:57:43 Ah 2019-10-06 13:49:31 clandmeter: could you move `numix-icon-theme` to `community`? 2019-10-06 14:27:30 Cogitri: https://github.com/alpinelinux/aports/pull/11804 2019-10-06 14:51:39 qa3Txu0iak0F: Please just ping me on GitHub so I don't forget about it. 2019-10-06 15:15:08 done. thx. 2019-10-07 02:23:02 Hm, I tried "abuild -r" but I'm getting "builddeps failed" which I'm not really understanding. 2019-10-07 02:23:30 I thought this was just supposed to install and uninstall dependencies around the build... 2019-10-07 02:23:59 I am in the abuild group too. 2019-10-07 04:30:28 <_ikke_> shrizza: did you add all the required repos to /etc/apk/repositories? 2019-10-07 05:01:31 _ikke_: Yeah, I'm pretty sure that part is good. I had just apk del'd all the dependencies so their repos are good. 2019-10-07 06:48:35 ncopa: I presume that you will soon build kernel upgrade. you can safely merge !290 with upgrade, I tested on real hardware 2019-10-07 09:08:43 ncopa: ^ looks like you missed my msg ;) 2019-10-07 10:57:15 shouldn't llvm8 conflict with llvm9? 2019-10-07 10:57:55 getting lots of `ERROR: llvm9-9.0.0-r0: trying to overwrite usr/bin/llvm-strings owned by llvm8-8.0.1-r0.` but don't want to trigger an llvm rebuild just to add a conflicting package 2019-10-07 11:03:41 <_ikke_> or a replaces= 2019-10-07 13:31:26 mps: i thought i merged it? 081be4a965c0e6c99cc44fd75cc0ed8993cd8fa1 2019-10-07 13:31:48 oh, this is a new one 2019-10-07 13:41:19 ncopa: np, next time 2019-10-07 13:44:43 although it can be pushed any time, it doesn't change pgkver nor pkgrel 2019-10-07 14:09:03 ohm, you pushed it 2019-10-07 14:10:47 to repeat my yesterdays question: anyone willing to help me with zig lang build problem, PIE and PIC for cmake settings 2019-10-07 14:11:38 I'm not good in cmake 2019-10-07 18:02:23 tcely: regarding !296 yes I missed to upgrade post-upgrade 2019-10-07 18:06:22 mps: tomorrow or at the weekend if that works for you :) 2019-10-07 18:06:40 Argh, my brain is toast, meant I can help with zig at those days 2019-10-07 18:09:26 Cogitri: thanks, np I'm not in hurry 2019-10-07 18:10:39 I will also ask upstream author for help, he promised to help when I prepare build logs and configs 2019-10-07 18:11:40 btw, what is default PI? in alpine PIE or PIC 2019-10-07 18:12:10 I remember that I had to make fixes for some packages adding -fPIC 2019-10-07 18:12:38 so looks like PIE is default 2019-10-07 18:16:13 PIE is flicked on by default, yes 2019-10-07 18:16:45 fPIC isn't since you can't make position independent code for all libs IIRC 2019-10-07 18:17:16 aha, I thought so, thanks for confirmation 2019-10-07 21:47:35 nice, got zig apk :) 2019-10-07 21:48:21 <_ikke_> :) 2019-10-07 21:49:03 ok, in little crude form but will be refined in a few days, I hope 2019-10-07 21:51:40 πŸ‘ 2019-10-07 22:00:05 Somebody knows what's up with pr11749? Not sure why CI fails 2019-10-07 22:00:37 Does it run go build with root or smth so it can't clean the src files? 2019-10-07 22:23:36 Cogitri: answered in pr 2019-10-08 06:24:51 hi. any idea why old packages are still there? 2019-10-08 06:24:52 https://pkgs.alpinelinux.org/packages?name=core*&branch=edge 2019-10-08 07:37:33 <_ikke_> context? 2019-10-08 07:38:32 <_ikke_> rahmanshaber[m]: which old packages are you referring to/ 2019-10-08 07:38:34 <_ikke_> ? 2019-10-08 07:39:04 <_ikke_> I see you submitted a commit that moved it from testing to community 2019-10-08 07:39:08 <_ikke_> which is what I see in that list 2019-10-08 07:40:49 ohh. as i saw many packages , i thought those old packages are still there. 2019-10-08 07:40:50 my bad sorry. 2019-10-08 07:41:53 <_ikke_> You are seeing all the arches these packages are available ine 2019-10-08 07:42:02 <_ikke_> https://pkgs.alpinelinux.org/packages?name=core*&branch=edge&arch=x86_64 2019-10-08 07:42:06 <_ikke_> here it's limited to a single arch 2019-10-08 07:42:43 thanks. got that. 2019-10-08 08:54:08 not sure if this is right place to ask this but 2019-10-08 08:54:10 what(): locale::facet::_S_create_c_locale name not valid 2019-10-08 08:54:17 does anyone knows how to fix this on alpine? 2019-10-08 08:54:32 since the compiled program doesn't run on alpine due to this error 2019-10-08 12:30:06 anybody with builder access around? 2019-10-08 12:41:36 <_ikke_> I'm in a meeting right now 2019-10-08 12:42:50 no worries, already found someone :) 2019-10-08 12:44:13 <_ikke_> k 2019-10-08 13:27:30 im working on the terraform issue on the builders 2019-10-08 13:27:42 <_ikke_> terraform? 2019-10-08 13:27:49 <_ikke_> ah, the package? 2019-10-08 13:28:24 yeah, apparently it fails to clean the src dir due to previous build failure 2019-10-08 13:28:28 The package 2019-10-08 13:28:40 <_ikke_> Right, as is usual with go packages 2019-10-08 13:52:36 it broke because of this change most likely https://golang.org/doc/go1.13#modules 2019-10-08 13:58:29 yes, it is 2019-10-08 13:58:53 disabling the module system using `GO111MODULE=off` fixes the build 2019-10-08 13:59:04 but unfourtunatly, cleaning $srcdir fails somehow one the builders 2019-10-08 13:59:08 works fine in abuild rootbld though 2019-10-08 14:02:04 The APKINDEX file contains list of .apk packages. Each entry consists of a set of key/value pairs. Do you know what is the meaning of entry: "C:Q1+uJc59lc/loF7fa2OtB5NbbusVg="? Is this a checksum of the .apk? 2019-10-08 14:02:16 The APKINDEX file contains list of .apk packages. Each entry consists of a set of key/value pairs. Do you know what is the meaning of an entry: "C:Q1+uJc59lc/loF7fa2OtB5NbbusVg="? Is this a checksum of the .apk? 2019-10-08 14:09:16 Sorry, I got disconnected earlier. The APKINDEX file contains list of .apk packages. Each entry consists of a set of key/value pairs. Do you know what is the meaning of an entry: "C:Q1+uJc59lc/loF7fa2OtB5NbbusVg="? Is this a checksum of the .apk? 2019-10-08 14:15:08 mrnoone: yes its a checksum, but i dont remember exactly what it is checksum of 2019-10-08 14:15:23 i think it may be the data part of the .apk 2019-10-08 14:16:03 re go packages and go modules 2019-10-08 14:16:16 go modules are supposed to be reproducible built 2019-10-08 14:16:31 so packages could have a shared go module directory cache 2019-10-08 14:16:55 s/go module directory cache/go module cache directory/ 2019-10-08 14:16:55 ncopa meant to say: so packages could have a shared go module cache directory 2019-10-08 14:24:14 if that is a checksum, do you know what kind of hash function was used? It looks like some base64 over something 2019-10-08 14:31:11 ncopa: AFAIU those modules are built from different git revs though, so I don't see the use in caching (unless we cache git repositoried?) 2019-10-08 14:32:37 mrnoone: md5 or sha1 iirc 2019-10-08 14:32:53 ok, thanks! 2019-10-08 14:43:12 over 300 MR's on gitlab.a.o , very good 2019-10-08 15:12:13 ncopa: did you manage to resolve the terraform build error? 2019-10-08 15:12:17 if so: what was the problem? 2019-10-08 15:16:00 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/terraform/terraform-0.12.10-r0.log shows it built succesfully 2019-10-08 15:20:43 nmeum: abuild clean failed due to go modules set the cache dir to be read-only 2019-10-08 15:20:49 to prevent what we are doing 2019-10-08 15:21:16 so i did: chmod -R +w src && rm -r src 2019-10-08 15:21:19 and rebooted the builder 2019-10-08 15:21:55 <_ikke_> you could add options="chmod-clean" to do that automatically 2019-10-08 15:22:08 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n113 2019-10-08 15:22:25 <_ikke_> Oh no, that's just the srcdir 2019-10-08 15:22:46 but the srcdir is the one causing the issue 2019-10-08 15:22:55 <_ikke_> https://git.alpinelinux.org/aports/tree/testing/minio/APKBUILD#n55 2019-10-08 15:22:56 _ikke_: i thikn you are right 2019-10-08 15:22:58 <_ikke_> ah ok 2019-10-08 15:23:14 <_ikke_> I thought it was the go package cachedir 2019-10-08 15:23:21 it's located in the srcdir 2019-10-08 15:23:23 <_ikke_> ok 2019-10-08 15:23:38 <_ikke_> go clean -modcache is what SpaceToast recommended doing for that 2019-10-08 15:23:56 right 2019-10-08 15:24:05 terraform also has a custom cleanup function which invokes go clean 2019-10-08 15:25:16 but apparently `abuild clean` does not call cleanup_srcdir 2019-10-08 15:25:21 or it would have worked? 2019-10-08 15:25:23 i dunno 2019-10-08 15:25:46 <_ikke_> I think back at the time you didn't want to do this by default 2019-10-08 15:30:29 correct, i still dont want run chmod -R +w always 2019-10-08 15:30:38 only when told to do 2019-10-08 15:30:49 but apparently it only does it on successful build 2019-10-08 15:31:00 and not during initial clean, before start build 2019-10-08 15:31:06 <_ikke_> And only with the option enabled, right? 2019-10-08 15:31:17 yes 2019-10-08 15:50:52 i have described somewhat nice way to build go packages on ML but you all seem to have ignored it 2019-10-08 15:50:54 https://lists.alpinelinux.org/~alpine/devel/%3CCAD+eXGQmWT+2ASHj+423TyosrHFRF974ogY+SqSCxYP99JQrdA%40mail.gmail.com%3E 2019-10-08 15:53:28 TLDR 2019-10-08 15:55:00 Yeah sorry I don't follow the ML 2019-10-08 15:56:03 kaey: so if I understand that correctly, we can simply set 3 env vars: GOPATH, GOCACHE and GOTMPDIR 2019-10-08 15:57:39 which one of those are marked as read-only by go? 2019-10-08 15:57:42 or is it all 3 2019-10-08 16:00:21 read-only are files on GOPATH 2019-10-08 16:01:10 but read full mail, including original quoted message. i have described some whys about dumy modules there 2019-10-08 18:36:57 MY-R: 5.4-rc2 is released last weekend and it will be released after -rc8 probably as stable 2019-10-08 18:37:11 that means month and a half at least 2019-10-08 18:37:14 nah, this month! :D 2019-10-08 18:37:59 Linus usually release -rc's at weekends 2019-10-08 18:38:29 so calculation 'says' about second half of next month 2019-10-08 18:39:20 we will see! :P 2019-10-08 18:40:24 yes, prediction, especially future is hard 2019-10-08 19:20:00 ncopa: thx for your work & mail re: icu 2019-10-08 19:22:51 srl295: that was quick! 2019-10-08 19:22:56 thanks for your email :) 2019-10-08 19:24:14 srl295 sent me an email with "thanks for alpine" and questions on icu package 2019-10-08 19:26:07 srl295: do you know if there are any plans to make ICU more ABI stable? 2019-10-08 19:26:24 i.e. not breaking ABI every release 2019-10-08 19:29:56 oh, i got response on that in the email :) 2019-10-08 19:32:49 ncopa: Sorry for the ping, but could you maybe take a look at https://github.com/alpinelinux/mkinitfs/pull/58 ? Would be super nice to have this in 3.11 to support ZFS encryption better :) 2019-10-08 19:38:39 Cogitri: I had a quick look at it 2019-10-08 19:39:29 iirc there is some ZFS support in the nlplug-findfs 2019-10-08 19:39:56 so i wonder if this should be handled in nlplug-findfs or in the initramfs-init 2019-10-08 19:40:32 it would likely be significantly simpler to handle it in shell script 2019-10-08 19:41:23 Yes, just wanted to mention that, it's so, so very much easier to do it in shell 2019-10-08 19:42:12 And ZFS upstream supports dracut(which id also shell), so if they do changes we would have an easy time copying those 2019-10-08 19:46:16 there is something that may be potentially unresolved in the nlplug-findfs too 2019-10-08 19:46:23 it is raid devices 2019-10-08 19:46:32 which is sort of tricky to syncronize 2019-10-08 19:46:48 doing the encryption in shell will bypass that i guess 2019-10-08 19:47:04 Cogitri: have you tested if it works? 2019-10-08 19:47:17 You can't do RAID stuff before you've decrypted the ZFS pool though 2019-10-08 19:47:27 hum 2019-10-08 19:47:29 ok 2019-10-08 19:47:34 I've tested it on my laptop's encrypted ZFS root, yes 2019-10-08 19:47:40 ok, good 2019-10-08 19:47:52 And the approach is pretty similar to what ZFS does in dracut 2019-10-08 19:48:03 *nod* 2019-10-08 19:48:12 ok, I'll try merge it tomorrow 2019-10-08 19:48:18 its late here now 2019-10-08 19:48:25 Cogitri: what timezone are you in? 2019-10-08 19:49:11 Europe/Berlin 2019-10-08 19:49:23 It's late here too, so I better sleep soon :) 2019-10-08 19:49:40 alright, lets continue tomorrow 2019-10-08 20:44:37 back 2019-10-08 20:44:58 <_ikke_> o/ 2019-10-08 20:45:00 <_ikke_> welcome back 2019-10-08 20:45:12 301 emails about Alpine :D 2019-10-08 20:45:20 i'll problably have no branches left 2019-10-08 21:06:01 Mails sorted, time to sort out my packages 2019-10-08 21:06:15 maxice8: welcome back :) 2019-10-08 21:06:45 thank you :) 2019-10-08 21:07:14 is your notebook fixed now 2019-10-08 21:07:39 Mostly yeah, it had some parts of the body that were breaking apart 2019-10-08 21:07:40 Plastic 2019-10-08 21:08:38 eh, my is also somewhat broken but I don't move it, just keep it on desk 2019-10-08 21:08:57 i like using it on the sofa and walking from it to my bed 2019-10-08 21:16:52 Cogitri: How should the iio-sensor-proxy be launched, as it doesn't have an init file? We have one at postmarketOS which works: https://gitlab.com/postmarketOS/pmaports/blob/master/main%2Fiio-sensor-proxy%2Fiio-sensor-proxy.initd 2019-10-08 21:18:02 ideally with that initd being upstreamed 2019-10-08 21:18:15 more ideally with supervise-daemon as supervisor for reliability 2019-10-08 21:19:13 Interesting that supervise-daemon is not mentioned at all in https://github.com/OpenRC/openrc/blob/master/service-script-guide.md 2019-10-08 21:19:55 sadly 2019-10-08 21:21:36 They have https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md though 2019-10-08 21:21:47 Yes 2019-10-08 21:25:13 maxice8: Is that good enough for you? https://pastebin.com/raw/kLsdSCiU ;) 2019-10-08 21:26:15 And killing the iio-sensor-proxy process makes it appear again now, so I'm guessing the supervise-daemon thing works 2019-10-08 21:39:07 z3ntu: it sin't 2019-10-08 21:39:09 isn't* 2019-10-08 21:39:21 command_background has no effect and background is harmful to supervise-daemon 2019-10-08 21:39:38 and there are no pidfiles since the process isn't in the background so the parent process knows exactly the pid and when it dies 2019-10-08 21:40:41 so just the supervisor and the command lines then? 2019-10-08 21:40:50 yes 2019-10-08 21:41:56 now brb gotta restart to get modules working, kernel updates are a pain 2019-10-08 21:42:07 that's actually easier then than without supervise-daemon 2019-10-08 21:42:08 thanks :) 2019-10-08 21:45:05 oh ye having last few kernel versions installed would be nice 2019-10-08 21:53:19 For booting I think https://getsol.us/2017/03/26/clr-boot-manager-now-available-in-solus/ is pretty cool 2019-10-08 21:58:31 sounds cool yes 2019-10-08 21:58:44 :D once packaged systemd-boot for Void as april's fool 2019-10-09 04:19:46 z3ntu: Isn't it dbus activatable? 2019-10-09 05:09:30 ncopa: yeah, for C: icu doesn’t break ABI each release, works hard not to. C++: we gave up on it decades ago, the compilers don’t allow stable abi 2019-10-09 05:09:45 β€œIt’s not java” 2019-10-09 05:38:43 Cogitri: hmm judging from the file in etc/dbus-1/system.d it should be... Will test again today 2019-10-09 05:39:59 I mean I don't mind adding an init service for it since it's possible to start it like that, but dbus should work 2019-10-09 06:02:00 <_ikke_> Anyone knows how to see in the webinterface when people have replied to comments (similar to github)? 2019-10-09 06:02:05 <_ikke_> gitlab webinterface 2019-10-09 06:11:17 hi tmhoang, I'm not really using ntop anymore, just maintaining it, so no plans to move to ng version 2019-10-09 06:11:23 patches are welcome :) 2019-10-09 06:19:09 _ikke_: You'll have to tweak your notification settings to `Participate` in threads that you've commented it 2019-10-09 06:19:22 Otherwise you'll only get notifications if you're assigned to a problem or pinged 2019-10-09 06:19:46 Which in theory should lesson unnecessary workload, but in practice only gets me more worked up if I missed some issue :P 2019-10-09 06:21:58 <_ikke_> I already have it set to participate 2019-10-09 06:22:08 <_ikke_> But that only makes you receive e-mails 2019-10-09 06:22:39 can someone add the `T-ci-malfunction` label to pr11852? 2019-10-09 06:24:24 <_ikke_> done 2019-10-09 06:24:56 danke 2019-10-09 06:26:08 ikke: Ugh, gitlab notifications are pretty annoying 2019-10-09 06:26:10 I don't know if it makes a difference, but I tell myself it'll get looked at quicker if it's failing and has the label 2019-10-09 06:30:23 i found a little bug in the mumble server, it doesn't come instantly with sqlite permissions for the user 'murmur' and you have to set the default user to 'murmur' 2019-10-09 06:31:12 <_ikke_> nicolaus: feel free to open an issue on gitlab.a.o 2019-10-09 06:31:18 well maybe it's not a bug, maybe it's a feature. But the same package in other distributions already come a little preconfigured to save time 2019-10-09 06:31:28 thank you _ikke_ 2019-10-09 06:32:48 if nothing else, it should probably be documented why it doesn't come working out of the box (or have a post-install message or whatever) 2019-10-09 06:33:18 true 2019-10-09 06:33:31 it's not documented 2019-10-09 06:43:04 _ikke_, you around? 2019-10-09 06:43:14 <_ikke_> yes' 2019-10-09 06:43:16 Hi! 2019-10-09 06:43:20 I'm looking at https://gitlab.alpinelinux.org/alpine/aports/merge_requests/177 2019-10-09 06:43:50 can you help me to check what I should verify? Just if the patch applies? 2019-10-09 06:48:11 <_ikke_> No, the changes to the APKBUILD 2019-10-09 06:48:14 <_ikke_> just 2019-10-09 06:49:25 ok 2019-10-09 06:52:34 _ikke_: https://gitlab.alpinelinux.org/alpine/aports/issues/10863 2019-10-09 06:52:36 is it enough commenting, or I should mark as done? 2019-10-09 06:52:37 is this fine 2019-10-09 06:52:39 ? 2019-10-09 06:52:50 (and ofc merging the patch) 2019-10-09 06:55:25 <_ikke_> fcolista: just adding a note would do 2019-10-09 07:28:20 ncopa: do you remember reason to have separate aports for linux-vanilla and linux-headers 2019-10-09 07:32:38 may be for bootstrapping reasons 2019-10-09 07:32:56 so we dont need build full kernels to build the toolchains 2019-10-09 07:33:58 aha, ok, understand 2019-10-09 07:35:13 i was thinking, maybe we should add a new kernel flavor: linux-lts 2019-10-09 07:35:26 and use that as default for alpine 3.11 2019-10-09 07:35:47 heh, you read my minds 2019-10-09 07:37:40 I thought about something similar, but not sure if we should make this for current stable, maybe for next stable when it is released 2019-10-09 07:38:45 i was thinking for linux-lts-5.4 2019-10-09 07:39:21 we could probably also move linux-vanilla to community 2019-10-09 07:39:22 that makes sense 2019-10-09 07:39:25 Sounds good 2019-10-09 07:39:39 its a "bigger" project though 2019-10-09 07:39:44 linux-vanilla would be non LTS then? 2019-10-09 07:39:53 thats the thinking 2019-10-09 07:39:53 or 2019-10-09 07:40:01 we rename it to something else 2019-10-09 07:40:09 linux-mainline or just "linux" 2019-10-09 07:40:19 or linux-stable 2019-10-09 07:40:21 i dunno 2019-10-09 07:40:40 the reason for not use linux-vanilla name would be for backwards compat 2019-10-09 07:40:50 so linux-lts can have a provides=linux-vanilla 2019-10-09 07:41:09 Ah yes 2019-10-09 07:41:10 Naming it just linux would be fine by me 2019-10-09 07:41:17 or linux-alpine 2019-10-09 07:41:27 alpine flavored kernel 2019-10-09 07:41:43 I didn't contemplate naming, but agree about idea 2019-10-09 07:46:00 another question which stays some time in my mind is the about two kernels, one 'small and simple' and another one 'full featured' (enabled a lot of modules and options) 2019-10-09 07:46:57 yeah thats another question, how do we do different kernel configs 2019-10-09 07:47:20 for now i think the linux-virt has been the "small and simple" while -vanilla has been the full featured 2019-10-09 07:47:44 we could also do server vs desktop flavor 2019-10-09 07:48:11 we have had requests for kexec 2019-10-09 07:48:23 but i dont want enable that by default 2019-10-09 07:48:41 kexec makes sense only for servers, imo 2019-10-09 07:48:48 exactly 2019-10-09 07:48:57 does alpine linux supports SELinux? 2019-10-09 07:49:03 Danct12: no 2019-10-09 07:49:22 well 2019-10-09 07:49:27 Nop 2019-10-09 07:49:34 Danct12: it doesn't make sense without userspace support 2019-10-09 07:49:36 Supporting SELinux is pretty painful 2019-10-09 07:49:56 i think we have some of the packages that has it enabled, so you can use it in containers 2019-10-09 07:50:02 or maybe that was apparmor 2019-10-09 07:50:03 Cogitri: and useless at the end 2019-10-09 07:50:16 Maybe you can generate your own TOMOYO rules (or use AppArmor if just protecting a few apps does the trick) 2019-10-09 07:50:28 mps: it's pretty useful 2019-10-09 07:50:56 imho selinux is too complicated 2019-10-09 07:51:33 decade ago I backported selinux for debian (forgot which release) and after that experience and results I stopped to use it and work on it 2019-10-09 07:52:04 about kernel config flavors 2019-10-09 07:52:16 i was thinking of a config for headless, typical for datacenters 2019-10-09 07:52:33 where you dont have wifi, bluetooth or audio drivers 2019-10-09 07:53:17 ncopa: Yes, it's too complicated but when it works it sure is good 2019-10-09 07:53:31 I personally prefer just using AppArmor though since I'm at least able to comprehend that 2019-10-09 07:53:53 but i find it difficult to draw the line for kernel configs 2019-10-09 07:53:57 But the automatically generated rules thingie from SELinux is nice (as long as you don't have to generate them yourself :P) 2019-10-09 07:54:15 we coudl also have smarter subpackages for the default kernel package 2019-10-09 07:54:33 But I guess on a desktop it's not too useful anyway since the user executing ransomware.sh is the biggest invade vector 2019-10-09 07:54:37 Cogitri: at the end of day you will have to generate it yourself 2019-10-09 07:55:01 apparmor is better option, imo 2019-10-09 07:55:09 ncopa: Supporting so many kernels sounds kind of painful 2019-10-09 07:55:14 im sure selinux has its value, but i dont think we want support it 2019-10-09 07:55:17 Cogitri: yes 2019-10-09 07:55:33 Nop, we certainly don't want to support SELinux :P 2019-10-09 07:55:42 we already have 3 flavors: linux-vanilla, linux-virt and linux-rpi and linux-rpi2 2019-10-09 07:55:45 4 flavors 2019-10-09 07:55:56 and it already is painful 2019-10-09 07:56:01 practice shows that pretty much the only organization capable of producing selinux rules for everything is Red Hat 2019-10-09 07:56:03 -desktop,-server and -virt (and possibly rpi*) sounds like more than enough 2019-10-09 07:56:13 TBB: Yup 2019-10-09 07:57:13 i have actually also been thinking of a linux-qemu kernel 2019-10-09 07:57:17 without modules 2019-10-09 07:57:36 just the vmlinuz-qemu 2019-10-09 07:57:52 only virtio drviers compiled in + maybe a few more 2019-10-09 07:58:32 and I'm working on linux-arm-mp (multiplatform) 2019-10-09 07:58:49 huh 2019-10-09 08:00:45 ncopa: Why though? Just to save some 50MB on your VM? 2019-10-09 08:01:03 I mean saving space is nice, but is that worth the maintenance effort? 2019-10-09 08:01:54 And we currently already have a hard time getting all the PRs for main/ merged :/ 2019-10-09 08:03:44 we can keep those 'flavored' kernels in community or testing 2019-10-09 08:04:32 Cogitri: the idea was to have a single vmlinuz-qemu binary that you can use for qemu ... -kernel /boot/vmlinuz-qemu 2019-10-09 08:04:56 for things like CI and similar 2019-10-09 08:06:01 and yeah, we dont have resources for it 2019-10-09 08:06:10 it was more of a "would be nice to have" idea 2019-10-09 08:06:56 we also need fix the way we manage the kernel configs 2019-10-09 08:07:09 i 'd like to rely more on default configs 2019-10-09 08:07:18 and keep a diff from the default 2019-10-09 08:07:25 rather than having the full config 2019-10-09 08:07:34 similar to what we do with linux-rpi now 2019-10-09 08:07:39 yes, morning dreams, but I still think that I would try to make linux-arm-mp but in testing 2019-10-09 08:08:45 i think one of the challenges with multiple kernel flavors is that people want 3rd party modules for those 2019-10-09 08:09:00 they want things like wireguard for rpi etc 2019-10-09 08:09:16 which increases the maintenance burden bit by bit 2019-10-09 08:15:57 kernel for different arm SOC/SBC (especially 32bit) is hard to make and maintain, i.e. require time and resources 2019-10-09 08:16:10 We could switch to using DKMS for those modules then, which would minimize the maintenance burden 2019-10-09 08:17:19 DKMS could help to some degree but not complete solution 2019-10-09 08:22:32 Not really, and it would pull in C development tools which kind of defeats the purpose of some of these kernels being minimal 2019-10-09 08:25:04 I mean, different and sometimes conflicting config options for different SBC's and SOC's 2019-10-09 08:53:26 finished zig lang APKBUILD, but for now it works only on x86_64 2019-10-09 09:22:37 speaking about https://gitlab.alpinelinux.org/alpine/aports/issues/10863 2019-10-09 09:23:30 in last murmur config syntax changed little and in APKBUILD lines with sed should replace lines start from "#" with ";" 2019-10-09 09:26:12 that is how default murmur.ini looks now: http://tpaste.us/kZ56 2019-10-09 10:34:36 <_ikke_> maxice8: would you mind if we added linting for init files to atools as well? 2019-10-09 10:36:57 another line in wishlist for it, is it possible to use busybox grep 2019-10-09 10:37:09 <_ikke_> mps: There is an issue for that 2019-10-09 10:37:41 <_ikke_> mps: https://github.com/maxice8/atools/issues/2 2019-10-09 10:37:59 <_ikke_> Hmm, better use https://gitlab.alpinelinux.org/Leo/atools/issues/2 2019-10-09 10:39:14 _ikke_: I see now, thanks. I missed it because I don't follow GH 2019-10-09 10:59:30 _ikke_: I wouldn't, just make it a separate binary like aports-lint apkbuild-lint 2019-10-09 11:04:53 <_ikke_> yes, that was my plan 2019-10-09 11:29:01 MartijnBraam: mind updating your vte3 pr? 2019-10-09 11:49:07 Sure 2019-10-09 11:49:47 πŸ‘ 2019-10-09 12:12:47 I'm doing a test with abuild and apk-tools and need to know their license. I can't find that information in the git repo or on gitlab (which says that license is missing). Which license is used and can I do a merge request for adding a LICENSE file? 2019-10-09 12:13:41 GPL2, says the APKBUILD file 2019-10-09 12:14:42 apk-tools-2.10.4-r3 license: 2019-10-09 12:14:42 GPL2 2019-10-09 12:14:42 abuild-3.4.0-r1 license: 2019-10-09 12:14:42 GPL-2.0 2019-10-09 12:15:17 thanks! didn't thought of looking at the APKBUILD file 2019-10-09 13:03:56 hi 2019-10-09 13:04:05 i have alpine linux installed 2019-10-09 13:04:56 and i want to compile rust cargo-cross static linked so it can work on gentoo-musl for a project of mine 2019-10-09 13:05:08 how this can be possible 2019-10-09 13:05:20 and good morning all 2019-10-09 13:05:42 im running edge 2019-10-09 13:05:47 inside chroot 2019-10-09 13:08:56 good afternoon 2019-10-09 13:09:18 i think Cogitri has been working on rust 2019-10-09 13:09:45 nice 2019-10-09 13:11:10 Install `cargo` and compile your project with `RUST_FLAGS="-C target-feature=+crt-static"` 2019-10-09 13:11:43 so far i was able to put rust from edge on my gentoo-musl-clang only system and compile only one firefox dep 2019-10-09 13:12:23 when i try to rebuild with it rust from gentoo-overlays with alpine patches at the minute 25 rust segfault 2019-10-09 13:12:28 same for firefox 2019-10-09 13:12:56 Cogitri, is not a project i want to rebuild cargo itselft 2019-10-09 13:13:10 i had tried that already 2019-10-09 13:13:23 from here 2019-10-09 13:13:24 http://zderadicka.eu/static-build-of-rust-executables/ 2019-10-09 13:14:13 i copied pasted all the instructions from the aports rust recipe 2019-10-09 13:21:30 Same applies to cargo then, build it with that env variable and the libc will be statically linked 2019-10-09 13:25:25 what about llvm 2019-10-09 13:25:39 that is what giving me troubles 2019-10-09 13:26:30 i added the rust cargo etc to my system gentoo and i was able to use it but segfault with libllvm9.so or something 2019-10-09 13:26:46 a big lib of 60 megas 2019-10-09 13:27:07 that rust is linked to 2019-10-09 13:33:06 We don't statically link that 2019-10-09 13:33:49 Either use LD_LIBRARY_PATH to find LLVM or compile it yourself with static llvm 2019-10-09 13:33:49 ok 2019-10-09 13:34:07 musl-dont-use-crt-static.patch i can avoid it for what i want ? 2019-10-09 13:39:08 Not sure if Rust will compile like that in our setup 2019-10-09 13:39:18 But you can certainly try 2019-10-09 14:31:31 Cogitri: pushed vte3 0.58.1 2019-10-09 14:42:12 Thank you 2019-10-09 14:42:47 ncopa: ^ mind taking a look at that? It's pr 11743 2019-10-09 15:19:21 ok 2019-10-09 15:29:54 Thank you :) 2019-10-09 16:01:28 Cogitri: About iio-sensor-proxy: launching `sudo monitor-sensor` while iio-sensor-proxy is not running, stops at "Waiting for iio-sensor-proxy to appear" 2019-10-09 16:01:53 Huh, weird 2019-10-09 16:01:57 dbus is functional? 2019-10-09 16:03:25 as running `sudo iio-sensor-proxy` in another terminal tab makes monitor-sensor work, I'd say yes 2019-10-09 16:03:27 @ncopa should I wait for clandmeter to accept pr11781 2019-10-09 16:06:09 andypost[m]: lgtm 2019-10-09 16:23:32 jomat: https://gitlab.alpinelinux.org/alpine/aports/issues/10863 2019-10-09 19:17:35 ncopa: any reason qemu is hold back? 2019-10-09 19:31:29 https://github.com/alpinelinux/aports/pull/11865 2019-10-09 19:31:36 new aport 2019-10-09 20:12:17 mps: just have to login and let you know the wireguard slow issue I had a couple of days ago: it's due to MTU value. I used 1460 and it sucked. Tried 1360 and god bless. 2019-10-09 20:19:59 MartijnBraam: You forgot to actually increase vte3's version to 0.58.1 :/ 2019-10-09 20:20:00 Want to create a new PR for that? 2019-10-09 20:20:47 eeh what? the version is 0.58.1 on my end 2019-10-09 20:21:16 at least it is in my local repo... 2019-10-09 20:22:08 shit 2019-10-09 20:22:11 forgot git add... 2019-10-09 20:22:13 Just pulled and it's 0.58.0 :/ 2019-10-09 20:22:44 Well, happens, don't worry about it. I'll just push GNOME Terminal 3.34.0 instead of .1 for now 2019-10-09 20:25:43 I eeeeh, made a new PR... 2019-10-09 20:27:20 algitbot: because something in between mess with packets, I presume 2019-10-09 20:36:02 <_ikke_> Cogitri: mutter is failing 2019-10-09 20:36:46 Huh, it's...looping? 2019-10-09 20:37:03 That's odd, didn't see that happen with meson set and didn't happen locally 2019-10-09 20:40:44 i think tinc-pre needs a rebuild 2019-10-09 20:41:06 seems to be build against older readline 2019-10-09 20:41:44 if anyone can check that would go nice. 2019-10-09 20:42:54 Is the system time on the builders correct? 2019-10-09 20:43:14 Apparently it being incorrect can cause such loops with ninja 2019-10-09 20:43:47 which builder? 2019-10-09 20:44:03 All edge ones apparently 2019-10-09 20:44:44 that would be weird 2019-10-09 20:45:47 Yes, it would very much be weird 2019-10-09 20:46:14 But it's also weird that ninja is looping on the builders when it doesn't for me nor for CI 2019-10-09 20:46:29 i can confirm time is ok on aarch64 2019-10-09 20:47:25 <_ikke_> x86 as well 2019-10-09 20:48:13 <_ikke_> x86_64 is correct 2019-10-09 20:48:22 Thanks for checking 2019-10-09 20:48:41 Uhh... let's give it a go with ninja debugging enabled I guesd 2019-10-09 20:53:27 Huh: ninja explain: output build.ninja older than most recent input ../../../../../../../../dev/stdout (1570654305711875044 vs 1570654306028547734) 2019-10-09 20:53:45 That's why it's regenerating the build files again... 2019-10-09 20:54:37 https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/mutter/mutter-3.34.1-r0.log 2019-10-09 20:58:08 ../../../../../../../../dev/stdout - I think you need some GPS to localize this path ;) 2019-10-09 21:05:19 Heh :P 2019-10-09 21:05:32 Anyway, it's weird that the timestamp is different on the builders only 2019-10-10 05:51:03 I've a fakeroot that I want to create an apk with. If I remember correctly there is somewhere on the wiki instructions on how to do this and how the apk format is built. But I don't find it :(. 2019-10-10 05:52:59 where can I look for information in how to build an apk? Using abuild -h my gut feeling is that abuild package should do what I want but the description says that it installs things, not package them 2019-10-10 06:51:38 fredrigu: abuild builds apk by using APKBUILD file 2019-10-10 06:52:52 fredrigu: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2019-10-10 07:25:57 mps: I know, but there must be a way to create an apk from a fakeroot as well 2019-10-10 07:26:27 or perhaps it's better to just ignore abuild and build the apk manually 2019-10-10 07:39:06 fredrigu: not sure I understand you, you want just to create apk and not build? 2019-10-10 07:47:48 mps: corrent, I already have a build and it's in a fakeroot dirtory. All I want to do is to package that into an apk 2019-10-10 07:54:21 apk is tar file with added two files, .PKGINFO and sign key in .SIGN.RSA......... 2019-10-10 07:57:49 that sounds sweet. But there's also a custom header APK-TOOLS.checksum.SHA1 2019-10-10 07:58:25 apk are 3 gzipped tar archives, the first one contains .SIGN.RSA signature of the second archive. The second archive contains .PKGINFO with metadata and the checksum (sha256) of the third archive. The 3rd archive contains all files which will be installed to the target filesystem 2019-10-10 07:59:42 right 2019-10-10 07:59:57 mrnoone: I just downloaded zlib from edge and did tar xfv zlib-1.2.11-r3.apk and that seems to be only a single tar archive? 2019-10-10 08:00:18 use abuild-gzsplit 2019-10-10 08:02:08 the thing is, when you are going to compose a new APK you need to correctly calculate the checksum and the signature. and those are calculated over the gzipped tar archives. so, in the end you finish up building 3 tar.gz and concatenating them 2019-10-10 08:02:10 yes, .PKGINFO is text file 2019-10-10 08:02:47 mrnoone: thanks, I got a successful split (I believe) 2019-10-10 08:03:50 yeah, the checksum should be pretty easy to calculate (just sha256sum data.tar.gz), but is the signature mandatory? 2019-10-10 08:04:46 abuild-sign 2019-10-10 08:05:50 I am not sure. I would say in the apk format v2 yes, but in v1 no. I think that is why APKINDEX required the checksum of the .PKGINFO 2019-10-10 08:05:51 tar --xattrs -f - -c . | abuild-tar --hash | gzip -9 > data.tar.gztar -c .PKGINFO | abuild-tar --cut | gzip -9 > control.tar.gzabuild-sign -k ~/.abuild/NAME.rsa -p ~/.abuild/NAME.rsa.pub control.tar.gzcat control.tar.gz data.tar.gz > zlib.apk 2019-10-10 08:06:27 (1) tar --xattrs -f - -c . | abuild-tar --hash | gzip -9 > data.tar.gz (2) tar -c .PKGINFO | abuild-tar --cut | gzip -9 > control.tar.gz (3) abuild-sign -k ~/.abuild/NAME.rsa -p ~/.abuild/NAME.rsa.pub control.tar.gz (4) cat control.tar.gz data.tar.gz > zlib.apk 2019-10-10 08:07:29 thanks, but doesn'nt (4) miss signatures.tar.gz? 2019-10-10 08:07:57 in step (3) the signature is appended to the control.tar.gz 2019-10-10 08:08:05 that is done by abuild-sign 2019-10-10 08:08:10 mrnoone: are you talking about .deb 2019-10-10 08:08:44 mrnoone: I see, thanks. I guess I should do a test run to see if I can get this to work 2019-10-10 08:09:30 @mps 2019-10-10 08:09:40 @mps no, about alpine apk 2019-10-10 08:10:16 where do you see data.tar.gz and control.tar.gz in apk's 2019-10-10 08:10:49 mps: with cat zlib-1.2.11-r3.apk | abuild-gzsplit 2019-10-10 08:11:02 that gives control.tar.gz, data.tar.gz and signatures.tar.gz 2019-10-10 08:13:27 ah, true, didn't know that, for me 'tar xf' was enough 2019-10-10 08:13:31 sorry 2019-10-10 08:14:36 me neither, just learned :) 2019-10-10 08:18:57 mps> algitbot: because something in between mess with packets, I presume: You meant the wireguard mtu issue ? 2019-10-10 08:19:30 fredrigu: will look at abuild-gzsplit source later 2019-10-10 08:20:04 tmhoang: yes, and good morning :) 2019-10-10 08:20:17 morning :D 2019-10-10 08:20:54 something in between probably reasemble packets 2019-10-10 08:20:56 I guess so, read a little bit about mtu and how cloud vps adding additional header to packets and so on, still trying to understand things 2019-10-10 08:21:37 there were some tool for discovery such things but I forgot it's name 2019-10-10 08:25:05 but traceroute also can help a little with '-F' option 2019-10-10 09:37:45 mrnoone thanks! I got it to work (although I believe I've a broken .PKGINFO file since apk list segfaults) But the packaging is correct. 2019-10-10 11:04:47 can anyone review pr11872? 2019-10-10 11:05:17 Why does `mpfr4` have `mpfr-dev` as a subpackage while `mpfr3` does as well? Is there a way to make packages depend on `mpfr4-dev` specifically? 2019-10-10 11:06:49 mpfr4-dev have 'replaces=mpfr' 2019-10-10 11:08:22 I think mpfr3-dev and mpfr4-dev cannot be used at the same time 2019-10-10 11:09:09 But now if you specify `mpfr-dev` for a package, which one does it actually use? 2019-10-10 11:09:24 Why is it not just called `mpfr3-dev` and `mpfr4-dev`? 2019-10-10 11:14:26 mpfr-dev on edge will give mpfr4-dev, I think 2019-10-10 11:15:51 I wanted to fix this for edge to have just mpfr but someone already pushed versioned mpfr again so now it doesn't make sense to fix it 2019-10-10 11:17:52 So for example `kcalc` currently depends on `mpfr3`, and to get it to use `mpfr4` instead it just needs a rebuild (`$pkgrel` bump)? 2019-10-10 11:20:43 on edge yes, probably 2019-10-10 11:40:02 How can you make subpackages have their own `-doc` and `-lang` subpackages? Currently my aport fails because the subpackage has uncompressed man pages. I tried `-doc` which just has `default_doc` in it, but that doesn't seem to work 2019-10-10 11:41:18 PureTryOut[m]: create doc() function in APKBUILD and do the work there 2019-10-10 11:42:41 PureTryOut[m]: we should remove the mpfr3 package now 2019-10-10 11:43:01 ncopa: I'd be okay with that 2019-10-10 11:43:12 Preferably before 3.11 anyway πŸ˜› 2019-10-10 11:43:39 the reason for mpfr3 + mpfr4 is that we need mpfr3 be around while we upgrade gcc 2019-10-10 11:43:43 ncopa: that is what started about month or two ago to fix 2019-10-10 11:44:37 the problem is not as serious as it used to be (due to so:lib*.so deps) 2019-10-10 11:45:00 no, it is not 2019-10-10 11:45:24 but mpfr3 is not needed anymore, I think 2019-10-10 11:45:35 but i kept mpf3 in case build of gcc broke or while building against mpfr4 similar, to guarantee that mpfr3 is not removed (and breaking gcc) 2019-10-10 11:46:07 understand 2019-10-10 11:49:23 mps: I don't fully understand. Do you mean I manually have to split the files and such rather than letting `default_doc` do it? 2019-10-10 11:50:57 yes, if default_doc doesn't work then you 'script it' in doc() function 2019-10-10 11:51:50 But isn't default_doc supposed to work with subpackages? 2019-10-10 11:51:57 <_ikke_> No 2019-10-10 11:53:18 <_ikke_> PureTryOut[m]: it always checks / copies from $pkgdir 2019-10-10 11:53:36 Ah that's where it goes wrong then 2019-10-10 11:53:47 <_ikke_> From $pkgdir to $subpkgdir 2019-10-10 11:53:49 Ok, manually it is I guess 2019-10-10 12:00:07 Can I just copy the default_doc function and replace all `$pkgdir` for `$subpkgdir` or something? 2019-10-10 12:00:26 <_ikke_> Not sure if that's required in this case? 2019-10-10 12:01:03 Probably not 2019-10-10 12:01:49 <_ikke_> Those default functions need to be generic, but in this case you just need to move a couple of specific files 2019-10-10 12:02:05 <_ikke_> and it's from one subpackage to another 2019-10-10 12:02:24 <_ikke_> So I think you have to hardcode the dirnames 2019-10-10 12:02:32 <_ikke_> I mean, subpackage names 2019-10-10 12:03:05 yeah seems like it... ugh 2019-10-10 12:04:53 anyone with some docbook knowledge would upgrade docbook* things 2019-10-10 13:22:53 PureTryOut: vidstab has -dev stuff but no -dev subpackage 2019-10-10 13:23:26 The entire package is just a library intended to be used in other packages. If you make a `-dev` subpackage, there is nothing in the main package 2019-10-10 13:23:58 there should be /usr/lib/vidstab.so.1.1 and /usr/lib/vidstab.so.1 in the main package 2019-10-10 13:30:31 ncopa: Do you want to handle meson? Otherwise I'll work on it (but I don't want to duplicate effort) 2019-10-10 13:33:41 Alright, fixed it I guess 2019-10-10 14:02:51 Yup, works now. Thanks for the help, ncopa 2019-10-10 14:17:08 Oh you're right, I somehow missed those 2019-10-10 14:17:09 I've pushed the `-dev` subpackage 2019-10-10 14:25:44 Is there an easy way to fetch a mr from the commandline on gitlab ? 2019-10-10 14:27:16 <[[sroracle]]> gitlab supports automatic refnames for mrs but i forgot what exactly the format is 2019-10-10 14:27:38 <[[sroracle]]> https://docs.gitlab.com/ee/user/project/merge_requests/#checkout-locally-by-adding-a-git-alias 2019-10-10 14:28:05 I just finished that document without success :c 2019-10-10 14:28:42 <[[sroracle]]> merge-requests/$remote/$id doesn't work? 2019-10-10 14:29:10 nope 2019-10-10 14:29:10 <[[sroracle]]> er merge-requests/$id/head 2019-10-10 14:29:54 nope git fetch $rmotemerge-requests/$id/head 2019-10-10 14:30:14 <[[sroracle]]> what does it say when you do that? 2019-10-10 14:31:10 <[[sroracle]]> maybe ensure that $remote points to the gitlab.a.o clone uri and not the git.a.o one in this case 2019-10-10 14:31:32 fatal: couldn't find remote ref merge-requests/330/merge 2019-10-10 14:34:08 worked for merge-requests/330/merge and not merge-requests/333/merge 2019-10-10 14:35:06 `git fetch remote merge-requests/mrid/head:nameoflocalbranch` does the trick for me 2019-10-10 14:39:18 sadly doesn't work for me when fetching from upstream (gitlab.a.o/alpine/aports.git) 2019-10-10 15:13:41 maxice8: doesn't adding .patch at the end of url work 2019-10-10 15:14:13 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/321.patch for example 2019-10-10 15:19:17 yeah i'll do that 2019-10-10 17:20:23 hi _ikke_, I have refined my patch for the GNUnet package with respect to your comments. What do you think? What's next? 2019-10-10 18:03:32 <_ikke_> I still have issues getting gnunet compiled 2019-10-10 18:04:36 <_ikke_> Can it be that a depency is missing? 2019-10-10 18:06:09 <_ikke_> Oh, they left 2019-10-10 18:39:26 Can someone review and merge pr11872 and pr 11873? 2019-10-10 19:23:03 <_ikke_> Danct12: left one question for the wlroots PR 2019-10-10 20:33:34 Anyone got a gitlab MR that can be reviewd and merged ? 2019-10-10 20:34:18 <_ikke_> seem to be enough in this list, not? https://gitlab.alpinelinux.org/alpine/aports/merge_requests 2019-10-10 20:36:44 giving the opportunity for someone to get in 2019-10-10 20:37:02 also i'm testing automatically commenting on merge requests i merged since you asked :D 2019-10-10 20:37:09 <_ikke_> heh 2019-10-10 20:37:51 <_ikke_> I automatically add Closes ! to the commit message. Even though that does not close them, it at least adds a reference to the MR 2019-10-11 00:26:03 Hi! I'm looking for the maintainer of Gnome (or mutter) for help regarding compiling mutter on a musl libc system. It fails on "[553/1436] Linking target cogl/cogl/libmutter-cogl-5.so.0.0.0." which I assume this patch should fix, except it doesn't 2019-10-11 04:28:54 <_ikke_> Wychmire: Cogitri here worked on mutter 2019-10-11 06:02:14 Wychmire: What doesn't work about it? Seems to work fine for Alpine 2019-10-11 06:04:26 ikke: can pr11872 be merged? 2019-10-11 07:47:29 <_ikke_> Danct12: can you add commits bumping the pkgrel for cage and sway then? 2019-10-11 08:02:36 directly to that one PR? _ikke_ 2019-10-11 08:03:13 <_ikke_> Danct12: yes please 2019-10-11 08:03:31 Yes 2019-10-11 08:03:35 right 2019-10-11 08:03:43 So it can be merged in one go 2019-10-11 08:07:47 done 2019-10-11 08:08:54 Cogitri: _ikke_ 2019-10-11 08:10:45 <_ikke_> Danct12: I can look into it later myself 2019-10-11 08:12:28 also after you merged that, can you rerun the CI on pr11873? 2019-10-11 08:13:35 <_ikke_> Danct12: certainly 2019-10-11 10:40:23 can pr11873 be merged as well? 2019-10-11 10:40:57 <_ikke_> yes, waiting for the wlroots packages to be available, then I restart CI 2019-10-11 10:52:07 <_ikke_> Danct12: restarted CI now 2019-10-11 10:52:51 the echo in the mirror, right. 2019-10-11 10:54:36 <_ikke_> https://cloud.drone.io/alpinelinux/aports/12807/3/1 2019-10-11 10:54:42 seems like wlroots 0.8 isn't available on aarch64 yet 2019-10-11 10:54:54 <_ikke_> Hmm, I see 2019-10-11 10:55:12 <_ikke_> the builder is stuck on another package 2019-10-11 10:59:58 <_ikke_> maxice8: Kodi is failing on aarch64, but no clear error as far as I can find 2019-10-11 13:44:27 Cogitri: I'm attempting to compile mutter on musl-based Void Linux but it fails, so I was hoping I could figure out what you did to get around the issue and apply that locally. It compiles fine on glibc 2019-10-11 13:48:25 Well, it's all in the APKBUILD 2019-10-11 13:48:55 Do you have a log for me? 2019-10-11 13:52:34 Cogitri: http://ix.io/1YdD 2019-10-11 13:52:51 I had thought it was your fix-cogl-path-build-ordering.patch patch that fixed it, but after applying it still fails. Here's what should be the relevant part of the build log: https://0x0.st/zxHa.log 2019-10-11 13:53:30 I wonder if it would make sense to automatically rubber-stamp aports patches which just bump the pkgver and update the checksums, if they pass CI 2019-10-11 14:00:26 Try disabling profiling 2019-10-11 14:00:40 Wychmire: look at the look, it's missing symbols to sysprof 2019-10-11 14:01:06 So disable profiling and it won't look for those 2019-10-11 14:01:54 That option is -Dprofiler=false ? 2019-10-11 14:06:02 so mrnoone said to use tar --xattrs to create a data.tar.gz file for an apk file. However the busybox tar does not have support for --xattrs. Is that really used by alpine? 2019-10-11 14:12:11 Cogitri: It compiles! Thank you for the help! 2019-10-11 14:12:31 Sure πŸ‘ 2019-10-11 14:12:32 Good that it works now :) 2019-10-11 14:37:32 fredrigu: try to untar one apk and see yourself what is 'inside' 2019-10-11 15:16:32 hey there -- when you install a python package on alpine, is a `__pycache__` supposed to be created with the `.pyc` files? On my test box I see no such thing (unless I go and import the modules as root), which means that any user importing those installed modules pays a startup cost 2019-10-11 15:17:38 anyone plan to go to fosdem 2020? 2019-10-11 15:21:31 i'll try go there 2019-10-11 15:33:45 PureTryOut: can you check out !372 and !373 ? 2019-10-11 15:34:02 I can indeed 2019-10-11 15:37:22 mps: oh I've. But just xattrs is a bit hard to see 2019-10-11 15:38:37 ncopa: never been there, but I might have an oppertunity this year. Have you attended before? Is it any good? 2019-10-11 15:49:00 i've been there once 2019-10-11 15:49:15 its kinda chaotic, but nice 2019-10-11 15:49:21 lots of opensource people there 2019-10-11 15:51:25 i'll head to fosdem again if i have the opportunity :) 2019-10-11 15:51:31 and fscons here in norway 2019-10-11 15:58:34 ncopa: I'll see. It would be really nice to visit. 2019-10-11 15:59:39 ncopa: I started to work on adding more SBC's/SOC's to armv7 kernel, some kind of multi platform support 2019-10-11 16:00:05 not sure should it go to linux-vanilla or separate package 2019-10-11 16:00:49 plan is to enable more drivers and needed options 2019-10-11 16:01:20 such kernel will increase in size by double if not more 2019-10-11 16:02:29 you don't need to answer now, but we should have solution for this because more and more users ask for such kernel in alpine 2019-10-11 16:03:06 (featurism, yes I know) 2019-10-11 16:06:37 https://github.com/alpinelinux/aports/pull/11873 2019-10-11 16:06:40 can this be merged? 2019-10-11 16:13:51 ncopa: made some merge requests for sqlite3 and other CVEs :D 2019-10-11 16:27:03 anyone know what is J0WI (on github)'s name here in IRC ? 2019-10-11 16:27:23 <_ikke_> tmhoang: I've never seen them on irc 2019-10-11 16:42:04 If I had a question about a package (and recent changes) would I ask it here or in the main channel? 2019-10-11 16:42:37 <_ikke_> here 2019-10-11 16:45:13 Thank you! I'm trying to compile postgis from source and am getting the error `could not find libproj - you may need to specify the directory of a PROJ.4 installation using --with-projdir`. Was the proj-dev package updated recently to move the files, or has something else broken? proj-dev is currently on the edge branch, so I expect occasional 2019-10-11 16:45:14 issues but I can't figure this one out 2019-10-11 16:46:09 I used to use the `proj4-devel` package but that was replaced with `proj-devel`, and it was working fine a week or two ago 2019-10-11 16:53:20 <_ikke_> The last change to that package was about a month ago 2019-10-11 16:53:26 <_ikke_> which was just an upgrade 2019-10-11 16:54:16 <_ikke_> so rename proj4 -> proj, upgrade to 6.1.1 -> upgrade to 6.2.0 2019-10-11 16:57:29 Yeah, I can install the `proj-devel` package just fine I just can't figure out where the PROJ.4 installation is located 2019-10-11 16:59:48 <_ikke_> There is no package containing a PROJ.4 file 2019-10-11 17:00:14 <_ikke_> I have no idea whether that changed or not 2019-10-11 17:01:23 Yeah that's what's causing me confusion, I'm not sure if that's just what they're calling the binaries or if there's an actual file they expect to be somewhere 2019-10-11 17:44:30 If I try to look at the build log of the `proj-dev` package it says 404, is that normal? 2019-10-11 17:44:37 https://pkgs.alpinelinux.org/package/edge/testing/x86_64/proj-dev 2019-10-11 18:45:22 Leo: community/wireshark: add missing secfixes 2019-10-11 18:45:37 Source branch does not exist. Please restore it or use a different source branch 2019-10-11 18:45:55 can you: git format-patch -1 --stdout | tpaste 2019-10-11 18:45:59 and i'll merge it now 2019-10-11 18:57:21 _ikke_, ncopa: would you mind helping me to check real quick if this patch still makes sense ? : https://git.alpinelinux.org/aports/tree/main/luajit/module-paths.patch 2019-10-11 18:58:14 I don't think we have any lua modules live under /usr/share/lua/common at this time. All the search I see already live in /usr/share/lua (which is already covered) 2019-10-11 18:59:20 ncopa: also, as you may already know luajit upstream is quite inactive, there is an active "fork" that Fedora + SUSE have been picking patches from in the last year. I'm doing so for at least s390x, so that maybe leter if we are confident we could enable to all arches. 2019-10-11 19:00:11 sorry, i need to have weekend now. please ping me monday and i'll have a look at it 2019-10-11 19:00:20 i looked at luajit earlier today 2019-10-11 19:00:29 i think we may want use the fork 2019-10-11 19:00:46 ncopa: I can finish by Monday :) Enjoy, tty soon 2019-10-11 19:32:36 For that builder failure currently, https://gitlab.alpinelinux.org/alpine/aports/merge_requests/413 is required 2019-10-11 19:34:53 dammit, i can't push to main 2019-10-11 19:35:08 @ncopa @ikke can i get a quick merge for !413 ? 2019-10-11 20:36:11 <_ikke_> maxice8: yes, looking at it now 2019-10-11 20:36:22 thank you 2019-10-11 20:44:03 <_ikke_> maxice8: ah, that explains 2019-10-11 20:44:34 yes 2019-10-11 20:45:03 the PR didn't deal with the merging of kwrite into kate and it did a big messy conflict 2019-10-11 20:45:28 <_ikke_> yay 2019-10-11 20:46:24 Also made lots of security MRs :D 2019-10-11 20:46:40 <_ikke_> yeah, will be looking at them 2019-10-11 20:48:24 ty :D 2019-10-11 20:50:29 <_ikke_> We lost the s390x CI builder :( 2019-10-11 20:54:44 D: 2019-10-11 20:57:14 _ikke_: but you can simulate it with docker buildx, right? 2019-10-11 20:59:27 <_ikke_> nrxr: not sure what you are referring to 2019-10-11 21:00:29 _ikke_: if I understand correctly the machine that was building packages for s390x is no longer available? 2019-10-11 21:00:55 <_ikke_> nrxr: It's unreachable, I expect it to come back eventually 2019-10-11 21:02:04 Oh, I see. I was basically suggesting to use docker to emulate the platform https://docs.docker.com/buildx/working-with-buildx/, pretty much qemu. 2019-10-11 21:03:50 <_ikke_> ok, an experimental feature 2019-10-11 21:06:17 well, putting it like that you make it sound really bad 2019-10-11 21:49:47 Fixed some builder failures https://gitlab.alpinelinux.org/alpine/aports/merge_requests/428 2019-10-11 22:20:34 Merged 2019-10-11 22:33:45 maxice8: another one https://gitlab.alpinelinux.org/alpine/aports/merge_requests/429 2019-10-12 06:32:40 anyone available to make a wiki edit for me? 2019-10-12 06:32:46 yes sure 2019-10-12 06:32:49 what is wrong 2019-10-12 06:33:22 I'm trying to delete some childish junk from https://wiki.alpinelinux.org/w/index.php?title=Alpine_and_UEFI 2019-10-12 06:34:20 the whole 2nd paragraph in the "secure boot" section can be removed, I created an account but it's less than 5h old so I can't add ip addresses or phone numbers... which also means I can't delete text it seems 2019-10-12 06:35:27 should also delete the meaningless authors' thought at the end of the first paren 2019-10-12 06:35:51 i'll try to fix it 2019-10-12 06:36:03 cheers mate, thanks 2019-10-12 06:36:08 the whole page seems so immature 2019-10-12 06:36:14 terrible 2019-10-12 06:37:44 it really is 2019-10-12 06:39:03 also, while I'm here... I'm trying to compile a custom kernel and both the wiki guide and the linux-vanilla APKBUILD are aweful 2019-10-12 06:39:11 "there must be a better way!" 2019-10-12 06:39:17 any one have any suggestions 2019-10-12 06:39:42 awful* 2019-10-12 06:39:48 i'll see if I can edit it tomorrow, some info on that wikipage is fine 2019-10-12 06:40:02 but very messy 2019-10-12 06:40:30 nicolaus: if you'd like, ping me 2019-10-12 06:40:34 ok 2019-10-12 06:40:57 I've just spent 5hours today getting refind set up to work nicely with alpine and windows 2019-10-12 06:41:21 there's no good information for dualbooting on the wiki, but the setup configuration was pretty easy for me 2019-10-12 06:41:38 no idea about that 2019-10-12 11:06:04 anyone with builder access around? seems like some builds are currently stuck during index signing 2019-10-12 11:08:47 never mind 2019-10-12 16:57:24 :D got MR for CVEs for people that can push to main/ 2019-10-12 17:24:31 anyone know if ncopa idles around here or if email is the best way to ask questions about the linux-vanilla APKBUILD? 2019-10-12 17:26:11 just ask right ahead 2019-10-12 17:26:12 grayhatter: most developers are quiet over weekends, usually 2019-10-12 17:26:30 weekends? what are those? 2019-10-12 17:26:41 but as AinNero says, just ask 2019-10-12 17:27:22 why is linux-vanilla called that, and would you accept a patch that adds a APKBUILD for all the "flavors" and cleans up the build process a little? 2019-10-12 17:27:57 vanilla flavour is the base flavour for ice cream 2019-10-12 17:28:13 I'm working on installing alpine on a Microsoft Surface Book 2, and having a single kernel unversioned kernel is hard on my boot 2019-10-12 17:28:20 I see vanilla as simple linux kernel without addons 2019-10-12 17:28:38 grayhatter: you mean versioning in the kernel file name? 2019-10-12 17:28:44 it is, but I'm wondering why the kernel version number isn't attached 2019-10-12 17:28:57 if it was, you'd always need to autodetect it 2019-10-12 17:28:58 yes, I'm assuming there's a reason 2019-10-12 17:29:03 rewrite bootconfigs on every update 2019-10-12 17:29:16 because it will cumbersome for auto upgrade 2019-10-12 17:29:19 no, you could use links as well 2019-10-12 17:29:34 grayhatter: alpine can also be netbooted 2019-10-12 17:30:05 pxe configs are much more painful when the kernel name is versioned 2019-10-12 17:30:53 debian is using versioned kernel filenames, and debian is much worse than alpine (also due to other reasons) with regard to netboot 2019-10-12 17:31:20 grayhatter: alternatively, what is the problem that you need versioned filenames? 2019-10-12 17:31:45 I don't need versioned filenames 2019-10-12 17:31:58 I just like them when I'm trying to figure out where stuff broke 2019-10-12 17:32:18 uhm, so you want to be able to read the version from a existing kernel file? 2019-10-12 17:32:52 there's a reason for the kernel to be named linux-vanilla, so I'm not gonna change it with/if any patches to fix the flavors code 2019-10-12 17:33:23 there is linux-virt and there /was/ linux-hardened (which was grsecurity) 2019-10-12 17:33:35 AinNero: I can, but if one kernel doesn't boot, all I can do is list the name from refind 2019-10-12 17:33:42 unless there's another way? 2019-10-12 17:34:41 grayhatter: yes, and we discussed this some time ago but without solution, for now at least 2019-10-12 17:34:51 ugh 2019-10-12 17:34:56 tbh the EFI stuff puts me off 2019-10-12 17:35:00 s/solution/conclusion/ 2019-10-12 17:35:00 mps meant to say: grayhatter: yes, and we discussed this some time ago but without conclusion, for now at least 2019-10-12 17:35:18 ... 2019-10-12 17:35:29 uhm, and chain-loading grub? 2019-10-12 17:35:31 well... that's a feature 2019-10-12 17:35:34 no 2019-10-12 17:35:47 refind boots the kernel directly 2019-10-12 17:36:40 instead of using the refind menu, you could use the grub menu from the grub config the alpine scripts generated 2019-10-12 17:36:48 it should be doable to include the kernel version there 2019-10-12 17:37:15 yes, that's a thing I *could* do. But I don't think it's a good idea 2019-10-12 17:38:42 grayhatter: I do this, preserve older kernel which boot in grub menu 2019-10-12 17:39:00 mps: via the update-extlinux scripts? 2019-10-12 17:39:43 and if upgraded kernel fail (which is not happened for long time) I have rescue kernel to fix problem 2019-10-12 17:39:57 AinNero: yes 2019-10-12 17:40:21 mps: im interested on how you did it, post code? 2019-10-12 17:40:23 lets see, no it is syslinux 2019-10-12 17:40:27 related: can someone explain why the subpackages are written they way they are in the linux-vanilla APKBUILD? 2019-10-12 17:41:11 AinNero: but I usually did something similar with grub on debian 2019-10-12 17:43:02 grayhatter: whats your bother with it? 2019-10-12 17:43:12 it doesn't seem weird to me... 2019-10-12 17:43:54 why should I add grub, when I'm already using refind, and refind can already boot linux? 2019-10-12 17:44:29 because refind doesn't do what you want 2019-10-12 17:45:01 or maybe you can hack the update-extlinux scripts to feed the kernel version into refind 2019-10-12 17:45:19 <_ikke_> maxice8: are you forwarding PRs from github to gitlab? 2019-10-12 17:47:00 ikke: forwarding you mean closing on github and opening on gitlab? 2019-10-12 17:48:15 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/418 this one for example? 2019-10-12 17:48:25 <_ikke_> The author is J0WI 2019-10-12 17:49:03 <_ikke_> I didn't check github 2019-10-12 17:49:23 It's a backport 2019-10-12 17:49:42 <_ikke_> ah ok, you probably cherry-picked the commit? 2019-10-12 17:49:49 I just took the commit from :master and applied to :3.10-stable 2019-10-12 17:49:52 <_ikke_> nod 2019-10-12 17:50:05 Switched to 3.10-libgcrypt and applied with git am 2019-10-12 17:50:39 AinNero: what makes you think that refind can't do what I want, where grub can? 2019-10-12 17:52:39 alpine already has support for generating grub configs 2019-10-12 17:52:44 so i'd assume its less work 2019-10-12 18:07:08 not if I'm already building myself a custom kernel 2019-10-12 18:11:00 grayhatter: if you are already building a custom kernel, why bother with refind instead of booting linux as efistub? 2019-10-12 18:11:44 because then I can also boot windows, and recover when the kernel I just built is missing something important... like the ability to boot :D 2019-10-12 18:12:11 does using efistub exclude using windows? 2019-10-12 18:12:38 <_ikke_> maxice8: I get an error when trying to build sqlite on 3.8: "install: can't stat './sqlite3.h sqlite3ext.h': No such file or directory" 2019-10-12 18:13:08 _ikke_: i'll take a look soon, updating the secissues 2019-10-12 18:14:02 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/420 for reference 2019-10-12 18:14:16 hehe 2019-10-12 18:14:47 AinNero: yeah, the Surface book ships with a shallow version of UEFI "loader" 2019-10-12 18:15:02 or maybe I just don't know how to use it 2019-10-12 18:41:19 why is -j1 specified in some locations of the linux-vanilla APKBUILD? 2019-10-12 18:41:29 *in the make commands 2019-10-12 18:41:42 <_ikke_> grayhatter: probably because it breaks when run in parallel 2019-10-12 18:42:06 ^ 2019-10-12 18:42:20 that's what I'm asuming but I was wondering what exactly breaks 2019-10-12 18:44:23 Blame it 2019-10-12 18:45:08 <_ikke_> (and hope someone actually documented why) 2019-10-12 19:08:31 should we wait for s390x CI runner to start work and finish to ask for merging MR's 2019-10-12 19:08:53 <_ikke_> I think I'll disable the s390x job for now, until it's returned 2019-10-12 19:11:55 ok, sorry for annoying but if someone have time to push !412 2019-10-12 19:12:31 I tested build on aarch64 and armv7 and it passed all CI's except non working s390x 2019-10-12 19:13:01 need it pushed to upgrade iwd 2019-10-12 19:13:05 <_ikke_> yes, hold on 2019-10-12 19:13:16 <_ikke_> talking about aarch64, I'm about to enable jobs for that arch :) 2019-10-12 19:13:31 you mean CI 2019-10-12 19:13:33 <_ikke_> yes 2019-10-12 19:13:38 ah, ok 2019-10-12 19:13:44 np, then 2019-10-12 19:13:50 will wait 2019-10-12 19:18:46 <_ikke_> ok, done 2019-10-12 19:19:09 <_ikke_> maxice8: did you have time to look at sqlite yet? 2019-10-12 19:19:48 Not yet, it will take a few hours 2019-10-12 19:21:11 <_ikke_> ok 2019-10-12 19:21:49 <_ikke_> mps: could you try to rebase that ell MR onto the latest master? 2019-10-12 19:27:00 _ikke_: I can, but are you it is needed 2019-10-12 19:27:29 <_ikke_> It's not required, it's just to test things work :) 2019-10-12 19:27:41 aha, understand 2019-10-12 19:27:51 lets see 2019-10-12 19:28:27 uh, no, still building kernel 5.3 from this aports repo 2019-10-12 19:28:39 <_ikke_> ah ok 2019-10-12 19:28:43 about one hour later 2019-10-12 19:28:44 <_ikke_> n/m then 2019-10-12 19:29:31 I'm testing config changes which will be needed for big leap of kernel 5.4 2019-10-12 19:30:17 all fans on my box make max noise ;) 2019-10-12 19:31:15 <_ikke_> haha 2019-10-12 19:31:47 <_ikke_> arg, varnish build fails for me because I use zsh as shell :-/ 2019-10-12 19:31:56 <_ikke_> works if I do SHELL=/bin/sh abuild -r 2019-10-12 19:32:23 sometimes I have issues with tcsh 2019-10-12 19:33:17 then I switch to /bin/sh 2019-10-12 19:38:23 <_ikke_> mps: ell is pushed 2019-10-12 19:39:03 _ikke_: I see, thanks 2019-10-12 19:42:04 <_ikke_> wow, 42 pending jobs 2019-10-12 19:43:35 <_ikke_> and counting 2019-10-12 19:47:50 well, people at works 2019-10-12 19:48:02 just syncing all my branches :D 2019-10-12 19:49:36 <_ikke_> https://imgur.com/a/mWX28LK 2019-10-12 19:49:48 beautiful 2019-10-12 19:51:42 <_ikke_> Was trying to find an API to get a global count of pending jobs, but apparently that does not exist yet 2019-10-12 19:54:11 'lab mr list gitlab -n 500 | wc -l' => 68 :) 2019-10-12 19:54:26 <_ikke_> yup 2019-10-12 19:54:39 <_ikke_> Those are merge requests, not pending CI jobs 2019-10-12 19:54:56 ah, I misunderstood 2019-10-12 20:49:30 hmm.. did we have any possibility to build only subpackage from the APKBUILD ? 2019-10-12 20:50:06 <_ikke_> nope 2019-10-12 20:50:47 <_ikke_> You first need to build the entire package to get a subpackage in the first place 2019-10-12 20:51:10 <_ikke_> technically you could then only package a single subpackage, but afaik that's not implemented 2019-10-12 20:51:30 or just rm -rf all the other produced packages :D 2019-10-12 20:52:50 heh =) 2019-10-12 20:57:46 when building rpi kernel, it just builds all to target architecture and that is not quite needed.. 2019-10-12 20:58:14 since I only want to have rpi4 configuration. separate APKBUILD, that is then 2019-10-12 20:59:07 unless someone has repo already for aarch64 rpi4 ? =) 2019-10-12 21:00:54 by the looks of it, rasbian will be also 64bit, as their kernel source is 64bit ready 2019-10-12 21:11:01 <_ikke_> maxice8: it's becoming crazy now, 150 pending jobs... 2019-10-12 21:11:17 all were synced 2019-10-12 21:13:48 <_ikke_> Is this stuck? https://gitlab.alpinelinux.org/Leo/aports/-/jobs/3504 2019-10-12 21:14:09 ah no, python3 tests are know to be supeeeer long 2019-10-12 21:16:02 <_ikke_> Job will stop at the 2h mark 2019-10-12 21:22:57 oh, didn't see the actual time 2019-10-12 21:23:01 yeah seems stuck 2019-10-12 21:23:33 it took a few minutes for me when building locally 2019-10-12 21:25:24 <_ikke_> Not sure why it goes so slow there 2019-10-12 21:25:37 <_ikke_> it does look stuck 2019-10-12 21:25:47 <_ikke_> I don't see any progress 2019-10-12 21:33:53 slow days, building linux-vanilla on my box for more than 2 hours and still not finished 2019-10-12 21:34:13 6GB RAM, i7 CPU, SSD disk 2019-10-12 21:36:57 oh, just finished, but 'ld: final link failed: No space left on device'. need to increase RAM for lxc 2019-10-12 21:46:21 s/RAM/disk space/ 2019-10-12 21:46:21 mps meant to say: oh, just finished, but 'ld: final link failed: No space left on device'. need to increase disk space for lxc 2019-10-12 21:58:00 mps, I'm compiling a kernel for the 4th time 2019-10-12 21:58:21 I need a threadripper, 2h delay is insane 2019-10-12 22:16:57 grayhatter: on armv7 and aarch64 it works a lot faster 2019-10-12 22:17:37 don't know why it is so slow in my x86_64 lxc 2019-10-12 22:22:56 damn it, another build failure for the -dev subpackage 2019-10-12 22:23:09 this is so fustrating 2019-10-12 22:28:08 hey, which sed is more correct: s/^;uname=$/uname=murmur/ or s/^\;uname=$/uname=murmur/ (is about how treat semicolon ";") ? 2019-10-12 22:29:50 MY-R: second is safer 2019-10-12 22:30:04 that what I thought 2019-10-12 22:30:16 Im not sed guru :P 2019-10-12 22:30:51 nor am I, but if in doubt i use '\' 2019-10-12 22:30:59 exactly! 2019-10-12 22:31:33 mps, you can save the world by some simple pull request! :D https://gitlab.alpinelinux.org/alpine/aports/issues/10863 2019-10-12 22:32:22 ACTION rly need to learn how to use git stuff :P 2019-10-12 22:32:58 maybe tomorrow, if I find some time, just going to bed 2019-10-12 22:33:14 :) 2019-10-12 22:33:26 and good night to all 2019-10-12 22:33:43 sleep well mps! 2019-10-12 22:34:23 thanks, will try :) 2019-10-12 22:36:24 ps when Im doing custom kernel I always delete -virt stuff since dont need it so compilation can be shorter 2019-10-12 22:42:32 MY-R: there's no need to escape ; since its use is for separating commands, so it has no special use within a // command, only outside 2019-10-12 22:42:57 MY-R: you can see more on it in the manual: https://www.gnu.org/software/sed/manual/html_node/sed-script-overview.html#index-_003b_002c-command-separator 2019-10-12 22:44:34 These are the ones you need to escape: $.*[\^ because they are used for the regex and {}()\/+?| because they have special meaning within a command 2019-10-12 22:44:36 nrxr, ye but in APKBUILD ; is already in use to do that separation so that is why I felt that weird to not use it with \ 2019-10-12 22:44:53 https://git.alpinelinux.org/aports/tree/community/mumble/APKBUILD?h=3.10-stable#n82 2019-10-12 22:45:23 I see: there's no strict need but indeed, it makes it _clearer_ for the one reading the sed command that its purpose is within the command 2019-10-12 22:46:04 yee 2019-10-12 22:46:27 Yeah, it's being used correctly there. 2019-10-12 22:46:56 I would use a space between / and ; for separating the commands, though, since is more visually appealing and therefore clearer to read 2019-10-12 22:47:03 with ; instead of # right? 2019-10-12 22:47:07 ah 2019-10-12 22:47:49 so s/^#uname=$/uname=murmur/;\ would be s/^#uname=$/uname=murmur/ ; \ 2019-10-12 22:48:22 but that's not technically required, neither. Just an estetic suggestion 2019-10-12 22:48:53 oh, ok thank you for clearing that up :) 2019-10-12 22:49:27 glad to be helpful in some way ;-) 2019-10-12 22:51:27 btw, MY-R, maybe https://git.alpinelinux.org/aports/tree/community/mumble/APKBUILD?h=3.10-stable#n97 should describe that package as "Documentation for the server component of Mumble" 2019-10-12 22:52:42 agree, sounds much better 2019-10-12 22:54:11 so I will need check out how I should use git... and then could contribute to my favorite distribution :) 2019-10-12 22:57:43 This is a great start https://guides.github.com/introduction/git-handbook/ 2019-10-12 22:58:04 Is not that hard, focus on the basics: branching, making a commit 2019-10-12 22:58:21 And then using git am for creating patches that can be sent to the alpine-devel mailing list 2019-10-12 23:00:25 wrong command, is not git am, that's for applying. It's git format-patch the one you should check 2019-10-12 23:00:31 yep I need focus and study that a bit more :) 2019-10-12 23:00:33 There's more info on the wiki of alpine 2019-10-12 23:00:42 Here: https://wiki.alpinelinux.org/wiki/Creating_patches 2019-10-12 23:02:06 ye and there are few quirks which are distribution specific things but that can learn from Alpine channels :> 2019-10-12 23:08:17 MY-R: if you have time now, I can help you. Just ask. I have some knowledge on this. 2019-10-12 23:10:51 ah damn maintenance rush hours! 2019-10-13 17:15:32 MY-R: to comment on your comment about building custom kernel from last night, I'm not building custom kernel but trying to test upgrade alpine kernel to 5.3.x and because of that I didn't trimmed anything 2019-10-13 17:16:41 when I build kernel for my local use on specific hardware it takes from 10 to 30 minutes to build, what depends on enabled options/drivers 2019-10-13 17:52:52 mps, my customization is based on default alpine config + just few settings change without any trims, I prefer system to stay as much vanilla possible :) 2019-10-13 18:00:49 MY-R: understand, but I working on WIP for next alpine linux-vanilla LTS and want to test needed changes 2019-10-13 18:01:19 I want to see what need to be changed and what must be changed 2019-10-13 18:01:53 (a lot of things to test) 2019-10-13 18:04:01 ACTION understood! 2019-10-13 18:04:10 oh ye can imagine :\ 2019-10-13 18:32:02 _ikke_: I'm preparing MR for ncurses bugfix release. we talked about changing url from 'www.gnu.org' to https://invisible-mirror.net/ncurses/ 2019-10-13 18:33:25 ncurses is still GNU Org project and there is the web page about it, so not sure should we change it. what is your advice 2019-10-13 18:33:57 <_ikke_> Not too sure either. The gnu.org link only shows a changelog 2019-10-13 18:34:22 Hello, the url should point to the one where you get the software. At least that's the debian policy on it and I think it's a safe and sound policy. 2019-10-13 18:34:41 You want the user to know where its software is coming from 2019-10-13 18:35:46 all files, ML and information are on invisible-mirror.net 2019-10-13 18:35:51 So probably https://invisible-island.net/ncurses/ncurses.html instead of the invisible-mirror ? 2019-10-13 18:36:10 I think it is ok to change it, but again not 100% sure 2019-10-13 18:36:31 nrxr: yes, island 2019-10-13 18:37:07 sorry, for confusion 2019-10-13 18:37:59 ML is still bug-ncurses@gnu.org 2019-10-13 18:38:04 I would be 100% sure you should point it to the source of the software. Reading there: the main source is island and GNU is used as an "also can be found there" 2019-10-13 18:38:20 Read here: https://invisible-island.net/ncurses/announce.html 2019-10-13 18:38:56 nrxr: I read that some time ago 2019-10-13 18:39:20 and I'm subscribed to ncurses ML 2019-10-13 18:39:31 Oh, no. I meant that I read that from there 2019-10-13 18:40:10 As a way to explain my thinking on the matter of which one is the main source 2019-10-13 18:40:44 but yes, I think proper url should be at invisible-island.net because there are more info's than gnu.org 2019-10-13 18:41:00 btw, the announce page is the only part where I can find links to GNU, the main one has all links to invisible-island.net 2019-10-13 18:41:50 and the gnu page points to invisible-island.net as well https://www.gnu.org/software/ncurses/ 2019-10-13 18:42:09 right 2019-10-13 18:42:26 so I'm 100% sure you should point it to invisible-island.net 2019-10-13 18:45:47 ok, here it is !457 2019-10-13 18:47:57 _ikke_: I tested fixing wrong MR, works very good 2019-10-13 18:49:20 MY-R: you asked me something on fix for murmur last night. could you tell me do you have patch or PR or MR for it 2019-10-13 18:50:36 so now you can do more than sending patches to the ML? 2019-10-13 18:51:28 yes, but PR on github works for long time 2019-10-13 18:52:09 but it will be probably closed when everything moves to gitlab.a.o 2019-10-13 18:52:52 maybe is better option to start sending merge requests to gl.a.o 2019-10-13 18:53:21 hmm, algitbot don't understand gl.a.o 2019-10-13 18:54:01 <_ikke_> gitlab.a.o 2019-10-13 18:54:10 mps, ahh nah I didnt do anything and prefer to not mess with public git :D but it is simple change "#" to ";" in line 82, 83 and 84 here: https://git.alpinelinux.org/aports/tree/community/mumble/APKBUILD?h=3.10-stable#n82 2019-10-13 18:54:57 in APKBUILD 2019-10-13 18:55:01 yep 2019-10-13 18:55:05 and in edge too 2019-10-13 18:55:09 lets see 2019-10-13 18:55:32 btw, did you tested it? last time I tried murmur it worked fine 2019-10-13 18:55:44 that is original murmur config after instalation now: https://tpaste.us/kZ56 2019-10-13 18:55:49 that was about 9 months ago 2019-10-13 18:56:16 ye working fine if your config is good but not working for people who doing fresh instalation 2019-10-13 18:57:00 cus for now if they do that then their log file going to /etc/murmur.log and murmur is running as root what is dangerous for such a service 2019-10-13 18:57:30 + pid file is missing and rc-status cant show if is running or not 2019-10-13 18:59:35 and ye I have murmur server so all that tested 2019-10-13 18:59:37 current APKBUILD is just 63 lines long 2019-10-13 19:00:14 ah, you speaking about version in 3.10-stable 2019-10-13 19:00:37 well in edge should be basically same 2019-10-13 19:00:52 BUT Im talking about murmur and not umurmur :) 2019-10-13 19:01:12 community/mumble/APKBUILD 2019-10-13 19:01:50 aha 2019-10-13 19:02:24 ye it is annoying for me too mumble/murmur and light version is umurmur... 2019-10-13 19:03:13 yes, now understand a little more 2019-10-13 19:03:42 few times I was confused by it too... and messed up config of both... 2019-10-13 19:04:41 :) 2019-10-13 19:05:00 so, this fix should go to 3.10-stable and edge 2019-10-13 19:05:05 yep 2019-10-13 19:05:40 ok, first will try edge and if it works fine then backport it to stable 2019-10-13 19:06:38 in edge APKBUILD lines are 83, 84, 85 2019-10-13 19:06:45 but that you for sure noticed 2019-10-13 19:06:53 ye, good idea :) 2019-10-13 19:07:38 yes, I see one line shift up 2019-10-13 19:07:55 and after can close issue: https://gitlab.alpinelinux.org/alpine/aports/issues/10863 2019-10-13 19:08:06 building it right now 2019-10-13 19:09:02 and going out for fresh air till it finish 2019-10-13 19:09:42 shouldnt take long, much more taking dependency installation :P 2019-10-13 19:09:51 but ye, thanks! 2019-10-13 19:28:58 MY-R: abuild error 'sed: -e expression #1, char 205: unterminated address regex' 2019-10-13 19:30:22 diff to APKBUILD is here http://tpaste.us/Erog 2019-10-13 19:32:10 mps, huh :\ so need put \ before those ; ? 2019-10-13 19:33:09 I think so 2019-10-13 19:34:14 I was checking sed one by one and was fine 2019-10-13 19:34:37 but if sed contain ; as a separators then need use \ 2019-10-13 19:35:32 uh no, even \; didn't worked 2019-10-13 19:35:44 damn 2019-10-13 19:35:48 I need to refresh sed syntax 2019-10-13 19:36:17 is busybox sed 2019-10-13 19:37:21 I think so 2019-10-13 19:51:53 mps, working for me just fine without any \ [] etc 2019-10-13 19:53:58 I just built package, installed and it created correct config 2019-10-13 19:55:25 MY-R: sorry, my mistake 2019-10-13 19:55:39 heh 2019-10-13 19:55:51 sed is left after failed linux-vanilla build 2019-10-13 19:55:57 it works 2019-10-13 19:56:09 :D 2019-10-13 19:56:20 ok so we both tested it already 2019-10-13 19:57:23 yes 2019-10-13 19:57:52 in a hurry I forgot to check stalled deps for other pkg 2019-10-13 19:59:22 do you build it from aports git repo 2019-10-13 20:00:24 mps yep 2019-10-13 20:00:54 you can then post patch 2019-10-13 20:02:11 ye but Im after few beers already... so will educate myself in a better time :> 2019-10-13 20:02:21 ok, np 2019-10-13 20:02:36 but ye, thank you :) 2019-10-13 20:06:12 it is on builders 2019-10-13 20:24:15 hmm, ERROR: libx11-dev-1.6.9-r0: trying to overwrite usr/include/X11/extensions/XKBgeom.h owned by xorgproto-2019.1-r1. 2019-10-13 20:26:17 mps, during mumble? 2019-10-13 20:26:28 yes 2019-10-13 20:27:03 libx11-dev-1.6.9 is in conflict with xorgproto-2019.1 2019-10-13 20:27:04 I was building it before that commit main/libx11: upgrade to 1.6.9 2019-10-13 20:27:10 obviously 2019-10-13 20:27:32 right, also on my local builder it worked 2019-10-13 20:28:10 maybe just need to wait when builders finish with libx11 2019-10-13 20:29:13 bad timing :D 2019-10-13 20:29:31 or dunno... 2019-10-13 20:30:56 no, it now fails on my local builder because libx11-dev is just upgraded 2019-10-13 20:32:06 ah 2019-10-13 20:32:10 <_ikke_> ACTION hides 2019-10-13 20:32:33 :D 2019-10-13 20:33:19 libx11-dev or xorgproto need to be fixed 2019-10-13 20:35:31 working on it 2019-10-13 20:35:37 my bad,missed the addition of the file 2019-10-13 20:36:45 maxice8: np, we all make errors 2019-10-13 20:37:44 but how fast that error was caught! :> 2019-10-13 20:37:47 but we should note somewhere will this file (XKBgeom.h) be removed in next xorgproto upgrade 2019-10-13 20:38:06 mps: Removal of files from xorgproto was also done in the past 2019-10-13 20:38:41 I already looked but didn't seen new xorgproto upstream 2019-10-13 20:39:22 so, probably will be in new release 2019-10-13 20:39:30 https://pkgs.alpinelinux.org/package/edge/main/x86_64/libxvmc-dev 2019-10-13 20:40:57 yes, that happens 2019-10-13 20:42:01 time to check 3.8-sqlite 2019-10-13 20:52:20 MY-R: looks like someone fixed the mumble package 2019-10-13 20:57:28 nicolaus, you can send beer/wine to mps :) 2019-10-13 20:58:26 cool 2019-10-13 20:58:40 i'm trying to see if my distribution already has the package 2019-10-13 20:59:01 and read backlog of this channel from 20:49 CET 2019-10-13 21:00:18 MY-R: done :P 2019-10-13 21:00:23 i think it's not yet in stable 2019-10-13 21:00:35 just did a fresh install and didn't work 2019-10-13 21:00:41 gonna do more research about it 2019-10-13 21:03:21 nicolaus, well... it will be there sooner or later but in that time you can just manualy fix your murmur.ini config, your rc-status issue was caused by missing pid file path 2019-10-13 21:03:39 oh yes! i forgot to fix the pid 2019-10-13 21:03:48 thanks 2019-10-13 21:04:27 :) 2019-10-13 21:04:40 based 2019-10-13 21:04:56 i didn't know that problem had to do with it, learnt something new 2019-10-13 21:05:03 nicolaus: I want to see if it build on all arches in edge before push to 3.10-stable 2019-10-13 21:05:27 mps: did you fix the sqlite permission? 2019-10-13 21:06:34 nicolaus, sqlite permission, rc-status issue was caused by those sed lines in APKBUILD 2019-10-13 21:06:47 oh ok 2019-10-13 21:06:54 nicolaus, you got wrong config and started murmur as a root first so that is why permissions were wrong 2019-10-13 21:09:11 after fix all will be fine, murmur server will be running by "murmur" user, pid file will be in right place same as log file 2019-10-13 21:09:12 anyone here using (e)udev on alpine? 2019-10-13 21:09:32 yes 2019-10-13 21:10:24 i think we are using /lib/udev/rules.d as ruledir? 2019-10-13 21:10:52 mostly 2019-10-13 21:11:07 but i see most other distros using /usr/lib/udev/rules.d 2019-10-13 21:11:11 https://i.imgur.com/rzZr8GE.png 2019-10-13 21:11:26 i think most other distros have done usrmerge 2019-10-13 21:11:41 but are both directories used by eudev? 2019-10-13 21:12:25 yes 2019-10-13 21:12:26 we pass --enable-split-usr 2019-10-13 21:12:40 src/udev/udev-rules.c:56,59 2019-10-13 21:12:51 hmm 2019-10-13 21:12:53 ok 2019-10-13 21:13:04 then my fix was not a real fix 2019-10-13 21:13:39 unless they (upstream) broke it without anybody noticing 2019-10-13 21:14:14 ok i just tested it 2019-10-13 21:14:18 seems to work as you said 2019-10-13 21:15:41 it seems we do not ship lvm2 with udev rules 2019-10-13 21:15:55 I think /lib/udev/rules.d is for system programs and /usr/lib/udev/rules.d is for userspace programs 2019-10-13 21:16:30 mps: Not really 2019-10-13 21:18:18 and i think multipath needs t hem 2019-10-13 21:19:45 clandmeter: pass --enable-udev_rules to lvm2 to enable it 2019-10-13 21:20:04 i know how to add them 2019-10-13 21:20:15 i wonder how to ship them 2019-10-13 21:20:25 i guess with device-mapper 2019-10-13 21:20:33 or else a seperate pkg 2019-10-13 21:22:11 device mapper sounds right 2019-10-14 00:58:44 any interest in an aports patch for a specific hardware kernel? 2019-10-14 06:08:44 grayhatter: can you be more specific? 2019-10-14 06:09:53 I've just "finished" an APKBUILD for a custom kernel to enable a bunch of hardware for a Microsoft Surface (Book/laptop/tablet) 2019-10-14 06:10:17 pastebin the patch 2019-10-14 06:10:32 it's a bunch of stuff that obviously doesn't belong in the main kernel, but as far as I can tell, there's nothing like the AUR for alpine 2019-10-14 06:10:48 if its just some drivers we can probably just add them to vanilla 2019-10-14 06:11:51 it's ugly AF, I can clean it up, but basically it's pulling a custom 5.3 tree and skipping all the submodule stuff 2019-10-14 06:12:21 ok so you need 5.3 2019-10-14 06:12:27 I tried applying patches the way the wiki suggests, but that I never got to build 2019-10-14 06:12:44 ah its based on out of tree patches? 2019-10-14 06:12:53 maybe not, there's versions available for 4.9 & 5.1 2019-10-14 06:13:05 but I pulled 5.3 because it has the camera drivers I wanted to play with 2019-10-14 06:13:23 there was an idea to introduce a new kernel 2019-10-14 06:13:28 lts and vanilla 2019-10-14 06:13:34 clandmeter: Can you push to main/ ? i need !459 pushed to fix building on -edge 2019-10-14 06:13:43 so vanilla will be in community 2019-10-14 06:13:49 and follow latest stable kernel 2019-10-14 06:13:54 maxice8: sure 2019-10-14 06:14:27 that's an interesting idea 2019-10-14 06:14:51 I think both vanilla and lts belong in main though 2019-10-14 06:15:05 but we will never add custom kernels (other than rpi) 2019-10-14 06:15:21 only lts can go to main due to support cycle 2019-10-14 06:15:51 clandmeter: right, but you're not dropping support for linux, you're just adding new versions 2019-10-14 06:16:23 I think I understand the support cycle between main/community, but I don't think you should lock support to a specific version number 2019-10-14 06:16:49 5.2 -> 5.3 is still supported, no? 2019-10-14 06:20:18 what do you mean? 2019-10-14 06:26:12 clandmeter: main promises support for [time] and community is for packages where support is promised for [shorter time] 2019-10-14 06:26:36 I don't think support should mean at this very specific version 2019-10-14 06:27:06 unless I'm missing something important? That said, I've only ever used rolling-release/edge linux flavors 2019-10-14 08:39:15 I'm having problems with building data.tar.gz in an apk. Last week I got this command as a suggestion: tar --xattrs -f - -c . | abuild-tar --hash | gzip -9 > data.tar.gz 2019-10-14 08:39:28 it works fine, but busybox tar is missing the --xattrs option 2019-10-14 08:40:31 and without that the package isn't correct (and can't be installed with apk). Is there any way around this? Would it be possible to use abuild-tar? I'm unable to find support for this in the source code but perhaps I'm missing something 2019-10-14 08:41:18 dear C/musl coder wizard, what is the alternative to g_critical() for musl? 2019-10-14 08:43:57 fcolista: isn't that function from glib 2019-10-14 08:44:03 yes 2019-10-14 08:44:19 that's why I'm asking for an alternative for musl 2019-10-14 08:44:42 <_ikke_> glib != glibc 2019-10-14 08:45:06 <_ikke_> Gnome Lib vs Gnu Libc 2019-10-14 08:45:19 I'm far from musl wizard but I doubt there will be musl implementation of this 2019-10-14 08:45:20 oh man.. 2019-10-14 08:45:31 _ikke_, thx 2019-10-14 08:45:35 you are right 2019-10-14 08:45:49 I'm dealing with openvas that is glibc-centric 2019-10-14 08:46:06 But in this case is not glibc.. 2019-10-14 08:46:07 right 2019-10-14 08:46:10 thanks! 2019-10-14 08:48:17 turns out that abuild is using gnu tar instead of busybox. That's a bit sad :( 2019-10-14 08:49:51 how to push to specific branch in aports on git.a.o, stable for example? I do 'git pull origin 3.10-stable' to pull changes 2019-10-14 08:50:30 so, I thinking just replace pull with push? 2019-10-14 08:50:52 i.e. 'git push origin 3.10-stable'. right? 2019-10-14 08:52:44 <_ikke_> fredrigu: correct 2019-10-14 08:52:47 <_ikke_> mps: * 2019-10-14 08:53:32 <_ikke_> fredrigu: busybox only imlements a subset of functionality to remain small. There is (imo) nothing wrong to use the full version of tools when you need the functionality 2019-10-14 08:54:18 _ikke_: ? 2019-10-14 08:54:52 didn't understood. Is my 'crystal ball' correct 2019-10-14 08:54:53 <_ikke_> mps: I hightlighted fredrigu by accident, but that was meant for you 2019-10-14 08:55:06 ah, ok, thanks 2019-10-14 08:55:14 <_ikke_> `git push origin 3.10-stable` pushes only that branch 2019-10-14 08:55:35 that is I need for now, thank you again 2019-10-14 08:59:52 ncopa: re: luajit . The fork has 2 branch : master and v2.1 . Master includes new features and v2.1 is meant to as bug fix for orignial usptream v2.1 branch. I think we should track master branch instead while we are doing this change. 2019-10-14 09:00:11 both master and v2.1 bug fix have snapshots 2019-10-14 09:00:31 also master has more fixes for ppc64le 2019-10-14 09:02:09 our ppc64le patch is for original v2.1 branch, iiuc (circa 2015) 2019-10-14 09:09:43 in fact, looking at the ppc64le situation, master branch of the fork added more ppc64le features and was rebased correctly by IBM guys 2019-10-14 09:09:50 https://github.com/LuaJIT/LuaJIT/pull/140 2019-10-14 09:10:17 so I think ppc64le would benefit the most by using master 2019-10-14 09:26:26 _ikke_: true, but when you already have 99% of what you need and you need to add another dependency to get the last 1% (which includes that you get a lot more than that 1%) it's not fun. But I totally understand the logic behind it, it saves time. 2019-10-14 11:03:52 ncopa: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/468 2019-10-14 11:09:48 tmhoang: i'll have a look at it in a bit 2019-10-14 11:10:08 i am skeptic to the pkgver 2019-10-14 11:10:18 currently we have pkgver=5.1.... 2019-10-14 11:10:42 this will chagne it to pkgver=20190925 2019-10-14 11:10:53 understand 2019-10-14 11:11:14 if we in the futer go back to 5.2 or similar, then will 20190925 > 5.2 2019-10-14 11:11:40 so i think it woudl be nicer with 5.1.20190925 or similar 2019-10-14 11:11:57 that way it will be possible to upgrade to 5.2 in future 2019-10-14 11:12:38 hah : /usr/lib/libluajit-5.1.so.2 . I was versioned after 5.1 2019-10-14 11:14:37 ncopa: or just keep the 2.1.0-beta3 since upstream also didn't change it 2019-10-14 11:15:10 but doesn't reflect the change 2019-10-14 11:57:15 ncopa: lvm has a new minor version, is that ok to upgrade? 2019-10-14 11:57:46 2.02.xxx vs 2.03.xxx 2019-10-14 12:03:07 ill just bump the patch version 2019-10-14 12:21:34 i'd guess its ok to upgrade 2019-10-14 12:23:50 oh btw 2019-10-14 12:23:58 ncopa: its the lvm2 udev scripts that create the multipath device. 2019-10-14 12:24:25 so finally something that works :) 2019-10-14 12:24:25 libaio doesn't seem to exist anymore with 0.3.111 version on http://ftp.debian.org/debian/pool/main/liba/libaio/ 2019-10-14 12:25:17 now to fix those initd scripts and be done with it. 2019-10-14 12:31:47 https://hastebin.com/inapafahem.bash here is diff for libaio, my network is lagging now to make a PR =) 2019-10-14 12:32:29 rnalrd seems to be maintainer for that 2019-10-14 12:36:36 yesterday I fixed community/mumble (with MY-R help) and same fix is needed for 3.10-stable 2019-10-14 12:37:13 but mumble in 3.10 is -rc1 release, and in meantime stable is released 2019-10-14 12:38:12 so, I think to upgrade to stable release also in 3.10 (with fixes, ofc). Is that ok for stable 2019-10-14 12:39:04 or, better to ask, anyone have objections to upgrade mumble to stable release in 3.10 2019-10-14 12:45:39 can someone remind me how to disable the build of a package? 2019-10-14 12:45:45 arch="" ? 2019-10-14 12:46:17 <_ikke_> yes 2019-10-14 13:05:06 fcolista: you are getting old 2019-10-14 13:05:18 clandmeter, so true../0\ 2019-10-14 13:05:40 luckly, i'm still behind you :P 2019-10-14 13:14:42 rnalrd: fcolista you ever used multipath on alpine? 2019-10-14 13:44:14 clandmeter, sometime ago, not recently 2019-10-14 13:44:24 rnalrd: hi 2019-10-14 13:44:30 i just pushed a few changes 2019-10-14 13:44:38 i hope i didnt break anything for you 2019-10-14 13:44:53 thanks, I don't think so :) 2019-10-14 13:45:21 it looked like it was already kind of broken 2019-10-14 17:55:23 ncopa: can you add CONFIG_DRM_AMDGPU to linux-vanilla for ppc64le when you get the chance, please 2019-10-14 21:06:33 Hi, I have an 'proposal' for a new directive in APKBUILDs to support some uses cases we face in postmarketOS, which is having to provide config files (e.g. /etc/conf.d/gpsd) which are device-specific and solving the problem that these conflict with - in that case - the gpsd package. 2019-10-14 21:06:48 I've written a few details at https://gitlab.com/postmarketOS/pmaports/issues/318#note_215375007 . Any comments? 2019-10-14 21:09:40 <_ikke_> I have a feeling apk / abuild is the wrong level to solve this issue 2019-10-14 21:11:05 <_ikke_> A common way to solve this is to have a directory where other packages can add conf files to which get automatically used 2019-10-14 21:13:34 well openrc only has /etc/conf.d/ as location afaik 2019-10-14 21:13:38 z3ntu: 'apk to allow a package to overwrite files from another package' doesn't sound like good idea 2019-10-14 21:14:02 at least without more elaboration 2019-10-14 21:21:48 <_ikke_> z3ntu: it would require support from gpsd I guess 2019-10-14 21:23:10 _ikke_: So you mean that gpsd reads the config not from the command line (configured by /etc/conf.d/gpsd) but from a config file? 2019-10-14 21:23:35 <_ikke_> for example 2019-10-14 21:31:23 Hm maybe we could use e.g. `gpsdctl add /dev/ttyUSB0` in a separate init script after gpsd starts 2019-10-14 21:32:33 <_ikke_> so anoying when APKBUILDs move files from $builddir instead of copying them 2019-10-14 21:32:46 <_ikke_> It prevents from running the package function twice if you are testing things 2019-10-14 21:43:02 sounds like a good rule to include in our non existing dev docs 2019-10-14 21:43:26 <_ikke_> nod 2019-10-14 21:43:35 <_ikke_> I run into it with the Zabbix package 2019-10-14 22:21:08 <_ikke_> ncopa: mind if I take over maintainership of Zabbix? 2019-10-15 03:43:05 Cogitri: i've updated pr 11879 and pr 11880 with the changes you requested 2019-10-15 04:15:35 Do we need to explicitly request PR merges here or will they eventually be reviewed/merged? 2019-10-15 04:25:26 <_ikke_> the latter 2019-10-15 04:50:43 <_ikke_> tmhoang: do you have any idea what might be going wrong here? https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/4750 cannot use &utsname.Sysname (type *[65]uint8) as type *[65]int8 in argument to arrayToString. This is failing on s390x and ppc64le. 2019-10-15 05:22:09 Hi, is there a maintainer around ? 2019-10-15 05:22:40 I've had a package sitting in the queue for 2 months without any feedback: https://github.com/alpinelinux/aports/pull/10107 2019-10-15 05:22:41 Geod24100: many are around but doing other things, you should ask what youd' like so they can respond when they see it 2019-10-15 05:22:45 Depends on what package you're talking about 2019-10-15 05:22:59 Wanted to check if there's a better place to submit it, perhaps ? 2019-10-15 05:22:59 I think pulls go to gitlab now don't they? 2019-10-15 05:23:44 I saw tons of PR on Github, and there's a CI setup, so that's where I went to, but if Gitlab is more active, happy to head there 2019-10-15 05:27:20 this is where I was pushed 2019-10-15 05:27:22 https://gitlab.alpinelinux.org/alpine/aports 2019-10-15 05:27:28 no idea what's cannon 2019-10-15 05:28:33 Well I'll try my luck there 2019-10-15 05:31:48 GitHub's fine too 2019-10-15 05:33:55 Cogitri Who should I ping for new packages then ? 2019-10-15 05:37:26 Probably no one, asking here after some time is best. I'll try looking at it this afternoon 2019-10-15 05:38:18 Thanks! 2019-10-15 05:59:20 _ikke_: please do 2019-10-15 06:05:01 <_ikke_> alright 2019-10-15 06:09:18 <_ikke_> Anyone familiar enough with Go to be able to tell what might be going on here? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/470 (build issues with x86 and s390x, ppc64le) 2019-10-15 06:12:16 seems like its struggeling with C types 2019-10-15 06:13:07 <_ikke_> Yes, indeed 2019-10-15 06:22:00 <_ikke_> maxice8: I would appreciate it if you would not rebase all your MRs every day, it generates a lot of noise 2019-10-15 06:25:42 _ikke_: does zabbix provide builds for those arches? 2019-10-15 06:26:26 <_ikke_> clandmeter: apparently not for the new agent 2019-10-15 06:26:36 <_ikke_> only x86_64 I see it 2019-10-15 06:26:38 <_ikke_> https://repo.zabbix.com/zabbix/4.4/ubuntu/pool/main/z/zabbix/ 2019-10-15 06:27:15 they only want you to monitor x86? 2019-10-15 06:27:17 :) 2019-10-15 06:27:42 <_ikke_> It has just been announced 2019-10-15 06:27:57 <_ikke_> It's a new project 2019-10-15 06:28:00 they do ship x86 2019-10-15 06:28:28 <_ikke_> The original agent has a very wide platform / arch support 2019-10-15 06:28:43 well i guess if you announce a new product you make sure it works? 2019-10-15 06:29:07 i think they have a large commercial audience? 2019-10-15 06:29:34 <_ikke_> Yes, they have their fair share of commercial users 2019-10-15 06:40:19 how do I know what is the name of the lib I should pass to the linker if Makefile is bugged? 2019-10-15 06:40:38 For insance, I need to pass gnutls to the linker 2019-10-15 06:40:54 how do I know that is -lgnutls, -ltsl or whatever? 2019-10-15 06:42:05 <_ikke_> I read the other day that it's looking for libgnutls or libtsl 2019-10-15 06:42:15 <_ikke_> lib 2019-10-15 06:42:29 where I can find this info (beside google ofc) 2019-10-15 06:43:42 <_ikke_> man ld? 2019-10-15 06:44:26 fcolista: Check what .so files a -dev package provides 2019-10-15 06:44:45 <_ikke_> "On systems which support shared libraries, ld may also search for files other than libnamespec.a. Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called libnamespec.a." 2019-10-15 06:44:58 And then pass -l 2019-10-15 06:45:17 <_ikke_> "-l namespec" 2019-10-15 06:45:25 interesting 2019-10-15 06:45:28 I have this issue: 2019-10-15 06:45:29 Error relocating /usr/lib/libgvm_util.so.11: gnutls_deinit: symbol not found 2019-10-15 06:45:41 I build with gnutls-dev ofcourse 2019-10-15 06:46:02 but I suspsect that is not seen 2019-10-15 06:50:43 _ikke_: so they include the go code in their main tree. 2019-10-15 06:50:48 sounds like lots of fun 2019-10-15 06:51:34 fcolista: Maybe the linking order is bad 2019-10-15 06:52:03 <_ikke_> clandmeter: they have everything in their main tree 2019-10-15 06:53:29 <_ikke_> setting GOPATH to $builddir makes it compile at least 2019-10-15 06:55:58 <_ikke_> clandmeter: I opened an issue on the Zabbix bug tracker about this 2019-10-15 06:56:09 fcolista: maybe you need to add '-L' i.e. library path 2019-10-15 06:57:13 but your error looks like incompatible version of libgvm_util with libgnutls 2019-10-15 06:59:20 mps, thats' what I suspect too 2019-10-15 06:59:59 debian builds with libgrypt28-dev 2019-10-15 07:01:06 not that I know anything about or what is libgvm 2019-10-15 07:01:34 gnutls >= 3.2.15 is a prerequirement 2019-10-15 07:02:07 which is met 2019-10-15 07:06:12 their gitlab is so slow 2019-10-15 07:07:13 their infra is dogslow 2019-10-15 07:10:46 two week ago I rebuilt mutt with gnutls and it worked, don't know if something is changed in meantime 2019-10-15 07:11:27 umh 2019-10-15 07:11:45 is it normal that ./.control.gnutls-utils/.provides-so is blank? 2019-10-15 07:11:53 I rebuilt gnutls 2019-10-15 07:12:04 cat ./.control.gnutls-utils/.needs-so 2019-10-15 07:12:04 libc.musl-x86_64.so.1 2019-10-15 07:12:04 libtasn1.so.6 2019-10-15 07:12:04 libgnutls.so.30 2019-10-15 07:12:10 but provides-so is empty 2019-10-15 07:13:14 ah ok 2019-10-15 07:13:15 is here: 2019-10-15 07:13:16 cat ./.control.gnutls/.provides-so 2019-10-15 07:13:16 libgnutls.so.30 30.25.0 2019-10-15 07:13:27 What should utils provide? 2019-10-15 07:13:45 I try to rebuild gvmd by passing -lgnutls to the linker 2019-10-15 07:14:08 @clandemeter, no it's correct 2019-10-15 07:14:16 utils should not provide anuyything 2019-10-15 07:14:27 Ok :) 2019-10-15 07:14:28 hmm, 'nm -D /usr/lib/libgnutls.so.30.25.0 | grep gnutls_deinit' shows '0000000000065214 T gnutls_deinit; 2019-10-15 07:16:32 *gvm-libs, not gvmd 2019-10-15 07:29:26 _ikke: I'm checking 2019-10-15 07:29:35 _ikke_ ^ 2019-10-15 07:30:11 building sudo 1.8.28 I got 'strsig_test: FAIL: str2sig(SIGSYS): -1 != 0'. we lost SIGSYS, or what 2019-10-15 07:30:32 <_ikke_> tmhoang: thanks 2019-10-15 07:32:56 http://dpaste.com/1ER25D8 2019-10-15 07:33:03 gnutls is not linked 2019-10-15 07:49:24 _ikke_: I see what you just did there hehe 2019-10-15 07:53:22 <_ikke_> What did I just do? 2019-10-15 07:59:50 poor little thunderx, please do your best in single core operations 2019-10-15 08:01:35 Uhh...do we not regenerate the initramfs when installing external modules (e.g. ZFS?) 2019-10-15 08:02:07 if there is no trigger i guess not 2019-10-15 08:49:32 _ikke_ : I just comment in your MR 2019-10-15 08:50:59 <_ikke_> tmhoang: Thanks :-) 2019-10-15 09:05:34 i'm looking into qt5-qtwebengine a bit, maybe i can fix it... 2019-10-15 09:18:54 I narrowed sudo check to SIGSYS issue. Anyone knows is something about this signal changed in musl 1.1.24 2019-10-15 09:28:49 python3 tests are also failing 2019-10-15 09:32:35 not sure is it safe (wise) to disable SIGSYS test in such security important pkg as is sudo 2019-10-15 09:33:13 would be good to know exactly why it fails first 2019-10-15 09:33:48 return '-1' instead of '0' 2019-10-15 09:34:14 probably will ask Felker, later 2019-10-15 09:35:32 I looked musl source but can't see anything about changes of SIGSYS in latest release, or I'm blind 2019-10-15 09:36:21 qa3Txu0iak0F: That'd be nice 2019-10-15 09:37:22 Can I somehow see if a certain package has also been modified in the current transaction? I want to regenerate the initramfs if zfs has been upgraded but only linux-vanilla hasn't been upgraded too (because we'd generate the initramfs twice then) 2019-10-15 10:47:49 Cogitri: i think we use triggers 2019-10-15 10:48:42 triggers="$pkgname.trigger=/usr/share/kernel/*" 2019-10-15 10:48:47 Yes, but can I somehow have the zfs trigger only he triggered if the Linux-* one wasn't? 2019-10-15 10:49:18 it will trigger if anything in /usr/share/kernel/* was updated 2019-10-15 10:50:03 Yup, but I don't want to regenerate the initramfs twice when both the kernel and zfs-* has been upgraded in the same transaction 2019-10-15 10:50:37 does it do so now? 2019-10-15 10:51:04 deffered trigger, like debian have 2019-10-15 10:51:37 ncopa: No, it doesn't do that, it just doesn't regenerate the initramfs if you install zfs-vanilla 2019-10-15 10:51:52 ok 2019-10-15 10:51:55 Meaning that you won't be able to boot if you install linux-vanilla first and then upgrade zfs-vanilla 2019-10-15 10:52:05 yeah 2019-10-15 10:52:49 I remember time when used debian in beginning that it creates initram few times during single 'apt-get install ....' 2019-10-15 10:53:28 so the current mkinitfs.trigger sript relies on the /usr/share/kernel/kernel.release 2019-10-15 10:53:50 after some time someone made deferred creation of initram 2019-10-15 10:54:19 mps: we already do deferred creation of initramfs 2019-10-15 10:54:33 the trigger will execute after all .apk are installed 2019-10-15 10:54:51 aha, so Cogitri don't have issue ;) 2019-10-15 10:55:14 the problem is that the trigger only monitors /usr/share/kernel/ 2019-10-15 10:55:30 So making both the kernel trigger and zfs (or other dkms module) trigger monitor /lib/kernel/* will do the trick? 2019-10-15 10:55:39 so if zfs-vanilla is updated, or installed it will not regenerate the mkinitfs 2019-10-15 10:55:42 yes 2019-10-15 10:55:52 (or rather just the kernel trigger, we wouldn't need a zfs one then( 2019-10-15 10:55:56 that should work 2019-10-15 10:56:11 Cogitri: yes, but i think we need refactor the trigger too 2019-10-15 10:56:44 the trigger should monitor /lib/kernel/*, to make it execute whenever 3rd party modules are installed 2019-10-15 10:56:49 Okie πŸ‘ 2019-10-15 10:57:00 Yes, that's what I tried to say here ^ 2019-10-15 10:57:09 but i think we need modify the triggerscript 2019-10-15 10:57:29 the trigger will only execute once, but with all the paths as arg 2019-10-15 10:58:54 currently we loop over the args and run mkinitfs for each arg 2019-10-15 10:59:09 so we'd run it twice 2019-10-15 10:59:31 Ah, okie 2019-10-15 10:59:41 and we need to fix the handling of removal 2019-10-15 11:01:05 _ikke_ : the agent2 in zabbix code is broken : it should not use golang's syscall lib directly if intends to support mutli-arch, it should use 'os' lib instead. I think I will rewrite uname_linux.go using 'os'. Do you want to let this stay in Alpine or push usptream ? 2019-10-15 11:01:24 <_ikke_> tmhoang: ideally upstream 2019-10-15 11:02:36 <_ikke_> Zabbix itself is mostly written in C, so it would not surprise me that the developers tend to use the lower level APIs 2019-10-15 11:02:38 I think I will send it to Alpine, and let Alpine developers upstream or not. 2019-10-15 11:02:47 <_ikke_> tmhoang: nod, I can handle that 2019-10-15 11:02:52 <_ikke_> but 2019-10-15 11:03:02 if using 'syscall' you have to guard in build time or #ifdef in .go code 2019-10-15 11:03:03 <_ikke_> Not sure if the patch is accepted 2019-10-15 11:03:23 <_ikke_> Zabbix does not have a huge track record of easily accepting patches 2019-10-15 11:03:27 ok 2019-10-15 11:03:28 lol 2019-10-15 11:04:32 <_ikke_> I can at least update the ticket to mention this 2019-10-15 11:05:21 hmm, hold on it semss using +build tag is possible to specifiy architecture at build time, so we can edit our APKBUILD - which is enough 2019-10-15 11:05:24 brb 2019-10-15 11:05:32 <_ikke_> tmhoang: oh ok 2019-10-15 11:52:28 <_ikke_> mps: I needed to enable the shared runners for Marian before the CI jobs start 2019-10-15 11:57:37 just wrote to him to forward our mail thread to alpine-devel ML, or to join us on IRC 2019-10-15 12:07:11 _ikke_: I was tempted to add you in Cc: field 2019-10-15 12:11:38 <_ikke_> Are there still issues? 2019-10-15 12:16:09 don't know, wrote to him if he have issues to write to ML or join us here 2019-10-15 12:16:42 <_ikke_> zk 2019-10-15 12:20:16 zk? 2019-10-15 12:20:56 <_ikke_> Ok 2019-10-15 12:43:48 tmhoang: Have you looked into Rust on s390x already? I would really like to bump librsvg but that'd remove lots of stuff from s390x (but that stuff might not be interesting anyway?) 2019-10-15 12:44:43 Cogitri: I have not sorry. 2019-10-15 12:45:28 it has many stuffs/deps which I don't understand. AFIK, libunwind support is there but there was something missing for llvm-libunwind 2019-10-15 12:46:18 _ikke_ : patch for zabbix would look like this : https://tpaste.us/jXE1 . I can't figure out a better way using. If using 'os' lib, it won't be able to get uname string./ 2019-10-15 12:46:52 Ah, okay. I guess I'll have to look into how much has to be displayed on s390x then if we were to bump librsv 2019-10-15 12:47:31 Cogitri: hey thanks 2019-10-15 12:51:22 :) 2019-10-15 12:53:47 So I guess the only notable would be Emacs? I don't see any of the other librsvg dependants being useful on a mainframe 2019-10-15 13:27:27 is thinks kind of linking correct? 2019-10-15 13:27:28 http://dpaste.com/0E8SM27 2019-10-15 13:28:01 why do I have this? 2019-10-15 13:28:01 pc:glib-2.0>=2.42.0 2019-10-15 13:28:01 pc:glib-2.0>=2.42.1 2019-10-15 13:28:36 apk search glib-dev : glib-dev-2.62.0-r0 2019-10-15 13:29:13 Cogitri: do you know if we can build rust without using llvm-libunwind ? 2019-10-15 13:31:30 We can use libgcc_s, yes 2019-10-15 13:31:47 so that the only way out for s390x as far as I can tell 2019-10-15 13:32:18 current there is no one at ibm is doing porting llvm-libunwind, and it would take time to do that ... 2019-10-15 13:32:47 I will try to look into libgcc_s 2019-10-15 13:33:52 Void Linux has a patch for it IIRC 2019-10-15 13:34:31 Cogitri: I heard bootstraping rust is quite different, was there a doc that you made ? cc mps because i remember he did some bootstrap 2019-10-15 13:36:06 Well, it's selfhosting 2019-10-15 13:38:48 So you'll need to either crosscompile to s390x musl from another musl arch (what I did for the other arches) or compile from s390x glibc (which upstream officially supports) to s390x musl 2019-10-15 13:41:04 Since we don't support crosscompiling and Void doesn't s390x (which is one of the few distros that supports cross compiling well IMHO) it'd be best to compile s390x glibc->musl 2019-10-15 13:42:12 that's the key point I see 2019-10-15 13:43:12 but hold on 2019-10-15 13:43:18 So yeah, getting the first tarball isn't fun 2019-10-15 13:44:12 "you'll need to either crosscompile to s390x musl from another musl arch (what I did for the other arches)" and "Since we don't support crosscompiling" are contracdictory 2019-10-15 13:44:38 I would really prefer to cross compile from x86 musl to s390x musl rather than putting glibc in here 2019-10-15 13:56:56 Well, if you can figure out crosscompiling on Alpine it should be possible 2019-10-15 13:57:49 ah I did cross compile Alpine s390x itself from Alpine x86 2-3 years ago, hopefully nothing much differ 2019-10-15 13:58:44 mps: how did you bootstrap rust on arms (did you ?) ? using glibc-rust-arm or using musl-rust-x86 ? 2019-10-15 14:02:24 tmhoang: I used adelie prebuilt tarballs 2019-10-15 14:02:45 ack, thanks 2019-10-15 14:35:24 is ti ok to apply patch from check() function? file which needs to be patched are generated during build 2019-10-15 14:35:43 wut? 2019-10-15 14:36:43 uh, file which need to be patched is not in upstream source but generated during build 2019-10-15 14:37:06 generated from what? 2019-10-15 14:37:46 from another file, but looking through it will require *time* 2019-10-15 14:38:23 sounds like you should patch that part not theresult 2019-10-15 14:38:55 well, tried and gave up after looking all the mess 2019-10-15 14:40:57 lots of project generated weird on-the-fly code, and try digging to the source is pita. i can feel you man mps 2019-10-15 14:41:43 tmhoang: thanks for understanding my pain 2019-10-15 14:41:52 hehe 2019-10-15 14:42:11 and I understand your ;) 2019-10-15 15:13:52 tmhoang: So I guess compiling s390x glibc -> s390x musl is your best bet for Rust, won't be that much fun though I guess :/ 2019-10-15 15:16:42 Cogitri: no, I think I would give musl-x86 a try before falling back to glibc-s390x 2019-10-15 15:17:04 I cannot guarantee to do it this month though ... 2019-10-15 15:20:33 Ah, sure, no hurry I suppose 2019-10-15 15:20:40 I'll just disable librsvg on s390x 2019-10-15 16:03:29 we should cache sudo tarball somewhere, upstream site is very slow 2019-10-15 16:03:58 cache it for CI and builders 2019-10-15 16:47:14 Crap, ccache is masking compiler errors 2019-10-15 17:04:27 ok, I managed somehow to make sudo latest CVE fix (upgrade) in !488 2019-10-15 17:05:20 it is hackish but couldn't come to anything better in reasonable time, and marked MR as WIP 2019-10-15 17:06:18 so please review, update, fix or throw away, whatever anyone find appropriate with this MR 2019-10-15 17:14:21 are we aware of some musl specific signals messing up gdb debugging and there's a quick and dirty patch available for that: https://github.com/shaharv/binutils-gdb/commit/0ca9c66889bdc9558622a92f96a86552fa701924.patch 2019-10-15 18:02:50 ewige blumenkraft 2019-10-15 18:03:00 ewrongchan 2019-10-15 18:05:48 happens to the best of us 2019-10-15 19:22:11 ah, here is even a gdb upstream bugreport about this gdb issue: https://sourceware.org/bugzilla/show_bug.cgi?id=23616 2019-10-15 19:24:19 qa3Txu0iak0F: afaik, musl tries to be posix as much as possible 2019-10-15 19:24:28 yah 2019-10-15 20:23:17 Cannot compile for powerpc64le-unknown-linux-musl with /usr/bin/rustc 2019-10-15 20:23:23 rust is available for ppc64le but doesn't seem to work 2019-10-15 20:24:49 <_ikke_> It doesn't seem to recognize alpines tripple / quadruple 2019-10-15 20:25:09 <_ikke_> Cogitri knows more about that 2019-10-15 20:29:55 ncopa: patch on ~alpine/devel for the linux-vanilla/ppc64le change I asked you about 2019-10-15 20:30:44 ddevault: try with 'export CARCH=native' 2019-10-15 20:31:05 this helped me on aarch64 to build firefox 2019-10-15 20:31:23 you seem to have read my mind on what I'm up to here :) 2019-10-15 20:32:32 where did you export that? in the APKBUILD's build() function? 2019-10-15 20:32:57 yes, in build() 2019-10-15 20:34:00 hm, no effect 2019-10-15 20:35:56 well, it worked for firefox but didn't for some simpler pkg's, zola for example 2019-10-15 20:36:58 the package in question is firefox 2019-10-15 20:37:12 I added export CARCH=native to the train of export statements in the build() 2019-10-15 20:38:37 hmm, I can post patch which worked for me 2019-10-15 20:39:23 please do 2019-10-15 20:40:05 here it is, http://tpaste.us/J6kE 2019-10-15 20:40:29 oh, this is firefox-esr 2019-10-15 20:40:36 I'll try with that 2019-10-15 20:40:39 it is from few months ago 2019-10-15 20:40:55 I was trying to build testing/firefox 2019-10-15 20:41:17 ah, didn't tried 2019-10-15 20:41:59 actually I did but someone posted ready made patch and I stopped to work on testing/firefox 2019-10-15 20:42:27 I'm speaking for aarch64 2019-10-15 20:46:30 no dice 2019-10-15 20:46:33 I'll wait for Cogitri's input 2019-10-15 20:46:43 I fucking hate triples, we shouldn't live in a world where they matter 2019-10-15 20:47:20 quartets 2019-10-15 20:47:47 and also I don't know why we have it 2019-10-15 21:02:49 I suspect, but cannot prove, that the problem is that rustc -V reports powerpc64le-unknown-linux-musl as the host arch 2019-10-15 21:02:59 and that the firefox arch fix patch swaps unknown for alpine 2019-10-15 21:04:05 did you looked at patch I posted, there is file which changes that 2019-10-15 21:04:25 diff, I mean 2019-10-15 21:04:26 oh, so it seems 2019-10-15 21:04:40 at a glance I thought your patch added that patch in the first place 2019-10-15 21:04:55 this part is important there 2019-10-15 21:05:08 aye 2019-10-15 21:05:33 ayy the build is going 2019-10-15 21:06:11 nice, hope it will finish 2019-10-15 21:11:28 I think that disabling the DRM AST driver, or at least making it blacklistable, will be helpful for getting my AMDGPU working better 2019-10-15 21:11:34 right now it's =y 2019-10-15 21:16:47 I'm going to assume that the level of interest in a ppc64be port is approximately zero 2019-10-15 21:22:12 error 2019-10-15 21:22:14 *sad trombone* 2019-10-15 21:22:28 the actual error message is somewhere in the past 5,000 lines of build output 2019-10-15 22:01:01 error is related to too-new rustc, the esrs are pinned to a rust version 2019-10-15 22:01:10 I'm making another approach at firefox nightly 2019-10-16 01:41:57 got firefox working ^^ 2019-10-16 01:42:07 nice 2019-10-16 04:20:18 ddevault: So I guess you've solved it on your own? :) 2019-10-16 06:42:09 ncopa: if you have time please review !488 2019-10-16 06:43:02 and, good morning to all 2019-10-16 07:24:30 morning 2019-10-16 07:58:40 morning 2019-10-16 07:59:09 mps: do you have details on the fix-sigsys-check.diff? 2019-10-16 07:59:20 good afternoon, ncopa 2019-10-16 07:59:21 what is the problem and how does the fix solve it 2019-10-16 08:00:49 ncopa: yesterday I talked about this on #alpine-linux with dalias 2019-10-16 08:03:12 https://dev.alpinelinux.org/irclogs/%23alpine-linux-2019-10.log, after 2019-10-15 13:05:25 2019-10-16 08:03:59 he confirmed my thinking about sudo wrong signal settings for test 2019-10-16 08:05:53 I tried different variants to fix this problem, and this one in MR is most optimal, imo (it will not need much tweaking/diff-ing in the source) 2019-10-16 08:21:36 reading the irc log 2019-10-16 08:21:41 scary reading... 2019-10-16 08:22:34 patched file is generated during build, and because that patch is applied in check() 2019-10-16 08:22:46 it doesn't exist before build 2019-10-16 08:23:28 and patching source which generate resulting file is cumbersome 2019-10-16 08:47:20 mps: we can use adelie's patch 2019-10-16 08:49:34 didn't looked there, heh 2019-10-16 08:49:58 do you have url 2019-10-16 08:58:23 https://code.foxkit.us/adelie/packages/blob/master/system/sudo 2019-10-16 09:01:04 found it already 2019-10-16 09:01:22 and tried to patch same file but got errors 2019-10-16 09:01:35 looking at it now it looks good 2019-10-16 09:01:48 at their patch, I mean 2019-10-16 09:03:37 even have aside patch for lib/util/siglist.in 2019-10-16 09:04:21 so, I'm ok with this patch from adelie, it is better than my final hack 2019-10-16 09:14:22 ncopa: so, should I update MR or ...? 2019-10-16 09:21:33 mps: i can handle it if you want 2019-10-16 09:24:20 np, however you like, bur anyway I started to building and testing 2019-10-16 09:27:41 do you have a patch ready? 2019-10-16 09:28:01 you can git format-patch --stdout -1 | tpaste here if you want 2019-10-16 09:29:23 yes, I made, but want to test it on other arches before updating MR, to check it again on our new and shiny CI 2019-10-16 09:29:38 ok 2019-10-16 09:32:04 except patch doesn't work :( 2019-10-16 09:33:25 'strsig_test: FAIL: str2sig(SIGSYS): -1 != 0' again with this SIGUNUSED.patch, and it applies cleanly 2019-10-16 09:37:56 found it APKBUILD need hack 2019-10-16 09:38:11 will update MR in a few minutes 2019-10-16 09:48:39 updated MR but https://www.sudo.ws is unreachable and CI failed because that 2019-10-16 09:49:35 how come there's ipkg variables in the apk source code? Does apk have support for ipkg packages as well as apk packages? 2019-10-16 09:50:06 <_ikke_> what are ipkg variables? 2019-10-16 09:50:31 for example p->pkg->ipkg 2019-10-16 09:51:05 there's a lot of things named ipkg in the source code 2019-10-16 09:52:03 <_ikke_> struct apk_installed_package *ipkg; 2019-10-16 09:52:12 <_ikke_> I guess it's short for installed package 2019-10-16 09:54:18 of course, thanks. I've worked with ipkg/opkg packages the last days so my vision has been quite focused 2019-10-16 10:14:23 can anybody with CI access debug why resolving "nonexistent.nonexistent" timeouts on aarch64 CI server, but correctly returns empty response on all other archs 2019-10-16 10:14:55 pr11868 fails because of this 2019-10-16 10:25:18 <_ikke_> kaey: Let me hceck 2019-10-16 10:25:46 <_ikke_> Oh, this is droneci 2019-10-16 16:26:17 looks like s390x CI doesn't work 2019-10-16 16:52:13 mps: what happened ? more details ? 2019-10-16 16:57:46 tmhoang: it status is pending for job https://gitlab.alpinelinux.org/mps/aports/-/jobs/5026, vim upgrade 2019-10-16 17:01:49 mps: some tests failed it seem, socket stuffs 2019-10-16 17:04:22 yes 2019-10-16 17:05:07 who can restart CI !498 2019-10-16 17:05:37 for* 2019-10-16 17:19:34 Cogitri: are you around? I have this error on aarch64 when tried to build both firefox's, community and testing from current aports, 'ERROR: Target C compiler target CPU (aarch64) does not match --target CPU (armv8l)' 2019-10-16 17:19:57 rust target for aarch64 is changed? 2019-10-16 17:22:10 Hm, it builds on the builders, doesn't it? 2019-10-16 17:22:30 <[[sroracle]]> anyone else having problems with the mailing lists sending copies twice? 2019-10-16 17:23:01 <[[sroracle]]> i got two from Jonas about zstd and two from Timothy about package query API 2019-10-16 17:23:12 Anyway, Rust on aarch64 still has the different triplet (aarch64-unknown-linux-musl vs aarch64-alpine-linux-musl), I haven't gotten around to fixing that yet sadly 2019-10-16 17:23:19 <[[sroracle]]> i can't easily check rn but i suspect they are identical in each case 2019-10-16 17:23:26 [[sroracle]]: got the zstd one twice too 2019-10-16 17:23:55 And it's not identical 2019-10-16 17:24:09 In the footer of the 2nd the link to ProtonMail is removed 2019-10-16 17:24:26 <[[sroracle]]> ah i see, just pebkac people then i guess 2019-10-16 17:26:07 also I received 'nearly duplicate' mails in last few days 2019-10-16 17:27:00 Cogitri: this time triplet are not problem but --target CPU 2019-10-16 17:27:46 --target is the triplet, at least for Rust 2019-10-16 17:27:50 It'd really be helpful if you provided a full log 2019-10-16 17:28:28 give me some time 2019-10-16 17:32:43 Cogitri: here it is http://tpaste.us/VaN8 2019-10-16 18:12:10 Cogitri: I see it passed on builders, don't waste your time on my post, please 2019-10-16 18:13:38 Ah, sure. Good that it works I guess 2019-10-16 18:13:53 If you do need help feel free to ping me again, just wasn't on laptop to look at it before :) 2019-10-16 18:14:22 it works fine, just upgraded from repo 2019-10-16 18:15:07 if I find time I will look will it compile on armv7, but not this week, short time 2019-10-16 18:16:20 Same 2019-10-16 19:32:08 how we handle custom licences in pkgs? add it in to apk in package() ? 2019-10-16 19:33:22 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license 2019-10-16 19:35:42 maxice8: yes, I read it earlier, but I see a lot of pkgs with 'custom' license and don't see installed files with these custom licenses 2019-10-16 19:36:10 They are wrong 2019-10-16 19:37:40 agree, but have to give advice to new developer about that. Ok, I will post url you just wrote above 2019-10-16 19:39:57 PureTryOut: looking at the logs of !469 almost half of the packages failed 2019-10-16 20:02:51 ncopa: Is there a plan to make a new mkinitfs release before 3.11? 2019-10-16 20:09:06 We normally do releases of sub projects before the aports tag 2019-10-16 20:19:24 Nice, thanks for the info 2019-10-16 21:08:02 maxice8: oh I just assumed it failed because taking longer than an hour lol, as it compiled fine locally. I'll look into it 2019-10-16 22:44:49 \o/ i just got qt5-qtwebengine running \o/ i binary patched /usr/lib/libQt5WebEngineCore.so.5 at address to contain "xor rax,rax; nop; nop" instead of a call to `metric->GetMallocUsage();` which is being invoked at src/3rdparty/chromium/content/renderer/render_thread_impl.cc:1828 2019-10-16 22:45:27 now doing a rebuild of the apk with the line simply setting the value there to zero. 2019-10-16 22:48:59 at least it works for the qt.io page 2019-10-16 22:49:14 duckduckgo still crashes 2019-10-16 22:51:21 oh, i just overwrote my binary patch. that might explain the duckduckgo problem 2019-10-16 22:52:19 \o/ qutebrowser also works! also for duckduckgo 2019-10-16 22:54:27 that seems like the kinda thing you wouldn't want to patch out... 2019-10-16 22:55:54 totally 2019-10-16 22:56:04 it is hardcoded to 0 on fuchsia 2019-10-16 22:57:54 also on macos and ios 2019-10-16 22:58:15 for reference: src/3rdparty/chromium/base/process/process_metrics_posix.cc 2019-10-16 22:58:25 for reference: src/3rdparty/chromium/base/process/process_metrics_posix.cc:98 2019-10-16 22:59:07 musl doesnt implement mallinfo() since it is braindead and broken. 2019-10-16 23:00:16 oh yeah the address i patched in the lib was 0x4793e89 in case anyone wants to try it out. originally it contained this: e8 a4 69 01 fc callq 7aa832 2019-10-16 23:02:17 https://github.com/qt/qtwebengine-chromium/blob/feccbb4ea7fa685dcd013f5a3f6c14ea768636c9/chromium/base/process/process_metrics_posix.cc#L98 2019-10-16 23:03:08 oh. on macos/ios it is actually doing something. 2019-10-16 23:03:10 my bad. 2019-10-16 23:10:05 aah. there is actually a patch in the aports directory: qt-musl-mallinfo.patch, which adds a glibc check, but then this function does not return anything and thus it is UB and the compiler correctly compiles this to ud2 2019-10-16 23:17:49 btw qutebrowser could be bumped up to 1.8.1 it is quite old and still in testing... 2019-10-16 23:20:43 qa3Txu0iak0F: Yes,i made a MR to update it to 1.8.1 but the maintainer doesn't want to update while it is still broken 2019-10-16 23:20:48 so i guess if you make it work then feel free to update just tag @ddevault for his approval 2019-10-16 23:21:00 Cogitri: Thanks for the merge. 2019-10-16 23:21:22 it works 2019-10-16 23:22:03 if you got qute working on musl you will be a great friend of mine 2019-10-16 23:22:09 i just did 2019-10-16 23:22:10 :) 2019-10-16 23:22:12 nice 2019-10-16 23:22:21 tag me on the patches and I'll test and approve em 2019-10-16 23:22:29 currently suffering through firefox 2019-10-16 23:22:38 you can immediately test it with just patching 5 bytes in /usr/lib/libQt5WebEngineCore.so.5 2019-10-16 23:22:46 though on ppc64le I imagine it's likely that I'll run into additional issues with qt/webengine 2019-10-16 23:22:53 possibly 2019-10-16 23:22:57 haha, hot patching binary files is not how I test things 2019-10-16 23:23:22 qt5-qtwebengine is quite a bitch to build. takes a few hours. 2019-10-16 23:23:27 I'm well aware 2019-10-16 23:23:37 doing a rebuild now, all my cores are running hot. 2019-10-16 23:25:21 void people are also interested in this according to some of their github issues 2019-10-16 23:25:40 yes 2019-10-16 23:26:56 no one was especially excited about debugging the deep problems of a 25-million LoC C++ codebase 2019-10-16 23:27:30 well, i enjoy these challenges, i ported emacs to musl/alpine back then, and before that zfs to musl/grsec... ;) 2019-10-16 23:29:25 and it was quite easy after having a minimalist code that uses qtwebengine without any cruft around it. 2019-10-16 23:30:15 investigating the crash and the backtrace was mostly a hassle, because there's like 3 forks and one exec before gdb is in the right context. 2019-10-17 09:05:53 Hey, could someone please check why algitbot doesn't work for J0WI? I always have to close them manually like here: https://github.com/alpinelinux/aports/pull/11899 :c 2019-10-17 09:20:36 Cogitri: its a known issue, but no-one cared enough to debug it 2019-10-17 09:22:11 Ah, okie. Do we have an issue tracker for that somewhere? How can I help with that? 2019-10-17 09:23:03 <_ikke_> Cogitri: We're migrating to gitlab, not sure if it's worth to fix it if it's isolated to github 2019-10-17 09:23:59 Fair enough 2019-10-17 09:24:08 Thought we'd use algitbot on Gitlab too 2019-10-17 09:25:35 Aaaalso, I'm currently bumping librsvg to 2.46.2 which needs Rust, so we'll either gave to move librsvg (the only package affected would be graphviz, but that pulls quite the rattail with it) to community from main or move Rust to main 2019-10-17 09:25:41 this is the code: https://github.com/jirutka/github-pr-closer 2019-10-17 09:26:39 how long does rust support each version? 2019-10-17 09:26:47 <_ikke_> Doesn't seem that long 2019-10-17 09:26:52 i dont think they support it for much time 2019-10-17 09:26:54 <_ikke_> nope 2019-10-17 09:27:24 which means we need to cut support time for librsvg as well 2019-10-17 09:31:04 They support it for 6 weeks 2019-10-17 09:31:04 So not really main/ ready 2019-10-17 09:31:44 Okie, I'll start moving things to community/ then 2019-10-17 09:34:23 it means we cannot support imagemagick, vala or wayland 2019-10-17 09:35:01 which means we cannot support vte3, which means we cannot support qemu 2019-10-17 09:36:17 seems liek libvirt can be built without qemu? 2019-10-17 09:36:32 i just wonder if dropping longterm support for qemu is acceptable 2019-10-17 09:36:56 Cogitri: can you please create a full list of all packages that needs to moev? 2019-10-17 09:37:00 move? 2019-10-17 09:37:50 We can build vala without librsvg 2019-10-17 09:37:58 ok 2019-10-17 09:38:03 Cogitri meant to say: We can build vala without graphviz 2019-10-17 09:38:03 s/librsvg/graphviz/ 2019-10-17 09:38:22 lets do that then 2019-10-17 09:38:29 So that isn't much of a problem, but the wayland thingie is annoying since we'd have to move xorg-server and all that stuff into community then AFAICS 2019-10-17 09:38:52 But maybe we can build that without graphviz too 2019-10-17 09:39:15 Nice, it's only required for the docs 2019-10-17 09:39:44 So we only have to move librsvg, graphviz and geeqie 2019-10-17 09:40:05 thats doable 2019-10-17 09:40:16 Yup 2019-10-17 09:51:05 i am considering disable the python optimizations again 2019-10-17 09:51:19 intriduced with df3979dba3df1fbdf3e91a06462ee1d91c39dcff 2019-10-17 09:51:36 because it makes various builders hang 2019-10-17 09:51:46 <_ikke_> s/various/all 2019-10-17 09:52:01 link time optimization? 2019-10-17 09:52:11 i think its pgo 2019-10-17 09:52:18 profile guided optimization 2019-10-17 09:52:35 im 90% that the pgo is the problem 2019-10-17 09:52:50 aha, if it fails to build then do, imo 2019-10-17 09:53:05 <_ikke_> It hangs, if will kill the test, it continues 2019-10-17 09:53:13 it will make python slower though 2019-10-17 09:53:17 not sure with how much 2019-10-17 09:53:54 iirc, it is slow already in previous releases 2019-10-17 09:54:45 could that be solved by giving more time to builders 2019-10-17 09:54:49 <_ikke_> no 2019-10-17 09:54:51 <_ikke_> it just hangs 2019-10-17 09:54:53 <_ikke_> deadlock 2019-10-17 09:54:56 this is what hangs: 2019-10-17 09:54:59 <_ikke_> the builders don't have a timeout 2019-10-17 09:54:59 LD_LIBRARY_PATH=/home/ncopa/aports/main/python3/src/Python-3.7.5 ./python -m test.regrtest --pgo || true 2019-10-17 09:55:00 Run tests sequentially 2019-10-17 09:55:10 note the --pgo 2019-10-17 09:55:18 <_ikke_> Yes, that's what I saw as well 2019-10-17 09:55:31 imo, disable is solution 2019-10-17 09:55:34 it is during build() `make`, not during check() 2019-10-17 09:55:50 disable it is the quick solution 2019-10-17 09:56:04 we can also find the exact test and remove them 2019-10-17 09:56:15 or even better, we fix them, so they dont hang 2019-10-17 09:56:23 but the problem is that we dont have resources 2019-10-17 09:56:51 <_ikke_> ncopa: python -c from multiprocessing.semaphore_tracker import main;main(9) 2019-10-17 09:56:52 <_ikke_> python -c from multiprocessing.forkserver import main; main(14, 15, ['__main__'], **{'sys_path': [..] 2019-10-17 09:56:59 <_ikke_> That was what's hanging 2019-10-17 09:57:01 so i am considering disable the optimization, and let the first one to complain to fix it :) 2019-10-17 09:57:09 is the problem specific to alpine (or musl) 2019-10-17 09:57:19 dont know 2019-10-17 09:57:53 <_ikke_> ncopa: problem is that people might blame Alpine when they notice python is running slower 2019-10-17 09:58:02 yes 2019-10-17 09:58:24 they already do 2019-10-17 09:58:29 <_ikke_> Yup 2019-10-17 09:58:30 yes, but we can put wiki about that 2019-10-17 09:58:36 <_ikke_> people don't read those 2019-10-17 09:58:40 https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image 2019-10-17 09:59:27 release note? ah, I know people don't read release notes (or anything) 2019-10-17 10:00:22 but if it hangs on build then there is no option than to disable pgo, till someone find fix 2019-10-17 10:00:29 <_ikke_> https://www.phoronix.com/scan.php?page=article&item=docker-os-tests&num=1 2019-10-17 10:03:27 the pgo was enabled in aug, so it is not included in any release 2019-10-17 10:05:51 https://github.com/docker-library/python/issues/160 2019-10-17 10:06:02 some details 2019-10-17 10:07:34 ACTION decided long time ago to not touch any python code 2019-10-17 10:12:58 this is interesting: https://github.com/docker-library/python/issues/160#issuecomment-509426916 2019-10-17 10:13:16 which was in the direction i wsa thinking 2019-10-17 10:20:21 and it seems like they have fixed it upstream: https://github.com/python/cpython/commit/2406672984e4c1b18629e615edad52928a72ffcc 2019-10-17 10:23:25 i'll backport that 2019-10-17 10:24:07 πŸ‘ 2019-10-17 11:10:33 mps: did MR437 solve itself after yesterday ? I thought it has hanging tests, or maybe the CI is just slow ? 2019-10-17 11:13:10 <_ikke_> !437 2019-10-17 11:13:18 <_ikke_> tmhoang: It build too much 2019-10-17 11:13:21 <_ikke_> built* 2019-10-17 11:13:24 <_ikke_> I fixed that 2019-10-17 11:14:04 ah it's about gitlab, not runner 2019-10-17 11:14:50 <_ikke_> gitlab uses shallow clones by default 2019-10-17 11:15:05 <_ikke_> if your branch is too much behind, git cannot properly compute the changed packages 2019-10-17 11:15:22 _ikke_: I see, how did you fixed it? I thought to use 'git push --force mps' to this branch to restart it 2019-10-17 11:15:44 <_ikke_> mps: in your CI/CD settings I changed fetch to clone and set shallow 0 2019-10-17 11:15:46 <_ikke_> to 0 2019-10-17 11:17:59 <_ikke_> I want to make something that adjusts this automatically when someone forks aports 2019-10-17 11:19:00 too much for my understand how gitlab works, but I trust you fully 2019-10-17 11:19:11 <_ikke_> I set it too fetch now instead of clone, I feel that that should work as well 2019-10-17 11:19:40 <_ikke_> mps: To give a bit of a background: In order to know what packages to build, we need to look at the changed files between the merge request branch and the target branch 2019-10-17 11:19:44 <_ikke_> this is just plain git things 2019-10-17 11:19:48 understanding* 2019-10-17 11:47:47 ncopa: !509 2019-10-17 11:48:14 Still WIP, I'm pretty sure that I've missed some reverse deps which I should disable too and I haven't had time to test it much yet 2019-10-17 12:52:13 <_ikke_> ncopa: ah, you found a patch for the python pgo issue? 2019-10-17 12:53:03 <_ikke_> nice 2019-10-17 12:54:53 Uhh..I think (at least) the edge x86_64 are inconsistent 2019-10-17 12:55:40 Apparently I can't upgrade because libreoffice-draw is on 6.3.2.2-r0 while the other libreoffice-* stuff is on 6.3.2.2-r1 (rebuild for poppler( 2019-10-17 12:56:31 But they're all in the same package πŸ€” 2019-10-17 13:02:17 <_ikke_> master.a.o has libreoffice-draw 6.3.2.2-r1 2019-10-17 13:04:10 Huh 2019-10-17 13:04:19 Maybe it's some CDN oddness then 2019-10-17 13:04:34 Thanks for checking 2019-10-17 13:04:41 <_ikke_> dl-cdn as well 2019-10-17 13:06:32 _ikke_: i did 2019-10-17 13:13:44 Seems to work now, huh 2019-10-17 13:13:47 Oh well, good that it works again I suppose 2019-10-17 13:40:36 python 3.8 was released 2019-10-17 13:40:43 we should have that for alpine 3.11 i guess 2019-10-17 13:41:15 does anyone know or have heard of any problems with upgrading to python 3.8? 2019-10-17 13:44:32 Exherbo recently upgraded to it, apparently lots of packages have failing tests 2019-10-17 13:44:41 Lemme get the numbers 2019-10-17 13:46:26 15/180 packages failed for one of the devs (although some of those failures might be due to pytest5 and not py3.8) 2019-10-17 13:49:39 Not as bad as with py3.7 I guess 2019-10-17 13:49:53 Aaanyway, we have quite the backlog of PRs and MRs for packages belonging to main/, soooo 2019-10-17 13:50:31 i have merged a bunch today 2019-10-17 13:50:57 problem is that PR creators spend 5 mins on creating a (broken) PR, move on to next 2019-10-17 13:51:04 and i spend a half day to fix it 2019-10-17 13:51:38 :c 2019-10-17 13:52:01 I'll try looking at main/ stuff too and labeling it if it's fine 2019-10-17 13:52:11 woudl be great 2019-10-17 13:52:27 i like the green s-ready label 2019-10-17 13:52:48 which tells me that someone else has had a look at it and that it will not break stuff 2019-10-17 13:53:05 Okie πŸ‘ 2019-10-17 13:53:08 i also need to ge the 3.10.3 release out 2019-10-17 13:53:12 and get the 3.11 builders up 2019-10-17 13:53:24 but i'd like to have python 3.8 done before i start up the 3.11 builders 2019-10-17 13:54:21 oh, i need to tag a new abuild release too 2019-10-17 13:54:21 One thing: It'd be really nice if you could maybe take a look at pr11783 and pr11784 first since those contain pretty important fixes 2019-10-17 13:54:37 they look trivial 2019-10-17 13:55:05 (without those any program crashes on GTK Wayland if you use a stylus which is pretty bad) 2019-10-17 13:55:09 They are, yes 2019-10-17 13:55:15 A new mkinitfs release would be good too :) 2019-10-17 13:55:54 yeah, i was hinking of doing that while 3.11 builders are running 2019-10-17 13:56:14 there was 2 conflicting PRs for dealing with multi encrypted devices 2019-10-17 13:56:14 Ah, okie 2019-10-17 13:57:21 i think the multi device cryptroot may need some more work 2019-10-17 13:57:47 Ah yes, don't know anything about cryptsetup so didn't look at those 2019-10-17 13:58:04 Cogitri: do you have any other high prio PR you want me to look at? 2019-10-17 13:58:06 Also, maybe while you're at it: pr11907 and pr11855 & pr11541 are pretty trivial too πŸ˜… 2019-10-17 13:58:53 After that the only thing I definitely want to get into 3.11 is the librsvg thingie but that'll need a bit more work 2019-10-17 13:59:05 And I'll have to come up with some sane way to handle Rust in stable releases, right now we just let it rot 2019-10-17 13:59:27 speaking of rust 2019-10-17 13:59:39 i think some of our arches have "wrong" triplet for rust 2019-10-17 14:00:33 Yes, everything but x86_64 has a wrong triplet for now 2019-10-17 14:00:55 Well, wrong as in it doesn't use the -alpine one but -unknown-linux-musl 2019-10-17 14:01:10 we shoudl be consequent 2019-10-17 14:01:34 either all should use $arch-unknown-linux-musl or $arch-alpine-linux-musl 2019-10-17 14:01:51 For some reason neither the Rust devs nor me could come up with it fails to build against our triplets for those arches (even when the triplets are exact copies of each other than the name) 2019-10-17 14:01:58 Yes, I totally agree Rust should use -alpine 2019-10-17 14:02:10 do we have a ticket for it? 2019-10-17 14:02:15 But it's not quite there yet 2019-10-17 14:02:44 No, I have one at Rust upstream 2019-10-17 14:02:50 But opening one in our Gitlab wouldn't be a bad idea, I suppose 2019-10-17 14:03:03 with link to upstream ticket 2019-10-17 14:03:07 yeah 2019-10-17 14:03:55 heh, glibmm conflicts with 3d0d8fa701d2b470ebc6b37a2fffb30003cd35ef 2019-10-17 14:04:46 Ah, I guess someone was quicker then :P 2019-10-17 14:04:50 Thanks for the info 2019-10-17 14:04:59 im rebasing it 2019-10-17 14:05:07 i guess it happens with we use both github and gitlab 2019-10-17 14:07:14 I guess so, yes 2019-10-17 14:07:39 ncopa: if you preparing 3.10 release, please look at this !472 2019-10-17 14:08:22 this fixes one bug report, forgot which one 2019-10-17 14:09:22 mps: i set the milestone for it 2019-10-17 14:09:30 will have a look at it in a bit 2019-10-17 14:10:31 and, we need probably backport latest sudo CVE, not sure completely backport latest version on make patch for current version in 3.10 (and previous) 2019-10-17 14:11:09 I will not have much time today for this to look at this 2019-10-17 14:11:45 Ah yes, a milestone sounds like a good idea 2019-10-17 14:12:29 yes, I see it right now 2019-10-17 14:24:46 mps: is openresolv currently broken in 3.10? 2019-10-17 14:25:09 i think moving libexecdir in a stable branch is risky 2019-10-17 14:25:24 people may have updated their scripts with the path to /usr/lib/ 2019-10-17 14:25:36 or config 2019-10-17 14:25:38 it is broken 2019-10-17 14:26:05 let me find bug report 2019-10-17 14:28:16 hmm, can't find 2019-10-17 14:29:48 probably reported only on IRC (#alpine-linux iirc) 2019-10-17 14:30:27 I'll do this in addition: http://tpaste.us/zBRv 2019-10-17 14:30:35 will look later, too busy now 2019-10-17 14:31:51 but it worked for me on stable when I detected this bug 2019-10-17 14:32:19 and, I also backported it to my stable workstation 2019-10-17 14:32:27 works well 2019-10-17 14:47:34 openresolv bug is reported on #alpine-linux by ahills at 2019-10-14 23:43 2019-10-17 14:49:02 would be good to have that kind of reports in gitlab issue tracker 2019-10-17 14:52:01 agree, but not all users wants to go through canonical path 2019-10-17 14:52:36 <_ikke_> We could always report the issue for them 2019-10-17 14:53:42 yes, but we can't always reproduce bugs as original reporter can 2019-10-17 14:55:45 ncopa: current openresolv configuration using /usr/lib seems really dangerous to me as it executes *everything* in that directory 2019-10-17 14:56:07 not sure what alpine releng standards are but I would much rather get the fix on the stable branch than continue in the current state 2019-10-17 14:57:47 I don't mind adding bugs to the tracker; I was just following directions in IRC 2019-10-17 14:58:16 <_ikke_> gitlab.a.o under aports 2019-10-17 14:59:38 ahills: true, I fixed it myself few months ago on stable and backported current upstream, and it works good 2019-10-17 15:00:09 will reporting this as a bug in that channel cause 3.10 to get this update? :) 2019-10-17 15:00:53 (and I don't understand why we are so conservative for backporting pkg's which fixes their working) 2019-10-17 15:01:18 ahills: it is alredy pushed few minutes ago 2019-10-17 15:02:32 and I'm not sure if ncopa's symlinks is ok 2019-10-17 15:02:44 but don't have time to test it 2019-10-17 15:02:53 it can't be worse than what we have now 2019-10-17 15:03:11 whenever a build is ready I'll test it immediately 2019-10-17 15:04:23 it pushed at 16:31, so it is probably at the mirrors 2019-10-17 15:06:01 so it is, thanks 2019-10-17 15:06:57 ahills: please report if it works now 2019-10-17 15:10:27 mps: i didnt check if there are any references to /usr/lib/$prog in any config scripts, and I dont know if there may be any reference to that path from any user scripts 2019-10-17 15:10:38 if it does, and we move the location, those configs and scripts will break 2019-10-17 15:10:42 which is ok in edge 2019-10-17 15:10:47 but not ok in stable branch 2019-10-17 15:11:44 the symlinks may not be needed if it is very unlikely that there are any references to that path 2019-10-17 15:11:53 but i didnt take the time to investigate 2019-10-17 15:12:13 mps: confirmed working, I don't integrate with the libexec dir but the core resolvconf script works fine 2019-10-17 15:12:16 I checked all that few months ago, I'm 95% sure it will not break anything 2019-10-17 15:13:23 maxice8: my KDE Frameworks MR (!469) is ready. CI now just fails because of the 1h timeout 2019-10-17 15:13:45 the symlinks don't seem to interfere with dnsmasq which doesn't use /usr/lib, can't speak to the other references in the provided libexec scripts 2019-10-17 15:14:28 PureTryOut: merged 2019-10-17 15:14:29 <_ikke_> PureTryOut[m]: Would a slightly longer timeout help, or is it still going to take longer? 2019-10-17 15:14:31 ok, I will try to find some time tomorrow to check that 2019-10-17 15:14:31 <_ikke_> ah ok 2019-10-17 15:14:40 ncopa: is the filesystem "API" something that is guaranteed to be stable within a release? 2019-10-17 15:14:54 Thanks! 2019-10-17 15:15:13 _ikke_: I'm not sure how long it takes tbh. We can just try some values 2019-10-17 15:15:22 This is just KDE Frameworks, KDE Applications would take way longer 2019-10-17 15:16:40 Hopefully no other errors appear in packages that would compile after the timeout, locally everything built fine. I'm online for quite a few hours anyway, I'll send fixes if anything new is found. 2019-10-17 15:18:43 ncopa: looking again to your patch at http://tpaste.us/zBRv , makes sense 2019-10-17 15:19:04 ahills: not sure if we guarantee filesystem API stability, but we want avoid breakages 2019-10-17 15:19:05 I will test it tomorrow 2019-10-17 15:19:33 people should be able to do `apk upgrade` in stable branches and nothing should break 2019-10-17 15:19:43 ok 2019-10-17 15:19:52 i guess we could have dropped the symlinks in this case 2019-10-17 15:20:01 and in edge we definitively drop them 2019-10-17 15:20:25 i already pushed the symlinks 2019-10-17 15:20:29 I think avoiding breakage within a release is a great principle 2019-10-17 15:20:44 thats kind of the point with stable branches 2019-10-17 15:21:12 <_ikke_> PureTryOut[m]: I did increase the timeout a bit for your fork 2019-10-17 15:21:18 yeah, and I guess it means I can stop inspecting every package when I update my laptop and only go through that during an upgrade 2019-10-17 15:21:51 thats the idea yes 2019-10-17 15:21:54 Thanks, so any MR I make has that higher timeout? 2019-10-17 15:22:22 I'd be nice if at least KDE Frameworks would pass 2019-10-17 15:22:32 And hopefully Plasma too, but KDE Applications just takes too long 2019-10-17 15:23:02 when we are talking about breakage, next 3.10 need to add info about split of clamav-libunrar in release notes 2019-10-17 15:23:15 Awesome 2019-10-17 15:23:36 I think maxice8 have wiki page about release notes 2019-10-17 15:23:50 Btw when is the 3.11 split going to happen? I'd like at least Plasma 5.17 in before that 2019-10-17 15:23:52 <_ikke_> PureTryOut[m]: yes. Ideally we would be able to split things up in multiple jobs. The problem is that the ci description is static 2019-10-17 15:24:33 mps: yes 2019-10-17 15:24:34 <_ikke_> Just right before the stable release is done 2019-10-17 15:24:34 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas) 2019-10-17 15:25:31 maxice8: ah, yes, but something similar will be good for stable upgrades 2019-10-17 15:26:58 😱 DXVK has been packaged, awesome 2019-10-17 15:26:59 for 3.11 freeze, I think it should wait for kernel 5.4 2019-10-17 15:27:47 i don't follow stable branches that much 2019-10-17 15:28:00 someone else will have to do it 2019-10-17 15:28:41 <_ikke_> usually ncopa arranges those when making a new release of a stable branch 2019-10-17 15:28:46 Ah yes new kernel please. Then I can try to get 3.11 running on the Pine A64LTS devices 2019-10-17 15:28:47 could we make wiki about releases on gitlab 2019-10-17 15:29:27 <_ikke_> We haven't used gitlab wiki as of yet, and I think we want to avoid to introduce another place where documentation can live 2019-10-17 15:30:58 (would be nice, because then I can contribute to docs using markdown syntax) 2019-10-17 15:43:51 Hmm there is a build failure, but the build log gives 404 2019-10-17 15:44:33 <_ikke_> Not sure when the build logs are uploaded 2019-10-17 15:44:49 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/kdeclarative/kdeclarative-5.63.0-r0.log ? 2019-10-17 15:50:18 I was talking about kio, https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/kio/kio-5.63.0-r0.log 2019-10-17 15:51:41 <_ikke_> It see it on the builder, so somehow it's not synchronized yet 2019-10-17 15:52:59 <_ikke_> PureTryOut[m]: https://tpaste.us/Xn5j 2019-10-17 15:53:23 <_ikke_> curl: (7) Failed to connect to piotrkosoft.net port 80: Connection refused 2019-10-17 15:53:26 Thanks! 2019-10-17 15:53:46 Ah that just needs a retry 2019-10-17 15:54:27 <_ikke_> I still get a connection refused if I try it from that builder 2019-10-17 15:54:31 <_ikke_> (just contacting the domain) 2019-10-17 15:54:44 <_ikke_> I think the site is down 2019-10-17 15:54:55 <_ikke_> hmm 2019-10-17 15:55:08 It shouldn't need to contact that domain, guess it's a fallback from abuild 2019-10-17 15:55:29 <_ikke_> a fallback how? 2019-10-17 15:56:18 Oh sorry, probably a redirect from KDE 2019-10-17 15:56:24 Just try the build again, https://download.kde.org/stable/frameworks/5.63/kio-5.63.0.tar.xz will probably redirect to something else this time 2019-10-17 15:57:21 <_ikke_> http://www.mirrorservice.org/sites/download.kde.org/stable/frameworks/5.63/kio-5.63.0.tar.xz 2019-10-17 16:02:19 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/519 fixes the kdeclarative build failure 2019-10-17 16:03:02 Also, what's wrong the Gitlab CI linter? https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/5267 2019-10-17 16:03:03 Fails to connect to Docker 2019-10-17 16:03:08 I keep retrying but it just keeps happening 2019-10-17 16:03:46 <_ikke_> Hmm, strange, we saw that earlier as well, no clue why that's happening. Let me check 2019-10-17 16:07:06 <_ikke_> No, that was a different issue 2019-10-17 16:07:52 <_ikke_> PureTryOut[m]: fixed, I configured that runner incorrectly 2019-10-17 16:08:49 Ah thanks! 2019-10-17 16:13:46 So the linter currently doesn't like `() AND `, as it tries to parse the round brackets as well. Could that be changed? 2019-10-17 16:14:18 `( OR ` would be a better example 2019-10-17 16:15:41 <_ikke_> PureTryOut[m]: It's abuild that checks this 2019-10-17 16:16:10 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n896 2019-10-17 16:23:46 Can I just add those brackets to the exclude list then? 2019-10-17 16:23:47 Seems simple enough 2019-10-17 16:29:15 ddevault: https://github.com/alpinelinux/aports/pull/11922 2019-10-17 16:29:39 qa3Txu0iak0F: nice 2019-10-17 16:35:17 Very nice 2019-10-17 16:35:55 I'd even say, "Holy shit nice" 2019-10-17 17:08:35 hmm, !508 tried on armv7 ci although it is not enabled in arch field 2019-10-17 17:10:05 handbrake needs to be rebuilt 2019-10-17 17:10:33 ddevault: Handbrake is broken for a long time ever since Harfbuzz was updated long ago 2019-10-17 17:10:39 ack 2019-10-17 17:15:12 <_ikke_> mps: hmm, strange, normally abuild should not built it 2019-10-17 17:15:16 appetizer: https://www.ctrlc.hu/~stef/qutebrowser.png 2019-10-17 17:16:15 [379/15670] on my machine over here 2019-10-17 17:21:41 meh. travis-ci > The job exceeded the maximum time limit for jobs, and has been terminated. 2019-10-17 17:27:34 Yup, I doubt CI will be able to handle it 2019-10-17 18:15:03 drone ci is happy. 2019-10-17 18:16:11 Neat 2019-10-17 18:16:32 Will test with MellowPlayer tomorrow and merge it then if no one beats me to it 2019-10-17 18:56:57 seems like 3.10 arm builders hangs on python build 2019-10-17 19:04:54 <_ikke_> with pgo limited? 2019-10-17 19:12:47 yes, problem happens during make check 2019-10-17 20:03:18 oh, another go cve 2019-10-17 20:12:15 has anyone messed with compressed kernel modules? I'm having some trouble with mkinitfs, wondering if fixes would be welcome or if compressed modules is just considered a nono 2019-10-17 20:14:01 ... why do you want to compress kernel modules? 2019-10-17 20:14:29 asking for the usecase 2019-10-17 20:14:54 size? 2019-10-17 20:15:19 when they are stored where? 2019-10-17 20:15:33 the initramfs is already gzipped 2019-10-17 20:15:36 xz compressed modules are about 1/3rd the size of uncompressed 2019-10-17 20:15:57 rootfs (we have small drives) 2019-10-17 20:17:45 have you done any boot time tests when booting on low powered hw? 2019-10-17 20:21:44 no 2019-10-17 20:22:31 It would be nice if we could find out what the impact is. size vs delay. 2019-10-17 20:23:30 to be clear, I'm not pushing this for linux-vanilla, just trying to make life easier for people not running linux-vanilla 2019-10-17 20:24:14 if it is optin it would be ok, optout we would need some more infol. 2019-10-17 20:27:21 arch linux alarm (arch for arm) use have compressed modules 2019-10-17 20:27:39 for sure, I'm not sure it makes sense for a lot of use cases, I've just got a weird setup 2019-10-17 20:28:56 in 'weird setup' it is better to build kernel with minimum needed modules and options enabled in kernel 2019-10-17 20:29:16 I do that for some use cases 2019-10-17 20:35:23 fwiw go is failing on s390c 2019-10-17 21:40:39 hrmpf, wxgtk has been upgraded from 3.0.4 stable to 3.1.2 which is a backward incompat devel version. 2019-10-17 21:42:08 ncopa you merged this. what was the reason for this? can we stick with stable versions please? 2019-10-17 22:54:27 oh.. 2019-10-17 22:54:31 thats bad 2019-10-17 22:54:35 shouldnt have merged that 2019-10-17 23:01:55 i thikn we need revert to wxgtk 3.0 2019-10-17 23:10:10 shall i do this in my PR? 2019-10-17 23:10:38 is it ok if i fix the pkgconf include dir and revert back to 3.0.4? 2019-10-18 05:32:06 I think 3.1 has a compat mode for 3.0, no? 2019-10-18 09:11:59 <_ikke_> Apparently there has been found a serious buffer overflow in the realtek wifi driver for linux 2019-10-18 09:12:39 <_ikke_> https://lkml.org/lkml/2019/10/16/1226 2019-10-18 09:12:42 <_ikke_> https://nvd.nist.gov/vuln/detail/CVE-2019-17666 2019-10-18 09:23:32 is fix included in 4.19.80? 2019-10-18 09:23:40 im working on kernel update 2019-10-18 09:27:16 <_ikke_> The patch was sent 2 days ago 2019-10-18 09:27:46 looks like it fixed in latest kernels releases 2019-10-18 09:29:58 hmm, not sure 2019-10-18 09:30:52 need to look deeply 2019-10-18 09:36:39 re kernel config 2019-10-18 09:36:57 this is a request for rumble support to dualshock 4: https://gitlab.alpinelinux.org/alpine/aports/issues/10873 2019-10-18 09:37:07 what arches does it make sense to add it to? 2019-10-18 09:37:12 x86_64 and x86 only? 2019-10-18 09:37:28 arm* and aarch64? 2019-10-18 09:38:00 i'd guess that no-one uses it with s390x 2019-10-18 09:38:59 it is this game controller: https://www.playstation.com/en-us/explore/accessories/gaming-controllers/dualshock-4/ 2019-10-18 09:40:20 tmhoang: ^ 2019-10-18 09:40:25 Do we have a Gitlab MR or smth for the government document, ncopa? 2019-10-18 09:41:04 i dont think so 2019-10-18 09:41:19 not sure in what gitlab project it should be 2019-10-18 09:41:21 docs? 2019-10-18 09:42:07 <_ikke_> https://gitlab.alpinelinux.org/alpine/docs/governance 2019-10-18 09:42:09 <_ikke_> ? 2019-10-18 09:42:31 yeah 2019-10-18 09:42:33 that makes sense 2019-10-18 09:44:23 Ah, thanks 2019-10-18 09:45:24 not sure how to express it as a ticket or MR yet though 2019-10-18 09:53:45 Cogitri: re PR11897 2019-10-18 09:54:05 as i understand we also want enable it for aarch64 at least? 2019-10-18 09:55:06 regarding CVE-2019-17666, looks like it is not fixed in 4.19.80 2019-10-18 09:59:08 ugh 2019-10-18 09:59:09 ok 2019-10-18 10:00:47 mps: do you know if the patch for it is simple? so we can backport it? 2019-10-18 10:00:53 for 4.19.80 that is 2019-10-18 10:00:56 and discussion about this is not finished yet 2019-10-18 10:01:01 ok 2019-10-18 10:01:07 https://lkml.org/lkml/2019/10/16/1758 2019-10-18 10:05:08 but yes, patch looks simple, if you want to apply it, it applies without conflict, just tested 2019-10-18 10:06:12 although didn't tried to build this driver, so don't know will it work at the end 2019-10-18 10:07:46 lets wait for upstream 2019-10-18 10:08:04 agree 2019-10-18 10:21:52 ncopa: Ah, also replied on GH. I think we also want that config switch flipped on other arches, but how would I do `make oldconfig` for those to make sure I haven't forgotten some switch? 2019-10-18 10:26:20 you can run: CARCH=$arch abuild oldconfig 2019-10-18 10:26:35 $ tpaste < update-kernel-configs 2019-10-18 10:26:35 http://tpaste.us/lZxw 2019-10-18 10:26:59 you need to do `abuild deps clean unpack prepare` first though 2019-10-18 10:29:48 ncopa: I would wish to play ps4 on s390x :) 2019-10-18 10:30:24 but it is a super nice request 2019-10-18 10:31:09 ncopa: Ah, thanks 2019-10-18 10:31:24 Will do that then :) 2019-10-18 10:31:25 there are some people running Alpine on ps4 machines, super nice. I once watched somebody hacked bsd version on ps4 to run linux but it's tough 2019-10-18 10:31:52 Didn't Sony remove the possibility to install Linux on a PS3/4? :o 2019-10-18 10:32:47 watch this guy present it long time ago https://fail0verflow.com/media/33c3-slides/, maybe Sony patched it, dunno 2019-10-18 10:35:43 maybe they patched the hw in later versions 2019-10-18 10:37:32 it's a bit strange really, they even actively distributed a Linux variant for, was it, PS2 2019-10-18 10:37:57 and just to be a bit of a contrarian, why run Linux on a PS4, it's already FreeBSD you know :P 2019-10-18 10:40:53 because we can 2019-10-18 10:42:43 while I in no way enjoy trolling, I feel very slightly disappointed no one took the bait ;) 2019-10-18 10:46:25 TBB: take it easy :P 2019-10-18 10:50:18 no worries :) 2019-10-18 11:31:35 If your only contribution to a review is to suggest breaking a package I'm maintaining, please don't waste everyone's time! 2019-10-18 11:35:08 Ah? 2019-10-18 12:15:47 tcely: url? 2019-10-18 12:26:56 ncopa: !327 2019-10-18 12:29:22 <_ikke_> tcely: No need to be passive aggressive about this 2019-10-18 12:30:20 <_ikke_> tcely: being a maintainer of a package does not mean that you can do whatever you want 2019-10-18 12:30:52 _ikke_: I'm fully willing to be direct. This is a stupid upgrade. Stop looking for useless things to argue about it is not a helpful review! 2019-10-18 12:31:19 <_ikke_> tcely: the problem is that there are so many changes in these stupid ugprades 2019-10-18 12:31:35 <_ikke_> if they were stupid upgrades, they would have been long applied 2019-10-18 12:33:10 That last statement is false. If you disagree with changes, you need to do the work yourself. Stop shitting all over work you didn't have to think through for petty nonsense. 2019-10-18 12:42:28 can we please calm down 2019-10-18 13:17:46 tcely: i agree with _ikke_ that your commits are not always self explanatory, and a bit confusing to understand 2019-10-18 13:18:13 it may be good to have more explanations in the commit message to help people that are not as smart as you 2019-10-18 13:19:10 there seems also to be a disagreement on the coding style e.g $var vs ${var} 2019-10-18 13:19:43 i think consistence is better than the "perfect" coding style 2019-10-18 13:20:51 and we have landed on $var rather than ${var} 2019-10-18 13:21:46 and we expect maintainers to respect that 2019-10-18 13:25:51 Duly noted. You want total control and slave labor with no room for improvement. I'll stop wasting my time. 2019-10-18 13:29:14 Won't get into an argument here, but I very much doubt that's what is being aimed for here 2019-10-18 13:29:31 <_ikke_> Cogitri: fyi, tcely quit the channel 2019-10-18 13:30:18 Ah, Riot didn't show that 2019-10-18 13:31:52 i find that some developers are a bit salty, myself included 2019-10-18 13:33:01 or did i missed something? 2019-10-18 13:34:39 <_ikke_> Danct12[m]: Why are you salty? 2019-10-18 13:37:44 He's just salty when he got into a bad day. 2019-10-18 13:37:58 Usually he's fine, I'm close friend to him 2019-10-18 13:41:07 Still feeling bad for tcely, I guess he was a active member here in this channel? 2019-10-18 13:42:08 <_ikke_> He was here regularly, yes 2019-10-18 13:44:01 Then I guess he was just having a bad day 2019-10-18 13:46:07 We try to be as social as possible. But also we have bad days sometimes... 2019-10-18 13:47:22 everyone do 2019-10-18 13:49:30 most likely 2019-10-18 13:50:25 usually if they feel it's not good they probably would start a discussion about 2019-10-18 13:50:29 instead of a simple irc message "stop wasting time" 2019-10-18 13:51:37 <_ikke_> Some people are very adament about certain topics 2019-10-18 14:18:18 sigh 2019-10-18 14:19:17 :c 2019-10-18 14:19:37 i find it difficult to draw the line of consistency and let the maintainers do their own thing/style 2019-10-18 14:19:48 how much we should require of the maintainers 2019-10-18 14:20:16 maintainers needs freedom or it will not be fun 2019-10-18 14:20:34 however, it is also needed that we have some sort of consistency 2019-10-18 14:20:43 naming standards, coding style etc 2019-10-18 14:20:49 or it will be full chaos 2019-10-18 14:21:16 it is not uncommon that opensource projects require that you use their coding style etc 2019-10-18 14:22:12 we did have a discussion some time ago on where to draw the line, and the conclusion was that we should try enforce the coding style 2019-10-18 14:22:52 most people have no problem with that, even if they disagree with the style 2019-10-18 14:23:33 i have also contributed with patches to lots of projects, and i dont always agree with the coding style 2019-10-18 14:23:58 but ofc i have to respect the projects standards 2019-10-18 14:24:24 i guess that we havent been clear enough of what we expect and what the standards are 2019-10-18 14:25:06 alpine didn't had coding style from beginning and it is not easy to force it in short term time 2019-10-18 14:26:32 but is good to have it and strive to it 2019-10-18 14:27:23 <_ikke_> One example that I used is that Linux has lots of subsystems, each with their own maintainers, but Linux as a whole still uses the same coding style 2019-10-18 14:28:41 alpine didnt have a coding style because i considered it common sense that you look what others has previously done 2019-10-18 14:28:54 also, that reaction (above), is why I hesitate to change apkbuilds much when making upgrade or any change 2019-10-18 14:29:37 yeah, and i think avoid big changes is a good thing 2019-10-18 14:30:11 small incremental changes is normally better 2019-10-18 14:30:43 I upgrade/fix pkgs by first looking maintainer field, and if I see someone of whose reaction I'm not sure I stop 2019-10-18 14:32:04 and, I'm only sure that ncopa and clandmeter will not be harsh to me if I make mess with pkgs 2019-10-18 14:32:48 <_ikke_> and also KISS 2019-10-18 14:33:00 forgot to add _ikke_ to list 2019-10-18 14:33:02 <_ikke_> APKBUILDs should be straightforward 2019-10-18 14:34:33 whatever is now we should work to accept some coding style and incrementally apply it, imo 2019-10-18 14:34:53 <_ikke_> We have a coding style 2019-10-18 14:35:23 <_ikke_> We have a linting tool that verifies that coding style 2019-10-18 14:35:29 <_ikke_> and a ci job that runs that linting tool 2019-10-18 14:35:40 yes, but I don't know if it officially forced/accepted 2019-10-18 14:36:11 <_ikke_> Mostly because the idea still exists that the maintainer decides over their own packages 2019-10-18 14:36:56 on the other hand, I don't think it will be good to rush to fix all files which are not according coding style 2019-10-18 14:43:10 _ikke_: where is that tool? 2019-10-18 14:44:03 <_ikke_> kaey: atools in aports 2019-10-18 14:44:15 <_ikke_> https://gitlab.alpinelinux.org/Leo/atools 2019-10-18 14:45:23 thanks 2019-10-18 14:46:03 (agree re discussion of coding style etc- small focused changes) 2019-10-18 14:46:12 (move slowly, break nothing kind of approach :) 2019-10-18 14:46:16 _ikke_: how did you made it work on CI, with grep apk or adapted to busybox grep applet 2019-10-18 14:46:33 <_ikke_> mps: the former 2019-10-18 14:46:51 mort___: agree 2019-10-18 14:46:55 <_ikke_> https://git.alpinelinux.org/aports/tree/community/atools/APKBUILD 2019-10-18 14:47:02 <_ikke_> see depends 2019-10-18 14:51:16 yes, I have it installed and use (ok, sometimes forgot) 2019-10-18 14:51:52 <_ikke_> Well, that's where the CI lint job is for 2019-10-18 14:52:18 <_ikke_> Sadly a lot of people ignore it (I made it allow to fail to prevent false positives from stopping the rest of the build) 2019-10-18 14:54:12 I do not see lint step on travis nor drone on github 2019-10-18 14:54:58 <_ikke_> Correct, it was introduced when we moved to gitlab ci 2019-10-18 14:55:24 I'm one of these, but not because I don't care but because don't like to provoke discussion like we had above with changing someone pkg 2019-10-18 14:55:34 <_ikke_> At some point, we will ask people to use only gitlab 2019-10-18 14:55:53 <_ikke_> mps: Yes I understand 2019-10-18 15:00:59 to add a little, before started to work as packager for alpine I thought it is easy task (lot easier than coding), but after some time I changed mind, it is not easy task 2019-10-18 15:01:40 <_ikke_> it's simple but complex 2019-10-18 15:01:46 styling issues should be deferred to tools as much as possible, but they must not have false positives 2019-10-18 15:01:55 a check with false positive should be done in another tool 2019-10-18 15:02:12 for formatting there is shfmt, which seems not many people know about 2019-10-18 15:02:14 <_ikke_> atools has a test suite where we also try to test for false positives 2019-10-18 15:02:55 <_ikke_> shellcheck does a lot more, so the chances for false positives is a lot bigger (and there are false positives) 2019-10-18 15:05:42 I just hit one in my pkg, it says to remove "cd $builddir" which is wrong https://github.com/alpinelinux/aports/blob/master/testing/telegraf/APKBUILD#L27 2019-10-18 15:07:02 <_ikke_> kaey: why is that wrong? https://git.alpinelinux.org/abuild/tree/abuild.in#n639 2019-10-18 15:07:27 because if [ -d "$builddir" ] 2019-10-18 15:08:51 <_ikke_> Yeah, that 2019-10-18 15:09:00 <_ikke_> that's a tough one to fix 2019-10-18 15:09:24 <_ikke_> kaey: feel free to open an issue on that gitlab project if you want 2019-10-18 15:33:32 would someone push !457 2019-10-18 16:09:05 ACTION take clandmeter as the `relax and chill` reference and _ikke_ as `nice and helpful` reference lol  2019-10-18 16:09:25 ACTION enjoy watching clandmeter slapping _ikke_ in #alpine-infra lol  2019-10-18 16:10:59 https://i.imgflip.com/s4f1k.jpg 2019-10-18 16:29:26 tmhoang: that is culture differences 2019-10-18 16:30:44 we are from different cultures and we have to keep that in mind 2019-10-18 16:50:29 mps: while you are here, do you have a qemu options to run 32bit kernel on 64bit host ? 2019-10-18 16:50:41 x86 I'm saying 2019-10-18 16:54:28 I'm out of home now, will look when I come back 2019-10-18 16:55:36 you mean 32bit kernel in qemu guest on 64bit host 2019-10-18 16:56:11 eh it just boot like normal 64 bit kernel 2019-10-18 16:56:20 it works now 2019-10-18 16:56:25 yes, it should 2019-10-18 16:56:26 have a good evening mps 2019-10-18 16:56:34 <_ikke_> evening 2019-10-18 16:56:56 but for better perfomance you have to find right options 2019-10-18 16:57:22 I just want to test this !1047 2019-10-18 16:57:37 470 2019-10-18 16:57:51 !470 2019-10-18 16:58:43 good evening to all 2019-10-18 16:59:17 I'm going to coffee shop 2019-10-18 17:00:37 <_ikke_> o/ 2019-10-18 18:36:12 Does anybody know how to specify the apkovl a diskless boot will use? 2019-10-18 18:36:12 I have alpine installed on sda1 and sda2, booting from sdc loads the apkovl from sda1. 2019-10-18 18:36:12 I see I can set the kernel cmdline apkovl= value, but I'm not guaranteed that the USB drive will always be assigned to sdc. When initramfs-init runs sdc is not yet mounted on /media/usb. 2019-10-18 18:40:52 Cogitri: small nitpicking note, on gitlab use prefix 'WIP:' instead of '[WIP]' 2019-10-18 18:41:10 are nits blocking? 2019-10-18 18:41:30 grayhatter: 'nits'? 2019-10-18 18:41:43 nitpicking comments 2019-10-18 18:42:12 hehe, no, but we should use standard tags in our gitlab 2019-10-18 18:42:44 <_ikke_> prefixing with "WIP:" is a convention in gitlab and is something the interface supports 2019-10-18 18:43:54 I'm just asking, nits are good things to mention, because eventually everyone should move to an easy standard, but I've worked on projects where nits are blocking... and it sucks the fun out of something when it's blocked on a single nitpicky comment 2019-10-18 18:44:10 _ikke_: i noticed also some MR's prefixed with '[3.9]' and similar, is that new convention we should use or some free-form 2019-10-18 18:44:53 <_ikke_> I would go with that 2019-10-18 18:45:30 then we will have that in commit msgs, or I'm wrong 2019-10-18 18:46:01 <_ikke_> Not necessarily 2019-10-18 18:46:11 <_ikke_> You can prefix it in the MR description 2019-10-18 18:47:37 I made one such bad commit c1996f126a 2019-10-18 18:48:15 c1996f126a9c460fb24e16e3df1400d92107a9df 2019-10-18 18:48:21 <_ikke_> Doesn't look bad 2019-10-18 18:49:47 hmm, in my local git it is prefixed with '[2019-10-14] c1996f126a (mps/3.10-stable) community/mumble: upgrade to stable 1.3.0 release' 2019-10-18 18:51:12 oh, I forgot that I pushed it directly to git.a.o and not over gitlab 2019-10-18 18:52:11 _ikke_: btw, I fixed mesa on gitlab 2019-10-18 18:54:21 can someone tell me what I can do for https://github.com/alpinelinux/aports/pull/10235, main/libevent: upgrade to 2.1.11 2019-10-18 18:54:45 mps: Oh right 2019-10-18 18:54:57 there are two packages which I 'care about' in last year, crystal and shards 2019-10-18 18:55:02 Yes, the built in WIP thingie is pretty nice 2019-10-18 18:55:34 Cogitri: sorry for my nitpick 2019-10-18 18:56:16 No worries, thanks for the heads-up, forgot about it :) 2019-10-18 18:57:55 should the crystal and shards be rebuilt somehow with new libevent version or ....? 2019-10-18 18:58:20 maxice8: could you help me with this 2019-10-18 19:00:45 mps: yes ? 2019-10-18 19:01:33 maxice8: regarding https://github.com/alpinelinux/aports/pull/10235 2019-10-18 19:01:44 main/libevent: upgrade to 2.1.11 2019-10-18 19:02:13 there is a list of pkgs which needs something done with them 2019-10-18 19:02:25 rebuild or something else? 2019-10-18 19:02:28 ohhh 2019-10-18 19:02:35 i never got crystal and its stuff to build 2019-10-18 19:03:03 what should be done for that PR to be unblocked 2019-10-18 19:03:13 rebuild to use the new soname of libevent 2019-10-18 19:03:44 guarantee that all items of that list are ticked 2019-10-18 19:04:23 hmm, how to rebuild if new libevent is not in repos 2019-10-18 19:05:47 build libevent locally, upgrade and the build crystal (and shards) with it 2019-10-18 19:05:49 ? 2019-10-18 19:06:10 Build libevent yourself? 2019-10-18 19:06:13 mps: build it yourself and have your repos before the remote ones on /etc/apk/repository 2019-10-18 19:06:28 thought so but was not sure 2019-10-18 19:06:37 ok, thanks both 2019-10-18 19:06:50 all future builds will use the ones from your repo before the other ones 2019-10-18 19:07:15 maxice8: yes, I know, I do this much too :) 2019-10-18 19:07:28 toooooooooo :D 2019-10-18 19:08:05 but I'll have to report result to you, I think 2019-10-18 19:11:32 It is on GitHub so i don't work on it anymore 2019-10-18 19:11:46 :D if you want to take reponsability of doing it 2019-10-18 19:13:19 no, please. Actually I made my local upgrade and prepared patch to send to gitlab but in last moment looked at github (just in case) and found your MR 2019-10-18 19:13:30 and that list there scared me 2019-10-18 19:14:20 yeah, a lot of stuff uses libevent 2019-10-18 19:16:27 yes, I have to 'apk del tmux' to install it. tmux! 2019-10-18 19:27:02 you don't need to 2019-10-18 19:27:05 if you use dabuild (dockerized abuild builds) 2019-10-18 19:27:26 i prefer lxc 2019-10-18 19:28:13 good thing is if I deinstall tmux current session continue to work without problem 2019-10-18 19:37:09 recommend using a clean repo with just your new libevent in it 2019-10-18 20:08:01 ahills: i'm accustomed to lxc 2019-10-18 20:56:34 all three pkg which holds libevent upgrade (crystal, shards, ameba) passed build with new version 2019-10-18 20:57:38 except that shards failed check. but this is not related to libevent upgrade but to crystal upgrade 2019-10-18 20:58:49 so, someone with github access should mark it as 'ok' in checkboxes 2019-10-18 21:18:00 <_ikke_> opencpn fails to build currently. It complains about missing wx/version.h. It appears that wxgtk-base-dev contains /usr/include/wx/version.h, but it's looking for them here: '/usr/lib/wx/include/gtk2-unicode-3.0;/usr/include/wx-3.0' 2019-10-18 21:19:21 <_ikke_> anyone got an idea how to fix this? Otherwise I disable opencpn for now to keep the builders going 2019-10-18 21:23:53 <_ikke_> ah: https://github.com/alpinelinux/aports/pull/11925 2019-10-18 21:37:45 <_ikke_> qa3Txu0iak0F: ping 2019-10-18 22:05:43 pong 2019-10-18 22:05:51 _ikke_: pong 2019-10-18 22:08:27 ah, damn again conflicts in this wxgtk fix of mine... 2019-10-18 22:11:28 huh, nice i can resolve conflicts on github in the browser. which i just did... 2019-10-18 22:16:52 btw irrespective of my current nick you can always hilite me with stf or stef... no need to figure out what the current one is... 2019-10-18 22:24:36 i dunno why drone is failing, a local build succeeds 2019-10-18 22:57:01 <[[sroracle]]> both [WIP] and WIP: are supported by gitlab fwiw (and toggleable by /wip comment command) 2019-10-19 06:37:49 can somebody merge my PRs https://github.com/alpinelinux/aports/pulls/kaey 2019-10-19 06:48:37 <_ikke_> stef: ah, I just wanted to ask you about wxgtk :-) 2019-10-19 07:47:57 _ikke_: the wxgtk fix is ready to pull 2019-10-19 09:59:19 How should we handle init.d scripts of subpackages? 2019-10-19 11:24:57 <_ikke_> qa3Txu0iak0F: Would you be able to verify https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/5477? I already tried to fix the conflicts myself last night to fix opencpn, but it still complains with this patch. 2019-10-19 12:57:56 hey ho 2019-10-19 12:58:21 re https://gitlab.alpinelinux.org/alpine/aports/issues/10884: I think only minor changes are required the to package 2019-10-19 12:58:57 one of them running rndc-confgen; how does it work in the build process, when/how can/should I call binaries that are part of the package? 2019-10-19 13:04:48 telmich: start_pre? 2019-10-19 13:05:44 look for example in unbound init script 2019-10-19 13:07:02 ack 2019-10-19 13:07:44 hmm... that's a bit different 2019-10-19 13:08:08 it is, but could give you idea 2019-10-19 13:08:09 because checkconf *checks*. I need to generate a key only once 2019-10-19 13:08:47 once per session or? 2019-10-19 13:08:56 The workflow on gitlab is regular in the sense that I create a fork and a pull/merge request later? 2019-10-19 13:09:11 no, only once - so I'd have thought to put it into the installation part of the APKBUILD 2019-10-19 13:09:37 then yes, not in init but pre-install script 2019-10-19 13:10:52 gitlab use, fork aports to your private repo, make changes and create merge request from this changes 2019-10-19 13:12:12 bind already have pre-install script, you can add changes there 2019-10-19 13:13:49 In the pre-install script, I can already access binaries in path from the package? 2019-10-19 13:14:07 From my feeling what I want to do sounds a bit more like post-install 2019-10-19 13:16:06 it depends on use case, ofc. 2019-10-19 13:16:55 there are pre/post scripts 2019-10-19 13:17:48 and install, deinstall, upgrade 2019-10-19 13:20:15 Does "eend" in the init script terminate if the argument is non-zero? 2019-10-19 13:20:18 telmich: keep in mind that some devs don't like too much messing with their packages 2019-10-19 13:20:32 mps: ack. I try to keep it non-invasive 2019-10-19 13:21:48 eend should return, but I'm not openrc expert 2019-10-19 13:21:59 terminate* 2019-10-19 13:27:29 what is the purpose of install=... ? Should I list $pkgname.post-install in it, if I want to use it? The description on https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#install only says that there are 6 different types 2019-10-19 13:29:53 ah, yes, seems to be a list 2019-10-19 13:38:23 Just created https://gitlab.alpinelinux.org/alpine/aports/merge_requests/540 - I hope it's ok 2019-10-19 13:40:04 telmich: You have to bump the pkgrel for that to have an effect 2019-10-19 13:41:55 Also, I think the indention in the named.initd:89 is wrong 2019-10-19 13:50:47 !540 2019-10-19 15:40:22 <_ikke_> qa3Txu0iak0F: ok, opencpn now compiled correctly, nice 2019-10-19 15:41:58 Cogitri: will checkm, thanks for the pointers 2019-10-19 15:43:10 Hooray, so builders aren't blocked anymore 2019-10-19 15:43:15 telmich: Sure thing :) 2019-10-19 15:43:37 <_ikke_> Cogitri: I still need to push it, but yes 2019-10-19 15:44:53 did the ssh key of gitlab just change? 2019-10-19 15:45:53 ikke: Ah okie :) 2019-10-19 15:46:01 I just got "SHA256:HWk/38lXkDGL+G6xrSIdoF/WZujwPFxGGTK8aHFe4nI." and I did not have the authorized_keys entry before 2 hours ago 2019-10-19 15:46:53 not for me 2019-10-19 15:47:07 ok, so it might be something in the hotel wifi - thanks 2019-10-19 15:47:19 and hi 2019-10-19 15:48:03 Just to confirm, which host key should be correct? I wonder if the previous one is/was wrong or the current one 2019-10-19 15:48:23 I've ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAd9h3xhLHSDvI7TFNhNV3W4dKDg1BHQtKE50nUgHJvcUy76qu2tJunRMAGZv4VvpJ9xwBnUvshtXOwn0zEAPKk= in my known_hosts 2019-10-19 15:49:03 gitlab.alpinelinux.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAd9h3xhLHSDvI7TFNhNV3W4dKDg1BHQtKE50nUgHJvcUy76qu2tJunRMAGZv4VvpJ9xwBnUvshtXOwn0zEAPKk= 2019-10-19 15:49:14 looks the same 2019-10-19 15:49:24 we can probably write it somewhere 2019-10-19 15:49:28 just dont know where yet 2019-10-19 15:50:07 ok, will change the location to find a different wifi - I conistently get the written SHA256 hash in this network - see you later 2019-10-19 15:50:30 telmich: did you previously offer arm resources? 2019-10-19 15:51:41 telmich: Can recommend using a VPN, I use that for uni too 2019-10-19 15:54:47 _ikke_: with my patch, or something else? 2019-10-19 16:01:16 <_ikke_> qa3Txu0iak0F: with your patch, indeed 2019-10-19 16:03:11 <_ikke_> :( 2019-10-19 16:03:36 <_ikke_> wxWidgets wx/version.h file not found in 2019-10-19 16:03:38 <_ikke_> /usr/lib/wx/include/gtk2-unicode-3.0;/usr/include/wx-3.0. 2019-10-19 16:06:33 whatthe... 2019-10-19 16:10:29 <_ikke_> I have no idea 2019-10-19 16:10:45 <_ikke_> I tried it in a CI job, and there opencpn built correctly 2019-10-19 16:24:21 <_ikke_> qa3Txu0iak0F: any idea what's happening?e 2019-10-19 17:18:13 we don't have armv7 (or armhf) CI runner? 2019-10-19 17:19:18 <_ikke_> not armhf, but armv7 there is 2019-10-19 17:19:21 hmm, we have armv7 2019-10-19 17:19:45 just see that mesa is built on armv7 2019-10-19 17:20:17 how can I add armv7 CI to !471 2019-10-19 17:20:47 <_ikke_> mps: You need to rebase it onto master 2019-10-19 17:21:14 rebase? how? 2019-10-19 17:21:38 I only used rebase to rewrite git history 2019-10-19 17:21:38 <_ikke_> first, make sure your local master is up-to-date 2019-10-19 17:21:48 <_ikke_> then git rebase master 2019-10-19 17:22:02 <_ikke_> after that, you have to force push your branch 2019-10-19 17:22:21 ok, will try, it's time to learn this 2019-10-19 17:23:50 _ikke_: it works! thank you very much! 2019-10-19 17:24:38 <_ikke_> :-) 2019-10-19 17:25:03 I fixed kexec-tools by editing one file for x86 arch 2019-10-19 17:25:12 <_ikke_> Looks good 2019-10-19 17:25:16 <_ikke_> I mean, the rebase 2019-10-19 17:26:20 but I'm not sure if it will work, and I don't have where to test it. Is it ok to push it 'as is' and wait for bug reports (in the case it doesn't work) 2019-10-19 17:27:57 <_ikke_> depends on what the risc of breakage is I guess 2019-10-19 17:29:17 maybe I should left it on gitlab, with WIP: and add some labels? 2019-10-19 17:29:45 <_ikke_> no idea 2019-10-19 17:29:49 do we have appropriate label for such cases 2019-10-19 17:30:53 <_ikke_> I prefer not to keep MRs open for a long time 2019-10-19 17:32:18 yes, you want low numbers 2019-10-19 17:37:31 <_ikke_> did someone report an issue about it? 2019-10-19 17:38:29 not that I know, only someone asked about it's status on #musl channel 2019-10-19 17:38:53 <_ikke_> It's in testing 2019-10-19 17:38:58 yes 2019-10-19 17:38:58 <_ikke_> so I would just push it 2019-10-19 17:39:01 <_ikke_> that's what testing is for 2019-10-19 17:39:40 anyway, I think I will post patch to kexec-tools ML and ask devs 2019-10-19 17:40:31 I don't like broken pkgs even in testing 2019-10-19 17:41:16 <_ikke_> sure, but the whole idea is that you can push packages there so that they can be tested in the first place 2019-10-19 17:41:36 <_ikke_> If you want someone to be able to test it, they need to be able to install it 2019-10-19 17:42:43 yes, but this is always where my doubts live 2019-10-19 17:43:35 <_ikke_> I would not worry too much if you did your best to create a working package 2019-10-19 17:44:01 <_ikke_> Having it in testing allows people to test it and give feedback 2019-10-19 17:44:05 <_ikke_> now they don't have any possibility 2019-10-19 17:44:06 well, perfect is enemy of good, I agree 2019-10-19 17:45:09 will wait for answer from upstream few days and if they don't answer will push it in current state 2019-10-19 17:45:14 <_ikke_> ok 2019-10-19 17:45:36 thanks for help in cleaning my minds 2019-10-19 17:46:01 <_ikke_> I struggle with these kinds of thing myself from time to time 2019-10-19 17:47:24 personally, I prefer stable alpine even little outdated more than new and shiny features and new packages 2019-10-19 17:48:27 <_ikke_> I think that counts mostly for the core of alpine 2019-10-19 17:48:56 <_ikke_> Of course you want things to be stable, but you don't want to get too much behind as well 2019-10-19 17:49:22 <_ikke_> And the larger Alpine becomes, the less sure you are things are actually stable 2019-10-19 17:50:04 <_ikke_> each new package version can introduce a bug, but at the same time, it could fix bugs as well 2019-10-19 17:52:04 <_ikke_> Ideally you would have a period where you update all packages, and after that, a feature freeze and test everything 2019-10-19 17:52:11 <_ikke_> but I don't think that's achievable 2019-10-19 17:52:30 OT but, obligatory look for packagers, https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ 2019-10-19 17:53:26 <_ikke_> *watching* 2019-10-19 17:54:16 yes, watch/watching, hard to translate in my mind 2019-10-19 18:01:05 <_ikke_> mps: this was not a comment on you, just a comment that I'm currently watching it 2019-10-19 18:04:36 understood, but I'm talking about my knowledge about fine points of English 2019-10-19 18:06:02 I first thought to write 'watch', then 'watching' and was not sure what term is correct so wrote 'look' (which is also incorrect) 2019-10-19 18:06:43 <_ikke_> to `watch` is correct in this case 2019-10-19 18:08:39 will try to remember, but I know I will not succeed :) 2019-10-19 18:09:09 <_ikke_> Watch*ing* is continuous, still ongoing 2019-10-19 18:10:19 like work and working 2019-10-19 18:11:31 thank you for trying to help me, but at the it is important that we mostly understand each other, even with some semantic errors 2019-10-19 18:11:37 <_ikke_> yup 2019-10-19 18:11:56 s/but at/but at the end/ 2019-10-19 18:11:56 mps meant to say: thank you for trying to help me, but at the end the it is important that we mostly understand each other, even with some semantic errors 2019-10-19 18:12:27 <_ikke_> yes, indeed, that's why I clarified that I was not correcting you :) 2019-10-19 18:14:48 feel free to correct me whenever you see I'm making obvious errors 2019-10-19 18:15:02 <_ikke_> alright :-) 2019-10-19 18:16:26 <_ikke_> Am happy with our CI stack :) 2019-10-19 18:16:28 <_ikke_> helps a lot 2019-10-19 18:18:12 yes, you (and clandmeter) did a great work 2019-10-19 19:04:21 <_ikke_> mps: good talk btw :) 2019-10-19 19:05:42 also enjoyed watching it, with laugh ;) 2019-10-19 19:17:16 _ikke_: do you have idea why commit messages in MR are shown on one line (no LF or CR) and not line by line as they are in commit, i.e. 'git log' 2019-10-19 19:17:58 <_ikke_> mps: do you have an example? 2019-10-19 19:18:29 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/471 2019-10-19 19:18:56 'remove aarch64-build-fix.patch, not needed change url to current development url' is shown as one line in gitlab web ui 2019-10-19 19:19:59 or is something wrong with my gitlab UI setup 2019-10-19 19:20:04 <_ikke_> mps: Ah, it's rendered as markdown, and in markdown, single enters are ignored 2019-10-19 19:20:17 <_ikke_> If you look at commits 2019-10-19 19:20:23 <_ikke_> and click on the 3 dots, you see it correctly 2019-10-19 19:22:14 ah, yes 2019-10-19 19:26:04 <_ikke_> You could render it as a list 2019-10-19 19:26:12 <_ikke_> - changed thingy one 2019-10-19 19:26:16 <_ikke_> - updated thingy two 2019-10-19 19:28:02 yes, or write markdown commit message 2019-10-19 19:28:48 <_ikke_> That would be markdown ;-) 2019-10-19 19:29:17 true, but why to stop just with lists 2019-10-19 19:30:50 we could add images, even :p 2019-10-19 19:57:37 _ikke_: i'm sooo lame: https://github.com/alpinelinux/aports/pull/11933 2019-10-19 19:58:12 <_ikke_> heh, it happens 2019-10-19 20:22:49 <_ikke_> qa3Txu0iak0F: algitbot β”‚ edge/community/x86_64: uploaded :-) 2019-10-19 20:24:20 <_ikke_> qa3Txu0iak0F: It works now 2019-10-19 20:24:22 <_ikke_> thanks 2019-10-19 20:28:21 \m/ 2019-10-20 01:51:59 I'm having this mysterious failure on rsyslog 2019-10-20 01:52:00 https://gitlab.alpinelinux.org/Leo/aports/-/jobs/5633/raw 2019-10-20 01:52:12 the build succeeds but at the end APK has 1 error for some reason 2019-10-20 06:17:26 <_ikke_> "1 errors; 10370 distinct packages available" looks like an apk message 2019-10-20 07:45:34 yes i deduced that 2019-10-20 07:45:35 but i have no clue why it got the error 2019-10-20 07:50:25 Is that docker image the correct version? 2019-10-20 07:50:51 Looks like it needs to downgrade too much 2019-10-20 07:52:01 The image is latest but the indexes from stable 2019-10-20 12:11:33 <_ikke_> clandmeter: should I use another base image for stable branches/ 2019-10-20 12:11:35 <_ikke_> ? 2019-10-20 12:19:13 Probably? 2019-10-20 12:21:23 <_ikke_> I 2019-10-20 12:21:36 <_ikke_> It didn't look like it was doing that for drone.io 2019-10-20 12:34:22 I think i did branches 2019-10-20 12:34:30 But only one 2019-10-20 12:35:09 Was this a patch against stable branch? 2019-10-20 12:35:35 <_ikke_> against 3.10 2019-10-20 12:36:32 <_ikke_> But apparently the next run in succeeded 2019-10-20 12:37:38 <_ikke_> https://gitlab.alpinelinux.org/Leo/aports/pipelines/1159 2019-10-20 12:37:44 It did ? 2019-10-20 12:37:44 nice 2019-10-20 12:38:02 i pushed again after syncing just to see if it was a sporadic error 2019-10-20 12:39:17 <_ikke_> It does miss a few arches, is this based on an older commit? 2019-10-20 12:39:27 <_ikke_> notably armv7 and aarch64 2019-10-20 12:40:00 it does ? 2019-10-20 12:40:17 must be 2019-10-20 12:40:30 i did rebase and push way earlier than this conversation 2019-10-20 12:40:36 way earlier = 2 to 3 hours 2019-10-20 12:43:14 Do we periodically rebuild the ci image? 2019-10-20 12:43:27 To update the pkgs 2019-10-20 12:46:07 <_ikke_> Let me verify, but it shoudl 2019-10-20 12:46:43 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/pipelines 2019-10-20 12:46:45 <_ikke_> YES 2019-10-20 12:46:48 <_ikke_> sorry, caps 2019-10-20 12:46:52 <_ikke_> last one was from tonight 2019-10-20 12:47:43 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/pipeline_schedules 2019-10-20 13:24:16 Nice 2019-10-20 14:33:56 <_ikke_> Anyone able to compile https://gitlab.alpinelinux.org/alpine/aports/merge_requests/420 on 3.8? I get an error: "install: can't stat './sqlite3.h sqlite3ext.h': No such file or directory" 2019-10-20 15:21:53 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/510 (Plasma 5.17) is ready to be merged. CI only fails on s390x and ppc64le due to the log size exceeding the limit. New with this upgrade: Plasma is now fully available on s390x and ppc64le πŸŽ‰ 2019-10-20 15:28:37 Thanks for merging maxice8! 2019-10-20 15:30:21 <_ikke_> PureTryOut[m]: Log file size does not cause build failure 2019-10-20 15:30:29 <_ikke_> it does hide the actual failure though 2019-10-20 15:31:30 Ah ok. Well, I'll just wait for the builders to crash on it then 2019-10-20 15:54:06 Why do we have plasma on s390x? 2019-10-20 15:54:28 <_ikke_> I guess because we can? 2019-10-20 15:55:04 It's pretty useless 2019-10-20 15:55:08 <_ikke_> PureTryOut[m]: plasma failed on ppc64le 2019-10-20 15:55:29 <_ikke_> Because they are mainframes? 2019-10-20 16:29:00 Does someone know what's the status of mono on musl? 2019-10-20 16:29:48 I'm trying to package gnome-subtitles but it just explodes saying that mono ran out of memory when I have some 10GB of RAM just sitting arounf 2019-10-20 16:30:29 _ikke_: oh yeah I noticed, I forgot to re-enable ppc64le on some dependencies. Will make MR for it 2019-10-20 16:37:43 Yes, i don't see how anyone who has one will use it. 2019-10-20 16:38:31 Is plasma useable on alpine now? 2019-10-20 16:38:36 _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/560 2019-10-20 16:38:50 Yeah, has been for a while now 2019-10-20 16:38:55 ACTION uses it right now on his laptop 2019-10-20 16:39:03 Cool 2019-10-20 16:39:21 Any docs available? 2019-10-20 16:41:36 Well I made this, but I'm sure it could use more info https://wiki.alpinelinux.org/wiki/KDE 2019-10-20 16:54:10 <_ikke_> PureTryOut[m]: CI is failing for ppc64le and s390x 2019-10-20 16:54:19 <_ikke_> plasma-workspace-dev 2019-10-20 16:54:21 <_ikke_> missing 2019-10-20 16:55:00 I know, I just made a MR for it https://gitlab.alpinelinux.org/alpine/aports/merge_requests/560/pipelines 2019-10-20 16:55:19 Although for some reason CI fails for it 2019-10-20 16:55:22 Oh wait 2019-10-20 16:55:30 <_ikke_> I was looking at that pipeline 2019-10-20 16:56:09 Has plasma-workspace not been built yet for s390x and ppc64le? It should be available 2019-10-20 16:56:29 <_ikke_> apparently not 2019-10-20 16:56:33 <_ikke_> https://pkgs.alpinelinux.org/packages?name=plasma-workspace&branch=edge 2019-10-20 16:57:20 Strange 2019-10-20 16:57:48 It did built though https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/plasma-workspace/plasma-workspace-5.17.0-r0.log 2019-10-20 16:58:32 <_ikke_> Maybe it still needs to sync 2019-10-20 16:59:06 <_ikke_> http://dl-cdn.alpinelinux.org/alpine/edge/community/s390x/ does not list it yet 2019-10-20 16:59:08 Guess so. Maybe it didn't sync due to the total build failing? 2019-10-20 16:59:34 <_ikke_> yes, it's only synced after the it finished building everythign 2019-10-20 17:03:48 <_ikke_> PureTryOut[m]: I fixed the output limit issue for the runners (on some I increased it already, but not for all) 2019-10-20 17:09:06 Ah good thanks! 2019-10-20 17:13:12 And yeah that explains plasma-workspace not being available then. So in theory the builders should be fixed with my MR, but it can't be tested from the CI 2019-10-20 17:13:35 <_ikke_> ok 2019-10-20 18:18:35 <_ikke_> PureTryOut[m]: s390x is now fixed, ppc64le hangs on nextcloud 2019-10-20 18:21:29 Oh, it does? 2019-10-20 18:21:34 Let me check what I broke 2019-10-20 18:22:27 <_ikke_> Cogitri: same as s390x 2019-10-20 18:22:44 <_ikke_> I'm about to disable it 2019-10-20 18:22:51 Ah, oops 2019-10-20 18:23:17 <_ikke_> done 2019-10-20 18:23:30 Thanks 2019-10-20 18:26:10 Gonna be glad once we switch to everything Gitlab with CI for all arches 2019-10-20 18:26:17 <_ikke_> nod :) 2019-10-20 18:26:35 <_ikke_> So, now everything is happy again 2019-10-20 19:29:25 some pkgs have nearly weekly upstream releases 2019-10-20 19:30:59 just read ncurses ML inbox and we are two releases behind, and latest have bug fixes which we need to fix 2019-10-20 19:31:31 ehm, _ikke_ I will try to make MR in a hour 2019-10-20 19:31:36 <_ikke_> (y) 2019-10-20 19:33:15 btw, should I add in commit msg those release notes from ML, they are few lines 2019-10-20 19:35:03 <_ikke_> It's not common to do so, but I would not mind either 2019-10-20 19:35:09 _ikke_: sorry to bother you, but I'm asking for your opinion 2019-10-20 19:56:17 <_ikke_> maxice8: libuv fails to build on s390x (though CI succeeded) 2019-10-20 19:56:25 <_ikke_> test failure 2019-10-20 19:56:36 <_ikke_> sorry, ppc64le, not s390x 2019-10-20 20:02:14 Looks like this happens for more people: https://github.com/libuv/libuv/issues/2468 2019-10-20 20:02:24 https://github.com/clearlinux-pkgs/libuv/commit/a4cbe099b2a60d1598f35bcbf6641903c17ba7bf 2019-10-20 20:03:26 <_ikke_> That patch should fix it? 2019-10-20 20:05:02 Well, the patch just reverts the test to how it was in the previous release, so it should work I guess 2019-10-20 20:05:19 <_ikke_> Right 2019-10-20 20:05:33 <_ikke_> They expect multicast to work 2019-10-20 20:07:16 <_ikke_> But it only fails on ppc64le apparentl 2019-10-20 20:12:13 Yup, maybe it's on the builder? 2019-10-20 20:12:39 Also, for something completely different: How should one handle OpenRC files when they belong to a subpackage? 2019-10-20 20:23:55 And could someone who knows Go take a look at pr11760? 2019-10-20 20:27:05 <_ikke_> Cogitri: It is possible to create a dedicated $subpkgname-openrc package 2019-10-20 20:28:34 <_ikke_> Cogitri: zabbix does that for example for the agent subpackage 2019-10-20 20:28:51 <_ikke_> Cogitri: some said you're not supposed to create sub-subpackages 2019-10-20 20:29:56 Ah, okie, thanks for the info 2019-10-20 20:37:03 And maybe someone with a clue about Java could look at pr8552? 2019-10-20 20:57:18 anyone aware of a segv in bluez with musl? 2019-10-20 21:01:02 Bluetooth works fine for me at least 2019-10-20 21:06:07 Cogitri: ever use audio playback? 2019-10-20 21:06:47 No, I only use it for my stylus 2019-10-20 21:07:13 Microsoft Surface? 2019-10-20 21:07:21 I can try if it works with my IEMs, but those don't work properly under Windows for some reason so I doubt they'll work on Linux 2019-10-20 21:07:37 HP Spectre X360 w/ a HP Tilt Pen 2019-10-20 21:07:51 nah, I think it's hardware, I'll investage a bit more on my own first 2019-10-20 21:07:55 thanks though! 2019-10-20 21:08:09 s/hardware/drivers 2019-10-20 21:08:09 grayhatter meant to say: nah, I think it's drivers, I'll investage a bit more on my own first 2019-10-20 21:08:22 ok, never correcting that way again 2019-10-20 21:08:32 :) 2019-10-20 21:09:14 :P 2019-10-20 21:23:55 <_ikke_> :-( 2019-10-20 21:24:00 <_ikke_> now 2 arches fail on libuv 2019-10-20 21:27:30 Huh, weird 2019-10-20 21:28:12 <_ikke_> yup 2019-10-20 21:28:16 <_ikke_> like wack a mole 2019-10-21 08:04:08 ACTION checking libuv 2019-10-21 08:04:25 <_ikke_> tmhoang: thanks! 2019-10-21 08:04:36 morning 2019-10-21 08:04:46 <_ikke_> morning 2019-10-21 08:09:08 Morning 2019-10-21 08:33:38 the new mesa-19.2.1 rekt everything :D 2019-10-21 08:34:18 <_ikke_> oink 2019-10-21 08:35:47 <_ikke_> What broke? 2019-10-21 08:35:47 maxice8: it works for me on aarch64, but ofc looks like there are bugs, #908 2019-10-21 08:36:02 oh, no, not this 2019-10-21 08:36:28 this issue report #10887 2019-10-21 08:36:44 mps: on x86_64 anything that uses libGL and libEGL fail hard 2019-10-21 08:37:00 Yes, Cogitri sent me it when i asked him to test alacritty 2019-10-21 08:38:17 ok, need to be fixed, obviously. anyone can test it on x86_64 and create fix/patch 2019-10-21 08:38:26 mps: I think it might be related to the elf-tls thing 2019-10-21 08:38:33 I don't have x86_64 box with edge 2019-10-21 08:38:39 Working on it 2019-10-21 08:38:48 if it is elf-tls i'll add a conditional to enable it only on aarch64, can you test in that arch ? 2019-10-21 08:38:50 maxice8: I also think same 2019-10-21 08:38:53 i have no aarch64 hw 2019-10-21 08:39:48 maxice8: maybe it will be better to remove this patch and use previous one for tls 2019-10-21 08:40:12 previous one will node some tweaks 2019-10-21 08:41:10 i don't know what the previous one was 2019-10-21 08:41:13 but I think not too much 2019-10-21 08:41:46 it was add-glx-use-tls.patch 2019-10-21 08:42:11 That sounds familiar 2019-10-21 08:42:29 oh, From: maxice8 :) 2019-10-21 08:44:15 probably should be reverted to your previous patch 2019-10-21 08:46:07 yep, it still has broken GLX 2019-10-21 08:47:10 @mps i modified your patch to make use-elf-tls to false by default so i have to only set it to true on aarch64 instead of disabling on everything else 2019-10-21 08:47:32 yep, cna confirm on x86_64 edge with i3wm: (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: Error relocating /usr/lib/libGL.so.1: alphasort: initial-exec TLS resolves to dynamic definition in /usr/lib/libGL.so.1 2019-10-21 08:47:42 at least xorg start :> 2019-10-21 08:47:44 maxice8: please set it to false also for aarch64 2019-10-21 08:48:01 oh ? 2019-10-21 08:48:25 I will test it and if it doesn't work then you can enable it only for aarch64 2019-10-21 08:48:56 less divergence is good for pkg's, imo 2019-10-21 08:50:48 ah ok 2019-10-21 08:50:49 well it didn't work :D GLX is still broken 2019-10-21 08:50:50 and now have to reboot my aarch64 box, just built kernel 5.4-rc4, and too unpatient to test it :) 2019-10-21 08:51:10 heh 2019-10-21 08:51:25 oh 2019-10-21 08:51:33 see you later 2019-10-21 08:52:10 well my older patch doesn't apply anymore because mesa doesn't even test for USE_GLX_TLS 2019-10-21 09:21:20 !570 need testers and someone to merge it 2019-10-21 09:21:41 <_ikke_> maxice8: I can merge it once it's tested 2019-10-21 09:38:00 _ikke_, working for me on x86_64, no more load error, firefox fine, acceleration too 2019-10-21 09:41:54 nice 2019-10-21 09:43:35 just in build log is that: 2019-10-21 09:43:38 WARNING: Unknown options: "glx-use-tls" 2019-10-21 09:43:46 :P 2019-10-21 09:44:35 <_ikke_> maxice8: Should I use gnutls >= 3.6.10-r0 for that wiki entry? 2019-10-21 09:45:19 seems the best way to express a pkg version for me 2019-10-21 09:45:25 <_ikke_> I mean that specific version 2019-10-21 09:45:53 then i don't know 2019-10-21 09:46:19 <_ikke_> Is the version that is specified the one that fixes it again or that is affect (then >= does not make sense to me) 2019-10-21 09:47:53 should be the one that fixes it 2019-10-21 09:48:56 <_ikke_> That version has been built after the last musl ugprade, so I assume that one fixes it 2019-10-21 10:12:07 I see 2019-10-21 10:12:09 can you merge !570 ? 2019-10-21 10:19:38 <_ikke_> maxice8: yes 2019-10-21 10:20:05 <_ikke_> Why does it fail on x86? 2019-10-21 10:20:44 <_ikke_> tmhoang: libuv built without issues on our CI pipeline btw 2019-10-21 10:21:06 _ikke_: because of textrel 2019-10-21 10:21:42 something about TEXTREL 2019-10-21 10:22:05 <_ikke_> No idea what that is :) 2019-10-21 10:23:16 text relocation 2019-10-21 10:25:29 Something something not good for security 2019-10-21 10:27:14 options = `if arch == x86 then textrel fi` 2019-10-21 10:27:53 textrels* 2019-10-21 10:29:34 or build all with -fPIC 2019-10-21 10:31:03 <_ikke_> Wasn't this a problem before? 2019-10-21 10:33:13 no, for some unknown reason (to me) it appeared now 2019-10-21 10:33:49 but in such code as is mesa we can expect every surprise 2019-10-21 10:35:09 is the musl upgraded on x86 CI, just guessing in dark 2019-10-21 10:35:10 It appeared after we removed USE_ELF_TLS which was breaking mesa 2019-10-21 10:35:31 _ikke_: !580 removes an obsolete workaround 2019-10-21 10:36:32 ah, that is 2019-10-21 10:36:50 gnutls change 2019-10-21 10:39:06 <_ikke_> Thread Local Storage 2019-10-21 10:46:00 hmm, failed in my aarc64 lxc but probably my lxc is broken, not the mesa 2019-10-21 10:46:17 so can't test it now 2019-10-21 10:48:05 this monday is one of those which should be added to weekend :) 2019-10-21 10:57:23 PREFIX ?= $(HOME) 2019-10-21 10:57:26 lol 2019-10-21 10:58:07 nobody uses our sparse package 2019-10-21 10:58:35 http://ix.io/1Zop 2019-10-21 10:59:50 <_ikke_> lol 2019-10-21 11:00:03 <_ikke_> Even in community 2019-10-21 11:00:53 <_ikke_> The apkbuild says PREFIX=/usr 2019-10-21 11:01:30 it does on build() 2019-10-21 11:01:34 not on the make that calls install 2019-10-21 11:03:35 morning 2019-10-21 11:03:41 my xfce desktop is broken 2019-10-21 11:03:50 morning 2019-10-21 11:04:01 seems like the mesa update broke xfwm 2019-10-21 11:04:12 <_ikke_> Yes 2019-10-21 11:04:19 <_ikke_> A fix is being worked on 2019-10-21 11:04:30 oh 2019-10-21 11:04:33 _ikke_: can you push !570 ? i added a workaround for x86 2019-10-21 11:04:41 <_ikke_> maxice8: Yes, just read it 2019-10-21 11:04:41 @ncopa the mesa update broke everything that uses mesa 2019-10-21 11:04:43 :D 2019-10-21 11:06:09 <_ikke_> Pushed 2019-10-21 11:07:02 that's what happens for those who use edge 2019-10-21 11:07:29 <_ikke_> yes, but on the other hand, be happe they do and these issues are noticed 2019-10-21 11:08:11 such breakage couldn't be not noticed 2019-10-21 11:08:33 although it works for me without issue 2019-10-21 11:08:39 <_ikke_> sure, but you want to catch it as soon as possible, not at rc time 2019-10-21 11:09:25 mps, some wm using glx by default and cant even run it 2019-10-21 11:09:50 <_ikke_> The fixed package is being built 2019-10-21 11:10:27 MY-R: no one can test every package upgrade on every possible arch and use cases 2019-10-21 11:11:07 and I'm sure _ikke_ wouldn't push it it didn't passed CI on all arch's 2019-10-21 11:11:28 <_ikke_> ahuh 2019-10-21 11:11:30 s/it it/if it/ 2019-10-21 11:11:30 mps meant to say: and I'm sure _ikke_ wouldn't push if it didn't passed CI on all arch's 2019-10-21 11:11:34 mps, you didnt nootice the issue :P 2019-10-21 11:11:46 <_ikke_> But CI just tests if it builds 2019-10-21 11:11:59 MY-R: as I wrote it works fine on my edge box 2019-10-21 11:12:02 was enough to run something what need gpu acceleration, browser, game, mpv with gpu :P 2019-10-21 11:12:35 mps, got anything in: grep EE /var/log/Xorg.0.log 2019-10-21 11:12:37 ? 2019-10-21 11:13:18 yes, but unrelated 2019-10-21 11:13:38 where can i read about this glx-use-tls vs use-elf-tls in mesa? 2019-10-21 11:13:52 is there any upstream issue or discussions somewhere 2019-10-21 11:14:01 mps, rly no single missing libglx.so ? :\ 2019-10-21 11:14:40 they have issues on mesa.gitlab.org 2019-10-21 11:15:08 <_ikke_> gitlab.mesa.org? 2019-10-21 11:15:18 <_ikke_> neither exist 2019-10-21 11:15:41 <_ikke_> https://gitlab.freedesktop.org/mesa/mesa 2019-10-21 11:16:08 https://gitlab.freedesktop.org 2019-10-21 11:16:20 yes, sorry 2019-10-21 11:16:59 I looked but didn't found anything which looks related to the issue 2019-10-21 11:17:13 <_ikke_> https://gitlab.freedesktop.org/mesa/mesa/issues/1032? 2019-10-21 11:17:15 <_ikke_> this 2019-10-21 11:17:17 <_ikke_> ? 2019-10-21 11:17:45 curious asking 2019-10-21 11:17:54 is it alright to upstream a ddos botnet simulator 2019-10-21 11:18:49 no it's not some skid tool like LOIC or something, this is a simulation which helps educate people how bad a ddos attack could be 2019-10-21 11:18:55 and only works with LAN 2019-10-21 11:19:11 _ikke_: isn't this related to x86 textrels issue 2019-10-21 11:19:26 ... without the appropriate patches, that is ;) 2019-10-21 11:19:46 MY-R: probably because I don't use glx on aarch64 2019-10-21 11:19:47 Oh interesting that a Void patch is used for Mesa to enabled the "use-elf-tls" build option. We had our own version of that patch in postmarketOS already https://gitlab.com/postmarketOS/pmaports/blob/master/temp/mesa-git/add-use-elf-tls.patch 2019-10-21 11:19:54 <_ikke_> mps: ah yes, not the original issue 2019-10-21 11:20:37 mps, that for sure :) 2019-10-21 11:21:05 thought you have some pc :P 2019-10-21 11:21:23 Not really, Bonesi ICMP/UDP attack could run on the internet 2019-10-21 11:21:32 It's just HTTP-based attack couldn't 2019-10-21 11:21:44 PureTryOut[m]: this patch is in previous aports version for mesa 2019-10-21 11:22:14 MY-R: yes, I have x86_64 but with stable on it, not edge 2019-10-21 11:22:50 I use it for my $day_job and can't run edge on it, for well known reasons 2019-10-21 11:23:01 ohh 2019-10-21 11:27:46 i wonder if its this: https://bugs.freedesktop.org/show_bug.cgi?id=35268 2019-10-21 11:28:54 <_ikke_> quite an old bug report 2019-10-21 11:29:51 yeah 2019-10-21 11:30:25 and migrated to https://gitlab.freedesktop.org/mesa/mesa/issues/966 2019-10-21 11:32:09 i think they had/have same problem in freebsd: https://lists.freebsd.org/pipermail/freebsd-arch/2016-February/017699.html 2019-10-21 11:37:21 PureTryOut[m]: do you have any details on the use elf tls thing? 2019-10-21 11:37:56 Not really sadly 2019-10-21 11:38:41 maxice8: seems link !570 makes things work again. 2019-10-21 11:39:12 ncopa: nice, MY-R tested it as well and my computer didn't crash when i tried running HOI4 via wine 2019-10-21 11:39:23 but i wonder if we need the patch at all, if its disable by default anyway 2019-10-21 11:39:33 yes, just restared X with this patch and it works also on aarch64 2019-10-21 11:39:39 It isn't 2019-10-21 11:39:55 so we could just disable it? 2019-10-21 11:40:14 it is enabled by default if you're not android 2019-10-21 11:41:00 ncopa: We did 2019-10-21 11:41:20 maxice8: how you remember such details, I also looked there but forgot about it 2019-10-21 11:41:25 i mean, we could just remove the patch? 2019-10-21 11:41:38 ncopa: no 2019-10-21 11:42:18 if you remove the patch ELF_TLS will be enabled because it always enables if the target system is not android 2019-10-21 11:42:32 ok 2019-10-21 11:42:42 yeah, i read the patch again 2019-10-21 11:43:25 i guess the price is reduced performance? 2019-10-21 11:43:33 mps: the patch is open on one of my workspaces 2019-10-21 11:44:06 Preferably we get upstream to realize there are more Linux targets than just Android and glibc 2019-10-21 11:45:27 apparently it is/was a problem in freebsd too 2019-10-21 12:07:42 back 2019-10-21 13:27:29 im tagging alpine 3.10.3 now 2019-10-21 13:30:23 ncopa: would you write release notes 2019-10-21 13:33:42 splitting clavav-libunrar should be added to release notes, if some will write them 2019-10-21 13:37:19 https://wwwtest.alpinelinux.org/posts/Alpine-3.10.3-released.html 2019-10-21 13:52:13 this is git short log, maybe there should be notes about important chages 2019-10-21 13:52:37 <_ikke_> Usually only major releases get extended release notes 2019-10-21 13:52:54 I only know for split of libunrar from main clamav apk 2019-10-21 13:53:00 <_ikke_> minor releases should not have significant changes 2019-10-21 13:53:11 well, they sometimes have 2019-10-21 13:53:57 most users of clamav who upgrade it to 3.10.3 will have issue with this 2019-10-21 13:54:35 <_ikke_> Most users would just upgrade without reading release notes 2019-10-21 13:54:43 <_ikke_> It's not as if they are switching to 3.10.3 explicitly 2019-10-21 13:55:17 well, true, but anyway, will not hurt to some notes 2019-10-21 13:58:01 users should not have any issues with upgrading in stable bracnjes 2019-10-21 13:58:20 why was libunrar splitted? 2019-10-21 13:59:11 mps: what do you think we should include in the release notes? 2019-10-21 13:59:16 im about to send it out now 2019-10-21 14:00:19 cf6b14480665acd8c533d8a514cb32bf74f565d7 2019-10-21 14:00:42 commit message says "fix libunrar subpkg creation" 2019-10-21 14:02:19 mps: like this? http://tpaste.us/aRJl 2019-10-21 14:03:11 <_ikke_> ncopa: It probably needs some information about what users should do to prevent issues 2019-10-21 14:03:48 shouldnt be any issues. apk upgrade should only fix things 2019-10-21 14:04:13 <_ikke_> I agree, but that's the point mps I believe tries to make 2019-10-21 14:05:07 looking at the commit, it should not have any noticable effect on users 2019-10-21 14:05:14 <_ikke_> They would possibly have to explicitly install clamav-libunrar 2019-10-21 14:05:51 no, i dont think so. the libs should be pulled in via so:depends 2019-10-21 14:06:55 <_ikke_> Ok, but why does mps think something needs to be noted in the release notes then that users should be aware of 2019-10-21 14:07:20 <_ikke_> "plitting clavav-libunrar should be added to release notes". "most users of clamav who upgrade it to 3.10.3 will have issue with this" 2019-10-21 14:07:43 <_ikke_> But it only contains libs, so yeah, it should automatically be pulled in 2019-10-21 14:07:50 mps: will clamav users get issues when the upgrade clamav? 2019-10-21 14:09:37 mps: can you please clarify what we need to include in release notes? 2019-10-21 14:10:22 previously libunrar was in main clamav pkg 2019-10-21 14:10:55 cf6b14480665acd8c533d8a514cb32bf74f565d7 2019-10-21 14:11:15 and this in commit msg, - fix libunrar subpkg creation 2019-10-21 14:11:31 iirc, this is done by clandmeter 2019-10-21 14:11:35 <_ikke_> mps: But wouldn't alpine automatically pull in the right package? 2019-10-21 14:11:35 what does that mean for upgraders? 2019-10-21 14:12:03 why does it need to be mentioned in release notes? 2019-10-21 14:12:11 it means that during upgrade they will lost libunrar 2019-10-21 14:12:32 <_ikke_> What depends on libunrar? 2019-10-21 14:12:38 unless they explicitly add clamav-libunrar? 2019-10-21 14:12:46 _ikke_: no, it will not be pulled automaticaly 2019-10-21 14:13:43 ok. i think that we shouldnt have done that in stable branch 2019-10-21 14:14:01 its not good that you unexepectedly lose unrar scanning 2019-10-21 14:14:33 I did not made that split 2019-10-21 14:14:53 maybe we should add clamav-libunrar as hard dep to clamav for now? 2019-10-21 14:15:23 or do you think we should mention it in release notes? 2019-10-21 14:15:29 well, clandmeter better know what is the reason for split 2019-10-21 14:15:55 I think it is enough just to mention it in notes 2019-10-21 14:15:58 i dont think we need to mention it 2019-10-21 14:16:17 because it will probably not make any difference at this point anyway 2019-10-21 14:16:24 people have probably already done apk upgrade 2019-10-21 14:16:51 mps: how do you suggest we word it? 2019-10-21 14:16:59 yes, people do not read it, but project will have less blames if that is mentioned, imo 2019-10-21 14:17:15 http://tpaste.us/qKBB 2019-10-21 14:17:35 or do you think we should say: if you use clamav you should apk add clamav-libunrar 2019-10-21 14:17:57 yes, that sounds fine 2019-10-21 14:18:08 but to be honest 2019-10-21 14:18:15 i'd rather revert the change 2019-10-21 14:18:34 I'm not against that 2019-10-21 14:19:04 just would like to have less angry users 2019-10-21 14:19:19 i think we will get more blame if we mention it in release notes 2019-10-21 14:19:34 we messed up, and we documented it, so it was by design 2019-10-21 14:19:42 then I'm also for reverting it back 2019-10-21 14:20:13 or add explicit depends 2019-10-21 14:20:19 that maybe even better 2019-10-21 14:20:45 whatever you think, I agree with both options 2019-10-21 14:20:54 http://tpaste.us/Nmvv 2019-10-21 14:21:19 looks fine 2019-10-21 14:25:13 the apkbuild was broken, so this commit fixes it. it can break some ppl's setup yes. 2019-10-21 14:25:36 because they didnt explicitly installed libunrar subpkg 2019-10-21 14:25:44 it was bundled 2019-10-21 14:26:03 https://tpaste.us/xkZW 2019-10-21 14:26:06 if we make it a hard dep then the subpkg has no function and can be removed. 2019-10-21 14:27:00 but there existed an empty clamav-libunrar? 2019-10-21 14:27:08 yes 2019-10-21 14:27:30 so a proper install would have had it anyways 2019-10-21 14:27:43 but it would have been cosmetic 2019-10-21 14:27:44 so if someone did: apk add clamav clamav-libunrar, thinking that they installed the libunrar plugin 2019-10-21 14:28:04 and when testing it it worked (but they didnt know that libunrar package was broke) 2019-10-21 14:28:06 yes they would have it but packed with main pkg 2019-10-21 14:28:25 then if we remmove it, they'll get error message? 2019-10-21 14:28:27 when upgrade 2019-10-21 14:28:33 remove what? 2019-10-21 14:28:53 if we remove clamav-librunrar package rather than add it as depends to clamav 2019-10-21 14:29:18 i guess you can also add provides 2019-10-21 14:29:46 i think explicit depends is the simple/stupid solution here 2019-10-21 14:29:59 imho its not a solution 2019-10-21 14:30:10 its bandage to ppl who didnt install it correctly 2019-10-21 14:30:23 right 2019-10-21 14:30:30 and removes the function of a real subpkg 2019-10-21 14:30:41 so you are also breaking things for ppl who dont want to install it. 2019-10-21 14:31:12 that we cannot do anything about 2019-10-21 14:31:23 why not? 2019-10-21 14:31:29 will not be possible to uninstall if we add provides 2019-10-21 14:31:44 im saying you are trying to fix something that is not broken 2019-10-21 14:31:45 you will always get libunrar regardless if you want it or not 2019-10-21 14:31:56 ok 2019-10-21 14:31:58 not in current state 2019-10-21 14:32:04 true 2019-10-21 14:32:24 so you rather let it be as it is? 2019-10-21 14:32:28 and a good user would installed both if he queried apk about clamav 2019-10-21 14:32:58 anyway, too much time for too small gain. 2019-10-21 14:33:01 so what you think is good :) 2019-10-21 14:33:15 s/so/do 2019-10-21 14:33:15 clandmeter meant to say: do what you think is good :) 2019-10-21 14:33:32 i'll leave it as is then 2019-10-21 14:34:52 ok, when first users come to ask we can open issue and explain there about this 2019-10-21 14:35:46 yeah 2019-10-21 14:35:52 tbh, i dont think anyone will care 2019-10-21 14:35:58 clandmeter: thanks for good explanation 2019-10-21 14:36:37 mps: thanks for paying attention :) 2019-10-21 14:36:46 ncopa: yes, users/admins of alpine knows such things, mostly 2019-10-21 14:37:26 ncopa: np, I'm trying to help keep good 'image' of alpine 2019-10-21 14:37:37 im glad i finally managed to get it out the door 2019-10-21 14:37:46 its so heavy to get releases out 2019-10-21 14:38:57 btw, to get back to clamav, this would have been a good candidate for apk changelog option. 2019-10-21 16:45:00 _ikke_: I guess you reverted the libuv commit brining it back to ok ? 2019-10-21 17:11:00 <_ikke_> tmhoang: No, not yet. The only thing I reverted was the changes to a test (as some other projects did the same to fix it), but it didn't help 2019-10-21 17:13:16 _ikke_: !470 I still don't know how to fix properly for x86. It seems GOARCH and GOOS are properly set 2019-10-21 17:13:33 continuing tmr, good night 2019-10-21 17:13:50 <_ikke_> tmhoang: no worry, thanks for your help 2019-10-21 17:19:17 <_ikke_> tmhoang: apparently it finally succeeded 2019-10-21 17:19:19 <_ikke_> :D 2019-10-21 17:19:22 <_ikke_> (libuv) 2019-10-21 20:58:39 what to do with packages which require network connection during build 2019-10-21 21:17:11 anyone know why iputils don't have -doc subpackage 2019-10-22 04:12:48 _ikke_: atools 18.8.6 is out 2019-10-22 04:33:17 <_ikke_> maxice8: thanks 2019-10-22 04:35:35 <_ikke_> maxice8: I've pushed it to aports :) 2019-10-22 04:35:48 i saw 2019-10-22 07:18:37 <_ikke_> Rebuilding the lint image to include the new version 2019-10-22 07:20:31 <_ikke_> "(22/29) Installing atools (18.8.6-r0)" 2019-10-22 07:23:49 nice 2019-10-22 08:48:18 clandmeter: im pushing qemu-4.1 upgrade 2019-10-22 08:49:32 oh nice 2019-10-22 08:49:50 i have a MR to update virglrenderer that requires a qemu rebuild 2019-10-22 09:16:29 ncopa: ok 2019-10-22 09:16:41 there seem to be some things disabled 2019-10-22 09:16:47 i was wondering if we could enable them 2019-10-22 09:16:52 ie iscsi support 2019-10-22 09:22:59 ncopa: do you remember why iputils doesn't build -doc subpackage 2019-10-22 09:37:31 mps: i dont 2019-10-22 09:42:09 maybe because xsltproc issues? (just guessing) 2019-10-22 09:43:55 doesnt seem to build any manpage 2019-10-22 09:45:25 I'm working on upgrade, and noticed that -doc is missing 2019-10-22 09:45:55 clandmeter: i can look at enable iscsi 2019-10-22 09:46:45 I managed somehow to build manpages tweaking xsltproc parameters but not sure are man pages needed because they are not in current version 2019-10-22 09:47:12 so far noone has missed them 2019-10-22 09:47:25 or at least not reported they are missing 2019-10-22 09:47:43 personally i tend to google man .... 2019-10-22 09:48:21 looks like so, but sooner or later someone will ask why we don't have -doc 2019-10-22 09:49:56 problem with xsltproc is that it need network during build, although it is disabled in makefiles. maybe that is reason why there is no -doc 2019-10-22 10:30:31 ncopa: for what do you use the size value in mqtt git msg? 2019-10-22 10:46:05 <_ikke_> qemu fails on ppc64le 2019-10-22 10:47:54 clandmeter: not following. isnt it the size of the message? so it depends on how big the message is? 2019-10-22 11:01:47 @ncopa #include from libisci 2019-10-22 11:05:09 hum 2019-10-22 11:05:21 ok its probably a missing linux-headers 2019-10-22 11:05:25 im on it 2019-10-22 11:05:40 im also investigating qemu on ppc64le 2019-10-22 11:05:50 seems like CONFIG_LINUX is not defined on ppc64le 2019-10-22 11:06:08 i wonder if it gets defined on x86_64 2019-10-22 11:06:56 i believe this fixes qemu: http://tpaste.us/DDEO 2019-10-22 11:11:33 ncopa: no its the amount of commits in a push i beleive 2019-10-22 11:55:12 When is the 3.11 fork going to happen, so what's the deadline for updates and moving stuff to community? 2019-10-22 11:55:27 <_ikke_> PureTryOut[m]: Usually right before the release 2019-10-22 11:55:37 <_ikke_> so even at rc time, it's not forked yet 2019-10-22 11:56:07 ASAP basically, ncopa is going to start the 3.11 builders soon 2019-10-22 11:56:23 (which is why I'd really, really like to get !509 in soon) 2019-10-22 11:56:41 <_ikke_> There is still enough time 2019-10-22 11:57:00 <_ikke_> The builders will first need to build world 2019-10-22 11:57:00 hopefully python2 is out before 2019-10-22 11:58:48 maxice8: do you mean 'python2 out of main' 2019-10-22 11:58:56 So when is that release exactly? 2019-10-22 11:58:58 or out of alpine 2019-10-22 11:59:32 PureTryOut[m]: I expect it for new year 2019-10-22 12:00:40 PureTryOut: 6 months after 3.10 has been released 2019-10-22 12:01:13 I think the rc cycle was supposed to start in November 2019-10-22 12:01:59 Which is... 2019-10-22 12:01:59 June 2019-10-22 12:02:00 Ok thanks 2019-10-22 12:02:34 https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases yup, June 2019-10-22 12:03:06 mps: Out of Alpine most likely since it won't be supported for that long anymore 2019-10-22 12:03:34 At least not officially 2019-10-22 12:05:24 Cogitri: thanks for explanation. then I need to rebuild some packages with python3 2019-10-22 12:07:30 Would be best, yes 2019-10-22 12:14:51 Got lot of MRs for main/ :D 2019-10-22 12:28:03 maxice8: what is with your PR for libevent? will you create MR or ...? 2019-10-22 12:28:31 <_ikke_> maxice8: I look at them when I have time, but there's only so much I can do 2019-10-22 12:28:39 <_ikke_> last weekend I applied a bunch of them 2019-10-22 12:28:55 <_ikke_> maxice8: maybe you could spend time looking at the MRs that are stuck 2019-10-22 12:33:16 mps: it is abandoned 2019-10-22 12:36:21 Do we have a fancy label indicating some MR is ready on Gitlab too? 2019-10-22 12:36:42 <_ikke_> Nope, not atm afaik 2019-10-22 12:37:02 <_ikke_> There is a duplicates label, but that's quite generic 2019-10-22 12:45:25 maxice8: ok, then I will create MR for libevent, I have it somewhere in local git repo 2019-10-22 14:08:44 mksully22: I suspect that ppc64le linux headers are broken. on x86_64 asm/mman.h has a #include , on ppc64le it is missing 2019-10-22 14:09:02 ncopa: this patch fixes build of testing/libiscsi, http://tpaste.us/7KXw 2019-10-22 14:09:22 the result is that MAP_SYNC is not defined with #include , which is needed by qemu 2019-10-22 14:10:39 i dont know if that is the case for glibc as well 2019-10-22 14:33:41 mps: sounds like wrong fix. we syoud disable -Werror 2019-10-22 14:35:02 it will fail with '-Werror', already tried 2019-10-22 14:35:15 we should disable -Werror 2019-10-22 14:35:43 apparently there is a configure option for it 2019-10-22 14:35:49 --disable-werror 2019-10-22 14:37:08 let me try 2019-10-22 14:38:05 i already pushe :) 2019-10-22 14:38:06 right, adding ' --disable-werror' to configure fixes it 2019-10-22 14:38:10 pushed* 2019-10-22 14:38:32 good, problem solved 2019-10-22 15:38:30 _ikke_: iirc you had a script that searched the pkgs.a.o database for packages containing python3.6 or similar? Do you remember where we have that script? 2019-10-22 15:38:39 i'd like to rebuild packages for python 3.8 2019-10-22 15:39:32 so i need a script that generates a list of packages that contains /usr/lib/python3.7 2019-10-22 15:55:36 <_ikke_> I guess it was just a query on the DB 2019-10-22 15:55:48 <_ikke_> Let me see if I can still find it 2019-10-22 15:56:22 <_ikke_> ncopa: it's in the root of alpine-pkgs.nld3.alpin.pw 2019-10-22 16:02:54 <_ikke_> ncopa: I've updated it for python3.8 2019-10-22 16:03:01 <_ikke_> (just replaced 3.7 with 3.8) 2019-10-22 16:50:47 hmm, what is 'GLOB_TILDE support'? I see some package are rebuilt with this in commit msg 2019-10-22 16:57:15 <_ikke_> A new musl feature 2019-10-22 16:58:24 thanks, missed that in release notes 2019-10-22 17:06:31 <_ikke_> Me too, I asked about it 2019-10-22 17:45:23 If we have to disable check in pkg (options="!check") do we need to bump pkgrel, or left it as it is? 2019-10-22 17:46:29 <_ikke_> If you try to fix a broken build, then no pkgrel bump is needed 2019-10-22 17:46:46 <_ikke_> And disabling checks would not warant a pkgrel bump anyway 2019-10-22 17:47:39 ok, thought so, thanks 2019-10-22 20:01:52 <_ikke_> Great 2019-10-22 20:02:05 <_ikke_> sysstat source origin returns 500 :-/ 2019-10-22 20:11:03 https://github.com/sysstat/sysstat ? 2019-10-22 20:11:23 <_ikke_> Yes, that's what I ended up using 2019-10-22 23:00:21 maxice8: please merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/668 2019-10-23 03:56:46 PureTryOut: But my protobuf commit did relbump libphonenumber 2019-10-23 04:57:01 <_ikke_> Weird, now it suddenly just built 2019-10-23 06:32:26 maxice8: huh, that commit/change wasn't there when I looked yesterday evening, and it wasn't in the repos either 2019-10-23 06:32:26 Guess my MR can be ignored then 2019-10-23 06:45:57 _ikke_: you there ? 2019-10-23 06:46:20 http://ix.io/1Zzq can you confirm this also happens to you ? 2019-10-23 09:11:00 <_ikke_> let me check 2019-10-23 09:11:36 <_ikke_> maxice8: yes, it does 2019-10-23 09:11:39 maxice8: _ikke_: looked at it, missing perl-try-tiny in depends 2019-10-23 09:11:56 I deduced that much 2019-10-23 09:12:09 <_ikke_> I also get a different error 2019-10-23 09:12:20 <_ikke_> ERROR: nx-libs-3.5.99.22-r0: trying to overwrite usr/lib/libX11.so.6.3.0 owned by libx11-1.6.9-r0. 2019-10-23 09:12:38 yes that is weird 2019-10-23 09:12:50 no other distro depends on nx-libs for that package :D 2019-10-23 12:34:17 im working on python 3.8 now 2019-10-23 12:36:06 Nice :D 2019-10-23 12:37:12 Saw some packages will require adaptation 2019-10-23 14:22:46 Made some PRs that drop usage of python2 on packages that are not python-modules 2019-10-23 14:22:58 like porting packages that use python2 to run minor build scripts to python3 2019-10-23 14:23:32 _ikke_: i also tagged you on a few MRs that can be merged that were blocked due to py-twisted 2019-10-23 14:24:22 <_ikke_> Yes, I saw them 2019-10-23 16:25:12 Can i get pr11766 merged ? it is blocking FF-70 2019-10-23 16:26:18 <_ikke_> I just finished my pizza :) 2019-10-23 16:27:03 <_ikke_> DOne 2019-10-23 16:29:23 ty 2019-10-23 16:34:36 maxice8: !700 failed to apply patch 2019-10-23 16:36:08 I've built libevent as it is in !658 2019-10-23 16:36:21 mps: yes, it is meant for the version that is being updated on your MR 2019-10-23 16:37:45 ok, I'm uninitiated to python so don't know about that 2019-10-23 16:38:53 but, I built 4 packages with libevent upgraded without that patch (tmux, crystal, shards and ameba), all worked 2019-10-23 16:39:58 oh, ignore it then 2019-10-23 16:40:05 but again, I trust you about this. and I can't fix this patch because I don't know much about python. someone else should 2019-10-23 16:40:35 just disregard the patch 2019-10-23 16:41:32 easy words, now you 'forced' me to test more packages :) 2019-10-23 16:45:08 also this !693 I think I pushed it last night with 88d8cf363947b19ef656aa1f70e6371cebc9c616 2019-10-24 09:08:28 <_ikke_> SpaceToast: I've pushed the latest salt version :-) 2019-10-24 09:43:03 please, if someone with main push rights have a little time !753 need to be pushed, so I can make new iwd and push 2019-10-24 09:46:54 while browsing aports i saw a bug in main/compat-pvgrub, i dont know how you normally handle this or who is the maintainer, but here is a patch http://dpaste.com/25XP8X9 2019-10-24 09:47:20 <_ikke_> jailbox: apparently it's unmaintained 2019-10-24 09:47:56 <_ikke_> do you mind sending it to the mailing list or opening a gitlab merge request? 2019-10-24 09:48:33 sure i'll mail it 2019-10-24 11:41:28 i think we have a problem with the indirect depends in python 2019-10-24 11:41:37 this for example c6d12c52b562aea3fad3c22d09edcf4394a6f85b 2019-10-24 11:41:46 broke various packages 2019-10-24 11:42:30 but im not sure if it is because it was difficult to find any users of py2 pytest 2019-10-24 11:43:02 py-filelock build fails now 2019-10-24 11:43:11 checkdepends="pytest" 2019-10-24 11:44:24 i suppose the proper thing is to also drop py2-filelock 2019-10-24 11:45:19 There are no consumers of it 2019-10-24 11:45:23 :D move it to py3-! 2019-10-24 11:46:55 !765 2019-10-24 12:04:39 i think community/pytest-xdist uses it for check 2019-10-24 12:04:45 thanks though! 2019-10-24 12:05:05 i have it in my local python3.8 branch now 2019-10-24 12:16:07 any volunteer to take over maintainership of one of those packages? http://tpaste.us/red1 2019-10-24 12:17:31 i'll take ntpsec 2019-10-24 12:19:12 i could take fstrm 2019-10-24 12:19:56 will look later at knot 2019-10-24 12:19:57 mps: I have an MR to update fstrm to 0.6.0, if you confirm i'll set you as maintainer: as well 2019-10-24 12:20:18 maxice8: np 2019-10-24 12:20:25 0c67cd1eba2f8985bf99a3d59c014e31866f0e35 what's this all about? 2019-10-24 12:23:49 nmeum: tcely doesn't want to work on his packages anymore 2019-10-24 12:24:43 yeah, I am just suprised about the dramatic commit message 2019-10-24 12:25:12 i think it is something that has buildt up over time 2019-10-24 12:25:17 looks like it 2019-10-24 12:25:23 and he simply got enough 2019-10-24 12:25:36 That conversation can't be the only reason he did this... 2019-10-24 12:25:46 nope 2019-10-24 12:26:41 in general, his PRs was often complicated, and very "smart", (i.e not KISS) 2019-10-24 12:26:50 sometimes they broke things 2019-10-24 12:27:07 often they looked like they broke things 2019-10-24 12:27:10 many emotions, like in politics :D 2019-10-24 12:27:22 but after closer look they didnt 2019-10-24 12:27:23 <_ikke_> Most maintainers didn't dare to merge his PRs, so they remained open for quite some time 2019-10-24 12:27:43 often the changes ahd coding style changes embedded 2019-10-24 12:27:59 he had strong opinion on the coding style 2019-10-24 12:28:03 he has* 2019-10-24 12:28:43 i find it difficult to balance the freedom maintainers are given wrt codingstyle etc, and consistency 2019-10-24 12:28:44 That much is clear 2019-10-24 12:29:18 ncopa: I think you handeled that balance quite well in the past :) 2019-10-24 12:29:27 I have to agree with you that consistency is preferred, even though it pains me sometimes lol 2019-10-24 12:30:02 we discussed it a few weeks ago, and the conclusion was that we need to be stricter with coding style 2019-10-24 12:30:07 <_ikke_> The problem is that when each aport has a different style, it's difficult for others to know what to expect 2019-10-24 12:30:19 consistency over maintainer freedom 2019-10-24 12:30:57 nmeum: i think most people adapt to the projects general style 2019-10-24 12:31:03 regardless if they agree with it or not 2019-10-24 12:31:21 yeah 2019-10-24 12:31:22 @ncopa i made MRs for unbound and aspell secissues 2019-10-24 12:32:01 maxice8: great! i'll have a look at it in a bit 2019-10-24 12:32:35 tcely's PR was often very time consuming to review 2019-10-24 12:32:54 which resulted in few people who dared to look at them at all 2019-10-24 12:33:03 which again is frustrating for a contributor 2019-10-24 12:37:07 hmm, he contributed his time, some resources and effort to help alpine project and we should just say 'thank you for your help and good luck' 2019-10-24 12:37:19 yeah 2019-10-24 12:37:20 <_ikke_> mps: ncopa thanked him 2019-10-24 12:37:34 mps: you are absolutely right 2019-10-24 12:37:43 _ikke_: yes, I read it already 2019-10-24 12:38:17 anyone is free to leave for whatever reason 2019-10-24 12:40:42 ^ exactly but his last sentence sounded very personal, not to mention that rage quit and some big need to show in commit message how waste of time was to contribute to Alpine :\ 2019-10-24 12:44:57 MY-R: we all are human beings (I hope) and we sometimes take 'things' personally (some too much) but no one is forced to work on alpine (except ncopa maybe) 2019-10-24 12:45:40 so, we willingly waste our time and don't see as a problem 2019-10-24 12:45:54 agree! 2019-10-24 13:02:19 and nobody need to explain why leaving 2019-10-24 13:02:29 in this case i think he wanted to 2019-10-24 13:06:07 oh, cool! apparently oracle cares about alpine 2019-10-24 13:06:14 they sent me patches for mysql 2019-10-24 13:06:25 <_ikke_> You personally? 2019-10-24 13:06:32 yup 2019-10-24 13:06:40 <_ikke_> interesting 2019-10-24 13:06:41 should have been to the mailing list :) 2019-10-24 13:06:55 <_ikke_> probably because you were listed as the maintainer? 2019-10-24 13:07:08 They've sent you patches rather than the mailing list or via Gitlab/Github? 2019-10-24 13:07:18 correct 2019-10-24 13:07:32 now only me can respond :-/ 2019-10-24 13:07:53 NDA? ;) 2019-10-24 13:08:01 https://bugs.mysql.com/bug.php?id=80322 2019-10-24 13:08:31 <_ikke_> that's an old report 2019-10-24 13:08:36 (oracle want to take over alpine :D ) 2019-10-24 13:11:00 there is a patch: https://bugs.mysql.com/file.php?id=28498&bug_id=80322 2019-10-24 13:12:01 mps, πŸ™„ (rolling eyes emoji) 2019-10-24 13:12:20 looks like they support alpine upstream: https://github.com/mysql/mysql-server/search?q=alpine&type=Commits 2019-10-24 13:14:57 this is good 2019-10-24 13:23:10 how should be revdeps for !658 made 2019-10-24 13:23:29 one by one or all in one commit 2019-10-24 13:24:48 here https://github.com/alpinelinux/aports/pull/10235 is a list of packages (prepared by maxice8) which should be rebuilt with upgraded libevent 2019-10-24 13:26:03 When coming from void I'd do one by one 2019-10-24 13:26:08 looks like only seamonkey is left confirmation (I rebuild crystal, ameba and shards) 2019-10-24 13:26:21 Now I just do all in one commit besides the one to update libevent itself 2019-10-24 13:26:48 heh, I'm for void method, then 2019-10-24 13:36:30 i normally do rebuilds one by one commit 2019-10-24 13:36:44 because its more convenient while working on it 2019-10-24 13:38:56 good, I will remove WIP from MR and when it pushed prepare other one by one 2019-10-24 13:41:23 Well, respond that they should post it to the mailing list lol 2019-10-24 14:18:04 <_ikke_> mksully22: Can it be that the ppc64le Alpine Builder is down? 2019-10-24 14:18:29 <_ikke_> mksully22: we cannot ping it anymore 2019-10-24 15:30:24 ncopa: is there a chance you could move linuxconsoletools to community? It has been in testing since 2013 already, and we have used it in pmOS perfectly fine 2019-10-24 15:41:04 Well, open a MR for it and everyone with commit access could do that :) 2019-10-24 16:01:20 :) there is an update to 1.7.0 available for it 2019-10-24 16:13:02 Ok https://gitlab.alpinelinux.org/alpine/aports/merge_requests/786 2019-10-24 16:27:00 πŸ‘ 2019-10-24 17:28:29 i must say i also feel demotivated by reviews and nitpicking on style. i spend a lot of time to get things correctly working, and this is ignored and obstructed because i dont give about spaces vs tabs or because i wrote "bumped to version" instead of "upgraded" in the commit message. if the reviewer things that this is important the reviewer should correct such cosmetic issues themselves. 2019-10-24 17:30:01 <_ikke_> qa3Txu0iak0F: Would you feel clear documentation would alleviate this? 2019-10-24 17:30:09 <_ikke_> and tools? 2019-10-24 17:30:18 and hence i do maintain my own repo where noone looks at style, and i call it aports-ugly 2019-10-24 17:30:55 <_ikke_> Both on how to submit aports and do's and don't for reviewing? 2019-10-24 17:31:19 Well, if you use atools it'll spot about all of those things during comitting already 2019-10-24 17:31:34 i think often the effort on communicating on a review takes more effort than the reviewer simply fixing the style-change himself 2019-10-24 17:31:58 <_ikke_> qa3Txu0iak0F: which is what I often do if it's simple issues 2019-10-24 17:32:10 <_ikke_> But I'm not always sure it's appreciated 2019-10-24 17:32:38 <_ikke_> But sometimes for new users it's good to make them aware about certain practices 2019-10-24 17:33:16 <_ikke_> like Cogitri said, we have atools, with a CI pipeline that runs it 2019-10-24 17:33:25 <_ikke_> so users already get quick feedback about codestyle issues 2019-10-24 17:35:10 qa3Txu0iak0F: The problem is the merger always fixing the style doesn't scale, it's way better to tell someone how the style is done once and after that they'll do it themselves 2019-10-24 17:35:46 And things like mixing tabs and spaces isn't just about looking uniform or something, it can make for pretty hard to read diffs too 2019-10-24 17:36:01 diff -w helps that 2019-10-24 17:36:45 We certainly don't have to go so far as to enforce ordering deps alphabetically or something over the top like that, but some basic style makes the life easier for everyone else 2019-10-24 17:37:19 diff -w isn't the default though, git diff doesn't use it by default either and GitHub/GitLab will highlight it too 2019-10-24 17:37:31 zomg. what an idea. this deps alphabetic ordering. zomg 2019-10-24 17:40:13 anyway, my preference would be less style checking, but i respect the opposite as well, the consequence is my motiviation and the number of my contributions. 2019-10-24 17:40:36 qa3Txu0iak0F: It does but it is a long-term investment, fixing it every time takes more than teaching a few things. 2019-10-24 17:41:10 re: reviewer fixing stuff instead of showing what is wrong 2019-10-24 17:41:49 well, the hidden cost is the motivation and number of contributions of those that are sensitive to this. your call. 2019-10-24 17:42:55 look at my repo and see all those packages that i maintain out-of-the-official-repos because of this. 2019-10-24 17:43:26 <_ikke_> qa3Txu0iak0F: but almost any project has some required codestyle and other requirements 2019-10-24 17:44:07 and alpine's are pretty tame 2019-10-24 17:44:22 Well, my motivation is drained when I have to work on an APKBUILD where I first have to dig through some super odd styling before I can get to actually doing what I want 2019-10-24 17:44:51 <_ikke_> qa3Txu0iak0F: Of course, if you keep your aports private, you can do whatever you want 2019-10-24 17:45:10 <_ikke_> But it's not unreasonable to expect some quality if you want to upstream things 2019-10-24 17:45:31 <_ikke_> qa3Txu0iak0F: My experience is that it's easier to adopt the style of the project 2019-10-24 17:45:36 even Void Linux is pretty tame and they have forced order of know variables 2019-10-24 17:45:53 known* 2019-10-24 17:46:14 PureTryOut: you there ? 2019-10-24 17:46:30 _ikke_: I would like clear documentation for what is expected, for example I only learned about the lint tool in a middle of a review 2019-10-24 17:46:34 Atm yes 2019-10-24 17:46:45 I see your plasma MR has passed on all except one (which is running), can i merge it ? 2019-10-24 17:46:54 <_ikke_> xerireu: Yes, I agree. atools is relatively new, so it's not advertised a lot yet 2019-10-24 17:47:13 Yes! Thanks πŸ˜ƒ 2019-10-24 17:47:24 maxice8: ppc64le will complete once libsass has got the latest pkgrel bump for that architecture (which it hasn't atm) 2019-10-24 17:47:34 <_ikke_> xerireu: I'll try to kickstart some official developer documentation 2019-10-24 17:47:36 till then, the build will be stuck at current position 2019-10-24 17:47:44 ah ok 2019-10-24 17:47:45 <_ikke_> xerireu: except for atools, anything you feel should be included? 2019-10-24 17:47:46 merged 2019-10-24 17:49:16 BTW, librsvg has been bumped to 2.46.3, want to merge !509 soon before I need to re-run CI for all those packages with 2.46.3, ikke? :P 2019-10-24 17:49:29 <_ikke_> Cogitri: Alright 2019-10-24 17:49:30 hah! 2019-10-24 17:49:38 _ikke_: for me it's mostly clear expections and solidated documentation, I was personally a bit confused by the wiki pages and where to look for information 2019-10-24 17:49:47 bump to is incorrect. it should be "upgraded to"... 2019-10-24 17:49:49 :) 2019-10-24 17:50:02 <_ikke_> lol 2019-10-24 17:50:32 Don't you worry, that's just the MR title :P 2019-10-24 17:50:41 you troll you :) 2019-10-24 17:50:53 <_ikke_> Cogitri: I already started to look at it, but it's a lot :) 2019-10-24 17:51:09 nice one. respect :) 2019-10-24 17:51:19 Yup, it sure is 2019-10-24 17:52:38 Somewhere along the line I stopped doing style fixes for all the packages I've touched and just disabled on s390x/moved 2019-10-24 17:52:49 <_ikke_> nod 2019-10-24 17:53:08 <_ikke_> espcially with these larger projects, I would skip mass fixing style issues 2019-10-24 17:53:15 <_ikke_> Makes reviewing a lot easier 2019-10-24 17:54:59 Yup, I'll just disable my pre-commit hook next time 2019-10-24 17:56:45 <_ikke_> --no-verify :-) 2019-10-24 17:59:36 ACTION curses self for not RTFM'ing 2019-10-24 18:04:40 <_ikke_> protip if you use tig: install git-diff-highlight and add `set diff-highlight = true` to ~/.tigrc 2019-10-24 18:06:18 <_ikke_> makes it easier to see what changed in a line 2019-10-24 18:09:52 <_ikke_> Anyone knows what this error is about? https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/8128 2019-10-24 18:10:01 <_ikke_> darktable-2.6.3/src/iop/highlights.c:700:17: error: '*.LC2' not specified in enclosing 'parallel' 2019-10-24 18:10:37 <_ikke_> Only on aarch64 / armv7 2019-10-24 18:23:17 <_ikke_> Cogitri: for graphviz, the gtk subpackage is what requires librsvg? 2019-10-24 18:25:21 Yup 2019-10-24 18:25:58 <_ikke_> ok 2019-10-24 18:39:56 <_ikke_> Sad that we lose so many packages on s390x, but on the other hand, I don't think these packages would matter so much on s390x anyway 2019-10-24 18:41:47 Yup, I doubt anyone used any of them 2019-10-24 18:41:54 And Rust on s390x musl still seems a bit distant 2019-10-24 18:42:00 looking on all these MR's with upgrades to python3 I'm amazed how much packages depends on python 2019-10-24 18:42:12 On another note, pr 11967 seems kind of important too 2019-10-24 18:45:57 <_ikke_> Anyone knows why vim is not automatically wrapping commits messages at 72 characters on alpine, while it does on other platforms? It does higlight in red the 2nd line, so it does recognize it's a git commit message 2019-10-24 18:46:19 mps: They don't depend per-se, some do but most use it with scripts during build to generate headers and other information 2019-10-24 18:46:40 maxice8: yes, I meant to say for building 2019-10-24 18:47:26 _ikke_: we don't have APKBUILD setup for vim, tagline or something similar 2019-10-24 18:48:38 <_ikke_> Cogitri: ok, hold on, I think I'm ready to push !509 2019-10-24 18:49:09 <_ikke_> Cogitri: are you available to look at eventual build issues? 2019-10-24 18:49:48 Yup 2019-10-24 18:49:49 ':set textwidth=72 2019-10-24 18:50:08 <_ikke_> Yes, but normally that automatically happens for git commit messages 2019-10-24 18:50:14 ':set textwidth=72' in vim solve that issue 2019-10-24 18:50:24 <_ikke_> Yes, I know how I can set it manually 2019-10-24 18:50:36 <_ikke_> just wondering about the difference 2019-10-24 18:50:38 I guess we don't have the vim syntax file for that? 2019-10-24 18:51:28 <_ikke_> :echo &filetype -> gitcommit 2019-10-24 18:51:57 there are files for git in /usr/share/vim/vim81/, syntax plugins etc 2019-10-24 18:52:04 but not for apkbuild 2019-10-24 18:53:17 mps: It's not about APKBUILD syntax highlighting, it's about gitcommit highlighting so that doesn't matter 2019-10-24 18:53:36 <_ikke_> yeah, APKBUILD is just sh, that works fine 2019-10-24 18:54:23 funnily enough, my neovim thinks APKBUILDs are of the `conf` filetype 2019-10-24 18:55:20 yes, vim see it as sh but doesn't know for special thing in it 2019-10-24 18:56:09 things* 2019-10-24 18:56:42 https://github.com/alpinelinux/aports/pull/11967#issuecomment-546054859 2019-10-24 18:56:42 ^ 2019-10-24 18:57:31 Cogitri: git commit for me have all these 'bells and whistles' by default 2019-10-24 18:58:14 vim git commit, I mean 2019-10-24 18:58:18 <_ikke_> For me it does highlight the 2nd line for example 2019-10-24 18:58:29 <_ikke_> but no autowrapping at the 72th column 2019-10-24 18:58:49 <_ikke_> ok, brace yourself 2019-10-24 19:00:12 git commit in vim for me mark in red background lines over 72 but don't wrap it, maybe by intention to allow longer lines 2019-10-24 19:00:58 even spell check work although I ignore it's suggestions :) 2019-10-24 19:01:05 ACTION presses "f" for the builders 2019-10-24 19:01:10 <_ikke_> ha! 2019-10-24 19:01:12 Thanks for looking at that massive MR :) 2019-10-24 19:02:53 Cogitri: merged the libssh2 PR, thanks for pointing that out 2019-10-24 19:03:44 πŸ‘ 2019-10-24 19:07:30 <_ikke_> Cogitri: maybe it would be nice to have a check that pkgrel / pkgver are increased in the first place 2019-10-24 19:07:54 Yup 2019-10-24 19:07:58 _ikke_: i tried that via githooks 2019-10-24 19:08:28 :D sure was a f*cking mess 2019-10-24 19:08:30 <_ikke_> in the CI pipeline we can get the diff 2019-10-24 19:08:37 maxice8: your githook works fine for pkgver 2019-10-24 19:08:59 in git, I mean 2019-10-24 19:09:24 sometimes i even get bitten by my check that pkgrel=0 when doing a pkgver bump :D 2019-10-24 19:10:39 I'm so accustomed to it that i blindly accept what it does 2019-10-24 19:10:44 <_ikke_> loo 2019-10-24 19:10:46 <_ikke_> lol 2019-10-24 19:11:23 and sometimes have fear that I will make mess because of this 2019-10-24 19:11:31 there are some edge cases 2019-10-24 19:12:06 if you move an APKBUILD (renaming a package or moving it to another repo) and modify it, sometimes it will complain that pkgrel=0 is not 0 because it sees +pkgver in the git-diff 2019-10-24 19:12:17 i mean 2019-10-24 19:13:04 I need to discipline myself a little to check it just in case 2019-10-24 19:13:19 it will complain that pkgrel is not 0, because it sees the addition of pkgver and thinks you're bumping, and when you bump you need to put pkgrel=0 2019-10-24 19:23:51 So I want to add some codeingstyle rules with regards to pkgver; but there is some ambiguity there. But I guess the most important question to ask (for me) is; do we want to honor the software authors versioning scheme, or do we somehow want to 'convert' this to something alpine specific. 2019-10-24 19:24:43 if for example, the author of software awesome, wants to version his software as 'rel-0.1', how do we rename this (we can drop the rel- part, but we are also going against the authors wishes) 2019-10-24 19:25:38 to make it more complex, what if the author has 'bionic-0.1' followed by 'crystal-0.1' Of course this will be next to impossible to reliably script (what version is higher) so there could be rules where it is always required to allow for such algorithm to work 2019-10-24 19:26:08 <_ikke_> yes, there will always be edge cases 2019-10-24 19:26:33 right now, there is the rule, that if 'semver' is used for software (v2.6.5) for example, that the v prefix is to be dropped, as it's just the short hand moniker for 'version', so we deviate slightly from what the author wants/intended maybe? (just look at any random github release) 2019-10-24 19:26:59 <_ikke_> the pkgver is not there for esthetic reasons though 2019-10-24 19:27:05 <_ikke_> It's a technical field 2019-10-24 19:27:10 for me personally, I tag my software with the v prefix, v0.1; everywhere, all links etc the software is called 'awesomeness v0.1' 2019-10-24 19:27:27 both though, right? 2019-10-24 19:27:43 i mean, you want to match 'our' version, to the authors version, if it where purely technical, we'd use our own versioning scheme 2019-10-24 19:28:02 which how does that work for simple 'svn' style revisions 'r1, r2, r3' 2019-10-24 19:28:09 and with it being a technical field i don't think that makes much sense to have a detailed codestyle in regardings to it. imho this is something which could be easily delegated to the maintainer 2019-10-24 19:28:30 and a rule of thumb such as "stick to the upstream version scheme if possible if not come up with something else" 2019-10-24 19:28:43 so while we absolutly _use_ it as a technical field (ensure higher versions replace lower versions) 2019-10-24 19:29:07 aux contraire; if it is a technical field, it HAS to be documented in the code style 2019-10-24 19:29:30 as people need to know what EXACTLY to put there and what is allowed 2019-10-24 19:29:46 the rule of thumb you just mention, is the perfect eample 2019-10-24 19:30:33 but 'stick to the upstream verisioning scheme' already brings up questions, e.g. "convert prefixed semver, to just plain semver; e.g. v[er-]0.0.1 -> 0.0.1 2019-10-24 19:30:54 that's a shortcoming indeed. for instance, a -r suffix cannot be used in $pkgver as it's used for $pkgrel that should be documented indeed 2019-10-24 19:31:02 <_ikke_> oliv3r[m]: shfmt is the only package in aports currently that has a v prefix 2019-10-24 19:31:05 in any case, the last thing you want is to have discussions of 'what is the right way', and more importantly WHY it is the right way 2019-10-24 19:31:50 _ikke_: lol yeah I wasn't aware that we where stripping it, I just used what the author did; I honored his wishes in essense 2019-10-24 19:32:08 for _users_ I think it is important (while it is a technical field) they want to be able to 'clearly' map one to the other 2019-10-24 19:32:30 <_ikke_> the version number is more important than the v prefix for that though 2019-10-24 19:32:50 as always, consistency (within the package) is key of course 2019-10-24 19:33:04 <_ikke_> I prefix my git tags with v as well, but I would not care whether a project uses it or not to refer to a version 2019-10-24 19:33:08 I prefer plain semver 2019-10-24 19:33:18 so again, question 1; do we want to honor the authors versioning scheme as much as possible, or is it more something 'loosely follow it' 2019-10-24 19:34:29 mps: ah see, but you see v prefixed semver SO often, that *I* wrongfully assumed that that was actually part of the semver spec 2019-10-24 19:34:41 <_ikke_> oliv3r[m]: My guess is that there are not a lot of people that care whether alpine uses the v prefix or not, but hard to tell 2019-10-24 19:34:57 <_ikke_> oliv3r[m]: so far, as far as I know, we've had no one complain yet 2019-10-24 19:34:59 but what _ikke_ says may not always be true, some people tend to be very pendantic about these kind of things 2019-10-24 19:35:07 <_ikke_> ^^ 2019-10-24 19:35:23 i think alpine is still 'small' in that regard in the public 'knowledge' side of things 2019-10-24 19:35:55 well it's pretty easy though; we can simply describe the pkgrel as 'loosely follows the upstream versioning' to begin with 2019-10-24 19:35:58 <_ikke_> https://www.archlinux.org/packages/ 2019-10-24 19:36:01 <_ikke_> no v prefix there 2019-10-24 19:36:15 also debian 2019-10-24 19:36:16 The only thing I want to do, is start to document it, so we can refer to the CODESTYLE.md :) 2019-10-24 19:36:47 and I think fedora does use plain semver 2019-10-24 19:37:13 <_ikke_> oliv3r[m]: I think we should not make too much a point out of it (and try to think for the authors) unless they actually ask us to change it 2019-10-24 19:37:15 which, mind you, makes sense, but lets then just put it down somewhere :) 2019-10-24 19:37:51 e.g. if a project uses {prefix}semver; use just semver for pkgver 2019-10-24 19:38:23 <_ikke_> note that x.y.z does not necessarily imply semver 2019-10-24 19:38:30 I think it is fair to say, that alpine favors semver in general for versioning? 2019-10-24 19:38:46 <_ikke_> (even though we kind of assume it does) 2019-10-24 19:40:34 I'll find some time to draft something up for the codestyle document, and we can discuss it in depth on the MR :) 2019-10-24 19:44:38 <_ikke_> interesting. v1.0.0 is deemed older than 1.0.0 2019-10-24 19:44:45 <_ikke_> (apk version -t v1.0.0 1.0.0 2019-10-24 19:45:53 <_ikke_> oliv3r[m]: so apparently there is even a semantic difference 2019-10-24 19:46:02 what about !4 2019-10-24 19:46:14 <_ikke_> apk version -t v500 1.0.1 2019-10-24 19:46:17 <_ikke_> < 2019-10-24 19:47:02 ah, v500; would we strip the v here as well? 2019-10-24 19:47:38 <_ikke_> That was just an example. versions prefixed with a v are always deemed older than versions without the prefix 2019-10-24 19:47:53 <_ikke_> so from v -> is trivial, the other way around not 2019-10-24 19:48:28 _ikke_: I've contacted the person in charge of the ppc64le hardware and asked him to restart the builders 2019-10-24 19:48:37 <_ikke_> mksully22: thanks! 2019-10-24 19:49:01 <_ikke_> Note that our CI builder (the last one received) is alright 2019-10-24 19:51:02 _ikke_: I know it's an example. but if someone versions his package as v1234; do we strip the v or not. it's not 'clearly semver' so what do we favor here? (ver-1234 isn't even allowed) 2019-10-24 19:53:06 <_ikke_> oliv3r[m]: https://pkgs.alpinelinux.org/packages?name=go-acceptlanguageparser&branch=edge 2019-10-24 19:53:56 his tag is horrible: goacceptlanguageparser_v100 2019-10-24 19:54:04 but ultimpately his choice :) 2019-10-24 19:54:16 so in this example I guess this answer is 'yep, strip it' 2019-10-24 19:56:42 <_ikke_> https://github.com/OpenAoE/vblade/releases 2019-10-24 19:56:50 <_ikke_> vblade-xx 2019-10-24 20:00:27 The ppc64le builder is on a machine at Unicamp. It appears that they have networking issues going on. They are working to resolve but apparently it may take a while 2019-10-24 20:00:51 <_ikke_> mksully22: ok, thanks for the headsup 2019-10-24 20:21:12 Unicamp? 2019-10-24 20:27:32 nmeum: What's the status of pr6719? 2019-10-24 20:29:47 Unicamp is The University of Campinas in Brazil. 2019-10-24 20:33:29 Almost went study there 2019-10-24 20:40:04 https://github.com/alpinelinux/aports/pull/11974 commited but will need backport and probably bump other packages 2019-10-24 20:41:09 Hi guys 2019-10-24 20:41:25 Should I use pkggroups="www-data" or should I use addgroup -Sg 82 www-data in preinst? 2019-10-24 20:42:26 <_ikke_> for what webserver? 2019-10-24 20:43:11 I'm packaging a wiki 2019-10-24 20:43:14 dokuwiki 2019-10-24 20:43:41 I need some group for uploaded data (e.g. pictures and stuff) and it seems that in alpine most of the webapps use www-data group for that matter 2019-10-24 20:43:55 cacti, racktables 2019-10-24 20:44:01 gogs and gitea 2019-10-24 20:44:01 ncopa: fwiw I labeled a few main/ PRs as `Ready` for when you have some time. 2019-10-24 20:44:37 And a bunch of other packages 2019-10-24 20:44:42 <_ikke_> Cogitri: seems like we don't have a single user for webservers 2019-10-24 20:44:50 <_ikke_> so I'm not sure of www-data makes a lot of sense 2019-10-24 20:45:08 well, it's kinda common in the tree 2019-10-24 20:45:08 <_ikke_> consus: in any case, you would need btoh 2019-10-24 20:45:13 <_ikke_> both 2019-10-24 20:45:20 nginx adds itself to www-data 2019-10-24 20:45:26 I can check apached and lighttpd 2019-10-24 20:46:07 <_ikke_> apache does as well 2019-10-24 20:46:14 <_ikke_> that yes, do both 2019-10-24 20:46:24 ad lighttpd 2019-10-24 20:46:27 *as 2019-10-24 20:46:28 <_ikke_> pkgusrs / pkggroups is while building 2019-10-24 20:46:46 <_ikke_> so that you can chown files ot those users 2019-10-24 20:46:53 hmm 2019-10-24 20:46:56 yeah, good point 2019-10-24 20:46:57 <_ikke_> but you still need to make sure it exists on the target system 2019-10-24 20:47:22 Wel... I guess that what preinst for, right? 2019-10-24 20:47:33 <_ikke_> correct 2019-10-24 20:48:01 community/racktables just relies on php 2019-10-24 20:49:30 Is that a good idea? 2019-10-24 20:50:56 Well... or it does not rely on anything at all 2019-10-24 20:51:15 <_ikke_> you mean depend? 2019-10-24 20:51:19 <_ikke_> https://git.alpinelinux.org/aports/tree/community/racktables/APKBUILD 2019-10-24 20:51:41 No, I mean it does not create www-data group itself 2019-10-24 20:51:51 So it either expects php to do it 2019-10-24 20:52:46 Or I dunno 2019-10-24 20:53:04 It ships a file without a group I guess 2019-10-24 20:53:18 Just with group-id 82 2019-10-24 20:55:39 Yep 2019-10-24 20:55:45 It's what it does 2019-10-24 20:55:59 # ls -ld /etc/racktables/ 2019-10-24 20:55:59 drwxrwx--- 2 root 82 4096 Oct 24 23:55 /etc/racktables/ 2019-10-24 20:56:19 <_ikke_> I think the tar file does have the www-data group 2019-10-24 20:56:33 I just installed racktables on semi-clean system 2019-10-24 20:56:37 <_ikke_> yeah 2019-10-24 20:56:43 It's 82 pretty much 2019-10-24 20:56:47 <_ikke_> So it just relies on you installing a webserver as well 2019-10-24 20:56:57 Yeah 2019-10-24 20:57:04 <_ikke_> Yeah, because it's a well-known group, it can just use that 2019-10-24 20:57:07 gogs and other packages create the group itself 2019-10-24 20:57:13 with the same id 2019-10-24 20:57:35 <_ikke_> not sure if you should have to repeat that with every package though 2019-10-24 20:57:54 Gentoo uses nice approach these days 2019-10-24 20:58:20 acct-group/ 2019-10-24 20:58:24 With fixed gid/uid 2019-10-24 20:59:35 anyway, seems like www-data it is 2019-10-25 01:39:12 *continued from #alpine-linux. I just updated mergerfs and the package I built is fine, but the one in the repo is now giving me a missing symbol error 2019-10-25 01:39:25 I'm not sure why there would be this discrepency 2019-10-25 02:02:19 good morning everyone 2019-10-25 02:53:39 ncopa: got MRs related to CVEs in aspell, nmap and unbound 2019-10-25 02:53:49 Danct12: morning (23:53 here) 2019-10-25 02:55:33 heh, it's 9:55 here 2019-10-25 02:55:56 and now im sitting and chatting on a frickin' phone running alpine linux 2019-10-25 02:56:06 no it's not postmarketos so dont say it is 2019-10-25 06:21:27 Danct12[m]: which phone? 2019-10-25 06:21:41 redmi 4x :) 2019-10-25 06:21:53 alpine's running inside a chroot 2019-10-25 06:22:26 chroot only? not native 2019-10-25 06:22:49 i'd love to run it native if there's a way i could get mobile data 2019-10-25 06:24:19 isn't wifi enough for phone :) 2019-10-25 06:24:35 public wifis are gay 2019-10-25 06:27:44 I'm only interested in phone on which I could run alpine native 2019-10-25 06:28:14 does postmarketos counts as alpine native 2019-10-25 06:28:34 to some degree, but not quite 2019-10-25 06:29:33 This is the best quote ever of the day 2019-10-25 06:30:38 yeah because i just ran into this wifi which wants my full name and phone number 2019-10-25 06:31:02 which i'd rather kms other than giving back my information D:< 2019-10-25 06:31:13 Just make up a fake name and phone number 2019-10-25 06:31:39 asriel: would you mind to explain to non native speakers who do not know fine points of English, and slang 2019-10-25 06:32:45 I'm not a native speaker. :P 2019-10-25 06:33:24 ok, np then 2019-10-25 06:33:35 I don't think you're supposed to use "giving back" for this 2019-10-25 06:33:52 Dan: the worst thing is public wifis wanting you to login with some social network 2019-10-25 06:34:44 So basically you're screwed if you're a FOSS chad and uses Fosstodon as the only social network? 2019-10-25 06:35:13 i never ran into those kinds of wifi before anyway 2019-10-25 06:35:19 just this one which asks for my name and phone number 2019-10-25 06:35:36 also they use mikrotik 2019-10-25 06:36:51 Still better than the kind of Wi-Fi that Cogitri mentioned 2019-10-25 06:37:39 And even if I'm logged in, still can't trust it. πŸ˜‰ 2019-10-25 06:38:19 Yup, it really sucks :c 2019-10-25 06:39:19 this channel is sponsored by nordvp- oh wait wrong channel 2019-10-25 06:39:44 Yeah I don't think anyone would use NordVPN after the hack 2019-10-25 06:40:38 I mean if the hack thing died down in a few days or months, probably people will forget about it and use it just like others 2019-10-25 06:41:19 Or just host your own VPN on your home computer, that also helps 2019-10-25 06:41:51 0$ VPN ;-) 2019-10-25 06:41:53 (electricity bill aren't included) 2019-10-25 06:53:50 (and hardware and maintenance :P) 2019-10-25 06:54:36 Doing system maintenance is fun 2019-10-25 06:55:20 But not if the hardware breaks.. :\ 2019-10-25 06:56:11 Just in case if you're unaware, I'm a sysadmin and.. 2019-10-25 06:56:23 Actually we did ran into a hardware problem before 2019-10-25 06:57:49 And it was a faulty motherboard, but thankfully HP Care Pack actually did took care of it 2019-10-25 06:57:53 So yeah.. sometimes bad things happens 2019-10-25 07:02:15 didn't linus torvalds sucks at system maintenance? 2019-10-25 07:02:18 he said it in a talk 2019-10-25 09:00:27 ncopa: got MRs for fixing security issues in aspell, nmap and unboudn 2019-10-25 09:49:33 saintdev: if mergefs is mailfunctioning could you file a bug for it https://gitlab.alpinelinux.org/alpine/aports/issues ? 2019-10-25 09:51:38 maxice8: why did you close https://github.com/alpinelinux/aports/pull/11393 ? as far as I can tell it wasn't merged yet 2019-10-25 09:53:44 nmeum: I don't use github for Alpine anymore 2019-10-25 09:54:17 i have no capacity (i mean will here, i can very well answer an email from github) to answer requests and questions 2019-10-25 09:54:18 gitlab.a.o is being used fully now 2019-10-25 09:55:20 right, I just went through old github PRs 2019-10-25 09:55:33 I will merge the upgrade with a minor change then 2019-10-25 09:56:13 in any case we support too many ways to submit patches :S 2019-10-25 10:03:00 ddevault: anything from the ~aports patches that should be merged ? just merged qutebrowser 2019-10-25 10:33:26 maxice8: if you are github.com/alpinelinux 2019-10-25 10:33:29 oops 2019-10-25 10:33:51 yes ? 2019-10-25 10:34:09 maxice8: if you are interested in discussing the github sitution further: I just suggested stopping support for github PRs on the ML https://lists.alpinelinux.org/~alpine/devel/%3C3OHWOOASIXH2T.20R4V2YVU7P8Y%408pit.net%3E 2019-10-25 10:34:17 (sorry hit enter too soon) 2019-10-25 10:38:36 we have already discussed to do that recently 2019-10-25 10:39:10 great 2019-10-25 10:39:38 in the irc? haven't read the entire backlog the last few days 2019-10-25 10:40:01 <_ikke_> not extensively, just mentioned it 2019-10-25 10:40:05 its not a real discussion, just me making noise 2019-10-25 10:40:17 like usual 2019-10-25 10:40:58 ah 2019-10-25 10:41:13 in case there is need to discuss this further the ml thread is probably the right place to do so 2019-10-25 10:41:41 sure lets wait if ppl have concerns 2019-10-25 10:42:27 <_ikke_> Should probably open an issue on gitlab? 2019-10-25 10:44:09 idk, i think it's better discussed on the ml on gitlab you only reach those who already have an account 2019-10-25 10:44:40 <_ikke_> I don't get the feeling that the mailing list gets a lot of feedback either 2019-10-25 10:45:03 ml is good 2019-10-25 10:45:56 most important is that gitlab is stable 2019-10-25 10:46:10 <_ikke_> performance improved a lot 2019-10-25 10:46:12 and im not 100% sure yet. 2019-10-25 10:46:26 maxice8: reminds me i didnt have time to check that log 2019-10-25 10:46:35 im kind of busy with getting payed 2019-10-25 10:46:43 <_ikke_> :) 2019-10-25 10:47:02 _ikke_: if you want, please check the api logs for the time he mentioend 2019-10-25 10:47:15 regarding 500 error 2019-10-25 10:47:25 maybe maxice8 can provide his origin ip 2019-10-25 10:47:58 we could really need some help in our infra team 2019-10-25 10:48:40 <_ikke_> where do I find the API logs? 2019-10-25 10:49:15 <_ikke_> nginx access log? 2019-10-25 11:02:13 nmeum: not on new ML, imho (please do not ask why, don't like yet another flame war) 2019-10-25 11:47:53 _ikke_: new runner is up https://imgur.com/a/iuOtqkZ 2019-10-25 11:48:46 this one will eat intel for breakfast :) 2019-10-25 11:49:28 too bad i dont have 3200Mhz memory 2019-10-25 11:49:31 clandmeter: i'm getting a machine with two of that :) 2019-10-25 11:49:51 tarzeau: nice 2019-10-25 11:50:00 and a machine nvtop with 8 gpus is also fun 2019-10-25 11:50:26 i guess not as a desktop :) 2019-10-25 11:51:04 no graphics output :) and way too noisy, but setup like a desktop (same config) 2019-10-25 11:51:15 so feel free to run x sessions remotely 2019-10-25 11:51:32 8gpu in 2u? 2019-10-25 11:51:48 4u, let me look it up 2019-10-25 11:51:55 thats no fun 2019-10-25 11:52:09 we do 8gpu in 2u :p 2019-10-25 11:52:24 indeed 2u 2019-10-25 11:52:26 we also 2019-10-25 11:52:34 who is we? 2019-10-25 11:52:42 eth zurich, d-phys 2019-10-25 11:52:55 nice 2019-10-25 11:52:59 its gbt? 2019-10-25 11:53:06 what's gbt? 2019-10-25 11:53:10 gigabyte 2019-10-25 11:53:32 i think we are the only one doing 8gpu in 2u 2019-10-25 11:53:38 GIGABYTE R09 06/23/2018 2019-10-25 11:53:57 ours is called spaceml4, so there 3 more at eth zurich other department 2019-10-25 11:54:22 yeah i know 2019-10-25 11:54:26 and we plan to get more... 2 gpu possible with amd epyc, up to 10 with intel (not sure on the 2u or not) 2019-10-25 11:54:42 so the world is small :) 2019-10-25 11:54:44 titan xp, 11 gb mem? 2019-10-25 11:54:48 where are you? 2019-10-25 11:55:00 pytorch and tensorflow? nvcc also? 2019-10-25 11:55:04 gigabyte 2019-10-25 11:55:37 have it since 2017/09 2019-10-25 11:55:45 we do hardware 2019-10-25 11:56:27 for top500 clusters? 2019-10-25 11:56:44 you dont know gigabyte? 2019-10-25 11:56:52 gigabyte.com 2019-10-25 11:56:55 yeah it's a multitude of megabyte 2019-10-25 11:57:01 (j/k, sure know the company yes) 2019-10-25 11:57:33 i guess we move this to offtopic 2019-10-25 12:23:21 maxice8: not afaik, thanks! 2019-10-25 13:30:27 fcolista: ping? 2019-10-25 13:52:53 nmeum, echo-reply 2019-10-25 13:53:59 <_ikke_> ppc64le builder is back 2019-10-25 13:54:02 fcolista: you are maintaining the openconnect package which currently doesn't seem to work due to an issue with vpnc (see https://github.com/alpinelinux/aports/pull/11961) 2019-10-25 13:54:15 there are two solutions to this issue https://github.com/alpinelinux/aports/pull/11961 and https://github.com/alpinelinux/aports/pull/11960 which do you prefer? 2019-10-25 13:55:50 nmeum, first of all 2019-10-25 13:55:53 thanks for sharing. 2019-10-25 13:56:24 I don't use openconnect, so I would go with 11960 (which is what the other distro does), if you agree. 2019-10-25 14:00:58 ok, sounds good to me 2019-10-25 14:01:00 will merge it then 2019-10-25 14:21:29 anyone have time to push !753 2019-10-25 14:21:52 need in repos to push new iwd 2019-10-25 14:22:07 s/need/need it/ 2019-10-25 14:22:07 mps meant to say: need it in repos to push new iwd 2019-10-25 14:22:36 Can't both be done in a single MR ? 2019-10-25 14:24:30 well, iwd require ell to be upgraded first, or I don't understand you 2019-10-25 14:25:03 and I can push iwd in community and don't want to bother someone else with it 2019-10-25 14:25:29 I can push the ell upgrade in a sec 2019-10-25 14:25:55 nmeum: thanks, you can see it pass CI 2019-10-25 14:25:56 if you upgrade iwd afterwards make sure to add something along the lines of depends="ell>=0.25" 2019-10-25 14:26:07 oh 2019-10-25 14:26:09 i tought iwd was in main 2019-10-25 14:26:23 nmeum: :D up for mass-merging stuff to main/ ? 2019-10-25 14:26:45 which stuff? 2019-10-25 14:27:21 https://gitlab.alpinelinux.org/alpine/aports/merge_requests?scope=all&utf8=βœ“&state=opened&author_username=Leo&search=main%2F :D 2019-10-25 14:27:25 nmeum: iwd and ell versions are related (and released together) 2019-10-25 14:27:50 maxice8: that's a lot of stuff :) 2019-10-25 14:27:53 I will look into a few of them 2019-10-25 14:28:07 but, your advice for iwd depends sounds reasonable 2019-10-25 14:28:49 mps: sure but if you upgrade them separatly you might get the new iwd but not the new ell version unless you add depend on a specific ell version in iwd 2019-10-25 14:28:53 nmeum: it ends up pilling up like that 2019-10-25 14:29:00 ty :D 2019-10-25 14:31:15 yes, because that I always ask someone to push ell, and after it is in repos I then push iwd 2019-10-25 14:32:04 mps: pushed the ell upgrade, remove the "new upstream release" part from the commit messages as this seemed obvious 2019-10-25 14:32:48 ok, also I have doubt about these and similar lines 2019-10-25 14:32:49 mps: it doesn't make a difference when the upgrade is pushed 2019-10-25 14:33:46 but some core devs asked for such lines 2019-10-25 14:34:23 consider a scenario where I have ell 0.24 installed but not iwd and then install iwd using `apk add iwd` getting the new iwd version (you haven't pushed yet) but not the new ell version therby ending up with an incompatible ell version for iwd 2019-10-25 14:34:49 if you add depends="ell>=0.25" to iwd it will upgrade ell before installing iwd 2019-10-25 14:35:10 s/it/apk/ 2019-10-25 14:35:10 nmeum meant to say: if you add depends="ell>=0.25" to iwd apk will upgrade ell before installing iwd 2019-10-25 14:35:34 ok, will add it 2019-10-25 14:36:42 great :) 2019-10-25 14:36:52 I will look into some of maxice8's MRs then 2019-10-25 14:36:52 btw, can we have '=' in depends, for example depends="ell=0.25" 2019-10-25 14:37:33 idk, probably have to read the abuild/apk source code to figure that out or look at existing APKBUILDs 2019-10-25 14:37:39 and, thanks 2019-10-25 14:37:42 I don't think i have seen that yet 2019-10-25 14:43:32 what's the prefered workflow for merging GitLab MRs? 2019-10-25 14:43:56 on github merged PRs were autoclosed by algibot but we don't seem to have an aquivalent for gitlab, right? 2019-10-25 14:44:28 mps: use ell~$ver 2019-10-25 14:44:32 nmeum: Push to g.a.o and close 2019-10-25 14:44:32 Not optimal but works for now until we have some fancy autoclose bot like on GitHub I guess 2019-10-25 14:45:58 Cogitri: thanks 2019-10-25 14:46:01 nmeum: No, i use my own script called mgmr 2019-10-25 14:48:06 I don't think I have suffcient access rights to close other peoples MRs 2019-10-25 14:48:30 could probably close through the commit messages though 2019-10-25 14:48:35 nmeum: if anything you don't need to close, i delete the branch as soon as i notice it is merged 2019-10-25 14:48:44 and that will make gitlab close it automatically 2019-10-25 14:48:45 :D 2019-10-25 14:48:56 sure, but not everyone does that 2019-10-25 14:49:01 There is just the risk of missing it 2019-10-25 14:49:14 maxice8: nice trick :) 2019-10-25 14:49:15 how does your mgmr script close the MRs? 2019-10-25 14:50:29 calls close-mr which is another script that uses the gitlab v4 api 2019-10-25 14:51:00 https://github.com/maxice8/meltryllis/blob/master/bin/close-mr 2019-10-25 14:51:23 it requires some setup by the user 2019-10-25 14:51:45 it also uses the Freedesktop Secrets API to get your access token 2019-10-25 14:52:18 I think 'lab' also can close MR 2019-10-25 14:52:55 <_ikke_> I just type in /close in the comments field :) 2019-10-25 14:53:07 how does that work? 2019-10-25 14:53:18 <_ikke_> gitlab supports commands in the comments field 2019-10-25 14:53:38 <_ikke_> /label and /close are the ones I use the most 2019-10-25 14:53:39 but that only works if you have sufficient privileges to close the issue in the first place, right? 2019-10-25 14:53:43 <_ikke_> correct 2019-10-25 14:53:51 could you just elevate my privileges then? 2019-10-25 14:54:00 <_ikke_> nmeum: Yes, I think we can do that 2019-10-25 14:54:22 thanks 2019-10-25 14:55:01 <_ikke_> done 2019-10-25 14:55:06 iirc I have push access to all repos, not sure what your permission module is but imho you could just add me to the alpine gitlab organization 2019-10-25 14:55:07 thanks 2019-10-25 14:55:27 <_ikke_> for now I just added you as developer to aports 2019-10-25 14:55:27 *model 2019-10-25 14:56:39 ok, I guess that works as well for now. thanks 2019-10-25 14:57:17 <_ikke_> We haven't decided yet how we will implement it 2019-10-25 14:58:25 probably also something that should be decided before we deprecate github entirely 2019-10-25 14:58:38 <_ikke_> yes 2019-10-25 14:58:42 and imho something like github algibot for gitlab would really be nice as well 2019-10-25 15:25:58 @ncopa you were talking about mysql 2019-10-25 15:26:03 i found this quite old thing on pr10651 2019-10-25 15:27:07 nice 2019-10-25 15:29:30 maxice8: are you okay with the following addition to your check upgrade https://tpaste.us/dEaJ ? 2019-10-25 15:29:38 noticed while reviewing the PR that documentation files were no longer installed 2019-10-25 15:30:17 oh, yes please 2019-10-25 15:30:34 I guess I should also upstream this patch 2019-10-25 15:31:03 I just don't get why they check for the tex command instead of makeinfo, it doesn't make sense 2019-10-25 15:34:38 pushed 2019-10-25 15:46:05 its weekend for me now. have a nice wekend everyone 2019-10-25 16:57:23 <_ikke_> o/ 2019-10-25 17:23:18 Could someone with access to main take a look at pr11934 please? :) 2019-10-25 17:27:52 <_ikke_> ok 2019-10-25 17:28:22 Thank you 2019-10-25 17:38:18 <_ikke_> pushed 2019-10-25 18:14:55 πŸ‘ 2019-10-25 19:45:11 is the aarch64 builder stuck? 2019-10-25 19:45:45 <_ikke_> again? 2019-10-25 19:46:09 it stays to long on openjfx11 11.0.4_p1-r0 2019-10-25 19:46:18 Yes, openjfx again 2019-10-25 19:46:26 Could you disable it on aarch64 please? 2019-10-25 19:46:41 Cogitri: what is issue 2019-10-25 19:47:10 Build fails and gradle doesn't shut down so the build doesn't exit 2019-10-25 19:47:39 ahm 2019-10-25 19:48:04 who of us should disable it? 2019-10-25 19:48:38 I'm currently not on my laptop, so not me 2019-10-25 19:49:23 <_ikke_> I can 2019-10-25 19:49:33 ok, I will 2019-10-25 19:49:47 _ikke_: then do please 2019-10-25 19:50:39 I'll try to build it on aarch64 in meantime 2019-10-25 20:26:11 openjfx11 also stuck in lxc on aarch64 2019-10-25 20:26:52 <_ikke_> You mean when you manually built it? 2019-10-25 20:28:44 yes 2019-10-25 20:29:07 <_ikke_> iyk 2019-10-25 20:29:11 <_ikke_> ok* 2019-10-25 20:29:36 I didn't investigated deep, but gradle is stuck 2019-10-25 20:30:35 <_ikke_> That's what I saw as well 2019-10-25 20:30:43 Yup 2019-10-25 20:31:25 <_ikke_> Well, not necessarily gradle, just some processes it ran 2019-10-25 20:31:39 Huh, I think it worked on CI 2019-10-25 22:20:11 Hi. Any chance of getting Andy's PHP 7.3.11 update into the 3.10 branch? 2019-10-26 06:07:29 <_ikke_> aragon: yeah, it should be backported 2019-10-26 06:22:05 <_ikke_> aragon: I pushed the fix for 3.10 stable 2019-10-26 06:29:39 <_ikke_> aragon: All backports have been pushed now. Thanks 2019-10-26 14:38:13 been reading the governance email (cc ncopa) 2019-10-26 14:38:41 one thought is that it would be easy to expand the core team's bandwidth with the use of a git hook which allows anyone to push commits to update packages for which they are the maintainer 2019-10-26 14:38:47 <5 lines of shell script, I imagine 2019-10-26 14:38:58 eh, <10 2019-10-26 14:39:34 then the core team's bandwidth contraints are described by maintainership edits, new packages, etc; but not by every single change to aports 2019-10-26 14:41:06 <_ikke_> Not sure if 5 lines of shell script would be enough 2019-10-26 14:42:00 <_ikke_> But at least it gives more meaning to what it means to be a maintainer 2019-10-26 14:42:25 for pkg in git diff $1 $2; do maintainer=$(head -n1 <"$pkg" | cut -d: -f2-); if $SSH_PUSHER -ne $maintainer; then exit 1; ... 2019-10-26 14:43:08 git diff --names-only * 2019-10-26 14:43:35 <_ikke_> You would need to make sure you look at the original file, not the changed file 2019-10-26 14:43:48 <_ikke_> and probably a mapping from ssh identity to maintainer 2019-10-26 14:44:57 replace <"$pkg" with git show $1:$pkg | 2019-10-26 14:45:05 these issues are where the correction from <5 becomes <10 :) 2019-10-26 14:45:21 ${1}^ rather 2019-10-26 15:38:45 I think the aport maintainer role needs some rethinking in general 2019-10-26 15:39:16 even if packages have a maintainer comment they are often poorly maintained and not update 2019-10-26 15:39:27 *updated 2019-10-26 15:40:02 and many packages in main/ and community/ don't even have a mantainer comment 2019-10-26 15:41:01 there are also package mantainers which haven't commmitted any changes at all in the past years 2019-10-26 15:42:35 for me all those contributors/maintainers informations are kind of useless, especially in APKBUILD file, isnt enough to just look at history of commits? 2019-10-26 15:43:57 or dunno, add info with link in APKBUILD to for example: https://gitlab.alpinelinux.org/alpine/aports/commits/master/main/abuild 2019-10-26 15:45:26 well the mantainer comment should ideally identify a person which can be contacted regarding issue with the aports and makes sure that it is always update to date, reviews patches, etc. the usefulness of the contributor comment is certainly debatable 2019-10-26 15:49:20 so maybe some trigger if somebody open a issue with "main/abuild" in title then automaticly everyone who done some commit in to that package in past 6 months will be notificated 2019-10-26 15:56:24 ACTION just thinking at loud, sorry for noise, please debate! 2019-10-26 16:11:48 I think this is better debated on the ML tbh 2019-10-26 16:15:48 ddevault: if you send a reply to the governance mail we can discuss this further on the ML 2019-10-26 16:15:56 ack 2019-10-26 19:50:16 <_ikke_> Anyone got a clue why on some arches it seems to still use busybox cpio, even though I have cpio as a dependency? https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/apenwarr-redo/apenwarr-redo-0.42-r0.log 2019-10-26 19:52:28 does the cpio package install the cpio binary to the same path used by the busybox cpio binary? 2019-10-26 19:52:43 e.g. if the package uses /usr/bin/cpio but busybox provides /bin/cpio it's not properly overwritten 2019-10-26 19:53:18 but this should happen on all arches then 2019-10-26 19:53:22 <_ikke_> yes 2019-10-26 19:53:28 <_ikke_> the packages just calls cpio 2019-10-26 19:53:46 <_ikke_> and I verified that both busybox cpio as the cpio package uses the same path 2019-10-26 19:56:11 hm, in that case I would probably try to use strace(1) with the appropriate flags (-f, …) to figure out why/how it calls busybox cpio 2019-10-26 19:57:41 <_ikke_> let's see if I can replicate it 2019-10-26 20:01:32 _ikke_: testing it 2019-10-26 20:02:28 <_ikke_> mps: ok, thanks 2019-10-26 20:03:11 passed ok on my aarch64 lxc 2019-10-26 20:03:36 as it is in aports, i.e. cpio in checkepends 2019-10-26 20:03:55 <_ikke_> :( 2019-10-26 20:04:39 builder issue 2019-10-26 20:27:29 <_ikke_> that's anoying :( 2019-10-26 20:28:46 <_ikke_> It didn't fail on CI as well 2019-10-26 20:33:58 did you check if the busybox cpio binary was overwritten on the builder as well? you have access to the builder, don't you? 2019-10-26 20:39:31 <_ikke_> nmeum: yes, I do, and I did check it :) 2019-10-26 20:40:08 hm, that's strange then 2019-10-26 20:40:28 have you tried strace on the builder? 2019-10-26 20:41:25 <_ikke_> not yet 2019-10-26 20:41:37 if the busybox cpio symlink is overwritten the only way to call busybox cpio would be through 'busybox cpio' 2019-10-26 20:44:00 <_ikke_> I can run the same command that the package does after I install cpio on the builder 2019-10-26 20:44:14 <_ikke_> and after I remove it, I get the same error message 2019-10-26 20:48:29 <_ikke_> and ofcourse when I build it by hand (abuild -r), it just works :-/ 2019-10-26 20:49:27 really sounds like an annoying issue 2019-10-26 20:51:33 <_ikke_> yup 2019-10-26 21:29:26 anyone know how to disable gcc to look for include files in /usr/include 2019-10-26 21:29:37 in APKBUILD, I mean 2019-10-26 21:30:08 Why would you do that? 2019-10-26 21:30:15 But I guess -isystem can do (break) that 2019-10-26 21:31:04 conflict in defined types for uboot-tools 2019-10-26 21:31:48 it have internal include dir 2019-10-26 21:36:33 Fixing it properly sounds way better than not including /usr/include... 2019-10-26 21:37:46 patch will be big 2019-10-26 21:38:56 and I suspect upstream will accept criticism of using glibc-isms 2019-10-26 22:05:46 _ikke_: Amazing. Smooth upgrade. Thank you and Andy! :) 2019-10-27 01:54:23 if I want to make a couple backport builds from edge/testing for 3.10, can I use git master on a 3.10 system, or would I need to be in the older tree? 2019-10-27 02:36:33 oh, didn't realize the stable branches have testing also 2019-10-27 10:50:05 <_ikke_> bobertlo: yes, as these branches are branched of from master, they just inherit all the packages, but they are not built, nor upgraded on stable branches 2019-10-27 10:59:35 <_ikke_> I'm curious how replaces and provides interect with eachother between different packages 2019-10-27 10:59:59 <_ikke_> for example, package A has provides=X, package B has replaces=X 2019-10-27 11:37:16 _ikke_: not sure but B should replace A. Right? 2019-10-27 13:22:23 <_ikke_> mps: ping 2019-10-27 13:30:09 _ikke_: pong 2019-10-27 13:31:39 <_ikke_> mps: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/565/diffs is the commented out source line on purpose? 2019-10-27 13:32:52 uh, probably forgot to remove it, sorry 2019-10-27 13:33:13 <_ikke_> np 2019-10-27 13:33:17 <_ikke_> I can drop it when applying 2019-10-27 13:33:22 <_ikke_> Just wanted to be sure 2019-10-27 13:34:28 ok, or I can do it later when I finish with my dual monitor setup on my main workstation. I'm now on 'moving computer' 2019-10-27 13:35:23 <_ikke_> I'm applying it now 2019-10-27 13:36:45 ok, thanks 2019-10-27 14:18:29 are we still cd'ing into builddir in main 2019-10-27 14:22:20 Yes as far as I remember 2019-10-27 14:22:24 ddevault: I think yes 2019-10-27 14:22:38 also, isn't abuild supposed to do the thing for you if you make a subpackage named -static 2019-10-27 14:23:06 sometimes yes, but sometimes no 2019-10-27 14:23:35 depends on upstream 'install' 2019-10-27 14:27:36 oh, it's order-dependent 2019-10-27 14:27:40 you have to put -static first in the list of subpackages 2019-10-27 14:27:52 fails principle of least surprise 2019-10-27 14:34:46 and static libs should go in -dev 2019-10-27 14:46:53 ddevault: yes the check was broken so it needs to be before -dev 2019-10-27 14:47:04 mps: +1 2019-10-27 15:25:07 ddevault: is it intended that an author isn't disabled for the comments at https://lists.alpinelinux.org/~alpine/aports/patches/3107 ? 2019-10-27 15:25:28 what? 2019-10-27 15:25:30 hey guys, I tried to post something to ~alpine/devel@lists.alpinelinux.org, but I failed. What can I do? 2019-10-27 15:25:48 xrs: let's take it to #alpine-infra 2019-10-27 15:26:02 ddevault: it doesn't say who wrote the mail, do I need an account for that? 2019-10-27 15:26:13 your From header doesn't have a name 2019-10-27 15:26:17 you need to configure your email cilent properly :) 2019-10-27 15:26:35 ah 2019-10-27 15:27:00 why not display the mail address as a fallback? 2019-10-27 15:27:05 it does? 2019-10-27 15:27:14 oh, only if you're logged in 2019-10-27 15:27:26 if you're logged out it hides email addresses to prevent scraping by spammers 2019-10-27 15:27:51 ok, good to know 2019-10-27 15:31:36 ddevault: regarding the new version of that patch, I would honestly stick to makedepends_build / makedepends_host. libedit needs to crosscompile properly as it's used by openssh 2019-10-27 15:31:45 bah 2019-10-27 15:38:24 applied, thanks 2019-10-27 15:38:54 btw: I noticed that https://lists.alpinelinux.org/~alpine/aports/patches/3109.patch causes a 500, should probably be a 404 2019-10-27 15:39:00 and yes, I am aware that the right url is /mbox 2019-10-27 15:40:06 can you ticket it out: https://todo.sr.ht/~sircmpwn/lists.sr.ht 2019-10-27 15:40:14 or shoot email to ~sircmpwn/lists.sr.ht@todo.sr.ht if you don't have a sr.ht account 2019-10-27 15:40:31 sure, will do the latter 2019-10-27 15:44:23 thanks nmeum 2019-10-27 15:44:32 became https://todo.sr.ht/~sircmpwn/lists.sr.ht/131 2019-10-27 15:45:02 thanks for the new mailinglist software stack, it's really superior to the old one :) 2019-10-27 15:45:07 :) 2019-10-27 16:17:34 already archived the email, forgive me for bringing it up here first 2019-10-27 16:17:42 but what about introducing a new aports contributor role 2019-10-27 16:17:51 for people who have been vetted as producing decent enough patches for their ports 2019-10-27 16:18:05 and giving this group access to push changes affecting their packages 2019-10-27 16:21:00 not sure, at some points this ends up being a trust issue could also imagine this being hard to manage if we have lots of people with access to a few aports 2019-10-27 16:22:31 besides: if we trust a person to maintain a single aport, why not trust them with maintaining other (less important) aports as well? 2019-10-27 16:22:40 i think that was the entire idea behind the community / testing split 2019-10-27 16:22:52 to give people with less experience access to the repo 2019-10-27 16:23:00 did that ever materialize? 2019-10-27 16:23:15 anyway, I retract the idea, if it's contentious then it's not worth the effort to achieve consensus 2019-10-27 16:24:30 <_ikke_> yes, more people have access to community / testing than to main 2019-10-27 16:24:48 but less so community vs testing 2019-10-27 16:25:01 \o/ 2019-10-27 16:26:20 <_ikke_> I'm not sure if it makes sense to split that up 2019-10-27 16:26:34 testing comes with no expectation of workituded 2019-10-27 16:26:37 workitude* 2019-10-27 16:26:39 community does 2019-10-27 16:27:16 <_ikke_> sure, but that says something about the package, not the one pushing the package 2019-10-27 16:27:37 <_ikke_> ie, a package should move quickly to community if possible 2019-10-27 16:27:39 nah 2019-10-27 16:27:56 <_ikke_> If people have access to testing but not community, they might want to keep a package in testing 2019-10-27 16:27:56 a pusher who has access to testing isn't expected to produce packages with a guarantee of workitude 2019-10-27 16:28:07 it's useful for incubating contributors 2019-10-27 16:28:10 in theroy 2019-10-27 16:28:12 theory* 2019-10-27 16:32:04 <_ikke_> So for a single package maintainer, it makes less sense, but for someone contributing to aports in general, it would make more sense 2019-10-27 16:58:22 I'm wondering, why was Mesa upgraded to 19.2.x? I thought even releases are not as stable and we were trying to stay on uneven releases (e.g. 19.1.x)? 2019-10-27 16:59:43 PureTryOut[m]: not stable? 2019-10-27 17:00:28 19.2.1 is latest stable 2019-10-27 17:00:42 <_ikke_> What about 19.2.2? 2019-10-27 17:00:52 19.x.0 is a development that it is to be avoided, 19.x.1 and above is stable 2019-10-27 17:01:02 Oh it was the point releases, nvm 2019-10-27 17:01:04 You're problably confusing GNOME and mesa versionig 2019-10-27 17:01:06 No never mind 2019-10-27 17:01:06 x.UNEVEN on GNOME is a development branch 2019-10-27 17:01:06 and x.EVEN is stable 2019-10-27 17:01:33 It's just that Mesa currently causes annoying artifacts on Plasma Mobile on pmOS, and I'm looking for something to blame 2019-10-27 17:01:39 <_ikke_> hehe 2019-10-27 17:07:34 regarding push access to aports, I would like that we have some kind of check and verification of the real identity for anyone who have push access 2019-10-27 17:08:54 I mean to main and community, not sure about testing 2019-10-27 17:10:31 <_ikke_> mps: Doesn't your ssh key verify your identity? Or are you referring to the commits you are pushing? 2019-10-27 17:13:06 I got access without meet (in real world) any of the core developers, so how anyone of you know that I'm really who I say I'm 2019-10-27 17:13:53 (well, one of core team member know me by some real facts but this is not much relevant) 2019-10-27 17:16:24 note that I don't want to say that people who don't show their real names are less trusted 2019-10-27 17:16:43 <_ikke_> right, I'm not sure how much a real identity brings to the table 2019-10-27 17:18:01 true, even if we know real identity it can't be sign of the good intentions 2019-10-27 17:18:14 <_ikke_> You ssh key is our trust anchor 2019-10-27 17:19:25 you know, in this world a lot of strange things happens, especially in OS development 2019-10-27 17:19:47 <_ikke_> yes, but that has little to do with having verified at one point who mps is 2019-10-27 17:20:14 <_ikke_> even though we verified it at one point, your key can be compromised for some reason 2019-10-27 17:20:36 ofc, I understand these issue, I worked in computer security field for some time 2019-10-27 17:20:42 <_ikke_> nod 2019-10-27 17:22:02 you remember Steve Belowin's old saying 'Yes, I'm paranoid, but am I paranoid enough' 2019-10-27 17:22:44 <_ikke_> In my mind, verifying a real identity only matters if you know that identity in the first place 2019-10-27 17:22:54 <_ikke_> if it's a random person, it does not add a lot 2019-10-27 17:23:44 <_ikke_> If I knew you in real life, and trust you because of it, it makes a lot of sense that I verify that the mps I talk to here is the mps I know 2019-10-27 17:23:44 true, and at the end there is no silver bullet 2019-10-27 17:24:55 <_ikke_> What matters more is consistency 2019-10-27 17:25:09 <_ikke_> is the mps that we talk to at one point the same person at another point 2019-10-27 17:25:53 or is the mps bribed to spill something bad even if he is stil right person 2019-10-27 17:26:27 <_ikke_> right, but that's even more difficult to protect against 2019-10-27 17:26:32 <_ikke_> if not impossible 2019-10-27 17:26:40 <_ikke_> technology cannot certify intent 2019-10-27 17:26:41 and, 'mps' is anyone of devs 2019-10-27 17:27:36 imho everyone who got shell access to some servers/machines should be verified 2019-10-27 17:27:40 <_ikke_> That's why some parts of Alpine are only accessible by just a few persons 2019-10-27 17:28:21 all true what you say, but paranoid in me always talk to me about that is possible to happen something bad 2019-10-27 17:28:30 <_ikke_> MY-R: ok, now I know you're John Doe. Does that bring any security to the table? 2019-10-27 17:28:44 <_ikke_> (or Jane Doe for that matter) 2019-10-27 17:30:19 _ikke_, imagine you gave access to your server which you rent to for exmple mps :D and then police knock knock to your door 2019-10-27 17:30:42 <_ikke_> Ok, but that's talking about liability, not security 2019-10-27 17:30:51 actually, I'm more for trust which are proven, than to trust on real identity 2019-10-27 17:30:59 <_ikke_> mps: agreed 2019-10-27 17:31:17 <_ikke_> But what is the basis of this proof 2019-10-27 17:32:31 MY-R: that depends on particular country laws and not on access for particular person, afaik 2019-10-27 17:33:18 ye but somebody who wanna do some damage will think twice before do it in some dunno rage or whatever 2019-10-27 17:33:27 so is kind of about security too ... 2019-10-27 17:35:26 yes, "security is complex, isn't it" (Steve Belowin, again) 2019-10-27 17:35:33 :) 2019-10-27 17:38:06 ok, to conclude my moaning, I wouldn't like to wake up one morning and read on news that alpine have a backdoor 2019-10-27 17:38:18 <_ikke_> mps: that's something I worry about as well 2019-10-27 17:38:34 <_ikke_> But the attack surface is so large 2019-10-27 17:39:13 ofc, and even doesn't depend much of alpine devs 2019-10-27 17:39:43 <_ikke_> Maybe we should create a list of security practices to limit the chance of compromise 2019-10-27 17:40:03 <_ikke_> We already require gitlab 2fa for example 2019-10-27 17:41:40 yes, something as security practices and some rules would good to have 2019-10-27 17:42:22 but alpine doesn't have much man power for something like big distros have 2019-10-27 17:42:51 <_ikke_> On the other hand, if you are big, the requirements change as well 2019-10-27 17:43:27 we strive to be big, I hope :) 2019-10-27 17:43:42 <_ikke_> Sure, but you should start small ;) 2019-10-27 17:44:32 hehe, so we are at good starting point 2019-10-27 17:44:35 <_ikke_> Fosdem might be an opportunity to meet 2019-10-27 17:48:15 some people can't go there for different reasons 2019-10-27 17:48:21 <_ikke_> sure 2019-10-27 17:48:27 <_ikke_> It's more oportunistic 2019-10-27 17:48:57 does Alpine APKBUILD support multiple "source" of same file, something like fallback in case first link is broken etc? 2019-10-27 17:49:10 <_ikke_> no, there is no automatic fallback 2019-10-27 17:49:25 ah ok 2019-10-27 17:49:41 actually I would like to meet all of you in person, but I'm to lazy to travel 2019-10-27 17:50:49 I'll most likely be at FOSDEM 2019-10-27 18:38:10 linux 5.4-rc5 is released, time to test will it work on rk3399 chromebook :) 2019-10-27 19:39:21 BTW, are we going to upgrade to 5.4 on edge soon? 2019-10-27 19:45:45 new rc is released every week, so we can expect 5.4.0 in 4 weeks 2019-10-27 19:46:52 will we have it in next Alpine stable depends on ncopa 2019-10-27 19:47:21 and, I'm for that (to not forget to tell) 2019-10-27 19:48:14 <_ikke_> open a ticket I would say 2019-10-27 19:49:20 I thought to create MR with WIP status 2019-10-27 19:49:27 not sure is this ok 2019-10-27 20:49:39 filoozom: any progress on rpi4 thingie? 2019-10-28 13:01:03 mps: re 163ac6aeef12affd8b0296e5c491fa944f313d63 2019-10-28 13:01:22 seems like btrfs-progs does not build after that commit 2019-10-28 14:28:54 ncopa: ah, will look later, I'm on the meeting now 2019-10-28 16:43:21 are there any documented steps to create a cross-compilation environment for Alpine on ARM? I would like to package a new app for Alipine targetting ARM from my x86 box. I wonder how, for example, Docker does this: https://hub.docker.com/r/arm32v7/alpine/ (I don't want to use docker tho) 2019-10-28 16:43:55 IOW, is there a "buildroot for Alpine" :-) 2019-10-28 16:44:24 <_ikke_> ihavenohead: alpine itself only cross-compiles the bare necessary to get a toolchain going on native hardware\ 2019-10-28 16:44:36 <_ikke_> So there is no extensive cross-compile toolchain 2019-10-28 16:44:43 Crosscompiling doesn't really work on Alpine, we use native builders 2019-10-28 16:45:09 <_ikke_> I guess it would work on Alpine if the tools were there 2019-10-28 16:45:15 ..and qemu doesn't go well 2019-10-28 16:45:52 I have done LLVM toolchain that builds against aarch64 alpine 2019-10-28 16:45:54 Thanks for the heads-up, I would love to use a native builder, but the app in question is just too big to compile natively 2019-10-28 16:49:18 depending what you are building, copying sysroot from the target and using cross compiling toolchain will do 2019-10-28 16:49:59 <_ikke_> Alpine uses sponsered hardware to build everything natively 2019-10-28 16:50:08 <_ikke_> There is some 'beefy' arm hardware available 2019-10-28 16:50:51 <_ikke_> https://www.packet.com/cloud/servers/ 2019-10-28 16:51:26 <_ikke_> c1.large.arm costs $0.50 an hour 2019-10-28 16:51:35 <_ikke_> 96 cores, 128G ram 2019-10-28 16:51:37 artok: I think that's the approach I'll take. I've seen some folks using binfmt + docker to approach this problem, I'd rather not involve docker in my build process now for "reasons" 2019-10-28 16:52:42 _ikke_: that's an impressive machine to get for that price :-) Thanks for the pointer, never heard of packet before, this could be a workable option for me too! 2019-10-28 16:52:54 <_ikke_> They sponsor Alpine :) 2019-10-28 16:52:56 I've got docker because of my laptop is macOS 2019-10-28 16:53:17 What an awesome sponsor to have, nice! 2019-10-28 16:53:47 that's why https://github.com/djazo/arm-toolchain and https://github.com/djazo/sysrooter 2019-10-28 17:01:03 just use commands from sysrooter's setup.sh script and you can get your alpine sysroot 2019-10-28 17:01:41 alpine is good in the way that you can bootstrap packages into chroot without actually entering the sysroot 2019-10-28 17:01:50 hence, qemu is not needed 2019-10-28 17:04:49 apk.static --arch ${ARCH} -X ${MIRROR} -U --allow-untrusted --root ${ROOTPATH} --initdb add alpine-base linux-headers musl-dev libgcc gcc g++ ... 2019-10-28 17:05:39 you can add all -dev files that you need on the same command, and just have ARCH, MIRROR, ROOTPATH set 2019-10-28 17:05:48 artok: so basically, I create the sysroot by entering Docker and compile the packages that I can natively, and then use an arm toolchain and that sysroot to compile my big package for on the x86? 2019-10-28 17:07:15 that is docker based thing because of CI in mind. if running linux on x86, you can just get sysroot for alpine with that command I gave 2019-10-28 17:08:44 .. which you can ofcoz strip down little, sysroot just needs /lib /usr/lib /usr/include directories (and /usr/local/lib /usr/local/include ) 2019-10-28 17:09:29 if you're first building on some system, I recommend rsync copying those directories from your running system 2019-10-28 17:11:16 so you'll get the fresh, correct versions of all libraries that you have built on the target machine 2019-10-28 17:12:28 gotcha, thanks artok those are very helpful starting points for me πŸ‘ 2019-10-28 17:14:34 now only that you'll need the toolchain that will be able to target the system 2019-10-28 17:16:59 I've fallen in love with LLVM, but you can ofcoz build binutils + gcc 2019-10-28 17:19:00 https://github.com/djazo/avr-toolchain/blob/master/Dockerfile has that thingie (with addition of avr libc building) 2019-10-28 17:20:09 just put correct --target and other options for binutils and gcc configure commands 2019-10-28 17:30:14 example for cmake toolchain file : https://hastebin.com/ozuyacimih.bash that you can give -DCMAKE_TOOLCHAIN_FILE=/your/toolchain.cmake parameter 2019-10-28 17:33:02 now only problem for me is that we don't have alpine for rpi4 =D 2019-10-28 17:34:56 that needs native aarch64 builder 2019-10-28 17:39:39 ..or actually not necessarily, now that I think more 2019-10-28 17:47:20 ncopa: fixed docbook-xsl and created MR !892 2019-10-28 17:48:30 rebuild few packages with this fixed version, btrfs-progs, drbd-tools, libsecret, tdb, bubblewrap. all builds fine 2019-10-28 19:18:51 mps: Could you try building https://github.com/alpinelinux/aports/pull/11997 on armhf/v7 maybe? :) 2019-10-28 19:21:39 Cogitri: ofc, on armv7 2019-10-28 19:23:01 Thanks 2019-10-28 19:24:57 community/firefox-esr, I thought to try it later because I'm busy these days, but when you asked I will do now 2019-10-28 19:27:58 Ah, thanks, hope it doesn't cause too much trouble 2019-10-28 19:30:34 np, I started it and going to drink coffee, hope it will finish before I finish with coffee 2019-10-28 19:30:54 and it is my pleasure to help 2019-10-28 20:27:52 _ikke_: up for merging security stuff ? :D 2019-10-28 20:56:18 <_ikke_> maxice8: Hmm, I saw a fix for file on the mailing list as well 2019-10-28 20:56:26 <_ikke_> But it had issues 2019-10-28 20:57:37 <_ikke_> https://lists.alpinelinux.org/~alpine/aports/patches/3103 2019-10-28 21:01:34 <_ikke_> maxice8: is nmap in master not vulnerable to CVE-2018-15173 and CVE-2017-18594? 2019-10-28 21:07:13 Cogitri: failed, log is here http://arvanta.net/ff-esr.log.gz 2019-10-28 21:09:55 <_ikke_> maxice8: Ah, I see, it was already applied 2019-10-28 21:11:47 mps: thanks for trying 2019-10-28 21:13:55 np 2019-10-28 21:18:12 <_ikke_> maxice8: I wonder. The security issues was made confidential, but then the merge requests were all public 2019-10-28 21:35:08 good, linux-virt x86_64 5.4-rc5 works, but vanilla doesn't boot 2019-10-28 21:39:54 _ikke_: sadly I don't know how to use the gitlab v4 API to do confidential merge requests 2019-10-28 21:40:17 <_ikke_> maxice8: I don't think gitlab supports it 2019-10-28 21:40:36 <_ikke_> Their rational is that the commits themself would be public anyway 2019-10-28 21:41:08 what is the script that now makes installer packages? 2019-10-28 21:41:47 <_ikke_> installer packages? 2019-10-28 21:42:03 ones that you can download from the web 2019-10-28 21:42:51 <_ikke_> installer packages you can download from the web..? 2019-10-28 21:42:54 yeah 2019-10-28 21:43:05 <_ikke_> doesn't ring a bell 2019-10-28 21:43:22 alpine-iso is dead project so... 2019-10-28 21:43:39 <_ikke_> mkimage.sh? 2019-10-28 21:43:47 <_ikke_> https://git.alpinelinux.org/aports/tree/scripts/mkimage.sh 2019-10-28 21:44:05 ah it is in the aports tree, blind again 2019-10-28 21:44:48 I just managed to kind-of boot rpi4 aarch64 2019-10-28 21:58:56 _ikke_: Gitlab has an option to do confidential merge requests but not on its API 2019-10-28 22:46:21 <_ikke_> maxice8: ah ok 2019-10-29 09:51:24 _ikke_: thanks for nmap merge, answered the question on the file one 2019-10-29 09:51:51 <_ikke_> maxice8: alright 2019-10-29 09:52:08 :D also got a MR for poppler if you're interested, includes inflicting a libreoffice rebuild on the builders 2019-10-29 09:52:16 <_ikke_> yaay 2019-10-29 09:52:28 <_ikke_> I'm at work right now, so will be later 2019-10-29 10:23:03 ncopa: have you seen my msgs last night 2019-10-29 10:23:31 I fixed docbook-xsl and created MR !892 2019-10-29 10:24:04 I tested build some pkgs and it worked 2019-10-29 10:24:15 so I hope it is ok now 2019-10-29 10:24:19 <_ikke_> mps: fyi 'and bump pkgrel' is kind of redundant 2019-10-29 10:25:47 _ikke_: also to me looked little strange but didn't found better sentence 2019-10-29 10:25:59 <_ikke_> just drop that part 2019-10-29 10:26:00 anyone is free to fix it 2019-10-29 10:26:14 <_ikke_> 'remove unneeded patch' is sufficient 2019-10-29 10:26:36 I'm going to business meeting and don't have time now 2019-10-29 10:26:44 <_ikke_> sure, it's just an fyi 2019-10-29 10:26:59 <_ikke_> good commit messages are a pet peeve of mine 2019-10-29 10:27:24 don't worry, I understand your intentions, which are always good 2019-10-29 10:28:12 see you later 2019-10-29 10:32:39 <_ikke_> One easy thing to improve in commit messages is focussing more on why a change is made then what is changed 2019-10-29 10:33:00 <_ikke_> What is changed can be easily deducted from the diff 2019-10-29 11:49:20 hi 2019-10-29 11:49:24 mps: i saw 2019-10-29 11:54:52 Heya, ncopa 2019-10-29 11:55:06 I've marked some stuff as S-Ready on GitHub for main/ 2019-10-29 11:55:18 Also, could you look at pr11897 before it conflicts again? :) 2019-10-29 12:03:40 hi Cogitri 2019-10-29 12:03:45 re !866 2019-10-29 12:04:00 do you mind if i push with this commit message: http://tpaste.us/vJMW 2019-10-29 12:04:13 the only diff is that we mention that this is what udev rules does 2019-10-29 12:05:21 Cogitri: i marked it with C-kernel, which i normally check before i updater kernel 2019-10-29 12:05:31 that is PR11897 2019-10-29 12:06:35 Ah, okie, thanks 2019-10-29 12:09:30 Someone please merge !908 2019-10-29 12:20:45 <_ikke_> Ah, someone already did 2019-10-29 12:20:56 <_ikke_> ncopa: 2019-10-29 12:22:22 Thanks! 2019-10-29 12:22:37 <_ikke_> My push got rejected :D 2019-10-29 12:23:01 Lol, well there are worse reasons to get rejected πŸ˜‚ 2019-10-29 12:23:06 <_ikke_> hehe 2019-10-29 12:30:29 <_ikke_> At least no lack of people to merge your MR :) 2019-10-29 12:32:06 😁 2019-10-29 13:07:57 for 16core Intel Xeon (E5520) it took 7hrs to build two kernels using qemu chroot... cross compiling (or compiling native arch) takes 10min per kernel... 2019-10-29 13:12:15 Yup, but would require way more work on the Alpine side to get right 2019-10-29 13:12:29 And since we have native builders we don't really have a problem with it 2019-10-29 13:13:04 yeah, you don't, but I have, since I need to build the kernel before sending pr =) 2019-10-29 13:15:13 FWIW: this is the reason why I wanted to not be too quick with removing `cd "$builddir"`: https://github.com/alpinelinux/aports/pull/7558#issuecomment-547412855 2019-10-29 13:15:32 people to cherry-pick to older stable release 2019-10-29 13:15:52 and don't pay attention to that you need keep the `cd "$builddir"` 2019-10-29 13:16:38 <_ikke_> Thanks for the example 2019-10-29 13:16:57 fix is trivial 2019-10-29 13:17:00 ncopa: raspberry seems to have 4 kernels on their own 2019-10-29 13:17:07 raspbian, that is 2019-10-29 13:17:20 but it consumes time 2019-10-29 13:17:36 artok: what architectures do they support? 2019-10-29 13:18:20 hum 2019-10-29 13:18:31 thinking of `cd "$builddir"` 2019-10-29 13:19:27 i wonder if it would be an idea to backport that change to the older stable releases 2019-10-29 13:19:56 ah sure, they have arm7l and arm8 also.. 2019-10-29 13:20:07 64 bit arm8? 2019-10-29 13:20:38 <_ikke_> ncopa: Could it break packages that assume PWD is the default one? Ie, they do build() { do_something; cd "$builddir"; }? 2019-10-29 13:20:49 that is not yet on release, but all signs are that they're releasing it soonish 2019-10-29 13:21:23 _ikke_: the thing is that there are no default PWD 2019-10-29 13:21:52 <_ikke_> $startdir? 2019-10-29 13:22:13 what cwd is, is undefined 2019-10-29 13:22:17 so it can be anything 2019-10-29 13:23:05 <_ikke_> Even if it's undefined, it could be stable enough that people uknowingly relied on it 2019-10-29 13:23:11 i dont think there are any packages that will break 2019-10-29 13:23:14 <_ikke_> ok 2019-10-29 13:23:27 and if there is, it is already "broken" 2019-10-29 13:23:32 and should be fixed 2019-10-29 13:23:36 thats my thinking 2019-10-29 13:23:46 its a relatively low risk change 2019-10-29 13:25:40 i guess we dont care for 3.7-stable 2019-10-29 13:30:06 actually 2019-10-29 13:30:14 i think i'll backport for both 3.8-stable and 3.7-stable 2019-10-29 13:45:42 ncopa as far as I understood, they have armhf all around, (exception with that 8, which is upcoming aarch64), just kernel configs are different 2019-10-29 13:47:17 Cogitri: i have a problem with gnome-builder and meson/ninja 2019-10-29 13:47:27 [5/676] Linking static target src/libide/debugger/libide-debugger-3.34.a.ninja: fatal: posix_spawn: Argument list too long 2019-10-29 13:49:25 that's https://github.com/ninja-build/ninja/issues/1261 2019-10-29 13:50:38 @ncopa im tackling the libxslt secissue 2019-10-29 13:52:54 artok: yes 2019-10-29 13:54:36 no 2019-10-29 13:54:41 its this: https://gitlab.gnome.org/GNOME/gnome-builder/issues/1057 2019-10-29 13:55:01 this is the fix apparently: https://github.com/mesonbuild/meson/pull/6030 2019-10-29 13:57:03 Oh, huh, when did that happen? :o 2019-10-29 13:57:44 apparently a regression in meson 2019-10-29 13:57:49 i found a fix 2019-10-29 13:57:57 https://github.com/mesonbuild/meson/pull/6030 2019-10-29 13:58:09 Yup, nice. Are you going to take care of that or should I do that? 2019-10-29 13:58:13 im on it 2019-10-29 14:02:59 Great, thanks 2019-10-29 14:16:03 whee! I did alpine tar.gz that (almost) booted rpi4 aarch64 2019-10-29 14:16:20 Nice 2019-10-29 14:16:51 new bootloader just doesn't allow kernel or initramfs to be under directory, they need to be in the root of the sd fat partition 2019-10-29 15:23:57 I want to do a merge request for abuild (and later for apk-tools), however even if I've made a user on gitlab.alpinelinux.org I'm not allowed to push to the abuild repo 2019-10-29 15:24:14 what's the prefered way to submit code to abuild and apk-tools? 2019-10-29 15:24:52 fredrigu: you have first to fork to your account 2019-10-29 15:24:55 <_ikke_> fredrigu: You can fork the project, and .. 2019-10-29 15:25:04 <_ikke_> push to your fork 2019-10-29 15:25:21 I didn't know that I could to a MR cross forks 2019-10-29 15:25:22 fredrigu: Fork the project to your account, push to it and make a merge request against the upstream repo 2019-10-29 15:26:38 That's the entire point of MRs :) 2019-10-29 15:26:41 but it worked, thanks :) 2019-10-29 15:27:18 Cogitri: I believe it's a new thing. Github did pull requests earlier but when I started with gitlab it was always one repo and you instead did a merge request 2019-10-29 15:27:31 <_ikke_> Cogitri: in our company we never work with forks but always with merge requests :) 2019-10-29 15:28:17 _ikke_: How does that work ? everyone has their own branch ? 2019-10-29 15:28:34 Yup, but that only works if you trust everyone with pushing 2019-10-29 15:28:39 maxice8: topic branches I guess, that's how we used it in the companies I worked at 2019-10-29 15:29:00 <_ikke_> yes. topic branches, trust, and in some case, only maintainers that can push / merge to master 2019-10-29 15:29:02 Cogitri: yes, but pushing isn't dangerous if you can protect branches, or is it? 2019-10-29 15:29:07 <_ikke_> fredrigu: indeed 2019-10-29 15:29:35 <_ikke_> But with these kinds of projects, it's more common for people to fork projects rather than adding everyone as a contributor 2019-10-29 15:30:42 _ikke_: a bit off-topic, but since I recognize your nickname from #git a few years ago. I'm iveqy (in case you remember me). Using fredrigu at $dayjob and are finally ready to contribute a bit to alpine :) 2019-10-29 15:31:11 <_ikke_> fredrigu: I certainly remember iveqy 2019-10-29 15:31:21 <_ikke_> fredrigu: Welcome here 2019-10-29 15:32:03 thanks! 2019-10-29 15:32:34 <_ikke_> And we just migrated to gitlab, so everything still has to settle a bit 2019-10-29 17:13:10 ncopa you update patches for rpi kernel? the ones that dev.a.o/archive/rpi-patches have? 2019-10-29 17:41:04 just picturing the all process on my head so that's why asking =) 2019-10-29 19:18:06 what is the situation of non-free firmwares ? 2019-10-29 19:18:35 to get raspberry pi to work, we need to get firmwares from https://github.com/RPi-Distro/firmware-nonfree 2019-10-29 19:19:04 for example pi4 wlan started working after installing those 2019-10-29 19:28:39 artok: what license says 2019-10-29 19:31:17 "feel free to redistribute this binary, unmodified, to be used with broadcom integrated circuits" 2019-10-29 19:31:20 in nutshell 2019-10-29 19:31:39 https://github.com/RPi-Distro/firmware-nonfree/blob/master/LICENCE.broadcom_bcm43xx 2019-10-29 19:32:53 oh, I didn't asked question, meant to say 'if license allow redistribituion then can be somehow added 2019-10-29 19:33:39 maybe create script which downloads it and install 2019-10-29 19:34:09 well indeed, but would it be ok to have as apk package 2019-10-29 19:34:45 <_ikke_> I wonder that why some software is in non-free, while others just live in main/community/testing 2019-10-29 19:35:24 best option would be to add it (maybe in non-free) but someone with law knowledge should look at license first 2019-10-29 19:35:28 actually it needs to be, to be able to give people "untar this package to your sd and start using your rpi with alpine" 2019-10-29 19:36:00 <_ikke_> artok: there is a difference between people downioading it themselfs or redistributing it 2019-10-29 19:36:55 ofcoz 2019-10-29 19:39:01 but that licence allows distributing it, otherways no linux would work on broadcom device 2019-10-29 19:41:01 license text point 5 says that it is restricted 2019-10-29 19:41:55 <_ikke_> Seems to be about export law 2019-10-29 19:41:59 '5. Export Laws.', so it is non free and I think alpine cannot distribute it 2019-10-29 19:48:37 or can but not in all countries :P 2019-10-29 19:49:52 alpine doesn't discriminate users on any conditions, afaik 2019-10-29 19:50:31 <_ikke_> But apparently those users can just download it from github as well 2019-10-29 19:50:53 <_ikke_> I don't think github is blocking access to users in those countries (except for creating accounts) 2019-10-29 19:52:42 <_ikke_> mps: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.broadcom_bcm43xx 2019-10-29 19:52:51 <_ikke_> same clause is in there 2019-10-29 19:55:06 <_ikke_> https://pkgs.alpinelinux.org/contents?file=bcm43xx-0.fw&path=&name=linux-firmware-brcm&branch=edge&repo=main&arch=x86_64 2019-10-29 19:55:23 <_ikke_> We do distribute this broadcom firmware 2019-10-29 19:56:45 https://hastebin.com/jimaliroxi.bash would be otherways ready with rpi4 aarch64 2019-10-29 19:57:05 if so, we are on slippery slope 2019-10-29 19:57:29 um.. 2019-10-29 19:57:42 how many embedded systems use broadcom ? 2019-10-29 19:57:54 and alpine.. 2019-10-29 19:58:32 buying broadcom hardware grants you to use that binary 2019-10-29 19:58:50 <_ikke_> but not the right to distribute it necessarily 2019-10-29 19:58:57 <_ikke_> which is what we would do 2019-10-29 19:59:40 (this is reason I don't by RPis) 2019-10-29 19:59:43 <_ikke_> "to reproduce and distribute the Software complete, 2019-10-29 19:59:45 <_ikke_> unmodified, and as provided by Broadcom," 2019-10-29 19:59:53 <_ikke_> They do seem to allow distribution 2019-10-29 20:00:07 for Trump, there is that exporting clause 2019-10-29 20:00:16 _ikke_: yes, with restriction to some countries clause 2019-10-29 20:00:37 <_ikke_> Yes, I was just wondering if they specified distribution in general 2019-10-29 20:00:38 artok: that was long before Trump 2019-10-29 20:00:57 yeah I know, that has been from cuba hassle 2019-10-29 20:01:05 at least 2019-10-29 20:01:11 <_ikke_> mps: but even the linux kernel includes that firmware 2019-10-29 20:01:20 software is ammunition in some minds 2019-10-29 20:01:59 so.. to add one package more to linux-firmware ? 2019-10-29 20:02:02 <_ikke_> so why can everyone except us redistribute it? 2019-10-29 20:02:20 <_ikke_> artok: linux-firmware comes from the linux-firmware repo 2019-10-29 20:02:33 _ikke_: yes, I know that some distros have it but again I'm not sure is that legal 2019-10-29 20:02:51 ..with addition of some BT stuff from that same RPi-Distro github 2019-10-29 20:02:53 and, IANAL 2019-10-29 20:03:40 <_ikke_> artok: ah yes, I see 2019-10-29 20:04:30 <_ikke_> mps: but how is brcm not violating export laws itself by making it available publically? 2019-10-29 20:05:01 <_ikke_> (if they would apply) 2019-10-29 20:06:10 I presume they have lawyer team which can solve these issues 2019-10-29 20:06:31 not sure how Alpine can do the same 2019-10-29 20:06:50 <_ikke_> In this case Alpine Linux should prune a lot more software 2019-10-29 20:08:10 this is one option, second is to wait for first lawsuit 2019-10-29 20:08:42 ...and then would many other distros do the same 2019-10-29 20:09:56 but as I said IANAL and don't take my writing about this as something serious 2019-10-29 20:11:27 <_ikke_> http://tpaste.us/onZE 2019-10-29 20:12:25 custom license doesn't mean always same 2019-10-29 20:12:39 <_ikke_> Nope, but I bet we didn't verify each of them 2019-10-29 20:12:41 "Packages in the other archive areas (contrib, non-free) are not considered to be part of the Debian distribution, although we support their use and provide infrastructure for them (such as our bug-tracking system and mailing lists)." 2019-10-29 20:12:48 that is what debian says about :D 2019-10-29 20:13:17 but are broadcom drivers in there? I guess not 2019-10-29 20:13:32 <_ikke_> artok: in where? 2019-10-29 20:13:45 under non-free 2019-10-29 20:13:53 <_ikke_> for debian? 2019-10-29 20:13:56 yeah 2019-10-29 20:14:17 installer has those drivers 2019-10-29 20:14:50 in debian these software is in non-free 2019-10-29 20:15:00 <_ikke_> they have firmware-linux an firmware-linux-nonfree 2019-10-29 20:15:20 <_ikke_> But they still redistribute it 2019-10-29 20:16:04 yep, can even get non-free iso/images from their servers 2019-10-29 20:16:36 <_ikke_> so they let the user decide whether they want to use it or not 2019-10-29 20:16:58 no, debian have 'firmware-linux' which depends on firmware-linux-nonfree and firmware-linux-free 2019-10-29 20:18:08 <_ikke_> doesn't matter how they call or arrange it, they distribute it 2019-10-29 20:18:24 <_ikke_> (sorry, don't mean this in a hostile way) 2019-10-29 20:18:24 and non-free is unofficial in debian 2019-10-29 20:18:37 <_ikke_> but they still redistribute it :) 2019-10-29 20:19:14 <_ikke_> They package it and you can download it from their mirrors 2019-10-29 20:19:14 I would say that they package it but distribution is unofficial 2019-10-29 20:19:21 <_ikke_> doesn't matter to the law 2019-10-29 20:19:52 so enough if Alpine add note about non-free repo that isnt supported by Alpine and will be like with Debian :D 2019-10-29 20:20:37 too bad they dont update this site anymore: https://wiki.debian.org/KernelFirmwareLicensing 2019-10-29 20:20:47 can see there their battle with it 2019-10-29 20:22:16 https://www.debian.org/CD/faq/#nonfree 2019-10-29 20:22:47 'Sometimes, someone is kind enough to create unofficial non-free CDs.' 2019-10-29 20:23:07 <_ikke_> those are the CDs, but the online repos contain it 2019-10-29 20:23:30 <_ikke_> which makes it even easier to obtain 2019-10-29 20:24:02 <_ikke_> https://packages.debian.org/stretch/all/firmware-linux-nonfree/download 2019-10-29 20:24:29 yes, I know, I was debian user for about two decades 2019-10-29 20:24:56 <_ikke_> so fact: debian distrutes packages they call non-free 2019-10-29 20:25:00 and I'm still on debian-devel ML 2019-10-29 20:25:37 iirc, non-free is served from server which are not debian infra 2019-10-29 20:25:44 they only claim that non-free cd's are UNOFFICIAL but still hosting them on own infrastructure :P 2019-10-29 20:25:54 <_ikke_> *.debian.org 2019-10-29 20:25:55 cdimage right 2019-10-29 20:26:29 it is debian.org domain name, but real servers are somewhere else, iirc 2019-10-29 20:27:13 <_ikke_> curl -vI http://ftp.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-linux-nonfree_20161130-5_all.deb -> 200 OK 2019-10-29 20:27:29 <_ikke_> no redirect, just a direct download 2019-10-29 20:29:19 iirc, ftp.debian.org is in Enschede, NL 2019-10-29 20:29:44 ..and then the mirrors 2019-10-29 20:29:58 not in USA 2019-10-29 20:29:58 <_ikke_> mps: does it matter where it's physically located? 2019-10-29 20:30:07 yes, it is 2019-10-29 20:30:11 <_ikke_> They offer it directly from their domains 2019-10-29 20:30:46 <_ikke_> I don't think a judge would see that as a difference 2019-10-29 20:30:54 iirc, this was intentional to put it in country which do not restrict redistribution 2019-10-29 20:30:59 + hundreds of mirrors 2019-10-29 20:31:46 MY-R: mirrors are out of question for this 2019-10-29 20:31:59 even those in US? 2019-10-29 20:32:21 but every mirror have to obey laws of country where it is physically located 2019-10-29 20:32:27 <_ikke_> mps: what about http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-linux-nonfree_20161130-5_all.deb then? 2019-10-29 20:33:28 _ikke_: that is the mirror owners who can answer this question 2019-10-29 20:34:32 <_ikke_> I still maintain that no judge is going to see a difference 2019-10-29 20:34:37 never tried to access these mirrors from a country on the ban list, so don't know how this works 2019-10-29 20:34:55 <_ikke_> they offer the download from their domains 2019-10-29 20:36:12 from legislation POV physical location is what counts, not domain name 2019-10-29 20:36:46 but, I think we need a lawyer who knows these issues 2019-10-29 20:37:35 I know about this just superficially, from internet articles and some ML's, nothing more 2019-10-29 20:37:43 even lawyer would have problems with clear answer :P 2019-10-29 20:37:56 MY-R: true :) 2019-10-29 20:38:18 <_ikke_> mps: I think there would be a difference if you just directly link to a mirror 2019-10-29 20:38:34 <_ikke_> mps: ie, a difference between the dl-*.a.o mirrors and the third-party links 2019-10-29 20:39:30 <_ikke_> reminds me of an old colleague of mine 2019-10-29 20:39:47 <_ikke_> got sued by realmedia 2019-10-29 20:40:23 not sure, I can look at git.kernel.org and read license from banned country and download firmware, but then git.kernel.org can be sued for distributing this firmware to this banned country 2019-10-29 20:40:29 <_ikke_> they accused him of building an alternative to realplayer, which infringed on their patents / copyright 2019-10-29 20:40:58 <_ikke_> He had a site where he linked to it via a cname 2019-10-29 20:41:08 <_ikke_> Never heard how that lawsuite ended 2019-10-29 20:41:11 pretty sure if Alpine would start making big money then some corporations could make a law suit :D 2019-10-29 20:42:01 MY-R: trolls, before big corp 2019-10-29 20:42:05 yep! 2019-10-29 20:47:07 I thought about all this nonsense some distant time ago, and I think US will not dare to sue kernel.org or debian.org because they 'export' firmware to banned countries because then kernel.org (or debian.org) will move all their work to some country (or countries) without such laws 2019-10-29 20:47:43 <_ikke_> mps: like that has ever stopped the US from suing someone 2019-10-29 20:48:18 <_ikke_> with things like the patriot act, they claim jurisdiction if you have any affiliation in the US 2019-10-29 20:48:25 imagine kernel.org move to China 2019-10-29 20:48:55 <_ikke_> and then being blocked because it distributes something the chinese government does not like? 2019-10-29 20:49:35 yes, ofc, but politicians don't look so far 2019-10-29 20:50:04 <_ikke_> ah, RealNetworks lost the case apparently 2019-10-29 20:50:23 hehe, nice to hear this :) 2019-10-29 20:51:09 <_ikke_> The colleague did suffer a lot due to that lawsuite though 2019-10-29 20:52:54 uhm, what to say, we live in a world where judges and lawyers destroyed justice 2019-10-29 20:54:28 <_ikke_> RealnetWorks was sentenced to pay the attorney costs, so at least he was somewhat compensated 2019-10-29 20:54:49 (medicine destroy health etc in every field of humanity) 2019-10-29 21:00:56 seeking no truth, winning is all 2019-10-29 21:01:44 and that is the freedom! :D 2019-10-29 21:03:26 now then 2019-10-29 21:11:38 should that be separate linux-firmware-rpi/APKBUILD or added to that same as subpackage... 2019-10-29 21:12:24 <_ikke_> They're all subpackages 2019-10-29 21:14:27 separated by directory 2019-10-29 21:15:51 hence question is, how to merge 2019-10-29 21:16:30 <_ikke_> weren't there examples from bt firmware from that repo already? 2019-10-29 21:16:45 just individual files 2019-10-29 21:16:55 two of them 2019-10-29 21:24:56 might as well start by adding just the updated wifi firmware and check how it goes after that 2019-10-29 21:36:42 artok: we have non-free/b43-firmware, I used it as base to install some wifi firmware on one old macbook 2019-10-29 21:37:52 off to spin up again AWS aarch64 to build the packages... 2019-10-29 21:38:02 that's different than on rpi4 2019-10-29 21:38:37 yes, ofc. but script could be adapted, probably 2019-10-29 21:38:52 dmesg says brcmfmac43455-sdio 2019-10-29 21:39:22 rather put that into basic firmware package so no further mkimage hacking needed =) 2019-10-29 21:41:06 but indeed that could be done, different APKBUILD, that was kind of my question 30min ago =) 2019-10-29 22:16:37 would be great to get one drone runner on some aarch64 16core machine 2019-10-29 23:45:59 packet have an arm system that works out to about $4500/year (running 24/7)... wonder if it could run on demand 2019-10-29 23:49:59 aws instance for 8core would be $0.2304/hr or spot instance $0.0712/hr 2019-10-29 23:53:57 the packet one was 96 cores 2019-10-29 23:54:34 well that would do some compiling 2019-10-29 23:56:00 eh.. was faster to build with 8cores than with 16.. might be that 24 jobs was too much for make 2019-10-29 23:56:21 gave cores * 1.5 on abuild.conf 2019-10-29 23:57:22 oddly, packets spot price was $5/hr... 2019-10-30 00:13:39 yeah. my suggestion is to make APKBUILD for linux-rpi-firmware and install that on installer 2019-10-30 00:13:51 it works without hassle 2019-10-30 00:15:20 oh wait.. no 2019-10-30 00:18:14 just the brcm directory differencies, yeah 2019-10-30 04:14:05 alpine:3.9 appears to now be including musl-1.1.20-r4, instead of musl-1.1.20-r5, which it was including up until today (and, according to https://pkgs.alpinelinux.org/packages?name=musl&branch=v3.9, should include.) We saw this earlier today when one of our automated builds failed due to the vulnerability with musl-1.1.20-r5, and I just confirmed it by building an image with the simple Dockerfile of just "FROM alpine:3.9". Both G 2019-10-30 04:14:05 oogle Cloud Container Registry and Twistlock show musl-1.1.20-r4 2019-10-30 04:16:05 correction. I meant to say "We saw this earlier today when one of our automated builds failed due to the vulnerability with musl-1.1.20-r4..." 2019-10-30 07:19:02 artok: yes, I'm the one who rebases the alpine rpi patches 2019-10-30 07:19:29 ncopa: just a heads up, I'm starting working on multiarch support for apk. I hope that's welcomed to be merged? 2019-10-30 07:20:13 multiarch, as in 64 bit + 32 bit x86? 2019-10-30 07:21:34 ncopa: no, multiarch as in /etc/apk/arch can contain multiple lines with one arch in one line and when doing an apk add we're searching through all arch in the repos 2019-10-30 07:22:24 what is the usecase for that? 2019-10-30 07:24:03 using yocto, we're building packages for multiple architectures (for example: x86, cortexa9hf-neon, all, etc.). Then we install packages from different architectures to the same root file system 2019-10-30 07:24:39 I'm working on adding support for apk in yocto 2019-10-30 07:32:17 fredrigu: can you elaborate a little what is use case of having apk's for different archs on same root FS 2019-10-30 07:33:01 I guess crosscompiling 2019-10-30 07:33:16 Cogitri: yes it is for cross compiling 2019-10-30 07:34:00 mps: I actually have no real good answer on why yocto does it this way. More than that we have multiple CPU's in our product 2019-10-30 07:34:07 (using the same system) 2019-10-30 07:34:39 like debian multiarch? 2019-10-30 07:35:39 mps: I don't know enough to be able to answer that unfortunately. I don't know exactly how we handle the different CPU's 2019-10-30 07:36:50 so, idea is to cross build complete distro on one arch for some other arch's, iiuc 2019-10-30 07:37:16 what I know is that when building packages yocto is creating 5 different architectures, 4 of them are for target and 1 for the host system. 2019-10-30 07:38:03 this is a usecase that is supported by opkg, rpm and deb 2019-10-30 07:38:13 understand, and this will be a lot of works to achieve this goal 2019-10-30 07:39:10 mps: yeah, fortunately I'm doing this at $dayjob and we will have great benefits on using apk instead of rpm 2019-10-30 07:40:09 I don't think it will be too hard :). The real hard part would be to try to get apk multithreaded to speed it up even more. But that's an other topic 2019-10-30 07:40:48 TBH, personally I think this is not worth a hassles, native build is better and more correct, ime 2019-10-30 07:41:09 mps: we're not able to do native builds, it's too slow 2019-10-30 07:41:48 fredrigu: I'm not against your effort 2019-10-30 07:43:25 mps: I understand that this is a somewhat different usecase that for alpine. So far apk and abuild is used only for alpine and with aports as far as I know 2019-10-30 07:45:19 Fwiw you might want to take a look at Paludis' Exherbo which was one of the first PMs to support native multiarch 2019-10-30 07:46:16 few months ago I looked at cross tools in the debian and arch linux, i.e how make alpine base cross tools but didn't have much free time to work on it 2019-10-30 07:47:12 it is interesting and would be nice have all that, but will require coordinated effort and work, imo 2019-10-30 08:02:15 The one thing I'd want most in apk is packagekit I think, maybe I should look into implementing that 2019-10-30 08:02:27 But that'd become with a dbus dep :/ 2019-10-30 08:02:42 Maybe we can make it a seperate daemon or smth 2019-10-30 08:07:46 <_ikke_> why would packagekit need dbus? 2019-10-30 08:08:06 <_ikke_> "PackageKit uses PolicyKit for user authentication." 2019-10-30 08:08:08 <_ikke_> that explains 2019-10-30 08:08:33 <_ikke_> So it allows users to install software, not just root 2019-10-30 08:21:18 but why needs it be to run all time? as a daemon? 2019-10-30 08:21:45 that gnome, systemd, dbus, *kit, apparmor stuff is all broken 2019-10-30 08:22:33 <_ikke_> "PackageKit itself is a system activated daemon called" 2019-10-30 08:22:42 <_ikke_> so it does not run all the time 2019-10-30 08:22:44 ACTION keeps eyeing at https://en.wikipedia.org/wiki/Systemd#Adoption and wondering when the Orphaning part will appear 2019-10-30 08:22:45 [WIKIPEDIA] Systemd#Adoption | "The systemd software suite provides fundamental building blocks for a Linux operating system. It includes the systemd "System and Service Manager", an init system used to bootstrap user space and manage user processes.Systemd includes features like on-demand starting of daemons, snapshot support, process..." 2019-10-30 08:25:08 I dislike all these *kit and systemd* ideas 2019-10-30 08:26:31 instead of all them linux distros could port windows registry :P 2019-10-30 08:26:58 you know windows had ini files before they got registry? 2019-10-30 08:27:12 it's an iterative process, just give systemd some more time 2019-10-30 08:28:10 i mean they fucked up networking, see https://alt.org/nethack/dudley/?f=2018.5.5 then user editable config files, user viewable log files ... 2019-10-30 08:29:19 tarzeau: how did they mess with the config files and user viewable log files? 2019-10-30 08:29:48 xerireu: hostnamectl/telinit q/inittab and journalctl? 2019-10-30 08:30:18 i miss inittab in etc and hostname they fucked it up. also they fucked up dns 2019-10-30 08:31:39 tarzeau: ah 2019-10-30 08:31:58 The nice thing about PackageKit is that it allows users to install packages via a GUI 2019-10-30 08:32:02 E.g. via GNOME Software 2019-10-30 08:32:15 Which is pretty nifty especially on a phone 2019-10-30 08:33:06 tarzeau: but users can view the log with journalctl AFAIK, depending on configuration of course 2019-10-30 08:33:12 did they think about enterprise computers and phones where users are not supposed to install packages? 2019-10-30 08:33:35 xerireu: users normally use sed, awk and other tools with pipes on unix like systems 2019-10-30 08:33:57 systemd developers are anti pipes, it's all screwed up beyond fixage, i'm gone (sorry for trolling) 2019-10-30 08:34:59 tarzeau: yeah, but I never seen a system with only journalctl and no syslog 2019-10-30 08:45:10 ncopa: do we want to move forward with the deprecation of github pull requests? nobody complained on the ML so far. if so: I could just setup the webhook I wrote for this purpose which adds a comment to new PRs and (optionally) closes them 2019-10-30 08:45:36 <_ikke_> nmeum: where can we find this webhook? 2019-10-30 08:46:28 _ikke_: https://github.com/nmeum/noprs also created an alpine package https://gitlab.alpinelinux.org/alpine/aports/merge_requests/870 2019-10-30 08:46:46 comes with an OpenRC service 2019-10-30 08:47:57 we just need to agree on a comment text and maybe an a algibotprbot account to the github organization which closes the issues 2019-10-30 08:48:01 *add 2019-10-30 08:48:43 Didn't we agree on the ML to wait for a bit until GitLab is really ready? 2019-10-30 08:49:59 nobody posted that suggestion in the thread, no but as I said: we can keep github PRs open for now and just post a comment that we will close them soon 2019-10-30 08:50:24 <_ikke_> I think that's a good first step, people to use gitlab 2019-10-30 08:50:35 <_ikke_> s/people/encourage people/ 2019-10-30 08:50:35 _ikke_ meant to say: I think that's a good first step, encourage people to use gitlab 2019-10-30 08:50:59 nmeum: take that with alpine infra (clandmeter and _ikke_). I dont mind switching over, but its up to clandmeter to decide 2019-10-30 08:51:16 We still need updated docs for GitLab, a working algitbot (seems like it worked for a bit but doesn't work now), labels, maybe some fancy work queue thingie like we have on GitHub 2019-10-30 08:51:26 I feel like we already have enough ppl on Gitlab to test 2019-10-30 08:51:46 <_ikke_> gitlab project boards don't work for merge requests :( 2019-10-30 08:51:57 <_ikke_> issue boards 2019-10-30 08:52:28 <_ikke_> We already have labels, but nothing that auto-labels yet 2019-10-30 08:53:07 <_ikke_> Though, filtering in gitlab is very limited 2019-10-30 08:54:59 are those issues blockers though? 2019-10-30 08:55:02 Ah, okie 2019-10-30 08:55:19 <_ikke_> Not for me 2019-10-30 08:55:22 Not really blockers but IMHO super, super nice to have before we do the switch 2019-10-30 08:55:41 At least a working algitbot and docs are blockers I think 2019-10-30 08:55:49 <_ikke_> clandmeter needs to make the ultimate call, but for me I think we are ready as ever 2019-10-30 08:56:13 I can do without autolabelling and the issue board for now, but no algitbot makes it hard to trace which MR was merged how 2019-10-30 08:56:40 <_ikke_> At least for me, I always add a reference to the MR in the commits 2019-10-30 08:56:46 <_ikke_> and that shows up in the MR 2019-10-30 08:56:50 I always close them manually 2019-10-30 08:56:55 <_ikke_> yes, me too 2019-10-30 08:57:02 i think the plan is to make git.a.o read-only and push to gitlab 2019-10-30 08:57:08 I think algibot for gitlab would be nice, but it's not a blocker for me 2019-10-30 08:57:10 i think that may be the current blocker 2019-10-30 08:57:28 so we can merge via web interface in gitlab 2019-10-30 08:57:31 <_ikke_> ncopa: Did we make a decision yet about how that affects access to push to main? 2019-10-30 08:57:51 not that i remember 2019-10-30 08:58:13 <_ikke_> Because we have no mechanism to limit pushing to main in gitlab as of yet 2019-10-30 08:58:20 does the gitlab web interface support merging without merge commits? 2019-10-30 08:58:21 _ikke_: But lots of people don't add that reference and we have loads of "closing, merged" 2019-10-30 08:58:54 nmeum: i think it does 2019-10-30 08:59:08 ok, grea 2019-10-30 08:59:08 t 2019-10-30 08:59:22 _ikke_: right, i think we discussed it but i dont remember the conclusion 2019-10-30 08:59:26 Yes 2019-10-30 08:59:28 You just have to enable FF merges in the repo's settings 2019-10-30 08:59:44 <_ikke_> nmeum: https://imgur.com/a/GeHXffU 2019-10-30 08:59:49 But if we can merge via the webinterface it's fine by me 2019-10-30 11:05:16 Hi. How to file issues or feature request, if the project gitlab server doesn't accept new users? 2019-10-30 11:11:54 cschlote: gitlab.a.o 2019-10-30 11:12:17 It works fine afaik 2019-10-30 11:13:04 I can't select the register tab, nor the login by github or gitlab buttons. I can only log-in to an existing account. 2019-10-30 11:17:23 something must be strange, I select it even from elinks (text mode web browser) 2019-10-30 11:18:45 (hmm, reCaptcha wouldn't work in text mode browsers? or I'm wrong) 2019-10-30 11:31:32 <_ikke_> cschlote: can you show a screenshot or something? For me it seems to work 2019-10-30 11:31:56 cschlote, working fine for me in Firefox and in Chrome on phone (pc version of site) do you use any noscript etc extension? 2019-10-30 11:32:24 but in mobile version I cant even slide to login/register tab 2019-10-30 11:34:02 well, rotating phone by 45 helped with it :D ... 2019-10-30 11:39:38 Tried some different network connection. Seems to work now.... Thanks for feedback. 2019-10-30 12:46:10 is Timo here? What's his nickname? 2019-10-30 12:46:39 <_ikke_> fabled 2019-10-30 12:47:22 thanks, then he's not here I see :) 2019-10-30 12:48:07 still you can ask if it's not personal ;) 2019-10-30 12:57:57 so yeah, I installed whole linux firmware package and copied what rpi-distro has under brcm onto (overwriting and adding) the brcm folder that comes from linux-firmware-brcm apk, and now the rpi4 works 2019-10-30 12:58:16 just if someone is interested 2019-10-30 12:58:50 someone could make an APKBUILD out of your procedure 2019-10-30 12:59:51 artok: that's true. I'm wondering what this line in database.c do: db->arch = apk_blob_atomize(APK_BLOB_STR(dbopts->arch)) 2019-10-30 13:00:08 more specific, whata do apk_blob_atomize do? 2019-10-30 13:01:00 grepping that from sources won't give comment lines that describe ? 2019-10-30 13:02:59 artok: no,no comments. I'm reading the code and try to understand it :) 2019-10-30 13:06:28 I think it adds the architecture to a global hash table, but I don't understand why 2019-10-30 13:27:29 TBB could. I won't do until I'll get some advice if that should be in linux-firmware package or own package =) 2019-10-30 13:32:24 fredrigu: it dedupes the string 2019-10-30 13:33:09 kaniini: so it make sure there's only one single arch? 2019-10-30 13:33:14 no 2019-10-30 13:33:34 so that only one copy of "x86_64" (or whatever) exists in memory 2019-10-30 13:33:41 because every package 2019-10-30 13:33:44 has an arch field 2019-10-30 13:34:03 and so if we load into the in-memory database "x86_64" thousands of times, it adds up 2019-10-30 13:34:05 kaniini: oh I see, smart! 2019-10-30 13:34:39 this also means 2019-10-30 13:34:44 instead of doing strcmp() 2019-10-30 13:34:53 and that's why it's a global hash table 2019-10-30 13:34:54 apk_blob_atomize() will always return the same atom 2019-10-30 13:35:02 so you can just do 2019-10-30 13:35:09 if (atom_x86_64 == package->arch) { ... } 2019-10-30 13:35:17 which means it's a faster comparison 2019-10-30 13:36:48 ah, I learned something new today. Usually I do this with #define X86_64 1 2019-10-30 13:37:21 but that also means that the .PKGCONFIG files would just contain strange numbers, and all numbers had to be defined in compile time 2019-10-30 13:37:34 this solution with atoms seems way better for this case 2019-10-30 13:51:15 oh no 2019-10-30 13:51:24 fredrigu: are you writing a package manager? 2019-10-30 14:02:22 kaniini: no, I'm improving apk 2019-10-30 14:02:33 (or try to improve it) 2019-10-30 14:02:40 I'm adding support for multiple architectures 2019-10-30 14:05:24 multiple architectures ? 2019-10-30 14:05:41 like debian's multiarch ? 2019-10-30 14:06:49 maxice8: I'm not quite sure how debian multiarch is working. But I don't think so. There won't be any different library paths and so on. But /etc/apk/arch will contain a list of architectures and all packages matching those architectures will be installed 2019-10-30 14:24:04 well 2019-10-30 14:24:06 to do multiarch 2019-10-30 14:24:11 there has to be different library paths 2019-10-30 14:24:17 otherwise you get collisions 2019-10-30 14:24:39 i'm just bringing this up as it's something to be aware of 2019-10-30 14:47:12 can someone restart CI for !876 2019-10-30 14:47:58 want to see will it pass with fixed docbook-xsl 2019-10-30 14:48:15 done 2019-10-30 14:50:20 maxice8: thanks 2019-10-30 14:55:28 nice, it pass all, except x86 where it waiting 2019-10-30 15:14:46 real sysroots are better than multiarch to handle. for me at least =) 2019-10-30 15:50:09 kaniini: yes thank you, but that's not what I'm trying to do 2019-10-30 15:51:17 i'm not sure what you are trying to do then 2019-10-30 16:05:13 kaniini: There won't be any different library paths and so on. But /etc/apk/arch will contain a list of architectures and all packages matching those architectures will be installed 2019-10-30 16:05:29 kaniini: this will make it possible to use apk with yocto/bitbake 2019-10-30 16:05:31 installed to where? 2019-10-30 16:05:52 to sysroot 2019-10-30 16:06:03 you don't need to modify apk to build sysroots 2019-10-30 16:06:04 the --root 2019-10-30 16:06:06 use --arch 2019-10-30 16:06:40 this is literally what --arch is for, even 2019-10-30 16:06:43 kaniini: how do I do if I've serveral architectures that all should be a part of the same sysroot? 2019-10-30 16:07:00 then you need to have real multiarch support 2019-10-30 16:07:07 because you will have path collisions in the sysroot 2019-10-30 16:07:23 no I won't. Because no packages will overlap 2019-10-30 16:07:29 really 2019-10-30 16:07:59 /lib/libz.so.1 is built for x86, but you also have arm who want zlib, at /lib/libz.so.1 2019-10-30 16:08:19 voila: collision 2019-10-30 16:09:01 unless you are talking about using an entirely different set of apks than what alpine or adelie are shipping 2019-10-30 16:09:05 this is going to be a problem 2019-10-30 16:10:48 that's not how yocto works. For example I've apk, I need it on the hosts and target, so both x86_64 apk and arm apk is built. Then we need ca-certs, it's the same for both x86_64 and arm so it's built with "all" as architecture. 2019-10-30 16:11:17 then when building the rootfilesystem. I wan't packages from "all" and "arm" in the same sysroot 2019-10-30 16:11:21 thats not multiarch, that's noarch 2019-10-30 16:11:40 and okay, that makes more sense 2019-10-30 16:11:54 but why would yocto want apk over rpm? 2019-10-30 16:12:05 what's noarch? I've seen some support for it in the apk source code but I'm not sure how to use it 2019-10-30 16:12:40 noarch is 'all' 2019-10-30 16:13:03 Think bash scripts etc. 2019-10-30 16:13:05 kaniini: so how do I use it? can I just use --arch noarch ? 2019-10-30 16:13:27 right now, alpine just includes duplicate noarch packages in each arch's index 2019-10-30 16:13:30 i do agree it shouldn't 2019-10-30 16:13:59 noarch is set for the pkg, you can't specific noarch in the CLI 2019-10-30 16:14:56 so the reason for replacing rpm is that it's huge and slow. The rpm database won't fit on target. rpm is also slow, building our rootfs takes 4 min 30 sec. Using opkg (to get a smaller database that will fit on target) is even slower, it takes arount 5 min to build rootfs then. Using apk it takes 2 min to build rootfs. 2019-10-30 16:15:15 saving 2 min each build is huge to me 2019-10-30 16:15:57 ah thanks, that's great. Becuase then my change will contribute to alpine as well, making it possible to put noarch packages in their own repo 2019-10-30 16:16:43 i would like to change the index format :( 2019-10-30 16:16:50 (though i am not in favor of CDB) 2019-10-30 16:17:19 CDB? 2019-10-30 16:17:33 kaniini: what do you dislike about the index format (I can think of a few things...) 2019-10-30 16:17:55 djb's constant database 2019-10-30 16:18:08 the index format still has to be parsed 2019-10-30 16:18:19 but it's not human readable, nor is it optimized for parsing really 2019-10-30 16:19:41 exactly my thought. Yes it's text and not binary, but it's still not easy to read 2019-10-30 16:20:05 but I'm not sure that a binary database would be better... 2019-10-30 16:21:00 i would probably reuse the parser from pkgconf 2019-10-30 16:21:09 (apk and pkgconf have some relation to each other) 2019-10-30 16:21:56 one thought would be to use tarstreams 2019-10-30 16:22:06 fabled is scared of tarstreams though since that one CVE a while ago 2019-10-30 16:22:11 but i think tarstreams are legit :) 2019-10-30 16:22:39 i can't really think of why an object graph stored as a tarstream would be any worse than an object graph stored as a CDB 2019-10-30 16:22:46 but ehh :) 2019-10-30 16:23:13 i'm kind of against CDB in general too, because we've already battle-tested our tarstreams stuff 2019-10-30 16:23:24 changing the binary format to CDB means we get to do it all over again 2019-10-30 16:23:27 and for what? 2019-10-30 16:25:09 I like the few dependencies that apk has 2019-10-30 16:27:41 gah, linked lists in apk is hard. Time to go home for today 2019-10-30 16:27:56 hard? it's same implementation as in linux kernel 2019-10-30 16:30:35 kaniini: yes I saw that. But somehow I mess it up and get a inifinity loop when iterating the list. I think I do something wrong in the setup 2019-10-30 16:30:51 fredrigu: are you deleting from the list? 2019-10-30 16:31:22 no, just inserting 2019-10-30 16:31:50 can you put up a diff or something? i can take a look 2019-10-30 16:34:15 https://gitlab.alpinelinux.org/fredrigu/apk-tools/commit/0340ae3e6622d384b9355df65b33f48242b22de1 2019-10-30 16:34:25 sorry for the mess with debut printfs 2019-10-30 16:39:26 I also believe that I've made a design error. For specifying multiple archs on the command line I thought: apk --arch x86_64,arm but I believe it shoule be: apk --arch x86_64 --arch arm instead. I've a hinch that it's more in line with other apk arguments 2019-10-30 16:42:02 fredrigu: struct list_head tmp; is on the stack 2019-10-30 16:42:29 way it should be is 2019-10-30 16:42:57 list_add(&aal->list, &db->archs.list); 2019-10-30 17:10:16 @mps iwd 1.0 is out 2019-10-30 17:45:37 maxice8: yes, running here 2019-10-30 17:46:08 waiting for !949 2019-10-30 17:46:39 it need to be pushed before I can push iwd 1.0 2019-10-30 17:48:05 and I have a question about file removed upstream, i.e. /etc/iwd/main.conf is removed 2019-10-30 17:49:14 we have it in all alpine pkg versions. so should I copy it from previous version and add to aports or follow upstream and not add it 2019-10-30 18:49:27 hehe, how fast is 'Alpine Package DB' robot, it informs me by mail just 5 hours after iwd 1.0 is released :P 2019-10-30 18:50:27 180hp 2019-10-30 18:50:46 It refreshes every night i think 2019-10-30 18:51:18 maxice8: heh, in what TZ is its night 2019-10-30 18:51:57 mps: Japan it is 3 AM 2019-10-30 18:52:21 aha, that explains 2019-10-30 18:54:33 It should listen on a topic 2019-10-30 18:54:42 Not sure that's still running 2019-10-30 18:54:52 It had some issues 2019-10-31 06:54:46 kaniini: thanks! I think I've got it working now. So list_head is automatically created on the heap? 2019-10-31 07:11:47 kaniini: hmm, no I see that a list_init also needs to be done 2019-10-31 07:38:25 Cogitri: good morning. here is the patch for NM which fixes issue with iwd 1.0 https://raw.githubusercontent.com/dtzWill/nixpkgs/nixos-dtz/pkgs/tools/networking/network-manager/iwd-new-root-path.patch 2019-10-31 07:39:09 Nice, thanks 2019-10-31 07:39:15 it is just FYI, don't need to be applied till we have iwd 1.0 in repo 2019-10-31 07:40:07 I will note you again when I push iwd 1.0 2019-10-31 07:40:30 hope the patch will be included in next NM release 2019-10-31 07:43:12 also, can we use 'depends="pkgxyz=1.1"' instead of 'depends="pkgxyz>=1.1"' in APKBUILD, i.e. exact version of dep 2019-10-31 07:43:33 can't find any reference to this 2019-10-31 07:49:10 You can also use ~ 2019-10-31 07:53:27 what does it mean? to me looks like heuristic sign (: 2019-10-31 08:19:17 <_ikke_> Cogitri: first time I've heard of it as well 2019-10-31 08:20:14 it looks like some regex pattern match, but not sure how it works 2019-10-31 08:20:51 looked some examples in aports, but still have no idea how to use it 2019-10-31 08:21:01 <_ikke_> mps: If it's similar to how ruby does it, it means it fixes it to a certain minor release for example 2019-10-31 08:21:25 <_ikke_> in ruby ~> 1.5.0 means that 1.5.x matches, but 1.6.x doesn't 2019-10-31 08:22:01 <_ikke_> so a shortcut for >=1.5.0 AND <1.6.0 2019-10-31 08:22:27 huh, strange syntax 2019-10-31 08:23:34 why not simply '=~/^1.5.*/' 2019-10-31 08:24:02 ok, everyone have his idea how regex should work :) 2019-10-31 08:24:18 <_ikke_> * is not a wildcard in regex ;-) 2019-10-31 08:24:42 <_ikke_> 1\.5\.[0-9]+ 2019-10-31 08:24:57 <_ikke_> Not sure if we want to use regex syntax for version constraints :-) 2019-10-31 08:25:24 then 1\.5\.[0-9a-zA-z]+ :D 2019-10-31 08:25:59 you know some people add letters to release versions 2019-10-31 08:26:12 <_ikke_> yup 2019-10-31 08:26:25 <_ikke_> so it's better to use a version constraint syntax, not regexp (imo) 2019-10-31 08:27:26 yes, I'm for simple math, '<' '=' '>' and their combo 2019-10-31 08:27:52 <_ikke_> What about between versions? 2019-10-31 08:28:13 <_ikke_> like only patch releases in a minor release 2019-10-31 08:28:34 not sure but to me looks like corner cases 2019-10-31 08:32:38 <_ikke_> Sometimes there are these constraints and it's nice to be able to capture them 2019-10-31 08:33:32 like debian 2019-10-31 09:15:19 <_ikke_> Especially when mass updating packages, it's nice to have a warning that you are breaking other packages which depend on a certain version 2019-10-31 09:18:46 <_ikke_> anyone willing to help me to get this: https://lists.alpinelinux.org/~alpine/aports/patches updated? It would be nice of someone can check which patches are already applied or out-of date. Then I can update them 2019-10-31 09:19:42 not small list 2019-10-31 09:19:57 <_ikke_> nope 2019-10-31 09:20:23 <_ikke_> But at least start with recent posts 2019-10-31 09:21:12 libedit is applied, iirc 2019-10-31 09:21:52 <_ikke_> indeed 2019-10-31 09:23:43 quitebrowser also 2019-10-31 09:25:06 opencsg also https://lists.alpinelinux.org/~alpine/aports/patches/3094 2019-10-31 09:27:18 <_ikke_> thanks! 2019-10-31 09:28:23 <_ikke_> strange, ncopa replied they hey pushed wxgtk, but aports still contains the old version 2019-10-31 09:29:10 <_ikke_> ah, it's reverted 2019-10-31 09:29:44 I think I saw musl-nscd ( https://lists.alpinelinux.org/~alpine/aports/patches/3077 ) on gitlab also 2019-10-31 09:30:13 _ikke_: it was reverted because 3.1 is unstable devel release 2019-10-31 09:30:30 musl-nscd is interesting 2019-10-31 09:30:46 <_ikke_> ncopa: yeah, I saw the revert message 2019-10-31 09:31:03 and this one (https://lists.alpinelinux.org/~alpine/aports/patches/3095) also have MR !793 by same author 2019-10-31 09:31:14 <_ikke_> ncopa: would it make sense to add a note to the APKBUILD about that? 2019-10-31 09:31:26 <_ikke_> kind of like package specific policies / notes 2019-10-31 09:31:34 wouldnt hurt 2019-10-31 09:31:50 we have same issue with gnome packages 2019-10-31 09:32:00 odd version number is devel 2019-10-31 09:32:08 even version number stable 2019-10-31 09:32:11 <_ikke_> indeed 2019-10-31 09:33:05 i have ~40 packages left in community to rebuild against python 3.8 2019-10-31 09:33:24 i wonder if i should push main+community before i do testing 2019-10-31 09:36:26 _ikke_: there are a lot of patches on ML from PureTryOut[m] maybe you should ask him to look what is already done and what is 'moved' to gitlab 2019-10-31 09:36:36 <_ikke_> ok 2019-10-31 09:37:10 he will know better the status of them than I 2019-10-31 09:37:14 <_ikke_> correct 2019-10-31 09:56:19 Uh afaik everything I've sent to the ML has been merged. It's a bit annoying that it doesn't show what has and what hasn't been applied 2019-10-31 09:56:59 <_ikke_> Yeah. someone has to update that 2019-10-31 09:57:15 <_ikke_> And right now, the list of people able to do that is limited 2019-10-31 09:57:31 I'll probably use ML again when that bit is fixed and the CI works πŸ˜› 2019-10-31 09:57:42 <_ikke_> https://lists.alpinelinux.org/~alpine/aports/patches?search=from%3Abart+ribbers 2019-10-31 09:58:04 <_ikke_> PureTryOut[m]: I wonder if the CI that Drew offers includes all the arches that Alpine supports 2019-10-31 09:58:20 Same 2019-10-31 09:58:41 <_ikke_> Right now, I just push patches from the mailing list to gitlab myself to test them 2019-10-31 09:59:46 when I argued for moving to gitlab I did it with idea that everything will be moved there, not to have scattered patches on few places 2019-10-31 10:00:07 <_ikke_> We at least want to move away from github 2019-10-31 10:00:27 <_ikke_> but some people still prefer a mailing list kind of workflow, and we do not want to force those to use gitlab 2019-10-31 10:00:51 I thought that the gitlab can create MR from git send-eamil 2019-10-31 10:00:58 Honestly, sr.ht is nice. It just needs to be properly configured πŸ˜‰ 2019-10-31 10:01:51 I tried that, didn't seem to work. Documentation for it is vague 2019-10-31 10:02:34 looks like it doesn't work in gitlab CE 2019-10-31 10:03:34 and the EE license is probably quite expensive 2019-10-31 10:04:08 You should not want to use a proprietary product anyway, keep it to CE 2019-10-31 10:04:35 wonder if Alpine's status in the world of docker would justify asking for a sponsorship (read: free EE version) from the maker 2019-10-31 10:05:20 <_ikke_> TBB: iirc they already offer EE to open source projects 2019-10-31 10:05:38 oh! 2019-10-31 10:07:35 Can't we have the same rule like KDE? Only use open-source/free products 2019-10-31 10:08:17 <_ikke_> PureTryOut[m]: we have no interest in persuing EE 2019-10-31 10:08:28 Awesome 2019-10-31 10:09:07 sounds to me you have two conflicting interests then 2019-10-31 10:09:27 <_ikke_> TBB: why? If he's contend with using the mailing list (which we still offer) 2019-10-31 10:11:03 wasn't it just pointed out that some people prefer ml based approach, and that GitLab CE doesn't support it but the EE does? 2019-10-31 10:12:02 I may have misunderstood completely, that's always an option 2019-10-31 10:13:13 Well I don't need the ML based approach, and if it allows me to stay away from EE I'll just use MR's like I do now. However, I can use ML fine with the sr.ht stuff Alpine also hosts 2019-10-31 12:10:33 5-6 packages left in community... 2019-10-31 12:11:23 im making progress with python 3.8 2019-10-31 12:11:48 <_ikke_> nice 2019-10-31 12:16:27 im a bit scared of testing repo... 2019-10-31 12:16:45 it is normally lower quality there than in main and community, so i expect more build breakages 2019-10-31 12:19:23 <_ikke_> I can imagine 2019-10-31 12:38:15 PureTryOut[m]: I'm having an issue with mopidy and python 3.8. Do you mind if i leave it to you after I push python 3.8? 2019-10-31 12:38:38 it seems to be the documentation that fails 2019-10-31 12:38:56 so alternatively we simply drop docs for now 2019-10-31 12:44:01 ncopa: Mopidy doesn't yet work with Python 3 2019-10-31 12:44:04 Next version (3.0) will include support for it 2019-10-31 12:44:12 ugh, ok 2019-10-31 12:44:15 then we have a problem 2019-10-31 12:44:37 i think we dropped py2 for some of its dependencies 2019-10-31 12:45:22 There was a py-tornado PR that got rejected because of Mopidy still depending on it 2019-10-31 12:45:24 Did some others get pushed anyway? 2019-10-31 12:46:05 I could push the latest commit from master as there seems to have been done a lot of Python 3 work recently, but I give no guarentees for it working properly or being stable 2019-10-31 12:46:11 probably 2019-10-31 12:46:23 it could also be for docs 2019-10-31 12:47:36 Ignore docs, it's not as important. The main program itself currently doesn't fully work on Python 3 yet, even if it installs fine 2019-10-31 12:47:37 https://github.com/mopidy/mopidy/issues/779#issuecomment-537825599 2019-10-31 12:47:38 or it was py-gst, which I problably removed py2 while upgrade it for python 3.8 2019-10-31 12:51:00 ok, i need to revert my py-gst thing then 2019-10-31 12:51:46 and now i remember why i dropped py2 2019-10-31 12:52:04 i need to do the fallback properly 2019-10-31 13:25:06 hum there are hundreds of packages that nees to be rebuilt in testing 2019-10-31 13:26:13 <_ikke_> all python? 2019-10-31 13:40:25 yup 2019-10-31 14:31:26 back to depends field, I see this in testing/node-sodium/APKBUILD:makedepends="libsodium-dev=1.0.11-r0 python2 npm" 2019-10-31 14:32:16 libsodium-dev=1.0.11-r0, if it works for makedepends does it also works for depends 2019-10-31 14:33:09 <_ikke_> yes, it works 2019-10-31 14:33:53 aha, then I could fix iwd 0.23 to explicitly depend on ell-0.25 2019-10-31 14:33:59 thanks 2019-10-31 14:34:50 <_ikke_> I do wonder what happens when you upgrade ell. I guess apk would complain when you try to install iwd 2019-10-31 14:38:45 it should automatically upgrade iwd then? 2019-10-31 14:39:49 <_ikke_> only if that is available 2019-10-31 14:40:36 but ell doesn't depend on iwd. it can be installed alone 2019-10-31 14:40:56 <_ikke_> mps: say someone updated ell to ell-0.26 2019-10-31 14:41:00 <_ikke_> but iwd is not updated 2019-10-31 14:41:11 <_ikke_> then when you try to install iwd, it would complain that it cannot find ell-0.25 2019-10-31 14:41:26 <_ikke_> or perhaps it would not update ell to ell-0.26 2019-10-31 14:41:53 true, because that I want to add depends="ell=0.25" to iwd 0.23 2019-10-31 14:42:17 and ell=0.26 to iwd 1.0 2019-10-31 14:43:08 reason is iwd 1.0 segfaults with ell-0.25 2019-10-31 14:44:04 <_ikke_> but if you installed ell-0.26, you can no longer install iwd 2019-10-31 14:44:55 yes for iwd 0.23, but iwd 1.0 could be installed 2019-10-31 14:45:12 <_ikke_> But we only have one version of iwd in the repos 2019-10-31 14:45:45 when (you) push ell-0.26 iwd 1.0 will follow shortly after that ;) 2019-10-31 14:46:03 <_ikke_> in theory :) 2019-10-31 14:46:40 hehe, but all that goes to edge, so we can expect short breakage 2019-10-31 14:47:45 <_ikke_> if we would have multiple versions of iwd in the repos, apk would pick the one that matches, on the other hand, you could also create conflicts (one packages wants version A, the other wants version B) 2019-10-31 14:49:37 uhm, ok, going to lunch, will think about that 2019-10-31 14:50:44 <_ikke_> multiple versions of ell I meant in this case 2019-10-31 14:51:51 but we will not have multiple ell versions ever, I think 2019-10-31 14:53:23 <_ikke_> No, but that's what in theory allows you to update ell separately from updating iwd 2019-10-31 14:55:04 hm, I'm tryig to solve practical problem and you drag me to theory field :) 2019-10-31 14:55:12 <_ikke_> sorry :) 2019-10-31 14:55:26 np, I'm just kidding 2019-10-31 14:55:52 <_ikke_> It's a tough thing to solve, because you would need to be able to install multiple versions of dependencies alongside eachother 2019-10-31 14:55:59 it is good to discuss (and learn) such cases 2019-10-31 14:58:38 isn't this in case we keep multiple versions of pkg in repo 2019-10-31 14:59:03 and we don't have multiple versions of pkgs in any repo 2019-10-31 14:59:31 <_ikke_> correct 2019-10-31 15:00:10 <_ikke_> We force everything to only use a single version of every package 2019-10-31 15:01:41 so, problem can arise in 'small' time window, till the all needed is upgraded and pass builders 2019-10-31 16:10:45 Can i get the security-sensitive MRs merged ? 2019-10-31 16:11:49 !689 !914 !915 !916 !917 2019-10-31 16:25:07 <_ikke_> maxice8: On it in a moment 2019-10-31 16:31:46 <_ikke_> I'll look at all of the open ones 2019-10-31 16:41:09 thank you :D 2019-10-31 16:44:40 <_ikke_> https://imgur.com/a/ROV7SPY :-) 2019-10-31 16:45:17 That is the plan 2019-10-31 16:54:09 hehe, just read long thread on debian-devel ML debating systemd and someone mention Alpine as example of successful distro without systemd 2019-10-31 16:58:39 <_ikke_> mps: pushed 2019-10-31 16:58:45 <_ikke_> maxice8: * 2019-10-31 17:01:15 <_ikke_> tmhoang: They set the issue status for the zabbix-agent2 build issues to resolved, but no details yet how / where it's fixed 2019-10-31 17:01:44 <_ikke_> Well, fix version 4.4.2, so let's see 2019-10-31 17:07:40 mps: They're going to vote on whether to keep computability with other inits, right? 2019-10-31 17:08:05 ACTION kinda misses systemd for coredump 2019-10-31 17:08:30 Does someone happen to know a good alternative to it, or will I have to look into implementing that this weekend? :P 2019-10-31 17:14:23 Cogitri: yes, they raises this to GR (general resolution) I think 2019-10-31 17:18:45 <_ikke_> maxice8: this mentions 3.7-stable, but there was no patch for 3.7? https://gitlab.alpinelinux.org/alpine/aports/issues/10926 2019-10-31 17:35:27 <_ikke_> mps: So if I would merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/949, iwd would break? 2019-10-31 17:37:39 right 2019-10-31 17:38:04 but when you push it I will push iwd 1.0 which will work 2019-10-31 17:38:06 <_ikke_> Would it make sense to include the iwd upgrade at the same time? 2019-10-31 17:38:44 <_ikke_> THey *can* be pushed at the same time 2019-10-31 17:38:57 I can, but didn't because don't want to bother you with both of them 2019-10-31 17:39:13 <_ikke_> That's not much of a bother to be honest 2019-10-31 17:39:34 and I think that the ell need to be on mirrors before pushing iwd. right? 2019-10-31 17:39:51 <_ikke_> No, it works if they are pushed at the same time 2019-10-31 17:40:16 <_ikke_> It builds packages in dependency order 2019-10-31 17:40:26 ah, ok then 2019-10-31 17:40:38 <_ikke_> and the builders use local packages, not the mirrors 2019-10-31 17:41:00 give me time to come back to home, about half an hour 2019-10-31 17:41:05 <_ikke_> sure, np 2019-10-31 17:41:09 <_ikke_> was just a heads up 2019-10-31 17:42:23 <_ikke_> I just saw that MR and thought about your question 2019-10-31 17:44:40 is this channel logged? 2019-10-31 17:45:04 artok: dev.a.o irclogs 2019-10-31 17:45:39 thanks 2019-10-31 17:51:22 just had to check if ncopa had any opinion on how to do broadcom updates 2019-10-31 17:57:39 artok: iirc, we discussed this about few months ago on this channel 2019-10-31 17:57:56 and he also 2019-10-31 18:00:01 for firmware, I haven't seen any (or been discussed) but about kernel we're already clear 2019-10-31 18:00:26 (or been discussing) 2019-10-31 18:00:48 we discussed non-free/b43-firmware 2019-10-31 18:01:11 I was only with yesterdays discussion 2019-10-31 18:03:17 shall linux-firmware package have same brcm folder on each platform, or not. there is the question 2019-10-31 18:04:47 artok: I think it should 2019-10-31 18:13:10 oh well, upstream is also changing now these days with the firmwares.. could wait for few days then 2019-10-31 18:13:36 as long as I've got working rpi4, I'm ok =) 2019-10-31 18:38:18 _ikke_: !967 2019-10-31 18:38:52 now I'm thinking that you meant both of in single MR 2019-10-31 18:39:13 because iwd failed on CI 2019-10-31 18:39:15 <_ikke_> mps: correct :) 2019-10-31 18:39:30 uhm, should ask you before 2019-10-31 18:39:41 <_ikke_> You can just push the commit in the same branch as the ell MR 2019-10-31 18:40:07 yes, I see now 2019-10-31 18:40:28 but don't know what to do now 2019-10-31 18:40:38 <_ikke_> You can close this MR 2019-10-31 18:40:43 <_ikke_> checkout the branch you used for ell 2019-10-31 18:40:51 <_ikke_> cherry-pick the commit for iwd 2019-10-31 18:40:53 <_ikke_> and push it 2019-10-31 18:41:10 ok 2019-10-31 18:42:52 any shortcut for cherry-pick (: 2019-10-31 18:43:35 <_ikke_> git cherry-pick 2019-10-31 18:43:58 <_ikke_> git cherry-pick iwd-1.0 2019-10-31 18:44:11 thought so, let's try 2019-10-31 18:47:20 !949 2019-10-31 18:47:29 does it looks better now 2019-10-31 18:47:45 <_ikke_> Yes 2019-10-31 18:48:33 <_ikke_> It's first building ell 2019-10-31 18:48:39 <_ikke_> I expect it to build iwd afterwards 2019-10-31 18:51:27 <_ikke_> iwd check failed 2019-10-31 18:51:53 <_ikke_> FAIL: unit/test-wsc 2019-10-31 18:52:54 I see, it passed without issue in lxc and on aarch64 edge 2019-10-31 18:53:41 interesting, test pass on s390x CI 2019-10-31 18:54:11 <_ikke_> heh, 2019-10-31 18:54:13 <_ikke_> for a change 2019-10-31 18:56:02 CI's are docker images? 2019-10-31 18:56:18 <_ikke_> yes 2019-10-31 18:56:25 <_ikke_> docker containers indeed 2019-10-31 18:57:14 I have no idea how to solve this 2019-10-31 18:58:22 I built it on lxc, on aarch64 edge, and backported to 3.10 on x86_64. all works fine 2019-10-31 18:59:13 <_ikke_> ok, let me see if I can reproduce it locally 2019-10-31 18:59:44 <_ikke_> (in docker)) 2019-10-31 19:04:36 not sure will it work in docker, if it not worked on CI 2019-10-31 19:05:04 but, try if you have time, would be good to know 2019-10-31 19:09:10 <_ikke_> repro 2019-10-31 19:09:46 <_ikke_> Aborted (core dumped) 2019-10-31 19:09:59 <_ikke_> Assertion failed: prime (unit/test-wsc.c: wsc_test_parse_m2: 1123) 2019-10-31 19:13:00 <_ikke_> Hmm, why would something like that fail only in docker? 2019-10-31 19:13:48 and at the same time pass on s390x, also docker 2019-10-31 19:14:00 <_ikke_> indeed 2019-10-31 19:14:20 <_ikke_> prime = l_key_new(L_KEY_RAW, crypto_dh5_prime, crypto_dh5_prime_size); 2019-10-31 19:14:22 <_ikke_> assert(prime); 2019-10-31 19:14:24 <_ikke_> this is the code that fails 2019-10-31 19:14:51 <_ikke_> But it's beyond me to fix that 2019-10-31 19:15:10 <_ikke_> Would it be worth to report it to iwd? 2019-10-31 19:15:40 not sure, because it works on native builds and in lxc 2019-10-31 19:16:14 will test on armv7 now 2019-10-31 19:16:31 <_ikke_> If you want to test it, this is what I did 2019-10-31 19:16:36 <_ikke_> in a directory with aports 2019-10-31 19:16:49 <_ikke_> docker run -it -v $PWD:/home/buildozer/aports/ --user buildozer -w /home/buildozer alpinelinux/alpine-gitlab-ci 2019-10-31 19:16:56 <_ikke_> then abuild-keygen -ai 2019-10-31 19:17:12 I don't have much experience with docker 2019-10-31 19:17:55 <_ikke_> It's not that hard to setup 2019-10-31 19:18:21 all this looks strange to me and probably will require some time to learn about it 2019-10-31 19:19:53 passed without any problem in armv7 lxc 2019-10-31 19:20:47 <_ikke_> There is an #iwd channel 2019-10-31 19:21:07 yes, and I'm there for months 2019-10-31 19:21:18 <_ikke_> is there any activity there? 2019-10-31 19:21:28 ofc, a lot I would say 2019-10-31 19:21:40 <_ikke_> ok, so it's worth it to ask there? 2019-10-31 19:22:19 well, I can, but suspect that I will get answer which will help us to solve build in docker 2019-10-31 19:22:33 will now 2019-10-31 19:22:36 <_ikke_> not 2019-10-31 19:22:38 <_ikke_> I guess 2019-10-31 19:22:46 <_ikke_> I joined the channels well 2019-10-31 19:26:46 ok, we asked and now have to wait 2019-10-31 19:26:54 <_ikke_> yes, indeed 2019-10-31 19:27:16 btw, n_copa is also there 2019-10-31 19:27:24 <_ikke_> yeah, noticed 2019-10-31 19:28:10 they usually answer all questions when they are online 2019-10-31 19:28:31 <_ikke_> ok, just have patience, which is not a bad thing 2019-10-31 19:28:55 need some docker help? 2019-10-31 19:29:06 #iwd is one of most pleasant channel, ime 2019-10-31 19:29:41 is the docker container running privileged mode? 2019-10-31 19:29:57 <_ikke_> crosbymichael_: Only if you can offer in-depth knoweledge on why a unit test about primes and cryptography only fails on docker, I guess not 2019-10-31 19:30:06 <_ikke_> s/only/unless 2019-10-31 19:30:06 _ikke_ meant to say: crosbymichael_: Only if you can offer in-depth knoweledge on why a unit test about primes and cryptography unless fails on docker, I guess not 2019-10-31 19:30:31 <_ikke_> d'oh :P 2019-10-31 19:30:48 hah =) only!=Only 2019-10-31 19:31:05 do you have a reproduction case that I can try and see what's up? 2019-10-31 19:31:07 <_ikke_> I thought I fixed that, but failed to 2019-10-31 19:31:15 <_ikke_> crosbymichael_: see above 2019-10-31 19:32:38 <_ikke_> http://tpaste.us/8XQk 2019-10-31 19:32:42 <_ikke_> something like that 2019-10-31 19:33:00 thanks 2019-10-31 19:46:12 _ikke_: running docker container in privileged mode and I'll get passed tests 2019-10-31 19:46:34 <_ikke_> Why should that matter :-/ 2019-10-31 19:46:51 some tests need devices that are isolated default by docker 2019-10-31 19:46:57 <_ikke_> what devices? 2019-10-31 19:47:10 dbus 2019-10-31 19:47:15 <_ikke_> :-/ 2019-10-31 19:47:41 at least one dbus test failed on ell without privileged 2019-10-31 19:47:54 <_ikke_> For me ell compiled without issues 2019-10-31 19:47:58 <_ikke_> it was iwd causing problems 2019-10-31 19:48:01 <_ikke_> and in CI as well 2019-10-31 19:48:02 hm, what is a difference between s390x docker and other 2019-10-31 19:48:05 <_ikke_> yea 2019-10-31 19:48:55 does s390x CI run in privileged mode 2019-10-31 19:49:02 <_ikke_> Not that I'm aware of 2019-10-31 19:49:59 ping - could someone tell Soren (or modify by hand) that restic should depend on ca-certificates in runtime? 2019-10-31 19:50:14 it hangs under some remotes if it's not present (without any debug information) 2019-10-31 19:50:31 <_ikke_> SpaceToast: so depends += ca-certificates? 2019-10-31 19:50:35 yes 2019-10-31 19:50:40 thanks _ikke_ :) 2019-10-31 19:50:54 <_ikke_> nmeum: ^ 2019-10-31 19:51:20 (reproducing is easy - b2 does so repeatedly, run any restic command against b2 without ca-certificates installed and it will hang forever) 2019-10-31 19:51:43 <_ikke_> Why would it hang? 2019-10-31 19:53:02 <_ikke_> mps: I don't see any configuration on the s390x host that runs docker in priviliged mode, and the containers are certainly not running in priviliged mode 2019-10-31 19:53:34 I suspect it's just infinitely retrying connections while using ca-certificates to establish tls connections 2019-10-31 19:53:42 I could dig through the code but eh 2019-10-31 19:53:50 <_ikke_> right, ok 2019-10-31 19:54:59 _ikke_: we can go previous route, push ell and after it build then push iwd 2019-10-31 19:55:17 on builders, I mean 2019-10-31 19:55:23 artok, _ikke_ it's actually the seccomp profile in docker blocking it, looking for the blocked syscall now... 2019-10-31 19:55:39 <_ikke_> mps: Do you have the patience to wait for ^ 2019-10-31 19:55:41 <_ikke_> ? 2019-10-31 19:56:01 yes, I have however long you want 2019-10-31 19:56:02 <_ikke_> Not that I insist to let it pass CI, just interested if we can manage it 2019-10-31 19:56:14 looking at it, it looks like Go might use ca-certificates for its stdlib tls stuff, but verifying that would take a while 2019-10-31 19:56:27 and I understand you intention at this 2019-10-31 19:56:45 so, no problem for me 2019-10-31 19:56:45 <_ikke_> clandmeter: What was it with golang and ca-certificates? 2019-10-31 19:57:06 <_ikke_> crosbymichael_: thanks for helping :) 2019-10-31 19:57:52 <_ikke_> I love it that it's easily reproducable locally just by downloading the alpine-gitlab-ci image 2019-10-31 19:58:01 aren't our ca-certificates outdated 2019-10-31 19:58:31 <_ikke_> SpaceToast: https://gitlab.alpinelinux.org/alpine/aports/issues/10929 2019-10-31 19:58:55 ty _ikke_ :) 2019-10-31 19:59:04 one thing to note is that golang binaries do not depend on golang itself 2019-10-31 19:59:16 so it'd be a question of which ones need it vs not (as-is restic only depends on musl, for example) 2019-10-31 19:59:27 <_ikke_> Isn't that by design? 2019-10-31 19:59:47 yes, it is, I'm just saying that a naive approach of making go depends on ca-certificates (it might already, haven't checked) won't help 2019-10-31 19:59:50 (unlike with python etc) 2019-10-31 19:59:59 <_ikke_> yea 2019-10-31 20:00:30 <_ikke_> clandmeter noted before that depending on ca-certificates is not necessary usually 2019-10-31 20:01:00 mhm, in this case the difference is very clear 2019-10-31 20:01:09 30m of zero activity vs output within a second 2019-10-31 20:01:23 kind of why I'm fairly confident in the conclusion, even without digging through the sources 2019-10-31 20:01:39 You can make go use certs.pem or whatever the name is 2019-10-31 20:02:04 <_ikke_> " @clandmeter ncopa: can we symlink /etc/ssl/cert.pem to /etc/ssl/certs/ca-certificates.crt via some trigger or similar?" 2019-10-31 20:02:22 aha 2019-10-31 20:02:31 well, I'll let you lot figure it out, just making sure people know restic is affected :) 2019-10-31 20:02:32 \o 2019-10-31 20:02:39 <_ikke_> np. thanks 2019-10-31 20:03:20 It should probably depends on ca-certs 2019-10-31 20:03:59 For sure if you want to support your own certs 2019-10-31 20:04:59 <_ikke_> I do recall having issues getting our custom root CA at $work to work well with python requests, but I have no idea if it has to do with ca-certificates or not 2019-10-31 20:05:24 <_ikke_> python-requests has it's own root ca bundle 2019-10-31 20:09:54 back 2019-10-31 20:13:42 <_ikke_> wb 2019-10-31 20:14:19 maxice8: \o 2019-10-31 20:14:42 o/ 2019-10-31 20:15:35 _ikke_, that test is calling add_key() that is being blocked 2019-10-31 20:17:20 i believe the seccomp list is a whitelist so i'll have to see about adding those syscalls to the default profile. Do you have access to the docker nodes on the cI so you can add a custom seccomp profile in the meantime? 2019-10-31 20:17:32 <_ikke_> yes, I have 2019-10-31 20:17:50 <_ikke_> crosbymichael_: Any clue why it works on s390x? 2019-10-31 20:18:53 looking at the profile now, there are a few switch that modify the profile for x390x 2019-10-31 20:19:04 so there could be a difference because of that 2019-10-31 20:19:44 <_ikke_> ok 2019-10-31 20:32:26 i actually have no clue why it's allowed on s390 2019-10-31 20:38:36 i found https://github.com/moby/moby/pull/18780#issuecomment-166353303 2019-10-31 20:39:40 but i think it's ok to allow it now as each container gets it's own keyring now 2019-10-31 20:40:31 add_key, keyctl, request_key 2019-10-31 20:40:34 ? 2019-10-31 20:41:04 crosbymichael_: ^ 2019-10-31 20:41:30 add_key was the only one I saw blocked in that test 2019-10-31 20:41:40 but the others should probably be good to add 2019-10-31 20:42:49 I can patch iwd to not run problematic test (as I did for pkcs8) but not sure is that a good idea 2019-10-31 20:43:33 you can add those syscalls to a custom seccomp profile on the CI nodes 2019-10-31 20:43:57 i can open a PR to docker to discuss adding them 2019-10-31 20:44:20 i just need to make sure it's safe now that each container has it's own keyring 2019-10-31 20:44:22 yes, I think this is better to do 2019-10-31 20:45:03 <_ikke_> crosbymichael_: any pointer what to set as a profile, and potential risks? 2019-10-31 20:45:12 <_ikke_> I've never done anything with seccomp before 2019-10-31 20:46:54 you can modify this https://github.com/moby/moby/blob/master/profiles/seccomp/default.json 2019-10-31 20:47:59 https://docs.docker.com/engine/security/seccomp/ 2019-10-31 20:48:12 there will be a flag `--security-opt seccomp=/path/to/seccomp/profile.json \` 2019-10-31 20:48:22 <_ikke_> thanks 2019-10-31 20:48:43 <_ikke_> crosbymichael_: and your suggestion is to enable add_key, right? 2019-10-31 20:49:19 yes 2019-10-31 20:49:21 _ikke_: sooner or later we will need this 2019-10-31 20:49:23 <_ikke_> And this is not a risk because now containers get their own keyring? 2019-10-31 20:50:38 i have too look more into the risk but "i think" it should be safe now that containers have their own keyring (not inheriting the kernels') 2019-10-31 20:51:08 <_ikke_> k 2019-10-31 20:52:47 <_ikke_> crosbymichael_: thanks so much for your support, (and sorry for my snarky response at the beginning) 2019-10-31 20:52:56 no worries at all 2019-10-31 20:56:11 @_ikke_> tmhoang: They set the issue status for the zabbix-agent2 build issues to resolved, but no details yet how / where it's fixed : fancy a link ? 2019-10-31 20:56:30 <_ikke_> sure 2019-10-31 20:56:47 <_ikke_> tmhoang: https://support.zabbix.com/browse/ZBX-16769 2019-10-31 20:57:29 <_ikke_> (look at history, there are no comments from them) 2019-10-31 20:59:48 _ikke_: that's quite harsh lol no comment, just closed the issue lol 2019-10-31 20:59:51 internet 2019-10-31 21:01:09 <_ikke_> Their development is very internal 2019-10-31 21:14:12 <_ikke_> mps: testing on my desktop now 2019-10-31 21:15:02 waiting .... 2019-10-31 21:15:05 <_ikke_> crosbymichael_: it does not seem to work 2019-10-31 21:15:13 <_ikke_> I run docker like this: /usr/bin/dockerd -H fd:// --seccomp-profile=/etc/docker/seccomp/seccomp.json 2019-10-31 21:15:29 <_ikke_> In seccomp.json I'ved added the file that you linked to. 2019-10-31 21:15:46 <_ikke_> In the first list with syscall names, I've included add_key, restarted docekr 2019-10-31 21:15:56 <_ikke_> but it stil fails to build iwd 2019-10-31 21:16:26 <_ikke_> crosbymichael_: or do I need to recreate the container? 2019-10-31 21:17:04 _ikke_: could you try with all these: add_key, keyctl, request_key 2019-10-31 21:17:09 <_ikke_> k 2019-10-31 21:17:25 not that I know how docker works, just guessing 2019-10-31 21:18:43 <_ikke_> :-) 2019-10-31 21:18:57 <_ikke_> # TOTAL: 18 2019-10-31 21:18:59 <_ikke_> # PASS: 18 2019-10-31 21:19:05 heh, nice 2019-10-31 21:19:28 <_ikke_> But I will first ask clandmeter if we should do this before applying it to CI 2019-10-31 21:20:00 ofc, but keep in mind that he will be pro for this ;) 2019-10-31 21:20:02 <_ikke_> crosbymichael_: fyi ^ 2019-10-31 21:20:12 <_ikke_> you need all 3 syscalls 2019-10-31 21:21:23 sounds logical, if add_key is allowed then at least request_key is also needed 2019-10-31 21:22:20 <_ikke_> nod 2019-10-31 21:22:23 <_ikke_> let me check 2019-10-31 21:22:28 <_ikke_> if keyctl is needed 2019-10-31 21:23:01 <_ikke_> yup 2019-10-31 21:23:33 yup? all three? 2019-10-31 21:23:42 <_ikke_> ha, not request_key :D 2019-10-31 21:24:10 but it is less risky 2019-10-31 21:24:16 <_ikke_> add_key and keyctl 2019-10-31 22:27:22 <_ikke_> ncopa: fyi, kernel patch that is still open: https://lists.alpinelinux.org/~alpine/aports/patches/3100 2019-10-31 22:28:20 ya, you need to restart the container 2019-10-31 22:28:56 <_ikke_> yes, but not rebuild 2019-10-31 22:29:07 <_ikke_> I restared docker 2019-10-31 23:27:06 SpaceToast: regarding ca-certificates and restic: what kind of remotes are you talking about? e.g. which backup backend 2019-10-31 23:27:39 nmeum: b2 2019-10-31 23:27:44 (as mentioned in the bug etc) 2019-10-31 23:27:51 I could test all of them but that sounds like a lot of pain 2019-10-31 23:28:45 no need to 2019-10-31 23:29:00 but hm, we had this discussion previously and one could argue that it is an optional dependency then 2019-10-31 23:29:15 and usually we don't add optional dependencies to $depends since you can't uninstall them then 2019-10-31 23:30:06 it's a pity though that restic doesn't report this as an error and hangs 2019-10-31 23:31:20 anyway, it's a very unfortunate time to discuss these topics (at least in my timezone) will be back tomorrow :)