**** BEGIN LOGGING AT Tue Mar 12 02:59:57 2019 Mar 12 16:31:59 rburton: it's some oddball one-off for $reasons iirc Mar 12 16:35:43 Opensource summit is being combined with elc in Americas, earlier they were held separately, whereas in EU it was always together, thats why this year its offsetted, it will return to spring schedule in 2020 Mar 12 16:36:05 hey khem Mar 12 16:36:49 khem: Re alternatives and rshd/etc, should I just split all those out into separate packages that'll be empty on musl? They don't even try and build there as musl lacks some old syscalls Mar 12 16:36:55 or something along those lines Mar 12 16:37:38 configure: WARNING: Disabling rlogind and rshd, since no iruserok and no ruserok. Mar 12 16:45:11 Tartarus: ruserok is non posix so thats why you see its not there in musl, it would be good to check for it, and then return 0 when it does not exist Mar 12 16:46:59 khem: I don't follow. the version of the stuff in that package will not build on musl, so how do we want to handle the packaging side of that? Mar 12 16:48:18 khem: We don't, iirc, need them for busybox compatibility either Mar 12 16:49:35 khem: The problem is I don't see a way to whack alternatives stuff with an override Mar 12 16:49:57 I am suggesting to bypass need for these functions during build Mar 12 16:50:07 so we can build these pieces Mar 12 16:51:07 khem: Why? IMHO providing non-functional binaries is way worse Mar 12 16:53:14 We also hit: Mar 12 16:53:15 configure: WARNING: protocols/talkd.h is not available, not building talk, nor talkd Mar 12 16:53:40 I really have no interest in beating these things into building and then not working to silence a packaging warning Mar 12 16:54:02 (I'd go the easier route of making them point at /bin/false or something but still, that's the wrong direction) Mar 12 16:55:47 khem: There's no form of ALTERNATIVE_${PN}-rshd_libc-musl or similar that I can find, so is there anything else short of just re-working the package split, or faking the binaries into building, that I'm missing? Mar 12 16:56:39 thats fine, we can also turn them into individual ipks and that would be okay Mar 12 16:58:26 I was hoping we could fix it but its a hopeless package when it comes to portability Mar 12 16:58:42 Esp for stuff almost no one uses anymore Mar 12 16:58:54 rsh & company are a horrible idea these days :) Mar 12 16:59:05 And no one wants talk anymore Mar 12 16:59:16 (I don't think I've even used it since the 90s) Mar 12 16:59:21 I would rather use things from other packages Mar 12 16:59:49 hah, talk Mar 12 16:59:54 exactly, so I was kind of amazed that we dont want to use busybox but rather jump into abysss Mar 12 16:59:55 'mesg n' Mar 12 17:00:39 khem: I'm still smarting from that tar symlink creation fuck-up they did upstream Mar 12 17:00:55 I still need to understand why we cant use busybox versions Mar 12 17:01:08 khem: busybox versions of what? Mar 12 17:01:25 these utils that inetutils is supposed to provide Mar 12 17:01:39 khem: You can, just fine. The packaging warnings turned errors are from that package Mar 12 17:01:45 I think most of them are provided by busybox Mar 12 17:01:51 And nothing actually wants to pull in rshd & co Mar 12 17:02:01 They aren't enabled in busybox by default, iirc Mar 12 17:02:06 but lemme check again Mar 12 17:02:19 I understand the problem, but I dont understand is the itch to use inetutils Mar 12 17:02:54 khem: For real utilities? Mar 12 17:05:22 Actually, heck, I wonder what the other provider of "talk" and "rshd" and stuff even is Mar 12 17:05:24 I think most of them can be replaced by other non-busybox packages e.g. iputils etc. Mar 12 17:07:49 telnet might have been the odd one out there Mar 12 17:09:40 maybe just build the packages that are needed and disable the others Mar 12 17:10:13 subset might be buildable across both libcs Mar 12 17:10:56 my take is if no one fixed inetutils on musl in these years then its not as important a package Mar 12 17:10:58 Yes, that's what we do now Mar 12 17:11:11 inetutils builds fine on musl Mar 12 17:11:26 It just has these errors on the non-standard config the autobuilder uses Mar 12 17:14:19 yeah rsh/rcp/rlogin are disabled on musl, is it being used ? Mar 12 17:14:48 By anyone in this day and age? I hope not. Mar 12 17:16:25 maybe disable then on glibc as well Mar 12 17:16:51 We allow lots of other bad security designs Mar 12 17:20:10 thats no justificationf for adding another one :) maybe use remove_libc-musl to remove these from alternatives Mar 12 17:33:02 khem: I tried that, I swear, and it wasn't evaluated out right. but good news is, afaict there's no need for these to be alternatives Mar 12 17:33:13 Maybe ages ago someone else also provided them, but they don't today Mar 12 17:35:19 okay thats simpler then Mar 12 17:39:03 wait, no, netkit, how did I forget to check that more specifically Mar 12 17:57:59 Ugh, this warning happens even if we don't have anything in that package Mar 12 17:59:00 * Tartarus tries harder to find the right overrides order Mar 12 18:11:24 khem: OK, need to build for glibc quick, netkit-rsh blows up on musl as it's not as smart as inetutils ;) But I'll have something shortly enough. Can you off-hand tell me the "disable package X on musl" bit to add? I'll grep later if you don't see this in time, getting ready to grab the kids from school Mar 12 19:19:46 khem, ping Mar 12 19:20:28 armpit:yes Mar 12 19:21:40 khem, have you seen any issues with arm64 musl for gdb and strace ? Mar 12 19:23:11 I am using 5.0 kernel and master core Mar 12 19:36:15 khem: OK, I'll be posting the inetutils stuff shortly now, testing the final patch which is just nuking it all together after cleaning it up. So if someone is crazy enough to want it, they can still get it Mar 12 19:44:25 armpit: yes there are ptrace.h conflicts with kernel headers IIRC Mar 12 19:44:43 Tartarus:sounds good Mar 12 19:45:19 khem, k, looks like what I am seeing Mar 12 20:19:50 armpit: I have sent a kernel headers patch which was supposed to fix it and I think its fixed upstream as well so I was hoping it is fixed with 5.0 kernel unless Bruce missed somethings Mar 12 20:55:33 So, do we have any informal guidelines on when we expect the user to override a conf file via layer or not? For example, dnsmasq.inc puts dnsmasq.conf in SRC_URI so it's easy to package your own up. hostapd on the other hand, does not. Mar 12 21:04:21 change hostapd Mar 12 21:04:38 usually it depends on package Mar 12 21:04:42 no hard rules Mar 12 21:52:02 khem: That's kinda what I figured. I'll put that on my list Mar 12 21:52:34 khem: Any thoughts on perhaps enabling /etc/sudoers.d ? That I know I should take up on the ML tho Mar 12 21:53:06 I dunno if that or overriding sudoers is more sensical **** ENDING LOGGING AT Wed Mar 13 02:59:57 2019